Depois de mais três encontros e um problema resolvido, decidimos atualizar o blog através deste post! Vale ressaltar que, mesmo sem atualizações semanais, as atividades continuam acontecendo com frequência normal (semanal) e que os estudos não param.

Datas: 15, 23 e 30 de Março de 2010.

Presentes: Houve um problema (de memória limitada) no registro dos participantes, mas podemos resgatar alguns através de fotos: Nécio Veras, Giovanni, Roniere, Sávio, Luan, Alan, Dener, William, Francisco Junior (o das Chagas), Márcio Brito, Thiagos (Barros e Costa), Leonardo e muitos alunos do Bloco I do curso Técnico em Informática.

Linguagem: Java

Problema: Codificar frases da língua portuguesa para o Código Morse. Obs: foram inseridos no alfabeto dígitos, caracteres (maiúsculos), ponto e vírgula.

Retrospectivas

Foi bom:

• Problema interessante e repleto de requisitos;
• Maturidade na codificação (evolução durante os três encontros);
• Mais participantes ativos;

Pode melhorar:

• Participação ativa (o número de espectadores ainda é muito alto);
• Merenda (eita ano de 2010 magro!)
• Lista de frequência;
• Plateia dispersa em alguns momentos, principalmente quando o encontro se dá no laboratório;

Solução: no local de sempre: github.

Bom, fizemos ainda um DOJO bem rápido nesta semana (dia 06/04) realizando uma codificação simples e básica voltada para os alunos iniciantes em lógica de programação.

Para esta semana que se segue será um DOJO ESPECIAL, o Dojo Google Code Jam PHB, onde resolveremos um problema do Round de Qualificação do Google Code Jam Africa 2010, realizado no último dia 15.

Sejam todos bem-vindos à participar!

Até breve!

Passadas as festividades gerais de final e início de ano e com a poeira da volta ao período letivo baixando,  é hora de retomarmos as atividades “dojianas” em Parnaíba. Fizemos dois encontros bem interessantes e, apesar de perdermos momentaneamente a presença do sr. Régis Pires, eles foram excelentes!

No primeiro, contamos com a presença de alguns participantes que não conheciam ainda o Coding DOJO (mesmo com as atividades do ano passado!). Por isso, tivemos pouco tempo de codificação, porém as conversas e discussões foram super produtivos. Ainda com essa limitação, houve programação e um leve revezamento entre alguns guerreiros. Para este caso específico, diminuímos o tempo de mudança para cinco minutos.

Vamos às informações:

Primeiro dia

Data: 02/03/2010.

Presentes: Nécio Veras, Giovanni, Denival, Luan, Alan, William, Macilene (candidata a  muda do dojo), Francisco Junior (o das Chagas), Márcio Brito, Dener, Genílson e um aluno parceiro do Denival (desconhecido por todos, mas cunhado do Denival).

Linguagem: Java.

Problema: Foi o FizzBuzz, uma brincadeira tradicional onde os jogadores falam um número em ordem (1,2,3…). Se o número contiver 3 ou for múltiplo de 3 então a pessoa deve dizer Fizz ao invés do número, se o número contiver 5 ou for múltiplo de 5 então o jogador deve dizer Buzz. Por fim, se as duas condições forem verdadeiras então é necessário dizer FizzBuzz.

Retrospectiva

Foi bom:

• Novos participantes;
• Problema simples (bom para quem nunca tinha participado);
• Comunicação entre piloto e co-piloto;
• Presença de mais de três professores;
• Plateia respeitando as regas (verde e vermelho);
• Muitas opções de problemas (extraídas do Dojo-SP);

Pode melhorar:

• Nem todos participaram da codificação;
• Baixo tempo de revezamento (5 minutos);
• Lanche (não teve!);
• Baixa participação da plateia no verde;
• O Alan foi embora mais cedo!
• O Luan perdeu o ônibus e teve que ficar no IF até às 22:00.

Segundo dia

Resolvemos finalizar o problema do FizzBuzz, pois a sua simplicidade permitia que os novos participantes (mais ainda neste segundo encontro) pudessem entender exatamente como funciona o Coding Dojo.

