Em seu repositório Git, crie o arquivo ".git/hooks/pre-commit" com o conteúdo abaixo:

#!/bin/bash
cd "$0/../../.."
rake git:precommit

Execute o comando chmod a+x .git/hooks/pre-commit. Se você não fizer isso, o Git não irá executar este hook. Ele irá executar a tarefa Rake git:precommit.

Acesse a Yahoo! Developer Network e baixe o YUI Compressor. É um arquivo "jar", o que significa que você precisa ter Java 1.4 ou superior instalado. Alternativamente, você pode executar os comandos abaixo à partir da raíz de seu projeto Ruby on Rails.

wget http://www.julienlecomte.net/yuicompressor/yuicompressor-2.4.2.zip -O yuicompressor.zip
unzip yuicompressor.zip
mkdir tools
cp yuicompressor-2.4.2/build/yuicompressor-2.4.2.jar tools/yuicompressor.jar
rm -rf yuicompressor-2.4.2/

Agora, podemos fazer todo o trabalho sujo utilizando código Ruby. Crie o arquivo lib/tasks/dev.rake e adicione o código abaixo:

require "config/environment"
 
def run_compressor(type, files, except=[])
  output_refs = {:css => "stylesheets", :js => "javascripts"}
  output_dir = "public/#{output_refs[type]}"
 
  files.each do |input|
    output_name = File.basename(input)
    output_name.gsub!(/\.(js|css)$/, "-min#{File.extname(output_name)}")
    output = "#{output_dir}/#{output_name}"
 
    system "java -jar tools/yuicompressor.jar --type=#{type} #{input} > #{output}"
 
    original = file_size(input)
    compressed = file_size(output)
 
    puts " - #{File.basename(input)} [#{original}] => #{output_name} [#{compressed}]"
  end
end
 
def file_size(file)
  ActionController::Base.helpers.number_to_human_size(File.size(file))
end
 
namespace :git do
  desc "Run before a Git commit"
  task :precommit do
    Rake::Task['compress:css'].invoke
    Rake::Task['compress:javascript'].invoke
  end
end
 
namespace :compress do
  desc "Compress all javascript files using YUI Compressor"
  task :javascript do
    puts "\nCompressing javascript files"
 
    files = Dir['public/javascripts/*.js'].reject do |f|
      f =~ /-min\.js$/ || f =~ /\/jquery\.js/
    end
 
    run_compressor(:js, files)
  end
 
  desc "Compress all stylesheet files using YUI Compressor"
  task :css do
    puts "\nCompressing stylesheet files"
 
    files = Dir['public/stylesheets/*.css'].reject do |f|
      f =~ /-min\.css$/
    end
 
    run_compressor(:css, files)
  end
end

É um código bastante simples. Ele simplesmente pega todos os arquivos Javascript e CSS que não possuem "-min" no nome e aplica a compactação. O arquivo "jquery.js" não é compactado pois sempre utilizado a versão reduzida.

Como saber se está funcionando? Faça um commit! Se os arquivos compactados foram gerados, tudo saiu como esperado. Você receberá uma saída como esta:

Compressing stylesheet files
 - application.css [15.1 KB] => application-min.css [12.3 KB]
 
Compressing javascript files
 - application.js [4.6 KB] => application-min.js [3.1 KB]
 - facebox.js [9.2 KB] => facebox-min.js [4.9 KB]
 - jquery.form.js [22.3 KB] => jquery.form-min.js [8.2 KB]
 - rails.js [1 KB] => rails-min.js [466 Bytes]

Eu estou utilizando dois helpers que exibem a versão original dos arquivos caso eu esteja no ambiente de desenvolvimento, tornando a tarefa de depurar erros de Javascript e CSS mais simples.

module ApplicationHelper
  def compressed_stylesheets(*files)
    files.collect! do |f| 
      f.gsub!(/\.css$/, '')
      "#{f}-min.css"
    end unless Rails.env == "development"
 
    stylesheet_link_tag *files
  end
 
  def compressed_javascripts(*files)
    files.collect! do |f| 
      f.gsub!(/\.js$/, '')
      "#{f}-min.js"
    end unless Rails.env == "development"
 
    javascript_include_tag *files
  end
