Fernando Luizão

Desenvolvimento de software e nerdices em geral

Archive for the ‘Ruby’ Category

Organizando seus projetos Ruby com RVM

with 19 comments

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

Advertisements

Written by fernandoluizao

August 26, 2010 at 12:34 am

Posted in Ruby, Shell Script

Tagged with , ,

Tornando dependências opcionais com autoload

with 2 comments

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

Written by fernandoluizao

May 11, 2010 at 10:11 pm

Posted in Gems, Plugins, Ruby

Tagged with , , ,

Migrando o Brazilian Rails para Ruby 1.9

leave a comment »

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.

Written by fernandoluizao

September 12, 2009 at 1:13 pm

Posted in Plugins, Rails, Ruby

Tagged with , ,

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

with 5 comments

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!

Written by fernandoluizao

August 28, 2009 at 11:55 pm

Posted in Rails, Ruby

Tagged with , , , ,

Tradução: Delegação em Ruby

with 4 comments

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:

Robô

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

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

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.

Written by fernandoluizao

March 31, 2009 at 1:48 am

acts_as_active: mais um plugin no estilo acts_as_paranoid

leave a comment »

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 :).

Written by fernandoluizao

March 6, 2009 at 12:51 am

Dica: define_method com parâmetros opcionais

leave a comment »

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 :).

Written by fernandoluizao

February 11, 2009 at 9:26 pm

Posted in Ruby