Instalando a linguagem Go no Mac

13 de novembro de 2009  |  Open Source  |  3 Comentários  | 

logo-153x55O Google acabou de anunciar o lançamento de uma nova linguagem de programação chamada Go. A linguagem foi desenvolvida por um time formado por cinco engenheiros do Google, incluindo Ken Thompson e Rob Pike, que são famosos por terem trabalhado no UNIX.

De acordo com o Google, além de oferecer suporte integrado a processos concorrentes, Go tem a pretensão de combinar a velocidade de desenvolvimento de uma linguagem dinâmica com a performance de uma linguagem compilada.

Eu ainda não testei a linguagem o suficiente para poder expressar qualquer opinião. De qualquer forma, a melhor coisa a fazer é testar por si próprio e tirar suas próprias conclusões. Abaixo você vai encontrar um breve tutorial com os passos que percorri para instalar tudo o que é necessário para começar a brincadeira no meu Mac Os. Espero que ele seja útil para você também.

Instalando o Mercurial

Mercurial é uma ferramenta de controle de versão distribuído, assim como o nosso querido Git. É necessário instalá-lo para poder baixar o código fonte do Go.

Eu utilizei o instalador disponível para Mac na página de downloads no próprio site da ferramenta.

Após a instalação, você pode verificar se tudo deu certo digitando o comando abaixo no terminal:

$ hg version

No meu caso, uma mensagem de erro foi disparada e a solução foi configurar algumas variáveis de ambiente. Se isto também acontecer com você, abra o arquivo ˜/.profile e acrescente as seguintes linhas no final:

# Mercurial
export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8

Configurando o ambiente para a instalação do Go

Aproveite que você já está com o arquivo .profile aberto e também acrescente as seguintes linhas no fim do arquivo. Estas linhas servem para configurar o seu ambiente para a instalação do Go.

# Go
export GOROOT=$HOME/Sources/go
export GOOS=darwin
export GOARCH=amd64
export GOBIN=$HOME/Development/Go/Binaries
export PATH=$GOBIN:$PATH

$GOROOT deve conter o diretório onde o código fonte da linguagem será baixado.

As variáveis $GOOS e $GOARCH servem para configurar o seu ambiente. As combinações validas são: linux/amd64, linux/arm, linux/386, darwin/amd64, darwin/386 e nacl/386. O código acima está preparado para a instalação no Mac OS 10.6.

E por último, a variável $GOBIN deve conter o diretório onde você deseja que os binários do Go sejam instalados. Se você optar por instalar os binários no diretório /usr/local/bin, aconselho ler esta discussão. Esta variável é opcional e o valor padrão para ela é o diretório $HOME/bin.

Para garantir que tudo está funcionando execute:

$ env | grep '^GO'

O resultado deve ser uma lista semelhante a esta:

GOBIN=/Users/carlosbrando/Development/Go/Binaries
GOARCH=amd64
GOROOT=/Users/carlosbrando/Projects/go
GOOS=darwin

Instalando

Após instalar o Mercurial, utilize o comando abaixo para recuperar o código fonte do projeto:

$ hg clone -r release https://go.googlecode.com/hg/ $GOROOT

Antes de continuar, certifique-se de criar o diretório que você configurou para receber os binários e execute os comandos abaixo:

$ cd $GOROOT/src
$ ./all.bash

Criando o primeiro programa

Se tudo correu bem, você já tem o seu ambiente pronto para começar a programar em Go. E nada melhor do que um “Hello, world” para começar. Crie um arquivo com o nome helloworld.go e adicione o seguinte código nele:

package main

import fmt "fmt"

func main() {
  fmt.Printf("Hello, world\n");
}

Primeiro compile o arquivo com o comando:

$ 6g helloworld.go

Para “linkar” o arquivo utilize:

$ 6l helloworld.6

E para executar:

$ ./6.out
Hello, world

Agora é só continuar no tutorial criado pelo próprio time de desenvolvimento. E não deixe de compartilhar suas experiências com a linguagem deixando um comentário.

Remarkable 3.0 is out and it’s… well… remarkable!

14 de abril de 2009  |  English, Open Source, Remarkable  |  6 Comentários  | 

