Que mal tem o Twitter trocar de Ruby para Scala (ou whatever)?

Isso vai te afetar? Só se você trabalha no Twitter e não sabe programar em nada além de Ruby e está com preguiça de aprender alguma coisa nova, o que é uma vergonha se você tem a oportunidade. Bom, eu não trabalho no Twitter, e acredito que muita gente que está lendo isso também não, então qual é problema? Precisa de todo esse auê?

“Ah, mas isso pode queimar o filme da linguagem, dizendo que ela não escala, não aguenta o tranco, consome muitos recursos blá blá blá”. Ok, vamos lá.

Quem programa na linguagem (ou em qualquer outra) e gosta do que ela faz e dos seus recursos não precisa se preocupar em “queimação de filme”. Isso é coisa de modinha. Talvez só se precisar entrar em um processo de convencimento da linguagem e/ou tecnologia para o chefe, que pode ser aquele tipo que toca toda a TI da empresa baseado em folders que recebe pelo Correio (sim, esse pessoal investe em papel bem bonito, nada de email), por muita grana e por notícias que ele vê em sites especializados. E talvez essa notícia nem saia lá, então fique tranquilo.

Só fica “noiado” quem investe muito em uma “aura santa” da dita cuja e pode perder dinheiro e status (ah, esse talvez mande até mais do que o primeiro) se ela deixar de ser “cool”, de ficar em evidência, se carregar o mínimo arranhão sobre o que alguém disse sobre ela. Aí se cria todo esse auê, onde o marketing excessivo acaba saturando e remendando a situação. Afinal, mesmo que não se chegue à uma conclusão o ruído foi criado e pode ser utilizado para disfarçar a coisa. Você não vai querer ser superficial desse jeito, vai? Olhe o que aconteceu com toda a aura que o Java tinha nos últimos anos. Na AURA, eu disse, não na tecnologia!

Vejam bem, eu escrevi um livro sobre a linguagem e fico divulgando ela por aí, mas NUNCA vou fazer um barulho desses se alguém disser “migrei de Ruby pra XYZ” (ok, eu posso ficar inconformado se você for para ASP ou coisa do tipo, mas aí a discussão é, além de técnica, filosófica, e é outra história) e não vejo necessidade de ficar provando que ela é melhor que as outras. Putz, parece que xingam a mãe quando dizem que vão fazer uma migração, quando dizem que não gostam da linguagem ou que ela tem as suas limitações. TODA linguagem tem suas limitações, qual é o problema?

Apesar de ser grande utilizador e, por que não, “evangelizador” da linguagem, eu prefiro, antes de mais nada, ser honesto com quem lê minhas opiniões. Tomara que não chegue o dia em que eu fique sem grana e precise ser pago para dizer “ei, isso é legal”, mesmo que a coisa seja uma porcaria. A gente tem visto isso acontecer muito ultimamente, e é algo bem ruim. E eu uso a linguagem sim por achar ela muito boa, não porque quero parecer o gostosão da cocada preta de Ruby. Quem me acompanha pode ver que sou bem sossegado em termos de marketing.

Acredito que, se você gosta da linguagem, está se divertindo fazendo com gosto os seus programas nela, não deve ligar para umas notícias dessas. Se a gente ligasse tanto para o que os outros fazem e falam não teríamos um monte de coisas legais que temos por aí.

Agora, você está começando agora a usar Rails, ou está estudando a linguagem, ou pretende migrar a sua aplicação de XYZ para Rails e está preocupado porque o Twitter migrou, sendo que a sua aplicação pode consumir 1/1000 dos recursos que a deles consome??? Benza Deus, hein!!! Se for desistir fácil assim, melhor comprar a revista mais cara que tem na banca de gerentes e escolher a tecnologia mais cara e talvez, mais obscura, onde você nunca precise escutar nada que possa deixar ela menos “cool”.

Fonte: Imasters

Continuando com os tipos básicos de Ruby (no artigo anterior já falamos de Arrays e Hashes):

Strings

Novamente, nada de muito surpreendente aqui:

>> palavra = "bla bla"
=> "bla bla"
>> palavra.size
=> 7

A operação mais comum em string é a concatenação:

>> nome = "Diego"
=> "Diego"
>> sobrenome = "Moreira"
=> "Moreira"
>> nome + " " + sobrenome
=> "Diego Moreira"

Porém, já vimos em seções anteriores outra maneira
de fazer a mesma concatenação:

>> "#{nome} #{sobrenome}"
=> "Diego Moreira"

Tudo que estiver dentro de “#{}” é executado e o resultado convertido
em String e concatenado junto com o resto. Isso deve evitar aquele
monte de “+” o tempo todo quando queremos concatenar as coisas. Um dos
lugares onde mais usamos concatenação é quando queremos strings com
quebras de linha. O jeito comum é fazer assim:

>> nome = "F"
=> "F"
>> query = "SELECT * FROM NOMES \n" +
?>     "WHERE NOME LIKE '%" + nome + "%' \n" +
?>     "ORDER BY NOME"
=> "SELECT * FROM NOMES \nWHERE NOME LIKE '%F%' \nORDER BY NOME"

Ou algo parecido com isso, o que é bem feio e sabemos o quanto isso se
torna impossível de dar manutenção no futuro. Mas em Ruby podemos fazer
um pouco melhor que isso:

>> nome = "F"
=> "F"
>> query = <<-STR
  SELECT * FROM NOMES
  WHERE NOME LIKE '%#{nome}%'
  ORDER BY NOME
STR
=> "  SELECT * FROM NOMES\n  WHERE NOME LIKE '%F%'\n  ORDER BY NOME\n"

Onde está “STR” na realidade pode ser
qualquer palavra em letras maiúsculas, tomando o cuidado para não ter
espaços em branco nem antes nem depois do “STR” da última linha. 

>> nome = "F"
=> "F"
>> query = %{SELECT * FROM NOMES
  WHERE NOME LIKE '%#{nome}%'
  ORDER BY NOME}
=> "SELECT * FROM NOMES\n  WHERE NOME LIKE '%F%'\n  ORDER BY NOME"

E também desta maneira:

>> nome = "F"
=> "F"
>> query = %Q(SELECT * FROM NOMES
  WHERE NOME LIKE '%#{nome}%'
  ORDER BY NOME)
=> "SELECT * FROM NOMES\n  WHERE NOME LIKE '%F%'\n  ORDER BY NOME"

Todas as maneiras acima são jeitos de se criar strings de múltiplas
linhas com a possibilidade de execução e substituição in-place usando
“#{}”. Eu particularmente prefiro fazer alguma coisa do tipo:

>> nome = "F"
=> "F"
>> query = %q(SELECT * FROM NOMES
  WHERE NOME LIKE '%[nome]%'
  ORDER BY NOME)
=> "SELECT * FROM NOMES\n  WHERE NOME LIKE '%[nome]%'\n  ORDER BY NOME"

>> query.gsub!('[nome]', nome)
=> "SELECT * FROM NOMES\n  WHERE NOME LIKE '%F%'\n  ORDER BY NOME"

A sintaxe de “%q()” também permite criar strings de múltiplas linhas mas não suporta a execução de código via “#{}”, por isso coloquei algo que possa encontrar depois (um “placeholder”) como “[nome]” e no final uso o método “gsub” que faz substituição em Strings. Eu disse que “prefiro” mais para separar explicitamente as substituições fora do String. Mas, novamente, existem diversas maneiras de realizar essa mesma tarefa, depende do que você precisa fazer.

Disclaimer: nunca crie consultas SQL da forma como mostrei acima. Se você apenas concatenar o valor que foi passado pelo usuário diretamente no comando SQL que vai executar, seu código estará automaticamente vulnerável à SQL Injection. Esse é o erro mais comum que todo desenvolvedor Web novato comete. Então cuidado! Para isso servem pacotes como ActiveRecord, que abstraem o SQL nativo e realizam as checagens mais comuns antes de criar o SQL.

Symbols

Note que na seção sobre Hashes, criamos um pequeno dicionário ligando uma palavra em inglês à sua tradução em português. Para isso usamos objetos String tanto para os valores quanto para as chaves, por exemplo:

dic1 = { "leg" => "perna" }

Mas você vai notar que em Ruby e principalmente no Rails, não costumamos
usar Strings como chaves.
Em vez disso usamos Symbols:

dic2 = { :leg => "perna" }

Quero dizer, não é proibido usar Strings, mas se não precisar, prefira usar Symbols. Existem dois motivos para isso: o primeiro é porque symbols são mais legíveis e fáceis de visualizar, a segunda é economia de memória.

Em poucas palavras, um Symbol sempre gera um objeto Singleton imutável. Por exemplo:

>> a = :leg
=> :leg
>> b = :leg
=> :leg
>> a.object_id
=> 531778
>> b.object_id
=> 531778

Note como atribuímos :leg às variáveis “a” e “b”. Chamando o método
“object_id”, ambas respondem o mesmo ID, denotando que as duas
variáveis estão apontando ao mesmo objeto Symbol. Vejamos o mesmo
exemplo usando Strings:

>> a = "leg"
=> "leg"
>> b = "leg"
=> "leg"
>> a.object_id
=> 11823830
>> b.object_id
=> 11820130

