Adolfo Sousa

Na última semana, eu e mais três Locawebers (Antônio Marques, Fernando Amorim e Nando Vieira) estivemos em Baltimore para a Railsconf 2010. Com mais de 1000 participantes, incluindo grandes expoentes de importantes comunidades de software, é a maior conferência de Ruby on Rails do mundo.

Durante os 4 dias do evento, muitas palestras aconteceram. Mais importante do que escrever sobre cada uma delas, é falar um pouco sobre algumas novidades e sobre o que mais me impressionou na conferência:

• Rails 3 - talvez a maior expectativa da comunidade fosse o anúncio do lançamento do Rails 3. Ela não foi completamente atendida, porém foi lançada a versão beta 4 do framework. Adicionalmente, Gregg Pollack anunciou uma série de screencasts explicando as novidades da versão 3. Vale a pena conferir: http://rubyonrails.org/screencasts/rails3/

• Keynotes - fiquei impressionado com a quantidade e com a qualidade da grande maioria deles. Destaque para a apresentação do Yehuda Katz sobre “fazer”, dando dicas de como contribuir para projetos open source (http://en.oreilly.com/rails2010/public/schedule/detail/14132). Acredito que todos os keynotes podem ser encontrados no site oficial do evento: www.railsconf.com

• Palestras - assisti a algumas palestras ruins, algumas boas e outras excelentes. Entre as melhores a que assisti, estão as seguintes:

- Rocket Fueled Cucumbers: sobre como escalar testes de aceitação. A apresentação foi muito bem preparada e todas as ferramentas e dicas dadas pelo Joseph Wilk foram pertinentes. Vocês podem conferir os slides aqui e a gravação da mesma palestra apresentada na Scottish Ruby aqui

- Ruby on Rails Tasty Burgers: sobre os componentes, as diversas partes que formam o Rails. Aaron deu uma palestra muito divertida, didática e informativa. Além da excelente palestra, ele também recebeu um Ruby Hero Award

- Making Rails Really RESTful with Restfulie: quase que diariamente em listas ou em conversas, e também durante a conferência, vejo muita gente com conceitos incompletos ou equivocados a respeito de Rest. Sem dúvida, um dos desafios de quem defende e luta pela adoção deste estilo arquitetural é acabar com estes equívocos; foi um pouco do que fez o Fábio Akita. Além de explicar muito bem alguns conceitos, ele mostrou o que no Rails está e o que não está de acordo com as definições de Rest. Ele também falou um pouco sobre o projeto Restfulie (http://restfulie.caelumobjects.com/), uma excelente e inovadora iniciativa tocada principalmente pelo Guilherme Silveira da Caelum

• Birds of a Feather - as BOF na RailsConf acontecem todos os dias, durante o dia todo. O valor de conversar e programar com as pessoas que desenvolvem importantes projetos é impagável. Elas estavam lá o tempo todo e dispostas a conversar e mostrar o seu trabalho. Admirável.

• A comunidade Brasileira - na minha opinião, a força e importância da nossa comunidade está sendo reconhecida e valorizada pelo mundo inteiro. Por exemplo: o Fábio Akita deu uma das melhores e mais elogiadas palestras da conferência. O Guilherme Silveira e o Cauê Guerra fizeram um BOF a respeito do Restfulie e pudemos perceber que o projeto é o que há de mais avançado e inovador no assunto. Muitas pessoas vinham conversar com o George Guimarães da PlataformaTec sobre o Devise. Um dos palestrantes mostrou e elogiou umas das muitas gems criadas pelo Nando Vieira, nosso colega aqui da Locaweb. Muitas pessoas vinham falar conosco da Locaweb sobre o Rails Summit e sobre a comunidade Rails no Brasil. E, pra terminar, o José Valim foi um dos Ruby Heroes deste ano. Muito bom, não?

Há alguns meses, resolvi que aprenderia a utilizar alguma outra IDE diferente do Eclipse. Como muitos programadores imersos no mundo Java, eu estava encantado com Ruby e Ruby on Rails e a tendência natural nesta comunidade é utilizar o excelente Textmate. Paguei a licença de 1 ano pra macromates mas não estava confortável porque sabia que no próximo ano teria que desembolsar outros USD 60 ou piratear o software. Minha saída foi buscar alternativas gratuitas. Cheguei a brincar com o VIM por 2 dias e achei fantástico. Entretanto, estava lendo o SICP e uma velha vontade de conhecer o mítico Emacs não me deixava em paz. Resolvi atender minha vontade e dar uma espiada nele. Fiquei apaixonado pelas possibilidades de customização e criação de funcionalidades que esta fantástica ferramenta proporciona, por elisp e também pela produtividade que você ganha quando aprende a se virar sem o mouse.

O Começo

Comecei assistindo ao “Meet Emacs” da PeepCode. Ali aprendi rapidamente o básico e usei como configuração o emacs-starter-kit. Não demorei muito pra querer customizar algumas coisas e, depois de apanhar bastante por conta da bagunça do starter-kit, tomei a decisão de começar o meu projeto de configuração do zero, pegando do starter-kit somente aquilo que me interessava. Foi uma bela diversão. Gastei alguns dias brincando com elisp e terminei com todas as customizações que queria mas com um projeto também bagunçado.

Analisando em retrospectiva, acho que esse seja um bom caminho pra aprender e começar a mexer no Emacs:

1. Copie as configurações de alguém que você conheça ou acompanhe
2. Use uma colinha pra não ficar travado. Eu gosto bastante desta aqui
3. Use por um tempo até ter uma pequena lista das coisas que você quer mudar
4. Pegue um item por vez e customize à sua maneira
5. Crie um projeto com as suas configurações

As Minhas Configurações

Como disse anteriormente, cheguei a ter as minhas configurações guardadas num projeto bem bagunçado. Toda vez que precisava customizar ou adicionar um novo plugin ficava um pouco perdido e, às vezes, outra coisa parava de funcionar. Programador nenhum consegue viver com isso, então resolvi fazer uma grande refatoração no meu projeto (você pode acompanhar os meus commits e ver que na verdade foi uma reescrita).

Hoje, estou satisfeito como meu projeto. Ele está organizado, funcionando, elegante, tem a instalação automatizada e é extremamente fácil adicionar um plugin ou alterar alguma configuração. Se quiser utilizá-lo de alguma forma, o projeto está aqui:

http://github.com/adolfosousa/emacs-config

Estava consultando as novidades no meu leitor RSS quando vi um post no blog do Cássio Marques. Ele estava fazendo uma chamada para traduzir os “Rails Guides”. Como eu não conhecia os guias, resolvi dar uma olhada e, pelo pouco que vi, achei o material muito bom. Fiquei empolgado com a iniciativa e resolvi ajudar. Comecei anteontem a contribuir com a tradução do “Getting Started With Rails”.

Você pode estar se perguntando “mas por que você vai traduzir um material para um público que tem obrigação de saber inglês?” Ora, simplesmente porque eu estou estudando a dupla Ruby/Rails e também porque tem gente na nossa área que realmente não sabe inglês suficiente para ler os guias. Embora acredite que para nós programadores o domínio desta língua é fundamental, entendo que muita gente talentosa nunca teve acesso ao ensino decente de inglês na escola ou em cursos particulares. Se é bom para mim e pode ser útil para todos, por que não fazer?

Se interessou? Quer ajudar? Vá ao post do Cássio e encontre mais informações:

http://cassiomarques.wordpress.com/2008/11/14/convocacao-vamos-traduzir-os-rails-guides-para-portugues/

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!!!