Numa aplicação típica, um model geralmente estende a classe ActiveRecord::Base ou inclui um módulo, como Mongoid::Document, no caso do Mongoid, por exemplo, para mapear a estrutura do banco de dados. Além disso, o model contém as regras de negócio associadas a ele. O controller tem a responsabilidade de mapear a ação atual numa view – por exemplo, ao submeter um formulário para criação de um novo objeto, um controller típico renderiza uma view exibindo uma mensagem de sucesso, ou renderiza a mesma view do formulário com as mensagens de erro, caso haja algum. Já a view é responsável por exibir os dados correspondentes à página atual.

Essa estrutura básica funciona bem numa aplicação simples. O problema é quando a view começa a conter muita lógica. Por exemplo, uma view para exibir dados de um usuário poderia ser simples assim:

@usuario.nome

Porém, se o conteúdo muda dependendo do tipo de usuário (ex: usuário comum e admin), precisamos de um if dentro da view:

<% if @usuario.admin? %>
  admin
<% else %>
  @usuario.nome
<% end %>

Quando mais diferenças houver, mais complexa fica a view. Consequentemente, fica mais difícil de gerenciar. Além disso, normalmente fazemos testes unitários para o model e o controller, e testamos a view somente com testes de aceitação, que são muito mais lentos (é preciso carregar todo o ambiente, Rails, banco de dados, e dependendo do teste, abrir um browser). Fica impraticável testar todos os fluxos de uma view cheia de if’s usando testes de aceitação.

Uma solução comum no mundo Rails é usar os helpers. No exemplo acima, eu poderia ter o seguinte helper:

class UsuarioHelper
  def titulo_usuario(usuario)
    usuario.admin? ? "admin" : usuario.nome
  end
end

Isso deixa o código da view mais simples:

titulo_usuario(@usuario)

E, além disso, posso testar a lógica num teste unitário do helper. Mas essa solução também tem problemas: o helper não está associado diretamente ao objeto em questão. Isso ficou claro no exemplo acima, onde precisei passar o usuário como parâmetro para o método do helper. Isso se repetiria para cada método.

Uma boa solução para este caso é utilizar o design pattern Decorator. Para isso, criamos uma classe que recebe o model como parâmetro no construtor e implementa todos os métodos necessários para lógicas de visualização (ou seja, que não estão associados ao negócio e não devem ficar no model). Quando é chamado um método que não existe, o Decorator delega (daí o nome do padrão) a chamada para o model. Existem várias implementações para o Decorator, essa é uma das mais simples:

module Decorator
  attr_reader :model

  def initialize(model)
    @model = model
  end

  def method_missing(meth, *args)
    if @model.respond_to?(meth)
      @model.send(meth, *args)
    else
      super
    end
  end

  def respond_to?(meth)
    @model.respond_to?(meth)
  end

  def self.included(base)
    base.extend(ClassMethods)
  end

  module ClassMethods
    def decorate(object)
      if object.is_a? Enumerable
        object.map {|obj| self.new(obj)}
      else
        self.new(object)
      end
    end
  end
end


class UsuarioDecorator
  include Decorator

  def titulo
    @model.admin? ? "admin" : @admin.nome
  end
end

Desta forma, temos uma classe que recebe o model no construtor ou no método de classe decorate. A implementação do método titulo_usuario no Decorator ficou muito mais simples. Para utilizá-la, basta decorar o model no controller:

class UsuariosController
  def show
    @usuario = UsuarioDecorator.decorate(Usuario.find(params[:id]))
  end
end

A implementação da view fica assim:

@usuario.titulo

Em casos mais simples, o Decorator atende bem. Mas e quando temos uma página mais complexa, envolvendo diversos objetos? Precisaríamos criar um Decorator para cada model, e lembrar de decorar cada objeto na criação, assim como fizemos com o usuário no exemplo anterior. Outro problema é que podemos ter visualizações diferentes de um objeto em cada tela da aplicação. Como tratar este caso? Poderíamos criar métodos diferentes no Decorator, mas com o tempo o Decorator poderia virar um monstro. Outra opção é criar vários Decorators para aquele model, onde cada um se aplica a uma página. Ou podemos usar um outro padrão, o Presenter.

