Keep Learning Conhecimento nunca é o bastante

Testes envolvendo tempo: usando a gem time-warp

É comum que precisemos “manipular o tempo” quando escrevendo testes para código cujo comportamento depende do momento no tempo.

Uma técnica comum é utilizar um mock ou stub na classe Time do Ruby para manipular o horário de acordo com o desejado. Isso vai contra um princípio importante do uso de fake objects em testes: “Não use fakes em objetos que não são seus“. Na maioria do tempo isso pode não causar problemas, mas alterar o comportamento de uma classe usada internamente pela linguagem não soa bem e pode causar bugs difíceis de rastrear.

Aí entra a gem time-warp. Ela ainda trabalha sobre as classes do Ruby, mas provê uma camada específica para testes para todo código executado em um bloco definido pelo programador. Um exemplo de uso (da nossa aplicação feita para o Rails Rumble):

it "should only silence tweets with the desired word inside the configured time interval" do
  pretend_now_is(Time.now.utc.beginning_of_day + 1.hour) do
    tweet1.sent_at = 2.minutes.ago
    tweet2.sent_at = 32.minutes.from_now
    tweet3.sent_at = 1.hour.from_now
 
    collection = [tweet1, tweet2, tweet3]
 
    Silencer.apply(collection, {:word => "soccer", :until => 30.minutes.from_now})
  end
 
  tweet1.should be_filtered
  tweet2.should be_filtered
  tweet3.should_not be_filtered
end

A gem adiciona o método “pretend_now_is”, que recebe um parâmetro com o horário desejado e um bloco. Dentro desse bloco, todo código executado é “transportado no tempo” para o horário definido. Além de tornar a manipulação das classes de tempo mais segura, o código fica muito mais elegante.

Veja mais detalhes no README da gem.

Como aumentei minha produtividade eliminando distrações

(ou: Como deixei de me preocupar e deixei de assinar muitos feeds)

Não, ainda não sou uma pessoa super-mega-produtiva, mas aqui está como consegui aumentar minha produtividade usando alguns truques (e o incrível sistema operacional que é o Mac OS X em conjunto com ótimas aplicações):

• Não verifique seu e-mail mais de quatro vezes ao dia: se você está esperando algum e-mail importante, peça para quem for enviá-lo que te avise quando isso acontecer, usando, por exemplo, uma SMS;
• Não verifique seu e-mail se você sabe que não estará apto a agir sobre alguma mensagem imediatamente: por exemplo, verificar seu e-mail de trabalho no final da tarde de Sexta – deixe para fazer isso na Segunda;
• Livre-se dos feeds que você assina: você não vai realmente sentir falta deles sem ficar um tempo longe. Se, após alguns dias, você sentir muita falta de ler um deles, assine-o novamente, mas não verifique seus feeds mais do que uma vez ao dia. Essa é uma excelente técnica para descobrir o que é realmente importante dentre tudo que você consome;
• Deixe que as pessoas sejam seu filtro: acredite em mim, se algo é realmente importante (ou banal, mas “quente”), vai chegar a você. Você não precisa ficar garimpando. O recurso de “shared items” do Google Reader é excelente nesse ponto – estou à caminho de usar apenas ele, me livrando de todos os feeds que assino (são por volta de oito hoje). Quando realmente precisar encontrar algo, o Google é seu amigo;
• Desabilite notificações desnecessárias: como muitas do Growl ou os “contadores vermelhos” nos ícones de aplicações na Dock do OS X – mantenha apenas as que você realmente precisa (por exemplo, eu mantenho as notificações do Propane, já que é importante saber o que meus colegas de trabalho dizem no Campfire);
• Não use um monitor muito grande: isso pode parecer estranho, mas pesquisas mostram que, após aproximadamente 26 polegadas, o tamanho do monitor diminui a produtividade. É óbvio: muitas coisas no seu campo visual vão lhe distrair. Use o Spaces e divida as telas de acordo com a tarefa (uma para programação, uma para navegação na internet etc);
• Aumente o espaço livre na sua tela eliminando itens do seu Desktop: configura o Finder para não exibir discos rígidos (eu deixo apenas discos ópticos e dispositivos removíveis). Elimine da Dock as aplicações que você não usa muito frequentemente. Use o QuickSilver ou algo similar para acessar as aplicações e arquivos que você não usa frequentemente, apenas não deixe que eles se empilhem na Dock e no Desktop;
• Elimine da Menu Bar os itens que você não precisa, como o ícone de status do Bluetooth, o indicador AM/PM se você usa o formato americano (é fácil saber isso olhando pela janela), o ícone do Time Machine etc;
• Use o Adium e configure-o para que fique oculto a menos que seja a aplicação ativa (veja aqui: ativo, inativo, configurações 1, configurações 2);
• Use o Fluid para criar SSBs para as aplicações web que você precisa para trabalhar: o motivo para isso é evitar ter um browser repleto de abas abertas te distraindo enquanto você usa uma aplicação para trabalhar. Com as aplicações Fluid você pode focar apenas na tarefa à mão;
• Use o Tags para facilitar o processo de organização e busca de arquivos.

É difícil tomar algumas dessas ações, como se livrar dos feeds que você assina – especialmente porque o número de feeds assinados geralmente é motivo de “disputazinhas” entre nerds/geeks. É estupidez pura, como competir para ver quem dorme menos e fica acordado programando por mais tempo.

De qualquer modo, dê uma chance. Após algum tempo (eu recomendo tentar por, pelo menos, dez dias), você vai sentir falta das coisas que realmente precisa e pode tê-las novamente assim que quiser.

