class ProductsController < ApplicationController
  def index
    @products = Product.with_state(:published).limit(34).load
    respond_with @products
  end
end

Embora seja apenas uma única linha de consulta, fiz um refactoring alterando essa única linha para isso:

@products = Vitrine.load(34)

Essa abstração introduziu uma nova classe chamada Vitrine, que quebrei em diversos métodos menores.

class Vitrine
  def self.load(size, finder = Product)
    new(size, finder).load
  end

  def initialize(size, finder)
    @finder = finder
    @size = size
  end

  def published
    @finder.with_state(:published)
  end

  def limit
    @finder.limit(@size)
  end

  def scope
    published.merge(limit)
  end

  def load
    scope.load
  end
end

OMG! Trocar uma linha com 56 caracteres por um novo arquivo com 26 linhas e 347 caracteres? Faz sentido?

Ao meu ver, faz todo o sentido. Por ter quebrado essa consulta em uma nova classe, tive a flexibilidade de poder escrever testes completamente desacoplados do Rails.

require "test_helper_lite"
require "./app/models/vitrine"

class VitrineTest < ActiveSupport::TestCase
  test "delegates to the initializer" do
    finder = stub
    instance = stub

    instance.expects(:load)

    Vitrine
      .expects(:new)
      .with(10, finder)
      .returns(instance)

    Vitrine.load(10, finder)
  end

  test "scope searches by state" do
    finder = stub
    vitrine = Vitrine.new(10, finder)

    finder
      .expects(:with_state)
      .with(:published)

    vitrine.published
  end

  test "limits result" do
    finder = stub
    vitrine = Vitrine.new(10, finder)

    finder
      .expects(:limit)
      .with(10)

    vitrine.limit
  end

  test "merges scope" do
    published = stub
    limit = stub
    finder = stub
    vitrine = Vitrine.new(10, finder)

    vitrine.stubs(limit: limit, published: published)
    published.expects(:merge).with(limit)

    vitrine.scope
  end

  test "loads products" do
    finder = stub
    scope = stub
    vitrine = Vitrine.new(10, finder)

    vitrine.stubs scope: scope
    scope.expects(:load)

    vitrine.load
  end
end

Perceba que estou apenas validando a interface desta classe, o que exige que eu escreva testes de integração, ou estarei testando apenas stubs.

O ponto é o seguinte: até onde esse tipo de abstração traz benefícios? Fui questionado sobre a vantagem de ter trocado uma única linha por vinte e cinco delas.

Minha alteração foi movida pela segurança que escrever este tipo de testes me traz. É infinitamente mais simples encapsular este comportamento e ter testes isolados, do que deixar em um controller e ter testes por lá.

Justificar a implementação de uma determinada funcionalidade não deve ser motivada apenas pelo teste, mas eu quase sempre não consigo fazer a desassociação. Se é difícil de testar, deve existir uma maneira melhor.

Eu continuo acreditando que ter uma classe desacoplada com testes isolados que validam sua interface, juntamente com testes de integração é a melhor abordagem, mas confesso que bateu uma dúvida.

O que você acha? Esse tipo de abstração faz sentido ou é apenas overengineering? O que você faria de diferente?

O SPDY não veio para substituir o protocolo HTTP. Na verdade, ele modifica o modo como as respostas e requisições HTTP são realizadas. Em vez de realizar diversas requisições para carregar os elementos de uma página, o SPDY estabelece uma única conexão e trabalha com multiplexing, ou seja, pacotes de diversas requisições são combinados e enviados por esta única conexão. Com isso, é possível ter até 64% de redução no tempo de carregamento das páginas.

Mas e quanto aos navegadores que suportam o SPDY? O suporte ainda não é completo, mas a lista já é bastante promissora.

• Firefox 15+
• Chrome 11+
• Opera

Instalando o NGINX com suporte ao SPDY

Se você se interessou, saiba que o NGINX possui suporte experimental ao SPDY. Esta funcionalidade foi patrocinada pela Automattic, empresa por trás do Wordpress.

Para instalar o NGINX com suporte ao SPDY, você vai precisar compilá-lo à partir do código-fonte.

$ wget http://nginx.org/download/nginx-1.3.13.tar.gz
$ tar xvfz nginx-1.3.13.tar.gz
$ cd nginx-1.3.13
$ wget http://nginx.org/patches/spdy/patch.spdy.txt
$ patch -p1 < patch.spdy.txt
$ ./configure --with-http_ssl_module --with-http_spdy_module
$ make
$ make install

Se você está usando o Ubuntu 12.04 Precise Pangolin, pode usar o repositório Debian da Hellobits, que possui o pacote nginx-plus, com algumas outras extensões como Redis, Websockets e outras.

Primeiro, adicione a chave pública GPG.

$ wget -O - http://apt.hellobits.com/hellobits.key | sudo apt-key add -

Depois, adicione o repositório.

echo 'deb http://apt.hellobits.com/ precise main' | sudo tee /etc/apt/sources.list.d/hellobits.list

Agora basta atualizar a lista de pacotes e instalar o pacote nginx-plus.

$ sudo apt-get update
$ sudo apt-get install nginx-plus

Configurando o NGINX

Você vai precisar de um certificado SSL para poder usar o SPDY. Se você precisa de certificados SSL, recomendo o site CheapSSLs. Um certificado de 5 anos da PositiveSSL custa apenas $25.

Para configurar o NGINX, basta adicionar poucas linhas ao seu bloco server. Veja, por exemplo, as configurações que estou usando no Simples Ideias.

server {
  listen 443 ssl spdy;
  server_name simplesideias.com.br;
  root /var/www/simplesideias/current/public;

  ssl_certificate /etc/nginx/ssl/simplesideias.com.br/ssl.crt;
  ssl_certificate_key /etc/nginx/ssl/simplesideias.com.br/ssl.key;
  ssl_session_cache shared:SSL:10m;
  ssl_session_timeout 10m;
  ssl_prefer_server_ciphers on;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers RC4:HIGH:!aNULL:!MD5;

  # other config
}

Verifique se as configurações estão corretas e reinicie o servidor.

$ sudo nginx -t
$ sudo nginx -s reload

