Dojo 005 – Bilhetagem Eletrônica

Data: 23/09/2009.

Presentes: Cairo Noleto, Cleiton Francisco, Ewerton Costa e Weldys Santos.

Linguagem: Ruby.

Problema: Bilhetagem Eletrônica.

Nós, insatisfeito com a bilhetagem eletrônica em Teresina, resolvemos fazer nosso próprio sistema de bilhetagem, livre de bugs e cheio de testes.

Devido a pouca presença, conseguimos explicar rapidamente para o Ewerton, que ainda não sabia do problema.

Solução: Está no Github.

Tínhamos a idéia de fazer 1 classe, que seria herdada por outras 3 e fazer uma classe para leitura do cartão. Fizemos apenas a classe Cartão, com os métodos de inserção de crédito, debito e saldo.

Esse Coding Dojo foi um dos que os testes ficaram a maior parte do tempo verde!

Retrospectiva:

Nós discutimos um pouco sobre a pouca presença de poucas pessoas, eu (Cairo Noleto) acho que o problema pode ser o dia fixo, já que a desculpa mais escutada é que “não posso faltar a aula”. Mas o Cleiton disse que pode ser por conta da linguagem, enfim, nós decidimos que iríamos discutir na lista sobre os dois casos.

Foi Bom:

• Teve lanche!!!
• Boa explanação do problema.
• Uso de vários matchers do rspec.
• Problema ótimo

Pode Melhorar:

• Mais participantes!
• Fazer refactoring.
• Sala para disputas calorosas!
• Voltar a discutir o rodízio de dias.

Dojo PHB 003 – Jogo da Velha

Dojo PHB 003

Bom, aqui no litoral nossos encontros estão a todo vapor. A cada semana um passo novo é conquistado e, de forma gradual, todos vão participando e se divertindo – como realmente é para ser! ;).

Visão geral (data e problema): Como sempre, nosso quarto encontro (003) aconteceu na sexta-feira (dia 18/09/2009) e decidimos não mais continuar com o problema do caixa eletrônico, pois acreditávamos que ele seria bem mais complexo e poderia causar prejuízos ao nosso precioso tempo. Então partimos para o ataque ao “Jogo da Velha”, pois é um problema conhecido por todos, não muito complexo e interessante.

Participantes: professores (dois) e alunos do curso técnico em informática do IFPI (módulos I, II e III de diferentes turnos).

Linguagem: Java

Framework de teste: JUnit

