Nesta quarta-feira aconteceu mais uma reunião do grupo TaSafo, em Belém do Pará. Foi um prazer poder re-encontrar antigos amigos e conhecer pessoalmente os responsáveis por movimentar a comunidade Paraense de desenvolvimento.

O encontro foi composto por duas apresentações, seguidas da ‘Hora do Desapego’.

Meu amigo Mateus Linhares falou sobre sua experiência implantando práticas e métodos ágeis no Ikwa.

Eu falei sobre ‘Comunidades Dinamicamente Tipadas’.

Não lembro ao certo quando escutei este conto pela primeira vez.

“Certo dia, um rapaz que caminhava pelo bosque avistou um lenhador tentando derrubar uma árvore. Observou-o por alguns instantes e notou que, mesmo investindo cada vez mais força em suas machadadas, não estava obtendo muito sucesso em derrubar a árvore.

Então o rapaz sugeriu ao lenhador:

- ‘Por que você não descansa um pouco e, enquanto isso, aproveita para amolar o seu machado ?’

O lenhador respondeu:

- ‘Não posso perder tempo! Tenho que derrubar logo esta árvore!’”

Desenvolvimento de software é um processo contínuo de aprendizagem. Diariamente nos deparamos com árvores a serem derrubadas. No caso das mais difíceis, pense em parar e refletir sobre o que está fazendo enquanto amola seu machado ao invés de ficar repetindo incessantemente a mesma coisa, esperando resultados diferentes (a definição de estupidez, segundo Einstein).

http://www.flickr.com/photos/shedboy/3610432084/

Você reserva algum momento de sua semana para a leitura de blogs de referência da sua comunidade ?

Participa de alguma comunidade ?

Participa de pelo menos uma grande conferência por ano ?

Está lendo algum livro técnico ?

Estar atualizado é responsabilidade de qualquer profissional de tecnologia.

Na última sexta-feira tive o prazer de realizar um Coding Dojo junto ao pessoal do CESUPA, em Belém do Pará.

Ao todo, nove pessoas estavam presentes. Paulo Igor, Marcos Venicius, Aldrin Leal, Gustavo Pinto, Igo Medeiros, Mateus Miranda, Danilo Cunha, Rafael Santana e eu nos reunimos as 16 horas (horário mais conhecido como “depois da chuva”) no campus José Malcher, sala 4F, munidos apenas de um pc e um retro-projetor.

Enquanto aguardávamos o resto do pessoal chegar, Paulo Igor, Aldrin Leal e eu conversamos sobre Ruby, Python, FISL e sobre o Project Zero, um projeto ao qual o Aldrin pertence.

Após uma pequena apresentação do que é o Coding Dojo, sugeri alguns problemas que poderíamos resolver. A maioria optou pelo problema do jogador de futebol, que já havia sido resolvido em Ruby no último Dojo Rio mas que desta vez seria resolvido utilizando Java.

O problema mostrou-se mais uma vez de fácil compreensão e não precisamos de muito tempo para a definição das estórias. Gosto do formato de user stories para fechar o escopo de problemas como este (e como o wowspec) para um Coding Dojo, uma vez que são idéias muito gerais e com possibilidades  de implementação quase que infinitas.

A utilização do Netbeans como IDE não foi uma boa escolha. Com apenas duas classes, o Netbeans foi capaz de se perder e exibir testes falhando mesmo quando corretos. A solução foi dar ‘clean’ no projeto de tempos em tempos.

Após 40 minutos de codificação, conseguimos completar as quatro estórias criadas mas não tivemos tempo para refatorar nosso código. Como o objetivo do Coding Dojo não é completar os problemas, mas exercitar ao máximo as técnicas de programação e comunicação durante o time-box estabelecido, paramos de trabalhar no código e passamos para a retrospectiva.

Realizamos nossa retrospectiva e trocamos muitas idéias sobre, claro, metodologias e práticas ágeis e também sobre a situação do mercado de desenvolvimento de software em Belém, que carece de profissionais que pensem ‘out-of-the-box’.

Obrigado ao CESUPA pela disponibilidade da sala e equipamentos e também aos que estiveram por lá e participaram do Dojo. Espero que tenham gostado e que possam levar a prática do Coding Dojo a diante!

Chega ao final a décima edição do Forum Internacional de Software Livre, realizado na PUC-RS e com participação de mais de oito mil pessoas.

