Nome do Jogo

Railties

• Corrigido bug ao usar script/about em produção.

ActionPack

• No Rails 2.2 o método ActionView::Base#render_file passa a ser privado.
• O método auto_link agora também suporta o caracter ‘ (aspas simples) no meio da url.

Foto de chrys

Algumas pessoas estão comentando que o Ruby on Rails 2.2 deve ser lançado até setembro, a tempo do RailsConf Europe, e acredito que esta é uma das novidades que mais nos interessa.

Tudo começou em setembro de 2007 quando um grupo de desenvolvedores começaram a construção de um plugin para o Rails chamado rails-I18n, que visava eliminar a necessidade de monkey patching no Rails para internacionalizar uma aplicação.

Peraí, antes de começar, o que é I18n?

Há claro, não posso começar um artigo sobre I18n sem explicar o que isto significa. Primeiro, para entender o porque deste nome, precisamos ter um conhecimento profundo de cálculos matemáticos. Conte comigo, quantas letras temos entre o I e o n na palavra Internationalization? 18. Muito bom, I18n.

O mesmo vale para Localization e L10n.

Já viu quando um site tem aquelas bandeirinhas no topo, permitindo que você escolha em que língua quer navegar? Quando você clica em uma delas, todos os textos do site mudam para a língua correspondente daquele país.

Isto é Internationalization, ou I18n.

Claro que estou sendo muito simplista, na maioria das vezes não é só os textos que mudam de um país para outro. Não podemos nos esquecer do formato da data, fuso-horário, padrões de peso e medida. E talvez o mais importante a moeda.

I18n e L10n, qual a diferença?

Internacionalização é preparar seu software para que pessoas de outros países e línguas possam usá-lo.

Localização (L10n) é adaptar o seu produto as necessidades de um país. É como pegar um site americano que só aceita pagamento via PayPal e adaptá-lo para aceitar boleto bancário, por exemplo.

O que tem de novo no Rails?

No Rails 2.2 este plugin de internacionalização será integrado ao seu código fonte.

Isto não significa que o Rails sofrerá grandes alterações. Na verdade quase nada muda no Rails, ele continuará sendo o mesmo framework de sempre, com todas as suas mensagens de validações em inglês e tudo mais.

A diferença é que se quiséssemos estas mensagem em português, ou em outro idioma, hoje, teríamos de criar um monkey patch para isto. Não posso deixar de citar como exemplo o famoso Brazilian Rails, que faz exatamente isto para traduzir as mensagens do ActiveRecord.

A novidade é que a partir do Rails 2.2 teremos uma forma padronizada e mais simples de fazer isto, usando uma interface comum.

Como isto vai funcionar?

Básicamente este gem é dividido em duas partes:

• A primeira acrescenta à API do Rails uma coleção de novos métodos, estes métodos basicamente servirão para acessar a segunda parte do gem.

• A segunda parte é um backend simples que implementa toda a lógica para fazer o Rails funcionar exatamente como funciona hoje, usando a localização en-US.

Okey, até aí, não mudou nada. A grande sacada é que esta segunda parte poderá ser substituída por uma que dê suporte à internacionalização que você deseja. Melhor ainda, uma série de plugins que serão lançados irão fazer exatamente isto.

E é claro que teremos um em português. Talvez uma adaptação do Brazilian Rails? Tomara que desta vez com um nome um pouco mais bonito…

No próximo artigo vou dar mais detalhes desta implementação, usando código.

À partir da próxima versão do Rails quando usarmos a opção :limit para colunas com números inteiros, em nossas migrations, estaremos nos referindo ao número de bytes, no MySQL e no PostgreSQL (no sqlite sempre foi assim).

O tipo da coluna no banco de dados dependerá da quantidade de bytes espeficida. Veja o trecho de código que identifica o tipo da coluna para o MySQL:

when 1; 'tinyint'
when 2; 'smallint'
when 3; 'mediumint'
when nil, 4, 11; 'int(11)' # compatibility with MySQL default
when 5..8; 'bigint'
else raise(ActiveRecordError, "No integer type has byte size #{limit}")

E para o PostgreSQL:

when 1..2; 'smallint'
when 3..4, nil; 'integer'
when 5..8; 'bigint'

Algumas correções de bugs que sairão na próxima versão do Ruby on Rails:

ActiveRecord

• Correção de uma colisão entre named_scope e :joins.
  Quando se usava with_scope junto com :joins todos os atributos da tabelas secundárias eram adicionados ao modelo da tabela principal.

• Partial updates não atualizavam o lock_version se nada foi alterado.
  Quando usávamos optimistic locking com partial updates, tinhamos queries extras quando na verdade elas não eram necessárias.

Performance é coisa séria, e um dos métodos mais usados para aumentar a velocidade de execução em códigos é o uso de cache. Quem nunca fez algo assim?

class Person < ActiveRecord::Base
  def age
    @age ||= um_calculo_muito_complexo
  end
end

Na próxima versão do Rails teremos uma forma mais elegante de fazer isto usando o método memoize (é memoize mesmo e não memorize). Vamos alterar o exemplo acima para funcionar com esta nova funcionalidade:

class Person < ActiveRecord::Base
  def age
    um_calculo_muito_complexo
  end
  memoize :age
end

O método age será executado apenas uma vez e o seu retorno será armazenado e retornado em futuras chamadas ao método.

Só existe uma diferença entre os dois códigos acima. No primeiro, como o método é executado todas as vezes, se o valor armazenado na variável @age for nil ou false o cálculo (muito complexo) será executado novamente até termos a idade da pessoa.

No segundo exemplo, o método age só será executado uma vez e o valor retornado será sempre devolvido nas próximas chamadas, mesmo que seja nil ou false.