Rails Summit Latin America 2009

Dias 13 e 14 de outubro rolou em São Paulo o Rails Summit Latin America 2009, evento organizado pelo Fabio Akita e pela Locaweb. É seguramente o maior evento da comunidade RoR na América do Sul. Esta é a segunda edição e, em relação ao ano passado, temos mais palestrantes e, no geral, o evento está bem mais interessante. Fiz uma cobertura do evento ao vivo, mas depois fiz um resumo das palestras que assisti.

* * *

A primeira palestra, “Ruby on Rails Insurgency”, foi do Chad Fowler (de longe esse cara me lembra o Seth MacFarlane) e ele fez uma introdução do eco-sistema cobrindo várias falácias que os concorrentes (ou os “trolls”) falam.

Alguns highlights:

If you’re gonna switch technologies (…) you might as well do things differently.

(…) Rails is about taking crap that you should be doing out of software development.

Support contract doesn’t guarantee anything.

Stop doing things you know are wrong. Stop.

– Chad Fowler

A segunda palestra, “On The Edge of Rails Performance”, foi do Gregg Pollack que apresentou algumas dicas de otimização do Rails e alguns plug-ins interessantes que, parafraseando o Gregg, “can just might save your ass”. Do blog dele e das poucas anotações que consegui fazer, os plugins são:

• Bullet: reduz o número de queries com alertas (no growl);
• Rails Indexes: tarefas do Rake para encontrar índices faltando;
• Scrooge: otimizador de queries SQL, para que se consulte apenas o que a página necessita;
• rack-bug: barra de ferramentas para debug de aplicações Rack implementada como middleware;
• memorylogic: adiciona o id e utilização de memória do processo nos logs do Rails;
• oink: faz parse do log a fim de encontrar actions que causam aumento do tamanho da pilha da VM;
• rubber: um plugin para Capistrano e para Rails que auxilia a publicação, gerenciamento e escalonamento de aplicações EC2;
• cloud crowd: gerencia processamento paralelo através de jobs em segundo-plano;
• Mad Mimi: aplicação de e-mail marketing com uma API muito interessante.

Na terceira palestra vim ver o Ilya Grigorik com a “Real-Time Ruby for the Real-Time Web”, que falou sobre Real-Time Ruby e coisas das quais sou fã como AMQP. Os slides já estão disponíveis. Na outra sala, o Carlos Brando está falando da construção de um framework com Ruby e de como o Rails funciona por dentro.

Na quarta palestra do dia, escolhi o Glenn Vanderburg, que falou do Tarantula, uma ferramenta para geração de testes fuzz em Ruby. Acabei passando um pouco por cima da palestra porque fiquei trabalhando pela VPN, mas achei especialmente interessante porque a Microsoft também está para lançar algo parecido para o mundo .NET e devo postar mais sobre o assunto em breve.

Depois fui na palestra do David Chelimsky, que passou várias dicas sobre Cucumber, RSpec etc. Destaque para a gem spork, que eu não conhecia e parece bastante útil quando usada junto com o Cucumber.

A palestra do Fabio Akita, como sempre, trouxe uma grande variedade de assuntos que levam algumas semanas para serem digeridos. Basicamente ele falou sobre a Teoria do Caos e como levá-la em consideração durante o gerenciamento de empresas, equipes e projetos pode fazer mais sentido do que trabalhar com modelos fechados, previsíveis e, portanto, limitados. Por isso que agilidade tem se mostrado eficiente onde paradigmas clássicos falharam. A teoria ajuda a justificar a necessidade de práticas como interações curtas, realimentação etc. Parafraseando o próprio Akita, o foco está no “porquê” e não no “como”.

Para finalizar, o Matt Aimonetti falou sobre o Ruby 2, Rails 3 e as tecnologias interessantes que os rodeiam. A plataforma promete coisas muito interessantes para o futuro.

* * *

No segundo dia, resolvi “cabular” as palestras e aproveitei que os palestrantes estavam pelo saguão para me juntar ao pessoal da InfoQ Brasil (Felipe Rodrigues e Ricardo Almeida) e entrevistar alguns. A InfoQ Brasil deve postar as entrevistas em forma de vídeo em breve, mas transcrevi dois trechos interessantes de perguntas que fiz para o Matt Aimonetti e o David Chelimsky. Por enquanto, é só uma prévia do que há por vir.

O Matt falou bastante das novidades do Ruby 2 e Rails 3 e destacou algumas das dificuldades que esse processo de evolução pressupõe:

InfoQ: As pessoas sempre lhe perguntam para quando elas podem esperar o Rails 3.0 ou o Ruby 2.0. Como você lida com isso?