Minhas impressões do evento foram as melhores possíveis. Excelentes palestras aconteceram durante os quatro dias de conferência mas assisti a pouquíssimas. Passei a maior parte do tempo revendo amigos, conhecendo novas pessoas e conversando com mentes brilhantes que passaram por lá.

Com a proposta de tentarmos mostrar o “espírito” do FISL para os que não puderam estar presentes, o Henrique Bastos e eu relatamos os acontecimentos em forma de podcasts. Todos encontram-se disponíveis no site da PythOnRio (primeiro dia - parte I, primeiro dia - parte II, segundo dia, terceiro dia, quarto dia).

Junto a PythOnRio e Python Brasil, tive a honra de poder contribuir com a comunidade ao colocar em prática um plano para entregar uma camiseta da PythOnRio ao presidente Lula e contar a ele sobre a iniciativa PythOnCampus.

A Python Brasil realizou duas sessões de palestras relâmpago. Ao assistir a primeira sessão, achei o formato tão legal que preparei ali mesmo uma apresentação rápida para a segunda sessão. Em apenas cinco minutos falei sobre técnicas para melhorar sua orientação a objetos - PyListhenics. As palestras podem ser vistas no site da PythOnRio.

Ainda exausto e meio gripado por conta do frio em Porto Alegre, gravamos o último podcast quase que de saída para o #horaextra da primeira segunda-feira pós-FISL - que bateu o record!

Esta última semana pode ser resumida com o título da apresentação do Henrique Bastos nas palestras relâmpago: pequenos atos fazem grandes revoluções. Assista a palestra e saiba a razão.

Iniciam-se já os preparativos para o FISL 11!

A keynote do DHH na RailsConf deste ano me causou uma boa impressão. Segundo ele, mesmo havendo muitas mudanças incorporadas ao código do Rails desde que o projeto foi iniciado há 6 anos, no geral não mudou muito.

Das vezes que pude assiti-lo falar, ele sempre deixou bem claro que o Rails “básico” é tudo o que ele realmente usa ou sabe a respeito. Nada supreendente, uma vez que ele escreveu o framework para seu próprio uso e exatamente da maneira como ele precisava que fosse.

Então veio um “core team” e estendeu a ferramenta. Legal. Agora temos pessoas cavando nas profundezas para melhorar sua performance, que será visto na versão 3 do Rails. Excelente!

Sua convenção sobre configuração nunca pretendeu agradar a todos ou servir a todas as situações. O Rails nunca será a bala de prata e eu realmente espero que permaneça desta maneira. Caso você precise mudar alguma coisa no comportamento do Rails, na maioria das vezes esta mudança é tão simples quanto escrever um plugin ou gem. 

Toda a hype em torno de frameworks (do próprio Rails e outros ‘auxiliares’) que vemos hoje é muito mais do que vamos realmente precisar algum dia. O segredo que DHH fala sobre a alta produtividade não é nada relacionado a tecnologia. Mesmo tendo desenvolvido o Rails para aumentar sua produtividade, o seu real segredo é saber renegociar requisitos.

Se você está desenvolvendo software profissionalmente para a indústria e ainda utiliza a maneira hacker, nenhuma plataforma será produtiva o suficiente para você. Caso não haja comunicação envolvida no seu processo de desenvolvimento, você irá certamente falhar ou então gastar muito mais tempo para desenvolver algo que - a princípio - resolva o problema do seu cliente.

Cinco anos se passaram desde que o Rails foi lançado. Tudo o que ele oferece e mais todos os outros zilhões de frameworks de teste e gems são totalmente inúteis, a não ser que você preocupe-se com o que essencialmente precisa ser feito.

Seu cliente pode não saber o que ele quer, mas certamente sabe o que não quer. 

Ele pode chegar para você e pedir algo que levará duas semanas para ser desenvolvido. Como um desenvolvedor profissional, cabe a você começar da onde ele quer e chegar aonde ele precisa. Talvez o resultado seja resolver problema do seu cliente com uma solução completamente diferente da que foi sugerida por ele, mas uma muito mais simples e que levará você muito menos tempo para desenvolver.

Como DHH falou, quando você quiser um chocolate, talvez um Twix que esteja no seu bolso seja tudo o que precise, ao invés de dirigir até o centro da cidade e gastar muito mais dinheiro com uma caixa de chocolates belgas.