Solução: Todos os códigos estão no Github (http://github.com/dojopiaui)

Retrospectiva

Foi bom:

– Revezamento (a grande maioria participou);

– Problema interessante e não muito complexo;

Pode melhorar:

– Perda de tempo para iniciar os testes (a “coisa” realmente andou apenas quando uma equipe mais experiente assumiu o “cockpit”) e isso deu-se pela falta de prática das equipes iniciais;

– Nem todos participaram (três pessoas apenas assistiram);

– Piloto e co-piloto devem falar para que todos ouçam e não só entre si, pois isso evita dispersões, conversas paralelas e melhora o potencial de comunicação dos participantes.

Projeções: Para o próximo encontro finalizaremos o problema e, dependendo do tempo, poderemos já planejar e iniciar outro.

Fotos:

Dojo PHB 003 (Problema)

Dojo PHB 001 e 002 – Caixa Eletrônico

Em Parnaíba os Dojos estão andando. Hoje teremos nossa 4ª reunião. Peço desculpas pelo nosso atraso em reportar as 2 últimas reuniões que somente vou resumir agora.

Dojo PHB 000 – Dia 28 de agosto – Apresentação do DOJO – Apresentado em outro post.

Dojo PHB 001 – Dia 4 de setembro – Aquecimento (Retangulo) e Caixa Eletrônico

Aquecimento

Resolvemos iniciar a reunião com um aquecimento que basicamente era um problema simples para facilitar o entendimento dos testes por parte de quem jamais tinha visto testes com JUnit. Assim, o problema consistiu em criar uma classe Retangulo com métodos para obtenção da área e perímetro.

Problema

Depois da brincadeira com o Retangulo, resolvemos partir para um problema mais desafiador. Escolhemos, então o problema do Caixa Eletrônico para resolver. O objetivo era simular a entrega de notas por um caixa eletrônico. Os requisitos foram os seguintes:

• Entregar o menor numero de notas
• Saldo Infinito (para simplificar a resolução)
• Notas infinitas (para simplificar a resolução)
• Notas disponíveis de R$ 100,00; R$ 50,00; R$ 20,00 e R$ 10,00

Exemplo: para as notas disponíveis de R$ 100,00; R$ 50,00; R$ 20,00 e R$ 10,00, os seguintes saques resultarão nos seguintes resultados:

Valor do Saque: R$ 30,00 – Resultado Esperado: Entregar 1 nota de R$20,00 e 1 nota de R$ 10,00.

Valor do Saque: R$ 30,00 – Resultado Esperado: Entregar 1 nota de R$20,00 e 1 nota de R$ 10,00.

Futuros requisitos:

• Possibilidade de personalizar as notas disponíveis através de um array contendo os valores das notas;
• Ordenação do array de notas disponíveis;
• Saldos do cliente e cédulas;
• Valor do saque descrito em texto.

Durante a codificação resolvemos já atacar um requisito futuro que era a possibilidade de personalizar as notas disponíveis através de um array já ordenado contendo os valores das notas. No entanto, não houve tempo suficiente para devolvermos o resultado por extenso. O resultado foi obtido como um array de inteiros contendo a quantidade de notas necessárias para o saque.

Na retrospectiva, achamos por bem continuar a resolução do problema na reunião seguinte.

Dojo PHB 002 – Dia 11 de setembro – Caixa Eletrônico (continuação)

Continuação do problema do Caixa Eletrônico.

Dessa vez resolvemos atacar os requisitos:

• Tratar array de notas disponíveis desordenado, fazendo sua ordenação;
• Obtenção do resultado por extenso (valor do saque descrito em texto) e não apenas como um array com as quantidades;
• Tratar repetições no array de notas disponíveis.

Ao final da resolução, criamos uma suíte de testes para realizar todos os testes (Retangulo e CaixaEletronico) de uma só vez.

Durante a retrospectiva os seguintes problemas foram apontados:

• Somente 2 pilotos “codaram” (codificaram) durante todo o encontro;
• Platéia ficou opinando antes do verde, ou seja, antes do teste passar;
• Não houve revezamento a cada 7 minutos;
• O tempo total de 1h 30min foi considerado curto.

A sugestão foi sanar estes problemas no próximo encontro do dia 18 de setembro.

O código referente ao Aquecimento (Retângulo) e Caixa Eletrônico pode ser baixado no GitHub.

Abaixo algumas fotos:

Coding Dojo Especial InfoPi 2009

Data: 17/09/2009.

Presentes: Muitos, não sabemos o nome de todos! Foi o dojo com mais gente.

Linguagem: Ruby.

Problema: Equação do segundo grau.

Resolvemos algumas questões antes de iniciarmos, queríamos apenas um problema simples, que todos podessem entender e participar.

Solução: Está no Github.

Antes de comerçamos explicamos o que era o Coding Dojo utilizando os slides do Régis Pires, mostramos algumas coisas que fazemos, tentamos passar a idéia do Ágil, do TDD, de tudo!

Como muitos nem sequer tinham ouvido falar de ruby (E como já tínhamos nos preparado), apresentamos de forma extremamente rápida a sintaxe, apenas um pouco para podemos resolver aquele problema.

Eu sei, o Coding Dojo é para ser feito em uma linguagem que todos conheçam, não precisam dominar, mas como nós pensamos no espírito de aprendizagem, achamos que um problema matemático simples poderia ser resolvido por todos usando Ruby (E que foi comprovado!)

Então, nesta sequência, nós preparamos um esquema onde um mais experiente em Ruby sempre iria conduzir um que não tinha tanta fluência assim. Dessa forma ficamos com duas linhas: Eu(Cairo), Cleiton, Cyrus e Weldys e com a platéia, nos revezando.

Infelizmente o único que sabia um pouco a mais de Ruby era o Caio, o restante da platéia não conhecia e os que conheciam, era poucos fluentes. Tinha um também que não sabia nem muita coisa de programação, mas foi o segundo da platéia a participar!

O mais legal em tudo, é que conseguimos passar a mensagem de que qualquer linguagem pode ser usada para resolver qualquer tipo de problema, e que o mais importante é a lógica de programação.

E a codificação começou com o Cleiton e com o Pedro Alcântara:

Depois de algum tempo nós decidimos finalizar o problema, com um código funcional e uma boa bateria de testes! 🙂

Retrospectiva:

Nós tivemos a maior retropesctiva (Mais gente, mais opiniões).

Foi bom:

• Número de participantes
• Problema simples
• Presença do Pedro Alcântara
• Ótimas instalações
• Data show

Pode melhorar:

• Diferença de conhecimento entre os participantes
• Teoria sobre Testes podem ser mais explanados
• Tem que ter lanche
• Nem todos participaram
• Mais voluntarismo
• A presença do Fábio Gomes e do Ricardo Ramos

Felizmente nós conseguimos explorar bem a comunicação, mesmo com pessoas que não participaram efetivamente do código, mas participaram contribuindo na discussão de código.

Infelizmente nós convidamos algumas pessoas para participar, mas que não foram. Mas as que foram, realmente foram ótimas!

E algumas fotos:

Dois Cairos!

Dojo 004 – Boliche

Data: 02/09/2009.

Presentes: Cairo Noleto, Marcelo Soares, Cleiton Francisco, Ricardo Farias, Weldys Santes e Cyrus Cavalcante.

Mas o José Esmerino passou por aqui antes do Coding Dojo e depois de muita pressão da mulher, foi embora antes de começarmos. O Fanfarrão do Lucas não veio. Deve ter se confundido, porque ele pensou que antes-de-ontem (novas regras do português!?) era ontem (oO).

Linguagem: Ruby.

Problema: Jogo de Boliche.

Resolvemos antes do Coding Dojo, na lista, de que iríamos resolver o problema da obtenção dos pontos do jogo de Boliche. Queríamos passar uma estrutura para um novo objeto e que ele retornasse o valor total do jogo.

Solução: Está no Github.

Chegamos a um acordo antes de começar a codificar. De que entraríamos com um array de arrays, onde cada array dentro do array array, array, array, array, teria o valor da primeira, segunda ou da terceira rodada (no caso a último frame).

Todos concordaram e principalmente, entenderam o problema. Nós iniciamos os trabalhos com eu (Cairo) e o Marcelo, que pela primeira vez codificou. O layout da sala foi o mesmo do Dojo 003, então foi melhor para gerenciarmos tudo. Apenas esquecemos uma vez de ligar o relógio, já no finalzinho!

Depois de quase 3 horas, nós finalizamos o Coding Dojo sem um código pronto, cheio de ifs/elses que com certeza podem e devem ser refatorados. Nos perdemos quando o primeiro bug apareceu e não conseguimos avançar mais.

Retrospectiva:

Esse foi cheio de pontos que devem melhorar.

Devem melhorar:

• Usar outros matchers do Rspec (estamos praticamente só usando o should ==)
• Mais pessoas. Esse Dojo foi o que teve menos gente até agora, 6.
• Discutir mais antes do código, nós discutimos apenas sobre o problema, não discutimos como seria o funcionamento.
• Quando os testes passarem, discutir o design do código.

Positivos:

• Poucas pessoas (dava pra gente brincar mais vezes! :D)
• Problema amplo. Existe mil maneiras de se resolver o boliche.

Temos muitos pontos a melhorar, eu acho que o nosso problema foi comunicação, a cada dupla, uma implementação diferente era abordada, não convesamos entre si e nem com a platéia para definir como deveria ser resolvido o problema. Por isso que agora, quando os testes estiverem passando, vamos discutir mais com a platéia.

Algumas fotos:

Problema para o Dojo Teresina 004 – Boliche

Conforme já foi discutido na lista o problema do 4º dojopi [em Teresina, já que agora temos também a contagem do dojopi de Parnaíba correndo em paralelo 🙂 ] deve ser um programa de pontuação de partidas de Boliche.

Como eu não entendo muito de boliche resolvi fazer uma pesquisa pra conhecer mais sobre o jogo. O resultado é um resumo das regras no tocante à pontuação. Ao final teremos um roteiro que irá guiar nossos testes e, consequentemente, nossa implementação.

Contagem dos pontos

O jogo de boliche consiste de dez frames. Um jogador tem direito a duas bolas em cada frame. A pontuação de uma partida varia de acordo com a quantidade de pinos e a forma como o jogador os derruba.

Em resumo, existem três formas de acumular pontos:

1. pelos pinos derrubados, quando não fizer strike ou spare;
2. pelos pinos derrubados, mais (bônus) os pinos derrubados nas DUAS bolas seguintes quando fizer strike;
3. pelos pinos derrubados, mais (bônus) os pinos derrubados na BOLA seguinte quando fizer spare.

Strike: é marcado quando todos os pinos são derrubados no primeiro lançamento do frame, neste caso, o jogador não precisará fazer a segunda jogada do frame e a pontuação se dará conforme o item 2 acima. No quadro de pontuação o strike é simbolizado com um X.

Spare: acontece quando os pinos que não foram derrubados no primeiro lançamento são derrubados no segundo arremesso do mesmo frame. Os pontos obtidos são descritos no item 3 acima. No quadro de pontuação o spare é simbolizado com uma /.

O último frame é especial, ele “poderá” permitir uma jogada extra, caso o jogador obtenha um spare ou duas jogadas extras caso o jogador tenha obtido um strike.

No quandro de pontuação o símbolo ‘-‘ significa que não houve pinos derrubados na jogada. A pontuação máxima no boliche é de 300 pontos (12 strikes).

Simulação

Pontuação de uma partida de boliche

Frame a frame

Frame 1: 30 pontos

10 pontos pelo strike + bônus das DUAS BOLAS jogadas na seqüência (10 + 10, já que o jogador fez dois strikes logo a seguir) por esse strike.

No primeiro frame o jogador do exemplo derrubou os 10 pinos na primeira bola jogada (strike), porém para marcar esses dez pontos do primeiro frame, antes é preciso jogar as duas bolas seguintes (porque o bônus pelo strike são os pontos das DUAS BOLAS seguintes)

Frame 2: 57 pontos

São os 30 acumulados do primeiro frame (veja acima) + os 10 pontos pelo strike que fez neste segundo frame + bônus das DUAS BOLAS jogadas na seqüência por esse strike (na primeira o jogador fez outro strike e na segunda derrubou apenas 7 pinos). Então: 30 + 10 + 10 + 7 é igual a 57 pontos (total até o segundo frame)

Frame 3: 76 pontos

São os 57 acumulados até o segundo frame + os 10 pontos pelo strike que fez neste terceiro frame + bônus das DUAS BOLAS jogadas na seqüência por esse strike (na primeira o jogador derrubou 7 pinos e na segunda apenas 2).

57 + 10 + 7 + 2 = 76

Frame 4: 85 pontos

São os 76 pontos acumulados até o terceiro frame + os 9 pontos (7+2) conseguidos nesse frame (sem bônus porque não fez strike nem spare).

76 + 9 = 85

Frame 5: 95 pontos

São os 85 pontos acumulados até o quarto frame + os 10 pontos (spare 8+2) conseguidos nesse frame + o bônus da BOLA SEGUINTE por esse spare (zero, porque o jogador cometeu falta e não marca ponto).

85 + 10 + 0 = 95

Frame 6: 104 pontos

São os 95 pontos acumulados até o quinto frame + os 9 pontos conseguidos nesse frame (0 + 9), sem bônus porque não fez strike nem spare).

