Organizando seus projetos Ruby com RVM

O RVM (Ruby Version Manager) é uma ótima ferramenta para gerenciar versões de ruby diferentes, mantendo todas as versões instaladas dentro do seu home, sem necessidade de uma conta de superusuário. Além de permitir instalar e usar várias versões, ele tem outros recursos interessantes que podem ser usados para manter organização entre projetos com gems diferentes. Vou explicar como eu costumo trabalhar, meu workflow básico e também algumas dicas de uso do RVM. Se você nunca ouviu falar nele, recomendo uma visita ao site do projeto.

Instalando

Para instalar o RVM é necessário o curl, git e bash (nunca testei em outros shell’s), e você também
vai precisar de ferramentas de desenvolvimento para compilar os rubis (gcc, make, etc). Depois de instalar as dependências, instale o RVM com o comando:

bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )

Depois de instalado, edite (ou crie) seu ~/.bashrc e adicione o seguinte ao fim dele:

if [[ -s ~/.rvm/scripts/rvm ]]
then
    source ~/.rvm/scripts/rvm
    source ~/.rvm/scripts/completion
    rvm reload
fi

Com isso o RVM será carregado e também será possível completar comandos do RVM usando o TAB. Agora regarregue seu bashrc:

source ~/.bashrc

Pronto, já podemos instalar nossos rubies, porém, antes de instalar qualquer coisa quero explicar o conceito de gemset do RVM. Gemsets permitem manter conjuntos de gems separados, dentro de uma mesma versão de Ruby. Quando você está usando um gemset, tem acesso apenas às gems instaladas nele, em um ambiente isolado. (isso é muito bom para evitar conflitos de versões de gems entre projetos diferentes). Sempre que uma versão do Ruby é instalada o RVM cria automaticamente dois gemsets, default e global. O gemset default é usado sempre que não for especificado qual gemset deseja-se utilizar. O gemset global é compartilhado entre todos os gemsets, ou seja, todas as gems instaladas no gemset global são visíveis nos outros gemsets da versão. Ao instalar uma versão de Ruby, o RVM verifica nos arquivos ~/.rvm/gemsets/global.gems e ~/.rvm/gemsets/default.gems quais gems devem ser instaladas nos respectivos gemsets, junto com o interpretador. Eu altero o arquivo ~/.rvm/gemsets/global.gems e adiciono as seguintes gems:

rake
bundler
pg
sqlite3-ruby
mysql
rspec

Assim, sempre que eu instalar um novo Ruby essas gems também serão instaladas automaticamente no gemset global, me poupando algum tempo . Se você não quiser fazer isso não precisa, é só um truque que eu uso para agilizar um pouco .

Agora podemos instalar nossos rubis. Para ver uma lista dos rubies que podem ser instalados, digite:

rvm list known

Instalar uma versão do Ruby é simples:

rvm install versao # ou versões separadas por vírgula

Eu instalo os seguintes:

rvm install 1.8.6,1.8.7,1.9.1,1.9.2,ree

O RVM vai baixar e compilar as versões selecionadas. Para usar alguma versão:

rvm use 1.9.1
# ou
rvm 1.9.1

Conferindo a versão do ruby:

ruby -v

Recomendo que vc escolha alguma versão como a default, eu deixo a 1.8.7 como default:

rvm 1.8.7 --default

Sempre que você abrir um novo shell a versão default já será usada. Se vc estiver usando outra versão e
quiser mudar para a versão default é só usar

rvm use default

Para ver qual é o ruby default:

rvm list default

Para listar todas versões instaladas:

rvm list

Para ver informações sobre uma versão (paths, variáveis de ambiente):

rvm info versao

Para remover totalmente uma versão:

rvm remove versao --gems --archive

Trabalhando com gemsets

Como dito anteriormente, gemsets permitem isolar gems dentro de uma mesma versão. Para criar um gemset:

rvm gemset create nome_gemset

Usando um gemset:

rvm gemset nome_gemset
# ou
rvm gemset versao@nome_gemset

Para criar um gemset e já usá-lo:

rvm --create use versao@nome_gemset

Todas as gems que você instalar quando estiver usando o gemset ficarão confinadas a ele.
Na listagem de gems aparecerão apenas as gems do gemset e as do gemset global.
Se vc quiser instalar uma nova gem ao gemset global, use:

rvm gemset use global
gem install nome_da_gem

Para ver qual gemset está sendo usado:

rvm gemset name

Listando todos os gemsets disponíveis para a versão:

rvm gemset list

Apagando um gemset e as gems contidas nele (–force serve para não pedir confirmação):

rvm --force gemset delete nome_gemset

Como manter gems separadas por projeto

Sempre que vc muda para um diretório (cd diretorio), o RVM verifica se existe um .rvmrc dentro dele.
Esse arquivo é um shell script que pode conter qualquer código necessário para inicializar o ambiente do projeto. Por exemplo, se vc quiser que um gemset xuxu seja carregado com a versão default sempre que você entrar no diretório do projeto, bastaria criar um .rvmrc com o conteúdo:

rvm default@xuxu

Com isso em mente, padronizei o setup dos meus projetos para:

mkdir nome_projeto
cd nome_projeto
rvm --create --rvmrc use default@nome_projeto