Solução: no github!

Data: 09/03/2010

Presentes: Victoria, Jo Carlos,  Pedro Victor,  George, Cibelle, William, Marcio, Pedro Henrique, Frco. das Chagas, Luan, Alan, Nécio, Sávio e Roniere.

Linguagem: Java

Retrospectiva:

Foi bom:

• Grande numero de participantes (e curiosos);
• Problema de fácil compreensão;
• Os mais antigos estão mais ágeis em programação (problema resolvido de forma forma fácil);
• Bom revezamento;
• O tempo voltou a ser de 7 minutos;
• Plateia obediente;
• Problema resolvido;
• O Luan desta vez conseguiu ir pra casa no ônibus (dizem por aí que ele da outra vez foi a pé no escuro);

Pode melhorar:

• Novamente, o Lanche!
• Alunos com experiências em programação devem participar! (principalmente, do bloco II);
• Problema muito fácil;
• Faltou o Régis (saudades, principalmente por parte do Sávio);

É isso! Foram dois ótimos encontros com muita discussão, brincadeira, socialização e programação de boa qualidade. Vale ressaltar que as atividades continuarão todas as terças em algum laboratório ou sala de aula do IFPI.

Abraços e até lá!

Data: 28/11/2009.

Presentes: Cairo, Daniel, Dmitry, Fabricio e Stevie.

Linguagem: Ruby.

Problema: Criptografia.

Estavam presentes no horário Cairo, Dmitry e Stevie. Conversamos um pouco e começamos a decidir o que seria feito, procuramos no Ruby Quiz e quando o Fabricio chegou resolvemos usar esse problema. Logo depois chegou o Daniel.

Solução: Adivinha onde está!? No github!

Retrospectiva:

Nós discutimos bastante na retrospectiva (Na realidade, no final dela) sobre o quão complexo deve ser os problemas e seus testes. Não chegamos a nenhuma conclusão, mas foi uma boa discussão sobre testes.

O que foi bom:

• Resolução do problema
• Desktop melhor do que notebook
• Tempo mais visível
• Retrospectiva

O que pode melhorar:

• Presença de mais gente
• Problema mais complexo
• Lanche (Recorrente…)
• Horário de inicio (O Fabricio falou em começar no horário, mesmo que tenha uma pessoa Uma pessoa não da pra fazer dojo!. Ele comentou sobre isso e acho que vamos adotar essa postura, sempre ter gente no horário ajuda e muito.
• Escolha do problema antes na lista

Foi um ótimo Coding Dojo, o problema simples, uso de alguns métodos de hash e de string, testes passando.

A princípio nossa tarefa era implementar uma simulação do jogo Texas hold ‘em, mas devido a maioria dos presentes não conhecer bem as regras deste estilo de porker, o tempo já estava curto.

Então, uma sugestão dada pelo Marvin foi a implementação do jogo Campo Minado. Depois de explorarmos melhor o jogo definimos nosso objetivo: um gerador do jogo de Campo Minado.

Lembra do jogo Campo Minado, onde o objetivo é revelar um campo de minas sem que alguma seja detonada, pois é. A idéia era: Dado o tamanho do tabuleiro (no caso, a ordem da matriz quadrada que representa o tabuleiro) e a quantidade de bombas, a idéia foi gerar uma versão em Ruby do Jogo Campo Minado. Como o tempo foi limitado, concluimos apenas o modelo do Jogo, sem GUI (Isso fica quem sabe p/ um próximo Dojo) . Seguindo boas práticas de desenvolvimento conseguimos envolver os desenvolvedores presentes na solução do nosso Jogo.

Data: 21/11/2009.

Presentes: Lucas, Aecio, Edalmo, Fabricio, Marvin Lemos, Dmitry, Jáder, Danilo.

Linguagem: Ruby.

Problema: Campo Minado.

Solução: Está no Github.

Retrospectiva

Positivos:

• Novos participantes
• A maioria dos presentes eram mais proficientes em Java. A experiência com ruby foi muito interessante.
• Envolvemos desenvolvedores de vários backgrounds
• Coding Dojo itinerante
• Abordamos a possibilidade de usar SmallTalk  e outras linguagens em próximas reuniões ( mas iremos dar um tempo p/ que todos possam se familiarizar com a linguagem)
• Houve muita troca de idéias sobre boas práticas em um bom de caso de testes
• Usamos um monitor 17”, mas deu tudo certo

Negativos:

• Não estudamos o problema inicial previamente, isso nos rendeu um belo atraso
• Muitas pessoas comunicam a vontade de participar, mas infelizmente são impedidos pelo trabalho
• Tirar fotos
• Não usamos nenhum SCM
• Falta de presença de quem já participava (Só o Dmitry)

Esse último foi eu que adicionei, eu era um que não estava presente.

Data: 03/10/2009.

Presentes: Cairo Noleto, Cleiton Francisco, Dmitry Rocha, Ewerton Costa, Ricardo Farias e o “Jeová” (Esqueci o nome, é algo parecido com isso ).

UPDATE: O nome é Joval

Estavam lá também presentes o prof. Fábio Gomes e a Mônica, mas eles não participaram, apenas estavam por lá.

Linguagem: Ruby.

Problema: Music Player.

Estávamos sem um problema para resolver, mas o Cleiton chegou com o music player para fazermos.

Após um pouco de explicação nós começamos a codificar.

Solução: Está no github.

Tínhamos várias classes para fazer, fizemos duas, faltou várias funcionalidades, mas mais uma vez terminamos o Coding Dojo com o problema resolvido(ou pelo menos parte dele).

Retrospectiva:

Nós fizemos no IF-PI. Pela empolgação e motivação da galera na lista, eu achei que ia bombar, que ia ter cerca de 20 pessoas, cheio de gente, várias rodadas. NADA, só foi especulação, mais uma vez frustrado!

Nós discutimos sobre, mesmo mudando de data, a pouca presença das pessoas. O prof. Fábio deu a idéia de que poderíamos fazer um Coding Dojo especial uma vez ao mês, onde poderia ser no IF-PI.

Eu já tinha pensado em fazer um “Dojo itinerante” e ir em faculdaes/empresas divulgando a importância do Coding Dojo.

Outra coisa que o Fábio falou foi sobre falar mais das vantagens/desvantagens da prática do Coding Dojo, explanar mais sobre TDD/BDD, programação em par e esse tipo de coisa.

Por conta da pouca presença das pessoas, ainda usaremos nos próximos Dojos Ruby, queríamos conversar com todos sobre o uso de Java e tal, mas como não tinha javeiro em peso, rubistas ganham!

Sobre o Coding Dojo nós chegamos aos pontos:

Positivos:

• Problema Simples e do conhecimento de todos
• Projetor
• Ambiente
• Novo participante
• Bom inicio

Negativos:

• Precisa de mais participantes
• Mais incentivo
• Mais divulgação sobre as vantagens
• Participação do Ricardo e do Dmitry
• Lanche
• Máquina fotográfica

Sobre a máquina, eu realmente esqueci, tanto a máquina, como tirar as fotos do celular, o que resultou em algumas fotos no final!

Mas eu só vou colocar uma, nosso amigo Dmitry Rocha, o mais novo dono e proprietário de um MacBook, quis se mostrar um cara bastante inteligente quando resolveu pegar seu macbook e fazer pose para uma foto. Ele se enganou quando eu percebi que seu lindo macbook nem estava ligado, resultado:

Cleiton, Dmitry e os MacBooks

Dessas perguntas, duas delas não tem uma resposta definitiva. Atualmente estamos realizando o Coding Dojo no Jus Navigandi, ficaremos por lá enquanto o espaço permitir. E estava sendo realizado todas as quarta feiras, mas notamos uma grande evasão, então estamos reencontrando um dia melhor para realizar o Coding Dojo.

O Coding Dojo é uma espécie de treinamento prático de desenvolvimento. Ele é fundamentado nas técnicas Ágeis de desenvolvimento de software. É uma atividade realizada em grupo, de no mínimo duas pessoas.

Para realizar o Coding Dojo é necessário apenas algumas coisas básicas:

• Um computador
• Um projetor (Nós utilizamos um segundo monitor)
• Duas cadeiras
• Duas pessoas

O Coding Dojo funciona da seguinte forma: É escolhido um problema que deve ser levado a cada Coding Dojo (No nosso caso, nós discutimos os problemas na lista, para não perder muito tempo), a maioria dos participantes deve saber uma linguagem de programação e conhecer um framework de testes nessa linguagem (A linguagem não deve ser restritiva, não podemos impedir que um problema seja resolvido por causa da linguagem.).

Sobre a linguagem tem um ponto a mais a ser observado, nós preferimos Ruby porquê é uma linguagem fácil de se aprender. Mas nem por isso vamos fazer todos os Coding Dojos em Ruby. Queremos começar a fazer em Java usando JUnit, mas queremos que mais linguagens entre no Coding Dojo (Python, C, Erlang, Closure, Haskell, PHP, <coloque uma linguagem aqui>).

Sobre as regras do Coding Dojo são simples:

• Dois programadores, 1 piloto e 1 co-piloto.
• A cada 7 minutos o piloto sai, o co-piloto assume e entra um novo co-piloto da platéia.
• Enquanto os testes não estão passando, a platéia só pode fazer perguntas (Que não devem ser tendenciosas).
• Quando os testes estão passando, então discutimos um pouco sobre o andamento do código.
• Ao final é necessário a retrospectiva.

A retrospectiva serve para melhorarmos os próximos Coding Dojo, considerada a atividade mais importante, já que é aqui que vamos colher o feedback.

E um ponto importante que o Ewerton lembrou na lista é a comunicação, sem ela o dojo falhará! Assim como vários e vários projetos de softwares sem comunicação.

Data: 25/09/2009

Presentes: 11 pessoas - Daniel Kohler Oliveira, Antonio José Costa do Nascimento, Roniere da Silva Sousa, Evaldo Sávio Silva Araújo da Costa, Ariel Soares Teles, Nécio de Lima Veras, Mábio Alves Coelho, Regis Pires Magalhães, Francisco Gerson Amorim de Meneses, Luan Machado Pontes e Alan Sousa Santos.

Linguagem: Java

Problema: Jogo da Velha (continuação do Dojo passado)

Solução: atualizada no GitHub.

Resumo:

Na sexta-feira (dia 25/09/2009) demos continuidade ao nosso jogo da velha.

Dessa vez resolvemos validar algumas situações e implementar algumas funcionalidades relacionadas à jogabilidade.

O resumo dos requisitos é esse:

• Tamanho do tabuleiro (3×3)
• Preenchimento
  • Não permitir preenchimento em posição já preenchida (ok)
  • Não permitir preenchimento de valores inválidos (diferente de O ou X) (ok)
  • Não permitir preenchimento em posições inválidas (ok)
  • Preencher todo o tabuleiro (ok)
  • Garantir a alternância de valores de preenchimento (to do)
  • Criar histórico de jogadas (to do)
• Jogo
  • Checar fim de jogo
    • Checar tabuleiro cheio (ok)
    • Checar vencedor (to do)
  • Checar vencedor (nem sempre há um) (to do)
  • Sugestão de lance (to do)
  • Checar perigo (iminência de término de jogo) (to do)

Como vemos, há muito a fazer (To Do). E como o problema está muito interessante, resolvemos continuá-lo no próximo DOJO.

As atualizações do código foram “comitadas” ao github.

Retrospectiva

Na retrospectiva, pontuamos o seguinte:

Foi bom

• tempo bem aproveitado em codificação
• amadurecimento dos participantes em testes e no entendimento dos requisitos
• aprofundar alguns aspectos do problema
• novos participantes da platéia
• melhor entrosamento dos pares

Pode melhorar

• nem todos participaram devido ao tempo
• piloto e co-piloto poderiam falar para todos
• participação da platéia antes do verde
• lanche (já prometido para a próxima reunião pelo Mábio)

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

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)

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: