Dojo #4 - Where's Waldorf

Data: 28/11/2008
Participantes: Hugo, Vanderson, Rodrigo, Eduardo, Gustavo e Tiago
Randori: Where's Waldorf
Linguagem: Ruby

Esse post está bem atrasado, mas como ninguém teve tempo pra postar antes, aqui está.

Neste Dojo arriscamos mais uma vez uma linguagem diferente de Python, dessa vez Ruby.
Houve uma enquete para decidir qual seria a linguagem usada no dojo mais ou menos uma semana antes do dia 28 no grupo de discussão, e por democracia, Ruby venceu.
Durante a semana alguns olharam a documentação da linguagem e alguns nem sequer lembraram disso. O resultado foi que o dojo acabou ficando engraçado, por tropeçarmos em detalhes sintáticos.

Houve também, pela primeira vez desde o início de nossas reuniões, uma pessoa que não faz parte do NSI (Núcleo de Pesquisa em Sistemas de Informação).
Como de costume, foi realizado na segunda sala do NSI, no CEFET - Campos. Acabou iniciando com mais ou menos uma hora e meia de atraso, devido a reunião que fazemos no NSI toda sexta-feira.

Eu, Hugo, olhei alguns problemas no livro Programming Challenges e selecionei três simples. Os problemas eram: 3n + 1, Poker Hands, Where's Waldorf.
De primeira o Poker Hands foi eliminado, porque tinha muitas regras e pouca gente havia jogado poker na vida. Depois o 3n + 1 foi eliminado porque alguns acharam bem idiota e Where's Waldorf ganhou.

O problema era basicamente procurar por palavras dentro de uma grade, parecido com um jogo de palavra-cruzadas. Houve alguns problemas iniciais com a IDE selecionada pelo Rodrigo (NetBeans) e alguma coisa do Compix no notebook dele. Sanado os problemas fomos ao dojo, propriamente dito.

Coisas boas:

• A maioria dado uma passada de olho na sintaxe de Ruby


• Linguagem escolhida por votação


• A mudança de data facilitou o local pra realizar o dojo


• A presença de um convidado


• A prática de TDD e Baby Steps foram implementadas de forma correta

Coisas ruins:

• Não conhecer a linguagem o suficiente pra não colar (olhamos a documentação durante o dojo)


• Falta de organização (ausência de um dojo organizer)


• Atraso de duas horas


• A mudança de data foi decida de última hora


• Dois abandonos no meio do dojo

Dojo #3 - Fizz/Buzz

Data: 08/11/2008
Participantes: Diego, Rodrigo, Everton e Gustavo
Randori: Fizz/Buzz
Linguagem: JavaScript

Após o problema das eleições, o dojo volta a ser realizado no CEFET. A sessão, que estava marcada para as 15h, iniciou-se por volta de 16:30, por contratempos diversos que serão tratados na retrospectiva.

O problema foi proposto pelo Diego, que, porém, manifestou a questão do problema poder ser resolvido rapidamente, por ser bem fácil. Eu sugeri, então, que a linguagem a ser utilizada fosse o JavaScript, pois em Python, linguagem em que todos são proficientes (menos eu, mas chego lá!), a solução seria rápida demais, no que todos concordaram.

Pelo fato de a linguagem (e o problema [ver retrospectiva]) terem sido decididos na hora, foi necessário gastar algum tempo com setup, procurando uma ferramenta de testes unitários para o JavaScript, no que encontramos a JSUnit. Não consegui configurá-la de modo rápido e optamos por escrever um método assertEquals caseiro para que pudéssemos executar rapidamente os testes de unidade.

Para incrementar ainda mais a dificuldade, decidimos adotar alguns dos preceitos de Object Calisthenics: utilizar apenas um nível de endentação por método, não utilizar a palavra-chave else (e nem derivadas como elif), utilizar apenas um ponto por linha (ou seja, respeitar a Lei de Demeter: somente fale com seus vizinhos imediatos), não utilizar classes com mais de dois atributos e não utilizar acessors e nem properties.

Tudo pronto, iniciamos o dojo. De cara, uma das dificuldades foi implementar orientação a objetos em JavaScript. Alguns de nós já tínhamos visto algo de OO com JavaScript mas nunca havíamos implementado nada. Encontramos um exemplo, o Diego e o Gustavo deram algumas dicas e lá fomos nós.

A implementação foi bastante simples (até porque o problema também era) e conseguimos terminar a parte 1 do problema (Fizz para múltiplos de 3, Buzz para múltiplos de 5 e FizzBuzz para múltiplos de 3 e 5), mas não chegamos a iniciar a segunda parte (incluir em Fizz números que contém 3, em Buzz os que contém 5 e em FizzBuzz ambos).

O projeto privilegiou a OO clássica, utilizando uma "classe" FizzBuzzNumber onde cada objeto tem a responsabilidade de responder seu status (Normal, Fizz, Buzz ou ambos).

Em cerca de 1 hora e meia, terminamos o dojo.

Sobre as regras do Object Calisthenics, creio que trapaceamos a regra de não utilizar else nos valendo de uma seqüência de ifs.

Do c@r@!#0

• Uso de uma linguagem diferente
  
  O uso de uma linguagem que não é do dia-a-dia de nenhum dos desenvolvedores traz interesse e desafio adicionais


• Melhor utilização do TDD
  
  Ao contrário de dojos anteriores, a utilização de TDD ocorreu mais naturalmente, com poucas exceções.


• Aprendizado de OO em JavaScript
  
  O dojo rendeu um aprendizado concreto para todos, que foi a utilização de JavaScript orientado a objetos