O último comando vai criar um gemset para o projeto, e também o .rvmrc para carregar o gemset correto.
Como eu também estou usando o bundler, eu crio um Gemfile, listando as dependências do projeto, (mesmo em projetos antigos, com Rails 1.2.6). Depois é só instalá-las com:

bundle install

Assim, tenho um ambiente de gems isolado para cada projeto, e o melhor, toda vez que eu mudar para o diretório de um projeto, o RVM já vai carregar o gemset correto com base no .rvmrc!

Rodando seus testes com RVM

Uma das coisas mais úteis do RVM é facilitar a execução testes em várias versões de Ruby diferentes. Por exemplo, para rodar sua suíte de testes em todas as versões de ruby instaladas:

# no caso de Rspec
rvm specs
# caso use Test::Unit
rvm tests

Também dá pra limitar a apenas algumas versões

rvm 1.8.6,1.8.7,1.9.1 specs

Se for necessário carregar um gemset específico para o projeto, pode ser feito da seguinte maneira

rvm 1.8.7@nome_gemset,1.9.1@nome_gemset specs

Finalizando

O RVM mudou muito meu jeito de trabalhar, essa é a forma que eu atualmente uso para manter meus projetos. Não quer dizer que é a melhor maneira, ou que você deve fazer da mesma forma. Esse post serve mais para dar uma idéia das possibilidades de uso do RVM, e servir como uma referência pra mim mesmo, pra consolidar meu workflow . Se alguém quiser compartilhar outras dicas para organização de projetos sinta-se livre!

Referências:

http://rvm.beginrescueend.com/
http://bcardarella.com/post/699582642/rvm-gemsets-bundler-awesome

Tornando dependências opcionais com autoload

Uma técnica bacana e que pouca gente conhece é usar o autoload para carregar classes. A função do autoload é a mesma do require (por baixo dos panos, o autoload usa o require), a diferença é que o autoload carregará o arquivo apenas quando for necessário. A idéia é que as constantes sejam registradas e associandas ao arquivo que deve ser requerido, por exemplo:

autoload :MinhaLib, 'minha_lib'

Note que o primeiro argumento é um símbolo, e não a classe. Com módulos é a mesma coisa:

module MeuModulo
  autoload :MinhaLib, 'meu_modulo/minha_lib'
end

Ou ainda:

module MeuModulo
  # coisas do meu modulo
end
MeuModulo.autoload :MinhaLib, 'meu_modulo/minha_lib'

Dessa forma, quando a constante MinhaLib (ou MeuModulo::MinhaLib, no caso do módulo) for usada, o arquivo ‘minha_lib‘ será carregado automaticamente. Qual a utilidade disso? Bem, se a constante não for usada, o arquivo não será carregado, o que nos trás duas vantagens:

• Como as classes desnecessárias não serão carregadas, a biblioteca será carregada mais rapidamente
• Conseguimos um mecanismo para tornar dependências opcionais

A primeira vantagem é óbvia, mas a segunda é meio implícita e depende de como o projeto está estruturado.
Por exemplo digamos que temos uma gem, que dependa da gem mail, mas apenas se o usuário desejar notificações. Se declararmos a mail como dependência na gemspec, quando alguém for instalar nossa gem, a mail será instalada mesmo que o usuário não precise dela.

O que podemos fazer para relaxar as dependências é usar o autoload para registrar a constante Mail,
e deixar a cargo do usuário instalar a dependência caso ele precise. Um exemplo de como seria o esqueleto da nossa gem:

# minha_gem.rb
autoload :Mail, 'mail'

# faz o que precisa ser feito

# a gem será carregada apenas se o usuário desejar notificações
# as notificações poderiam ser configuradas por um arquivo *.yml por exemplo
if user_wants_notification?
  Mail.new ...
end

Um exmplo de uso dessa técnica pode ser visto na gem backup, que antes especificava várias dependências na gemspec, e após uma pequena reestruturação, deixaram de ser obrigatórias. Veja aqui como foi feito. Outro exemplo de gem que usa essa técnica é a devise, vale a pena dar uma olhada no código .

Se você desenvolve alguma gem que usa adaptadores, e esses adaptadores dependem de outras gems, você encontrou um bom uso para o autoload, e vai deixar seus usuários mais felizes por não precisarem instalar o que não usarem .

Referências:

http://www.rubyinside.com/ruby-techniques-revealed-autoload-1652.html
http://ruby-doc.org/core/classes/Module.html

Migrando o Brazilian Rails para Ruby 1.9

Relato passo a passo das alteraçoẽs para migrar o Brazilian Rails:

Adicionados comentários de encoding. commit commit

: (dois pontos) não são mais válidos como separador de instruções. Deve-se trocar por ; ou then, ambas funcionam no 1.8 e 1.9. commit

ParseDate foi removido, Date#parse faz grande parte do que fazia o ParseDate. commit

O 1.9 introduziu o método Numeric#real, e estava sobrescrevendo um alias. commit

Variável $KCODE não tem mais efeito no 1.9, será setada apenas se a versão for anterior a 1.9. commit