end

Para utilizá-los, basta passar o nome dos arquivos compactados.

<%= compressed_stylesheets 'application' %>
<%= compressed_javascripts 'rails', 'facebox', 'jquery.form.js', 'application'  %>

Importante!

Tenha sempre em mente que se seu Javascript for ruim — por ruim quero dizer nas coxas, mal-feito, gambiarra, tosco, nojento, um código que nem seu pior inimigo deveria ter acesso — a compactação irá, provavelmente, gerar erros de Javascript (sintaxe inválida).

Para garantir nada irá quebrar, siga os passos explicados na página do JSLint; eu já sigo há um bom tempo e nunca tive nenhum problema em versões compactadas de meus códigos! Veja os erros mais comuns:

• não finalizar linhas de código com ponto-e-vírgula
• não utilize eval; as funções setInterval e setTimeout também devem ser evitadas se o argumento for uma string. Utilize algo como setInterval(function(){ /* do something */ }, 1000).
• evite operadores de incremento (++) e decremento (--); prefira algo como i += 1 e i -= 1

Para ver muitas outras dicas, leia a documentação do JSLint.

Infelizmente, não é possível garantir que bibliotecas de terceiros irão funcionar em 100% dos casos. Leia o código antes de aplicar a compactação, já que você pode estar lidando com algo bastante ruim.

Nos dias 15 e 16 de outubro aconteceu o Rails Summit Latin America, evento voltado aos desenvolvedores Ruby on Rails do Brasil e países hermanos. Muito bem organizado pelo Fabio Akita e Locaweb, teve a participação de mais de 500 pessoas, que ouviram apresentações de Obie Fernandez, Dr. Nic, Nihn Bui & Hongli Lai, Chad Fowler e Chris Wanstrath, dentre outros.

Dia 1

No primeiro dia do evento só pude chegar depois do almoço. Queria muito ter visto a palestra do Chad Fowler que, pelo que muitos disseram, foi excelente! Só queria lembrar que aquele não era o Chad Fowler; provavelmente era algum alienígena que engoliu o verdadeiro. Mais magro, sem barba e de cabelo curto, chocou muito quem esperava ver este cara.

Depois foi a vez de David Heinemeir Hansson, que respondeu perguntas dos participantes sobre Rails 2.2 and thread-safety, dentre outras coisas em sua apresentação remota.

Quando cheguei, George Malamidis e Danilo Sato falavam sobre REST. Pelo pouco que pude assistir, pareceu-me ter sido uma palestra interessante, embora o assunto já seja um pouco batido.

Assim que acabou a palestra de George Malamidis, subiu ao palco Dr. Nic Williams. Engraçado, demorou um pouco para cativar o público que não o conhecia, mas logo arrancou boas risadas de todos. Falou sobre como manter projetos opensource, utilizando ferramentas como Git, Blogs & Rubyforge, dentre outras.

Já no fim da tarde subiu ao palco Chris Wanstrath, criador do Github e um dos mais conhecidos desenvolvedores de Ruby on Rails. Ele leu na íntegra seu próprio texto, que também foi apresentado no Ruby Hoedown 2008. Foi meio frustrante.

Já no final, aconteceu o Birds of Feather (BOF), uma desconferência com diversas micro-palestras. Nihn Bui mostrou seu compilador para Brainfuck escrito em Ruby (alguém me explica como as tradutoras falaram "Brainfuck" em português?). Depois de muito jabá e posições (sic) políticas, subiu ao palco Elomar, de apenas 17 anos. Ele conseguiu arrancar risadas do público do começo ao fim! Falou sobre sua experiência em formar um grupo de estudos com seus amigos. Leia mais neste post do Spiceee. Sem dúvida, foi a melhor apresentação de todo o dia!

Para encerrar a noite, fomos para uma churrascaria com todos os palestrantes e mais uma galera bem legal! Sooo cool! ;)

Dia 2

O dia começou muito bem com a excelente apresentação de Ninh Bui e Hongli Lai, da Phusion. Engraçados, com uma apresentação cheia de efeitos especiais, conseguiram abordar um assunto que pode se tornar chato muito rapidamente: infra-estrutura e deployment.

Logo após o coffee break-começou a palestra de Charles Nutter e Thomas Enebo, que falaram sobre JRuby.

A palestra seguinte que assisti foi a de George Guimarães, do Pagestacker, que mandou muito bem falando sobre ferramentas de monitoração, infra-estrutura e capacity planning. Paralelamente, acontecia a apresentação de Jay Fields, que falou sobre testes e, segundo me disseram, "cutucou" o RSpec, criado por David Chelimsky.

Após o almoço Manoel Lemos, Ronaldo Ferraz e eu falamos sobre os desafios de infra-estrutura enfrentados pelo BlogBlogs e metodologia de trabalho utilizada pela Webco, abordando um pouco de SCRUM, Testes, soluções desenvolvidas por nós, dentre outros assuntos. Foi muito legal ver a sala cheia quando uma palestra de David Chelimsky acontecia na mesma hora.

Assim que acabou nossa apresentação, fui correndo para a outra sala para assistir a segunda parte da apresentação de David Chelimsky. Ele falou sobre BDD e o Cucumber, que substituirá o atual Story Runner. Saí antes do final para poder assistir a apresentação de Vinicíus Teles, que falou sobre empreendedorismo e como descobrir oportunidades em pequenos nichos de mercado, citando seu exemplo.

As duas palestras seguintes foram substituídas por uma papo com uma galera bem legal que pretendia gravar um vídeocast. Só não rolou porque o Davis deu um mega-FAIL e não gravou nada.

Para encerrar a noite, o aguardado Obie Fernandez. Depois de seu Do the Hustle, criou-se uma expectativa muito grande, que não foi em vão. Começou parabenizando o Akita, e falou sobre a escolha do nome Hash Rocket, com um conceito muito "interessante" por sinal. Falou sobre metodologias de desenvolvimento, organização e paixão. Conseguiu segurar a maioria das pessoas até 20h40, quando sua apresentação terminou. Se ele falasse por mais uma hora, acredito que ninguém iria ligar. Foi excelente. O que me deixou mais feliz foi que pude ter certeza que nós da Webco estamos no caminho certo, já que muito do que ele falou está sendo aplicado aqui! Kudos for us!

Foi um excelente evento. Novamente, gostaria de parabenizar ao Akita e a Locaweb, que mostraram como um evento pode ser bem organizado e problema imprevistos podem ser rapidamente resolvidos quando se quer. Outra coisa que foi muito legal foi o papo com a galera nos corredores. Encontrei pessoas que só tinha conversado por IM ou Twitter e revi pessoas que há tempos não encontrava. Espero que ano que vem tenha um Rails Summit Latin America 2009. Se tiver, estarei lá com certeza!

Infelizmente, o Ruby on Rails não possui nenhuma forma nativa de fazer isso (na verdade, acho meio burra a decisão de manter os métodos de sanitização apenas no escopo de views).

Pensando nesse problema, criei um plugin chamado has_markup, que permite especificar quais tags e atributos são permitidos, eliminando todo o resto. Ele também normaliza o HTML enviado, convertendo-o para XHTML caso ele esteja mal-formatado. Você pode definir se o texto será formatado em HTML puro, Markdown ou Textile.

Bem simples de usar e faz o trabalho muito bem!

Como instalar

Primeiro, vamos instalar o plugin.

script/plugin install git://github.com/fnando/has_markup.git

O has_markup possui algumas dependências se você quiser usar Tidy, Markdown ou Textile. Veja abaixo como você pode instalar estas dependências.

Markdown

Parar ter suporte a Markdown, é necessário instalar a gem RDiscount.

sudo gem install rdiscount

Textile

Se você prefere Textile —eu prefiro!—, instale a gem RedCloth.