Note como os dois IDs vieram diferentes. Ou seja, apesar do conteúdo ser o mesmo, as variáveis “a” e “b” estão apontando para objetos String diferentes. A primeira impressão é que são o mesmo objeto, mas na realidade são dois objetos distintos que por acaso tem o mesmo conteúdo. Espero que tenha ficado claro porque Symbols consomem menos memória que Strings.

Existem vários outros objetos singleton em Ruby. Números é um deles, afinal não faz sentido existir mais de um número “1”. O mesmo vale para objetos booleanos. Por exemplo:

>> a = 1
=> 1
>> b = 1
=> 1
>> c = true
=> true
>> d = true
=> true

>> a.object_id == b.object_id
=> true
>> c.object_id == d.object_id
=> true
>> a = 1
=> 1
>> b = 1
=> 1
>> c = true
=> true
>> d = true
=> true

>> a.object_id == b.object_id
=> true
>> c.object_id == d.object_id
=> true

Na prática, sempre use Symbols como chaves de Hash. É onde eles são
mais usados. Em Ruby on Rails, o pacote ActiveSupport consegue traduzir
Hashes com chaves em String para Symbols, desta forma:

>> require 'rubygems'
=> []
>> require 'activesupport'
=> []
>> params = { "nome" => "Diego", "sobrenome" => "Moreira" }
=> {"nome"=>"Diego", "sobrenome"=>"Moreira"}
>> params.symbolize_keys!
=> {:nome=>"Diego", :sobrenome=>"Moreira"}
>> params[:nome]
=> "Diego"
>> params[:sobrenome]
=> "Moreira"

Métodos em Ruby

Depois de tudo isso, podemos ir um pouco além. Em Ruby temos maneiras muito diferentes de se escrever métodos. Em linguagens estáticas, como Java, temos o conceito de overloading. Por exemplo:

public class Pessoa {
  String nome;
  String email;

  public Pessoa(String nome, String email) {
    this.nome = nome;
    this.email = email;
  }

  public Pessoa(String nome) {
  this(nome, "");
  }
}

Esse trecho define a classe “Pessoa” com dois construtores.
Dessa forma podemos instanciar uma nova Pessoa da seguinte forma:

Pessoa diego = new Pessoa("Diego", "diego@foo.com.br");
Pessoa Moreira = new Pessoa("Moreira");

Ou seja, o parâmetro “email” é opcional. Dependendo se passamos ou não esse parâmetro, um dos dois construtores será chamado.

Porém, esse tipo de construção pode começar a ficar extremamente tedioso quando temos muitos parâmetros opcionais. Em Ruby temos algumas maneiras diferentes de lidar com isso. Para começar vejamos uma maneira simples:

class Pessoa
  def initialize(nome, email = "")
    @nome, @email = nome, email
  end
end

Duas novidades: primeiro que um método suporta valores padrão. Dessa forma, se nada for passado no segundo parâmetro, ele assume o padrão vazio “”, conforme descrevemos acima. Segundo, é possível fazer atribuição em massa. Acredito que esteja bastante óbvio entender apenas lendo o trecho acima.

Outra maneira:

class Pessoa
  def initialize(nome, *args)
    @nome = nome
    @args = args
  end
  def args
    @args
  end
end

>> diego = Pessoa.new("Diego", "diego@foo.com.br", "6666-6666")
=> #<Pessoa:0x26ee61c @args=["diego@foo.com.br", "6666-6666"], @nome="Diego">
>> diego.args.first
=> "diego@foo.com.br"
>> diego.args.last
=> "6666-6666"

O que temos no contrutor acima, o “*”, é o “splat”. Pense nele como um
buraco-negro: depois do parâmetro normal “nome”, tudo que vier depois
será literalmente sugado para dentro da variável “args”. A resultante
disso será um Array. Isso permite um método que tenha capacidade para
infinitos argumentos. Outro exemplo de uso é este:

def soma(*args)
  args.inject(0) { |elem, total| total += elem }
end

>> soma(2,2)
=> 4
>> soma(1,2,3,4)
=> 10
>> soma(100,200,300)
=> 600

Felizmente já explicamos para que serve o “inject”. Resumindo: esse método somará todos os elementos passados como parâmetros, independente de quantos forem. E ainda podemos fazer mais: passar um array expandindo seus elementos para serem parâmetros:

>> items = [1,2,3,4,5,6]
=> [1, 2, 3, 4, 5, 6]
>> soma *items
=> 21

Se passássemos o array “items” sem o splat para expandí-lo, o array
inteiro seria considerado um único elemento do array “args” dentro do
método, não dando o efeito esperado, veja:

>> soma items
TypeError: can't convert Fixnum into Array
  from (irb):31:in `+'
  from (irb):31:in `soma'
  from (irb):40:in `inject'
  from (irb):31:in `each'
  from (irb):31:in `inject'
  from (irb):31:in `soma'
  from (irb):40

Outra situação é quando temos métodos com um número muito grande de
parâmetros opcionais. No Ruby on Rails temos exemplos como este:

>> Person.find :first, :conditions => { :nome => "Diego" },   rder => :nome
=> SELECT * FROM "people" WHERE ("people"."nome" = 'Diego') ORDER BY nome LIMIT 1

Qualquer um que já tenha lidado com SQL sabe que montar consultas pode ser bastante complexo. Criar um único método que cuide disso numa linguagem estático é impossível. Se tentar criar um conjunto de métodos via overloading como vimos antes, também será um trabalho homérico e totalmente fútil.

Vejamos como é definido o método “find” da classe “ActiveRecord::Base”

def find(*args)
  options = args.extract_options!
  validate_find_options(options)
  set_readonly_option!(options)

  case args.first
    when :first then find_initial(options)
    when :last  then find_last(options)
    when :all   then find_every(options)
    else             find_from_ids(args, options)
  end
end

O método “find” por si só é somente um envelope que chama outros métodos. Ele recebe nada mais, nada menos que um Array, usando o splat como mostramos antes. Logo na primeira linha ele usa um método interno do Rails para extrair tudo que é considerado “options”, no caso, elementos de um Hash.

Dependendo do primeiro argumento, ele repassa o Hash a métodos como “find_initial”, “find_last”, etc. No caso, o Hash em questão é o seguinte:

options = { :conditions => { :nome => "Diego" },   rder => :nome }

Vejamos um exemplo mais simples de um método com um parâmetro
obrigatório e uma lista de parâmetros opcionais:

class Pessoa
  attr_accessor :primeiro_nome, :sobrenome, :iniciais, :email
  def initialize(primeiro_nome = "", options = {})
    @primeiro_nome = primeiro_nome
    @sobrenome = options[:sobrenome]
    @iniciais = options[:iniciais]
    @email = options[:email]
  end
end

>> diego = Pessoa.new("Diego", :sobrenome => "Moreira", :iniciais => "DM")
=> #<Pessoa:0x26b2c98 @iniciais="DM", @sobrenome="Moreira", @email=nil, @primeiro_nome="Diego">
>> diego.primeiro_nome
=> "Diego"
>> diego.sobrenome
=> "Moreira"
>> diego.iniciais
=> "DM"
>> diego.email
=> nil

Caso não saiba, o método “attr_accessor” serve para criar métodos
equivalentes a “getters” e “setters” de Java ou C#. Como já falamos em
seções anteriores, classes Ruby podem ser modificadas em tempo de
execução. Veremos isso depois, por enquanto vejamos o construtor
novamente. Depois do primeiro parâmetro, temos o familiar uso do par
chave e valor. O que pode parece estranho é que talvez alguém estivesse
esperando algo assim:

diego = Pessoa.new("Diego", {:sobrenome => "Moreira", :iniciais => "DM"})

Novamente, as chaves “{}” são opcionais: os últimos parâmetros, sendo
pares com a sintaxe de “rocket” (“=>”) são tratados como elementos
do mesmo Hash e todos são “sugados” para o parâmetro “options” no
método construtor. Retirando tudo que é opcional, a chamada poderia
ficar simplesmente assim:

diego = Pessoa.new "Diego", :sobrenome => "Moreira", :iniciais => "DM" 

E assim temos algumas maneiras para criar métodos bastante flexíveis.
Obviamente, aqui cabe cuidados sobre como planejar seus métodos. Fica
muito fácil criar métodos que fazem mais do que deveriam dessa forma.
Assim como mostramos acima com o método “find” tente criar métodos
enxutos, que delegam a execução a outros métodos mais especializados,
por exemplo.

Métodos Dinâmicos

Vejamos mais sobre o método “attr_accessor”:

class Pessoa
  attr_accessor :nome, :email
end

>> diego = Pessoa.new
=> #<Pessoa:0x26a6f24 @iniciais=nil, @sobrenome=nil, @email=nil, @primeiro_nome="">
>> diego.nome = "Diego"
=> "Diego"
>> diego.nome
=> "Diego"

Podemos reimplementar nossa própria versão simplificada de “attr_accessor” desta maneira:

class Object
  def my_accessor( *symbols )
    symbols.each do |symbol|
      module_eval( "def #{symbol}() @#{symbol}; end" )
      module_eval( "def #{symbol}=(val) @#{symbol} = val; end" )
    end
  end
end

class Pessoa
  my_accessor :telefone
end

>> diego = Pessoa.new
=> #<Pessoa:0x2690f30 @iniciais=nil, @sobrenome=nil, @email=nil, @primeiro_nome="">
>> diego.telefone = "6666-6666"
=> "6666-6666"
>> diego.telefone
=> "6666-6666"

