Bom, como ando um pouco enferrujado em BDD – e em Java – busquei um bom material para seguir e encontrei esse post do Marcus Cavalcanti. Lá ele cita um tradução do JBehaver para português feita pelo Emerson. Para compilar o jbehave-br é preciso o buildr, uma ferramenta de build que não conhecia e achei bem interessante. Mas aí veio o problema. Após atualizar meu RubyGems para a versão 1.3.6  e instalar buildr, ele não funcinou.

Google vai, google vem e eis que encontro a resposta: instalar a versão Release Candidate do builder 1.4.0. Para isso, vá no site http://people.apache.org/~toulmean/buildr/1.4.0/dist/ baixe e instale manualmete a gem do buildr. Para instalação manual de qualquer gem, basta digitar

sudo gem install caminho_fisico.gem

Após, execute

buildr

Que tudo deve correr bem.

No mais, abraços

Até mais

Logo após a palestra trocamos uma idéia sobre Ruby e Rails no lounge do Software Livre para um público curioso. Sorteamos descontos para o curso de Webdeveloper+Ruby oferecido pela IT Informática, e para aquisição do novo livro do Urubatan. Entregamos 3 pendrives recheados de material sobre Ruby On Rails para aqueles que se deram bem nos desafios de Ruby que lançamos (parabéns para o pessoal do Python! ).

O Elomar também postou sobre o evento e disponibilizou algumas fotos, deem uma olhada.

Gostaria de agradecer a tink!, sempre nos apoiando, a IT Informática por mais uma parceria, ao pessoal da NOVATEC pelo desconto no livro e ao pessoal do PSL-RN pelo convite. Agradeço também, claro, ao Tapajós, Brando, Paulo Vanderley, Urubatan e o Akita pela força na divulgação. Valeu mesmo pela ajuda.

Fiquem atentos nas próximas atuações do ruby+web pelo site http://rubymaisweb.ning.com/. Semana que vem estaremos no FISL e no dia 01 de maio ocorrerá nosso 2o. Encontro, lá no IFRN.

Abraços e bons códigos

A ideia é simples. Ao criar um novo projeto, indicamos o caminho para o template com a opcão -m ao comando rails.

rails minha_app -m /caminho/para/o/template.rb

Se for um projeto já existente, existe uma rake para aplicar o template.

rake rails:template LOCATION=/caminho/para/o/template.rb

Na página do autor existe um exemplo de um template bem simples:

run "rm public/index.html"
generate(:scaffold, "person name:string")
route "map.root :controller => 'people'"
rake("db:migrate")
git :init
git :add => "."
git :commit => "-a -m 'Initial commit'"

Dá para perceber que seu uso é bem intuitivo. Esse template remove o arquivo public/index.html, cria um scaffold Person, mapeia a rota inicial para PeopleController e roda a migração. Depois inicializa o repositório git e commita tudo. Legal, né?!
Outros templates podem ser obtidos aqui e aqui.

Bom, mas a idéia desse post é criarmos nosso próprio template.

Como várias pessoas usam o brazlian-rails em seus projetos, vamos aqui criar nosso template configurando para tal.

Primeiro vamos configurar as gems. Crie um arquivo ruby chamado brazilian-rails-template.rb e adicione o código abaixo.

#brazilian-rails-template.rb
gem "brdinheiro",       :version => ">= 2.1.6"
gem "brcep",            :version => ">= 2.1.6"
gem "brcpfcnpj",        :version => ">= 2.1.6"
gem "brdata",           :version => ">= 2.1.6"
gem "brdinheiro",       :version => ">= 2.1.6"
gem "brhelper",         :version => ">= 2.1.6"
gem "brnumeros",        :version => ">= 2.1.6"
gem "brstring",         :version => ">= 2.1.6"
gem "brI18n",           :version => ">= 2.1.6"

O uso de :version é totalmente opcional. Assim como as opções :source e :lib.

Lembre-se que o método gem() não instala as gems para você. Se quiser fazê-lo, adicione a linha abaixo ao seu arquivo.

rake "gems:install"

Qualquer rake task pode ser executada. Caso precise permissões de sudo para rodar alguma delas, use a opção :sudo => true. Existe, ainda, a opção :env para você setar qual ambiente deseja que a rake seja executada. Por exemplo:

rake "db:migrate", :env => "test"

Existe também o método plugin(), para configurar, advinhem?, seus plugins.

Ok, voltemos para nosso template.
Uma vez que a internacionalização  do brazilian-rails é, por padrão, desabilitada, precisamos que nosso template carregue o suporte a I18n da gem brI18n. Uma forma de fazer isso é criar um arquivo dentro de config/initializers que faça a chamada à require ‘brI18n’. Isso pode ser feito assim:

#brazilian-rails-template.rb
#...
initializer "load_brI18n.rb", <<-CODE
require 'brI18n'
CODE