sudo gem install RedCloth

Tidy

Se você quer ter certeza de que não irá quebrar o seu próprio HTML, torne-o válido com o Tidy. Primeiro é preciso instalar a biblioteca. Acesse e faça o download do código-fonte. Existem alguns binários disponíveis, então dê uma olhada para descobrir qual é o mais adequado para você. Para compilar, execute os comandos abaixo.

tar xvf tidy4aug00.tgz
cd tidy4aug00
make
sudo make install

O Tidy deu alguns warnings após a compilação, mas ele foi instalado. No Mac OS X ele é instalado em /usr/lib/libtidy.dylib.

cp -f tidy /usr/local/bin
cp -f man_page.txt /usr/local/man/man1/tidy.1
cd /usr/local/bin; \
	chmod 755 tidy; \
	chgrp bin tidy; \
	chown bin tidy;
chown: bin: Invalid argument
make: *** [install] Error 1
 
 

Agora instale a gem com sudo gem install tidy.

Este plugin tentará encontrar o Tidy em seu sistema, procurando alguns diretórios onde ele normalmente estaria. Se ele não puder ser encontrado, especifique o caminho para o diretório da biblioteca em seu arquivo de ambiente na constante TIDY_PATH.

# config/environments/development.rb
TIDY_PATH = '/custom/path/to/tidy'

Usando o has_markup

O has_markup é um plugin para ActiveRecord, que disponibiliza algumas ferramentas que podem ser usadas em qualquer lugar. No seu modelo, basta adicionar algo como isto:

class Post < ActiveRecord::Base
  has_markup :content,
    :format       => :markdown,
    :tidy         => true,
    :tags         => %w(p a em strong ul li),
    :attributes   => %w(href)
end

No exemplo acima, o atributo content será formatado com Markdown. Apenas algumas poucas tags estão disponíveis e apenas o atributo href pode ser utilizado. O markup também irá passar pelo Tidy, garantindo que é um XHTML válido.

NOTA: o has_markup mantém uma versão final do markup em um atributo formatted_<attribute>. Dessa forma, você não terá problemas de performance por ter que converter o texto toda vez que quiser exibí-lo. O modelo acima poderia ter uma estrutura como esta:

create_table :posts do |t|
  t.string  :title
  t.text    :content, :formatted_content
end

Se você não quer limitar o conteúdo salvo, basta que você não especifique as tags e atributos aceitos.

class Post < ActiveRecord::Base
  has_markup :content,
    :format       => :textile,
    :tidy         => true
end

É possível usar o has_markup apenas para validar um HTML, mesmo sem estar formatado como Markdown ou Textile; basta especificar o formato :html.

class Post < ActiveRecord::Base
  has_markup :content,
    :format       => :html,
    :tidy         => true
end

Para pegar o HTML equivalente a um texto Markdown ou Textile diretamente, você pode instanciar um objeto da classe Markup

markup = Markup.new(:markdown, 'some text')
markup = Markup.new(:textile,  'some text')
puts markup.to_html

Para sanitizar códigos HTML, utilize a classe Sanitize.

# will sanitize and normalize HTML
Sanitize.html('<script>alert(document.cookie)</script>')
 
# will sanitize and allow only the specified tags
Sanitize.html('<script>alert(document.cookie)</script>',
	:tags => %w(p a em strong img ul li ol)
)
 
# will sanitize and allow only the specified attributes
Sanitize.html('<script>alert(document.cookie)</script>',
	:attributes => %w(href title alt)
)
 
# will sanitize and normalize HTML using Tidy
Sanitize.html('<script>alert(document.cookie)</script>',
	:tidy => true
)

Se quiser normalizar um HTML, utilize o método tidy.

Sanitize.tidy('some text', options)

Feedback

É isso! Se você tem alguma sugestão, dúvida ou crítica, envie um comentário. O projeto está hospedado no Github, então sinta-se livre para fazer um fork a qualquer momento.

O mais recente deles é o has_calendar, que permite exibir calendários com eventos de maneira muito simples.