A parte mais chata foi relacionada ao parser datas. O Date#parse no 1.9 se comporta de maneira diferente do 1.8, foram introduzidos outros formatos para parseamento, e o parse tenta converter a data com os novos formatos. Exemplo do novo comportamento:

# ruby 1.8.7
Date.parse("13/12/200A")
ArgumentError: invalid date
    from /usr/lib/ruby/1.8/date.rb:956:in `new_by_frags'
    from /usr/lib/ruby/1.8/date.rb:1000:in `parse'
    from (irb):7
    from /usr/lib/ruby/1.8/date.rb:811

# ruby 1.9.1
Date.parse("13/12/200A")
=> #<date: 0200-12-13>

Outra mudança foi que o formato padrão do parse passou a ser dd/mm/yyyy em vez de mm/dd/yyyy:

# ruby 1.8.7
Date.parse("10/12/2009")
=> Seg, 12 Out 2009

# ruby 1.9.1
Date.parse("10/12/2009")
=> Qui, 10 Dez 2009

Levando em conta essas mudanças, alterei o formado de algumas datas nesse teste. Esse outro teste, não está sendo executado no 1.9, justamente pelas diferenças do parse.

Sim, sei que essa solução está longe da ideal, mas para manter o mesmo comportamento seria necessário sobrescrever o parser do 1.9, e não gosto dessa solução… Para quem usa apenas datas no formato brasileiro, não vejo problemas, o Date#valid? continua funcionando (afinal, o propósito da brdata é trabalhar com datas no formato brasileiro ). O problema é se forem usadas datas em outros formatos, pois aí quem se encarrega de fazer a conversão é o parser do Ruby. Então, se você escolheu usar uby 1.9, esteja ciente das mudanças na classe Date.

Talvez no futuro seja interessante repensar a forma como o método Date#valid? é implementado, mas por hora, creio que deixar a cargo do usuário é razoável, já que é dele a decisão e sobre qual versão do Ruby usar. O suporte da brdata no 1.9 ainda é experimental, então se algém tiver idéias melhores, se pronuncie =).

Finalizando, destaco o papel dos testes na migração. Por sorte o Brazilian Rails tem uma boa cobertura, o que facilitou bastante. A cada alteração feita eu rodava os testes no 1.9 e no 1.8 para ver se estava tudo certo .

PS: para mudar a versão do Ruby eu uso o ruby_switcher. Também tem o rvm, mas acho o ruby_switcher mais simples.

Dica: adicionando comentários de codificação num projeto Rails

O Ruby 1.9 agora leva em consideração o encoding das strings nos arquivos, então caso algum arquivo ruby tenha algum caracter não ASCII (caracteres acentuados por exemplo), será exibido o erro:

invalid multibyte char (US-ASCII)

Para que o erro não ocorra, basta adicionar o comentário abaixo na primeira linha do arquivo *.rb:

# encoding: UTF-8

Ao migrar um projeto Rails para Ruby 1.9, esse erro acontecia em vários arquivos, então nada melhor que deixar o computador resolver o problema por você . O comando abaixo vai colocar esse comentário em todos os controllers, helpers e models do seu projeto Rails:

cd seu_projeto
find app/{controllers,models,helpers} -type f -name \*.rb | xargs sed -i '1i # encoding: UTF-8'

Para quem usa windows, pode usar o seguinte script Ruby para fazer o mesmo:

# utf_comment.rb
Dir["app/{controllers,models,helpers}/**/*.rb"].each do |filename|
  content = File.read(filename).sub(/^/, "# encoding: UTF-8\n")
  File.open(filename, "r+") { |f| f.write(content) }
end

Execute com

cd seu_projeto
ruby utf_comment.rb

Para mais informações sobre codificação de strings, aqui tem vários artigos abordando as mudanças. Recomendo a leitura!

Rails: Otimizando STI com default_scope

NOTA: se vc não faz idéia do que é STI, veja esse link.

Não dá pra negar que STI (Single Table Inheritance) é um recurso bacana do Rails. Claro que não é bom abusar, mas em alguns casos, ela se encaixa muito bem. No rails, quando queremos usar STI, basta ter uma coluna type do tipo string na tabela “mãe”, e nessa coluna o Rails se encarrega de gravar o nome da classe do registro, e a partir daí tudo funciona normalmente (para mais detalhes sobre como funciona STI no Rails, veja a api). Porém, apesar da implementação do Rails ser muito elegante e funcionar bem, ela tem alguns problemas:

• Comparações entre strings são lentas. Mesmo que haja um índice na coluna “type”, comparações entre strings ainda são bem mais lentas que comparações entre inteiros.
• Caso o model seja renomeado, os dados da coluna “type” terão que ser atualizados, ou ficaremos com dados incorretos na tabela. Para corrigir podemos criar uma migration, mas é mais uma coisa para se preocupar

Vamos tentar melhorar isso!

Criando um projetinho de exemplo (NOTA: estou usando Rails 2.3.3. Se usa uma versão mais antiga, veja algumas considerações mais abaixo):

rails sti
cd sti
script/generate model pessoa nome:string documento:string tipo:integer

Estamos criando nossa tabela base, e em vez de usar uma coluna type do tipo string, vamos usar uma coluna chamada tipo (o nome da coluna poderia ser qualquer um), do tipo inteiro.