Abrindo a classe Object significa que nosso método “my_accessor” estará
disponível a qualquer classe do Ruby, já que todos herdam de Object.
Esse método recebe um array de symbols, como já descrevemos antes. Daí
usamos “each” para iterar symbol a symbol, e para cada um chamamos
“module_eval” que simplesmente executa qualquer String passado a ele,
no caso criamos dinamicamente dois métodos, os equivalente a “getter” e
“setter”. Para o exemplo :telefone, seria o mesmo que escrevêssemos:

class Pessoa
  def telefone() @telefone; end
  def telefone=(val) @telefone = val; end
end

Muita gente confunde “meta-programação” com “reflexão”. Reflexão é
apenas perguntar a um objeto o que ele responde. Podemos fazer isso em
Ruby de várias maneiras:

>> a = "string"
=> "string"
>> a.methods
=> ["chop!", "constantize", ... "squish", "<<"]
>> a.respond_to? :size

>> p = Pessoa.new
=> #<Pessoa:0x261af60 @iniciais=nil, @sobrenome=nil, @email=nil, @primeiro_nome="">
>> p.telefone
=> nil
>> p.instance_variable_set("@telefone", "3333-4444")
=> "3333-4444"
>> p.instance_variable_get("@telefone")
=> "3333-4444"

Aqui vemos como todo objeto Ruby tem um método chamado “methods” que devolve um Array listando todos os métodos que ele responde. Além disso todo objeto Ruby ainda responde ao método “respond_to?” que recebe um symbol como parâmetro e responde se esse objeto responde a essa mensagem.

No exemplo seguinte, com a classe “Pessoa”, podemos ainda manipular diretamente a variável de instância “@telefone” sem sequer precisar de métodos acessores.

Como podemos ver, Reflexão em Ruby é trivial. Já vimos antes como funciona o método “send” para enviar mensagens arbitrárias e também como implementar o método “method_missing” para fazer um objeto responder a mensagens arbitrárias. Mas com exemplos como do “attr_accessor” podemos entender como manipular o comportamento de um objeto em tempo de execução.

Por isso dizemos que Ruby tem capacidades muito poderosas de meta-programação, que é o que o torna particularmente prazeroso de usar, sem precisar contar com sintaxes obscuras ou truques não documentados. Pensar em meta-programação faz parte do dia-a-dia de programação com Ruby.

Indo além do Nulo

Como mais um exemplo da flexibilidade do Ruby, vamos analisar o bom o velho “nulo”. Note que nulo é realmente nada. Não é o mesmo que zero. Não é o mesmo que uma string vazia.

Em Ruby, estamos falando do ‘nil’. Porém, como quase tudo em Ruby é um objeto, assim também é ‘nil’:

>> nil
=> nil
>> nil.class
=> NilClass
>> nil.object_id
=> 4

Ou seja, quando um método não devolve nada, ou seja, ‘nil’, ainda assim ele está devolvendo alguma coisa: a instância singleton da classe NilClass.

Não é difícil cair em situações onde queremos chamar um método em um objeto onde ainda não sabemos se o objeto é nil ou não. Por isso costumamos fazer algo assim:

unless obj.nil?
  obj.say_hello
else
  nil
end

Aqui eu propositadamente fiz um código mais longo do que deveria,
apenas para aproveitar e demonstrar o “unless”. Pense nele como o
oposto de “if”. Em outras linguagens estamos acostumados a fazer algo
assim:

if !obj.nil? ...

Ou seja, “se não for …”. Mas em vez disso, em Ruby preferimos dizer “a
menos que …”. Fica menos poluído do que colocar “!” ("not") o tempo
todo. Além disso chamamos o método “nil?” que checa se o objeto atual é
nulo ou não. Esse método “nil?” está presente direto da classe pai
“Object”, portanto todos os objetos no Ruby respondem a esse método, em
particular, como “nil” também é um objeto, ele também responde a esse
método:

>> nil.nil?
=> true
>> 1.nil?
=> false

E eu disse que o código acima era mais longo do que o necessário porque
sempre podemos usar o operador ternário (que também existe em outras
linguagens):

obj ? obj.say_hello : nil

Ou seja, se “obj” devolver “true” (apenas “false” e “nil” respondem como “false” em condicionais), então chame o método “say_hello”, caso contrário, devolva ‘nil’.

Como em qualquer objeto, se tentarmos chamar um método em ‘nil’ que não existe, ele responderá normalmente com uma exceção:

>> nil.size
NoMethodError: undefined method `size' for nil:NilClass
  from (irb):91

Um outro truque que discutiu-se algum tempo atrás é criar um novo método em Object chamado “try”:

class Object
  def try(metodo, *args)
    send(metodo, *args) if respond_to? metodo
  end
end

>> "".try(:size)
=> 0
>> nil.try(:size)
=> nil

Em vez de chamar um método diretamente quando ainda não sabemos se o objeto é nil ou não, podemos chamar o método “try” passando a mensagem (o nome do método) e seus parâmetros. Se o objeto para onde enviamos a mensagem souber responder essa mensagem (respond_to?), então repassamos normalmente, senão devolvemos nil.

Recomendo que teste todos esses exemplos no IRB para entender o comportamento. Esse tipo de pensamento é crucial na programação Ruby. Não quer dizer, claro, que agora devemos usar coisas como “try” o tempo todo, mas nas situações onde são necessárias, essa pode ser a diferença entre um código extremamente enxuto e expressivo do que um código burocrático e difícil de entender.

Conclusão

Até aqui mostramos apenas a ponta do iceberg da programação com Ruby. Existem dezenas de classes que já vêm na biblioteca padrão do Ruby que vocês precisam saber, como Net, File, FileUtils e muitos outros. Use o site ApiDock sempre que tiver dúvidas quanto à sintaxe de algum método. Lembre-se da questão de parâmetros dinâmicos, o que dificulta a documentação automática. Mas também lembre-se que o código-fonte de bibliotecas Ruby costumam ser muito simples de ler. Portanto recomendo muito que, na dúvida, procure o código-fonte (que já está na sua máquina) e tente ler direto na fonte.

E para ver alguns exemplos muito interessantes de resolução de problemas em Ruby, também recomendo ler o site Ruby Quiz que contém uma biblioteca enorme de pequenos problemas simples com soluções muito criativas usando os recursos de Ruby.

O mais importante: não tente escrever Ruby da mesma forma como se escreve Java ou C#. “Quando se está em Roma, faça como os romanos.” Portanto, nada de usar “camelCasing” para nomear seus métodos, por exemplo, use “metodos_separados_por_underscore”. Escreva Ruby da forma Ruby.

Com base nesse resultado positivo, resolvi compartilhar aqui a minha experiência fazendo uma pequena explicação sobre como integrar o Searchlogic ao seu site.

Passo 1: Instalação do Searchlogic: Você pode fazer a instalação usando o RubyGems ou instalando com um plugin dentro do seu projeto.

Instalação como gem:

sudo gem install searchlogic

# e depois adicione ao config/environment.rb
config.gem "searchlogic" 

Instalação como plugin:

script/plugin install git://github.com/binarylogic/searchlogic.git

Passo 2: Faça a busca! É isso mesmo, já está “tudo no jeito” para você fazer a sua busca. Uma busca simples seria:

@search = Model.new_search( params[:q] )
@items, @items_count = @search.all, @search.count

O que esse código faz é buscar registros a partir do seu modelo (Model no exemplo) e colocar o resultado em duas variáveis: uma com a coleção de registros e outra com a quantidade retornada. Mais fácil impossível.

Passo 3: Personalizando sua busca: se você quiser, e você provavelmente quer, você pode especificar quais campos devem ser pesquisados ou quais as condições devem ser atendidas. Tudo isso é muito simples de ser feito e pode ser definido de duas formas: você pode usar um hash com as opções e condições (similar ao que fazemos com o tradicional find) ou uma abordagem mais orientada a objetos. Exemplos simulando uma busca de carros:

Passando um hash:

Car.all(
  :conditions => {
    :name_contains => 'ford', # name like '%ford%'
  },
  :per_page => 10
  :page => params[:page],
    rder_by => 'year',
    rder_as => 'DESC',
)

Ou como um objeto:

search = Car.new_search
search.conditions.name_contains = 'ford'
search.per_page = 10
search.page = params[:page]
search.order_by = 'year'
search.order_as = 'DESC'
search.all # execute

Simples não? E isso é só o começo, na documentação do projeto há muitos outros exemplos e possibilidades!

Métodos vs Mensagens

Na seção anterior vimos como podemos organizar nosso código em módulos e durante os exemplos usamos um método estranho, o “send”. Vamos ver para que ele serve de fato.

Outra noção que precisamos mudar aqui: “nós chamamos métodos dos objetos.” Em orientação a objetos, na realidade deveria ser “nós enviamos mensagens aos objetos.” Por exemplo:

>> "teste".hello
NoMethodError: undefined method `hello' for "teste":String
  from (irb):1

O pensamento comum seria: “tentamos chamar o método ‘hello’ que não existe em String.” Mas devemos pensar assim: “tentamos enviar a mensagem ‘hello’ ao objeto e sua resposta padrão é que ele não sabe responder a essa mensagem.”