A minha idéia, já que não uso Windows nem para desenvolvimento, nem para (sic) produção, foi utilizar o comando cal, disponível em sistemas *nix, evitando toda a complexidade de ter que se trabalhar com datas. Para deixar explicíto, este plugin não irá funcionar no Windows.

Usando o plugin

Primeiro, você terá que instalar o plugin. Para isso, execute o comando script/plugin install git://github.com/fnando/has_calendar.git.

Se você quiser exibir um calendário sem eventos, pode simplesmente chamar o helper calendar.

<%= calendar %>

Se quiser especificar um mês específico, pode passar um hash com algumas opções.

<%= calendar :year => 2008, :month => 9 %>

O dia atual é diferenciado e não exibe o número; em vez disso o texto "TODAY" é colocado no lugar. Se quiser substituir esta mensagem, utilize a opção :today.

<%= calendar :today => 'HOJE' %>

Para adicionar eventos, você deve passar um bloco, que receberá um objeto Date referente ao dia do calendário. Assim, você pode realizar consultas relacionadas a esta data e exibí-las da maneira que achar melhor.

<% calendar do |date| %>
  <% for schedule in Schedule.by_date(date) %>
    <%= link_to schedule.title, schedule_path(schedule) %>
  <% end %>
<% end %>

Como você pode perceber, isso faria até 31 consultas ao banco de dados (uma para cada dia da semana) se você não otimizasse seu código (embora eu tenha escrito o artigo assim para facilitar, minha idéia de uso ia ser totalmente diferente). Pensando nisso após ler o comentário do Carlos, decidi que seria melhor implementar uma forma onde apenas o resultado de uma consulta fosse informado.

No template, você pode definir a opção :events, passando o resultado de sua consulta. O bloco, que antes recebia a data, agora receberá também todos os registros específicos daquele dia.

<% calendar :events => Schedule.all, :field => :scheduled_at do |date, events| %>
  <% for schedule in events %>
    <%= link_to schedule.title, schedule_path(schedule) %>
  <% end %>
<% end %>

Melhorando a apresentação do calendário

Para formatar o calendário, você pode usar este CSS como ponto de partida.

#calendar {
  border-collapse: collapse;
  width: 100%;
}
 
#calendar td,
#calendar th {
  color: #ccc;
  font-family: "Lucida Grande",arial,helvetica,sans-serif;
  font-size: 10px;
  padding: 6px;
}
 
#calendar th {
  border: 1px solid #ccc;
  background: #ccc;
  color: #666;
  text-align: left;
}
 
#calendar td {
  background: #f0f0f0;
  border: 1px solid #ddd;
}
 
#calendar span {
  display: block;
}
 
#calendar td.events {
  background: #fff;
}
 
#calendar td.today {
  background: #ffc;
  color: #666;
}
 
#calendar caption {
  display: none;
}

Ele irá se parecer com isto:

Mais simples, impossível! ;)

NOTA: O Mac OS X não permite iniciar a semana pela segunda-feira. Sendo assim, se você desenvolve neste sistema operacional, a semana começará no domingo. Em sistemas Linux, onde a maioria das aplicações são executadas, a semana iniciará na segunda-feira.

NOTA 2: Se você quiser utilizar este plugin no Windows, certifique-se de que exista um comando cal no seu PATH, retornando exatamente a saída do comando para *nix. Ele deve ser executado no formato cal -m 12 2008. Teoricamente funciona. :)

UPDATE: Este artigo foi atualizado para mostrar a nova opção :events.

UPDATE 2: O Carlos sugeriu adicionar a chamada ao método da data no próprio helper. Claro que fica melhor! Use a opção :field.

Como já tinha lido muito sobre algumas ferramentas para esta finalidade, como Braid, resolvi testá-los. Infelizmente, nenhuma delas funcionava da maneira como eu gostaria. Então, como bom geek que sou, decidi fazer minha própria implementação: conheçam o Pez.

