Adolfo Sousa

Além da excelente palestra do Obie Fernandez, eu assisti a outras memoráveis apresentações no Rails Summit 2008. Aqui vai a trilha que segui no evento e o que mais me impressionou em cada uma delas:

• David Heinemeier Hansson (DHH) - O criador do Rails participou do evento respondendo a perguntas da platéia por vídeo-conferência. A meu ver, a pergunta mais interessante foi a respeito de como a equipe que mantém o framework lida com as sugestões de novas features. A resposta pode ser interpretada como “nós respiramos Lean”; DHH contou que eles simplesmente incorporam ou implementam somente o que o framework necessita e se faz prioritário. Se não é necessário naquele momento, não fará parte do Rails, não importando se está na moda ou qualquer outra coisa.
• Chad Fowler - o escritor de “My job went to India” fez uma palestra muito motivadora. Com o título “Being Remarkable”, Chad deu dicas sobre como nós, desenvolvedores de software, podemos nos destacar. Dentre as dicas, gostei das “machuque-se” e “seja o pior músico da banda”. A primeira diz respeito a nos colocarmos em situações em que nossos conhecimentos, habilidades e capacidades são postos à prova. A segunda nos diz que trabalhar com programadores melhores que nós é uma excelente maneira de aprender e evoluir. Eu nunca havia visto uma apresentação do Chad Fowler, mas agora posso dizer que é sensacional.
• Dr. Nick - muito boa a apresentação desta figura simpática e brincalhona. “Path to awesomeness” é a palestra a que eu gostaria de ter assistido, juntamente com a “Being Remarkable” do Chad Fowler, no comecinho da minha curta carreira de programador. Ele, basicamente, deu dicas a respeito de como ser um bom profissional na nossa área. São elas: 1) aprenda sobre sistemas de versionamento de código (svn e git, atualmente) 2) aprenda a testar 3) comece um blog 4) aprenda a criar aplicações 5) melhore o seu código. Como julgo estas dicas muito importantes e tenho acréscimos a fazer, vou falar mais sobre isto num próximo post.
• Jay Fields - falou sobre a imaturidade dos testes de desenvolvedores. O palestrante fez uma interessante análise das mais famosas ferramentas de testes existentes para ruby/rails. Eu não conhecia o Jay Fields nem tenho muita experiência com ruby e rails, mas me pareceu que ele sabia muito bem o que falava. Expôs claramente pontos positivos e negativos de cada ferramenta, bem como suas opiniões. Respondeu a perguntas e não ficou em cima do muro ao citar quais são as ferramentas que ele usa e prefere: para testes unitários, Expectation. Para testes integrados, Rspec. Para smoke tests, Selenium. Outro ponto importante que o Jay Fields fez questão de reafirmar repetidas vezes é que a sua suíte deve rodar muito rapidamente. Para ele, uma suíte que demora mais de 1 segundo já é problemática e deve ser melhorada.
• David Chelimsky - David é o atual mantenedor do Rspec e falou, na sua primeira apresentação, sobre BDD. Quando comecei a ler sobre BDD, ainda estava tentando fazer TDD. Lá no comecinho, tinha muita dificuldade para começar a escrever um teste. Sempre parava e falava “e agora? que teste eu escrevo? o que eu faço?”. E o que me ajudou muito a vencer esta limitação foi escrever os meus testes à BDD com “should…”. Pra mim foi mais fácil desta maneira porque me ajudava a pensar a funcionalidade de fora pra dentro. Era mais fácil modelar e começar a escrever desta forma. E o David falou disso na sua excelente e didática a palestra.
• Danilo Sato - falou das motivações que o levaram e das dificuldades que teve quando começou a escrever testes automatizados para os seus programas. Algumas das importantes lições citadas pelo Danilo são: testes grandes são difíceis de manter (escreva testes pequenos no estilo arrange-act-assert), é bom cobrir a funcionalidade do ponto de vista externo, código de teste também é código e cuidado com mocks para libs externas.
• Vinícius Manhães Teles - a apresentação foi dividida com o Carl Youngblood da Surgeworks, que falou sobre o ambiente rails aqui no Brasil. Eu nunca tinha assistido a uma palestra do Vinícius, apesar de já o conhecer pelo seu livro de XP.  Foi uma ótima apresentação, mas o que me impressionou mesmo foi ouvi-lo falar sobre empreendedorismo. É impossível descrever ou expressar o valor daquilo falado por ele. É admirável o que o Vinícius fez como pioneiro e evangelizador de XP e vem fazendo, com o pessoal da Improve It, ao inovar o nosso mercado de software.

