Este post serve mais como “cola” de referência, pois toda vez que vou fazer isso eu não encontro fácil no google e nunca lembro. Por sinal é mega simples, é só editar o config/application.rb e remover a linha:

require 'rails/all'

E substituir por:

require "active_record/railtie"
require "action_controller/railtie"
require "action_mailer/railtie"
require "active_resource/railtie"
require "sprockets/railtie"

Após isso, já não aparece mais as tasks de testes, e você pode remover a pasta test.

$ git rm -r test/

Pra finalizar, já segue a dica de alterar a task default, no final do Rakefile é só colocar:

Rake::Task[:default].prerequisites.clear
task :default => :spec  #no caso do rspec

Sucesso!

Muito buzz se formou depois que o DHH tornou público que a versão 3.1 do Rails virá com CofeeScript por padrão.

Aproveitando a barulheira, que é comum a cada vez que o criador da plataforma abre a boca, vamos nos ater ao que é importante e apresentar uma introdução ao resumo simplificado do CoffeeScript básico.

Confesso que minha opinião sobre essa ferramenta mudou nos primeiros instantes em que comecei a usar. No site do CoffeeScript (ok se eu começar a chamar de CS daqui para frente?) existe um link onde você digita o código do lado esquerdo e, imediatamente, do lado direito aparece o equivalente em JavaScript.

Fiz uma brincadeira lá usando um código que sempre me vem à cabeça ao tentar explicar o básico de programação funcional para alguem. Segue:

mimimi = (operation, value) ->
   operation(value);

dobro = (value) ->
  value + value;

quadrado = (value) ->
  value * value;

zero = (value) ->
  value - value;

um = (value) ->
  value / value;

alert(mimimi(dobro, 3));
alert(mimimi(quadrado, 3));
alert(mimimi(zero, 3));
alert(mimimi(um, 3));

Nada de outro mundo, certo? O equivalente JS é o código abaixo:

var dobro, mimimi, quadrado, um, zero;
mimimi = function(operation, value) {
  return operation(value);
};
dobro = function(value) {
  return value + value;
};
quadrado = function(value) {
  return value * value;
};
zero = function(value) {
  return value - value;
};
um = function(value) {
  return value / value;
};
alert(mimimi(dobro, 3));
alert(mimimi(quadrado, 3));
alert(mimimi(zero, 3));
alert(mimimi(um, 3));

CS permite também a checagem automática de valores e parâmetros opcionais, conforme o exemplo retirado do site:

fill = (container, liquid = "coffee") ->
  "Filling the #{container} with #{liquid}..."

Ou o equivalente em JS:

var fill;
fill = function(container, liquid) {
  if (liquid == null) {
    liquid = "coffee";
  }
  return "Filling the " + container + " with " + liquid + "...";
};

Sem dúvida, muito mais legível e expressivo.

É uma ferramenta que eu pretendo usar em algum projeto pequeno, para testar e ver o quanto acelera meu trabalho. Em projetos maiores talvez eu demore um pouco mais para usar mas, considerando que umas das minhas aplicações já conta com 79% de código total escrito em JavaScript, segundo o GitHub, imagino que isso vai melhorar consideravelmente a manutenção do código.

E no mais, se o CS não te chamou a atenção e você não quer mesmo utilizar, basta remover o require do arquivo Gemfiles e a vida segue como se nada tivesse acontecido.

Links recomendados:

• Site do CoffeScript: http://jashkenas.github.com/coffee-script/
• Mais do mesmo: http://www.rubyinside.com/rails-3-1-adopts-coffeescript-jquery-sass-and-controversy-4669.html
• Exemplo bacana de como utilizar CS dentro da sua view: http://geekiriki.blogspot.com/2010/08/jquery-meets-coffeescript.html

Documentação é aquilo que você reclama para fazer e reclama quando não encontra.

Por Plínio “Chico Xavier” via Twitter.

Isto me fez refletir (bem rápido) sobre as possíveis causas da não-documentação:

• É muito chato ! Editar wiki, doc … é incrível como toda documentação geralmente é feita em algo não produtivo.
• Espaço e Tempo (ou seja, prazo!). Sempre é deixado por último e nunca sobra tempo pra ser feito.
• Não é levado a sério. Levanta a mão que já viu a secretária documentando “tela” de sistema …
• Normalmente o “investidor” do software não vê valor nisto, ou melhor, espera alguém pedir e repassa a tarefa com prioridade “faz rapidinho”.

