Choque cultural

27.maio.2009
Diferenças culturais são bem difíceis de conciliar quando você trabalha em outro país, com outros povos. E sob pressão isso só tende a piorar.

Rated R

26.maio.2009

“Fazer refactoring sem testes é o mesmo que pegar puta no calçadão e depois dizer ‘eu não sabia’ quando as coisas não saem como esperado.”

Pensamento antigo, mas válido.


Viajando de novo

18.maio.2009
Estou na prosaica cidade de Santiago de León de Caracas, capital da Republica Bolivariana da Venezuela. Sim, povo aqui é megalomaníaco.

Mais duas semanas sem postar, sem dormir e sem comer direito.

E há quem pense que eu viajo para ficar esquiando por aí.


Entrevista de emprego

15.maio.2009

dilbert-1

Há seis meses fiz uma entrevista de emprego totalmente improvisada e despreparada. O carinha não entrou na empresa, o que não considero necessariamente negativo, e eu não participei de nenhuma outra entrevista de emprego, o que foi muito positivo. Para ser bem honesto, eu nem mesmo acho que o resultado daquela entrevista serviu pra alguma coisa.

As vezes, mais como um exercício mental, eu penso como seria uma entrevista de emprego para minha empresa fictícia, para uma vaga de desenvolvedor. Vamos supor que seja para trabalhar com Java, que é meu atual ambiente natural.

Primeiro aquela olhada no currículo. O cara tem meia dúzia de certificações, um emprego numa fábrica de software conhecida, formado numa faculdade da moda e chega de gravata para a entrevista. Sem julgamentos precipitados, lembre-se que esse é o perfil padrão de qualquer entrevista de emprego. Pode apostar, pelo menos um candidato vai aparecer nesses moldes. Numa empresa comum, ele estaria muito bem cotado a entrar.

Mas vamos à parte que interessa.

Antes de aplicar qualquer prova escrita, vou fazer algumas perguntas. Poucas, e em português mesmo. Considere que a entrevista é um momento tenso por natureza, e que não vai ajudar em nada piorar essa situação. Lembre-se de que a vaga é para desenvolvedor Java, e não para atirador de elite da SWAT.

Você gosta de ler? Qual a sua média de livros técnicos por mês? Você dá preferência a livros traduzidos ou em inglês?

Caso responda ‘não’ à primeira pergunta, podemos encerrar a entrevista por aqui mesmo. Preferência por livros traduzidos ao invés de livros em inglês, para mim, pode denotar preguiça e comodismo. Mas não acredito que esse ponto seja fundamental para definir a qualidade do profissional nesse ponto da entrevista.

Você já leu “Effective Java” (Joshua Bloch), “Test-Driven Development” (Kent Beck) e “Refactoring” (Martin Fowler)? O candidato ganha bônus se também já leu “Practices of an Agile Developer” (Venkat Subramaniam e Andy Hunt), “The Art of UNIX Programming” (Eric Raymond). Claro, pergunte também o que ele pensa dos livros e, principalmente, em que pontos ele discorda.

Eu considero os três primeiros leituras obrigatórias para qualquer programador que se considere profissional. Os seguintes são leituras importantes que não podem ser ignoradas. Se bem que, atualmente, se eu entrevistar um sujeito que realmente leu e consiga levar uma discussão rápida sobre todos eles, é bem provável que eu encerre a entrevista ali mesmo e o contrate de imediato. Novamente, se o candidato não leu nenhum deles, podemos encerrar por aqui para evitar mais perda de tempo.

O candidato conhece o Manifesto Ágil? Não estamos cobrando aqui nenhuma certificação-papel-de-bobo de Scrum ou coisa parecida (acalmem-se trolls, eu também tenho uma). Também não quero que o cara tenha o Manifesto decorado na ponta da língua. Importante é conhecê-lo e entender o que significa. Conhece TDD (ok, mesmo lendo o livro) e consegue usar essa abordagem de forma pragmática? Por pragmática entenda-se: sim, você tem que escrever testes antes de codificar. Não, você não pode perder tempo tentando alcançar utópicos 100% de cobertura de código. A tarefa do programador não é entregar as Obras Completas de Shakespeare em Java, mas sim código de qualidade em tempo relativamente curto. Utópico, mas que entrevista de emprego não é?

O candidato tem algum pet-project? Participa ou participou de algum projeto open source? (tradução de arquivos de i18n não conta). Programa porque gosta ou apenas porque alguém disse que dava dinheiro? Estuda tecnologias, linguagens ou abordagens que não estão necessariamente relacionadas ao trabalho? Conhecer Lisp, Erlang, Haskell e/ou linguagens dinâmicas ajuda a enxergar maneiras novas e até mesmo mais simples e limpas de se resolver um mesmo problema.

Na seqüência, se ainda não foi encaminhado à porta de saída, o candidato deve escrever uma dissertação breve, de vinte linhas, sobre algum assunto relacionado à área. A idéia aqui é apenas avaliar a clareza de raciocínio ao passar idéias para o papel e evitar futuros problemas com analfabetos funcionais. Seco e direto assim.

Agora a sobremesa. A hora preferida do verdadeiro desenvolvedor: a prova prática.

O candidato deve resolver um code kata em tempo pré-determinado (aqui a pressão faz parte do jogo), previamente definido e exibido todo o tempo. Um relógio na parede ajudaria nesse ponto. O desenvolvedor deve conviver com prazos definidos, que geralmente são curtos, e pressão. Nada de anormal. É exigido que o candidato utilize TDD ao resolver. Se ele chegou até aqui, pode apostar que ele consegue.