Se você usa o Google Chrome, existe uma extensão que permite verificar se o site que você está visitando possui suporte ao SPDY. O Firefox possui uma extensão semelhante.

Se você ainda está preso no Ruby 1.8, a história é muito diferente. À partir de Junho de 2013 ele deixará de ter atualizações. E isso inclui atualizações de segurança. Por isso, meu conselho é que você comece a fazer a migração o mais rápido possível.

Neste artigo irei mostrar as principais mudanças introduzidas pela nova versão, lançada no dia 24/02/2013.

Trivia: Você sabia que o lançamento do Ruby 2.0 foi exatamente no dia em que o Ruby completou seu vigésimo aniversário?

Argumentos nomeados

Nós já estamos acostumados a usar hashes quando precisamos passar muitos argumentos para um método. Assim, não temos que nos preocupar com sua ordem e obrigatoriedade.

Agora você pode usar argumentos nomeados, que na assinatura do método se parecem muito com a definição de hashes.

Veja o método abaixo. Ele aceita um único hash com diversas chaves. Se você quiser extrair seus valores em variáveis, é preciso fazer isso manualmente.

def link(options = {})
  href = options[:href]
  text = options[:text]

  puts "href: #{href}"
  puts "text: #{text}"
end

No Ruby 2.0 isso não é mais necessário. Basta definir seus argumentos com o valor de inicialização e a variável será definida automaticamente.

def link(href: nil, text: nil)
  puts "href: #{href}"
  puts "text: #{text}"
end

Se você quiser, pode executar o método com os argumentos em ordem arbitrária.

link href: "http://simplesideias.com.br", text: "SimplesIdeias"
link text: "Hellobits", href: "http://hellobits.com"

Mas o que acontece se passarmos argumentos que não foram definidos?

link rel: "external", text: "Codeplane", href: "http://codeplane.com"
#=> ArgumentError: unknown keyword: rel

Neste caso, uma exceção ArgumentError será lançada, informando qual argumento não foi definido. Se você quiser, pode pegar uma referência para todos os argumentos que forem passados mas não definidos na assinatura do método. Basta usar o double splat.

def link(href: nil, text: nil, **keywords)
  puts "href: #{href}"
  puts "text: #{text}"
end

Todo e qualquer argumento nomeado que não for definido na assinatura do método será armazenado em um hash, que aqui foi chamado de keywords.

Como fica, então, a assinatura do método se eu tiver parâmetros ordenados misturados com parâmetros nomeados?

def catch_all(*args, **keywords)
  p args
  p keywords
end

catch_all "WOW!", "Ruby 2.0 rules!", message: "It rules indeed!"
#=> ["WOW!", "Ruby 2.0 rules!"]
#=> {:message=>"It rules indeed!"}

Note que não é possível mudar a posição do double splat. Se você quiser mesclar argumentos ordenados e nomeados, passe primeiro os ordenados e depois os nomeados.

Uma outra restrição dos argumentos nomeados é que você não pode ignorar os argumentos não definidos sem passar uma variável. Com argumentos ordenados você pode simplesmente usar o *.

def catch_args(*)
end

No caso de argumentos nomeados, ainda não é possível definir apenas **, mas isso já foi corrigido e deve entrar no próximo release.

def catch_keywords(**)
end

catch_keywords a: 1
#=> ArgumentError: unknown keyword: a

O método Method#parameters identifica argumentos nomeados com o símbolo :key e :keyrest.

def inspect_parameters(a, b = nil, *args, c: nil, **keywords, &block)
end

p method(:inspect_parameters).parameters
#=> [
#     [:req, :a],
#     [:opt, :b],
#     [:rest, :args],
#     [:key, :c],
#     [:keyrest, :keywords],
#     [:block, :block]
#   ]

Arrays de símbolos

O Ruby já possuia muitas construções literais para arrays, strings e expressões regulares, como %w[], %() e %r[]. O Ruby 2.0 adicionou mais uma construção, que agora permite criar arrays de símbolos.

platforms = %i[mac windows linux]
[:mac, :windows, :linux]
#=>

O literal %i não permite interpolar valores. É aí que entra o %I.

