Coding Dojo 008 – Criptografia

Finalizamos com sucesso a criação de uma classe de criptografia e descriptografia, usamos um dicionário onde cada letra era representada pela próxima letra (A => B).

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.

Coding Dojo 007 – Campo Minado

Retomamos as atividades do Dojo Piauí, no último sábado (21/11/09) realizado no laboratório de informática e estatística da UFPI (DIE), onde estavam presentes 9 desenvolvedores, sendo a maioria novos no encontro.

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.

Dojo 006 – Microsystem!

Nós conseguimos fazer um microsystem! Ele tem a função de tocar uma música, passar para frente, para trás, parar e carregar uma lista de músicas!

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 :P).

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

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.

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:

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:

Dojo 002 – Conversor de Moedas

Data: 18/08/2009.

Presentes: Esmerino, Dmitry, Elias, Caio, Marcelo, Cairo, Weldys, Cyrus, Ricardo, Cleiton, Stevie, Ewerton, Lucas.

Linguagem: Ruby.

Framework de testes: Rspec.

Problema: Conversão de moedas.

Queríamos converter um valor em uma moeda para outro

Solução: Está no Github.

Criamos duas classes, uma para leitura de um arquivo XML com as cotações e outra para fazer a conversão.

Pensávamos que seria um problema de rápida solução, mas mostrou que não foi, é tanto que não finalizamos o problema.

Retrospectiva:

Este foi um primeiro Dojo em que não conseguimos finalizar e nem avançar muito no problema, tivemos inúmeros pontos não satisfátorios e alguns poucos bons pontos

Negativos:

• A sequência dos pares.
• 2 computadores para 10 pessoas foi muito.
• Github mal utilizado.
• Cronometragem.
• Não entendimento do problema
• Nem todos chegaram no horário

Positivos:

• Muita gente
• Todos que estiveram no primeiro Dojo vieram para o segundo

Resumo:

Antes de todos estarem presentes, conversamos um pouco sobre o problema, e chegamos a um acordo, mas nem todos estavam presentes e isso fez toda a diferença no andamento do Dojo.

Preparamos dois computadores, pois achamos que seriam várias pessoas (20 pessoas!? 30 pessoas!?). Como ainda não temos projetor, preparamos os computadores com Dual Monitor Espelhados, assim não precisaríamos ficar na cola de ninguém.

Quando começou ficou uma bagunça só, todos conversando muito, um computador em foco para resolver o problema da conversão e outro computador com foco na leitura de um XML com a cotação do dia.

Mais ou menos duas horas depois nós encerramos o Dojo e fizemos uma retrospectiva. Encerramos sem resolver o problema.

Próximo Dojo:

Vamos utilizar apenas um computador.

Aqui do Jus Navigandi são 4 salas, a de desenvolvimento é anexada a sala da recepção/administração, nesta sala ficará um computador para programação.

Na outra sala, a de desenvolvimento, ficará a platéia vendo o que está sendo feito no monitor espelhado e através de VNC ou software parecido, e teremos um mac fazendo a cronometragem (Usando o mesmo Widget do Oxente Rails).

As perguntas e a comunicação será mantida através de um “mediador” que poderá ser qualquer um, só colocar a cara na porta e perguntar :P.

Como queremos entender bem o problema, espero que todos cheguem um pouco mais cedo, para comerçamos mais cedo a conversa sobre o problema.

Não sabemos se assim será melhor ou pior, mas como todos estão aprendendo, nós iremos fazer assim.

UPDATE: Fotos

Dojo 001 – Palíndromo

Data: 12/08/2009.

Presentes: Cairo Noleto, Cleiton Francisco, Dmitry, José Esmerino, Ewerton e Ricardo Farias.

Linguagem: Ruby.

Framework de testes: Rspec.

Problema: Palídromo.

Queríamos saber se uma string é ou não palíndromo.

Solução: Está no github.

Adicionamos no objeto String um método chamado palindrome? Onde verificamos se uma string é ou não palíndrome. Como plus, adicionamos um outro método para verificar se é palidromo em case sensitive.

Nós escolhemos um simples problema para apresentar e motivar as pessoas para os próximos Dojos.

Retrospectiva:

Nota: Lado esquerdo o que foi bom, lado direito, o que foi ruim.

Mais dicas:

• A cada troca de par fazer um commit no git para manter o histórico. Mesmo que os códigos não estejam bons.
• Usar dual monitor em espelho. (Enquanto não temos um projetor).

Antes de começarmos explicamos o que é Dojo, como funciona, suas regras. Depois explicamos o problema, todos entenderam e começamos a colocar mãos na massa.

Apesar de termos um participante que nao conhecia a linguagem ruby e outros que não conheciam Rspec todos entraram no randori e foi uma experiência muito boa.

Segue algumas fotos:

Para o próximo Dojo, estaremos divulgando mais informações na lista do Google Groups rails-pi.