Bom dia! Estou participando do RailsSummit, o maior evento de RoR da America Latina. A Infra estrutura está ótima e a palestra do Chad Fowler foi bem inspiradora. Acompanhe tudo o que está acontecendo através do meu twitter: @rafaelmanoel

[]‘s
Rafael

Ok, sempre vi por aí que o pessoal recomenda fortemente a utilização de factories de objetos ao invés de fixtures, porém as fixtures sempre serviram pra mim. Pelo menos até hoje.

O Problema comecou quando eu tive que sair da convenção do Rails. Tenho uma classe, digamos Customer, por exemplo, que possui dois Addresses:

class Customer < ActiveRecord::Base

has_one :business_address, :class_name => 'Address'
has_one :home_address, :class_name => 'Address'

end

Para os meus testes, criei os arquivos de fixtures

# addresses.yml

endereco_1:
street: Endereco 1

endereco_2:
street: Segundo Endereco

# customers.yml
rafael:
name: Rafael
business_address: endereco_1
home_address: endereco_2

Com as novas sexy fixtures, acreditei que isso seria possível. Porém, as fixtures, por natureza, refletem o que está no banco de dados, e nao nos objetos. Não importa que a minha classe Customer tenha atributos business_address e home_address mapeando para a classe Address, o sistema de fixtures não irá conseguir vincular o meu endereco_1 e endereco_2 com o customer rafael. Eu teria que criar uma fixture da seguinte forma:

# customers.yml
rafael:
name: Rafael
business_address_id: 1
home_address_id: 2

E com isso, perder toda a legibilidade. Imagina a bagunça que ficaria se todas as associações do meu modelo fossem com os ids. Quem conseguiria entender além do computador ?

Foi por isso que decidi utilizar o factory_girls. Com ele é possível fazer este tipo de associação sem ter que ficar fazendo macumba gambiarra workarounds. Após a instalação da gem, e configuração (que pode ser vista aqui), basta criar um factories.rb da seguinte forma:

Factory.define :endereco_1, :class => Address do |a|
a.street "Endereco 1"
end

Factory.define :endereco_2, :class => Address do |a|
a.street "Endereco 2"
end

Factory.define :rafael, :class => Customer do |c|
c.association :business_address, :factory => endereco_1
c.association :home_address, :factory => endereco_2
end

E no seu teste:

rafael = Factory(:rafael)

Simples, não ? E bem melhor…

Quem nunca se confundiu com isso, que atire a primeira pedra =p. Realmente, e pra quem está começando com Ruby, isso gera ainda mais confusão. Por isso, estou postando um artigo bem interessante que acabei de ler. Segue o link:

http://www.neeraj.name/blog/articles/589-block-vs-lambda-vs-proc

[]‘s

Rafael

Aqui vai uma dica que vi no excelente blog rubyinside:

Há um projeto no github, chamado whenever, que encapsula chamadas ao cron, utilizando a sitaxe e o jeitão do Ruby.  É possível fazer agendar tarefas no cron desta forma:

  every 3.hours do
    runner "MyModel.some_process"
    rake "my:rake:task"
    command "/usr/bin/my_great_command"
  end

  every 1.day, :at => '4:30 am' do
    runner "MyModel.task_to_run_at_four_thirty_in_the_morning"
  end

  every :hour do # Many shortcuts available: :hour, :day, :month, :year, :reboot
    runner "SomeModel.ladeeda"
  end

  every :sunday, :at => '12pm' do # Use any day of the week or :weekend, :weekday
    runner "Task.do_something_great"
  end

Para saber mais, visite o site do projeto, ou assista a este video.

Fonte: http://www.rubyinside.com.br/whenever-uma-dsl-ruby-para-programar-tarefas-no-cron-1514

Veja como é simples invocar um session bean através de um cliente JRuby.

Obs: Não esqueça do jndi.properties e de adicionar, ao classpath (tem que ser via variável CLASSPATH), o seu jbossall-client.jar (caso seu servidor seja jboss =p) e o jar que contém as interfaces dos seu SessionBean.

#!/usr/bin/env jruby

require 'java'
include_class 'javax.naming.InitialContext'

ic = InitialContext.new
sb_home = ic.lookup("MySessionBean")
sb_remote = sb_home.create

value = sb_remote.sayHi
puts "Valor = #{value}"

Pois é, juro que com isso é possível invocar o EJB.

Isso abre várias portas, não ?

Pois é, hoje começou a Rails Summit, e eu estou doido para saber tudo o que está rolando lá, mas infelizmente só poderei ir amanhã. Obviamente perderei a palestra do DHH, e algumas outras que eu realmente queria ver, mas amanha o dia também tá cheio de coisas boas…

Obviamente, após a conferência, compilarei o que achar de mais interessante e postarei aqui no blog.