Podemos reescrever o mesmo comportamento acima da seguinte forma:

>> "teste".send(:hello)
NoMethodError: undefined method `hello' for "teste":String
  from (irb):22:in `send'
  from (irb):22

Outro exemplo de ‘envio de mensagens’:

>> "teste".diga("Fabio")
NoMethodError: undefined method `diga' for "teste":String
  from (irb):24
  
>> "teste".send(:diga, "Fabio")
NoMethodError: undefined method `diga' for "teste":String
  from (irb):25:in `send'
  from (irb):25

Está entendendo o padrão? O equivalente a ‘chamar um método’ é como se estivéssemos chamando o método ‘send’ onde o primeiro parâmetro é o ‘nome do método’ e a seguir uma lista (de tamanho arbitrário) de parâmetros. Numa linguagem tradicional, uma vez que a classe é definida, o contrato está fechado. Mas como vimos antes, em Ruby, nada é fechado. No caso, tentamos enviar uma mensagem chamada :diga e :hello que o String “teste” não sabe como responder. A resposta padrão é enviar uma exceção ‘NoMethodError’ indicando o erro.

Podemos resolver esse problema de duas formas: 1) reabrindo a classe String e definindo um método chamado ‘hello’ ou ‘diga’ ou 2) fazer com que a String receba qualquer mensagem, independente se existe um método para responder a ela ou não.

Nesse segundo caso, poderíamos fazer o seguinte:

class String
  def method_missing(metodo, *args)
    puts "Nao conheco o metodo #{metodo}. Os argumentos foram:"
    args.each { |arg| puts arg }
  end
end

Antes de explicar, vejamos agora como o String “teste” vai se comportar:

>> "teste".hello
Nao conheco o metodo hello. Os argumentos foram:
=> []

>> "teste".diga("Fabio")
Nao conheco o metodo diga. Os argumentos foram:
Fabio
=> ["Fabio"]

>> "teste".blabla(1,2,3)
Nao conheco o metodo blabla. Os argumentos foram:
1
2
3
=> [1, 2, 3]

Se você pensar em “chamar métodos” o que estamos fazendo acima parece muito estranho pois estaríamos “chamando métodos que não existem”. Mas se mudar o ponto de vista para “enviar mensagens a objetos” agora temos “objetos que respondem a qualquer mensagem”.

Outra coisa que é meio polêmico são métodos privados. Em Ruby podemos fazer assim:

class Teste
  private
  def alo
     "alo"
  end
end

>> Teste.new.alo
NoMethodError: private method `alo' called for #<Teste:0x17d3b3c>
  from (irb):47

>> Teste.new.send(:alo)
=> "alo"

Essa classe ‘Foo’ tem um método privado (tudo que vem depois de ’private’). A primeira tentativa de chamar o método “alo” falha, obviamente, por ser um método privado. Mas a segunda tentativa, usando “send” é bem sucedido! Na realidade “private” serve para indicar que não deveríamos estar acessando determinado método, mas Ruby não nos força a não conseguir. Se nós realmente quisermos, temos que explicitamente usar “send”, mas aí nós estamos conscientemente fazendo algo que “não deveríamos”. Ruby não é paternalista: é feita para quem sabe o que está fazendo.

Por isso no artigo anterior usamos Pessoa.send(:include, MeusPatches), porque “include” é um método privado que só deveria ser usado dentro da própria classe. Mas esse “pattern” costuma funcionar.

Talvez o melhor exemplo para demonstrar esta funcionalidade dinâmica é mostrando o XML Builder. Primeiro, instale a gem:

gem install builder

Agora podemos usar no IRB:

>> require 'rubygems'
>> require 'builder'
=> false
>> x = Builder::XmlMarkup.new(:target => $stdout, :indent => 1)
<inspect/>
=> #<IO:0x12b7cc>
>> x.instruct!
<?xml version="1.0" encoding="UTF-8"?>
=> #<IO:0x12b7cc>
>> x.pessoa do |p|
?>     p.nome "Fabio Akita"
>>     p.email "fabioakita@gmail.com"
>>     p.telefones do |t|
?>       t.casa "6666-8888"
>>       t.trabalho "2222-3333"
>>     end
>>   end
<pessoa>
 <nome>Fabio Akita</nome>
 <email>fabioakita@gmail.com</email>
 <telefones>
  <casa>6666-8888</casa>
  <trabalho>2222-3333</trabalho>
 </telefones>
</pessoa>
=> #<IO:0x12b7cc>
Como podem ver, instanciamos a classe XmlMarkup na variável “x”. Daí
passamos a enviar mensagens como “pessoa” ou “email” e ele gera os tags
XML adequadamente. Muito diferente do que teríamos que fazer do jeito tradicional:

import org.w3c.dom.*;
import javax.xml.parsers.*; 
import javax.xml.transform.*; 

class CreateDomXml 
{
  public static void main(String[] args) 
  {
    try{
      DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
      DocumentBuilder docBuilder = factory.newDocumentBuilder();
      Document doc = docBuilder.newDocument();
      
      Element root = doc.createElement("pessoa");
      doc.appendChild(root);
      
      Element childElement = doc.createElement("nome");
      childElement.setValue("Fabio Akita");
      root.appendChild(childElement);
      
      childElement = doc.createElement("email");
      childElement.setValue("fabioakita@gmail.com");
      root.appendChild(childElement);
      .....
    } catch(Exception e) {
      System.out.println(e.getMessage());
    }
  }
}

Note que este código sequer está completo pois seria comprido demais para mostrar aqui. A idéia toda de usar os conceitos de meta-programação, de redefinição dinâmica de comportamento do objeto, é de permitir que você nunca precise fazer mais código do que realmente necessário. Na versão Ruby, temos no máximo a mesma quantidade de linhas que o XML resultante, graças à capacidade de ter um método ‘method_missing’ que consegue definir dinamicamente o que fazer com cada nova mensagem inesperada.

Higher Order Functions e Blocos

Vejamos o Design Pattern chamado Command:

interface Command {
  public void execute();
}

class Button {
  Command action;
  public void setCommand(Command action) {
    this.action = action;
  }
  public void click() {
    this.action.execute();  
  }
}

Button myButton = new Button();
myButton.setCommand(new Command() {
  public void execute() {
    System.out.println("Clicked!!");
  }
});

O que está acontecendo aqui é o seguinte: Criamos uma interface com um único método chamado ‘execute’. Daí criamos uma classe ‘Button’ onde podemos configurar que ação cada instância dele executará ao ser clicado. Essa ação é uma instância de um objeto que implementa Command. No final, criamos uma instância de Button e uma classe anônima (sem nome) com a implementação do método ‘execute’ para aquela instância.

Vejamos o mesmo exemplo do Design Pattern Command em Ruby (um dos vários jeitos de implementar):

class Button
  def initialize(&block)
    @block = block
  end
  def click
    @block.call
  end
end

my_button = Button.new { puts "Clicked!!" }
my_button.click

Primeiro, claro, bem mais curto, mas o mais importante: não precisamos encapsular uma ação como método de uma classe. Em linguagens tradicionais que não tem o conceito de “funções como cidadãos de primeira classe”, precisamos encapsular qualquer coisa em classes, mesmo que sejam classes anônimas.

No Ruby, temos o conceito de “código como objeto”. Na realidade encapsulamos o código diretamente em um objeto. No exemplo acima, o construtor ‘initialize’ captura qualquer bloco de código que passarmos a ele dentro da variável ‘block’ (para isso serve o “&”). Daí quando instanciamos o parâmetro que passamos entre chaves {} é o bloco de código capturado como objeto e associado à variável ‘block’.

A partir daí ele fica armazenado como uma variável de instância “@block” e no método ‘click’ podemos executar esse bloco de código enviando a mensagem ‘call’ (afinal, ele é um objeto e, portanto, responde a métodos).

Vejamos um exemplo mais simples:

>> def diga_algo(nome)
>>   yield(nome)
>> end
=> nil

>> diga_algo("Fabio") { |nome| puts "Hello, #{nome}" }
Hello, Fabio
=> nil

>> diga_algo("Akita") { |nome| puts "Hello, #{nome}" }
Hello, Akita
=> nil

Agora complicou: primeiro definimos um método chamado ‘diga_algo’ que recebe apenas um parâmetro. Dentro do método chamamos o comando especial ‘yield’, passando o parâmetro recebido a ele. Esse comando ‘yield’ executa qualquer bloco que foi passado como último parâmetro à chamada do método. É como se o método ‘diga_algo’ tivesse um segundo parâmetro implícito – digamos, ‘&b’ – e ‘yield(nome)’ fosse a mesma coisa que chamar ‘b.call(nome)’.

Preste atenção neste trecho:

{ |nome| puts "Hello, #{nome}" }

Pense nisso como se fosse uma função anônima: o que está entre pipes
“||” são parâmetros dessa função. O ‘yield’ irá executar esse bloco de
código. Por acaso, ele passará o parâmetro ‘nome’ para dentro do bloco
Vejamos outro exemplo:

>> soma = lambda { |a, b| a + b }
=> #<Proc:0x012d4898@(irb):46>
>> soma.call(1,2)
=> 3
>> soma.call(4,4)
=> 8