Ok. Após reflexão feita, hora de atacar o problema.

Usando “guides” para criar um Guide !

Este é um resultado da experiência abaixo:

Com a gem guides, em segundos você tem um scaffold, pronto para ser preenchido.

$ gem install guides

 $ guides #mostra os comandos disponíveis

$ guides new sample

$ cd sample

$ guides build && guides preview

Pronto. Em http://localhost:9292 você terá acesso ao novo guia gerado.

Preenchendo o seu Guia

Em guides.yml (exemplo aqui), está o básico do seu Guia. Nele está o índice de “capítulos”, com resumo e nome do arquivo que o link deve seguir. Os arquivos textile  gerados/criados ficarão na pasta source, o resultado do “guides build” ficará na pasta output.

As páginas são em textile, o que facilita bastante. Mas o grande diferencial, está em alguns helpers disponibilizados pela gem, que torna muito simples criar áreas de destaque como INFO, WARNING … etc e adicionar comandos e códigos.

Para ter idéia de uma página em textile, segue o link source/getting_started.textile (raw).

Repensando a documentação

Com certeza, usando a gem guides, vocẽ consegue um boost na hora de documentar. Já evitando aquela chatice de editar wiki, .doc, controlando versão … etc. Usando textile, seu editor preferido e git, não tem mais desculpas.

Desenvolvendo Frameworks e APIs

Já faz um tempo que eu topo com a vibe Documentation Driven Development. Como tudo na vida, é questão de bom senso. Documentar uma API, nada mais é do que definir a interface dela, e dependendo do caso, isto ajuda bastante antes de começar o desenvolvimento.

Você é um Usuário !

Uma documentação com um monte de imagem e seta, descrevendo o óbvio não serve para nada (além de passar raiva). Uma documentação sucinta, com o básico, por exemplo Instalação, Modo de Usar, Configurações Disponíveis é bem melhor que muito dossiê por aí ! Tente ao máximo se colocar no lugar do usuário ao escrever alguma documentação ou ajuda.

—

Não deixe de contribuir com o post. Mande sugestões, comentários, reclamações etc.

No final do ano passado, ao ver um twitty do José Valim, fiquei tentando a comprar o livro, mas depois do post Crafting Rails Applications: Why I wrote this book, tive certeza que não perderia este presente de Natal.

Crafting Rails Applications: Expert Practices for Everyday Rails Development

Apesar de poucas páginas, o livro tem muito conteúdo. Logo no começo, em “Who should read this book ?” é avisado, não é para iniciantes. Os capítulos são separados em tópicos interessantes, abordando diferentes maneiras de extender o Rails 3.

Aliás, extender é a palavra chave do livro. Dos projetos que compõe o Rails, somente o Active Resource não foi citado. O livro com certeza pula o básico, ou seja, não espere por explicações em como usar as funcionalidades do Rails.

-

Detalhes que tornam o livro interessante.

• Enginex – é uma Ruby gem que cria um Rails 3 Engine com Rakefile, Gemfile e pronto para rodar testes em cima de uma aplicação “vendorizada”. Ou seja, no livro temos projetos reais, que são executados e tem testes !
• TDD – todo código apresentado, é feito seguindo o Test-driven Development, mostra-se o teste falhando e vai implementando aos poucos, até tudo ficar verde.
• Como melhorar o seu código – conhecendo Responders e o Renderer Stack do Rails 3, você com certeza irá ampliar o seu leque de possibilidades de como melhorar o fonte das suas aplicações. Tem bastante exemplos de Rails Generators também.
• Desmistificando Rails – o Valim realmente conseguiu de forma majestosa explicar as entranhas do Rails 3. A cada capítulo e detalhe explicado, pude ver o verdadeiro trampo que fizeram no projeto, em comparação com o 2.x, o Rails mudou muito (internamente!).

Finalizando…

Se você é um desenvolvedor que se preocupa em conhecer a fundo o framework que trabalha, compre agora! Confesso que depois da leitura, estou muito mais a vontade para navegar no fontes do Rails, inclusive passei a acompanhar os tickets no Lighthouse. Rails 3 definitivamente está mais flexível, e o José Valim conseguiu expor tudo isso com código e uma leitura agradável.

