Impressões sobre a 2ª Reunião do Dojo

Apesar dos poucos participantes (apenas 4 compareceram e a maioria que confirmou não foi), a reunião foi bastante proveitosa. A vantagem de se ter poucas pessoas neste tipo de reunião é a possibilidade de trocar experiências não apenas sobre programação mas sobre desenvolvimento de software em geral.

Discussões sobre contratos, SCRUM, dificuldades em começar a usar técnicas ágeis e treinamentos foram alguns assuntos que surgiram nesta reunião. O fato dos participantes virem de empresas diferentes ajuda muito a se ter uma idéia do que rola no mercado de desenvolvimento em geral, e quais são as tendências locais.

Quanto ao desafio, por sorte todos já estavam familiarizados com o que foi feito na 1ª reunião, então pudemos partir do código já existente. Também foi possível usar mais tempo para discutir alguns padrões de TDD (Fake It, por exemplo), o que espero que também aconteça nas próximas reuniões. Não chegamos a finalizar a solução porque preferimos conversar sobre outros assuntos, porém avançamos bastante e aí está o resultado:

dojo_20061218_poker.zip

Até a próxima 🙂

O que rola em outros blogs…

Pra começar, no blog da Caelum, Thadeu Russo ensina como Impressionar seus amigos com Java usando uma biblioteca para renderizar grafos em poucas linhas de código.

Se seu negócio não é Java e você quiser impressionar usando Ruby on Rails, Fabio Akita continua mostrando as facilidades do framework, desta vez mostrando como gerar formulários em Ajax usando o plugin Ajax Scaffold.

Falando em frameworks, uma matéria da revista Mundo Java que vende algo como “Não use Hibernate/Outro ORM, use 100% Java!” tem sua crítica feita pelo Phillip “shoes” Calçado no post Não use Framework, use 100% Java – WTF?

Pra fechar o assunto, também há um post questionando o que seria um framework no blog do Yguaratã Cavalcanti.

Desafio para a 2ª Reunião do Dojo

Assim como na primeira reunião, o assundo do desafio continua sendo o poker…

Descrição do desafio:

Criar um comparador de mãos de poker. Dada uma série de mãos (conjunto de 5 cartas válidas) , o software deve indicar qual é a mão vencedora e se possível ordenar todas as outras, identificando também possíveis empates . O ranking das cartas do jogo pode ser encontrada aqui.

Dependendo do interesse dos presentes podemos continuar a partir da solução do primeiro desafio, ou implementar a solução desde o início. Estamos sempre abertos a sugestões 🙂

É tão estressante assim trabalhar com TI?

Nas últimas semanas tenho acompanhado uma discussão sobre medicamentos que erradicam (ou diminuem) a necessidade de sono, criada no fórum do grupo de usuários Java e passei a me perguntar de onde a necessidade de uso de substâncias estimulantes estaria surgindo.

Pesquisando um pouco sobre o assunto, vi que a revista Info publicou que o profissional de TI é o mais estressado hoje em dia, ficando na frente médicos e engenheiros, inclusive. Dentre as causas principais estariam principalmente a carga de trabalho, os prazos e o tipo de trabalho a ser executado.

Por que será que a pressão sobre os profissionais está tão grande assim? Sobram vagas para estes profissionais e mesmo assim o problema continua. A demanda por tecnologia está em alta e quem “paga o pato” são os técnicos no assunto. Dentre algumas fontes de estress que eu vejo por aí também estão:

• Trabalhos free-lancer: a idéia de ganhar dinheiro no horário livre é tentadora para muitos profissionais, que acabam esquecendo que além de botar a mão na massa, terão provavelmente que trabalhar muito mais para cumprir tarefas que no seu trabalho normal seriam executadas por outra pessoa. Tratar com clientes, definir prazo/custo e dar suporte para a solução estão entre essas atividades que poderão tirar muitas noites de sono. Muitas vezes o retorno financeiro simplesmente não compensa.
• Pressão por aprender novas tecnologias: a cada dia surge uma nova tecnologia ou ferramenta que chama atenção dos profissionais de TI. E assim como as mulheres seguem as novas tendências da moda, os técnicos querem sempre dominar as “novidades” (isso quando não são obrigados a fazê-lo por pressão de um superior com essa visão). O resultado disso no dia-a-dia acaba sendo uma insatisfação com o trabalho atual, que passa a ser visto como “atrasado” mesmo que na prática todos os projetos estejam obtendo o sucesso esperado. Pensar que “poderíamos/deveríamos usar a tecnologia X ou Y” passa a ser mais preocupante que os resultados, o que muitas fezes não faz muito sentido.