O método initializer() cria um arquivo dentro de config/initializers/ com o nome passado com argumento. O último argumento vai ser impresso dentro do arquivo recém criado. A mesma ideia serve para o método lib(), que gera um arquivo dentro da pasta lib/, e para vendor(), dentro de vendor/. Existe, ainda, o file(), que gera o arquivo em um caminho absoluto:

file "app/components/foo.rb", <<-CODE
class Foo
end
CODE

Legal, assim já temos as gems configuradas. Vamos agora para o git.

#brazilian-rails-template.rb
#...
git :init

file '.gitignore', <<-CODE
log/*.log
log/*.pid
db/*.db
db/*.sqlite3
db/schema.rb
tmp
.DS_Store
doc/api
doc/app
config/database.yml
nbproject
CODE

inside("config") do
run "cp database.yml database.yml.sample"
end

Aqui iniciei o repositório git e criei o arquivo .gitignore com o file(). Note que usei o método run(), dentro de inside() para executar o comando ‘cp‘ no diretório config.
Meu amigo João Vitor me ensinou que é um boa prática nunca versionar o arquivo database.yml, então joguei ele (o arquivo, não meu amigo João dentro de .gitignore e versionei sua cópia inicial.

Bom, mas talvez nem sempre seja interessante fazer isso. Que tal perguntar ao usuário se ele desejar fazer uma cópia do database.yml? Para esse tipo de interação, existe o método yes?(), que recebe uma string como argumento, a imprime na tela e espera uma resposta “y” ou “yes” para sim e qualquer coisa diferente para não.

#brazilian-rails-template.rb
#...
git :init

file '.gitignore', <<-CODE
log/*.log
log/*.pid
db/*.db
db/*.sqlite3
db/schema.rb
tmp
.DS_Store
doc/api
doc/app
config/database.yml
nbproject
CODE

if yes?("Deseja fazer uma cópia de config/database.yml?")
run "cp config/database.yml config/database.yml.sample"
end

Pronto, melhor assim. Agora é só comitar

#brazilian-rails-template.rb
#...
git :add => "."
git :commit => "-a -m 'Initial commit'"

Por fim, nosso brazilian-rails-template.rb vai ficar assim:

gem "brdinheiro",       :version => ">= 2.1.6"
gem "brcep",            :version => ">= 2.1.6"
gem "brcpfcnpj",        :version => ">= 2.1.6"
gem "brdata",           :version => ">= 2.1.6"
gem "brdinheiro",       :version => ">= 2.1.6"
gem "brhelper",         :version => ">= 2.1.6"
gem "brnumeros",        :version => ">= 2.1.6"
gem "brstring",         :version => ">= 2.1.6"
gem "brI18n",           :version => ">= 2.1.6"

initializer "load_brI18n.rb", <<-CODE
require 'brI18n'
CODE

git :init

file '.gitignore', <<-CODE
log/*.log
log/*.pid
db/*.db
db/*.sqlite3
db/schema.rb
tmp
.DS_Store
doc/api
doc/app
config/database.yml
nbproject
CODE

if yes?("Deseja fazer uma cópia de database.yml?")
run "cp config/database.yml config/database.yml.sample"
end

git :add => "."
git :commit => "-a -m 'Initial commit'"

Esse template está no GitHub, fique a vontade para alterá-lo.

Se preferir, você pode apontar diretamente para o Gist:
rails minha_app -m http://gist.github.com/90973.txt

E é isso.

Abraços e bons códigos!

$ RSPEC=true autotest

And everything works fine!
Então, atualizei meu ~/.bash_profile com a linha abaixo e pronto.

export RSPEC=true

Abraços e bom código.

Algo como isso aparece no seu ‘output’:

from E:/cms/cms3/vendor/plugins/rspec/lib/spec/runner/options.rb:101:in `run_examples'
Finished in  seconds

0 examples, 0 failures
	from E:/cms/cms3/vendor/plugins/rspec/lib/spec/runner/command_line.rb:9:in `run'
	from E:/cms/cms3/script/spec:5

Para resolver é simples. Substitua o arquivo $NB_PATH/ruby2/nb_rspec_mediator.rb por esse aqui.

Você também pode baixar a versão 6.7 de desenvolvimento, mas, particularmente, não recomendo. Ela ainda não está estável e ocorrem muitos bugs.

Abraços e bons códigos.

A diferença entre as duas versões é que o plugin activerecord_i18n_defaults utiliza um método do 2.2 que foi renomeado na 2.3.2. Então, fiz um fork do projeto e corrigi a chamada ao método. Os testes passaram, ótimo.

Nos comentários do post do Patrick, o Thiago sugere o uso do plugin i18n_label para que as tags label utilize internacionalização. Fiz um fork do projeto também e juntei com meu primeiro fork. O resultado pode ser conferido na página do projeto no github.

Abraços e bons códigos.