Se você está pensando em fazer o deploy da sua aplicação Rails em um server Nginx com Phusion Passenger, você está no caminho certo! Não apenas pela segurança e performance do Nginx, mas também pela facilidade de instalação e configuração quando comparado à outros web servers populares.

A instalação do Nginx bem como configuração do módulo do Passenger são relativamente simples. A documentação de ambos é bem completa. Você provavelmente não terá muita dificuldade. Eu recomendo seguir o passo-a-passo da instalação do Passenger:

  passenger-install-nginx-module

Uma vez que tudo esteja instalado, é hora de configurar o Nginx editando o arquivo nginx.conf (provavelmente localizado em /usr/local/nginx/conf/nginx.conf)

Usando sub URI

O deploy como sub URI torna sua aplicação acessível com o endereço http://dominio.com/app1, sendo app1 o nome da sua aplicação. Supondo que diretório público do Nginx esteja em /var/www e sua aplicação Rails em /var/rails/app1, configure-o assim:

http {
    ...
    server {
        listen 80;
        server_name dominio.com www.dominio.com;
        root /var/www;
        passenger_enabled on;
        passenger_base_uri /app1;
    }
    ...
}

Ainda é preciso criar um link simbólico para que o contexto da aplicação Rails seja visível pelo document root em /var/www:

ln -s /var/rails/app1/public /var/www/app1

Reiniciando o Nginx, sua aplicação já estará rodando. Para adicionar outras aplicações, basta adicionar:

        passenger_base_uri /app1;
        passenger_base_uri /app2;
        passenger_base_uri /app3;

E em seguida criar os links simbólicos como descrito acima. Nota importante: em alguns casos, será necessário informar a URL relativa correta nas configurações do Rails:

   config.action_controller.relative_url_root = "/app1"

Usando subdomain

O deploy como subdomain torna sua aplicação acessível com o endereço http://app1.dominio.com. Basta configurar o Nginx como segue:

http {
    ...
    server {
        listen 80;
        server_name app1.dominio.com;
        root /var/rails/app1/public;
        passenger_enabled on;
    }
    ...
}

Note que o root aponta diretamente para o diretório “public” da aplicação Rails. Para fazer o deploy de outras aplicações como subdomínio, basta configurar outro “server”, alterando root e o server_name:

http {
    ...
    server {
        listen 80;
        server_name app1.dominio.com;
        root /var/rails/app1/public;
        passenger_enabled on;
    }
    ...
    server {
        listen 80;
        server_name app2.dominio.com;
        root /var/rails/app2/public;
        passenger_enabled on;
    }
    ...
}

Uma vez que o DNS do host esteja corretamente configurado, suas aplicações estarão acessíveis em http://app1.dominio.com, http://app2.dominio.com, etc.

Dúvidas ou sugestões, utilizem os comentários. Sucesso!

Enviar emails de uma aplicação Rails é muito simples. A parte complicada fica com a configuração do ambiente e do servidor de email. Se você não souber ou não tiver muita paciência para fazer isso (por exemplo instalar e configurar sendmail, mutt, etc), pode facilmente usar sua conta do Gmail para enviar as mensagens da sua aplicação.

Basta incluir as seguintes configurações no bloco config dos respectivos ambientes da aplicação (por exemplo, config/environments/production.rb):

  config.action_mailer.delivery_method = :smtp
  config.action_mailer.smtp_settings = {
    :enable_starttls_auto => true,
    :authentication => :plain,
    :address => smtp.gmail.com,
    :port => 587,
    :user_name => "seuemail@gmail.com",
    :password => "suasenha"
  }

O toque mágico é a chave :enable_startls_auto => true para habilitar TLS. Sucesso!

Iniciando minha participação neste blog, vou apresentar uma solução rápida para um problema que eu tive e levei um certo tempo para encontrar uma resposta.

Caso você não conheça, Bundler é uma ferramenta criada para facilitar a instalação e atualização de aplicações e suas gems, resolvendo facilmente as dependências e criando ambientes homogêneos em máquinas diferentes. Em outras palavras, resolve de uma vez por todas aquele inferno que era ter que baixar gem por gem da sua aplicação e ainda assim correr o risco de encontrar alguma incompatibilidade.

O Rails 3 utiliza o Bundler por padrão, mas aplicações em Rails 2.x ainda dependem das gems declaradas no arquivo config/environment.rb, e ao copiar os arquivos para uma determinada máquina, você é obrigado a usar rake gems:install, que vai levar algum tempo rodando e não vai instalar tudo o que você precisa.