95 + 0 + 9 = 104

Frame 7: 124 pontos

São os 104 pontos acumulados até o sexto frame + os 10 pontos pelo strike conseguido nesse frame + bônus das DUAS BOLAS jogadas na seqüência por esse strike (na primeira o jogador derrubou 7 pinos e na segunda 3 pinos).

104 + 10 + 7 + 3 = 124

Frame 8: 143 pontos

São os 124 pontos acumulados até o sétimo frame + os 10 pontos pelo spare conseguido nesse frame + o bônus da BOLA SEGUINTE por esse spare (o jogador derrubou 9 pinos).

124 + 10 + 9 = 143

Frame 9: 152 pontos

São os 143 pontos acumulados até o oitavo frame + os 9 pinos derrubados nesse frame (sem bônus porque não fez strike nem spare).

143 + 9 = 152

Frame 10: 180 pontos

São os 152 pontos acumulados até o nono frame + 10 pelo strike na primeira bola jogada nesse frame + bônus das DUAS BOLAS seguintes (outro strike e 8 pinos).

152 + 10 + 10 + 8 = 180

OBS: se fizer strike na primeira bola jogada no décimo frame ganha-se DUAS bolas extras para jogar como bônus. Se fizer spare nas duas primeira bolas jogadas no décimo frame ganha UMA bola extra para jogar como bônus.