O Presenter é um padrão também conhecido por outros nomes, como View Object, mas na comunidade Ruby o nome Presenter se popularizou com um post de Jay Fields. O Presenter é muito parecido com o Decorator, mas envolve vários objetos. O contexto do Presenter é uma página específica da aplicação, e recebe como parâmetro todos os objetos necessários à exibição daquela página. Desta forma, toda a lógica de apresentação fica numa única classe. Segue um exemplo de uso do Presenter:

class PedidoPresenter
  def initialize(usuario, pedidos)
    @usuario = usuario
    @pedidos = pedidos
  end

  def titulo
    "Usuário #{@usuario.nome} - #{@pedidos.size} pedidos"
  end

  def links
    @pedidos.map { |pedido| link_to pedido.nome, pedido_url(pedido) }
  end
end

Ainda há uma outra opção além do Presenter, que foi apresentada no livro Objects on Rails. É o padrão Exhibit. A diferença em relação ao Presenter é que, enquanto o Presenter disponibiliza métodos para serem chamados pela view (como no exemplo acima), o Exhibit é responsável pela renderização. Para isso, ele precisa receber um contexto:

class Exhibit
  def initialize(obj, context)
    @obj = obj
    @context = context
  end

  def render_header
    @context.render :partial => "header", :locals => {:obj => @obj}
  end
end

Este contexto pode ser o view_context do controller:

class Controller
  def show
    @usuario = Exhibit.new(Usuario.find(params[:id]), view_context)
  end
end

Outra maneira de instanciar o Exhibit é através de um helper, como mostrado no livro The Rails View:

class Helper
  def exhibit
    Exhibit.new(Usuario.find(params[:id]), self)
  end
end

São muitos padrões que tem a mesma função: encapsular a lógica de visualização num único local, que seja facilmente testável. E qual é a melhor opção entre os três? A resposta depende da situação. Não adianta querer encontrar um padrão perfeito para todos os casos. Na minha opinião, o Decorator funciona bem em páginas mais simples, que envolvem apenas um model. Quando a página é mais complexa e envolve vários models, o Presenter e o Exhibit são mais adequados. E a diferença entre os dois é uma questão de gosto.

Links relacionados:

• Decorators compared to Strategies, Composites, and Presenters
• Evaluating alternative Decorator implementations in Ruby
• Better Ruby Presenters
• Explorando as views Rails

Posts relacionados:

• Rails e mass assignment: como aumentar a segurança dos atributos
• Instant Rails, o ambiente Rails de bolso
• Ferramenta em Rails para criação de blogs
• Rails sem banco de dados
• IDEs para Ruby on Rails

Um dos itens mais importantes ao otimizar um site, de acordo com Steve Souders, é diminuir o número de requests. Um recurso muito útil para isso é a criação de sprites, ou seja, um único arquivo contendo várias imagens que são utilizadas no site. Nos locais que fazem referência a estas imagens, são definidos a largura, altura e offset do sprite. Desta forma, é feito um único request para obter todas as imagens. O uso de sprites é muito comum em grandes sites como Twitter, Facebook, Google e Yahoo.

A criação de um sprite manualmente é uma tarefa bem trabalhosa. É necessário criar uma imagem utilizando uma ferramenta como o Photoshop, por exemplo, e colar cada imagem uma abaixo (ou ao lado) da outra, deixando alguns pixels entre imagens. Sempre que se quiser adicionar uma nova imagem, será necessário abrir o sprite novamente no Photoshop e repetir o processo para inserir a nova imagem.

Para simplificar esta tarefa, é possível utilizar uma ferramenta para geração automática de sprites. Uma das melhores ferramentas para isso é o Compass. Após instalar e configurar, basta colocar as imagens num diretório e o sprite será gerado automaticamente. A instalação num projeto Rails é extremamente simples, e está bem explicada no help do Compass.

A configuração básica do Compass para geração de sprites segue o padrão abaixo:

$imagens-spacing: 2px
$imagens-sprite-dimensions: true
@import "imagens/*.png"