Ou pelo menos era assim que funcionava até você ler esse post.

Primeiro, considerando que você esteja no diretório raiz da sua aplicação, execute a sequência abaixo:

Antes de qualquer outra coisa, instale o Bundler na sua máquina executando o comando gem install bundler

No seu arquivo config/boot.rb, imediatamente antes da linha Rails.boot!, insira o bloco abaixo:

class Rails::Boot
  def run
    load_initializer
 
    Rails::Initializer.class_eval do
      def load_gems
        @bundler_loaded ||= Bundler.require :default, Rails.env
      end
    end
 
    Rails::Initializer.run(:set_load_path)
  end
end

Crie um arquivo config/preinitializer.rb. Esse arquivo não existe no Rails 2.x, então se você não criar, não vai funcionar. Adicione as linhas abaixo nesse arquivo:

begin
  require "rubygems"
  require "bundler"
rescue LoadError
  raise "Could not load the bundler gem. Install it with `gem install bundler`."
end
 
if Gem::Version.new(Bundler::VERSION) <= Gem::Version.new("0.9.24")
  raise RuntimeError, "Your bundler version is too old for Rails 2.3." +
   "Run `gem install bundler` to upgrade."
end
 
begin
  # Set up load paths for all bundled gems
  ENV["BUNDLE_GEMFILE"] = File.expand_path("../../Gemfile", __FILE__)
  Bundler.setup
rescue Bundler::GemNotFound
  raise RuntimeError, "Bundler couldn't find some gems." +
    "Did you run `bundle install`?"
end

Crie um arquivo chamado Gemfile no raiz da sua aplicação. Entre em config/environment.rb, remova todas as instruções config.gem e as adicione no arquivo Gemfile conforme abaixo, sem o prefixo config. (ponto incluído).

Seu arquivo config/environment.rb era assim:

# Be sure to restart your server when you modify this file
 
# Specifies gem version of Rails to use when vendor/rails is not present
RAILS_GEM_VERSION = '2.3.10' unless defined? RAILS_GEM_VERSION
 
# Bootstrap the Rails environment, frameworks, and default configuration
require File.join(File.dirname(__FILE__), 'boot')
 
Rails::Initializer.run do |config|
  # Settings in config/environments/* take precedence over those specified here.
  # Application configuration should go into files in config/initializers
  # -- all .rb files in that directory are automatically loaded.
 
  # Add additional load paths for your own custom dirs
  # config.load_paths += %W( #{RAILS_ROOT}/extras )
 
  # Specify gems that this application depends on and have them installed with rake gems:install
  config.gem "bj"
  config.gem "hpricot", :version => '0.6', :source => "http://code.whytheluckystiff.net"
  config.gem "sqlite3-ruby", :lib => "sqlite3"
  config.gem "aws-s3", :lib => "aws/s3"
  config.gem "authlogic", :version => "=2.1.6"
  config.gem "slim_scrooge", "=1.0.10"
 
  # Only load the plugins named here, in the order given (default is alphabetical).
  # :all can be used as a placeholder for all plugins not explicitly named
  # config.plugins = [ :exception_notification, :ssl_requirement, :all ]
 
  # Skip frameworks you're not going to use. To use Rails without a database,
  # you must remove the Active Record framework.
  # config.frameworks -= [ :active_record, :active_resource, :action_mailer ]
end

E agora é assim:

# Be sure to restart your server when you modify this file
 
# Specifies gem version of Rails to use when vendor/rails is not present
RAILS_GEM_VERSION = '2.3.10' unless defined? RAILS_GEM_VERSION
 
# Bootstrap the Rails environment, frameworks, and default configuration
require File.join(File.dirname(__FILE__), 'boot')
 
Rails::Initializer.run do |config|
  # Settings in config/environments/* take precedence over those specified here.
  # Application configuration should go into files in config/initializers
  # -- all .rb files in that directory are automatically loaded.
 
  # Add additional load paths for your own custom dirs
  # config.load_paths += %W( #{RAILS_ROOT}/extras )
 
  # Only load the plugins named here, in the order given (default is alphabetical).
  # :all can be used as a placeholder for all plugins not explicitly named
  # config.plugins = [ :exception_notification, :ssl_requirement, :all ]
 
  # Skip frameworks you're not going to use. To use Rails without a database,
  # you must remove the Active Record framework.
  # config.frameworks -= [ :active_record, :active_resource, :action_mailer ]
