Os envolvidos com Rails já sabem que no domingo passado terminou o Rails Rumble. Uma competição onde equipes de até 4 pessoas criam aplicações
dentro de um período de de 48h.
As aplicações são julgadas nos critérios de Inovação, Aparência, Utilidade e Acabamento. E neste ano 300 equipes estão competindo nestes pontos e concorrendo a vários prêmios legais.
Neste ano eu tive o imenso prazer de participar da competição e vou contar um pouquinho como foi essa experiência.
Preparação
Montamos nossa equipe bem antes do evento, formada por: eu, João Vitor, Jeffry Degrande, Bruno Alves.
Logo que todos toparam encarar essa maratona a tarefa foi decidir o que ser feito.
Como todo a equipe está em Belo Horizonte decidimos que a melhor forma de colocar as coisas na mesa seria através de reuniões presenciais. A primeira delas foi para a decisão do tema.
Antes da reunião cada pessoa levantou uma série de idéias e no dia fomos descartando o que era complexo de mais ou que não tinha interesse. Ficamos com 3 idéias principais mas no final o que escolhemos foi a idéia do Superfolio
A idéia
Basicamente a ferramenta é uma forma de resolver a criação de site profissionais. Como assim? Toda pessoa precisa de um curriculum, no entanto eles são trabalhosos de serem feitos, ficam desatualizados e para várias profissões não significam muito (ex.: para um desenvolvedor Ruby seu github pode fazer mais diferença que seu CV).
Por outro lado todo profissional precisa de um site na internet com informações bem parecidas com a de um CV, no entanto um site abre um mar de possibilidades. Possibilidades como facilidade de atualizações, anexar imagens e principalmente links para redes que possam interessar seus contratantes e clientes (ex.: um desenvolvedor Ruby pode linkar seu Github e seu Blog). Outro ponto que conta muito em qualquer contratação são sua recomendações, este também é um ponto que um site pode resolver e um CV não.
A idéia é bem simples, permitir que qualquer profissional interessado em criar seu site possa acessar um painel administrativo e definir sua biografia, experiências, fotos de projetos, links externos e aceitar recomendações.
Como a ferramenta é para criação de um site de verdade também é necessário que exista a possibilidade da customização completa do layout, ter um domínio próprio e poder monitorar os acessos (via Google Analytics).
Ficou curioso? Acesse o meu superfolio e veja tudo que pode ser feito: http://daniellopes.me/
Planejando a execução
Com a idéia levantada começamos a fazer encontros semanais na Dito Internet.
Diferente de um projeto de software convencional, desta vez nós sabíamos todas as features e não tínhamos a opção de ir criando o sistema e recebendo feeback. Por essa razão a opção de várias reuniões longas foi tomada ao invés do modelo Agile de reuniões.
Eu fiquei responsável pela interface, então antes mesmo do evento eu fiz todos os mockups necessários para termos a visão completa da aplicação. Com os mockups detalhamos algumas dezenas de tickets no Pivotal Tracker.
Dividindo tarefas
Alguns pontos precisavam ser estudados antes do evento já que no dia não poderíamos aprender nada, apenas executar.
Como dito anteriormente, eu fui o designer então além de todos os mockups também fiz uma grande pesquisa de referência para o layout, pois não haveria tempo para “inspiração”. Com base nos mockups também foi possível identificar quais pontos do HTML seriam complexos então achei solução para estes pontos e também bibliotecas de JS que deveriam ser usadas (jQuery, facebox, jquery-tools e etc).
Bruno ficou responsável por configuração dos servers então ele montou uma receita do que precisaria ser seguido no dia do evento. Também contratou uma VPS para os testes e estudou o Base-App, que automatiza o deploy.
Jeffry ficou com a parte de customização do layout e temas, ele optou pelo Liquid e se especializou neste ponto. Também cuidou de estudar a melhor alternativa para integração contínua (escolhido foi o CI Joe).
No site também temos uma busca complexa na home que pesquisa por qualquer termo no site dos usuários. Para isso João Vitor ficou a cargo das pesquisas e por final usamos o Solr.
Logística
Antes do evento também fizemos a organização do que precisaríamos no dia e quais tipos de refeições deveriam ser feitas para evitar o cansaço.
Para o local do evento o Bruno cedeu o escritório da Dito que conta com uma infra-estrutura muito boa e cercado de restaurantes.
Foi decidido que as principais refeições seriam feitas nesses restaurantes e ali faríamos as reuniões de retrospectiva dos mini-sprints.
Tudo foi muito bem planejado e a único complicador foi a falta de um chuveiro na Dito 
Execução
Uma coisa já era fato. O prazo é curto mas todos os membros da equipe são profissionais e nós não sacrificaríamos as boas práticas por causa do tempo.
Ficou definido que usaríamos métodos ágeis, pair pogramming quando necessário, deploy contínuo, integração contínua e principalmente Test Driven Development.
Jeffry montou um server de integração contínua com CI Joe que ficava ligado ao televisão de 42 polegadas da Dito. Todos os pushs para o github do projeto e builds ficavam visíveis e com um som diferente tocando para cada fato. Assim sabíamos ao certo quando os testes paravam de funcionar.
Para deploy usamos o famoso Capistrano. Mas antes do evento fizemos um tunning do meu template de app Rails, o Base-APP. Com ele o Capistrano já fica muito bem configurado além de várias outras coisas que melhoramos nele mas que são comuns para qualquer app (o projeto é open-source e MIT). Também foi usado o Hoptoad para monitoração de exceptions em produção.
Pair programming foi essêncial para achar os erros mas não para planejamento pois tudo já havia sido planejado antes. Também usamos pair programming para evitar o sono.
Para TDD decidimos pelo Rspec com Steak. Uma boa cobertura é essencial, principalmente em um ambiente tão apertado como o Rumble e testes de aceitação fizeram toda a diferença.
Tendência ao amadorismo
Nós, seres humanos, gostamos de colocar a culpa do nosso amadorismo em vários fatos mas nunca em nós mesmo. No Rumble a maior desculpa para a “tosqueira” é o tempo.
Já fui questionado várias vezes se deve ser feito TDD quando o tempo é apertado e vou compartilhar um pouco dessa experiência no caso mais extremo: Rails Rumble.
Não seguimos TDD a risca no projeto mas seguimos desenvolvimento com testes o tempo todo.
Na madrugrada de domingo, já extremamente cansados, estávamos fazendo vários push’s para o Github simultaneamente e em um certo momento alguns testes começaram a quebrar.
Não corrigimos isso na hora e ficamos com 9 testes quebrando. E nesse momento eu estava no HTML e o Bruno e Jeffry implementando novas features não relacionadas aos tests quebrados. Até que o Jeffry largou tudo para consertar os tests. Mas o Jeffry era o único da equipe com conhecimento do Liquid então o Bruno resolveu assumir o “pepino”.
Alguns dos testes foram corrigidos com meu HTML mas o mais complicado era um teste que estava falhando por algum motivo estranho que não era simples de achar. No fim, Bruno descobriu uma falha grave no nosso algoritmo de redirecionamentos que permite a usuário ter seu próprio domínio (daniellopes.me ao invés de de superfolio.net/daniel).
O resumo é que se não tivéssemos testes não teríamos conseguido achar esse bug e se a equipe tivesse deixado o caos tomar conta o sistema teria ido para o ar com este bug grave. Atualmente o sistema está rodando bem e sem notificar nenhuma exception.
Lições aprendidas
O Rumble serviu para colocar a prova todos os nossos conhecimentos de Ruby e desenvolvimento de software. Eu, pessoalmente, pude tirar várias lições (e acho que meu amigos de equipe vão concordar).
Amadorismo
Primeiro, o tópico anterior: Falta de tempo não é desculpa para amadorismo.
Equipe
Outro fator marcante foi a importância da equipe. Mais do que em qualquer projeto, no Rumble, pessoas são mais que processos e manter a comunicação, a amizade e pensamentos na mesma linha em 48h, sem descanso, é um mega desafio.
No nosso caso a equipe se deu muito bem, como eu nunca tinha visto antes. Apesar de nunca termos trabalhado todos juntos houve uma coesão muito grande.
Todos os membros trabalharam como loucos e suaram a camisa pelo projeto. Foi a melhor definição de uma equipe auto-gerenciável que já vi (kudos para o Jeffry, Bruno, João e eu mesmo 
).
Descanso
Outra lição é que sempre é preciso haver descanso, não importa o quão apertado é o deadline você não pode entrar no modo “Hero” (como dito no Rework). O estado onde resolver o problema se torna questão de honra, não importando mais nada.
Se você fica muito tempo olhando um problema você nunca vai resolve-lo se não descansar um pouco ou pedir ajuda. Toda vez que a coisa agarrava compartilhávamos o problema com a pessoa mais próxima e um olhar externo resolvia rapidamente.
Design
Outro ponto que ajudou muito foi ter uma equipe de Railer’s experts junto com um designer com conhecimento de Git, HTML, JS e testes. Ou seja, alguém focado no frontend mas com visão geral das tarefas. (depois farei outro post sobre o verdadeiro papel do Design em Software)
Em vários momentos quando eu passava do photoshop para o html nossos testes de aceitação quebravam no protótipo já existente. Conseguir resolver essas coisas sem precisar chamar outro desenvolvedor ajudou muito.
Também foi importante o designer conseguir “baixar” e trabalhar corretamente com o código usando o Git, então o fluxo e forma de compartilhamento era igual entre toda a equipe e eficiente.
A parte do design também guiou as funcionalidades, fazendo que conseguíssemos identificar problemas graves antes de implementarmos.
Refactoring
Ficou bem claro que o mais importante é colocar funcionando e que depois haverá tempo para ajustes. Pensando dessa forma é muito importante manter um bom suite de testes para que você possa voltar e refatorar depois e manter a confiança do funcionamento.
O sistema possui vários pontos que podem ser melhor arquitetados mas o que importa é que ele está online e com nosso suite de testes podemos fazer essa refatoração nos pontos que importam.
Conclusão final
Apesar do cansaço (e da falta de banho eu saí do evento extremamente motivado e satisfeito com o resultado. A equipe foi extraordinária e a competição uma experiência que não tem preço.
Não importa o resultado (bem… importa um pouco a verdade é que conseguimos entregar em 2 dias um CMS relativamente complexo e mantendo a qualidade do trabalho.
Agora é conseguir os usuários que vão fazer uso do sistema de fato. Passando o efeito que chamo de “Onda Sapo” (usuários curiosos que só entram no sistema para sapear e não para usar mesmo acredito que o sistema poderá evoluir para algo bem funcional. O exemplo é o meu próprio site em daniellopes.me .
Também decidimos manter a equipe e fazer encontros frequentes para melhorar o Superfolio como um time.
Com certeza ano que vem participarei novamente e caso passemos para final vamos precisar da ajuda de vocês 
