Se você é ainda um dos poucos a usar os scripts inspector, reaper e spawner do Rails, é bom saber que estes scripts não existirão mais à partir do Rails 2.3.

Eu mesmo só me lembro de usá-los uma vez em um arquivo ./script/spin que criei para subir múltiplas instâncias do Mongrel.

Como hoje a alternativa mais simples normalmente é o Passenger, estes scripts passaram a ser desnecessários na maioria dos casos. Portanto seu código foi retirado do core do Rails.

Caso você ainda precise de algum deles, foi criado um plugin chamado irs_process_scripts que os adicionará novamente em seu projeto.

Último dia do ano e o último artigo publicado este ano. Nada mais justo então do que uma retrospectiva de tudo o que rolou por aqui e comigo neste ano de 2008.

Janeiro

O ano começou muito bom com uma série de screencasts sobre os mais variados assuntos, desde Edge Rails até microformats. Também foi neste mês que saiu o primeiro episódio do nosso querido Rails Podcast Brasil!

Fevereiro

Este foi o mês de lançamento do meu primeiro plugin, o Custom Resource Name. Eu sempre tive um pé no mundo open-source, mas a aceitação do plugin na época foi muito importante para mim, já que me motivou a entrar de cabeça neste mundo.

Março

Em março tivemos a primeira (e única) promoção no Rails Podcast Brasil #9, o sorteio de um cupom do Peepcode. Lembra-se?

Abril

Abril foi o mês do Git. Tivemos a mudança de todo o código fonte do Rails para o GitHub e logo em seguido o Rubyforge também começou a oferecer repositórios em Git.

Maio

Foi neste mês que me rendi ao twitter (para me seguir, clique aqui), que lancei meu primeiro gem, o Autotest Notification e que iniciamos a dura tradução do livro Why’s (Poignant) Guide to Ruby para português.

Junho

Junho foi um mês bem agitado para mim. Com o lançamento do Ruby on Rails 2.1, lancei junto com o Marcos Tapajós o livro “Ruby on Rails 2.1 - O que há de novo?” em português, totalmente de graça. E com a ajuda da comunidade brasileira lançamos o primeiro livro de Ruby on Rails 2.1 do mundo em inglês. Neste mês também lancei a versão Doom Edition do meu gem Autotest Notification.

Julho

No mês de julho comemorei o 500º artigo deste blog. O lançamento do livro sobre Rails 2.1 foi um sucesso e foi publicado em 7 línguas diferentes. Também tivemos o anúncio do Rails Summit Latin America.

Agosto

Descobrimos que a idade média dos programadores Rails no Brasil é 24 (ui…) anos. Alguns artigos notáveis deste mês tiveram por tema: “Porque eu defendo o Shoulda” e “Não abrace a sua ignorância“. Também saiu a tradução do livro sobre Rails 2.1 em espanhol, completando 8 línguas.

Setembro

Anunciei que estaria ministrando o novo curso da e-Genial sobre Ruby on Rails 2.2. Outro artigo digno de nota neste mês foi o “Por que o salário dele é maior do que o meu?“.

Outubro

O maior destaque deste mês ficou para o 1º Rails Summit Latin America. Eu também palestrei com o tema “Meu emprego foi para os EUA“. Tivemos vídeos enviados por personalidades do mundo Rails e dois episódios do Rails Podcast Brasil sobre o evento. Neste mês também foi lançado o release candidate do Rails 2.2 e também o meu segundo livro “Ruby on Rails 2.2 - O que há de novo?” em português e inglês.

O primeiro encontro do time da Surgeworks

Novembro

Merb 1.0, finalmente! Também lancei meu segundo gem o Remarkable, que começou como um fork do Shoulda para usuários do RSpec. Também tivemos um episódio do podcast especial sobre o Rails 2.2.

O novo logotipo do projeto Remarkable

Dezembro

Terminou o curso de Rails 2.2 da e-Genial e foi muito bom ver alguns alunos já criando seus primeiros projetos em Rails. Lancei o Remarkable 2.0.1 totalmente reformulado e chegamos a 99,9% da tradução do (Comovente) Guia de Ruby do Why. E para fechar o ano com chave de ouro tivemos o anúncio da fusão entre o Rails e o Merb.