O comando ‘lambda’ serve para capturar o bloco de código numa instância da classe Proc. No exemplo, esse bloco aceita dois parâmetros, “a” e “b” e faz a soma deles. Depois podemos pegar o objeto ‘soma’ e chamar o método ‘call’ passando os dois parâmetros que ele requer.

No Ruby 1.8, um bloco também é uma Closure (“Fechamento”). Ou seja, o bloco de código engloba o ambiente ao seu redor, incluindo variáveis fora do bloco. Por exemplo:

>> def criar_bloco(nome)
>>   lambda { puts "Hello #{nome}"}
>> end
=> nil
>> 
?> fabio = criar_bloco("Fabio")
=> #<Proc:0x0124aae4@(irb):59>
>> akita = criar_bloco("Akita")
=> #<Proc:0x0124aae4@(irb):59>

O método ‘criar_bloco’ retorna um novo bloco de código. Note que o método recebe o parâmetro ‘nome’ e daí criamos o novo lambda usando esse ‘nome’ dentro dele. Finalmente chamamos o método duas vezes, criando dois lambdas diferentes, passando dois parâmetros diferentes a ‘nome’.

Agora vamos executar esses blocos:

>> fabio.call
Hello Fabio
=> nil

>> akita.call
Hello Akita
=> nil

>> fabio.call
Hello Fabio
=> nil

Veja que o bloco reteve o conteúdo do parâmetro ‘nome’ que foi passado como argumento ao método ‘criar_bloco’. Cada um dos blocos reteve o parâmetro, e como os configuramos com conteúdos diferentes, ao serem executados eles tem comportamentos diferentes. Esse conceito de Fechamento é um pouco complicado da primeira vez, por isso se você pelo menos entendeu que existem blocos e que eles são encapsulados em objetos anônimos que chamamos de lambdas, por enquanto é o suficiente.

Mas mais do que isso, você viu como métodos Ruby conseguem receber blocos de código e devolver blocos de código. É a isso que chamamos de Higher Order Functions, ou seja, uma ‘função’ (que chamamos de ‘bloco de código’) pode ser recebido ou repassado como se fosse uma variável qualquer. Isso é muito importante para categorizar Ruby como uma linguagem ‘inspirada em linguagens funcionais’, como Lisp. No caso, lambdas de Ruby não são livres de efeitos-colaterais, por isso ela não pode ser considerada puramente funcional. Mas isso já auxilia em muitas operações e é uma maneira bem mais eficiente inclusive de encapsular funcionalidades.

Vejamos outro exemplo de código para ler arquivos, começando por Java:

StringBuilder contents = new StringBuilder();
    
try {
  BufferedReader input =  new BufferedReader(
    new FileReader(aFile));
  try {
    String line = null; 
    while (( line = input.readLine()) != null){
      contents.append(line);
      contents.append(
        System.getProperty("line.separator"));
    }
  }
  finally {
    input.close();
  }
}
catch (IOException ex){
  ex.printStackTrace();
}

Algo parecido, de forma literal, em Ruby, ficaria assim:

contents = ""
begin
  input = File.open(aFile, "r")
  begin
    while line = input.gets
      contents << line
      contents << "\n"
    end
  ensure
    input.close
  end
rescue e
  puts e
end

Nada muito diferente, sequer em número de linhas. Porém, se considerarmos o caso de uso “abrir um arquivo e processar seu conteúdo”, todo esse código lida com o fato de abrir o arquivo, garantir que ele seja fechado, tratar exceções. O trecho específico de “processar o conteúdo” é nada mais do que as 4 linhas do bloco ‘while’. Podemos tornar isso mais Rubista criando um novo método ‘open’, que usa o recurso de ‘yield’ que mostramos acima.

Felizmente o Ruby já implementa o método ‘open’ da classe ‘File’ dessa forma, por isso podemos re-escrever o trecho de código acima assim:

contents = ""
File.open(aFile, "r") do |input|
  while line = input.gets
    contents << line
    contents << "\n"
  end
end
Um pouco melhor, bem mais encapsulado, expondo apenas o que é realmente
essencial ao que queremos fazer. Olhando para este trecho sabemos
exatamente que queremos abrir um arquivo e processar linha a linha de
seu conteúdo, armazenando o resultado na variável ‘contents’. Todo o
resto do encanamento está escondido dentro do método ‘open’.
Podemos passar apenas o bloco do ‘while’ como um lambda e ele será
executado no meio da implementação desse método. Se fôssemos
reimplementar o método ‘open’ da classe ‘File’ para agir dessa forma,
poderíamos fazer assim:

class File 
  def File.open(*args) 
    result = f = File.new(*args) 
    if block_given? 
      begin 
        result = yield f 
      ensure 
        f.close 
      end 
    end 
    return result 
  end 
end 

Aqui, simulamos a reabertura da classe ‘File’ e a reimplementação do método ‘open’. Note que primeiro checamos se foi passado um bloco (‘block_given?’) e daí usamos ‘yield’ para executar o lambda passado a ele, daí repassamos o arquivo ‘f’ recém-aberto. Quando seja lá o que ‘yield’ executar terminar, daí fechamos o arquivo e retornamos.

Aliás, é exatamente assim que os iteradores funcionam em Ruby. Um iterador serve para navegar pelos vários elementos de uma lista (ou outro objeto que se comporte como uma lista), sem se incomodar com os detalhes da implementação dessa lista (se é um array, uma lista ligada, uma sequência de bytes de um arquivo, etc).

Um pouco acima falei em reescrever de um jeito “um pouco mais Rubista”, mas vejamos um jeito mais Rubista ainda:

contents = File.open(aFile).readlines.inject("") do |buf, line| 
  buf += line
end

O método ‘readlines’ devolve um Array, onde cada elemento é uma linha do arquivo texto. O método “inject” é um Redutor: ele pega linha a linha do Array e repassa ao bloco, como primeiro parâmetro. O segundo parâmetro, ‘buf’, é um totalizador que é iniciado com o primeiro parâmetro que passamos no método ‘inject’, no caso a string vazia “”. Ele repassa sempre esse objeto como segundo parâmetro do bloco. Dentro do bloco podemos fazer o que quiser, mas normalmente queremos que seja um totalizador por isso usamos o operador “+=” que significa “buf = buf + line”.

Em Ruby é muito comum utilizar essa maneira de pensar: em vez de pensar em “como vamos iterar elemento a elemento”, partimos do princípio que isso é trivial e daí pensamos “como queremos filtrar elemento a elemento”. Linhas como a seguinte são bastante comuns:

>> [1,2,3,4,5].map { |elem| elem * elem }
=> [1, 4, 9, 16, 25]

>> [1,2,3,4,5].select { |elem| elem % 2 == 0 }
=> [2, 4]

>> [1,2,3,4,5].inject(0) { |total, elem| total += elem }
=> 15

>> total = 0
=> 0
>> [1,2,3,4,5].each { |elem| total += elem }
=> [1, 2, 3, 4, 5]
>> total
=> 15

O primeiro exemplo – “map” – substitui elemento a elemento pelo resultado do bloco. O segundo – “select” – devolve o resultado do filtro que é passado como bloco. O terceiro – “inject” – é o redutor que já vimos acima e o quarto – “each” – é a mesma coisa que o “inject” mas menos encapsulado e usando código extra para chegar ao mesmo efeito.

Para completar, blocos podem ser passados como parâmetro a um método usando duas sintaxes: chaves (“{}”) ou “do..end”, por exemplo:

[1,2,3,4].each { |elem| puts elem }

[1,2,3,4].each do |elem|
  puts elem
end
Ambas as formas acima fazem a mesma coisa. A diferença é que costumamos
usar chaves para blocos curtos, de uma única linha. Já o do..end é mais
usado quando temos múltiplas linhas. Em ambos os casos os parâmetros do
bloco vão entre pipes (“||”). Na realidade existem mais diferenças, mas
para começar até aqui está bom.

Tipos Básicos

Invertendo a ordem das coisas, finalmente vamos falar um pouco mais sobre os tipos básicos do Ruby. Nós já vimos muitos deles então vamos apenas passar por eles rapidamente.

Arrays

Arrays são listas simples de elementos, a sintaxe mais básica é a seguinte:

>> lista = [100,200,300,400]
=> [100, 200, 300, 400]
>> lista[2]
=> 300
Até aqui nada de novo, porém o Ruby tem alguns facilitadores, por exemplo:

?> lista.first
=> 100
>> lista.last
=> 400

Também já vimos que ele tem vários métodos que aceitam blocos para
processar elemento a elemento, como “each”, “map”, “select”, “inject”.
Já vimos anteriormente como operadores em Ruby nada mais são do que
métodos. Vejamos como os Arrays se comportam:

>> [1,2,3,4] + [5,6,7,8]
=> [1, 2, 3, 4, 5, 6, 7, 8]

>> [1,2,3,4,5] - [2,3,4]
=> [1, 5]

>> [1,2,3] * 2
=> [1, 2, 3, 1, 2, 3]

Como na maioria das linguagens a notação de colchetes (“[]”) deve ser
familiar, para encontrar o elemento através do seu índice. Mas em Ruby,
os colchetes também são operadores! Vamos fazer uma brincadeira:

class Array
  alias :seletor_antigo :[]
  def [](indice)
    return seletor_antigo(indice) if indice.is_a? Fixnum
    return self.send(indice) if indice.is_a? Symbol
    "Nada encontrado para #{indice}"
  end