Fontes:

• http://www.boliche.com.br/instru6_6.htm
• http://www.colegiosaofrancisco.com.br/alfa/boliche/boliche.php

Apresentação Dojo em Parnaíba

Ontem realizamos uma apresentação sobre Coding Dojo em Parnaíba. Os slides podem vistos a seguir…

A apresentação ocorreu no Instituto Federal do Piauí (IFPI) Campus Parnaíba e contou com a presença de mais de 50 pessoas!!! Fiquei tão empolgado com a apresentação que esqueci das fotos, mas espero que alguém tenha REGIStrado algo.

Depois da apresentação, mostramos um vídeo em que o Danilo Sato falava sobre testes, TDD (Test Driven Development), BDD (Behavior Driven Development) e implementava uns testes usando BDD. Mostramos também um screencast sobre TDD que o Ivan Sanchez do Dojo Floripa fez usando Java / Eclipse / JUnit.

Após os vídeos, decidimos o seguinte sobre os Dojos realizados em Parnaíba:

• Ocorrerão todas as sexta-feiras a partir das 16h30 no IFPI Campus Parnaíba;
• Iniciaremos usando TDD com Java / Eclipse, por serem as ferramentas mais conhecidas pela grande maioria dos participantes.
• Como a maioria dos muitos participantes ainda não conhece o JUnit, apresentaremos um Kata na nossa próxima reunião, ou seja, eu resolverei sozinho um problema ao vivo desde o início. Daí em diante, a intenção é realizarmos um Randori.