Matt Aimonetti: Bem, o Ruby 2.0 vai levar algum tempo até que seja lançado, porque o Ruby Core Team ainda não começou a trabalhar nele. Então, após o Ruby 1.9.2, que deve ser lançado próximo do Natal, eles vão focar e começar a trabalhar nele. O Rails 3.0, por outro lado, é uma história diferente, porque nós estamos chegando perto do lançamento. Conforme eu disse na minha palestra, ele foi disponibilizado para os desenvolvedores de plug-ins e agora nós logo poderemos falar sobre a API. A maioria do trabalho já foi feita. Nós falaremos sobre a integração destes diferentes aspectos e nos certificaremos que ele é estável o suficiente para que as pessoas possam usá-lo.

É sempre um desafio trabalhar com open-source, porque tem-se voluntários, pessoas trabalhando que não são pagos para isso e elas trabalham em projectos diferentes. Você tenta manter os deadlines, mas é realmente complicado ter um deadline, então…

InfoQ: Você considera que não ter um deadline é uma barreira de entrada para que as empresas comecem a utilizar o Rails? Isso é um problema? A comunidade está preocupada com isso?

MA: Eu não acho que seja realmente um problema, porque nunca anunciamos um deadline. O que existe uma idéia de deadline… algo que gostaríamos de atingir. Isso não quer dizer que podemos realmente atingí-lo. Agora, as empresas gostam de estabilidade. Você não vai querer falar do (Rails) 2.0 uma vez que nós ainda estamos migrando para o 1.9. E o 1.9 é a direção que devemos seguir. As pessoas ainda utilizam o 1.8 porque elas consideram que ele é estável, então você precisa fazer as coisas aos poucos.

Você não vai querer lançar algo muito cedo e ele está quebrado. Nós não queremos lançar o Rails 3 cedo e depois as pessoas não conseguem migrar, pois isso não faria nenhum sentido. Então nós queremos nos certificar de que a comunidade está andando connosco e o produto é estável o suficiente antes de nós o lançarmos. E eu acho que isso é algo que as empresas valorizam.

O David Chelimsky, por outro lado, focou bastante em testes e estava particularmente curioso em como o RSpec e outras bibliotecas de testes influenciaram as que existem fora da plataforma Ruby e como está a adoção da cultura de BDD e TDD no Brasil. Aproveitei o assunto para falar de testes fuzz:

InfoQ: O Glenn Vanderburg falou ontem sobre o Tarantula na sua palestra e nós estamos nos perguntando qual é sua opinião sobre Testes Fuzz. Eles tem sua utilidade?

David Chelimsky: Totalmente! Mas eles tem sua utilidade. Um dos problemas que todos temos é que há várias formas de se testar que possuem cada uma seu valor dentro de um mesmo projeto. E eu acho que as pessoas tendem a procurar uma solução única e definitiva que elas possam sempre aplicar, mas o desafio é realmente achar a combinação ideal para um projeto específico. E eu também acho que muitas pessoas acabam dizendo que “nós tivemos sucesso em determinado projeto utilizando uma determinada combinação de ferramentas e técnicas, então devemos utilizá-las em todos os próximos projetos”, mas elas podem não ser as ideias nestes próximos projetos.

No caso do Tarantula, eu pessoalmente ainda não o utilizei, só ouvi falar dele. E eu não estive na palestra do Gleen porque a minha era logo depois da dele, mas eu conversei com ele esta manhã. O que ele me disse foi que na sua empresa, a Relevance, eles utilizaram o Tarantula em muitos projetos e não houve um único caso em que a ferramenta deixou de achar alguma coisa que eles deixaram passar. O Tarantula tem um baixo custo de entrada: só leva 10 minutos para ligá-lo na sua aplicação. Se você só tem 10 minutos para testar e ele encontra alguma coisa, então você já saiu ganhando.

InfoQ: Mas você não acha que existe o perigo de as pessoas pararem de pensar nos seus testes e passarem a confiar apenas na ferramenta para fazê-los para eles?

DC: Totalmente. Mas se deixássemos de fazer tudo por causa do perigo, nenhum de nós estaria escrevendo Ruby hoje. É necessário uma discussão pública a respeito disso e as pessoas precisam compartilhar suas experiências.

Certamente há esse perigo e as pessoas são pegas a todo momento porque elas ouvem “você deveria usar isso”, mas elas não entendem o real sentido do que é aquilo. Então eu posso imagina que uma pessoa que não faz nenhum outro teste além de testes fuzz terá, sim, problemas.