%i[#{Time.now}]
#=> [:"\#{Time.now}"]

%I[#{Time.now}]
#=> [:"2013-02-26 19:13:13 -0300"]

Encoding

No Ruby 1.9, o encoding padrão é US-ASCII. Isto significa que se você quiser usar caracteres acentuados, por exemplo, precisa definir o magic comment ou uma exceção será lançada.

puts __ENCODING__
#=> US-ASCII

text = "áéíóú"
puts text
#=> invalid multibyte char (US-ASCII)

Agora, o encoding padrão é UTF-8. Você não precisa mais adicionar o magic comment, há menos que queira manter a compatibilidade com o Ruby 1.9, o que é uma boa ideia. Veja este mesmo código ao ser executado no Ruby 2.0:

puts __ENCODING__
#=> UTF-8

text = "áéíóú"
puts text
#=> áéíóú

Module#prepend

Você já deve ter sentido a necessidade de estender o comportamento de um método. Imagine que você tem uma classe chamada MyClass, que possui um único método MyClass#foo. Você precisa estender este método, executando algo antes e depois da implementação original.

class MyClass
  def foo
    puts "foo"
  end
end

Você tem duas alternativas para resolver este problema. A primeira usa os métodos Module.define_method e Module.instance_method e é a mais recomendada, já que não causa efeitos colaterais.

class MyClass
  foo_method = instance_method(:foo)

  define_method :foo do
    puts "before foo"
    result = foo_method.bind(self).call
    puts "after foo"
    result
  end
end

MyClass.new.foo
#=> before foo
#=> original
#=> after foo

A segunda alternativa, muito comum diga-se de passagem, seria renomear o método e executá-lo com este novo nome. O problema acontece se alguém teve a mesma ideia que você e também renomeou o método para MyClass#foo_original.

class MyClass
  alias_method :foo_original, :foo

  def foo
    puts "before foo"
    result = foo_original
    puts "after foo"
    result
  end
end

MyClass.new.foo
#=> before foo
#=> original
#=> after foo

Se você está no Rails, é possível usar o método Module#alias_method_chain, que segue a mesma ideia do Module#alias_method.

require "active_support/all"

class MyClass
  def foo_with_puts
    puts "before foo"
    result = foo_without_puts
    puts "after foo"
    result
  end

  alias_method_chain :foo, :puts
end

MyClass.new.foo
#=> before foo
#=> original
#=> after foo

Com o método Module#prepend isso se torna muito mais simples. Ele permite alterar a hierarquia de classes e módulos de modo que este módulo seja adicionado antes da própria classe. Assim, podemos trocar todas as soluções anteriores por esta, que usa o super.

module FooExtension
  def foo
    puts "before foo"
    result = super
    puts "after foo"
    result
  end
end

class MyClass
  prepend FooExtension
end

MyClass.new.foo
#=> before foo
#=> original
#=> after foo

Mas como isso funciona? Se você executar o método Module.ancestors, verá que o módulo FooExtension foi adicionado na hierarquia antes mesmo da própria classe MyClass.

MyClass.ancestors
#=> [FooExtension, MyClass, Object, Kernel, BasicObject]

Por isso é possível chamar o super, que por sua vez irá executar o método MyClass#foo.

Protocolo to_h

Finalmente temos um protocolo oficial para converter objetos em uma representação em Hash. Trata-se do método to_h, que agora é implementado em várias classes do Core como NilClass, Struct e OpenStruct.

Veja, por exemplo, como fica isso com a classe OpenStruct:

require "ostruct"

user = OpenStruct.new(:name => "John Doe", :email => "john@example.org")

# Ruby 1.9
user.to_h
#=> nil

# Ruby 2.0
#=> {:name => "John Doe", :email => "john@example.org"}

Com a classe Struct o comportamento é semelhante.

User = Struct.new(:name, :email)
user = User.new("John Doe", "john@example.org")

user.to_h
#=> {:name=>"John Doe", :email=>"john@example.org"}

No caso de nil, um Hash vazio é retornado.

nil.to_h
#=> {}

No Ruby 1.9 os métodos NilClass#to_h e Struct#to_h não existem.

Expressões Regulares

O Ruby 2.0 mudou seu engine de expressão regular mais uma vez. O Oniguruma saiu para dar lugar ao Onigmo, um fork do Oniguruma com novas funcionalidades.

Uma das novidades introduzidas pelo Onigmo é a possibilidade de se ter condicionais na expressão regular. Também foram adicionadas algumas funcionalidades do Perl 5.10+.

Para saber quais sintaxes são aceitas no Ruby, acesse a documentação do Onigmo.

Refinements

Uma das grandes preocupações de quem começa a usar Ruby é em relação às classes abertas. A justificativa quase sempre envolve o perigo que existe em modificar classes existentes. Na prática, isso quase nunca acontece, embora vez ou outra você vai dar de frente com um código que faz algo muito bizarro (e que não deveria), mais por culpa do desenvolvedor meia-boca que do Ruby.

Tentando amenizar este problema, o Ruby 2.0 introduziu o Refinements, que é uma maneira de fazermos Monkey Patching de modo mais controlado.

Para mostrar como o Refinements funciona, vamos estender a classe Integer com o método Integer#minutes, que retorna a quantidade de segundos. Você poderia adicionar este método diretamente à classe Integer.

class Integer
  def minutes
    self * 60
  end
end

class MyLib
  puts 3.minutes
  #=> 180
end

puts 5.minutes
#=> 300

É exatamente isso que o ActiveSupport faz, estendendo classes do Core como Time, Date, Hash, Array, dentre outras. O questão é que essas extensões são aplicadas em todo o Ruby.

Para resolver este problema, o Ruby 2.0 adicionou os métodos Module.refine e Module.using. A ideia é adicionar este tipo de extensão de um modo mais controlado. A proposta inicial permitia fazer isso.

module TimeExtension
  refine Integer do
    def minutes
      self * minutes
    end
  end
end

class MyLib
  using TimeExtension

  puts 3.minutes
  #=> 180
end

puts 5.minutes
#=>  undefined method `minutes' for 5:Fixnum (NoMethodError)

Infelizmente a implementação presente no Ruby 2.0 é experimental e reduzida. Este exemplo acima não funciona no Ruby 2.0.0-p0, mas funciona no Ruby 2.0.0-preview1. Em vez disso, você precisa fazer a chamada do método using() no contexto principal. As extensões aplicadas por este serão aplicadas apenas ao arquivo que fez a chamada.

# file: time_extension.rb
module TimeExtension
  refine Integer do
    def minutes
      self * 60
    end
  end
end

# file: with_refinement.rb
require_relative "time_extension"
using TimeExtension

puts 5.minutes
#=>  300

# file: without_refinement.rb
require_relative "time_extension"

puts 5.minutes
#=> undefined method `minutes' for 10:Fixnum (NoMethodError)

Existem muitas incertezas quanto ao modo como o Refinements deve funcionar. O Charles Nutter escreveu um ótimo artigo falando sobre a complexidade e problemas que o Refinements introduz.

Warnings

o Ruby gerará um warning toda vez que você executar um programa com o flag -w se você declarar uma variável e não usá-la.

def parse_name(full_name)
  first, last = full_name.split(" ")
  first
end

parse_name("John Doe")

Ao executarmos esse código:

$ ruby -c -w unused_var.rb
unused_var.rb:2: warning: assigned but unused variable - last
Syntax OK

No Ruby 2.0, variáveis começadas com _ não irão mais gerar estes warnings, mesmo quando não utilizadas.

def parse_name(full_name)
  first, _last = full_name.split(" ")
  first
end

parse_name("John Doe")

E ao verificar a sintaxe:

$ ruby -c -w unused_var.rb
Syntax OK

Constantes

Imagine que você tem uma constante A::B e quer pegar uma referência através do seu nome. Se você utilizar o método Object.const_get, verá que uma exceção será lançada.

module A
  module B
  end
end

Object.const_get("A::B")
#=> NameError: wrong constant name A::B

Para pegar a constante A::B você tinha iterar cada parte do nome da constante.

"A::B"
  .split("::")
  .reduce(Object) {|scope, name| scope.const_get(name) }
#=> A::B

Agora, isso ficou muito mais simples e funciona exatamente do jeito que você espera:

Object.const_get("A::B")
#=> A::B

Enumerator#lazy

O Ruby 2.0 introduziu um modo de criarmos enumerators que podem ser executados em conjuntos grandes ou mesmo infinitos. Veja o intervalo abaixo, por exemplo.

range = (1..Float::INFINITY)

Imagine que você quer pegar os 10 primeiros números primos maiores que 50. Com o método Enumerator#lazy, o estilo de programação não muda nada.

require "prime"

range = (0..Float::INFINITY)

primes = range.lazy
  .reject {|number| number < 50 }
  .select(&:prime?)
  .first(10)

primes
#=> [53, 59, 61, 67, 71, 73, 79, 83, 89, 97]

Se você tentar executar isso sem o método Enumerator#lazy, prepare-se para usar o Ctrl+C. Isso porque o Ruby tentará criar um objeto contendo o intervalo de 0 a infinito, o que obviamente não irá funcionar.

Já com o método Enumerator#lazy, apenas os elementos solicitados é que serão gerados, o que no nosso caso é bastante rápido de fazer, porque estamos acessando apenas 97 números.

Você não precisa ser tão radical quanto ao tamanho da coleção. Mesmo em uma lista muito menor, é possível ver a diferença. Vamos fazer um benchmark com este mesmo exemplo, mas desta vez usando uma coleção com apenas 1000 números.

require "benchmark"
require "prime"

range = (0..1000)
cycles = 1_000

def primes(range)
  range
    .reject {|number| number < 50 }
    .select(&:prime?)
    .first(10)
end

Benchmark.bmbm do |x|
  x.report("with lazy") do
    cycles.times{ primes(range.lazy) }
  end

  x.report("without lazy") do
    cycles.times{ primes(range) }
  end
end

O diferença é muito grande!

Rehearsal ------------------------------------------------
with lazy      0.250000   0.000000   0.250000 (  0.243124)
without lazy   4.800000   0.000000   4.800000 (  4.808169)
--------------------------------------- total: 5.050000sec

                   user     system      total        real
with lazy      0.290000   0.000000   0.290000 (  0.290303)
without lazy   4.250000   0.000000   4.250000 (  4.244091)

Já em coleções menores, usar o Enumerator#lazy pode não ser uma boa ideia. Mudando a quantidade de números gerados para 0..100, temos um resultado um pouco diferente.

Rehearsal ------------------------------------------------
with lazy      0.260000   0.000000   0.260000 (  0.260372)
without lazy   0.220000   0.010000   0.230000 (  0.226624)
--------------------------------------- total: 0.490000sec

                   user     system      total        real
with lazy      0.260000   0.000000   0.260000 (  0.262915)
without lazy   0.200000   0.000000   0.200000 (  0.200987)

TracePoint

O Ruby possui o método Kernel#set_trace_func, que permite rastrear diversos eventos durante a execução do código. Ele aceita um bloco, que pode receber até seis argumentos.

set_trace_func proc {|event, file, line, method, binding, class_name|
  puts "%8s %s:%-2d %10s %8s" % [event, file, line, method, class_name]
}

class Foo
  def initialize(options = {})
    @options = options
  end
end

Ao executar este arquivo, teremos uma saída como esta:

$ ruby trace.rb
  c-return trace.rb:1   set_trace_func     Kernel
      line trace.rb:5
    c-call trace.rb:5        inherited      Class
  c-return trace.rb:5        inherited      Class
     class trace.rb:5
      line trace.rb:6
    c-call trace.rb:6     method_added     Module
  c-return trace.rb:6     method_added     Module
       end trace.rb:9

Você pode ouvir até oito eventos diferentes:

• line: uma nova linha foi executada
• class: uma nova definição de classe/módulo
• end: fim da definição de classe/módulo
• call: um método foi executado por um método Ruby
• c-call: um método foi retornado por um método C
• return: um valor foi retornado por um método Ruby
• c-return: um valor foi retornado por um método C
• raise: uma exceção foi lançada

O Ruby 2.0 introduziu uma nova classe chamada TracePoint, que permite utilizar a mesma funcionalidade do método Kernel#set_trace_func usando uma API orientada a objetos.

Usando a classe TracePoint, o exemplo acima seria definido assim:

trace = TracePoint.new do |t|
  puts "%10s %s:%-2d %15s %10s" % [t.event, t.path, t.lineno, t.method_id, t.defined_class]
end

A saída é um pouco diferente, pois o nome do evento possui _ em vez de -.

$ ruby trace.rb
  c_return trace.rb:9           enable TracePoint
      line trace.rb:11
    c_call trace.rb:11       inherited      Class
  c_return trace.rb:11       inherited      Class
     class trace.rb:11
      line trace.rb:12
    c_call trace.rb:12    method_added     Module
  c_return trace.rb:12    method_added     Module
       end trace.rb:15

Se você quiser, pode ouvir um evento específico. Para isso, basta passar seu nome para o initializer.

trace = TracePoint.new(:class, &block)

Diretório corrente de um arquivo

Agora é possível pegar uma referência do diretório atual de um script que está sendo executado com o método Kernel#__dir__.

puts __FILE__
#=> ruby20_dir.rb

puts __dir__
#=> /Projects/samples

O método Kernel#__dir__ é equivalente a:

File.dirname(File.realpath(__FILE__))

Note que ele é todo em minúsculas, ao contrário de __FILE__. Isso acontece porque __FILE__ é apenas uma expressão, enquanto Kernel#__dir__ é um método. Não que isso seja uma justificativa, já que podemos criar um alias para este método, adicionando uma versão toda em maiúsculas.

module Kernel
  alias_method :__DIR__, :__dir__
end

puts __dir__
#=> /Projects/samples

puts __DIR__
#=> /Projects/samples

DTrace

O Ruby 2.0 trouxe integração com o DTrace, uma ferramenta que permite fazer a análise de performance e errors do sistema operacional e programas executados. O probes reconhecidos pelo Ruby estão disponíveis no wiki do projeto.

Outras mudanças

• A classe Iconv foi removida. A recomendação é que use o método String#encode. O uso do Iconv já era desaconselhado na versão 1.9.
• Os métodos String#chars, String#lines, String#codepoints e String#bytes agora retornam um Array, em vez de Enumerator. Use os métodos String#each_(char|line|byte|codepoints) se você quiser um Enumerator.
• A biblioteca net/http agora suporta Server Name Indication (SNI), uma extensão do protocolo SSL que indica o hostname no início do processo de handshake. Assim, é possível usar múltiplos certificados SSL com um único endereço IP.
• O método Kernel#require teve algumas otimizações que diminuem o tempo de boot de um app Rails.
• A classe CGI agora implementa o HTML5.

Finalizando

Como você pode perceber, o Ruby 2.0 tem muitas novidades. Eu não listei aqui tudo o que tem novo. Para saber exatamente o que entrou nesta versão, acesse a documentação.

Tenho que dizer que estou muito empolgado com esta versão! Se o Rails 4 der uma forcinha e exigir o Ruby 2.0, seria excelente! E isso não é nada impossível, já que em todos os projetos que testei o Ruby 2.0, nenhum precisou de mudanças para rodar o Rails 3.2.

O Ruby 2.0 trás uma série de novidades como argumentos nomeados em métodos, array literal para criação de símbolos, UTF-8 como encoding padrão, e muito mais. Se você já estava rodando seus projetos no Ruby 1.9 não precisará mexer quase nada. Algumas gems podem não estar funcionando, mas a tendência é que tenhamos uma série de atualizações nas próximas semanas. Vale notar que nenhum dos projetos que testei teve falhas desse tipo.

Veja à seguir como instalar o Ruby 2.0 em seu Ubuntu.

Removendo o ruby-stable/ruby-ichi

Se você já tinha instalado o Ruby 1.9 seguindo este outro tutorial, você precisará remover o Ruby.

$ sudo apt-get remove ruby-stable

ou

$ sudo apt-get remove ruby-ichi

Instalando o ruby-ni

Primeiro você precisará adicionar a chave pública GPG. Para isso, execute o comando abaixo em seu terminal. Se você já tinha instalado o pacote ruby-stable/ruby-ichi, pule esta etapa.

$ wget -O - http://apt.hellobits.com/hellobits.key | sudo apt-key add -

Agora, adicione o o repositório. Basta criar o arquivo /etc/apt/sources.list.d/hellobits.list. Você pode fazer executando o comando abaixo.

$ echo 'deb http://apt.hellobits.com/ precise main' | sudo tee /etc/apt/sources.list.d/hellobits.list

Finalmente, basta instalar o pacote Ruby.

$ sudo apt-get update
$ sudo apt-get install ruby-ni

Se tudo deu certo, o Ruby já deve estar disponível em seu sistema.

$ ruby -v
ruby 2.0.0p0 (2013-02-24 revision 39474) [x86_64-linux]

É importante que você apague todas as gems instaladas na versão anterior. Caso, contrário você terá alguns erros por causa da compilação.

$ rm -rf $(gem env gemdir)

Finalizando

Testei alguns projetos no Ruby 2.0 e até agora nenhum deles teve problemas. Ainda não coloquei em produção, mas devo fazer isso em breve (vou esperar um pouco para ver se nenhum novo release é lançado).

Se você precisa de pacotes para o Ubuntu 10.04 Lucid Lynx, deixe seu pedido nos comentários. Inicialmente não é minha ideia manter este pacote para o Ubuntu 10.04, mas se muita gente pedir, posso mudar de ideia!

É muito comum, por exemplo, termos um link para a página de login no header e no footer. Veja o exemplo abaixo:

<!DOCTYPE html>
<html lang="en" dir="ltr">
  <head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
    <title>Awesome Site!</title>
  </head>

  <body>
    <header>
      <h1>Awesome Site!</h1>
      <a href="/login">Log in</a>
    </header>

    <!-- content -->

    <footer>
      <a href="/login">Log in</a>
    </footer>
  </body>
</html>

Na Capybara 1, você poderia referenciar este link sem ter que definir o contexto. Um simples click_link "Log in" já era suficiente. No Capybara 2.0 isso não é mais possível. Se você tentar fazer isso irá receber uma exceção dizendo que o seu matcher é ambíguo.

Failure/Error: click_link("Log in")
     Capybara::Ambiguous:
       Ambiguous match, found 2 elements matching link "Log in"

Agora é preciso que você seja específico quanto ao elemento que deseja utilizar. Neste caso, a solução mais recomendada é usar o método within, definindo o contexto de seleção do elemento.

within("header") do
  click_link "Log in"
end

Embora esta sugestão funcione, ela traz dois problemas. O primeiro é que você irá, provavelmente, duplicar este código em mais de um lugar e todos nós sabemos que duplicar código quase sempre não é uma boa ideia. O outro problema é que seu teste terá um ruído desnecessário que, dependendo do contexto, pode torná-lo muito mais difícil de ler e entender.

Minha sugestão, neste caso, é criar helpers que irão fazer isso por você. Assim você acaba com os problemas que citei acima.

Primeiro, crie um arquivo chamado "spec/support/feature_helpers.rb". Neste arquivo nós iremos criar um módulo com helpers que iremos utilizar no grupo de features. Em vez usar o método within, nós iremos usar o método find, que retorna um contexto onde podemos buscar os elementos que precisamos.

module FeatureHelpers
  def main_header
    find("header")
  end
end

RSpec.configure do |config|
  config.include FeatureHelpers, :type => :feature
end

A maior vantagem de se criar um método como esse é que o seletor está totalmente encapsulado. Se você precisar mudar o contexto por algum motivo, basta alterar em um único lugar!

Agora, basta alterar o nosso teste para usar este contexto.

main_header.click_link "Log in"

Você pode usar esta técnica sempre que perceber que está fazendo muitas coisas durante os testes.

Muitos bancos utilizam módulos de segurança em Java Applets, que podem ser executados à partir do navegador. No entanto, essa tecnologia é constantemente questionada, pois as falhas de segurança são constantes.

Para você ter uma ideia de quão séria foi a última falha de segurança, o Departamento de Segurança americano fez uma recomendação para que todos usuários desativassem imediatamente o Java de seus navegadores. Nos últimos 24 meses foram lançadas 16 atualizacões críticas e de segurança.

A verdade é que ninguém mais usa Java Applets. Ninguém além dos bancos brasileiros. Essas falhas extremamente críticas simplesmente deixam você de joelhos. Como é que bancos dizem que isso é uma medida de segurança? Não dá para entender.

Ontem criei um site chamado Módulos de Segurança, que tem o objetivo de avisar sobre os problemas que esses módulos trazem.

Passe a palavra adiante. Só assim teremos a chance de nos livrarmos deles.

Mesmo com esta medida, que usa o método ActiveRecord::Base.attr_accessible, foram iniciadas discussões sobre outras maneiras de se resolver o problema. O Rails 4 virá com uma funcionalidade que permite filtrar quais parâmetros pode ser recebidos, mas que pode ser usada hoje mesmo em seu app através da biblioteca strong_parameters.

Configurando seu app

Se você quiser, pode desativar a whitelist dos atributos que podem ser atribuídos. Para fazer isso, basta editar o arquivo "config/application.rb".

require File.expand_path("../boot", __FILE__)

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

Bundler.require(*Rails.groups(:assets => %w[development test]))

module HOWTO
  class Application < Rails::Application
    config.active_record.whitelist_attributes = false
  end
end

Particularmente acho uma boa ideia continuar usando o ActiveRecord::Base.attr_accessible, principalmente se você terá vários perfis de atribuição, como o exemplo abaixo:

class User < ActiveRecord::Base
  DEFAULT_ATTRIBUTES = [:name, :email, :password, :password_confirmation, :username]

  attr_accessible *DEFAULT_ATTRIBUTES
  attr_accessible *DEFAULT_ATTRIBUTES, :role, :as => :admin
end

Uma outra motivação é que o ponto de entrada de dados pode mudar na aplicação, como background jobs e importadores de conteúdo, e nem sempre queremos que todos os atributos sejam definidos por atribuição em massa.

Na prática, isso significa que um usuário que é admin, pode facilmente definir atributos extras usando este novo perfil.

User.new(params[:user], :as => :admin)

Independente de sua escolha, você precisará incluir o módulo ActiveModel::ForbiddenAttributesProtection em cada modelo que pretende proteger. Supondo que você queira fazer isso no modelo User:

class User < ActiveRecord::Base
  include ActiveModel::ForbiddenAttributesProtection
end

Não é preciso dizer que isso pode ser extremamente chato de se fazer. Uma alternativa é incluir este módulo diretamente na classe ActiveRecord::Base. Crie um arquivo "config/initializers/strong_parameters.rb" com o conteúdo abaixo. Óbviamente, isso fará com que todos os modelos sejam protegidos.

ActiveRecord::Base.class_eval do
  include ActiveModel::ForbiddenAttributesProtection
end

Agora você pode definir no controller quais atributos são obrigatórios, além da lista de atributos permitidos durante a atribuição.

class SignupController < ApplicationController
  def create
    @user = User.create(user_params)
    respond_with(@user)
  end

  private
  def user_params
    params
      .require(:user)
      .permit(:name, :email, :password, :password_confirmation, :username)
  end
end

Perceba que estou usando o método SignupController#user_params para definir quais serão os atributos utilizados. Se um atributo não permitido for atribuído, uma exceção ActiveModel::ForbiddenAttributes será lançada. E caso o atributo params[:user] não seja enviado, uma resposta 400 Bad Request será retornada com o texto Required parameter missing: user.

Uma das coisas que não gostei desta abordagem foi ter justamente estas configurações em meu controller. Eu penso que isso introduz um ruído um tanto quanto desnecessário. Pensando em uma forma de como diminuir este ruído, decidi criar uma classe chamada PermittedParams, que contém todas essas definições. Além disso, sobrescrevi o método ActionController::Base#params para que ele use esta mesma configuração.

Primeiro vamos sobrescrever o método ActionController#params. Abra o arquivo "app/controllers/application_controller.rb" e adicione as linhas abaixo:

class ApplicationController < ActionController::Base
  private
  def params
    PermittedParams.new(super)
  end
end

Nossa classe PermittedParams irá delegar todas as chamadas para a implementação original, definindo apenas nossos filtros.

class PermittedParams < SimpleDelegator
  def user
    params
      .require(:user)
      .permit(:name, :email, :password, :password_confirmation, :username)
  end

  private
  def params
    __getobj__
  end
end

Agora, precisamos alterar o nosso controller. Para isso, remova o método SignupController#user_params, substituindo pela nossa nova implementação.

class SignupController < ApplicationController
  def create
    @user = User.create(params.user)
    respond_with(@user)
  end
end

Todos os filtros de outros modelos devem ser adicionados à classe PermittedParams. A grande vantagem desta abordagem é que fica muito simples ver todos os filtros existentes no sistema. Além disso, em apps com um grande número de filtros, é muito fácil fazer a organização desses métodos em módulos que podem ser incluídos na classe PermittedParams.

Eu costumava usar o localtunnel pelo fato de ser gratuito, mas ele é muito lento. E pagar por um serviço desse tipo, onde só preciso expor serviços exporadicamente não faz muito sentido. Além disso, no caso do localtunnel pelo menos, se sua conexão cai, você receberá um novo endereço ao se reconectar. Isto nem sempre é um problema, mas às vezes é preciso configurar o serviço que está testando com esta nova URL (como é o caso do PagSeguro), o que não é nada prático.

Existe uma maneira muito simples de fazer isso usando SSH e um servidor web. E como uso o servidor do Simples Ideias como um playground, vou mostrar como foi simples fazer isso usando NGINX.

Depois de ter instalado o NGINX, você só precisa criar um novo arquivo de configuração de host, como no exemplo abaixo.

upstream tunnel {
  server 127.0.0.1:3000;
  server 127.0.0.1:1234;
  server 127.0.0.1:9292;
  server 127.0.0.1:4567;
}

server {
  listen 80;
  server_name dev.simplesideias.com.br *.dev.simplesideias.com.br;
  client_max_body_size  10M;

  location / {
    proxy_set_header  X-Real-IP  $remote_addr;
    proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_redirect off;

    proxy_pass http://tunnel;
  }
}

A primeira coisa que você deve notar é que estou usando um bloco upstream, que permite definir os servidores que o NGINX usará para responder à requisição (na prática, você irá configurar o NGINX como um load balancer). Neste caso, adicionei as portas que normalmente uso para Rails, Node.js, Rack e Sinatra.

Outra coisa que você deve notar é que este servidor responderá a qualquer requisição no subdomínio *.dev.simplesideias.com.br. Isso é muito interessante se você também precisa testar apps que usam subdomínios. Para configurar o seu servidor de DNS, basta criar um registro ALIAS (registro próprio da DNSimple) como o abaixo.

Após reiniciar o servidor, você já poderá redirecionar a porta local de sua máquina para este servidor remoto. Imagine que eu queira redirecionar a porta 3000 do Rails. Neste caso, basta executar o comando abaixo na máquina local:

ssh simplesideias.com.br -R 3000:localhost:3000

Este comando diz que vou redirecionar a porta localhost:3000 para a porta 3000 do servidor simplesideias.com.br. Note que neste caso não é preciso ter nenhuma permissão especial, já que a porta é maior que 1024.

Simples, e funciona que é uma maravilha! ;)

A classe OpenStruct permite criar uma estrutura de dados com atributos que podem ser definidos de forma arbitrária. Além disso, se você passar um Hash durante a instanciação, cada uma das chaves irá gerar um atributo equivalente.

require "ostruct"

user = OpenStruct.new({
  :name => "John Doe",
  :email => "john@example.org"
})

puts user.name
#=> John Doe

puts user.email
#=> john@example.org

Você também pode atributir valores livremente, como o exemplo abaixo.

user.age = 42
puts user.age
#=> 42

Em versões anteriores, você só podia acessar os atributos de uma instância da OpenStruct através dos métodos readers. No entanto, o Ruby 2.0 introduziu alguns métodos muito úteis.

puts user[:name]
#=> John Doe

puts user["name"]
#=> John Doe

Você também pode usar o método OpenStruct#[]= para definir atributos.

user["name"] = "John D."
puts user.name
#=> John D.

Um outro método que foi adicionado permite retornar uma representação da OpenStruct como Hash. Trata-se do método OpenStruct#to_h. No Ruby 1.9 este método retornava nil.

p user.to_h
#=> {:name=>"John Doe", :email=>"john@example.org", :age=>42}

E, finalmente, uma mudança muito útil está relacionada ao método OpenStruct.new, que agora aceita instâncias das classes OpenStruct e Struct.

another_user = OpenStruct.new(user)

p another_user.to_h
#=> {:name=>"John Doe", :email=>"john@example.org", :age=>42}

Para quem gosta muito da classe HashWithIndifferentAccess, disponível na biblioteca ActiveSupport, esta mudança é particularmente empolgante.

Para você ter uma ideia, a API do Codeplane (que é o meu projeto atual), tem os seguintes tempos de execução:

$ time rspec
Finished in 7.37 seconds
357 examples, 0 failures

real  0m21.159s
user  0m11.233s
sys 0m3.444s

Veja o tempo de execução apenas dos modelos (persistência com ActiveRecord e outras classes):

$ time rspec spec/models/
Finished in 2.11 seconds
165 examples, 0 failures

real  0m4.023s
user  0m2.816s
sys 0m0.536s

E, por fim, todos os testes que não precisam do Rails:

$ time rspec spec/{extensions,middlewares,models,rack,services,workers}
Finished in 2.46 seconds
237 examples, 0 failures

real  0m4.531s
user  0m3.080s
sys 0m0.664s

Nada mal. Neste artigo você poderá ver um pouco das coisas que faço para ter tempos como estes.

Evite adicionar dependências

Dependência tem esse nome e não é por acaso. Pense duas vezes se você realmente precisa de todas aquelas gems que você está adicionando. Às vezes, algumas poucas linhas de código já podem resolver a coisa toda.

O boot do Rails não é lento. Um aplicativo novo, apenas com as dependências padrão, é executado em menos de 1.5s.

$ time rails runner ''

real  0m1.316s
user  0m1.164s
sys 0m0.148s

O stack padrão tem 40 gems de dependência (uma das linhas é apenas uma descrição), como você pode ver abaixo:

$ bundle show | wc -l
41

A API do Codeplane tem um tempo de boot três vezes maior, com quase o dobro de dependências.

$ time rails runner ''

real  0m3.850s
user  0m2.732s
sys 0m0.468s

$ bundle show | wc -l
76

Todas as bibliotecas que você adicionar ao seu projeto precisarão ser carregadas de alguma forma. No caso do Bundler, a menos que você seja específico quanto a isso, elas serão carregadas no momento do boot, e cada dependência que você adicionar, irá aumentar o seu tempo. Por isso, conforme nossa aplicação vai crescendo, temos a sensação de que o Rails é lento.

Nem sempre conseguimos evitar uma nova dependência. Uma coisa que você pode fazer, sempre que possível, é postergar o carregamento da biblioteca no lugar onde ela será usada. Imagine que eu queira usar a gem permalink. Esta gem, que é específica para o ActiveRecord, pode ser carregada no arquivo que irá usá-la. Primeiro, certifique-se de adicionar a opção :require => false no arquivo Gemfile. Depois, carregue-a no arquivo do modelo.

require "permalink"

class Post < ActiveRecord::Base
  permalink
end

Isole seus testes

Você nem sempre precisa do Rails. Para ser mais específico, os únicos testes que devem depender do Rails são os de integração (no caso do RSpec, são aqueles testes full-stack, com requisições HTTP). Todos os outros podem (e devem) ser isolados. Só assim você conseguirá executá-los mais rapidamente.

Mas para que isso seja possível, você precisará fazer algumas coisas. Primeiro, evite fazer muitas coisas no controller, porque aí você não precisará carregar o Rails para começo de conversa. A minha linha de raciocínio é bastante simples:

• Se eu vou apenas fazer uma consulta no ActiveRecord, por exemplo, eu faço diretamente no controller (obviamente, consultas complexas devem ser abstraídas em métodos no próprio modelo e/ou classes auxiliares).
• Se eu precisar fazer qualquer tarefa adicional como enviar um e-mail ou executar alguma coisa no background, crio uma classe que fará isso.

A primeira regra é aplicada no exemplo abaixo, onde apenas pego uma lista de repositórios de um dado usuário:

class ReposController < ApplicationController
  def index
    @repos = current_user.repos
    respond_with @repos
  end
end

No caso de um cadastro de usuário, onde um e-mail precisará ser enviado (assincronamente), eu teria que aplicar a segunda regra, como no exemplo abaixo:

class UsersController < ApplicationController
  def new
    @user = User.new
  end

  def create
    @user = User.create(params[:user])
    Signup.process(@user)

    respond_with @user, :location => login_path
  end
end

A classe Signup é responsável por adicionar o job que será executado assincronamente. Isso é importante, pois agora você consegue escrever testes específicos para a classe Signup, sem precisar bater, necessariamente, no controller ou mesmo no Rails.

Uma implementação possível dessa classe pode ser vista abaixo:

class Signup
  def self.process(user)
    new(user).process
  end

  def initialize(user)
    @user = user
  end

  def mailer_worker
    MailerWorker
  end

  def process
    return if @user.errors.any?

    mailer_worker.enqueue(
      :name => @user.name,
      :email => @user.email,
      :mail => :welcome
    )
  end
end

Isso introduz o conceito de PORO (Plain-Old Ruby Object), ou seja, uma classe pura de Ruby que serve como um serviço. Perceba que a minha dependência está definida no método Signup#mailer_worker, em vez de passar como um parâmetro para o método Signup#process. Prefiro fazer desta forma porque acho mais clara.

E quanto aos testes?

require "./app/models/signup"

describe Signup do
  describe "#mailer_worker" do
    let(:worker) { mock("MailerWorker") }

    it "returns MailerWorker" do
      stub_const "MailerWorker", worker
      expect(Signup.new(nil).mailer_worker).to eql(worker)
    end
  end

  describe "#process" do
    let(:worker) { mock("MailerWorker") }
    let(:user) { mock("user") }

    before do
      Signup.any_instance.stub :mailer_worker => worker
    end

    context "when user is valid" do
      before do
        user.stub({
          :errors => [],
          :name => "NAME",
          :email => "EMAIL"
        })
      end

      it "enqueues e-mail" do
        worker
          .should_receive(:enqueue)
          .with({
            :name => "NAME",
            :email => "EMAIL",
            :mail => :welcome
          })

        Signup.new(user).process
      end
    end

    context "when user is invalid" do
      before do
        user.stub :errors => ["ERROR"]
      end

      it "does not enqueue e-mail" do
        worker.should_not_receive(:enqueue)
        Signup.new(user).process
      end
    end
  end
end

Muita gente não gosta dessa abordagem com mocks e stubs. Particularmente, não vejo problemas, já que sempre tenho testes de integração que irão garantir o funcionamento desta classe no seu uso real e integrado ao sistema.

Perceba que não estou carregando o arquivo "spec_helper.rb", como fazemos normalmente. Isso porque, neste exemplo, não precisamos de nada do Rails. Então, não faz o menor sentido você carregar o Rails inteiro apenas para rodar estes testes. Veja como eles rodam muito rápido:

$ time rspec signup_spec.rb
...

Finished in 0.00727 seconds
3 examples, 0 failures

real  0m0.259s
user  0m0.196s
sys 0m0.024s

Claro que nem sempre é possível fugir do Rails. Será? Executar testes do ActiveRecord normalmente exigiriam coisas do Rails, mas podemos isolar o carregamento somente das dependências do ActiveRecord em um arquivo diferente do "spec_helper.rb".

Primeiro crie um arquivo "spec/spec_helper_active_record.rb". Este arquivo irá carregar o Bundler e definir o escopo de dependências, mas não irá carregar as bibliotecas automaticamente. No exemplo abaixo irei carregar o ActiveRecord, FactoryGirl, FactoryGirl Preload, o matcher have(n).errors_on, presente no rspec-rails, além de fazer a conexão com o banco de dados.

require "bundler"
Bundler.setup(:default, :test)

require "active_record"

require "rspec/matchers"
require "rspec/rails/extensions/active_record/base"
require "rspec/rails/matchers/have_extension"

require "factory_girl"
require "factory_girl/preload"
require "factory_girl/preload/rspec2"

connection_info = YAML.load_file("config/database.yml")["test"]
ActiveRecord::Base.establish_connection(connection_info)

Todas as gems específicas do ActiveRecord que você usa devem ser carregadas neste arquivo também.

Agora, no arquivo de testes do seu modelo, você irá carregar este arquivo e o modelo que você quer testar. Veja, por exemplo, como seria para testar as validações de um modelo User.

require "spec_helper_active_record"
require "./app/models/user"

describe User do
  context "validations" do
    it "requires name" do
      user = User.create(:name => nil)
      expect(user).to have(1).error_on(:name)
    end
  end
end

Com esta alteração, eu consegui reduzir o tempo de execução do diretório "spec/models" consideravelmente:

$ time rspec spec/models/
147 examples, 0 failures

# Antes da alteração
real0m11.537s
user0m6.652s
sys0m1.740s

# Depois da alteração
real0m3.688s
user0m2.672s
sys0m0.452s

E por falar em ActiveRecord, aqui vão mais algumas dicas.

• Evite criar registros quando você não precisa. Muitas vezes instanciar o modelo já é suficiente. Se for realmente necessário criar estes registros, não crie mais do que precisa.
• Sempre que puder, utilize fixtures ou algo equivalente. Eu sempre adiciono a minha gem factory_girl-preload, e defino alguns registros que uso em todos os lugares (como uma instância da classe User).
• Esqueça a ideia de Fat Model literal (um único modelo, inchado de métodos não relacionados). Você pode delegar regras de negócio para classes separadas e apenas criar métodos de conveniência, quando necessário (e quando fizer sentido).
• Fuja dos callbacks do ActiveRecord, principalmente para realizar tarefas que não são relativas ao modelo (enviar e-mail, por exemplo, com o after_create).

Finalizando

Testes rápidos não deve ser o seu objetivo final. Isso é apenas uma consequência de ter um código bem escrito, seguindo as boas práticas de desenvolvimento de software (piada que alguns amigos irão entender).

Ouça sempre o que o seus testes estão dizendo. Se está muito difícil de testar, provavelmente sua classe/método está fazendo mais coisas do que deveria.