Wow, a major release? Yes, a major release and we have plenty reasons for that. Since me and José Valim were working on it for a couple months, we have quite a list :). So follow up:

1. Remarkable Core

Remarkable is now a framework for rspec matchers. Since Rails matchers are not simple, as Remarkable grew, we saw our matchers full of logic to show messages (description and failure messages) and that some methods could be automatically generated, reducing repetitive work.

Compare the allow_mass_assignment_of matcher in Remarkable 2.x and in Remarkable 3.0. Which one do you prefer? :)

So we built a DSL and called it Remarkable, which with Remarkable ActiveRecord and Remarkable Rails, provides you nice matchers/macros to speed up your tests. To install them, just do:

sudo gem install remarkable_rails

You can also install just remarkable or just remarkable_activerecord. But remarkable_rails brings you the whole packet.

2. I18n

On Rails Summit Latin America, Obie Fernandez talked about the Hash Rocket way and one of the items were that they actually print out the specs and give it to the client. Both me and José work with Rails projects and we couldn’t deliver the same to technical clients, because the output was in english. Well, we scratched our own itch!

This is how an English output would be like:

Example disabled: require age to be set

User
- should require name and email to be set
- should ensure length of name is within 3..40 characters
- should require unique values for email
- should ensure numericality of age allowing only integer values and allowing blank values

In Remarkable, we can have the same results in Portuguese:

Exemplo desativado: exigir presença de idade

Usuário
- deve exigir presença de nome e email
- deve garantir tamanho de nome seja entre 3..40 caracteres
- deve garantir valores únicos para email
- deve aceitar apenas números em idade permitindo somente valores inteiros e permitindo valores nulos

As you have noticed everything gets translated including the class and attributes names. This happens by setting up Remarkable and Rails yml files.

3. Macros

In Remarkable earlier versions, we coded the matcher (validate_presence_of) but most of the time we had to do some tweaks in other to a matcher becomes a macro (should_validate_presence_of). In Remarkable 3.0 it happens transparently.

In other words, if you are using Remarkable 3.0 to build your matchers you have cleaner matchers, I18n support and transparent macros creation.

4. Pending and disabled macros

In Remarkable 2.2, we added the ability to mark macros as disabled:

xshould_validate_uniqueness_of :name

And it would print on your specs output:

Example disabled: require unique values for name

As some people pointed out, Remarkable was still lacking support for pending macros. Pending examples in Rspec would be:

it "should have one manager" do
  pending("create managers resource")
end

it "should validate associated manager" do
  pending("create managers resource")
end

And now in Remarkable, you have the pending group:

pending "create managers resource" do
  should_have_one :manager
  should_validate_associated :manager
end

In both cases a message “PENDING: create managers resources” is appended to matcher description.

5. More options to matchers

In Remarkable 2.2, we started to support ALL Active Record validations with ALL options. And now we extended support for association matchers!

From only :dependent and :through as supported options, now it accepts:

:through, :class_name, :foreign_key, :dependent, :join_table, :uniq, :readonly, :validate, :autosave, :counter_cache, :polymorphic

Besides matchers became much smarter. Whenever :join_table or :through is given as option, it also checks if the given table exists. Whenever :foreign_key or :counter_cache is given, it also checks if the given column exists.

6. Controllers matchers extended

To provide I18n, we ported redirect_to and render_template matchers from rspec-rails. We also added some extra options to respond_with and render template, so you can now do:

render_template 'edit', :layout => 'users'

respond_with 422, :content_type => Mime::XML,
                  :body => /Unprocessable Entitity/

And the route matcher is willing to make your life twice easier. Since it tests params recognitation and routes generation at once, you can cut your routing_specs at least in a half! So the following lines:

route_for(:controller => "companies",
          :action => "show",
          :id => "1").should == "/companies/1"

params_from(:get, "/companies/1").should == { :controller => "companies",
                                              :action => "show",
                                              :id => "1" }

Will become:

route(:get, "/companies/1", :controller => "companies",
                            :action     => "show",
                            :id         => "1")

7. Macro stubs

There is a presentation from José Valim that explains this feature with more details, but it basically makes your controllers specs from this:

describe TasksController do
  def mock_task(stubs={})
    @task ||= mock_model(Task, stubs)
  end

  describe "responding to #POST create" do
    it "exposes a newly created task as @task" do
      Task.should_receive(:new).with({'these' => 'params'}).
      and_return(mock_task(:save => true))‏
      post :create, :task => {:these => 'params'}
      assigns[:task].should equal(mock_task)end

    it "redirects to the created task" do
      Task.stub!(:new).and_return(mock_task(:save => true))‏
      post :create, :task => {}
      response.should redirect_to(task_url(mock_task))end
  end
end

Become this:

describe TasksController do
  mock_models :task

  describe :post => :create, :task => {:these => 'params'} do
    expects :new,  :on => Task, :with => { :these => 'params' }, :returns => mock_task
    expects :save, :on => mock_task, :returns => true

    should_assign_to :task, :with => mock_task
    should_redirect_to { task_url(mock_task) }
  end
end

It aims to improve readability and be more DRY, since you declare your expectations/stubs just once. You can see the whole controller specs in rspec and remarkable way compared here.

It works by eval’ing the expectation/stubs chain and performing the action before each macro is executed. On should_assign_to it evals using expectations (:should_receive), on should_redirect_to it uses stubs (:stub!).

We also want to thank David Chelimsky that gave the nice hint to allow :post => :create inside the describe method and suggested to use mocha syntax. :)

8. Documentation, documentation and documentation

Yes, three times, because each project is very well documented. Browse them:

Remarkable:
http://remarkable.rubyforge.org/core/

Remarkable ActiveRecord:
http://remarkable.rubyforge.org/activerecord/
http://remarkable.rubyforge.org/activerecord/classes/Remarkable/ActiveRecord/Matchers.html (just matchers)

Remarkable Rails:
http://remarkable.rubyforge.org/rails/
http://remarkable.rubyforge.org/rails/classes/Remarkable/ActionController/Matchers.html (just matchers)

9. Volunteers?

Last but definitely not least: we need you!

http://travelpod.files.wordpress.com/2009/02/446px-uncle_sam_pointing_finger.jpg

We created a solid basis for matchers/macros creation. And we want to take it further by hosting even more matchers. So anyone who wants to work on Remarkable Datamapper, Remarkable Sequel, Remarkable Sinatra, please step in! We are waiting for you. :)

And all the others can equally help us by joining the group and posting bugs, matchers, enhancements in bug tracking system.

Remarkable 2.3 is out!

18 de março de 2009  |  Open Source  |  2 Comentários  | 

Remarkable 2.2.x series was made of frequent releases with deprecation warnings to consolidate the API. Until we get into 2.3, we improved support for ActiveRecord validations, fixed some bugs and made some changes, so we are safe and clear to work on new features and new matchers.

We also run our specs suite in Rails 2.3.x and Rspec 1.2.0 to assure that everything is working as supposed, and they are. :)

Keep on checking, we will have very good news, very soon. So get Remarkable on Github, appear in the mailing list and if you find some problems, tell us about them in the bug tracking system.

Thanks for everyone who collaborated, we are getting solid as rock. :)

Utilizando valores de entrada como sugestões, a maneira fácil

23 de janeiro de 2009  |  Javascript, Open Source  |  5 Comentários  | 

Thomas Fuchs, o criador do script.aculo.us iniciou um novo projeto esta semana chamado Prototype helpers. O projeto visa disponibilizar uma série de scripts do Prototype criados por ele.

Eu particularmente gostei muito do defaultValueActsAsHint, um script que facilita a inclusão de dicas sobre o preenchimento de um formulário dentro do próprio campo no formato de um texto mais claro. Ao se clicar no campo o texto some, mas caso o usuário não preencha o campo o texto volta a aparecer ao perder o foco.

O efeito em ação

O efeito em ação

Enfim, é melhor mostrar do que falar. Clique aqui para ver um exemplo funcionando.

Como não sou um usuário de Prototype, fiz questão de portar este script para um plugin do jQuery, que faço questão de disponibilizar para vocês.

Para usar é muito fácil, lembrando que você deve estar usando o jQuery, basta incluir o script abaixo em sua página:

(function($){
  $.fn.defaultValueActsAsHint = function() {
    return this.each(function() {
      $(this).attr('_default', $(this).attr('value'))
      $(this).addClass('hint');

      $(this).bind('focus', function(event) {
        if ($(this).attr('_default') == $(this).attr('value'))
          $(this).removeClass('hint').attr('value', '');
      });

      $(this).blur(function() {
        if ($.trim($(this).attr('value')) == '')
          $(this).addClass('hint').attr('value', $(this).attr('_default'));
      });

    });
  };
})(jQuery);

Download: jquery.defaultvalueactsashint.js

E definir quais campos se beneficiarão deste script, assim:

<script type="text/javascript" charset="utf-8">
  $('#foo').defaultValueActsAsHint();
</script>

Como sempre, tudo está em um projeto no GitHub. Bom divertimento!

Remarkable 2.0.1 e Atualização do (Comovente) Guia de Ruby do Why

Remarkable 2.0.1 e Atualização do (Comovente) Guia de Ruby do Why

19 de dezembro de 2008  |  Destaques, Meus Livros, Open Source, Remarkable, Ruby  |  8 Comentários  | 

Desde que lancei a primeira versão do Remarkable tenho visto cada vez mais pessoas aderindo ao projeto para criar seus testes com maior rapidez. E com uma quantidade maior de pessoas usando nas mais diversas aplicações é claro que os bugs começaram a aparecer.

A maior parte dos problemas ocorriam por uma falha na arquitetura inicial do Remarkable, o que tornou necessário um refactoring no projeto inteiro para estruturá-lo melhor. Na primeira versão, internamente havia uma separação muito clara entre as duas sintaxes que o projeto oferecia. Com a reestruturação não existe mais esta separação, não importa qual é o seu estilo, RSpec ou Shoulda, internamente você sempre usará o mesmo código para realizar os testes.

Desta forma, acabamos por ganhar muitas macros novas.

Enquanto na versão em RSpec isto já era algo comum:

describe Dog do
  it { should belong_to(:user) }
  it { should_not have_many(:fleas) }
end

Na sintaxe do Shoulda apenas possuíamos macros should_[alguma coisa] e quase nenhuma should_not_[alguma coisa]. Mas agora todas as macros possuem as duas opções, assim:

describe Dog do
  should_belong_to :user
  should_not_have_many :fleas
end

Além disso mais testes foram adicionados para garantir que problemas antigos não voltem para nos assombrar.

Para atualizar o Remarkable, execute no terminal (lembrando que no Windows não precisa usar o sudo):

gem sources -a http://gems.github.com
sudo gem install carlosbrando-remarkable

Ainda falta um logo e um site para o projeto. Alguém se habilita?

O (Comovente) Guia de Ruby do Why

wixl-9

Acabei de atualizar o livro com novas traduções e correções. Devido a minha falta de tempo, acabei demorando para aplicar alguns dos patches que me foram enviados.

Na maioria das vezes, os colaboradores são rápidos demais e várias pessoas corrigem o mesmo texto de formas diferentes, e isto complica um pouco na hora de aceitar uma atualização. Eu tenho de olhar arquivo por arquivo antes de decidir qual será aplicado. Mas isto é bom, porque garante uma maior qualidade à tradução, embora torne o processo um pouco mais lento.

O livro pode ser encontrado na url: http://why.nomedojogo.com. Também existe uma versão para impressão em http://why.nomedojogo.com/print.html.

A processo de tradução já foi finalizado, todo o livro já está em português. Ainda falta ajustar algumas imagens e formatações de texto, mas acredito que se conseguirmos mais colaboradores teremos o livro completo e finalizado até o fim do ano.

Quer ajudar? Comece lendo o livro e quando encontrar algo errado altere aqui.

Twitter Images

Twitter Images

27 de novembro de 2008  |  Open Source, Remarkable  |  Nenhum comentário  | 

Rails 2.2 – Finalmente

23 de novembro de 2008  |  Notícias, Open Source, Rails 2.2  |  1 Comentário  | 

Finalmente a versão final do Rails 2.2 saiu!

Acho que já cobrimos todas as novidades desta nova versão, e de várias formas possíveis. Para ficar sabendo de tudo que temos de novo você tem três formas:

Série Edge Rails (Rails 2.2): clique aqui.

