Neste fim de semana, aconteceu o RejectConf SP 2007 e eu tive o prazer de estar presente. Dezenas de pessoas interessadas em Rails compareceram ao evento e ouviram palestras sobre os mais diversos assuntos.

O Akita abriu a conf contando um pouco da trajetória do Ruby e do Rails do início até os dias atuais. Falou do conceito de menos é mais, empregado pela 37 signals, empresa de onde surgiu o framework Rails. Sobre este conceito, recomendo a leitura do livro Getting Real(traduzido), e assistir esta palestra, feita por um professor de psicologia, explicando o paradoxo da escolha.

RSpec foi outro assunto que me interessou bastante. Apesar de ter sido um pouco rápido, o Danilo Sato conseguiu mostrar na prática um exemplo usando rspec com rails. Na minha opinião, o rspec deve crescer bastante e, talvez, ser mais utilizado que o xUnit. Para quem tem dúvidas sobre se vale a penas investir no assunto, veja o que Dave Astels tem a dizer nesta palestra.

Apesar de já ter lido alguma coisa sobre o JRuby, não tinha tido a oportunidade de mexer com ele ainda. Por isso, achei bem legal ver o Fabio Kung, da Caelum, mostrar as possibilidades de integração do Ruby com o Java. Com certeza, as implementações do JRuby e do IronRuby abrirão muitas portas para o Ruby. Vamos ficar de olho nelas :-)

Pra fechar, o Carlos Brando fez uma palestra muito motivadora nos chamando para a ação. Falou sobre inércia e comodismo, que são fatais para o desenvolvimento de qualquer pessoa.

Resumo da ópera: o evento foi excelente e todos os palestrantes estão de parabéns. Ficou claro para mim que Rails já não é mais brincadeira, e sim uma realidade no mercado brasileiro, e a tendência é aumentar. Para quem ainda não vê benefícios nem tem curiosidades em Rails, acho que deveriam olhar o assunto com mais calma.

O próximo evento que participarei será o RioOnRails, no dia 8/dez. Sei também que haverá o MinasOnRails no dia 1/dez, mas infelizmente, não poderei ir.

Segundo este post do blog de segurança de Ruby on Rails, o plugin Restful_Authentication contém um falha de segurança quando se utiliza a funcionalidade de ativação de um cadastro.

De acordo com o post, o plugin aceita receber o parâmetro activation_code vazio assim:

http://localhost:3000/user/activate ou http://localhost:3000/activate/?activation_code=

dependendo das rotas criadas.

Isto geraria a seguinte consulta SQL:

SELECT * FROM users WHERE (users.activation_code IS NULL) LIMIT 1

A pessoa, então, poderia se logar sem senha com a primeira conta que tivesse o activation_code vazio, ou seja, com um dos usuários registrados.

Pelo post, o dono do plugin já foi notificado e o mesmo já providenciou a correção.

Se você usa, ou pensa em usar este plugin em algum de seus projetos, vale a pena pegar a última versão ou trocar a primeira linha do método de ativação para:

self.currentuser = params[:activationcode].blank? ? :false : User.findby_activationcode(params[:activation_code])

não esquecendo de acertar os nomes dos models caso tenha alterado.

Lendo outros blogs hoje, encontrei este quiz sobre otimização de buscadores. O teste é muito interessante e contém perguntas básicas, intermediárias e avançadas.

Ele é um pouco grande, tem 75 perguntas, e demora um pouco para fazer, mas recomendo tanto para aqueles que já tem conhecimento sobre otimização de buscadores quanto para aqueles que querem aprender sobre o assunto.

A quantidade de "mágica" existente no Rails pode auxiliar em muito o desenvolvimento de sites em termos de velocidade e facilidade, mas também pode machucar feio o site em termos de performance, como mostra este post. Até que ponto o uso de "mágicas" é prejudicial ou não no desevolvimento de sites? Gostaria muito de saber a opinião de vocês sobre esse assunto.

"Mágica", para aqueles que não conhecem o termo, são partes de código que executam tarefas repetitivas ou com grande chance de erros ou ainda que facilitam a vida do usuário. Por exemplo, quando se usa o método find de um model para localizar um registro no banco de dados, o Rails gera um SQL por debaixo dos panos para encontrar o registro solicitado. Ou quando se usa o método url_for para gerar uma URL, o Rails analisa a tabela de rotas para poder gerar a URL correta.

O problema nestes exemplos é que nem sempre o SQL gerado é o mais otimizado. E para que fazer o Rails perder tempo analisando a tabela de rotas se a única coisa que se quer, na maiorias das vezes, é colocar uma url do tipo /controller/action/id?

Sei que este assunto não é restrito ao Rails, mas, no Rails, parece ser levado ao extremo e ser um pouco a causa de tantas pessoas gostarem deste framework.

Para quem é um pouco neurótico com performance como eu, Scott Becker fez um excelente plugin, o AssetPackager, para comprimir e agrupar arquivos JS e CSS. O plugin foi baseado no artigo de Cal Henderson chamado Serving Javascript Fast e utiliza o Javascript Minifier criado por Douglas Crockford e portado para o Ruby por Uladzislau Latynski.

O plugin permite que você desenvolva sua aplicação com quantos arquivos JS e CSS você quiser e, na hora de passar sua aplicação para produção, basta rodar um rake task para comprimir e agrupar seus arquivos baseado na configuração que você faz em um arquivo YAML. O helper que se utiliza nos views chama os arquivos separados, se estiver em desenvolvimento, e chama os arquivos agrupados, se estiver em produção.

Outra característica deste plugin é a criação dos arquivos agrupados com um timestamp ou SVN Revision, se existir, no prórpio nome do arquivo e não como querystring, uma vez que nem todos os browsers colocam arquivos com querystring no cache. Dessa forma, o browser pode cachear o arquivo correto e, caso haja alguma alteração, o nome do arquivo mudará forçando o browser a requisitar a nova versão.

Para mim, comprimir e agrupar esses arquivos é essencial para economizar banda, reduzir a quantidade de requests e acelerar o carregamento das páginas. Ainda pode resolver a questão de versão incorreta desses arquivos no cache do browser do usuário. Realmente muito bom!