Que ano!

O método Rails.root foi alterado para não mais retornar um String com o caminho físico do seu projeto Rails, mas sim um objeto do tipo Pathname.

É uma alteração simples, mas que agrega muito ao desenvolvimento. Por exemplo, veja o seguinte trecho de código:

"#{Rails.root}/app/controllers"

Ele pode ser facilmente substituído, pela nova implementação do método Rails.root, assim:

Rails.root.join("app", "controllers")

O método assert_valid foi marcado como deprecated. Embora ele ainda continue existindo no Rails 2.3, não estará mais presente no Rails 3.

Este método era útil para garantir que um registro era válido e que não possuía nenhuma mensagem de erro. A sugestão é que usemos o seguinte código em seu lugar:

assert record.valid?
# ou
assert @model.valid?, @model.errors

Este texto é uma tradução do artigo escrito por Matt Linderman para o blog Signal vs. Noise, originalmente em inglês.

Outro dia, fui vender alguns livros na livraria The Strand. Eles têm um balcão separado na parte de trás para a venda de livros. Eu os trouxe em uma sacola e dois funcionários começaram a fazer uma triagem.

Em seguida, outro cara parou atrás de mim. Um dos funcionários disse-lhe, “Você está aqui para vender livros?” Ele disse, “Sim”. O funcionário respondeu: “Espere na linha lá fora.” O cara saiu.

Trinta segundos mais tarde ele estava de volta. O balconista repetiu, “Espere na linha lá fora.” O cara disse calmamente, “Não existe nenhuma linha lá fora”.

O balconista suspirou, olhou para o outro balconista, e sarcasticamente disse, “Não existe nenhuma linha.” O outro balconista de forma grosseira disse, “Se você não consegue imaginar uma linha, então você não pode vender livros aqui.” O potencial vendedor saiu calmamente.

Um minuto depois, uma menina caminhou até o balcão com livros. “Espere na linha lá fora”, disse o balconista novamente. Ela saiu. Pouco tempo depois, ela estava de volta. “O que foi?”. Ela disse, “Quero vender meus livros.” Ele disse: “Atrás da linha.” Ela saiu novamente. Os atendentes riram. “Vamos ver se a Mensa sociedade lá fora pode descobrir como funciona uma linha!” E eles riram um pouco mais. Como se estes dois clientes fossem completos idiotas.

Sorte minha, eu ter chegado momentos antes que estes outros dois. Porque eu não tinha certeza, se realmente havia uma linha em algum lugar lá fora. Ou se “espere na linha lá fora” na verdade significava “formem uma fila em linha lá fora.”

Flickr: illuminaut

Acho que muitas pessoas que trabalham no serviço de atendimento ao cliente fazem coisas semelhantes, rindo de clientes ou tirando sarro deles pelas costas (PEBKAC vem à minha mente).

Esta pode ser uma armadilha perigosa. Claro, um cliente pode até ser estúpido. Mas, se muitos clientes estão cometendo várias vezes o mesmo erro, talvez não seja um erro da parte dele. Talvez seja um erro da sua parte. Se ninguém pode descobrir onde está a maldita linha, talvez seja um sinal de que você não está fazendo um bom trabalho.

Eu já falei do método try() antes. Na época era apenas uma dica dada por Chris Wanstrath (que ainda nem era famoso pelo GitHub) para simplificar o bom e velho trecho de código:

@person ? @person.name : nil

Que com este método ficaria assim:

@person.try(:name)

# Um outro exemplo, com parâmetros
Person.try(:find, 1)

Ele funciona como o Object#send, mas ao invés de disparar uma exceção ele retorna nil se o método ou o próprio objeto não existirem.

Chris Wanstrath teve esta idéia já faz um bom tempo, e não me pergunte porque só agora isto entrou oficialmente para o Rails. Como já se passou muito tempo, o método já foi aprimorado aceitando também blocos como parâmetros:

@people.try(:map) {|p| p.name}

