2010 May

Atualizado 26/05: Ajustei o artigo de acordo com os comentários do Tapajós :-)

Essa dica é meio velha, mas como muita gente ainda desconhece vamos falar dela. Um recurso que surgiu no Rails 2.2 é o suporte a ETAG. Se você ainda não usa, deveria. Isso porque é super simples, vai melhorar a performance do seu site para seus usuário e sai praticamente de graça, sem efeitos colaterais.

Meu blog não é muito diferente da maioria. Tem uma página principal com os posts mais recentes, uma barra lateral dando acesso a arquivos, posts mais antigos, últimos comentários e outras coisas.

Hoje resolvi fazer um pequeno ajuste cosmético. Até agora eu colocava uns 10 posts com um texto de introdução de cada. Porém na maior parte dos casos acho que isso não era muito útil pois meus posts costumam ser grandes e só alguns trechos de texto não eram úteis. Além disso só 10 posts na homepage significa que muitos (deste mesmo mês) eram arquivados rápido demais. E pouca gente vai atrás de posts arquivados.

Atualizado 25/05: A versão 2.3.7 saiu rápido demais, tentando corrigir um bug e acabou expondo outro. O Jeremy Kemper (@bitsweat) se desculpou pelo lapso e acabou de soltar, finalmente, a versão estável 2.3.8

Atualizado 24/05: Parece que havia alguns bugs ainda no novo suporte a XSS por isso o pessoal lançou uma correção na forma da versão 2.3.7

O pessoal do Rails Core acabou de lançar o Rails 2.3.6, provavelmente a última revisão da série 2.3 antes do lançamento da esperada versão 3.0 (atualmente em Beta 3). Ela trás algumas funcionalidades para servirem de “ponte” entre as duas séries. Vejamos algumas modificações.

Para começar, instale essa nova versão:

gem install rails --version=2.3.8

Me ocorreu esses dias que nunca falei sobre organização de código em Ruby. Diferente de Java, o Ruby não obriga que você separe tudo em namespaces, diretórios e sub-diretórios. Tecnicamente é válido ter um único arquivo com milhares de linhas de código, dezenas de módulos e classes dentro. Para o Ruby não faz diferença.

Porém, para nós desenvolvedores, essa organização faz toda a diferença na hora de dar manutenção ou mesmo de aprender mais sobre determinado projeto. Não existe um “padrão” que todos devem seguir, mas observando projetos open source mais maduros, podemos tirar algumas lições. Neste caso, vamos observar como o pessoal do Ruby on Rails (3.0 beta) organizou o código.

*Atualização 22/05:" A pedidos acrescentei o botão de Doações do Paypal também. Em breve vejo se coloco do PagSeguro. Valeu pessoal! Hoje resolvi passar o fim da tarde aqui no Starbucks do Shopping Morumbi. Não tão confortável quanto eu esperava mas é bom mudar de ares um pouco. O que tem ocupado meu tempo nesses últimos dias é a pesquisa para preparar minha palestra do RailsConf, que já está chegando! Será no dia 9 de junho, às 16:25h, horário em Baltimore. O tema é Making Rails really Restf...

Uma coisa que era meio que uma “gambiarra” (um “after thought” seria mais adequado) era o suporte a Engines. Desde a primeira versão, o Rails tinha suporte a plugins, que você coloca no diretório “vendor/plugins”. É bom para carregar bibliotecas. Uma evolução disso é o uso de RubyGems, para desacoplar a evolução dos projetos de forma independente.

Porém, quando desenvolvemos mais de uma aplicação, eventualmente gostaríamos de poder reusar partes de uma aplicação em outra. Por exemplo, um sistema de comentários, poderia servir para várias aplicações no estilo de CMS. Isso significa um conjunto de arquivos, por exemplo, composto por um CommentsController, suas Views, o model Comment, sua migration, seu conjunto de rotas e talvez alguma configuração.

Uma forma que alguns tentam é via Generators. Poderia ser uma gem que você executa dentro do seu projeto e ele gera esses arquivos e mescla aos existentes no seu projeto. É uma solução razoável para coisas simples e genéricas, mas é muito ruim se queremos algo testável, fácil de manter depois.

Lá pela era do Rails 2.1 mais ou menos, surgiu um projeto que tentava embutir uma infra-estrutura de Engines. Basicamente significava a possibilidade de ter a árvore “app/controllers”, “app/models”, “app/views”, “config” dentro de um plugin/gem e ele se mesclar ao projeto principal sem precisar mesclar os arquivos no mesmo lugar. Pessoalmente eu nunca achei que ele funcionava muito bem, era difícil se integrar ao processo de boot do Rails, tinha muito monkey patch envolvido, enfim, não ficava algo muito limpo. Além disso, se a versão do Rails mudava, provavelmente esse suporte se quebraria.

A partir do objetivo de ser um framework mais agnóstico a outros sub-frameworks, o Rails 3 trouxe uma limpeza na sua funcionalidade de Javascript.

Até o Rails 2.3.5 ele vinha embutido com Prototype e Scriptaculous. Em si, isso não seria um grande problema, mas ele também vinha com uma biblioteca chamada RJS que habilitava helpers como link_to_remote, remote_form_for, button_to_remote. Esse tipo de função gerava HTML desta forma:

<form action="/tasks" class="new_task" id="new_task" method="post" 
  onsubmit="new Ajax.Request('/tasks', {asynchronous:true, evalScripts:true, 
  parameters:Form.serialize(this)}); return false;">
  <div style="margin:0;padding:0;display:inline">
    <input name="authenticity_token" type="hidden" 
      value="ktEpYwrizNA/bMEydEr9PdHDy1KMEgSVZxScc827gOg=" />
  </div>

Até agora eu não havia entendido como que o iPhone OS 4 iria conseguir efetivamente fazer multitasking (multitarefa). Para não consumir bateria eu imaginava que algo como um sinal de SUSPEND seria enviado ao processo para que ele suspendesse as atividades enquanto permanecesse em background, daí quando você escolhesse ele de novo na barra de processos em execução ele voltaria a “acordar”. Se o aplicativo precisasse executar alguma coisa enquanto estivesse suspenso, ele enfileiraria uma tarefa assíncrona que o sistema operacional se encarregaria de executar, enquanto o aplicativo em si permaneceria suspenso no fundo.

Só que isso não explica como o sistema conseguiria economizar a quantidade limitada de RAM, pois mesmo suspenso um processo continuaria a consumir memória para permanecer aberto. Eu imaginava que uma forma seria serializar o estado atual da memória, fazer um “dump” num arquivo e quando o aplicativo reabrir ele poderia recarregar esse estado gravado. Mas isso seria complicado e não necessariamente confiável, por exemplo, se em memória houvesse ponteiros para recursos de I/O como sockets ou arquivos.

Simplesmente manter os aplicativos suspensos em memória não é viável porque rapidamente a memória RAM seria consumida. O sistema operacional precisaria ficar fazendo “faxina” o tempo todo matando aplicativos mais velhos para que outros possam ser abertos, mas nem isso é perfeito e de tempos em tempos a própria atividade de coletar o lixo poderia deixar o sistema com sensação de “lento”.