Em ambos os casos a conclusão do profissional é sempre a mesma: falta tempo! E o fato do dia ter apenas 24 horas e ainda por cima existirem outras atividades mais importantes do que trabalhar como se relacionar com outras pessoas e cuidar da saúde acabam gerando um estress absurdo.

Infelizmente não tenho a fórmula mágica para resolver o problema, mas acredito que fazer o que gosta e valorizar outras coisas da vida além do trabalho podem servir como parâmetros na hora de pesar o estress que o trabalho pode causar. Existe algum remédio na farmácia para ajudar nisso? Duvido muito.

Exemplo TDD, parte 3: corrigindo bugs

Ao final da segunda parte do nosso exemplo, terminamos com a seguinte lista de implementação:

• Representar hora no formato hh:mm
• Permitir a criação de uma hora padrão (”00:00?)
• Não permitir que se crie hora fora do formato hh:mm
• Pode haver uma hora do tipo h:mm
• Pode representar horas acima de 23:59, então uma hora como 300:00 é válida
• Horas negativas são válidas
• Deve ser possível fazer soma de horas

Vamos resolver o primeiro item que levantamos agora, mais uma vez partindo de um novo teste:

    public void testCriacaoHoraNoveEMeia()
    {
        Hora hora = new Hora("9:30");
        assertEquals("9:30", hora.toString());
    }

Ao rodar este teste ele esbarra na validação que criamos anteriormente:

java.lang.RuntimeException: Formato de Hora inválido: 9:30

Como isso não deveria acontecer, mudamos a nossa expressão regular:

        if (!string.matches("[0-9]*:[0-9][0-9]"))

Todos os testes passam, e podemos passar para nossa próxima tarefa que é representar horas maiores que 23:59. Fazemos isso com mais um teste:

    public void testCriacaoHoraCentoETrinta()
    {
        Hora hora = new Hora("130:00");
        assertEquals("130:00", hora.toString());
    }

Rodamos o teste e ele passa sem nenhuma mudança no código. Isso significa que o nosso item da lista já estava funcionando.

Neste ponto um outro programador que já usando nossa classe em outra parte do sistema afirma: “tem um problema com esse código! Parece ser possível criar uma hora sem definir a quantidade de horas (“:15”), o que vai contra nossa definição mínima de hora como h:mm”. Como não pretendemos mudar o formato da hora e outras partes do sistema já estão usando validação, esta nova possiblidade tornou-se um problema. E agora?

Corrigir bugs com TDD não é diferente de implementar qualquer outra funcionalidade. Basta ficar atento para não implementar a correção sem a criação de um teste antes. A definição deste teste permite a descrição e a reprodução exata do problema, e cria uma validação em código que garante que o erro não voltará a ocorrer.

Então vamos partir para a correção, escrevendo um teste que especifique o problema:

public void testCriacaoHoraSohComMinutos()
{
	try
	{
		new Hora(":15");
		fail("uma hora não pode ser criada só com minutos");
	} catch (RuntimeException e)
	{
		assertEquals("Formato de Hora inválido: :15", e.getMessage());
	}
}

O teste falha, confirmando as suspeitas de que algo não está como deveria:

junit.framework.AssertionFailedError: uma hora não pode ser criada só com minutos

Não resta nada a fazer a não ser refinar nossa expressão regular:

        if (!string.matches("[0-9][0-9]*:[0-9][0-9]"))

Com esta mudança todos os testes passam mais uma vez. Perceba que independente do que estamos implementando (correção ou nova funcionalidade) o processo é sempre o mesmo. Então restam os seguintes itens na nossa lista:

• Representar hora no formato hh:mm
• Permitir a criação de uma hora padrão (”00:00?)
• Não permitir que se crie hora fora do formato hh:mm
• Pode haver uma hora do tipo h:mm
• Pode representar horas acima de 23:59, então uma hora como 300:00 é válida
• Não pode haver hora definida apenas com minutos (“:15”)
• Horas negativas são válidas
• Deve ser possível fazer soma de horas

Até a próxima!