Isto é útil caso o método que você esteja testando chamar precise receber um bloco.

Meu amigo Márcio Gasparotto me deu de presente um logotipo para o projeto Remarkable! Veja abaixo:

Agora só falta o site do projeto!

Não é segredo para ninguém que membros da comunidade brasileira de Ruby on Rails estão traduzindo os famosos Rails Guides para o nosso idioma. Liderados por Cássio Marques, o grupo é formado por Daniel Lopes, Carlos Antonio da Silva, Adolfo Sousa, Cairo Noleto e Warlley Rezende.

Os Rails Guides apareceram recentemente como uma importante ferramenta de aprendizado para os iniciantes e aqueles que querem se aprofundar mais nos conceitos por traz do Rails. São guias completos sobre os mais diversos assuntos, como ActiveRecord, criação de rotas, cache, segurança, criação de plugins, internacionalização e outros.

Uma importante ferramenta para os novos em Ruby on Rails

Nossa comunidade felizmente já está acostumado com este tipo de trabalho, e estamos cada vez nos aperfeiçoando mais. Neste projeto, todos os arquivos que precisam ser traduzidos estão armazenados no GitHub.

Para colaborar é muito simples. Existe um projeto aberto no Lighthouse com tickets abertos para cada trecho que necessita de tradução. Crie uma conta, escolha um dos tickets e solicite acesso ao projeto para iniciar a tradução. Os responsáveis pelo projeto lhe darão permissão de escrita no repositório do GitHub.

Guarde este dia: 23 de dezembro de 2008 – o Fim da Guerra Rails x Merb!

Neste dia o Core Team do Rails e do Merb decidiram parar de brigar e resolveram trabalhar juntos para construir o melhor framework possível. Recebemos de braços abertos toda a comunidade Merb e esperamos que eles também estejam tão empolgados quanto nós!

Core Team do Merb

Em janeiro de 2009, provavelmente teremos o lançamento do Rails 2.3, e depois disso aguardaremos ansiosos o Rails 3, que será o resultado desta união!

Chega de gastar energias com brigas sem sentido e duplicação de código.

Já ouviu falar do plugin Quiet Backtrace criado pela Thoughtbot, a mesma galera por trás do Paperclip e Shoulda? Este plugin é muito interessante porque ele permite que você remova certas linhas do backtrace do Rails, tornando o log muito menor e simplificando a localização de problemas.

O conceito por trás deste plugin foi adicionado ao Rails. Um novo initializer chamado backtrace_silencers.rb foi criado e virá com algumas linhas de exemplo comentadas, assim:

# Be sure to restart your server when you modify this file.

# You can add backtrace silencers for libraries that you're using but don't wish to see in your backtraces.
# Rails.backtrace_cleaner.add_silencer { |line| line =~ /my_noisy_library/ }

# You can also remove all the silencers if you're trying do debug a problem that might steem from framework code.
# Rails.backtrace_cleaner.remove_silencers!

Neste arquivo você pode incluir silenciadores e filtros para o backtrace. Por exemplo o seguinte silenciador removerá do backtrace qualquer linha que contenha a palavra mongrel:

Rails.backtrace_cleaner.add_silencer { |line| line =~ /mongrel/ }

Os filtros funcionam de uma maneira um pouco diferente, não removendo a linha, mas substituindo trechos do backtrace por alguma outra coisa. No exemplo abaixo estou fazendo com que toda vez que a palavra mongrel aparecer no backtrace ela seja substituída por ‘aeiou’:

Rails.backtrace_cleaner.add_filter { |line| line.gsub("mongrel", 'aeiou') }

Para desligar esta funcionalidade temporariamente basta tirar o comentário da linha abaixo:

Rails.backtrace_cleaner.remove_silencers!

Usado com sabedoria, este novo recurso pode se tornar uma ferramenta poderosa.

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

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.

Foi adicionado à classe Enumerable um novo método chamado none?. Este método nos auxiliará nos momentos em que se faz necessário verificar se nenhum dos itens de uma coleção correspondem a uma determinada regra.