No exemplo acima, todas as propriedades são configuradas com o prefixo imagens. O sprite é configurado com espaçamento de 2 pixels entre cada imagem, para evitar sobreposição no limite entre as imagens. A segunda linha habilita a inclusão das dimensões das imagens no CSS gerado, o que é útil para manter fixo o tamanho ocupado pela imagem enquanto ela é carregada. A terceira linha informa quais imagens serão adicionadas. Neste caso, são todas as imagens com extensão png que estão no diretório imagens. É importante lembrar que o nome deste diretório deve ser igual ao prefixo utilizado nas propriedades.

Além de gerar o sprite, o Compass cria classes CSS para referenciar cada imagem. Os nomes das classes começam com o prefixo utilizado acima, seguido por hífen e o nome da imagem sem extensão. Por exemplo, para uma imagem chamada excluir.png, a classe teria o nome imagens-excluir.

O uso as imagens do sprite no seu CSS pode ser feito de duas formas: usando diretamente as classes criadas pelo Compass (como imagens-excluir, no exemplo anterior) ou utilizando um mixin do Compass no seu arquivo Sass:

.minha-classe { @include imagens-sprite(excluir); }

Ao utilizar uma destas configurações, a imagem será configurada como background do elemento.

Para criar um segundo sprite, para a parte administrativa da aplicação, por exemplo, é necessário utilizar um prefixo diferente, como no exemplo abaixo:

$imagens-admin-spacing: 2px
$imagens-admin-sprite-dimensions: true
@import "admin/imagens-admin/*.png"

Neste exemplo, as imagens do sprite estão no diretório admin/imagens-admin, e o prefixo segue o nome do último diretório (imagens-admin). Isso significa que, no exemplo acima, não seria possível manter o sprite do admin em admin/imagens, pois haveria conflito de nomes com o outro sprite.

Os sprites gerados pelo Compass são arquivos png que tem como nome o prefixo utilizado na configuração seguido por um hash (ex: imagens-b03bdb7a79370e7ff107e7b37fe7df6e.png). Quando o sprite é modificado (em ambiente de desenvolvimento o Compass verifica automaticamente a cada request se alguma imagem foi adicionada ou removida, e em produção é necessário executar um rake task para isso), o Compass gera um novo hash para o nome do arquivo. Isto é feito para evitar que o sprite seja cacheado pelo browser. Se isso acontecesse, o browser não buscaria o sprite atualizado, mantendo o arquivo anterior.

Os exemplos descritos acima descrevem apenas as configurações básicas para geração de sprites. A documentação de sprites traz mais detalhes sobre as opções de configuração. Além disso, o Compass tem muitas outras funcionalidades. Vale a pena pesquisar a referência no site do Compass para mais detalhes.

UPDATE: outra configuração útil para os sprites é o layout das imagens. Por padrão, o layout dos sprites é vertical, ou seja, cada imagem é colocada abaixo da anterior. Porém, o Compass também permite definir layout horizontal, diagonal ou smart. Neste último, a disposição das imagens é feita de acordo com o tamanho de cada uma, e o resultado é uma imagem menor do que com o layout padrão. No meu projeto, ao trocar o layout vertical pelo smart, o sprite ficou cerca de 10% menor. No primeiro exemplo deste post, a configuração do layout ficaria assim:

$imagens-layout: smart

Posts relacionados:

• Design patterns em Ruby – Decorators, Presenters e Exhibits
• Rails e mass assignment: como aumentar a segurança dos atributos
• Instant Rails, o ambiente Rails de bolso
• Ferramenta em Rails para criação de blogs
• Rails sem banco de dados

@usuario = Usuario.new(params[:usuario])

Na forma em que o Rails cria o formulário, os atributos do usuário são passados ao controller como um hash. O valor do params acima é algo parecido com isso:

{"authenticity_token"=>"xI1Cy+LvUZzg6FR/1Y/JHcaHVPRyWsHmRII8BhMOr0E=",
 "utf8"=>"?",
 "action"=>"create",
 "controller"=>"usuarios",
 "usuario"=>{"nome"=>"Novo usuario", "email"=>"novo@usuario.com"}}