• Ausência de "correria" para resolver o problema
  
  Não houve atropelamento das regras do dojo (baby steps, TDD) para que se chegasse mais rapidamente à solução.

Uma m&rd@

• Atraso para o início do dojo
  
  O dojo começou com inacreditáveis uma hora e meia de atraso.


• Inexistência de um dojo organizer
  
  O atraso se deveu, entre outras coisas, à ausência da definição de um dojo organizer. O Diego fez alguma coisa neste sentido, mas por iniciativa própria. É preciso que o organizer seja definido com antecedência


• Poucos participantes
  
  Tivemos apenas quatro participantes. E isto logo após uma enquete a respeito de dia e horário na qual a maioria escolheu este.


• Falta de confirmação de presença
  
  Quase não se viabiliza o dojo pela falta de participantes (até as 16h só havia dois presentes). Seria bom haver um confirmação prévia na lista de quem participará do próximo dojo, para eventual cancelamento em caso de insuficiência de participantes


• Não ter utilizado uma ferramenta de testes unitários
  
  A utilização de uma solução caseira para testes unitários foi um fator de perda de tempo, além de ser uma reinvenção da roda.


• Setup demorado
  
  As definições de última hora levaram a um setup bastante demorado


• Linguagem definida na última hora
  
  Apesar do uso de JavaScript ter sido avaliado como positivo, é preciso definir a linguagem com antecedência, para que o ambiente fique pronto antecipadamente.

Dojo 02 - Campo Minado

Data: 25/10/2008
Participantes: Diego, Hugo, Vanderson, Rodrigo, Gustavo e Lucas
Randori: Problema do Campo Minado
Linguagem: Python

A sessão sofreu uma mudança de local e horário devido à impossibilidade de se entrar no CEFET - Campos, por que as urnas eletrônicas ficam lá. Logo, ninguém poderia entrar.

Assim sendo, o dojo foi marcado para começar às 10:00hs na Universidade Cândido Mendes(UCAM), porém, como temos um sério problema com pontualidade, começamos às 11:00, utilizando a modalidade RandoriKata.

No início, houve uma discussão excessiva sobre como seria o Design da implementação(Big design up front), o que atrasou um bocado o início da implementação real.

Quando os "rounds" começaram, algumas pessoas tiveram problemas em escrever os testes primeiro, pois nem todos utilizavam TDD. Houve também uma divergência no design, quando tivemos dois testes que levariam a implementações completamente diferentes.

Passado isto, o ritmo prosseguiu normalmente, até que de repente, chegamos às 13:30hs. Sim, o dojo levou 2:30hs!! Todos acharam muito legal e engraçado, principalmente a parte de ficar quieto enquanto o teste estiver no vermelho.

Coisas Ruins:

• Mais conversa que código
• Pouco entendimento de TDD / Baby Steps
• "Tagarelice" da platéia
• Falta de confiança
• Correr para resolver o problema.

Coisas boas:

• Maior assimilação dos princípios do coding dojo
• Todos participantes habituados com testes unitários
• Bom entendimento do problema.
• Foco no problema principal
  

Dojo 01 - Carga pesada

Data: 11/10/2008
Participantes: Diego, Hugo, Wallace, Ewerton, Juliana e Tiago
Randori: Problema da Carga Pesada
Linguagem: Python

Começamos o evento muito mais tarde do que o esperado(4h e 30min). Primeiro, eu e o Hugo explicamos(ou tentamos...) sobre as premissas do coding dojo e como funciona a processo colaborativo do RandoriKata. Depois, disto mostramos os três problemas selecionados para avaliação de todos. Ficou no empate e achei melhor deixar no acaso(nada como um "cara e coroa" para resolver o impasse). O Problema da Carga Pesada foi o selecionado. O problema era muito simples, o que foi bom pois assim o pessoal poderia obter foco no processo e não tanto no problema. O pior é que o processo foi realmente o empecilho. A primeira dupla ficou perdida no inicio para escrever o primeiro teste. O teste acabou saindo com a ajuda externa ao pair programming. Depois disto ficou uma dúvida no ar sobre o que testar. Levantou-se a idéia de testar a validação da entrada. Passaram alguns rodízios e todos perceberam que era um teste inútil para o momento, e que existia outras coisas mais importantes para serem testadas. Depois disto a ficha caiu, o ritmo começou a aumentar, mas de repente 6h!!!! Chegou o final do dojo . Então fizemos uma retrospectiva do que cada um gostou e não gostou. Não irei citar nomes porque na verdade isto não é importante.

Pontos Legais

A idéia de testar primeiro foi algo que ficou como primordialidade no processo (TDD). NInguém dava propostas de código sem ter feito testes primeiro. Pro-atividade do pessoal para participar programando.

Pontos Ruins

Durante a troca do co-piloto para piloto e a chegada de um novo piloto, o pessoal comentava muito, sendo que os testes não tinham passado, o que é uma premissa do dojo. Faltou foco no problema, sendo que o problema foi discutido e todos o compreenderam. Na hora o foco foi em testes supérfluos. Relataram que a falta de uma cópia pessoal do problema atrapalhou o processo de compreensão do problema. Durante o dojo algumas pessoas sentiram fome e tiveram a grande idéia de sugerir aperitivos durante o dojo para a platéia. A técnica de testes não foi perfeitamente utilizada, deixando vestígios de teste na implementação!!!!! A técnica de baby-steps foi utilizada incoerentemente, tornando algumas implementações desnecessárias para o tratamento de um cenário simples, aumentando o tempo de resposta de convergência do teste.


Relato escrito pelo Diego