Update: Como bem notado pelo ArthurGeek, a imagem de configuração do Adium para que a lista de contatos se esconda automaticamente estava errada (a que eu chamei de “configuração 2″). Arrumei o link e deixo aqui também: http://yfrog.com/avpicture12xp.

–

Também em inglês.

Palestras e artigos altamente recomendados

Segue abaixo uma lista concisa de vídeos, artigos e slides que mantenho por perto como referência. Há material técnico e não-técnico e, é claro, não se trata de uma referência completa para desenvolvimento de software.

A intenção é ter algo que possa ser consumido em pouco tempo, resultando numa base sólida para o desenvolvedor profissional (ou seja, não há tópicos básicos para iniciantes) e, ao mesmo tempo, ser mantido como referência (o asterisco denota meus itens preferidos).

Vídeos de conferências:

• Don’t Mock Yourself Out – David Chelimsky
• The Grand Unified Theory – Jim Weirich*
• Mock Dialogue – Joe O’Brien and Jim Weirich
• SOLID Object-Oriented Design- Sandi Metz*
• Testing Heresies – Francis Hwang*
• What Makes Code Beautiful? – Marcel Molina Jr

Artigos/Slides:

• Common REST mistakes
• Functional Programming For The Rest of Us* – finalmente alguém que explica programação funcional de forma simples, sem querer parecer um “sabe-tudo”
• How I Explained REST to My Wife* – ótimo artigo, sempre uma referência ímpar
• On The Shortness of Life: An Introduction to Seneca
• Smart Model, Dumb Controller – focado em Rails, mas vale para qualquer MVC
• Top ten things ten years of professional software development has taught me
• Web2.0: Why we got here and what’s next

Como falhar com métodos ágeis

É comum vermos guias de como fazer algo da maneira correta. A meu ver, muitas vezes, um guia de como fazer tudo errado acaba sendo mais últil, pois mostra o outro lado da moeda e acaba servindo melhor de indicador de sucesso (ou falta de).

Dada alguma experiência que possuo com métodos ágeis, aqui vai um guia 100% garantido de como falhar utilizando-os. Todas as recomendações foram vistas em prática e são ótimas receitas para o fracasso, ainda mais quando utilizadas em conjunto:

• Não utilize equipes multi-funcionais
  Separe os membros em equipes de Criação, Desenvolvimento, Infra-estrutura e várias outras, assim como setores em grandes empresas. Mantenha-os distantes, de preferência em salas separadas, dificultando a comunicação (o pilar central dos métodos ágeis) ao máximo – sabemos que basta ficar em mesas separadas para que as pessoas se comuniquem apenas via e-mail, quando muito. Crie processos para que as equipes façam requisições umas às outras, faça com que isso seja demorado: com isso você desestimula qualquer resquício de colaboração.
• Espere até o final da iteração para avaliar as histórias
  Crie um processo de QA intrincado e lento. Faça com que a avaliação das histórias fique para o último dia da iteração – desta forma, se uma história não for aprovada, não haverá tempo para correção, garantindo assim mais um passo rumo ao fracasso.
• Não abrace a mudança
  Crie processos burocráticos com várias etapas, dificulte a resposta rápida e limite os profissionais o mais que puder. Deixe o caos reinar sob a desculpa de que não fará micro-gerenciamento quando, na verdade, não há gerenciamento nenhum. Não escute o que a equipe tem a dizer, esse bando de programadores, designers e administradores de sistemas não tem experiência com gerenciamento de verdade e não sabe o que está dizendo.
• Centralize o controle e as (in)decisões
  Crie comitês para qualquer problema, dos mais simples aos mais complexos. Responsabilize uma pessoa pelo controle de cada comitê, que deve fazer inúmeras reuniões, coletar muita informação e repassar ao responsável. Esse tem a tarefa de levar toda a informação ao “chefe” que, por sua vez, não decidirá nada e criará mais comitês. Dessa forma você garante que nenhuma decisão será tomada e todos os problemas se arrastarão até que se combinem no caos completo.
• Utilize “Agile by the book”
  Leia vários livros sobre Extreme Programming, Scrum, Lean e o que mais estiver na moda. Adote todos os processos do jeito que são descritos – o que, num primeiro momento, é bom, já que não há experiência. No entanto, recuse-se a modificar qualquer detalhe, mesmo que as coisas não estejam funcionando e que a experiência adquirida pela equipe aponte em uma direção diferente. Sempre refute qualquer argumentação com uma citação ao estilo “Ken Schwaber diz que…” (vale qualquer nome “de peso”), afinal Ken Schwaber está trabalhando junto à equipe todos os dias e conhece suas necessidades, correto?

Este é um trabalho em progresso. Quais práticas você adicionaria ao guia?

Waterfall é xadrez. Agile é futebol.

Essa é uma boa analogia quando necessário comparar esses dois tipos de filosofia/metodologia (é apenas uma analogia, não uma comparação perfeita, mas ajuda bastante).

Waterfall é xadrez: você usa muito tempo para pensar e planejar, fazendo o máximo de esforço para tentar prever cada possível movimento durante o jogo. Dada essa natureza de muito planejamento antes da execução, faz sentido apenas em domínios muito estáveis e conhecidos, sem mudanças na demanda (geralmente em software de alto risco, como para voos espaciais).

Agile é futebol (ou qualquer esporte coletivo): as decisões durante o jogo devem ser tomadas muito rapidamente, sem tempo para análise de todas as possíveis consequências. Por isso, é “ideal” para domínios altamente dinâmicos e instáveis, com constantes alterações na demanda (como software para a web). Outra semelhança muito importante a ser notada é: mesmo que você tenha os melhores jogadores, se a equipe não jogar bem junta, o time não vence.