Por exemplo, no código abaixo a variável success somente será true se o status de todos os elementos da coleção responses não representarem um redirecionamento:

success = responses.none? {|r| r.status / 100 == 3 }

Atualmente não existe nenhum incentivo no Rails para a criação de testes para helpers. Quando criamos um novo modelo ou controller, o próprio script de criação já se encarrega de gerar os arquivos para testes unitários e funcionais, mas nada é criado para que possamos testar nossos helpers.

Na próxima versão do Rails ao executar um dos scripts geradores de código, como o controller, resource ou scaffold, você ganhará também um arquivo de teste pré-criado para testar seus helpers. Um novo diretório chamado helpers será criado dentro do diretório test/unit, e nele arquivos seguindo a nomenclatura [controller]_helper_test.rb conterão os testes dos seus helpers.

Veja um exemplo de um arquivo pré-criado pelo comando script/generate scaffold photos:

require 'test_helper'

class PhotosHelperTest < ActionView::TestCase
end

Chegou ao fim o curso Ruby on Rails 2.2 - do básico ao avançado que ministrei pela e-Genial. Foi uma experiência muito boa para mim, aprendi muito com todos os meus alunos!

O curso mal acabou e já tem alguns projetos saindo do forno. O Luciano de Maria, por exemplo, acabou de anunciar o Financeea, um site de controle financeiro.

O Marcos Bohrer também criou o Investirbem.

Finalmente a série de artigos cobrindo todas as novas funcionalidades do Rails 2.2 terminou, e de agora em diante somente novas adições serão cobertas. Não sabemos ao certo se a próxima versão do Rails será a 2.3 ou 3.0, mas aqui chamaremos apenas de Edge Rails.

Outra novidade neste blog foi a adição do Google Connect. Vocês podem encontrar na primeira página uma caixa para se cadastrar no menu lateral. Ainda não inclui todas funcionalidades, até o momento é possível apenas se associar ao blog, mas futuramente serão permitidos comentários via esta ferramenta, além de outros tipos de colaboração. A idéia no momento é apenas testar ferramenta.

Vamos ao que realmente interessa. No Rails 2.1 tivemos a introdução dos named_scope, que se tornaram ferramentas poderosas em nossas mãos. Mas na próxima versão do Rails teremos também um default_scope.

Ele funciona exatamente como um named_scope, mas como o próprio nome diz é um escopo padrão que deve ser usado em todas as pesquisas. Vejamos alguns exemplos:

class Person < ActiveRecord::Base
  default_scope :order => 'last_name, first_name'
end

No exemplo acima estou definindo o escopo padrão para o meu objeto Person. Veja o resultado de uma simples pesquisa por todos os registros no banco de dados:

Person.all
# => Person.find(:all, :order => 'last_name, first_name')

Isto também vale para minhas associações:

class Company < ActiveRecord::Base
  has_many :people
end

Company.find(1).people
# => Person.find(:all, :order => 'last_name, first_name', :conditions => { :company_id => 1 })

Caso seu modelo possua named_scopes, eles também incluirão as condições impostas pelo default_scope, à menos que você sobrecarregue a condição existente com alguma outra (informando uma outra ordem no exemplo acima).

Para executar uma pesquisa desconsiderando o default_scope, você deve fazer uso do método with_exclusive_scope:

Person.with_exclusive_scope { find(:all) }
# => Person.find(:all)

O método Module#delegate agora possui uma nova opção :prefix que pode ser atribuída caso você queira que o nome da classe alvo seja usado como prefixo antes do nome do método. Vejamos dois exemplos, primeiro da forma comum:

class Invoice < ActiveRecord::Base
  delegate :street, :city, :name, :to => :client
end

Invoice.new.street
Invoice.new.city
Invoice.new.name

Agora usando a opção :prefix:

class Invoice < ActiveRecord::Base
  delegate :street, :city, :name, :to => :client, :prefix => true
end

Invoice.new.client_street
Invoice.new.client_city
Invoice.new.client_name

Você também pode personalizar, atribuindo um outro nome ao prefixo:

class Invoice < ActiveRecord::Base
  delegate :street, :city, :name, :to => :client, :prefix => :customer