A primeira edição do Rails Summit foi um incontestável sucesso pelo valor de tudo aquilo falado pelos palestrantes. Tivemos verdadeiras aulas de empreendedorismo, inovação, idéias e agilidade. Tenho certeza de que todos os participantes do evento aprenderam muito. Mais uma vez, meus parabéns à Locaweb e ao Akita pela histórica realização.

Vou relatar aqui uma das palestras com as quais mais me impressionei no Rails Summit 2008, brilhantemente organizado pela Locaweb e pelo Fábio Akita. Pra quem não o conhece, Obie Fernandez foi um dos pioneiros e responsáveis pela adoção do Ruby on Rails na Thoughtworks, escreveu o famoso “The Rails Way” e fundou a Hashrocket. Esta figura simpática, didática e inovadora nos presenteou com o Keynote de encerramento do evento.

Obie listou os 4 princípios do Manifesto Ágil e explicou o que faz para aplicá-los em sua empresa. Em suma, foi uma aula a respeito de agilidade e boas práticas para quem já trabalha ou pretende trabalhar seguindo esta filosofia. Com vocês, o “Hashrocket Way”:

1. Valorizar indivíduos e interações mais do que processos e ferramentas

Nesta parte da apresentação, ele falou muito a respeito das pessoas com as quais trabalha. Mostrou muitas fotos do seu escritório (com vista para o mar), das reuniões diárias e alguns vídeos engraçados do pessoal se divertindo enquanto trabalhava. O mais marcante, porém, foram as suas idéas a respeito de pair-programming. Para Obie, é fundamental ter um monitor com dois teclados e dois mouses para se programar em par. Isto impede que a pessoa mais imperativa domine o teclado e força a participação das duas pessoas. Falou que uma pessoa pode escrever um teste e a outra o pedaço de código para passar aquele teste. Ficou claro que ele enxerga esta prática, quando bem aplicada, como um bem para as pessoas, já que elas aprendem e crescem com mais rapidez, as tornam mais produtivas e, por conseqüência, realizadas. Outro ponto interessante é o número de pessoas nos seus times: segundo Obie, em um time com mais de 4 pessoas você já pode ter problemas de comunicação e perder o auto-gerenciamento. Seus times são de 2 ou 4 pessoas. E sobre contratações, ele contou que publica um post no seu blog, as pessoas respondem, e ele convida algumas para trabalhar para eles por 1 semana. Ele não se importa se o sujeito tem bilhões de diplomas e títulos, se tem 30 anos de experiência ou se já passou por muitos empregos. Ele quer ver como a pessoa se comporta trabalhando num projeto real e em par. Ele não espera perfeição, mas a candidato deve ser capaz de trabalhar em pares, aprender rapidamente e lidar com a pressão de um projeto verdadeiro.

2. Valorizar software funcionando mais do que documentação extensa

Aqui ele deu o recado citando a divertida palestra de um rapaz chamado Brian Liles: TAFT - Test All The Fucking Time. É bem curta e divertida, assistam!

3. Valorizar a colaboração do cliente mais do que (re)negociação de contrato

Ele mostrou uma espécie de contrato em que o cliente não é obrigado a pagar pelo software caso não fique satisfeito. Porém, deixou bem claro que é preciso se proteger. Se o cliente não é obrigado a pagar, ele também não pode processar a Hashrocket e pedir uma indenização maior do que pagaria. Depois, mostrou fotos de alguns clientes realmente trabalhando com a equipe em alguns projetos especiais que eles chamam de “3, 2, 1, launch”. São projetos que eles fazem em 3 dias, desde que o cliente esteja presente e que eles tenham a parte visual da aplicação já definida; este é o único caso em que ele não segue uma prática da XP (design simples).

4. Responder às mudanças mais do que seguir um plano

Neste final da apresentação, ele mostrou a ferramenta Pivotal Tracker. Falou que sempre estimam as tarefas em pontos (com tamanho máximo de oito) e também sobre a importância das reuniões diárias.

Como não consegui os slides, estou escrevendo a partir daquilo que lembro e anotei, e com a ajuda do post que acabo de ler no blog do próprio Obie Fernandez. Pretendo escrever mais a respeito das outras palestras a que assisti e gostei no Rails Summit 2008.

Até mais!!!