Dojo UENF [8]

sábado, 7 agosto 2010

No dia 01/06/2010 aconteceu mais um Dojo UENF. Depois de uma boa experiência, porém não viável, com um formato alternativo de Dojo, voltamos a utilizar o formato original do Dojo. Mudamos também de linguagem e utilizamos Python. Antes apenas havíamos utilizado Ruby.

O problema escolhido foi o de modelar a canção infantil “Atirei o pau no gato”, ideia tirada de um Dojo que vimos no 15° EDTED (onde conversamos com o Henrique e decidimos iniciar nosso Dojo).

Essa edição do Dojo foi uma das mais legais! O problema foi bem divertido e fluiu de forma muito natural. Tivemos também a oportunidade de testar algumas ferramentas para testes com Python: o should-dsl e specloud. Isso fez com que os testes fossem escritos de forma semelhante ao que fazemos no Ruby (ou seja, legibilidade extrema), além de ficar verde e vermelho quando os teste passavam ou quebravam. Utilizamos também uns snippets que criei para o Gedit que ficaram bem legais, principalmente o de definição de métodos e os de metchers do should-dsl.

Participantes

Retrospectiva

🙂

  • Python rocks!
  • Todos participaram
  • Problema muito legal e divertido
  • Shoud-dsl e Specloud estão muito bons!
  • Snippets irados!

😦

  • Pessoal chegou tarde

É isso aí. Abraços à todos!

Anúncios

Dojo UENF [7]

sábado, 7 agosto 2010

No dia 25/05/2010 (sim, tem muito tem já, rsrs) realizamos mais um Dojo UENF. Seguimos com a abordagem do ShuryoKata, continuamos com o problema do dominó.

Nos primeiros minutos fizemos uma retrospectiva sobre a atual situação do código.

No início tivemos dificuldade em refletir sobre a modelagem corrente do problema, existiam divergências sobre como ocorreria a comunicação entre os objetos e de como organizaríamos as especificações para que pudessem refletir o fluxo de um jogo de dominó, foi neste momento que percebemos a necessidade de uma abordagem de teste de mais alto nível.

Percebemos que para continuar com esta modalidade de dojo é necessário uma ferramenta de integração que possa descrever num nível mais alto o fluxo do problema, contudo, isso fugiria completamente do objetivo do Dojo, muito mais do que já esta estávamos fugindo.

Usar o ShuryoKata foi uma boa experiência, porém, não se mostrou viável. Ninguém revisava o código antes de ir para o Dojo; nos dois primeiros o pessoal estava empolgado, mas no terceiro, quando começou a ficar grande o problema, ficou desanimador.

Assim, decidimos em retornar a abordagem convencional do Dojo, que é a que realmente funciona e se quisermos nos aprofundar em alguma coisa, faremos um Fork =)

Participantes

Retrospectiva

🙂

  • Gedit estava réupis

😦

  • A idéia sobre como implementar não ficou clara
  • Sentimos que para o problema mais complicado faltou uma ferramenta teste de aceitação
  • Pouca gente programou
  • Falatório no vermelho

Foi isso. Abraços.