Além da definição do token de segurança, codificação em utf-8, nome do controller e da action que será executada, o parâmetro usuario contém todos os atributos que foram preenchidos no formulário. Desta forma, é muito simples atribuir os parâmetros preenchidos a um objeto Usuario, seja criando um novo (@usuario = Usuario.new(params[:usuario])) ou editando (@usuario.update_params(params[:usuario])). O Rails chama isso de mass assignment.

O problema desta abordagem é que o usuário poderia facilmente inserir novos parâmetros neste hash, simplesmente adicionando tags input hidden no formulário (usando o Firebug, por exemplo):

<input type="hidden" name="usuario[admin]" id="usuario_admin" value="true" />

Adicionando o código acima, o novo usuário criado receberia o valor true no atributo admin, o que representa uma falha grave na segurança da aplicação.

O Rails oferece um mecanismo para garantir a segurança nestes casos, usando os métodos attr_protected e attr_accessible do ActiveModel. O primeiro permite definir atributos que não podem ser alterados através de mass assignment:

class Usuario
  attr_protected :admin
end

E o attr_accessible é uma forma mais segura: somente os atributos passados para este método poderão ser alterados com mass assignment. Os demais ficam protegidos:

class Usuario
  attr_accessible :nome, :email
end

Obviamente estes dois métodos não podem ser usados simultaneamente, pois um exclui o outro.

Se você quiser atualizar um objeto com mass assignment ignorando a segurança fornecida pelo attr_accessible e pelo attr_protected, basta utilizar o parâmetro without_protection (somente no Rails 3.1):

Usuario.create(
  {:nome => "Novo usuario", :email =>"novo@usuario.com", :admin => true},
  :without_protection => true)

No exemplo acima, o usuário criado terá o atributo admin igual a true, mesmo que tenha sido usado o método attr_protected ou o attr_accessible para evitar a alteração deste atributo.

Outra opção interessante para evitar a alteração de atributos indesejados é o método attr_readonly. Os atributos passados para este método só poderão ser definidos na criação do objeto, e não poderão ser alterados depois. Porém, este método faz parte do ActiveRecord::Base, e não do ActiveModel, ou seja, ele não estará disponível se você usar outro ORM. Há uma issue aberta no Github solicitando que este método seja movido para o ActiveModel.

Link relacionado:

• Recebendo dados do usuário: attr_accessible e attr_protected

Posts relacionados:

• Rails sem banco de dados
• Configurações fora do padrão em Rails, parte 2 – Relacionamentos HABTM
• Configurações fora do padrão em Rails
• Acessando múltiplos bancos de dados em Rails
• Design patterns em Ruby – Decorators, Presenters e Exhibits

A opção mais óbvia para controle de tarefas seria o Google Tasks, pois é do próprio Google, e como tal, é totalmente integrado não só ao Google Calendar, mas também ao Gmail. Apesar de ser uma boa opção, o Google Tasks é bastante limitado, e não possui (ainda) uma funcionalidade que considero básica para uma ferramenta de controle de tarefas: o cadastro de tarefas recorrentes (ex: toda segunda-feira, todo mês no dia 10).

Em função destas limitações, eu prefiro utilizar o Remember the Milk, que é uma ferramenta muito mais completa que o Google Tasks. Ele também pode ser integrado tanto ao Gmail quanto ao Google Calendar.

Integração com Google Calendar

A integração é bem simples, através da interface iCalendar do Remember the Milk: vá até a opção settings, aba Info. Copie o link “iCalendar Events Service (All Lists)”. Em seguida, vá ao Google Calendar, em “other calendars”, à esquerda, há uma opção “Add by URL”. Cole a URL que foi copiada do Remember the Milk, e será criado um novo calendário com as suas tarefas – obviamente só aparecerão as que tem data.

Apesar de funcionar bem, a integração é limitada: a hora da tarefa não aparece, não há link direto para ver a tarefa no RTM, e é somente uma visualização, ou seja, não é possível editar, excluir ou concluir a tarefa a partir do Google Calendar. Além disso, quando uma tarefa é concluída, ela demora um tempo para sumir do calendário. Mas é possível configurar reminders para este calendário específico, o que torna a integração mais útil.