Vamos editar nossa migração e adicionar um índice na migration para melhorar a performance nas buscas:

class CreatePessoas < ActiveRecord::Migration
  def self.up
    create_table :pessoas do |t|
      t.string :nome
      t.string :documento
      t.integer :tipo
      t.timestamps
    end

    #adicionando o indice
    add_index :pessoas, [:id, :tipo]
  end

  def self.down
    drop_table :pessoas
  end
end

Criando o banco e nossa tabela de testes:

rake db:create
rake db:migrate

Alterando o model Pessoa para adicionar algumas constantes com os tipos de pessoas:

#app/models/pessoa.rb
class Pessoa < ActiveRecord::Base
  # tipos de pessoa
  JURIDICA = 1
  FISICA   = 2
end

Agora, vamos criar dois models que herdam de Pessoa, PessoaFisica e PessoaJuridica, e definir os seus default_scopes:

#app/models/pessoa_fisica.rb
class PessoaFisica < Pessoa
  default_scope :conditions => {:tipo => FISICA}
end

#app/models/pessoa_juridica.rb
class PessoaJuridica < Pessoa
  default_scope :conditions => {:tipo => JURIDICA}
end

Só isso? Só . Aparentemente, o Rails está bem espertinho, e quando instânciamos um objeto ele já se encarrega de colocar o valor correto na coluna tipo, da mesma forma que STI faz:

Pessoa.new
#<Pessoa id: nil, nome: nil, documento: nil, tipo: nil>
PessoaJuridica.new
#<PessoaJuridica id: nil, nome: nil, documento: nil, tipo: 1>
PessoaFisica.new
#<PessoaFisica id: nil, nome: nil, documento: nil, tipo: 2>

Criando algumas pessoas:

Pessoa.create(:nome => "Pessoa indefinida")
PessoaFisica.create(:nome => "João da Silva", :documento => "123.456.789-10")
PessoaFisica.create(:nome => "José Oliveira", :documento => "000.111.222-33")
PessoaJuridica.create(:nome => "Padaria pão quentinho", :documento => "26.721.163/0001-52")
PessoaJuridica.create(:nome => "Transportadora Leva e Traz", :documento => "70.562.197/0001-31")

Buscando:

>> Pessoa.all
# SELECT * FROM "pessoas"
=> [#<Pessoa id: 1, nome: "Pessoa indefinida", documento: nil, tipo: nil, created_at: "2009-08-12 01:08:29", updated_at: "2009-08-12 01:08:29">, #<Pessoa id: 2, nome: "João da Silva", documento: "123.456.789-10", tipo: 2, created_at: "2009-08-12 01:08:29", updated_at: "2009-08-12 01:08:29">, #<Pessoa id: 3, nome: "José Oliveira", documento: "000.111.222-33", tipo: 2, created_at: "2009-08-12 01:08:29", updated_at: "2009-08-12 01:08:29">, #<Pessoa id: 4, nome: "Padaria pão quentinho", documento: "26.721.163/0001-52", tipo: 1, created_at: "2009-08-12 01:08:29", updated_at: "2009-08-12 01:08:29">, #<Pessoa id: 5, nome: "Transportadora Leva e Traz", documento: "70.562.197/0001-31", tipo: 1, created_at: "2009-08-12 01:08:29", updated_at: "2009-08-12 01:08:29">]

>> PessoaJuridica.all
# SELECT * FROM "pessoas" WHERE ("pessoas"."tipo" = 1)
=> [#<PessoaJuridica id: 4, nome: "Padaria pão quentinho", documento: "26.721.163/0001-52", tipo: 1, created_at: "2009-08-12 01:08:29", updated_at: "2009-08-12 01:08:29">, #<PessoaJuridica id: 5, nome: "Transportadora Leva e Traz", documento: "70.562.197/0001-31", tipo: 1, created_at: "2009-08-12 01:08:29", updated_at: "2009-08-12 01:08:29">]

>> PessoaFisica.all
# SELECT * FROM "pessoas" WHERE ("pessoas"."tipo" = 2)
=> [#<PessoaFisica id: 2, nome: "João da Silva", documento: "123.456.789-10", tipo: 2, created_at: "2009-08-12 01:08:29", updated_at: "2009-08-12 01:08:29">, #<PessoaFisica id: 3, nome: "José Oliveira", documento: "000.111.222-33", tipo: 2, created_at: "2009-08-12 01:08:29", updated_at: "2009-08-12 01:08:29">]

Para quem ainda usa uma versão do Rails menor que 2.3 e maior que 2.0, uma solução é instalar o plugin com o backport do default_scope:

script/plugin install git://github.com/duncanbeevers/default_scope.git

Além disso, será necessário usar uma callback para setar a coluna tipo com o valor correto. Por exemplo:

class PessoaFisica < Pessoa
  default_scope :conditions => {:tipo => FISICA}
  before_save { |p| p.tipo = FISICA }
end

Para quem usa uma versão do mais antiga que a 2, já passou da hora de atualizar hem .

Finalizando

Conseguimos o mesmo comportamento da STI, sem as desvantagens citadas anteriormente, usando apenas algumas linhas de código a mais (os default_scopes e as constantes que definimos, no total 4 linhas). Espero que essa dica seja útil, e lembre-se, aprecie STI com moderação .

Deslocalizando datas e números usando o i18n do Rails

NOTA: Antes de começar, se você não sabe o que é ou não tem uma noção básica sobre o i18n do Rails, leia esse guia.

Fazer conversões de datas e números localizados sempre foi uma tarefa chata em Rails (e em outras linguagens/frameworks também). O usuário digita uma data no formato brasileiro (por exemplo, dd/mm/yyyy), e o Ruby não consegue converter a data corretamente. A maneira mais usada por aí é criar atributos virtuais (ou mesmo sobrecrever o setter padrão do atributo) no model para fazer a conversão, por exemplo:

class Model < ActiveRecord::Base

  #recebe uma data no formato dd/mm/yyyy e converte para yyyy-mm-dd
  def data_vencimento=value
    self[:data_vencimento] = value.split("/").reverse.join("-")
  end

end

Isso funciona, mas quando eu usava isso não ficava satisfeito, queria algo mais “mágico” . Perguntei no fórum RubyOnBr se não teria um jeito de fazer a conversão automaticamente, usando o próprio i18n do Rails. Então meu camarada Rafael Rosa chegou a uma solução, usando o formato padrão de data configurado no aquivo de i18n para fazer o parsing de datas. Eu acrescentei suporte à números, o Rafael organizou tudo, escreveu testes, e surgiu o i18n_localize_core.
O plugin funciona bem, consegue converter datas e números usando as configurações do arquivo de internacionalização. O plugin resolvia bem para mim, inclusive tinha feito alguns hacks no plugin para fazer a conversão nos text_fields, mas não coloquei no meu fork porque estava muito feio .
Só que a um tempo atrás, encontrei o plugin delocalize, escrito por Clemens Kofler, que faz basicamente a mesma coisa, mas melhor . O i18n_localize_core é meio invasivo, sobrescreve os métodos Date#_parse, String#to_i e String#to_f. No delocalize, o Clemens sobrescreveu apenas onde era necessário, e ainda adicionou suporte à entrada de vários formatos de datas.
Usar o plugin é simples, como tudo na vida deve ser . Tendo configurado seu arquivo de i18n e instalado o plugin, basta adicionar a chave :input no arquivo de i18n com os formatos de data que o usuário poderá digitar e sair pro abraço . O plugin se encarrega de fazer o resto de forma transparente.

No README do plugin tem alguns exemplos de uso, dêem uma conferida no projeto:

http://github.com/clemens/delocalize

Tradução: Delegação em Ruby

Hoje li um artigo interessante na primeira edição da Rails Magazine sobre delegação de métodos em Ruby, escrito por Khaled al Habache. Além da delegação, ele também aborda um tema antigo (e que gera muita discussão por aí) em se tratando de POO, Herança X Composição. Como não achei material sobre delegação em português, resolvi traduzir o artigo. Espero que gostem .

Delegação em Ruby

“Separar partes mutáveis das partes que não mudam” e “composição é preferível a herança” são dois princípios de projeto comuns quando você inicia no mundo da Programação Orientada à Objetos. Entretanto, enquanto o primeiro parece lógico, alguém pode pensar porque é preferível usar composição em vez de herança, e é uma questão lógica, então vamos respondê-la com um exemplo.

Vamos supor que temos um robô que possui um sensor de temperatura, representado pelo seguinte diagrama UML:

Classe Robô

Esse projeto tem alguns inconvenientes:

1. Existe grande probabilidade de existir outros tipos de robôs que não possuem sensores de calor (quebra o primeiro princípio de projeto: separar código mutável do estático)
2. Sempre que eu desejar alterar qualquer coisa relacionada ao sensor de temperatura, terei que alterar a classe Robô (quebra o primeiro princípio de projeto).
3. Exposição dos métodos do sensor de temperatura na classe Robô.

Vamos melhorar essa classe um pouco:

Classe Robô Vulcão

Bem, agora esse é um projeto baseado em herança que resolve o primeiro problema, mas ainda é incapaz de resolver os outros dois problemas relacionados ao sensor de calor. Vamos melhorar um pouco mais:

Delegação

Esse é um típico modelo, baseado em composição em vez de herança. Com ele podemos resolver todos os 3 problemas, e ainda por cima ganhamos uma nova classe: agora podemos abstrair o SensorDeTemperatura para usos futuros.

O que é delegação?

Delegação é o processo de delegar funcionalidade às partes contidas.

Se você olhar cuidadosamente à figura anterior, você notará que o RoboVulcao ainda possui 3 métodos relacionados ao sensor; esses são métodos que apenas chamam os métodos correspondentes do sensor. Isso é exatamente o que delegação é, apenas repassar funcionalidade às partes contidas.

Delegação vem junto com composição para oferecer soluções flexíveis e elegantes como essa que vimos anteriormente, e também respeita o princípio “separar código mutável de código estático”, mas também cobra um preço por isso: a necessidade de métodos que “embrulhem” as chamadas impõem um tempo extra de processamento por causa das chamadas a esses métodos.

Ruby e delegação

Agora vamos ver um exemplo de código:

Temos um robô de propósito geral que possui um Braço e um SensorDeCalor. O robô é capaz de executar várias tarefas, como empacotar caixas, empilhá-las e medir a temperatura.

Usaremos composição e delegação assim:

class Robô

  def initialize
    @sensor_temperatura = SensorDeTemperatura.new
    @braco = BracoDoRobo.new
  end

  def medir_temperatura(escala="c")
    @sensor_temperatura.measure(escala)
  end

  def empilhar(quantidade_de_caixas=1)
    @braco.empilhar(quantidade_de_caixas)
  end

  def empacotar
    @braco.empacotar
  end

end

class SensorDeTemperatura

  # Escala Celsius ou Fahrenheit
  def medir(escala="c")
    t = rand(100)
    t = escala=="c" ? t : t * (9/5)
    puts "A temperatura é #{t}° #{escala.upcase}"
  end

end

class BracoDoRobo

  def empilhar(quantidade_de_caixas=1)
    puts "Empilhando #{quantidade_de_caixas} caixa(s)"
  end

  def empacotar
    puts "Empacotando"
  end

end

robo = Robo.new #=>#<Robo:0xb75131e8 @arm=#<BracoDoRobo:0xb75131ac>, @sensor_temperatura=#<SensorDeTemperatura:0xb75131c0>>
robo.empilhar 2 #=>Empilhando 2 caixa(s)
robo.empacotar #=>Empacotando
robo.medir_temperatura #=> A temperatura é 59° C

Como pode ser visto, temos 3 métodos que “encapsulam” chamadas (empilhar, empacotar e medir_temperatura) na classe Robo que não fazem nada a não ser chamar o método correspondente dos componentes (BracoDoRobo e SensorDeTemperatura).

Isso é uma coisa péssima, especialmente quando existem vários objetos contidos no objeto principal.

Entretanto, em Ruby temos duas bibliotecas para nos salvar: Forwardable e Delegate, Vamos ver cada uma delas.

Biblioteca Forwardable

A biblioteca Forwardable possui dois módulos, Forwardable e SingleForwardable.

Módulo Forwardable

O módulo Forwardable oferece delegação dos métodos especificados para um objeto designado, usando os métodos def_delegator e def_delegators.

def_delegator(obj, method, alias = method): Define um método “method” que delega a chamada ao objeto “obj”. Se o alias for fornecido, será usado como o nome do método de delegação.

def_delegators(obj, *methods): Atalho para definir múltiplos métodos delegadores, mas sem permitir o uso de um nome diferente.

Vamos refatorar nosso exemplo de robô para utilizar o módulo Forwardable:

require 'forwardable'

class Robo

  # Extend fornece métodos de classe
  extend Forwardable

  # Uso do  def_delegators
  def_delegators :@braco, :empacotar, :empilhar

  # Uso do  def_delegator
  def_delegator :@sensor_temperatura, :measure, :medir_temperatura

  def initialize
    @sensor_temperatura = SensorDeTemperatura.new
    @braco = BracoDoRobo.new
  end

end

class SensorDeTemperatura

  # Escala Celsius ou Fahrenheit
  def medir(escala="c")
    t = rand(100)
    t = escala=="c" ? t : t * (9/5)
    puts "A temperatura é #{t}° #{escala.upcase}"
  end

end

class BracoDoRobo

  def empilhar(quantidade_de_caixas=1)
    puts "Empilhando #{quantidade_de_caixas} caixa(s)"
  end

  def empacotar
    puts "Empacotando"
  end

end

Como pode ser visto, é uma solução mais limpa e consisa.

Módulo SingleForwardable

O módulo SingleForwardable oferece delegação dos métodos especificados para um objeto designado, utilizando os métodos def_delegator e def_delegators. Esse módulo é similar ao Forwardable, mas trabalha com os próprios objetos, em vez de suas classes que os definem.

require "forwardable"
require "date"

date = Date.today #=> #<Date: 4909665/2,0,2299161>
# Prepara o objeto para delegação
date.extend SingleForwardable #=> #<Date: 4909665/2,0,2299161>
# Adiciona delegação para Time.now
date.def_delegator :Time, "now","with_time"
puts date.with_time #=>Thu Jan 01 23:03:04 +0200 2009

Biblioteca Delegate

Delegate é outra biblioteca que oferece delegação, irei explicar duas formas de usá-la.

Método DelegateClass

Utiliza o método de nível superior DelegateClass, que permite inicializar a delegação por meio de herança. No exemplo seguinte, quero criar uma nova classe chamada CurrentDate, que armazene a data corrente e alguns métodos extras, ao mesmo em que delego a objetos data normais:

require "delegate"
require "date"

# Note a definição da classe
class CurrentDate < DelegateClass(Date)

  def initialize
    @date = Date.today
    # Passa o objeto a ser delegado à superclasse
    super(@date)
  end

  def to_s
    @date.strftime "%Y/%m/%d"
  end

  def with_time
    Time.now
  end

end

cdate = CurrentDate.new
# Note como funciona a delegação
# Em vez de usar cdate.date.day e definir um
# attr_accessor para date, eu uso c.day
puts cdate.day #=>1
puts cdate.month #=>1
puts cdate.year #=>2009
# Testando métodos adicionados
# to_s
puts cdate #=> 2009/01/01
puts cdate.with_time #=> Thu Jan 01 23:22:20 +0200 2009

Classe SimpleDelegator

Use-a para delegar para um objeto que mode ser modificado:

require "delegate"
require "date"

today = Date.today #=> #<Date: 4909665/2,0,2299161>
yesterday = today - 1 #=> #<Date: 4909663/2,0,2299161>
date = SimpleDelegator.new(today) #=> #<Date: 4909665/2,0,2299161>
puts date #=>2009-01-01
# Usa __setobj__ para trocar a delegação
date.__setobj__(yesterday)#=> #<Date: 4909663/2,0,2299161>
puts date #=>2008-12-31

Como pode ser visto, criamos dois objetos e delegamos a eles.

E o Rails?

Rails adiciona uma nova funcionalidade chamada “delegate”, que fornece um método de classe para expor facilmente os metodos dos objetos contidos como se fossem métodos próprios. Passe um ou mais métodos (especificados como símbolos ou strings) e como último parâmetro o nome do objeto alvo na opção :to (também como símbolo ou string). Pelo menos um método e a opção :to são exigidos.

Vá para o console, crie um novo projeto e inicie um console do rails:

$ rails dummy
$ cd dummy
$ruby script/console
Loading development environment (Rails 2.2.2)
>> Person = Struct.new(:name, :address)
=> Person
>> class Invoice < Struct.new(:client)
>>   delegate :name, :address, :to => :client
>> end
=> [:name, :address]
>> john_doe = Person.new("John Doe", "Vimmersvej 13")
=> #<struct Person name="John Doe", address="Vimmersvej 13">
>> invoice = Invoice.new(john_doe)
=> #<struct Invoice client=#<struct Person name="John Doe", address="Vimmersvej 13">>
>> invoice.name
=> John Doe
>> invoice.address
=>Vimmersvej 13

Recomendo fortemente que você verifique todos os exemplos na documentação da API do Rails, para ver como usar esse recurso efetivamente com o ActiveRecord.

Antes de terminar esse artigo, quero compartilhar com você o código do método delegate do Rails. Adicionarei alguns comentários para explicar o que está acontecendo:

class Module

  # método delegate
  # Espera um array de argumentos contendo os métodos
  # a serem delegados e um hash de opções
  def delegate(*methods)
    # Desempilha o hash de opções
    options = methods.pop
    # Verifica se o hash de opções foi passado, e se contém a opção :to
    # Lança uma exceção se um dos dois não forem encontrados
    unless options.is_a?(Hash) && to = options[:to]
      raise ArgumentError, "Delegation needs a target. Supply an options hash with a :to key as the last argument (e.g. delegate :hello, :to => :greeter)."
    end

    # Certifica-se de que a opção :to segue algumas
    # regras de sintaxe para nomes de métodos
    if options[:prefix] == true && options[:to].to_s =~ /^[^a-z_]/
      raise ArgumentError, "Can only automatically set the delegation prefix when delegating to a method."
    end

    # Atribui o verdadeiro valor do prefixo
    prefix = options[:prefix] && "#{options[:prefix] == true ? to : options[:prefix]}_"

   # Aqui vem a mágica do Ruby :)
   # Técnicas de reflexão são usadas aqui:
   # module_eval é usado para adicionar novos métodos em tempo de execução, onde:
   # expõe os métodos dos objetos contidos
    methods.each do |method|
      module_eval("def #{prefix}#{method}(*args, &block)\n#{to}.__send__(#{method.inspect}, *args, &block)\nend\n", "(__DELEGATION__)", 1)
    end

  end

end

Isso é tudo para esse artigo, foram cobertos 5 pontos:

1. Composição versus Herança.
2. O que é delegação, e porque ela é usada.
3. Biblioteca Forwardable.
4. Biblioteca Delegate.
5. Método delegate do Rails.

acts_as_active: mais um plugin no estilo acts_as_paranoid

Pra quem é do mundo Rails, o acts_as_paranoid já é velho conhecido, ele sobrescreve alguns métodos do ActiveRecord para marcar um registro como excluído em vez de efetivamente excluí-lo. Ele também adiciona um escopo para esconder os registros “exluídos” dos finders e outras operações comuns como count, sum, max, etc. Meu novo plugin, acts_as_active, faz basicamente a mesma coisa, porém utiliza um booleano em vez de um timestamp para indicar que o registro está ativo e utiliza um escopo padrão para mostrar apenas os ativos.

Instalando o acts_as_active

Pra instalar, o de sempre:

script/plugin install git://github.com/fernandoluizao/acts_as_active.git

IMPORTANTE: Meu plugin depende de um novo recurso adicionado no Rails 2.3 chamado default_scope
Para quem usa Rails 2.1 ou 2.2, instale o plugin default_scope.

script/plugin install git://github.com/duncanbeevers/default_scope.git

Uso

O plugin assume que vc tem um campo booleano com o nome “active”, com valor default TRUE. Exemplo de uso:

  create_table :users do |t|
    t.string :name
    t.string :last_name
    t.boolean :active, :null => false, :default => true
  end

  class User < ActiveRecord::Base
    acts_as_active
  end

  User.first.destroy
  UPDATE users SET active = 'f' WHERE id = 1

  #chama o destroy original e acaba com nosso usuário
  User.first.destroy! 
  DELETE FROM users WHERE id = 1

  User.all
  SELECT * FROM users WHERE active = 't'

  User.all :conditions => {:name => "joe"}
  SELECT * FROM users WHERE (name = 'joe') AND (active = 't')

Se quiser procurar incluindo os inativos:

  User.find_with_inactive :conditions => {:name => "joe"}
  SELECT * FROM users WHERE (name = 'joe')

O nome do campo booleano pode ser configurado da seguinte forma:

class User < ActiveRecord::Base
  acts_as_active :with => :nome_campo
end

É isso, um plugin simples, mas que me poupa um bom trabalho. Espero que gostem .

Dica: define_method com parâmetros opcionais

Quando estamos definindo um método com define_method, passamos os parâmetros nas variáveis do bloco, por exemplo:

class Teste
  define_method "meu_metodo" do |foo, bar|
    puts "foo: #{foo}, bar: #{bar}"
  end
end

t = Teste.new
t.meu_metodo "param1", "param2"
#foo: param1, bar: param2

Porém, se tentarmos definir um parâmetro opcional (com valor default), da forma que estamos acostumados, temos um erro de sintaxe:

define_method "meu_metodo" do |foo, bar, options = {}|
#syntax error, unexpected tSTRING_BEG, expecting kDO or '{' or '('

Para contornar isso, podemos utilizar o splat (*), para colocar os parâmetros opcionais em um array:

class Teste
  define_method "meu_metodo" do |foo, bar, *options|
    #se o parametro opcional não for passado, inicializamos com um hash vazio
    options = options.first || {} 
    puts "foo: #{foo}, bar: #{bar}"
    puts options.inspect
  end
end

t = Teste.new
t.meu_metodo "param1", "param2", :foo => "foo", :bar => "bar"
#foo: param1, bar: param2
#{:bar=>"bar", :foo=>"foo"}
t.meu_metodo "primeiro", "segundo" 
#foo: primeiro, bar: segundo
#{}

Dessa forma podemos passar quantos parâmetros opcionais quisermos .

Insensitivity: O plugin insensível

Consultas case insensitive e independentes de acentos que funcionem em qualquer SGBD são difíceis de conseguir, pois cada banco possui sua maneira específica de fazer isso. Se forem tomados alguns cuidados, é possível usar a sintaxe correta de acordo com o adaptador que estamos usando. No PostgreSQL por exemplo, para conseguir uma consulta case insensitive e independente de acentos, temos que fazer coisas assim ou assim.

O problema em usar conversões nas colunas é que, além delas não fazerem parte padrão SQL, perdemos os índices na coluna, o que vai fazer nossa consulta demorar um pouco mais (dependendo da quatidade de registros, usar ou não um índice pode fazer uma grande diferença). Para resolver esse problema, criei o plugin “Insensitivity“, que usa uma coluna extra para armazenar o valor sem acentos e em minúsculas. Assim, durante as consultas, o ActiveRecord irá utilizar essa coluna em vez da coluna com o valor real.

Vantagens dessa abordagem

Independente de banco
Se hover índices, serão usados

Desvantagens

Utiliza o dobro de espaço.

Instalando e usando o plugin

script/plugin install git://github.com/fernandoluizao/insensitivity.git

No seu model, você deve indicar quais campos usarão a pesquisa case insensitive:

class User < ActiveRecord:Base
  insensible :name, :email
end

Depois, você DEVE adicionar à tabela, os campos com o mesmo nome dos que foram indicados e com o sufixo “_search”. Se desejar, também coloque índices para melhorar a performance. Por exemplo:

script/generate migration add_search_fields

def self.up
  change_table :users do |t|
    t.string :name_search
    t.string :email_search
  end

  add_index :users, :name_search
  add_index :users, :email_search

  #Se sua tabela ja tiver dados, vc pode usar
  #User.make_insensible!
  #Isso vai inicializar os novos campos nos registros já existentes
end

def self.down
  change_table :users do |t|
    t.remove :name_search
    t.remove :email_search
  end
end

Para fazer as buscas, não muda nada. Veja as consultas geradas:

User.find_by_name('bla')
SELECT * FROM users WHERE name_search = 'bla'

User.find(:first, :conditions => ['name = ?', 'bla'], :order => 'name')
SELECT * FROM users WHERE name_search = 'bla' ORDER BY name LIMIT 1

Tudo funciona de forma transparente, sem vc precisar se preocupar =). Sua única preocupação deve ser passar o valor nas conditions sem acentos e em minusculas, para isso pode usar o método “insensible”, adicionado à classe String:

User.find(:first, :conditions => ['name LIKE ?', "%#{params[:name].insensible}%"])
SELECT * FROM users WHERE name_search LIKE '%bla%'

Bom, é isso, pesquisa sem sentimentos . Quem quiser colaborar:

http://github.com/fernandoluizao/insensitivity/

PS: Testei apenas com rails 2.2.2. Pode não funcionar com versões mais antigas (< 2.0)