end

>> lista = [1,2,3,4]
=> [1, 2, 3, 4]

>> lista[2]
=> 3

>> lista[:first]
=> 1

>> lista[:last]
=> 4

>> lista[:size]
=> 4

>> lista["bla bla"]
=> "Nada encontrado para bla bla"

Viram o que aconteceu? Usamos “alias” novamente para criar um novo atalho à antiga implementação de [], daí reimplementamos []. Ele se comporta assim: se o parâmetro passado entre colchetes for um inteiro, é para se comportar como antes, portanto chamando o atalho “seletor_antigo”. Se for um símbolo (vamos explicar isso depois mas por enquanto entenda que é uma palavra com dois pontos antes, como “:first”), ele deve enviar a mensagem ao objeto usando “send”, ou seja, deve executar como se fosse um método. Dessa forma “lista[:first]” deve se comportar igual a “lista.first”. Finalmente, se for qualquer outra coisa (como um String), apenas mostre uma mensagem dizendo que nada foi encontrado.

Como podemos ver, mais do que o Array em si, o operador “[]” pode ser muito útil em vários cenários. Enfim, na maior parte dos casos um Array em Ruby se comporta muito parecido com um Array em qualquer outra linguagem.

Hashes

Um Hash, em outras linguagens, também é chamado de Dicionário, ou seja, é uma lista onde a ordem de inserção não é importante, e cada elemento é um par que liga uma chave a um valor. Por exemplo:

>> dic = { "car" => "carro", "table" => "mesa", "mouse" => "rato" }
=> {"mouse"=>"rato", "table"=>"mesa", "car"=>"carro"}

>> dic["car"]
=> "carro"

>> dic["mouse"]
=> "rato"

Novamente, é um comportamento parecido com um Array, mas em vez de
passar índices numéricos ao operador “[]”, passamos uma chave e
esperamos encontrar o valor correspondente. Para acrescentar mais
elementos à lista, podemos fazer assim:

>> dic.merge!( {"book" => "livro", "leg" => "perna"} )
=> {"leg"=>"perna", "mouse"=>"rato", "table"=>"mesa", "book"=>"livro", "car"=>"carro"}

Mais uma peculiaridade de Ruby. Um Hash tem dois métodos para mesclar
novos elementos a uma lista já existente: “merge” e “merge!”. A
diferença de um para outro é que o primeiro é um método não-destrutivo
e o segundo é um método destrutivo, ou seja, o primeiro retorna a lista
mesclada mas a original continua como antes, já o segundo método mescla
os novos elementos diretamente na lista original. Ou seja, a linha
anterior seria equivalente a fazer isso:

dic = dic.merge( {"book" => "livro", "leg" => "perna"} )

O resultado do merge é atribuído à mesma variável, ignorando a lista
original, que é o que fazemos normalmente. Você também pode ter Hashes
dentro de Hashes, assim:

>> fabio = { "emails" => 
?>           { "trabalho" => "fabio.akita@locaweb.com.br",
?>              "normal"   => "fabioakita@gmail.com" } }
=> {"emails"=>{"normal"=>"fabioakita@gmail.com", "trabalho"=>"fabio.akita@locaweb.com.br"}}

?> fabio["emails"]["normal"]
=> "fabioakita@gmail.com"

Finalmente, podemos explorar o conteúdo de um Hash da seguinte maneira:

>> dic.keys
=> ["leg", "mouse", "table", "book", "car"]
>> dic.values
=> ["perna", "rato", "mesa", "livro", "carro"]

>> dic.keys.each do |chave|
?>   puts "#{chave} = #{dic[chave]}"
>> end
leg = perna
mouse = rato
table = mesa
book = livro
car = carro

Se você entendeu blocos nas seções anteriores, este código deve ser bastante trivial de entender. Se não, retome a leitura do começo.

Hash é um dos tipos mais importantes e vamos retornar a ele em outra seção para ver como esse tipo é usado por todo tipo de codificação Ruby. Inclusive o Ruby on Rails utiliza Hashes o tempo todo em lugares onde a maioria nem imagina.

Meu objetivo nesta série de artigos é demonstrar algumas das características de Ruby que a tornam diferente de outras linguagens, principalmente as estáticas como Java ou C#.

Disclaimer: antes de mais nada, vale avisar que usarei alguns trechos de código Java apenas como referência para quem vem de linguagens tradicionais. Não considere isso uma comparação direta (pois os códigos estão propositadamente não otimizados ou simplificados por motivos didáticos).

O que tem de diferente no Ruby?

Todos os códigos Ruby mostrados neste artigo podem ser testados no ambiente IRB (Interpreted Ruby). Com o Ruby já instalado em sua máquina, digite o comando ‘irb’ e você estará dentro do ambiente dinâmico do interpretador Ruby. Qualquer código Ruby será executado na hora, o que deve facilitar seus testes. Na realidade eu recomendo que à medida que leiam o artigo, digitem os códigos em Ruby no IRB e vejam vocês mesmos os resultados. Será bem mais educativo desta forma.

Para começar, vejam este código:

class Pessoa
  def initialize(nome)
    @nome = nome
  end

  def nome
    @nome
  end

  def nome=(valor)
    @nome = valor
  end
end

fabio = Pessoa.new("Fabio")  
puts fabio.nome

Antes de mais nada, algumas explicações: o que outras linguagens chamam de funções ou métodos, em Ruby são definidas com ‘def … end’. Todo bloco de código termina com ‘end’.

Para colocar um método todo na mesma linha você poderia separar cada linha com “;” (ponto-e-vírgula):

def nome; @nome; end

Para que um método retorne um valor, não é necessário usar a palavra ‘return’ como estamos acostumados. O resultado da última expressão de um método sempre é devolvida no retorno. Por exemplo, o método ‘nome’ acima tem apenas ‘@nome’, que é o equivalente a fazer ‘return @nome’. Use ‘return’ apenas se quiser sair do fluxo do método antes de chegar à linha final. Finalmente, variáveis de instância (algo como ‘this.nome’) são denotados com o prefixo ‘@’.

Para instanciar uma classe, basta chamar o método ‘new’ dela. Os parâmetros passados a esse método são repassados como argumentos ao método padrão ‘initialize’. E ‘puts’ é apenas algo parecido com ‘System.out.println()’. Parênteses são opcionais, só os use para eliminar ambigüidades na hora de chamar um método com parâmetros.

À primeira vista, o código acima não é diferente de algo semelhante em Java:

class Pessoa {
  String nome;
  public Pessoa(String nome) {
    this.nome = nome;
  }
  public String getNome() {
    return this.nome;
  }
  public void setNome(String nome) {
    this.nome = nome;
  }
}

Pessoa fabio = new Pessoa("Fabio");
System.out.println(fabio.getNome());

Nem mesmo em número de linhas de código temos algum ganho. Olhando apenas dessa forma, para um iniciante, ficaria a pergunta: Onde está a diferença? Apenas por não ter chaves?

Bom, vejamos um outro exemplo – da mesma classe Ruby:

require 'ostruct'
class Pessoa < OpenStruct; end

fabio = Pessoa.new :nome => "Fabio"
puts fabio.nome

fabio.email = 'akitaonrails@mac.com'
puts fabio.email

Bom, agora estamos começando a conversar! No caso acima eu confesso, trapaceei um pouco. Fiz a classe ‘Pessoa’ herdar a partir de uma classe padrão do Ruby, a ‘OpenStruct’. Ela permite que os objetos instanciados a partir dessa classe tenham qualquer atributo que for necessário em tempo de execução! Vou voltar neste ponto mais tarde, por enquanto apenas ignore a magia negra e continue.

Ruby suporta herança simples de classes, assim como em Java ou C#. O caracter ‘<’ é o equivalente a ‘extends’ em Java.

Vamos a mais alguns exemplos simples:

>> 1 + 2
=> 3
>> numero = 5
=> 5
>> numero * 3
=> 15

>> contador = 1
=> 1
>> while contador < numero
>>   puts contador
>>   contador += 1
>> end
1
2
3
4

>> def hello
>>   "Hello World"
>> end

>> puts hello
Hello World

Obs: quando você está no IRB, “>>” é o “prompt de comando” e “=>” é o resultado do comando que você acabou de executar. Não confunda com o código Ruby propriamente dito.

Na primeira parte algumas operações simples. Em seguida um loop tradicional, com contador. Depois um pequeno método chamado “hello” e sendo executado. Acredito que, independente da linguagem de onde você veio, o que mostrei até agora é bastante familiar. Novamente, fica a pergunta: “onde está a diferença?”

Quase tudo é Objeto

Ruby foi muito influenciado por Smalltalk, a verdadeira linguagem que inspirou quase todas as outras mais modernas de orientação-a-objetos. Não quero aqui começar nenhuma discussão sobre o que é ser OOP ou não pois argumentos desse tipo são irrelevantes aqui.

O que muitos costumam reclamar em linguagens tradicionais é o seguinte:

class Teste {
  public static void main(String[] args) {
    System.out.println("Hello World");
  }
}

Muita coisa para fazer um simples “Hello World”. Agora vejamos o Hello World em Ruby:

puts "Hello World"

“Oras, mas Ruby não é OOP?? Cadê a classe!!?” Vamos entender o exemplo. Considerando que ainda estamos dentro do ambiente IRB, faça o seguinte:

>> puts "Hello World"
Hello World
=> nil

>> self
=> main
>> self.class
=> Object

Em Ruby, “self” é mais ou menos parecido com a função do “this” em Java ou outras linguagens. Mas como podem ver, nós já estamos dentro de um objeto, de uma instância de Object. Nunca estamos num ambiente estático ou não-objeto. Criar um método no IRB significa adicionar esse método ao objeto ‘main’ que, por sua vez é uma instância da classe Object.

Mas não é apenas isso, veja o seguinte:

>> 1.class
=> Fixnum

>> true.class
=> TrueClass

>> false.class
=> FalseClass

>> nil.class
=> NilClass

Um número, um booleano (verdadeiro, falso) e até nulo (o “nil”) são bjetos. Todos eles respondem a métodos, em especial o método “class” que indica de que classe esse objeto é instância. Note que até o nulo é uma instância da classe chamada “NilClass”.

Classes Abertas

Uma coisa que não tem o que se fazer em muitas linguagens estáticas como Java é mudar de idéia. Toda a idéia de se ter interfaces e classes fechadas força o programador a decidir da primeira vez e ter que sobreviver às conseqüências de sua decisão, o que normalmente força ter que tomar a decisão certa logo no começo e incentiva o temido Big Design Up Front.

Quando precisamos de mais funcionalidades nesses casos, precisamos improvisar. Por exemplo:

class StringUtils {
  public static boolean isEmpty(String str) {
    return str == null || str.length() == 0;
  }
}

String nome = "Fabio Akita";
StringUtils.isEmpty(nome);

O método “isEmpty()”, disponível na classe StringUtils do pacote Commons do Jakarta, avalia se o string que ele recebeu como argumento é nulo ou vazio. Na classe original “java.lang.String” não existia o método “isEmpty()”. Isso não é um erro, apenas na época em que essa classe foi criada, não parecia óbvio a ninguém que um método assim poderia ser útil. Mas agora, a classe String é fechada e não pode ser reimplementada. Também não adianta criar uma classe MyString que herda de String porque todas instâncias de String não terão as novas funcionalidades do MyString.

Portanto a solução-gambiarra significa criar uma classe separada “StringUtils”, com vários métodos estáticos, como o “isEmpty()”, o que efetivamente significa programação procedural e não-orientada a objetos. StringUtils é apenas uma estrutura com um punhado de métodos estáticos.

Em Ruby, podemos o mesmo problema resolver desta forma:

class String
  def empty?
    self.nil? || self.size == 0
  end
end

nome = "Fabio Akita"
nome.empty?

Nesse caso específico nem precisaríamos fazer isso porque o método “empty?” já existe na String de Ruby, mas está aí apenas para ilustrar o problema.

Temos algumas coisas interessantes aqui. Primeiro, o nome do método pode parecer estranho por causa da interrogação no final. Mas não se assustem, em Ruby isso é um caracter válido num nome de método e não tem nenhum efeito colateral, é apenas um caracter a mais que expressa a intenção do método, no caso, de fazer uma pergunta ao objeto.

Mas o mais importante: hoje estamos decidindo que a classe String deveria ter mais métodos do que ele já tem. Felizmente, graças às características da linguagem, não estamos presos a uma classe fechada: podemos reabrí-la, reimplementá-la como quisermos e, automaticamente, toda instância de String (novas e inclusive as que já existiam), passam a responder à nova implementação.

Vejamos outro exemplo de orientação a objetos mesclado com “eye candy”.

>> 1 + 2
=> 3

Vamos lembrar do básico: números, em Ruby, são objetos, mais especificamente instâncias da classe Fixnum. Agora vejamos outra maneira de escrever a mesma coisa em Ruby, sem “eye candy”:

>> 1.+(2)
=> 3

Espero que isso esteja claro: quando somamos dois números, na realidade estamos chamando o método especial “+” do objeto “1” e passando como argumento o objeto “2”. E isso vale para todos os operadores matemáticos que conhecemos como “-”, “/”. Mas o que acontece quando tentamos somar dois objetos incompatíveis?

>> 1 + "2"
TypeError: String can't be coerced into Fixnum
  from (irb):35:in `+'
  from (irb):35
  
>> 1.+("s")
TypeError: String can't be coerced into Fixnum
  from (irb):36:in `+'
  from (irb):36

Escrevi as duas maneiras novamente: passar um String como parâmetro ao método “+” de um Fixnum devolve uma exceção “TypeError” indicando que a operação é inválida. Mas digamos que, apenas por motivos didáticos, eu realmente queira que o Ruby reaja como Javascript ou Perl e que “1” seja convertido em String e depois concatenado ao parâmetro “2”, resultando em “12”.

>> class Fixnum
>>   alias :soma_velha :+
?>   def +(valor)
>>     return self.to_s + valor if valor.is_a? String
>>     soma_velha(valor)
>>   end
>> end
=> nil

>> 1 + 2
=> 3
>> 1 + "2"
=> "12"

Várias coisas acontecendo aqui. Vejamos os principais pontos: primeiro, estamos reabrindo a classe Fixnum, ou seja, todas as instâncias dessa classe serão afetadas automaticamente pelo que faremos a seguir.

Depois, mais uma novidade: o método ‘alias’. Esse é um método de classe que cria um novo apontamento a um método que já existe. Pense em algo assim: você tem ‘a = foo’ e depois ‘b = a’. Agora, tanto ‘a’ quanto ‘b’ apontam para o mesmo objeto ‘foo’.

Outra coisa: quando uma classe é criada, reaberta ou ‘executada’ os métodos chamados dentro dela são executados. Ou seja, o comando ‘alias’, por exemplo, serve para reapontar um método com outro nome. No exemplo, já existia o método chamado “+” e com “alias” criamos um segundo método chamado “soma_velha” que aponta para a mesma implementação do método original. Ou seja, neste ponto as três chamadas a seguir se equivalem:

>> 5 + 10
=> 15

>> 5.+(10)
=> 15

>> 5.soma_velha(10)
=> 15

Mas fizemos mais: depois de criar o novo apontamento “soma_velha” reimplementamos o método antigo “+”. A idéia é: se o parâmetro for um String, quero transformar o objeto Fixnum num String e depois concatenamos os dois. Veja como usamos o ‘return’ para retornar imediatamente caso este seja o caso. Senão, se o argumento passado não for um String, passamos para o método ‘soma_velha’ fazer a soma do jeito antigo.

Note também que usamos o ‘if’ de uma forma um pouco diferente: no fim da expressão:

return self.to_s + valor if valor.is_a? String

‘is_a?’ é um método que está sem os parênteses (lembram-se? são opcionais) e serve para verificar o tipo do objeto ‘valor’. Literalmente podemos ler assim: “retorne self.to_s concatenado com ‘valor’ se for do tipo String.” Se você entende inglês verá que a expressão é praticamente uma frase.

E é isso que acontece agora quando tentamos somar um número com um string: ele retorna a concatenação de dois Strings. Note também que esse comportamento passa a valer para todos os objetos numéricos (instâncias de Fixnum).

Esse conceito de reabrir uma classe e implementar uma nova funcionalidade ficou conhecido com o nome de monkey patching. É um recurso muito poderoso e, como tudo que é poderoso ele pode ser tanto uma grande vantagem como um grande risco se usado da maneira errada. Espera-se, claro, que o programador não abuse disso.

O framework Ruby on Rails faz muito uso desse recurso. Um dos pacotes que compõe o Rails chama-se Active Support e uma de suas utilidades é justamente reabrir diversas classes padrão do Ruby para incorporar mais funcionalidades. Por exemplo:

# carrega o pacote activesupport
>> require 'rubygems'
>> require 'activesupport'
=> true

# horário atual
>> Time.now
=> Wed Oct 29 23:36:24 -0200 2008

# fazendo cálculos com datas
>> Time.now - 23.days
=> Mon Oct 06 23:36:28 -0300 2008

>> 2.weeks.ago
=> Wed Oct 15 23:36:32 -0200 2008

# fazendo cálculos com unidades de medida
>> (1.gigabyte - 512.megabytes) / 1.kilobyte
=> 524288

# transformando objetos em XML
>> { :html => { :body => { :p => "teste" } } }.to_xml
=> "<?xml version="1.0" encoding="UTF-8"?>\n
<hash>\n  <html>\n    <body>\n      
<p>teste</p>\n    </body>\n  </html>\n
</hash>\n"

Como podem ver, podemos incrementar muito as funcionalidades de tudo que já existe. O Ruby on Rails começa exatamente assim: primeiro incorporando muitas coisas novas ao próprio Ruby e depois construindo sobre ela. Muitos são casos onde simplesmente depender de criar novas sub-classes não adiantaria muita coisa. Outro exemplo: em Java, se quisermos comparar o conteúdo de dois Strings, não devemos fazer isso:

String a = "foo";
String b = "bla";
if (a == b) {
  System.out.println("encontrado!");
}
if (a > b) {
  System.out.println("a maior do que b");
}

O correto seria assim:

if (a.equals(b)) {
  System.out.println("encontrado!");
}
if (a.compareTo(b) > 0) {
  System.out.println("a maior do que b");
}

Já, em Ruby, fazemos assim:

a = "foo"
b = "bla"
puts "encontrado!" if a == b
puts "a maior do que b" if a > b