O calendário criado exibe todas as tarefas do seu RTM que não estão concluídas e tem data. Outra possibilidade é criar calendários com listas específicas. Para isso, vá ao RTM, faça uma busca ou selecione uma lista ou smart list específica. No lado direito aparecerá uma opção “iCalendar (Events)”. Copie esse link e repita o procedimento anterior no Google Calendar.

O RTM também disponibiliza dois gadgets para Google Calendar:

• Sidebar Gadget

Permite visualizar, editar e adicionar tarefas diretamente no Google Calendar. Só não é possível visualizar e editar notas, mas há um link para exibir no RTM.

• Daily Gadget

Adiciona um botão a cada dia do calendário; ao ser clicado, exibe a lista de tarefas do dia.

Integração com Gmail

O RTM disponibiliza duas maneiras de exibir as tarefas no Gmail:

• Gadget do Google Calendar

Se você configurou a integração do RTM com o Google Calendar, descrita acima, o gadget do Google Calendar exibirá as tarefas do RTM.

• Gmail Gadget

Este gadget possui as mesmas funcionalidades do Sidebar Gadget para Google Calendar.

• Add-on (Firefox e Chrome)

Esta extensão é bem semelhante ao Gmail Gadget, mas possui algumas funcionalidades a mais: ela pode ser configurada para criar tarefas automaticamente quando um email for marcado com estrela ou com um label específico. Também é possível criar uma tarefa associada a um email específico, que será automaticamente concluída quando o email for respondido.

Posts relacionados:

• Problema com a extensão do Remember The Milk no Gmail

O Pik funciona de forma bastante semelhante ao RVM. Para instalá-lo, primeiro é necessário instalar o Ruby Installer, um pacote pré-configurado especialmente para instalar o Ruby no Windows. A documentação do Pik recomenda a versão 1.8.7. Em seguida, instale as gems rake, isolate e o próprio pik:

gem install rake isolate pik

Antes de instalar o isolate, talvez seja necessário atualizar o Rubygems com o comando abaixo:

gem update --system

O próximo passo é instalar o Pik no diretório de sua preferência. Um detalhe importante que já me custou um bom tempo é que o path completo não deve conter espaços. Execute o seguinte comando para instalar em C:\Ruby\pik, por exemplo:

pik_install C:\Ruby\pik

Concluída a instalação, o comando pik help commands exibe uma lista com os comandos disponíveis. Quem já usou o RVM não terá dificuldades, pois os comandos são bem semelhantes. Os comandos mais comuns são:

• pik install ruby/jruby/ironruby [versão] -> instala a versão desejada do Ruby, JRuby ou IronRuby. A versão é opcional; se for omitida, será instalada a versão mais recente. Importante: antes de executar este comando, instale o 7zip e adicione-o ao path
• pik list -> exibe as versões de Ruby atualmente instaladas
• pik use [versão] -> seleciona uma versão instalada
• pik gem [comando] -> executa um comando do Rubygems em todas as versões instaladas
• pik ruby [parâmetros] -> executa Ruby em todas as versões instaladas

Inicialmente, o comando pik list exibe apenas a versão 1.8.7:

C:\Ruby\pik>pik list
* 187: ruby 1.8.7 (2011-02-18 patchlevel 334) [i386-mingw32]

Decidi instalar a última versão do Ruby e do JRuby. Após instalar estas duas versões, a saída do comando pik list ficou assim (o asterisco mostra a versão atualmente em uso):

C:\Ruby\pik>pik install ruby
...
C:\Ruby\pik>pik install jruby
...
C:\Ruby\pik>pik list
  161: jruby 1.6.1 (ruby-1.8.7-p330) (2011-04-12 85838f6) (Java HotSpot(TM) Client VM 1.6.0_24) [Windows XP-x86-java]
* 187: ruby 1.8.7 (2011-02-18 patchlevel 334) [i386-mingw32]
  192: ruby 1.9.2dev (2010-05-31) [i386-mingw32]

Para selecionar o JRuby, por exemplo, use o comando pik use 161 (é importante lembrar que neste caso os comandos mudam de nome: irb vira jirb, ruby vira jruby):

C:\Ruby\pik>pik use 161

C:\Ruby\pik>ruby -v
'ruby' não é reconhecido como um comando interno
ou externo, um programa operável ou um arquivo em lotes.