Ah sim. Arranje uma máquina decente com um ambiente semelhante ao real para que ele faça essa parte da entrevista. Codificar em folha de papel é uma das coisas mais ridículas de uma entrevista. Só perde para dinâmica de grupo e entrevista com psicóloga (note o gênero).

Avalie a expressividade do código. Isso é importante. Você não vai querer pegar um código suíço pela frente, cheio de variáveis enigmáticas e abreviações que não querem dizer nada.

Como eu disse no início desse texto, que saiu mais longo do que eu esperava, isso é apenas um exercício mental. Mas no momento está me parecendo um modo bem mais honesto e efetivo do que passar um dia inteiro numa empresa escrevendo redações sobre minhas férias, sendo entrevistado por psicólogas (de novo o gênero) que mal sabem o que a empresa faz, e para terminar, com fome e dor de cabeça, uma entrevista técnica com um sujeito que não acha a própria bunda usando as duas mãos (do tipo que briga com você jurando de pés juntos que C# aceita herança múltipla). Ouviu, sevencomm?

Bom fim de semana,


Testes unitários – you’re doing it wrong

14.maio.2009
Se você:
– Precisa de um método public static void Main(String[] args) para executar seus testes
– Depende de uma ordem pré-determinada para executá-los
– Caso um teste falhe, todos falham na seqüência
– Dependa de um banco de dados, de uma conexão ou de qualquer recurso externo para executar o teste
– Precise rodar os testes na mão toda vez que quiser saber se estão passando
– Escreve testes sem assert com freqüência

Sinto dizer, mas você não está usando testes unitários.

Update: Estou amadurecendo melhor a idéia, mas relendo isso aqui, e conversando com alguns desenvolvedores, fiquei pensando: “OK, você está fazendo errado. Então como é o certo? Por que está errado?”. Fiquei em dívida com vocês. Mas pretendo publicar algo mais decente sobre isso em breve.


O que não é Scrum

13.maio.2009

dilbert-agile-programming

Departamento de sistemas da matriz adotou Scrum como metodologia de desenvolvimento. Bacana, não?

Não.

Primeiro ponto: Scrum é um framework de gerenciamento de projetos, e não de engenharia. Obrigatoriamente você vai precisar de alguma técnica complementar se quiser que seu desenvolvimento de sistemas (no caso) esteja dentro do que se considera aceitável. Os responsáveis pela adoção acreditam realmente que apenas o Scrum vai salvá-los da danação eterna.

Segundo: usar Post-its, quadros brancos, burndown charts e mimimitings não significa que você esteja usando Scrum. Daily Meetings semanais e Stand-up Meetings sentados, com três horas de duração também não tem nada a ver com Scrum.

Terceiro: Aposto um dedo da mão direita como um “Scrum” aplicado dessa forma vai afundar o projeto, ou pelo menos vai gerar um produto de péssima qualidade, caro de se manter e muito, mas muito estressante de se trabalhar.

Aposto outro dedo da mesma mão como o Scrum vai levar a culpa e vai ser banido a pontapés da empresa. Com o risco de alguém olhar para trás e se transformar numa estátua de sal.

Pedir a benção do Papa para ‘implantar Scrum’ dentro da empresa não soa exatamente ágil. O que a empresa teoricamente espera é software que funciona, com qualidade, dentro de prazo e custo estimados. Se você tem que beijar a mão do bispo para conseguir trabalhar direito, a agilidade definitivamente não faz parte do DNA da empresa.

E finalmente, imprimir “Scrum & XP from the Trenches” e ler passo a passo antes de tomar uma decisão só mostra o quão despreparadas estão as pessoas envolvidas. Por maior que seja a boa vontade, não vai rolar.

Scrum é flexível, e muito. Mas mudar os alicerces do framework é como ser católico sem acreditar em Deus.

Como bem escreveu Rodrigo Panachi, “agilidade não é metodologia, é atitude”.

Update: Recomendo a leitura do artigo do Rodrigo Yoshima.


Cuide bem do seu Ubuntu

12.maio.2009
Criei um script para atualizar automaticamente o Ubuntu do meu servidor. Se manter o Linux atualizado é uma tarefa chata e repetitiva, por que não automatizá-la?

Vamos utilizar o crontab, que é o gerenciador de tarefas agendadas do *ux (Linux, Unix e parentes).

Crie um arquivo com o conteúdo a seguir:
sudo -i
nano ~/update.sh

#! /bin/sh
apt-get update
apt-get upgrade -y

Salve e feche com F2. Para testar, digite:
chmod +x ~/update.sh
~/update.sh >> ~/update.log
tail ~/update.log

Agora, dê permissão ao seu usuário para que ele execute o crontab:
nano /etc/cron.allow

Dentro do arquivo, insira os usuários que terão acesso ao cron, um por linha, incluindo o root se precisar.

Teste com crontab -e. Possivelmente irá aparecer um arquivo com a linha abaixo:
# m h dom mon dow command

Adicione no arquivo:
0 0 * * * ~/update.sh >> ~/update.log

Novamente F2 para salvar e fechar e pronto. Você tem um agendamento para que todo dia a meia noite o Ubuntu atualize sua lista de pacotes e execute um upgrade automático. Nem o Windows Update faz melhor, hein?

Caso você queira saber se ocorreu algum problema, basta olhar o arquivo update.log. Ele contém todas as informações do que aconteceu. E caso você queira que ele mantenha somente a última execução, basta substituir o >> por > no agendamento do crontab.

That’s all, geeks.

Update as 21h00: Meu script acabou de rodar (é meia noite no servidor). Funcionou \o/.