end

Invoice.new.customer_street
Invoice.new.customer_city
Invoice.new.customer_name

Acredito que este episódio foi o mais enrolado de todos os tempos. No inicio do mês o Fábio estava viajando e não conseguimos gravar, quando ele voltou, tivemos de gravar no meio da tarde (em velocidade acelerada) e logo em seguida foi minha vez de viajar… Então com umas duas semanas de atraso: o episódio #39, cheio de noticias antigas, haha!

Neste episódio comentamos sobre a briga entre os desenvolvedores Rails e Merb, upgrade para Rails 2.2 , CouchDB, Pownce e muito mais!

Neste episódio

• Tradução: Merb ♡ Rails
• Nasceu o site da Comunidade Merb Brasil.
• Criando seu primeiro projeto com Merb e DataMapper
• Installing ruby 1.9preview1 on OS X Leopard
• Ruby 1.9.1 Preview 2 has been released.
• Prêmio Info, Palestras pelo Brasil, Meu Ano de 2008
• New Rails 2.2 i18n defaults
• Rails 2.2 Released – 27 Links and Resources To Get You Going
• Breakage and fixage in Rails 2.2
• Hot in Edge Rails: Generate Rails Apps from Templates
• API Dock
• Apresentações Oficiais de Ruby on Rails
• Fully Tested SQL Server 2000 & 2005 Adapter for Rails 2.2
• Pourquoi Git est Meilleur Que X
• Easy Git External Dependency Management with Giternal
• QCon San Francisco 2008 – Entrevistas
• Shoulda para RSpec é Remarkable!
• CouchDB Edge: Security and Validation
• Spree 0.5.1 Released
• E-commerce usando Spree
• RubyConf 2008
• HappyMapper: Easy XML / Object Mapping for Rubyists
• The HTTParty has just begun
• Convocação: Vamos traduzir os Rails Guides para Português!
• JBoss on Rails: Deploying Rails Apps to a JBoss App Server
• Automatic file type detection for Rspec and Rails in Textmate
• Ruboss – A Flex Framework on Rails
• Productivity for Programmers
• Clustered JRuby – Cluster transparente de JRuby com Terracotta
• Dica – traduzindo will_paginate
• Pownce Deadpooled, Team Moves To Six Apart
• Flay, eliminando repetições em código Ruby

Download: Episódio #39
iTunes: http://podcast.rubyonrails.pro.br/rss
Episódios anteriores: http://podcast.rubyonrails.pro.br/

 

 Rails Podcast Brasil - Episódio 39 [43:40m]: Play Now | Play in Popup | Download

No Rails 2.1 em alguns casos ao se criar dois controllers com o mesmo nome, mas em namespaces diferentes um erro acontece, veja:

$ rails -v
Rails 2.1.0

$ ruby -v
ruby 1.8.6 (2008-03-03 patchlevel 114) [universal-darwin9.0]

$ rails test

$ cd test/

$ script/generate scaffold Posts title:string body:text

$ script/generate controller -t Admin::Posts
The name 'Admin::PostsHelper' is either already used in your application or reserved by Ruby on Rails.
  Please choose an alternative and run this generator again.
  ...

Mais um bug corrigido na versão 2.2.

Após o lançamento do Rails 2.1 o método Time#advance parou de funcionar corretamente com frações de tempo como:

>> Time.stubs(:now).returns Time.local(2000)

>> 1.5.days.ago == 36.hours.ago
# => false

Este erro foi corrigido no Rails 2.2.

O helper atom_feed agora possui um builder interno que permite a criação de XHTML simplesmente acrescentando :type=>”xhtml” em qualquer elemento content, rights, title, subtitle ou summary. Assim:

entry.summary(:type => 'xhtml') do |xhtml|
  xhtml.p "A XHTML summary"
  xhtml.p post.body
end

Veja como este bloco se encaixa dentro do atom_feed:

atom_feed do |feed|
  feed.title("My great blog!")
  feed.updated((@posts.first.created_at))

  for post in @posts
    feed.entry(post) do |entry|
      entry.title(post.title)

      entry.summary(:type => 'xhtml') do |xhtml|
        xhtml.p "A XHTML summary"
        xhtml.p post.body
      end

      entry.author do |author|
        author.name("DHH")
      end
    end
  end
end

Desta forma o builder interno do atom_feed irá incluir o XHTML gerado dentro de uma tag DIV.

Claro que ainda podemos fazer da forma antiga passando todo o HTML dentro de uma string, mas desta forma nosso código fica mais limpo.

Uma nova opção foi incluída ao método atom_feed, agora podemos incluir instruções de processamento ao xml. Veja um exemplo:

atom_feed(:schema_date => '2008', :instruct => {
  'xml-stylesheet' => {
    :href=> 't.css', :type => 'text/css'
  }
}) do |feed|

  # ...

end

Instruções de processamento são informações contidas no documento XML que serão repassadas para o aplicativo que o requisitou. Essas instruções são na maioria das vezes usadas para informar ao aplicativo como ele deve manipular os dados que estão no documento XML.

No exemplo acima estou dizendo ao aplicativo que recebe o XML que ele deve exibi-lo com uma folha de estilo (CSS) especifico. Veja como fica no XML:

<?xml-stylesheet type="text/css" href="t.css"?>

De um tempo para cá parece que virou moda a criação de projetos Rails semi-prontos. Em uma rápida pesquisa no GitHub encontrei o Bort, Blank, Suspenders, starter-app, appstarter e mais alguns menos conhecidos.

E isto é muito bom, já que na maioria das vezes usamos sempre a mesma estrutura para criar nossos projetos, os mesmos gems e plugins e o mesmo sistema de autenticação. Eu mesmo já experimentei alguns dos projetos que mencionei acima, mas eles são projetos semi-prontos criados para suprir as necessidades das equipes que os criaram e não as minhas necessidades.

Existe um projeto mais interessante do que todos estes, chamado rg. Jeremy McAnally teve a idéia de criar um script na qual você pudesse montar a sua própria estrutura de projeto, apenas relatando quais gems e plugins você deseja usar, quais arquivos criar e com que conteúdo, etc..

Percebendo a necessidade dos desenvolvedores por tais projetos semi-prontos, o core team do Rails decidiu incluir o rg no Rails. Assim ganhamos a opção de carregar um template ao criar um novo projeto Rails de forma nativa.

Nunca foi tão fácil criar um template padrão para um projeto Rails. Veja um exemplo de um template:

# Install plugins from git or svn
plugin "will-paginate", :git => "git://github.com/mislav/will_paginate.git"
plugin "old-restful-auth", :svn => "http://svn.techno-weenie.net/projects/plugins/restful_authentication/"

# Add gems to environment.rb
gem "jeremymcanally-context"
gem "bluecloth"

lib("crypto.rb") do
  "crypted_special_value = '#{rand}--#{Time.now}--#{rand(1337)}--'"
end

# ...file data from block return value.
# #initializer creates a new initializer file
initializer("crypto.rb") do
  salt = "--#{Time.now}--#{rand}--#{srand(Time.now.to_i)}"

  "SPECIAL_SALT = '#{salt}'"
end

rakefile("bootstrap.rake") do
  project = ask("What is the UNIX name of your project?")

  <<-TASK
    namespace :#{project} do
    task :bootstrap do
      puts "i like boots!"
    end
  end
  TASK
end

route "map.root :controller => :welcome"

No código acima estou definindo quais plugins devem ser instalados, quais gems devem ser adicionadas no arquivo environment.rb, também estou criando um arquivo chamado crypto.rb na pasta lib e um initializer com o mesmo nome, uma tarefa rake e adicicionando uma rota no arquivo conifg/routes.rb.

Este script pode estar armazenado na sua máquina, ou mesmo em algum site como o Gist do GitHub, por exemplo. E para criar um projeto baseado neste template basta fazer assim:

# Usando um arquivo local:
$ rails <application name> -m /path/to/my/template.rb

# Ou através de um URL:
$ rails <application name> --template=http://gist.github.com/31208.txt

Adeus Bort, B