Rails Podcast Especial Rails 2.2: clique aqui.

Livro “Ruby on Rails 2.2 – O que há de novo?”: clique aqui.


Para atualizar, primeiro você precisa ter a versão 1.3.1 do RubyGems:

gem update --system

Então instale a última versão do Rails:

gem install rails

Shoulda for RSpec is Remarkable!

18 de novembro de 2008  |  Destaques, English, Open Source  |  23 Comentários  | 

For a long time I was evangelizing Shoulda at Surgeworks and used it in my personal projects. The fact is, I didn’t have much success in convincing my co-workers to adopt Shoulda. On the other hand, they managed to convince me to learn and use RSpec.

RSpec is a very interesting Testing Framework. But I start to like it more after I started to use the Cucumber.

The great thing about Shoulda is that it’s simplifies tests for trivial things.

I got to like RSpec more and more, so I decided to adopt it as my official testing framework from now on. But I can no longer live without the resources that Shoulda offers me. So I decided to scratch my itch.

Remarkable

Initially, the main objective of Remarkable is to port all Shoulda macros to RSpec, but of course the plan is more ambitious than that. I have other ideas that will hopefully be especially useful for Rspec users.

At this point you may ask: “But aren’t there already plug-ins that do the same thing, such as skinny and rspec-on-rails-matchers. Why build something else?”

First, this isn’t simply “another” plugin with RSpec matchers. It also does a lot of things differently that I feel are better than other approaches.

Here are some of the things that make Remarkable special:

  1. It is not a plug-in; it’s a gem.
  2. All currently Shoulda macros are ported to RSpec.
  3. It has two different test syntaxes: one for those who like the RSpec style and another for those who are migrating their projects from Shoulda to RSpec.
  4. Tests.
  5. More tests.
  6. And a few more tests.

Unlike other similar projects, Remarkable is the only one that tests itself, and this is a big difference, believe me! How can we trust in a project that has no tests? How can you develop an open-source project with no tests? How do you ensure that the last commit didn’t break anything?

Install

Install Remarkable is very easy. It is stored in GitHub, so if you have never installed a gem via GitHub run the following:

gem sources -a http://gems.github.com

Then install the gem:

sudo gem install carlosbrando-remarkable

In RAILS_ROOT/config/environment.rb:

config.gem "carlosbrando-remarkable",  :lib => "remarkable", :source => "http://gems.github.com"

Using

All Remarkable macros can be accessed in two different ways. For those who prefer the Shoulda style, let’s look at some model tests:

describe Post do  fixtures :all

  should_belong_to :user  should_belong_to :owner  should_belong_to :user, :owner

  should_have_many :tags, :through => :taggings  should_have_many :through_tags, :through => :taggings  should_have_many :tags, :through_tags, :through => :taggings

  should_require_unique_attributes :title  should_require_attributes :body, :message => /wtf/  should_require_attributes :title  should_only_allow_numeric_values_for :user_idend

Like Shoulda, right? That’s the idea! This syntax is for those who wish to migrate their Shoulda tests to RSpec. You basically just have to change context to describe and wrap your should statements with it {}.

But if you don’t like this syntax, you can also create the same tests as follows:

describe Post do  fixtures :all

  it { should belong_to(:user) }  it { should belong_to(:owner) }  it { should belong_to(:user, :owner) }

  it { should have_many(:tags, :through => :taggings) }  it { should have_many(:through_tags, :through => :taggings) }  it { should have_many(:tags, :through_tags, :through => :taggings) }

  it { should require_unique_attributes(:title) }  it { should require_attributes(:body, :message => /wtf/) }  it { should require_attributes(:title) }  it { should only_allow_numeric_values_for(:user_id) }end

Now with an RSpec style!

Macros

Here are all the available macros:

For Shoulda style, click here.
For RSpec style, click here.

Finalizing

This project has already reached the first goal, which was to port all Shoulda macros to RSpec. This has been done with great care and attention to detail, and I have tried to write lots of tests. But there is no substitute for using it in real life and finding areas that could use improvement.

Please use Remarkable and help me to make it even better!

Shoulda para RSpec é Remarkable!

13 de novembro de 2008  |  Open Source  |  12 Comentários  | 