C:\Ruby\pik>jruby -v
jruby 1.6.1 (ruby-1.8.7-p330) (2011-04-12 85838f6) (Java HotSpot(TM) Client VM 1.6.0_24) [Windows XP-x86-java]

Para instalar gems, basta usar o comando gem install normalmente. A gem será instalada na versão atual do Ruby (ou seja, a que você selecionou com o comando pik use). O comando pik gem permite instalar uma gem em todas as versões:

C:\Ruby\pik>pik gem install mongo
jruby 1.6.1 (ruby-1.8.7-p330) (2011-04-12 85838f6) (Java HotSpot(TM) Client VM 1.6.0_24) [Windows XP-x86-java]

Fetching: bson-1.3.1-jruby.gem (100%)
Fetching: mongo-1.3.1.gem (100%)
Successfully installed bson-1.3.1-java
Successfully installed mongo-1.3.1
2 gems installed

ruby 1.8.7 (2011-02-18 patchlevel 334) [i386-mingw32]

Fetching: bson-1.3.1.gem (100%)
Fetching: mongo-1.3.1.gem (100%)
Successfully installed bson-1.3.1
Successfully installed mongo-1.3.1
2 gems installed
Installing ri documentation for bson-1.3.1...
Installing ri documentation for mongo-1.3.1...
Installing RDoc documentation for bson-1.3.1...
Installing RDoc documentation for mongo-1.3.1...

ruby 1.9.2dev (2010-05-31) [i386-mingw32]

Successfully installed bson-1.3.1
Successfully installed mongo-1.3.1
2 gems installed
Installing ri documentation for bson-1.3.1...
Installing ri documentation for mongo-1.3.1...
Installing RDoc documentation for bson-1.3.1...
Installing RDoc documentation for mongo-1.3.1...

O comando pik ruby permite executar um código em todas as versões instaladas, útil para verificar incompatibilidades entre as versões, como por exemplo o construtor com parâmetros da classe Time:

C:\Ruby\pik>pik ruby -e "puts Time.new('2011-01-01')"
jruby 1.6.1 (ruby-1.8.7-p330) (2011-04-12 85838f6) (Java HotSpot(TM) Client VM 1.6.0_24) [Windows XP-x86-java]

ArgumentError: wrong number of arguments (1 for 0)
  (root) at -e:1

ruby 1.8.7 (2011-02-18 patchlevel 334) [i386-mingw32]

-e:1:in `initialize': wrong number of arguments (1 for 0) (ArgumentError)
        from -e:1:in `new'
        from -e:1

ruby 1.9.2dev (2010-05-31) [i386-mingw32]

2011-01-01 00:00:00 -0200

Mais detalhes sobre o funcionamento do Pik podem ser encontrados no Github do projeto.

Posts relacionados:

• Representação de data e hora em Ruby 1.8.7 e 1.9
• Instant Rails, o ambiente Rails de bolso
• Design patterns em Ruby – Decorators, Presenters e Exhibits
• Ruby no Ubuntu – erro na instalação de Rubygems
• Classes abstratas em Ruby?

No caso do Firefox, há uma outra forma de contribuir para o projeto, que não exige qualquer conhecimento específico. É através do Test Pilot, uma extensão que, ao ser instalada, exibe uma lista de estudos sendo conduzidos pela Mozilla. Sempre que surgir um novo estudo, você poderá ver os detalhes dele e optar por participar ou não. O estudo que acontece com mais frequencia é o “A Week in the Life of a Browser”, onde, caso você aceite participar, durante uma semana o Test Pilot monitorará informações sobre o seu uso do browser, como memória utilizada, número de abas abertas simultaneamente, número de downloads e de bookmarks – ou seja, nenhuma informação sensível do usuário é coletada. No final do período do estudo, esses dados são enviados para a Mozilla, mas antes você pode ver exatamente que informações serão enviadas através de gráficos como esse:

Alguns estudos são pesquisas sobre usabilidade e funcionalidades específicas, como mecanismos de busca e uso de bookmarks e dos botões na toolbar. Para ver os estudos já realizados, acesse a página de test cases. Para participar, basta instalar a extensão.