Pez é um gerenciador de plugins para Rails muito simples. A diferença principal em relação às ferramentas semelhantes é que ele não tenta adicionar as alterações/atualizações destes plugins no repositório do projeto. Em vez disso, ele cria um diretório central e faz apenas links simbólicos para o diretório vendor/plugins do projeto. Essa abordagem permite, por exemplo, que você mantenha um único diretório de plugins para diferentes projetos, desde que eles utilizem as mesmas revisões/branches.

Mas como não é só de notícias boas que se vive, aqui vem o lado negativo desta história: você não conseguirá usar o Pez se usa Windows, já que muitos comandos utilizados só estão disponíveis em sistemas *nix.

Se você se interessou, veja à seguir como instalá-lo e quais são os comandos disponíveis.

Instalando o Pez

O Pez está hospedado no Github e pode ser instalado com o comando abaixo.

sudo gem install fnando-pez --source=http://gems.github.com

Se quiser dar uma olhada no código ou gerar sua própria versão, siga os passos abaixo.

git clone git://github.com/fnando/pez.git
cd pez
rake gem:install

Usando o Pez na prática

Depois que o Pez tiver sido instalado, você deve executar o comando pez setup à partir da raíz de seu projeto. Isso irá criar um arquivo config/plugins.yml, que terá todas as informações dos plugins adicionados.

--- 
plugins: 
  rateableplugin: 
    repo: svn://rubyforge.org/var/svn/rateableplugin/trunk
    type: svn
  has_cache: 
    repo: git://github.com/fnando/has_cache.git
    type: git
    revision: 8aafca390796d79ed200000f3f13243b471b96fc
  cucumber: 
    repo: git://github.com/aslakhellesoy/cucumber.git
    type: git
    revision: 32d4f03d19bf33172bb7b48fed48e906a56598a7
    branch: html-visitor
  content_cache: 
    repo: http://svn.codahale.com/content_cache/
    type: svn
    revision: 20
development: /Users/fnando/Sites/sample/tmp/plugins
production: /Users/fnando/Sites/sample/tmp/plugins
 

Por padrão, os plugins são mantidos no diretório tmp/plugins. Você pode alterar essa configuração a qualquer momento, alterando o caminho relativo ao ambiente de seu projeto.

O Pez possui uma série de comandos. Para ver a lista completa, execute o comando pez help. Você pode visualizar a ajuda para um comando específico com o comando pez help [command].

Como você pode perceber, não tem muito segredo! Se você tiver alguma sugestão, envie um comentário. Se quiser contribuir, o projeto está no Github: http://github.com/fnando/pez.

Trivia: O nome foi tirado de um album do Less Than Jake chamado Pezcore, que eu estava ouvindo na hora que eu o programava. Ainda bem que não tenho gostos musicais bizarros! :)

Pensando nisso, comecei a estudar formas mais automáticas de se fazer isso. Eu já simpatizava com a idéia implementada pelo Geoffrey Grosenbach, onde ele de mostrou uma forma muito inteligente de lidar com cache ou, melhor dizendo, com sua expiração.

A idéia consiste basicamente em utilizar uma data de atualização do objeto para manter o controle de cache. Desta forma, sempre que a data for atualizada, o cache irá expirar automaticamente. Esta abordagem é especialmente útil quando utilizada com o Memcache, já que ele irá utilizar uma quantidade pré-definida de memória, descartando os itens mais antigos quando ela se esgotar.

A solução que encontrei para este problema foi empacotada na forma de um plugin: has_cache.

Utilizando o plugin has_cache

Para usar este plugin, basta você instalá-lo através do comando abaixo:

script/plugin install git://github.com/fnando/has_cache.git

Vale lembrar que este plugin exige as versões 2.1 ou superior do Ruby on Rails.

O plugin possui funcionalidades específicas para models, actions e views, como você verá a seguir.

Modelos

Depois de instalado, basta adicionar a seguinte chamada ao seu modelo:

class Game < ActiveRecord::Base
  has_many :comments
  has_many :publishers
  belongs_to :category
 
  has_cache
 
  def recent_comments
    comments.recent :limit => 5
  end