end

Bem mais limpo, não?

Já o seu recém criado arquivo Gemfile vai ficar assim:

source 'http://gemcutter.org'
gem "bj"
gem "hpricot", "~> 0.6"
gem "sqlite3-ruby", "~> 1.3.1", :require => "sqlite3"
gem "aws-s3", :lib => "aws/s3"
gem "rails", "= 2.3.10"
gem "authlogic", "~> 2.1.6"
 
group :development, :test do
  gem 'mongrel', :require => false
end
 
group :production do
  gem "slim_scrooge", "~> 1.0.10"
end

Note que eu criei dois grupos: um com :development, :test e um com :production. Significa que as gems do primeiro grupo somente serão utilizadas em desenvolvimento e em testes, e as do segundo grupo somente serão usadas no ambiente de produção. O que está fora dos grupos será usado em qualquer ambiente.

Agora, finalmente você digita bundle install, aguarda alguns instantes e pronto! A sua aplicação está com todas as gems instaladas e suas devidas dependências.

Para listar as gems utilizadas, execute bundle list.

Sugestões, correções e críticas são bem vindas nos comentários.

Para mais informações, leia a documentação no site do Bundle: http://gembundler.com/

Este não é daqueles posts que explicam o que é rspec, testes, diferenças entre teste funcional, integração e etc. Este post é só uma rapidinha, pra quem já conhece rspec e capybara.

A documentação do Capybara é boa, mas deixa a desejar nas instruções de como integrá-lo somente com rspec. Com a ajuda do George Guimarães da Plataforma, cheguei num passo a passo mega simples.

No config/environments/test.rb declare:

config.gem "rspec",            :version => "= 1.3.0", :lib => false
config.gem "rspec-rails",      :version => "= 1.3.2", :lib => false
config.gem "capybara",         :version => "= 0.3.9", :lib => false

No spec/spec_helper.rb coloque:

require 'capybara/rails'
[...]
Spec::Runner.configure do |config|
 
  [...]
  config.include(Capybara, :type => :integration)
 
end

Pronto! Isto é o suficiente para utilizar o Capybara nos testes de integração.
Para finalizar, você pode montar um teste simples de validação. Por exemplo:

Crie spec/integration/site_spec.rb e coloque:

require 'spec_helper'
 
describe "Site sample" do
 
  context "root" do
 
    before do
      visit root_url
      save_and_open_page
    end
 
    it "should have Hello" do
      page.should have_content("Hello")
    end
 
  end
 
end

Para executar somente os testes de integração:

rake spec:integration

have_content e um hot tip que pode te salvar muitas horas !

Caso aconteça o erro:

undefined method `have_content' for #<ActionController::Integration::Session:0xb618ad10>

Graças a esta mensagem Can’t make matchers work with cucumber and rails 2.3.2, descobri que o have_content não funciona com o rails 2.3.2, eu resolvi o problema fazendo um upgrade para a última versão do rails. #ficaadica

Dúvidas, melhorias, sugestões e elogios são sempre bem vindos !

A API de rotas do Rails simplifica consideravelmente o desenvolvimento fornecendo um padrão de geração e utilização de URLs para toda aplicação. Porém algumas necessidades especificas e relativamente simples podem gerar dores de cabeça se forem implementadas incorretamente.

Um caso bastante comum são URLs compostas que sempre apontam para um mesmo recurso. Por exemplo, um blog que possua rotas para seus posts no formato /posts/autor/categoria/permalink provavelmente terá uma rota mapeada como map.post "posts/:author/:category/:permalink" gerando automaticamente os helpers post_path e post_url.

Muito bom, porém para usufruirmos desta facilidade precisamos fornecer os valores dos parâmetros dinâmicos nos controllers e views:

post_path(:author => @post.author, :category => @post.category, :permalink => @post.permalink)

E mesmo que você forneça os parâmetros em um array, vai dar muito trabalho além de deixar muito código repetido pela aplicação.

Entendi! Mas como resolvo este problema?

Para este caso, apenas implementar o método to_param do model não vai servir. Uma solução seria reescrever o método post_path (que é gerado automaticamente) no respectivo helper (posts_helper.rb):

def post_path(post, options = {})
  super(post, :author => post.author, :category => post.category, :permalink => post.permalink)
end

Outra solução seria sobrescrever o método default_url_options no controller para retorna os parâmetros padrões da rota:

def default_url_options(options = {})
  options.merge!(:author => @post.author, :category => @post.category, :permalink => @post.permalink) if options[:action] == "show"
end

A má notícia é que você terá que fazer isto para todos seus controllers e respectivos models.

A terceira solução (e mais elegante) é padronizar a maneira com que os parâmetros opcionais da rota são obtidos a partir do controller e seu respectivo model. Basta adicionar os seguintes métodos no seu ApplicationController:

def default_url_options(options = {})
  if (model = controller_model(options))
    dynamic_route_params(options).each do |param|
      options[param] = model.send(param) if model.respond_to?(param)
    end
  end
  options
end
 
def controller_model(options = {})
  clazz = (options[:controller].singularize.camelize.constantize rescue ActiveRecord)
  options.select { |key, value| value.is_a?(clazz) }.first.second
rescue
  nil
end 
 
def dynamic_route_params(options = {})
  returning [] do |dynamic_params|
    matched_routes = ActionController::Routing::Routes.routes.select do |route|
      route.matches_controller_and_action?(options[:controller], options[:action])
    end
    dynamic_segments = matched_routes.map(&:segments).flatten.each do |segment|
      dynamic_params << segment.key if segment.is_a?(ActionController::Routing::DynamicSegment)
    end
  end
end

Assim, os valores defaults dos parâmetros da rota serão obtidos diretamente do model. Caso queiram contribuir, este código está disponível no github.

Referências
Rails Routing from the Inside Out
Rails Guides: Routing

Qualquer um que comece a desenvolver com Active Record (AR), minha primeira recomendação é, para tudo e leia:  A Guide to Active Record Associations ou O Guia de Associações do Active Record. O guia é bem completo, e descreve muito bem os tipos de associações que estão disponíveis no AR.

Association Proxy, #wtf !

As associações:

• belongs_to
• has_one
• has_many
• has_and_belongs_to_many

Quando usadas, adicionam alguns métodos (veja Detailed Association Reference). Por exemplo, ao declarar uma associação belongs_to, o model “ganhará” os seguintes métodos:

• association(force_reload = false)
• association=(associate)
• build_association(attributes = {})
• create_association(attributes = {})

Onde association, será substituído pelo nome da associação. Exemplo retirado do guides:

class Order < ActiveRecord::Base
   belongs_to :customer
end

Cada instância de Order, conterá os métodos:

• customer
• customer=
• build_customer
• create_customer

O association proxy, é o objeto que faz a ligação do objeto que contém a associação, conhecido como owner, e o objeto associado, conhecido como target.

Legal e daí !?!

Graças ao association proxy, ao declarar uma associação, podemos extendê-la e adicionar comportamentos “customizados”. No guia, é citado como Association Extensions. O código de exemplo abaixo, está no github em random-samples.

Para exemplificar, vamos criar um modulo que adiciona o comportamento de uma galeria a qualquer coleção.

module GalleryColletion
 
  def current=(curr = nil)
    @current, @index = nil
 
    if curr.nil?
      @current = collection.first
      @index = 0
    else
      collection.each_with_index do |item, index|
        if item.id.to_i == curr.to_i
          @current = item
          @index = index
        end
      end
    end
    @current
  end
 
  def current
    @current
  end
 
  def position
    @index + 1
  end
 
  def previous?
    return false if @index.nil?
    !!(@index - 1 >= 0)
  end
  def previous
    collection[@index - 1] if previous?
  end
 
  def next?
    return false if @index.nil?
    !!(@index + 1 < collection.size)
  end
  def next
    collection[@index + 1] if next?
  end
 
  private
 
  def collection
    proxy_owner.send(proxy_reflection.name)
  end
 
end

Gallery Collection

Note que o modulo está na pasta lib, logo, a pasta tem que ser adicionada no path via config/environment.rb.

Para extender a associação, declare:

class Article < ActiveRecord::Base
  has_and_belongs_to_many :images, :extend => GalleryColletion
end

Article model, Image model aqui.

Agora para navegar entre as imagens, você pode usar:

a = Article.first
a.images.current = 1 #1 e o Image.id que deseja selecionar
a.images.current
a.images.position
a.images.next?
a.images.next
a.images.previous?
a.images.previous

Caso esteja com coragem, baixe o projeto e veja rodando.

Dúvidas, sugestões, algum “case” de sucesso, comente!