Posts relacionados:

• Migrando do Delicious para o Google Bookmarks
• Solução de problema com o Flash Player no Ubuntu com Firefox >= 3.6.4
• Exclusão de itens individuais do histórico do Firefox
• Compartilhando perfis do Firefox com dual boot
• Vídeos com HTML 5 e a nova guerra dos browsers

irb(main):007:0> Time.new
=> Wed Feb 09 13:23:52 -0200 2011
irb(main):008:0> Time.now
=> Wed Feb 09 13:23:53 -0200 2011

Também é possível criar uma instância usando métodos como Time.at(time), que recebe um timestamp como parâmetro, Time.local(year, month, day, hour, min, sec_with_frac) e outros. Também há um construtor que recebe como parâmetro uma string representando a data:

irb(main):001:0> Time.new('2011-01-01')
=> Sat Jan 01 00:00:00 -0200 2011

Eu havia escrito um código que usava esse construtor no pidgin-logs-compressor, mas quando testei no JRuby 1.5.5, recebi uma exceção “ArgumentError: wrong number of arguments (1 for 0)”. Achei que fosse algum bug do JRuby, e realmente havia esse bug na versão que eu usava, mas já estava corrigido no JRuby 1.6RC1. Atualizei para esta versão, mas o erro continuou. Descobri que o erro que eu estava cometendo era relacionado com a versão do Ruby, e não do JRuby. Esse construtor com parâmetros é aceito no Ruby 1.9, mas não no 1.8.7, que é a versão usada por padrão pelo JRuby. Para fazer com que ele utilize a versão 1.9, basta acrescentar o parâmetro –1.9 na linha de comando:

jruby --1.9 -e 'puts Time.new("2011-02-16")'

Para manter compatibilidade com versões anteriores, é necessário usar algum dos outros métodos, como eu optei por fazer no pidgin-logs-compressor.

Para um overview de algumas novidades do Ruby 1.9: New Ruby 1.9 Features, Tips & Tricks.

Posts relacionados:

• Design patterns em Ruby – Decorators, Presenters e Exhibits
• Ruby no Ubuntu – erro na instalação de Rubygems
• Classes abstratas em Ruby?
• Instant Rails, o ambiente Rails de bolso
• Ferramenta em Rails para criação de blogs

guilherme@guilherme-desktop:~$ sudo gem install mechanize
Building native extensions.  This could take a while...
ERROR:  Error installing mechanize:
    ERROR: Failed to build gem native extension.