Dojo 003 – Conversor de Moedas

Data: 26/08/2009.

Presentes: Weldys Santos, José Tavares, Cleiton Francisco, Monica Regina, Cairo Noleto, Ewerton Costa, Lucas de Castro.

Linguagem: Ruby.

Framework de Testes: RSpec.

Problema: Conversão de Moedas.

Nós decidimos quer resolveríamos o problema não acabado do Dojo 002.

Solução: Está no Github.

Dessa vez, nós chegamos a um acordo comum entre os participantes antes de pegarmos no código. Nos focamos em resolver o problema de conversão. Decidimos que o Euro seria nossa moeda chave, assim davámos para passar de um euro para dolar ou de um dolar para um real sem mais problemas.

O Coding Dojo de ontem foi o mais tranquilo de todos, com o melhor layout de sala até agora. Ainda não temos o nosso projetor, mas estamos resolvendo o problema usando o computador em dual monitor espelhados, e o layout de ontem, a plateia ficou de frente com os pilotos, ficou melhor para quem está pilotando, por quê não ficou todo mundo atrás.

E para quem estava na platéia, ficou melhor de discutir, pq a gente não precisava ficar em pé atrás da dupla e nem precisava ficar se esquivando para olhar para uma tela ou outra!

Retrospectiva:

Como foi tranquilo, fizemos uma Retrospectiva com vários pontos em comum entre todos.

Positivo:

• Espaço Físico
• Dois novos participantes
• Melhoramento dos problemas do Dojo 002
• Abordagem no inicio
• Problema mais claro
• Cronometragem

O que pode melhorar:

• Mais participantes
• Lanche
• Complexidade do problema
• Variar a linguagem
• Fotos!

Nesse teve foto sim, só no finalzinho, quando lembramos da câmera!

Vai algumas fotos:

Coding Dojo Piauí em Parnaíba

Na sexta-feira (dia 28/09/2009) às 15h, ocorrerá no Instituto Federal do Piauí (IFPI) Campus Parnaíba a primeira reunião do grupo de Coding Dojo Piauí em Parnaíba. Nesta reunião inicial, haverá uma apresentação sobre o DOJO, um vídeo demonstrando como esse tipo de atividade ocorre e discussões sobre o funcionamento das reuniões do Coding Dojo em Parnaíba. A reunião é aberta para participação de todos os interessados em aperfeiçoar suas práticas de programação através do uso de boas práticas como TDD (Test Driven Development – Desenvolvimento Orientado a Testes) e BDD (Behavior Driven Development – Desenvolvimento Orientado a Comportamento).

Os relatos dos Dojos de Parnaíba também serão adicionados a este blog!!! Divulgue e participe!!!

Coding Dojo Especial InfoPi 2009

É com orgulho que iremos fazer nosso primeiro Coding Dojo especial em um evento aqui em Teresina, será no InfoPi 2009.

Para quem ainda não está ligando a cara com o nome, o InfoPi é o antigo InfoCefet, devido a alteração do nome dos cefet’s para if’s. Esse ano contará com um dos organizadores do FISL.

Esse ano as palestras serão realizadas no auditório do Metropolitan Hotel, os outros eventos serão realizados no auditório/salas do Ifpi.

O Coding Dojo será no auditório do Ifpi no dia 17/09/2009 das 14 às 17:30. Estamos preparando um Coding Dojo especial. Então não fique de fora, venha participar e se divertir com a gente.