Testes unitários – you’re doing it wrong

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

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

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/.

On the road

Devo estar há mais de mês sem publicar aqui.

Nesse meio tempo, a pressão só aumentou, passei Abril inteiro na matriz (ou na Matrix, como preferem alguns) desenvolvendo um projeto de seis meses em trinta dias. Hoje viajo para apresentar outro projeto e na semana que vem embarco novamente para fazer a instalação do projeto.

Além de fotos, eu sempre tento trazer dessas viagens alguma experiência que me faça crescer profissionalmente. Conforme for tendo tempo para respirar, vou publicar aqui alguns rabiscos que tenho feito “na estrada”.

Stay tuned.

Firula

Banner novo. Foto tirada num metrô europeu, na última viagem que fiz pela empresa. O lugar se orgulha de ser a menor cidade do mundo com Metrô.

Cada um com seus respectivos troféus, afinal.

ActiveScaffold

Não use.

Simples assim.

Sobre garrafas d’água e janelas quebradas

Há semanas eu queria publicar isso, mas a correria e a avalanche de viagens atrasou um pouco a coisa por aqui. A boa é que meu plano de milhagens ficou mais gordinho depois do último mês.

No escritório em que trabalho há um frigobar. No frigobar há uma garrafa d’água cuja função (duh) é fornecer água gelada aos funcionários e visitantes. Sem dúvida, nesses tempos de calor excessivo, um copo bem servido de água gelada é muito bem vindo.

O problema é que todo mundo gosta de tomar aquele copão de água refrescante, mas ninguém gosta de encher a garrafa de volta e, aquele que pega essa tarefa, gasta bons minutos enchendo uma garrafa vazia e bebendo água morna.

E o que você tem a ver com o que acontece no escritório?

Pense que a garrafa é um software. Você chegou da rua, com calor e suado e quer água gelada. Você foi jogado num projeto e quer código limpo,claro e que funcione, certo?

Só que, sinto dizer, as chances de você encontrar isso no seu novo projeto é ainda menor do que as chances de encontrar água gelada, e o motivo é bem simples: maioria das pessoas quer simplesmente se livrar do problema, pular para a próxima tarefa, correr logo para casa e/ou mostrar produtividade para a chefia. Poucos percebem que isso vai criando uma bola de neve, ou de fezes, que só cresce, e afoga o próximo que tiver que meter a mão no lodo.

“Não tenho tempo”, “o próximo que se dane” ou simplesmente “não reparei que estava fazendo isso” são as desculpas mais comuns e, infelizmente, tentar convencer essas pessoas do contrário é tão produtivo quanto lavar burro com xampu anticaspa.

Alguém um dia disse que, se quisermos um mundo melhor, temos que começar a limpar nosso próprio quintal. Se eu quero ter sempre água gelada, eu completo o que acabei de beber. Se eu quero um código limpo, eu corrijo, dentro do possível, o código em que estou trabalhando, e faço o possível para deixar código limpo para quem vier depois. E não compensa esperar que as outras pessoas mudem de comportamento, por mais que os cursos por aí preguem o contrário.

Conserte as janelas quebradas, escreva testes, não jogue papel na rua, limpe os pés antes de entrar e, pelo amor da sua divindade preferida, encha a porra da garrafa d’água depois de se servir.

E bom fim de semana.

Erro chato usando Git no Windows

De repente (bom, mais ou menos) meu git começou a exibir uma mensagem de erro ao dar commit:

You have some suspicious patch lines

WTF? Isso acontece depois de desabilitar a alteração de todas as quebras de linhas para CR-LF, tornando o fonte legível aos desenvolvedores que felizmente não estão usando Windows. Não sei porque o git passa a entender o sinal a mais de quebra de linha como sendo um espaço.

Depois de fuçar bastante, cheguei a um workaround para isso. Dentro do seu projeto, edite o arquivo .git/hooks/pre-commit e comente as linhas abaixo:

if (/\s$/) {
  bad_line("trailing whitespace", $_);
}

Pronto. Seja feliz e divirta-se, mesmo sendo um usuário de Windows cercado de Textpads por todos os lados.

Ruby ao resgate

Estou meio sumido, fazendo o projeto andar apesar dos gols contra, e chafurdando no Rails.

Fica uma dica para quem também está começando a se divertir no Ruby. Para executar um processo que pode causar uma exceção, podemos proteger o código usando rescue, assim como em C++/Java temos o try/catch:

begin
  file = open("arquivo")
rescue
  msg = "Arquivo não pode ser aberto"
  logger.error msg
  show_message :error => msg
end

Simples, não?

Integração Contínua

Instalei em minha máquina de trabalho um servidor de integração contínua.

Quando se trabalha sozinho, num projeto pequeno, isso realmente não faz muito sentido. Porém, trabalhando com um recurso a 500km de distância, e mais dois recursos remotos cuidando de um projeto relacionado, cuja alteração indevida pode quebrar o funcionamento da parte em que trabalho, esse tipo de ferramenta começa a fazer sentido.

O modo correto, antes de mais nada, é instalar esse servidor numa máquina que possa ser facilmente acessada por qualquer parte interessada. Minha máquina de trabalho, obviamente, só fica disponível quando estou conectado na rede da empresa, para quem estiver na mesma condição.

Instalei o Apache Continuum rodando como um NT Service (sim, eu uso Windows no trabalho), acessível como uma aplicação web a partir da porta 8080.

Para quem se interessou, recomendo a leitura do artigo do Martin Fowler sobre Integração Contínua. Estou organizando uma documentação para compartilhar com a equipe e pretendo divulgá-la aqui.

P.S.: Sim, eu sei que tem Bamboo, mas comunicação ainda é um ponto crítico a ser desenvolvido.