/usr/bin/ruby1.8 extconf.rb
extconf.rb:5:in `require': no such file to load -- mkmf (LoadError)
    from extconf.rb:5

A solução é simples: basta instalar o pacote ruby-dev: sudo apt-get install ruby-dev. Este pacote é necessário para a instalação de gems nativas, que precisam ser compiladas na instalação.

Posts relacionados:

• Instant Rails, o ambiente Rails de bolso
• Design patterns em Ruby – Decorators, Presenters e Exhibits
• Representação de data e hora em Ruby 1.8.7 e 1.9
• Ubuntu Netbook Remix no HP Mini
• Solução de problema com o Flash Player no Ubuntu com Firefox >= 3.6.4

Há alguns meses, eu havia pensado em migrar meus bookmarks para o Google Bookmarks, mas desisti, pois eu já estava bastante acostumado com o Delicious. Até que no início de dezembro veio a bomba: o Yahoo, que havia comprado o Delicious em 2005, anunciou que encerraria o serviço! Imediatamente comecei a pensar em alternativas, e o Google Bookmarks foi minha primeira opção. Alguns dias depois, o Yahoo voltou à cena informando que iria vender, e não fechar o serviço, e o próprio Delicious publicou uma nota sobre o assunto. Mas, mesmo assim, para mim foi a deixa para fazer a migração para outro serviço. Apesar de existirem várias alternativas ao Delicious, escolhi o Google Bookmarks pela simplicidade, e por já estar integrado à minha conta no Google.

A primeira parte da migração foi fácil: exportar os bookmarks do Delicious, através da opção Settings -> Export/Backup Bookmarks. Para importá-los no Google Bookmarks, uma das maneiras mais simples é importar os bookmarks do Delicious no Firefox e sincronizá-los com o Google Toolbar. Também é possível fazer a importação usando o Google Chrome, ou usar algum script (como este) ou serviço, como o del.icio.us to Google Bookmarks.

Em seguida, procurei as opções para integração com o browser (adicionar e pesquisar nos bookmarks). No Firefox existem diversas extensões para Google Bookmarks. Testei algumas, e a que achei melhor foi o GMarks. Com ela, é possível adicionar bookmarks com Control+D, de forma bem semelhante à extensão do Delicious, e também há uma barra lateral, acionada com Alt+M. Porém, não há integração com a barra de endereços, ou seja, não é possível pesquisar nos bookmarks digitando diretamente o endereço (como permitem as versões mais recentes da extensão do Delicious). Porém, há duas maneiras de pesquisar (além de acessar diretamente a página do Google Bookmarks para fazer a pesquisa):

1. Ao digitar a tecla Home duas vezes, aparecerá uma caixa de texto para pesquisa. É só digitar qualquer coisa e depois escolher um resultado e apertar Enter (ou Alt+Enter para abrir em outra aba)
2. Criando um atalho para a busca: acesse o Google Bookmarks, clique com o botão direito sobre o campo de busca e selecione a opção “Add a keyword for this search”. O Firefox adicionará a pesquisa nos bookmarks locais, e você poderá adicionar um keyword a este bookmark. Digite “gb”, por exemplo, e clique em OK. Agora, ao digitar qualquer texto precedido desta keyword na barra de endereços (por exemplo: “gb teste”), o Firefox pesquisará este texto no Google Bookmarks. Mas os resultados não aparecem diretamente, você precisa escolher a opção “Search Google Bookmarks” entre as sugestões que aparecem

Para integrar o Google Bookmarks ao Chrome é ainda mais simples, pois não é necessário instalar qualquer extensão (afinal, ambos são do Google). Para adicionar bookmarks, acesse a página de ajuda. Ela disponibiliza um botão que pode ser arrastado para a barra de bookmarks, e ao clicar nele, a página atual será adicionada. Para adicionar a pesquisa no Google Bookmarks à barra de endereços, clique na barra com o botão direito, selecione “Edit search engines” e adicione um novo, com as seguintes configurações:
Nome: Google Bookmarks
Keyword: gb
URL: http://google.com/bookmarks/find?&q=%s

Agora, a pesquisa integrada à barra de endereços funcionará da mesma forma que no Firefox (“gb texto para pesquisa”).

Posts relacionados:

• Ajude o Firefox a crescer com o Test Pilot
• Solução de problema com o Flash Player no Ubuntu com Firefox >= 3.6.4
• Exclusão de itens individuais do histórico do Firefox
• Compartilhando perfis do Firefox com dual boot
• Vídeos com HTML 5 e a nova guerra dos browsers

Em seguida, lembrei que quando eu havia instalado este mesmo sistema operacional num outro netbook HP Mini, mas a versão do Ubuntu era 10.04. Como a página principal do Ubuntu só disponibiliza links para download da última versão, encontrei as versões anteriores na página Ubuntu Releases. Na página específica da versão 10.04 (Lucid Lynx) o link aparece como PC (Intel x86) netbook live CD.

Após baixar esta versão e instalá-la no pen drive, tudo funcionou. Aparentemente é algum problema relacionado com a versão 10.10 mesmo. Tudo funciona de primeira, sem necessitar qualquer configuração (bluetooth, som, webcam, etc.), exceto o wifi. A página Hardware support do wiki do Ubuntu traz a solução: basta conectar o netbook à Internet via porta Ethernet e reinstalar o driver bcmwl, digitando no terminal: sudo apt-get install bcmwl-kernel-source. Após a instalação, reinicie o netbook e tudo funcionará.

Posts relacionados:

• Ruby no Ubuntu – erro na instalação de Rubygems
• Solução de problema com o Flash Player no Ubuntu com Firefox >= 3.6.4
• Matrix rodando no Windows
• Script para verificar o status da conexão PPPoE
• Instalação do Firefox 3.0 no Ubuntu