Exatamente como imaginaríamos que deveria ser. Isso porque “==” e “>” são ‘operadores’ mas são também nomes de métodos, como explicamos acima. Então fica fácil implementar o comportamento que precisamos da maneira mais clara e expressiva possível.

Módulos e Organização

No exemplo do Fixnum, reabrimos diretamente a classe para colocar novas funcionalidades. Mas podemos fazer diferente:

Fixnum.class_eval do
  alias :soma_velha :+
  def +(valor)
    return self.to_s + valor if valor.is_a? String
    soma_velha(valor)
  end
end

Como a classe “Fixnum” é por si mesmo um objeto, podemos chamar métodos nela. Por exemplo, “new” é um método dessa instância de Class. O que fizemos acima é a mesma coisa que fizemos antes, mas esse código podemos colocar dentro um método, para ser executado somente quando quisermos. Ou seja, podemos alterar o comportamento de uma classe programaticamente. Mas podemos ser ainda mais seletivos:

>> a = "teste"
=> "teste"
>> a.instance_eval do
?>   def hello
>>     "hello from teste"
>>   end
>> end
=> nil
>> a.hello
=> "hello from teste"
>> "foo".hello
NoMethodError: undefined method `hello' for "foo":String
  from (irb):17
  from :0

Veja agora: criamos um String na variável “a”. Então modificamos essa instância acrescentando um método chamado “hello”, mas somente a essa instância. Quando chamamos “a.hello” ele responde como esperamos, mas quando pegamos uma nova instância de String e tentamos chamar o mesmo método, vemos que não existe. Ou seja, podemos modificar o comportamento de todos os objetos de uma classe, ou somente de um único objeto individual.

Agora vejamos um outro meio de injetar código em classes de maneiras mais organizadas:

module MeusPatches
  def say_hello
    "Hello World!"
  end

  def say_time
    Time.now
  end
end

class Fixnum
  include MeusPatches
end

class String
  extend MeusPatches
end

Módulos são como Classes que não podem ser instanciadas. No exemplo acima, organizamos dois métodos dentro de um módulo chamado “MeusPatches”. Em seguida reabrimos as classes “Fixnum” e “String”. No primeiro incluímos o módulo e no segundo extendemos o módulo. Para entender a diferença vamos usar isso:

>> 13.say_hello
=> "Hello World!"

>> "".say_hello
NoMethodError: undefined method `say_hello' for "":String
  from (irb):19

>> String.say_hello
=> "Hello World!"

O objeto “13” (que é instância de Fixnum) responde ao método do módulo. A string vazia “” não responde. Eis a diferença entre “include” e “extend”: no segundo quem responde ao método do módulo é a própria classe. Na prática, pense que “include” serve para acrescentar métodos de instância e “extend” para acrescentar “métodos de classe” – esse não é o termo correto mas para a maioria dos casos serve.

No Ruby on Rails esse recurso é muito usado, principalmente para organizar códigos de classes muito longas. Por exemplo, o ActiveRecord tem centenas de funcionalidades. Colocar tudo numa única classe seria muito difícil de manter depois, por isso ele se organiza desta forma:

# 
ActiveRecord::Base.class_eval do
  extend ActiveRecord::QueryCache
  include ActiveRecord::Validations
  include ActiveRecord::Locking::Optimistic
  include ActiveRecord::Locking::Pessimistic
  include ActiveRecord::AttributeMethods
  include ActiveRecord::Dirty
  include ActiveRecord::Callbacks
  include ActiveRecord::Observing
  include ActiveRecord::Timestamp
  include ActiveRecord::Associations
  include ActiveRecord::NamedScope
  include ActiveRecord::AssociationPreload
  include ActiveRecord::Aggregations
  include ActiveRecord::Transactions
  include ActiveRecord::Reflection
  include ActiveRecord::Calculations
  include ActiveRecord::Serialization
end

Cada um dos includes acima tem um arquivo separado. Por exemplo ActiveRecord::QueryCache fica no arquivo “active_record/query_cache.rb”. É uma excelente maneira de organizar seus códigos. Mas existem alguns truques importantes de se conhecer. Uma delas é entender que módulos tem “eventos”. Ou seja, podemos instruir o módulo para executar alguma coisa toda vez que for incluso em alguma classe.

module MeusPatches
  def self.included(base)
    base.send(:extend, ClassMethods)
    puts "Module MeusPaches incluso na classe #{base.name}"
  end

  def metodo_de_instancia
    "sou um metodo de instancia"
  end

  module ClassMethods
    def self.extended(base)
      puts "Module MeusPatches::ClassMethods extendido na classe #{base.name}"
    end

    def metodo_de_classe
      "sou um metodo de classe"
    end
  end
end

class Pessoa
end

?>   Pessoa.send(:include, MeusPatches)
Module MeusPatches::ClassMethods extendido na classe Pessoa
Module MeusPaches incluso na classe Pessoa
=> Pessoa
>> 
?>   fabio = Pessoa.new
=> #<Pessoa:0x1789528>
>> fabio.metodo_de_instancia
=> "sou um metodo de instancia"
>> 
?> Pessoa.metodo_de_classe
=> "sou um metodo de classe"

Você vai entender o que significa “send” na próxima seção. Apenas entenda a seguinte idéia: criamos um módulo chamado “MeusPatches” e um sub-módulo dentro dele chamado “ClassMethods” (poderia ser outro nome, mas só para padronizar). Os métodos do módulo principal ficam disponíveis às instâncias dos objetos e os métodos do sub-módulo ficam disponíveis como métodos de classe. A sequência é assim:

1. primeiro definimos o módulo MeusPatches e seu sub-módulo ClassMethods
2. definimos a classe Pessoa, uma classe vazia
3. incluímos o módulo MeusPatches à classe Pessoa
4. o método self.included é ativado que, por sua vez, manda extender o sub-módulo ClassMethods na classe Pessoa (que é passado como o parâmetro “base”)
5. agora a classe Pessoa ganhou os métodos de instância e de classe
6. criamos a instância “fabio” e chamamos o método “metodo_de_instancia”
7. chamamos o método “metodo_de_classe” diretamente da classe Pessoa

Se fôssemos reescrever a classe Pessoa sem o recurso de módulos, ela ficaria assim:

class Pessoa
  def metodo_de_instancia
    "sou um metodo de instancia"
  end

  def self.metodo_de_classe
    "sou um metodo de classe"
  end
end

Criar um método a partir de “self” significa que o método está disponível apenas à classe e não às suas instâncias. Novamente, para ser mais fácil de comparar, pense em métodos estáticos de classe como em Java. Mas entenda que não é a mesma coisa: em Java ou C# as classes são estruturas estáticas, em Ruby a própria classe é um objeto (pois ela é instância da classe “Class”). Outra maneira de escrever a mesma coisa seria:

class Pessoa
  def metodo_de_instancia
    "sou um metodo de instancia"
  end

  class << self
    def metodo_de_classe
      "sou um metodo de classe"
    end
  end
end

A diferença é que em vez de escrever “def self.” o tempo todo, podemos simplesmente reabrir a metaclasse da classe Pessoa e escrever todos os métodos “localmente” ali dentro. Em ambos os casos a classe vai se comportar da seguinte forma:

>> p = Pessoa.new
=> #<Pessoa:0x1775370>

>> p.metodo_de_instancia
=> "sou um metodo de instancia"

>> p.metodo_de_classe
NoMethodError: undefined method `metodo_de_classe' for #<Pessoa:0x1775370>
  from (irb):94

>> Pessoa.metodo_de_instancia
NoMethodError: undefined method `metodo_de_instancia' for Pessoa:Class
  from (irb):95

>> Pessoa.metodo_de_classe
=> "sou um metodo de classe"

Não perca a Parte II deste artigo para entender o básico da linguagem Ruby. Espero que até aqui tenha ficado bastante claro que não devemos tentar codificar Ruby da mesma forma que codificamos em outras linguagens estáticas. Tirem proveito do dinamismo dessa linguagem, é assim que fazemos o “The Ruby Way”.

E como fazer caso seja necessário, no seu contexto, ter acesso ao username e password presentes nesse arquivo? Acredito que esses dados não estejam disponíveis em nenhum dos objetos que o Rails instancia (eu procurei), certamente por questões de segurança, mas se você realmente precisa carregar esses dados, eis aqui uma forma bem simples.

De preferência dentro de um controller da sua aplicação (como o ApplicationController), você pode definir esta linha:

class ApplicationController < ActiveRecord::Base
  @@db_config = YAML.load_file("#{RAILS_ROOT}/config/database.yml")
               [RAILS_ENV]
end

Agora você tem em @@db_config um hash (cujas chaves são strings, e não símbolos) com tudo aquilo que você precisa. Digamos que seu config/database.yml tivesse esta cara:

production:
  adapter: mysql
  database: teste_production
  username: teste
  password: teste
  timeout: 5000

development:
  adapter: mysql
  database: teste_development
  username: teste
  password: teste
  timeout: 5000

Se o servidor da aplicação está rodando em modo de desenvolvimento, então a constante RAILS_ENV guarda development. Por conseqüência, @@db_config['database'], por exemplo, guarda teste_development.

Por ter sido declarada no escopo de classe de ApplicationController, nesse exemplo @@db_config estaria disponível em todos os métodos de todos os seus controllers.