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!

If you have ever felt the need to do remote pair-programming and didn’t know of any tools around to help you do that, here is a quick tip using Screen.

Screen is a window-manager that makes it possible to share a single session among users logged onto the same machine, allowing them to interact with each other in real time.

This assumes that you:

a) have access to at least one Linux/Unix box with Screen and SSH enabled.
b) are comfortable working with a command line editor (vi, vim, emacs, etc).

For this example we will be using Screen 4, which is probably already bundled with your favorite Linux distro or OS X. If you happen not to have it, apt-get/yum/port/whatever to install it.

In order to have multiusers on one Screen session, some file permissions need to be changed. Screen needs to be able to be run as root and the /var/run/screen folder needs some executing permission.

sudo chmod +s /usr/bin/screen
sudo chmod 775 /var/run/screen

Now the first user - let’s call it foo - can log in to the Linux box via SSH and start a Screen session named pairprog.

[foo@linuxbox ~]$ screen -S pairprog

The user foo, now on Screen, needs to turn on multiuser mode and grant access to his friend, the user named bar.

^A :multiuser on
^A :acladd bar

(^A means ‘control + A’, which is the way commands are passed to Screen)

Now it is time for the user bar to log in to the same Linux box and join foo’s Screen session.

[bar@linuxbox ~]$ screen -x foo/pairprog

Now both users should see each others’ activities.

Fire up your favorite command line editor, start a voice chat (using Skype or something) and you’re good to go in no time!

Update! It is worth mentioning that the user foo actually shared everything. This might cause security implications, since the guest user (bar) will act as the host user. You can give the host user read-only permission by:

^A :aclchg bar -w "#"

Probably the best way to use Screen for session sharing would be to create a new “public” user and use it as the host for the session. Place all the files under this public users’ directories or other public directories.

Thanks for pointing it out, Pigor!