end

Apenas por adicionar a chamada ao método has_cache, todas as associações has_many e belongs_to irão ter uma versão com cache. Por exemplo, em vez de utilizar @game.comments, você pode utilizar @game.cached_comments. Simples assim!

Você também pode adicionar métodos que não são relacionamentos; basta utilizar a opção :include.

has_cache :include => :recent_comments

O exemplo acima irá adicionar o método de instância recent_comments. Se precisar adicionar métodos de classe, pode adicionar uma chamada como esta:

has_cache :include => {
  :class_methods => %w(all find), 
  :instance_methods => :recent_comments
}

Os métodos de classe possuem um argumento obrigatório, que é a chave que irá identificar aquele cache.

Game.cached_all :sorted_by_title, :order => 'title asc'

Se você instalar o plugin has_paginate, poderá fazer consultas paginadas com cache.

Game.cached_paginate %w(all @page), :order => 'title asc', :page => @page
@game.cached_comments(:page => @page)

Se quiser evitar a paginação, basta passar a opção :paginate com o valor false.

@game.cached_comments(:paginate => false)

ATENÇÃO: Se o plugin has_paginate estiver instalado, todas as associações has_many serão paginadas por padrão.

Mais à frente você verá como o cache é expirado, e como definir novas chaves que serão expiradas.

Controllers

No controller, você pode utilizar o método cached_render:

class GamesController < ApplicationController
  def index
    @page = [params[:page].to_i, 1].max
 
    cached_render :cache_name => %w(games index#{@page}) do
      @games = Game.cached_paginate %w(all #{@page}), @page
    end
  end
end

Você pode especificar o tempo de vida do cache com a opção :expires_in.

cached_render :expires_in => 15.minutes do
  # do something
end

Sempre que puder, utilize esta abordagem. Porém, se algum detalhe da tela é diferente para os usuários — um usuário logado tem um box com alguma identificação —, você não conseguirá fazer cache de toda a action. Mas poderá ter uma boa performance fazendo cache de pedaços da tela.

Views

Você pode fazer cache de fragmentos de um template. O plugin has_cache adiciona um método chamado cached_block.

<h1>Games</h1>
 
<% cached_block [:game_list, @page] do %>
  <ul>
    <% each_paginate @games do |game, i| %>
      <li>
        <%= game.title %>
      </li>
    <% end %>
  </ul>
 
  <%= paginate @games, url_for(:action => 'index') %>
<% end %>

Você também pode definir o tempo de vida do cache com a opção :expires_in.

<% cached_block [:game_list, @page], :expires_in => 1.hour do %>
  <!-- do something -->
<% end %>

Como funciona a expiração do cache

Todo relacionamento has_many precisa de um campo com o nome do relacionamento, que servirá como o controle de expiração do cache. No nosso exemplo, nosso modelo deveria ser criado da seguinte forma:

class CreateGames < ActiveRecord::Migration
  def self.up
    create_table :games do |t|
      t.references :category
      t.datetime :comments_updated_at, :publishers_updated_at
      t.string :title
 
      t.timestamps
    end
  end
 
  def self.down
    drop_table :games
  end
end

Toda vez que um comentário for criado, o plugin irá atualizar automaticamente o campo comments_updated_at, que é utilizado na composição da chave que irá identificar o cache. O mesmo irá acontecer quando um novo publisher for adicionado.

As seguintes estruturas de chave são expiradas quando um objeto é salvo ou destruído:

próprio objeto

:table/:id

:table/:id-:updated_at

associações has_many

:table/:id/:updated_at/:association/:association_updated_at

associações belongs_to

:table/:id

métodos de instância

:table/:id/:updated_at/:method_name

métodos de classe

Não são expirados automaticamente.

Como os métodos de classe recebem uma chave na hora que são chamados, não podem ser expirados automaticamente. Neste caso, você pode deixar o método expirar por tempo ou forçar sua expiração.

has_cache :before_expire => proc {|game|
  Game.has_cache_options[:to_expire] << "games/sorted_by_title"
}

E para finalizar…

Se você tiver alguma sugestão, faça um fork do has_cache e envie um patch. Dúvidas? Mande um comentário.

Você pode fazer o download do wallpaper aqui. Note que ele foi feito especialmente para Macbooks, com resolução de 1280×800.

No Ruby, você pode utilizar este padrão da maneira mais simples possível. Basta carregar a biblioteca Singleton.

require "singleton"
 
class Database
  include Singleton
 
  def connect
    @connection = Adapter.connect
  end
end

Ao adicionar o módulo Singleton, você torna o método new privado. Se você tentar instanciar esta classe, verá um erro como este:

NoMethodError: private method `new' called for Test:Class
  from (irb):3
  from :0

Para ter acesso à instância da classe Test, você deve utilizar o método instance.

Database.instance.connect

Muito elegante, assim como quase tudo no Ruby!

Exemplos de uso

Imagine que você tenha dois modelos: Band e Genre.

class CreateBands < ActiveRecord::Migration
  def self.up
    create_table :bands do |t|
      t.string :name
      t.references :genre
 
      t.timestamps
    end
  end
 
  def self.down
    drop_table :bands
  end
end
 

class CreateGenres < ActiveRecord::Migration
  def self.up
    create_table :genres do |t|
      t.string :name
      t.timestamps
    end
  end
 
  def self.down
    drop_table :genres
  end
end
 

Antes do Ruby on Rails 2.1, se você quisesse criar consultas personalizadas poderia criar métodos ou estender as associações. Por exemplo, poderíamos implementar uma busca pelos artistas recentes ou de um gênero.

class Band < ActiveRecord::Base
  belongs_to :genre
 
  def self.recent
    all :order => "created_at desc"
  end
 
  def self.by_genre(genre)
    all :conditions => {:genre_id => genre}
  end
end

Mas como você faria se quisesse todos os artistas recentes de um gênero? E se você quisesse adicionar mais uma condição, como a primeira letra do nome do artista? É quando a coisa se complica! Se você usar o named_scope, pode escrever o exemplo anterior desta maneira:

class Band < ActiveRecord::Base
  belongs_to :genre
 
  named_scope :recent, :order => "created_at desc"
  named_scope :by_genre, lambda {|genre| {:conditions => ["genre_id = ?", genre] }}
end

Ambas abordagens funcionam da mesma maneira quando acessadas sozinhas, como Band.recent ou Band.by_genre(params[:genre_id]). A difença principal do named_scope é que você pode fazer chamadas encadeadas, propagando as opções de consulta. Note que não é preciso seguir nenhuma ordem específica nas chamadas.

Band.recent.by_genre(params[:genre_id])
Band.by_genre(params[:genre_id]).recent

Todas as buscas adicionadas pelo named_scope se comportam como objetos do ActiveRecord. Você pode executar contagens, fazer outras buscas ou agir ativamente nos resultados retornados.

Band.by_genre.first(:conditions => ["name = ?", params[:name]])
Band.recent.reload
Band.recent.count
Band.by_genre(params[:genre_id]).fans.average(:fans_count)

Se você ainda não usa o named_scope, comece a usá-la agora mesmo! Ele é, sem dúvida, uma das melhores funcionalidades do ActiveRecord. Não sei como pude viver sem isto até agora!

if @object && @object.some && @object.some.fancy && @object.some.fancy.call
  # do something
else
  puts "meh. i don't like this syntax!"
end

Concordo que isto não é muito comum, mas você já deve ter feito algo como isto:

if @object && @object.respond_to?(:some_method) && @object.some_method
  # do something
end

Evite este tipo de aborrecimento trazido por estas verificações, adicionando um método como este:

def try(&block)
  raise 'No block given' unless block_given?
  yield rescue nil
end
 
if try { @objet.some.fancy.call }
  # do something
else
  puts 'hey! this call returned nil, false or threw an exception'
end

Muito mais com a cara de Ruby, não acha?