Durante um bom tempo andei evangelizando o uso do Shoulda na Surgeworks e fiz muito uso dele em meus projetos pessoais. O fato é que não obtive muito sucesso em evangelizar meus colegas de trabalho a adotarem o Shoulda, por outro lado eles conseguiram me convencer a aprender e usar RSpec.

E realmente RSpec é um framework de testes muito interessante. Mas tudo ficou ainda mais interessante quando comecei a brincar com o Cucumber (pretendo escrever sobre isto no futuro).

Mas o segredo do sucesso do Shoulda é a maneira em que ele transforma testes comuns como verificar se as associações estão funcionando, se todas as validações necessárias foram adicionadas ou se uma simples informação foi adicionada corretamente a sessão, em algo extremamente trivial.

Passei a gostar cada dia mais do RSpec e decidi adotá-lo como meu framework oficial de testes de agora em diante. Mas não posso mais viver sem as facilidades que o Shoulda me oferecia. Então resolvi coçar a minha própria coceira.

Remarkable

Inicialmente, a função do Remarkable é portar para RSpec todas as macros do Shoulda, mas obviamente o plano é muito mais ambicioso do que isto. Tenho muita coisa em mente que tornará este projeto especialmente útil para os usuários de RSpec.

Neste momento você talvez se pergunte: “Mas já não existem plugins que fazem a mesma coisa, como o skinny e o rspec-on-rails-matchers, por exemplo?”. Sou obrigado a responder: “Sim”. Então, por que mais um projeto?

Por que mais um projeto?

Em primeiro lugar este não é simplesmente “mais um” plugin com matchers para RSpec. Vou usar um clichê agora, mas é mais pura verdade: “Este é um projeto feito do jeito certo!”.

Vejamos então uma lista com o que torna o Remarkable único:

  1. Não é um plugin, e sim um gem.
  2. Porta todas as macros atuais do Shoulda para RSpec.
  3. Possui duas sintaxes de escrita, uma para quem gosta do estilo RSpec e outra para os que estão migrando seus projetos Shoulda para RSpec.
  4. Testes.
  5. Mais testes.
  6. E mais um pouco de testes.

Sim, diferente de todos os outros projetos com o mesmo objetivo, o Remarkable é o único que possui testes, e este é um grande diferencial, acredite! Como se pode confiar em um projeto que não tem testes? Como evoluir um projeto open-source que não possui testes? O que garante que o último commit não quebrou alguma coisa que estava funcionando?

Instalação

Instalar o Remarkable é muito fácil. Ele está armazenado no GitHub, então se você nunca instalou um gem via GitHub execute primeiro:

gem sources -a http://gems.github.com

Agora instale o gem:

sudo gem install carlosbrando-remarkable

Por último adicione a seguinte linha no seu arquivo RAILS_ROOT/config/environment.rb:

config.gem "carlosbrando-remarkable", :lib => "remarkable", :source => "http://gems.github.com"

Usando

Todas as macros do Remarkable podem ser acessadas de duas maneira diferentes. Para aqueles que preferem o estilo Shoulda, vejamos como ficaria o teste de um modelo:

describe Post do
  fixtures :all

  should_belong_to :user
  should_belong_to :owner
  should_belong_to :user, :owner

  should_have_many :tags, :through => :taggings
  should_have_many :through_tags, :through => :taggings
  should_have_many :tags, :through_tags, :through => :taggings

  should_require_unique_attributes :title
  should_require_attributes :body, :message => /wtf/
  should_require_attributes :title
  should_only_allow_numeric_values_for :user_id
end

Igualzinho ao Shoulda? É esta a idéia! Esta sintaxe é ideal para aqueles que desejarem migrar seus testes do Shoulda para o RSpec (tendo apenas de alterar de context para describe e de should para it) ou mesmo para os que adoram a jeitão do Shoulda, assim como eu.

Mas se você não gosta desta sintaxe, também pode criar os mesmos testes da seguinte forma:

describe Post do
  fixtures :all

  it { should belong_to(:user) }
  it { should belong_to(:owner) }
  it { should belong_to(:user, :owner) }

  it { should have_many(:tags, :through => :taggings) }
  it { should have_many(:through_tags, :through => :taggings) }
  it { should have_many(:tags, :through_tags, :through => :taggings) }

  it { should require_unique_attributes(:title) }
  it { should require_attributes(:body, :message => /wtf/) }
  it { should require_attributes(:title) }
  it { should only_allow_numeric_values_for(:user_id) }
end

Agora muito mais no estilo RSpec!

Macros

Veja uma relação com todas as macros disponíveis na documentação do projeto.

Para o estilo Shoulda, clique aqui.
Para o estilo RSpec, clique aqui.

Finalizando

Este projeto já atingiu o primeiro objetivo, que era portar todas as macros do Shoulda para o RSpec. Tudo feito da maneira correta, com todos os cuidados e muitos testes. Mas nada melhor do que o uso na prática para encontrarmos pontos que devem ser melhorados.

Enfim, usem o Remarkable, e ajudem a torná-lo ainda melhor!

Por que Paperclip?

12 de novembro de 2008  |  Open Source, Opinião  |  20 Comentários  | 

No último podcast mencionei minha escolha pelo Paperclip como meu plugin preferido para upload de arquivos. Depois disso algumas pessoas tem me perguntado porque usá-lo, já que o attachment_fu seria a opção mais conhecida.

Durante muito tempo usei o attachment_fu para esta função, mas em um projeto recente da Surgeworks optei por testar o Paperclip e depois disso acabei adotando-o como meu plugin padrão para uploads. Confesso que de inicio o grande motivo para experimentar o novo plugin foi por ele ter sido criado pela thoughtbot, o mesmo time que criou o Shoulda (que não estou usando mais, mas é uma outra história que vou explicar em um outro post), e como os caras são bons e tem criado inúmeros projetos interessantes, resolvi dar uma chance.

Mas foram alguns detalhes que me chamaram a atenção, como o fato de você não precisar de uma tabela extra no banco de dados para armazenar o caminho dos arquivos, a forma simplificada que ele oferece para se acessar e configurar o tamanho das fotos enviadas para o servidor, a macro de teste preparada para o Shoulda, a facilidade para configurar o acesso ao Amazon S3, entre outros detalhes que valorizam o plugin.

Enfim, não existe um grande motivo que chegue a desvalorizar o famoso attachment_fu ou torná-lo obsoleto. São apenas alguns pequenos detalhes que me conquistaram, só isso. É puramente uma questão de preferência  pessoal.

Não importa qual plugin de upload você use, só não esqueça do :multipart => true na construção do formulário!

Usando o Paperclip em 3 passos

1. Instale o plugin em seu projeto Rails:

./script/plugin install git://github.com/thoughtbot/paperclip.git

2. Adicione três colunas na tabela que armazenará os dados dos arquivos:

class AddAvatarColumnsToUser < ActiveRecord::Migration
  def self.up
    add_column :users, :avatar_file_name,    :string
    add_column :users, :avatar_content_type, :string
    add_column :users, :avatar_file_size,    :integer
    add_column :users, :avatar_updated_at,   :datetime
  end

  def self.down
    remove_column :users, :avatar_file_name
    remove_column :users, :avatar_content_type
    remove_column :users, :avatar_file_size
    remove_column :users, :avatar_updated_at
  end
end

3. Adicione uma linha no modelo com as configurações desejadas (tive de dividir em mais linhas para caber no blog):

class User < ActiveRecord::Base
  has_attached_file :avatar,
                    :styles => { :medium => "300x300>",
                                 :thumb => "100x100>" }
end

Leve ao forno e sirva à vontade!

No exemplo acima acabamos de adicionar um avatar (a famosa fotinha) para os usuários. Para recuperar a foto enviada pelo usuário, use:

<%= image_tag @user.avatar.url %>
<%= image_tag @user.avatar.url(:medium) %>
<%= image_tag @user.avatar.url(:thumb) %>

O attachment_fu também não é tão diferente disso, mas gosto mais do Papeclip. Apenas para fechar o artigo, um bônus! Para testar se o Paperclip está funcionando você pode pegar a macro para Shoulda, e depois adicionar uma linha ao teste do modelo:

class UserTest < Test::Unit::TestCase
  should_have_attached_file :avatar
end

Excelsior!