Dojo Marília – SP

• Data: 28/08/2010
• Horário: 10:00 hrs
• Participantes: Leandro, Joacir, Renato,  Fabio e Denis
• Problema: Jogo da Vida
• Linguagem: Python
• Formato: Randori

No último encontro Dojo Marília, o problema proposto foi o Jogo da Vida. Um exemplo clássico de problema de automação celular.

Regras do jogo:

As regras são simples e elegantes:

1. Qualquer célula viva com menos de dois vizinhos vivos morre de solidão.
2. Qualquer célula viva com mais de três vizinhos vivos morre de superpopulação.
3. Qualquer célula com exatamente três vizinhos vivos se torna uma célula viva.
4. Qualquer célula com dois vizinhos vivos continua no mesmo estado para a próxima geração.

Retrospectiva

Ruim:

• Mal planejamento;
• Falação;
• Falta de Foco;
• Atraso dos participantes;
• Participantes faltaram;
• Celular, mensagens e ligações.
• Testes furados

Bom

• Problema Proposto;
• Sorteio não viciado
• Python#;
• Baby Steps;
• Dinamismo;
• Documentação;
• Despedida do CIEM

Considerações

Não conseguimos terminar o problema por falha em alguns testes, mas o decorrer do dojo  foi bem dinâmico. O Python era uma linguagem nova para alguns participantes.

retrospectiva

• Data: 18/04/2010
• Horário: 10:30 hrs
• Participantes: Leandro, Joacir, Renato,  João e Fagner
• Problema: Campo Minado
• Linguagem: Python
• Formato: Randori

No último encontro Dojo Marília, o problema proposto foi um popular jogo de computador. Um verdadeiro clássico nativo de  um S.O. formado por janelinhas… Quem nunca jogou “Campo Minado”?

Regras do jogo:

Tomamos a liberdade de mudar um pouco a regra do jogo:

• A área do jogo consiste em um quadrado de 4 x 4, onde 8 posições contém uma mina (nível Avançado);
• Se o jogador selecionar um campo que possui mina “game over”;
• O jogado é vencedor quando todos os quadrados que não têm minas forem revelados.

Retrospectiva

Ruim:

• Pontualidade dos participantes;
• Falta de Harmônia;
• Correu com o TDD;
• Requisito Falho;
• Planejamento Falho;
• Participante sempre com a mesma camisa do “curintia”.

Bom

• Listas em Python;
• Python;
• Tamanho do problema;
• Letra légivel no planejamento;
• Legenda para identificar status do jogo.

Considerações:

A linguagem Python para maioria dos participantes era novidade, destaco aqui um ponto positivo que foi a passagem de conhecimento de alguns participantes para o restante do grupo.

Até o próximo Dojo Marília,

Abraços!

• Data: 13/02/2010
• Horário: 11:00 hrs
• Participantes: Leandro, Joacir, Renato,  João , Fabio e Maycon
• Problema: Código Morse
• Linguagem: PHP
• Formato: Randori

Post saindo com um pouco de atraso…No último Dojo contamos com a participação do Maycon e o problema proposto foi a conversão de Código Morse. O problema consistia em receber uma sequência caracteres em Código Morse e efetuar a conversão para nossa linguagem.

Regras do Código Morse

Retrospectiva

Bom :

• Programar com teste;
• Refatoração;
• Novo Participante;

Ruim:

• Falta de Prática;
• Dojo + Faxina = Fail;
• Problema Facil;
• Atraso;
• Preguiça;
• A lendária “FALÁCIA”.

Considerações

Voltamos a utilizar o planejamento antes de iniciar o Dojo, o que ocasionou em bons resultados, visto que no ultimo Dojo nao utilizamos o planejamento.

• Data: 30/01/2010
• Horário: 10:00 hrs
• Participantes: Joacir, Renato,  João, Fabio, Rodrigo e Cássio.
• Problema: Analisar a mão (as cartas) do poker.
• Linguagem: Python

Nesse sábado contamos com dois iniciantes no dojo, os senhores Rodrigo (programador em C e Java) e Cássio (Publicitário, nunca programou uma linha na vida), esse encontro serviu principalmente pra exemplificar como um Dojo, além de ampliar e qualificar as skills em Python dos programadores, também é interessante a quem quer aprimoramento em lógica.

O desafio escolhido foi relacionado a poker, o usuário entraria com as 5 cartas que possui e o sistema retornaria qual é o valor da sua mão, seguindo a sequência:

RoyalFlush: sequência com o mesmo naipe de 10, J, Q, K e A;

StraightFlush: cinco cartas em sequência com o mesmo naipe;

Quadra: Quatro cartas do mesmo valor;

FullHouse: Uma trinca (três cartas do mesmo valor) e um par (duas cartas do mesmo valor);

Flush: Cinco cartas do mesmo naipe;

Straight: Sequência de 5 cartas com qualquer valor ou naipe;

Trinca: Três cartas do mesmo valor

Dois pares: dois pares de cartas do mesmo valor

Um par: duas cartas do mesmo valor

Carta mais alta: Caso o usuário não tenha nenhuma das combinações acima a carta mais alta segue a sequência: A, K, Q, J, 10, 9, 8, 7, 6, 5, 4, 3, 2.

O sistema executaria a ação a partir do RoyalFlush, e ao encontrar o valor desejado retornaria ao usuário sem precisar passar pelos outros métodos.

Retrospectiva

Ruim:
Planejamento mal executado;
Novas regras são ruins;
Problemas na organização.

Bom:
TDD
Skill em Python

Graças ao João, não temos as fotos desse Dojo. : (

• Data: 16/01/2010
• Horário: 10:00 hrs
• Participantes: Leandro, Joacir, Renato,  João e Fabio
• Participação especial: Elaine
• Problema: Vortex
• Linguagem: PHP
• Formato: Randori

No último sábado iniciamos nossos encontros de coding dojo de Marília nesse ano de 2010. Aproveitando a ansiedade de todos por novos desafios,  selecionamos um game como tema do encontro. Como dessa vez iriamos utilizar o PHP que no momento é uma linguagem que todos já tem um nível de entendimento mais avançado e nivelado, optamos por aumentar a dificuldade do desafio, consistia em um game chamado Vortex (joguei muito esse game na minha adolescencia), o grupo conhecia pouco as regras, mas depois de uma rápida explicação todos ficaram alinhados.

Regras do Game Vortex:

• N jogadores possuem 4 peças em um tabuleiro;
• Todos começam com as peças na posição 0 (zero);
• O game sorteia um número de 0 (zero) até o total de posições do tabuleiro;
• O game movimenta uma peça do jogador o número sorteado de posições;
• Com exceção da última posição, se na posição onde a peça foi movimentada contiver peça(s) de outro(s) jogador(es), a(s) peça(s) do(s) outro(s) jogador(es) volta(m) para a posição 0 novamente;
• Para conseguir colocar a peça na última posição do tabuleiro, o número sorteado não pode ser um número superior a quantidade de casas restantes para tal;
• Ganha, o jogador que conseguir colocar todas as peças na última posição primeiro.

Retrospectiva

Ruim:

• Problema não foi resolvido;
• Planejamento estourou o tempo determinado;
• No final houve correria para resolver o problema;
• Sorteio das duplas não diversificou os pares;
• Falação (mais uma vez heim pessoal);
• Falta de atenção no TDD ocasionou má implementação;
• Nem todos do grupo entenderam o problema por completo.

Bom:

• Problema desafiador e estigante;
• TDD melhorando (mas ainda falta muito);
• Skills em PHP;
• Planejamento bem realizado apesar de termos estrapolado no tempo.

Considerações:

Percebi nesse dojo, que quando o problema é estimulante, o dojo pode se tornar uma experiência ainda mais produtiva e divertida, mesmo não tendo resolvido o problema, houve uma construtiva discussão no planejamento entre todos participantes, acho que por isso foi tão difícil concluir o planejamento dentro do tempo de 30 minutos previstos. Pelo nível das propostas de problemas fornecidas pelos participantes, acredito que nos próximos encontros continuaremos evoluindo.

abraços!

• Data: 12/12/2009
• Horário: 10:00 hrs
• Participantes: Leandro Cervelin, Joacir, Renato,  João e Fábio
• Problema: Fizz Buzz
• Linguagem: Ruby
• Formato: Randori

Hoje chegamos a realização do 3º Coding Dojo Marília – SP! Neste Coding Dojo resolvemos arriscar, fazer uma experiência, resolvendo o problema utilizando a linguagem Ruby. Arriscar? Sim! nenhum participante tinha conhecimento sobre Ruby e por esse motivo escolhemos um problema simples para podermos gerar skills sobre a linguagem e desta forma resolver problemas com maior grau de dificuldade futuramente. O prolema escolhido foi o Fizz Buzz, uma brincadeira tradicional onde crianças e/ou adultos falam um número em ordem (1,2,3…). Se o número contiver 3 ou for múltiplo de 3 então a criança deve dizer Fizz ao invéz do número, se o número contiver 5 ou for múltiplo de 5 então a criança deve dizer Buzz, por fim se as duas condições forem verdadeiras então o a criança precisa dizer Fizz Buzz.

Retrospectiva

Pontos Negativos:

• Linguagem desconhecida por todos os participantes
• O problema foi resolvido até fácil demais

Pontos Positivos:

• Conhecimento em Ruby
• TDD
• Maior quantidade de linhas de testes do que linhas de código
• Planejamento
• Resolução do Problema
• Pair Programming

Considerações:

Vou citar nas considerações um pouco do que foi dito na Retrospectiva realizada logo após o término do Coding Dojo. Alguns participantes gostaram de utilizar uma nova linguagem (literalmente), utilizando um problema menos complexo para aprimorar o conhecimento, outros nem tanto pelo fato de não ter utilizado mais que o básico de uma linguagem de programação para a resolução do problema, achando assim não ter aperfeiçoado seus conhecimentos na programação. Ficou definido que será utilizado uma quantidade “X” de linguagem para podermos sempre aprimorarmos o conhecimento nessas linguagens e na codificação das mesmas.

Até o próximo!

Abraço.

• Data: 28/11/2009
• Horário: 10:00 hrs
• Participantes: Leandro, Joacir, João, Fábio e Renato
• Problema: Média ponderada de notas
• Linguagem: Python
• Formato: Randori

Ráaaaaaaa! Segundo Dojo!

Apesar de 2 convidados não comparecerem, o dojo foi bem legal, o problema dessa vez foi:

“Escreva um algoritmo/programa que leia o código de um aluno e suas três notas. Calcule a média ponderada do aluno, considerando que o peso para a maior nota seja 4 e para as duas restantes, 3. Mostre o código do aluno, suas três notas, a média calculada e uma mensagem “APROVADO” se a média for maior ou igual a 5 e “REPROVADO” se a média for menor que 5. Repita a operação até que o código lido seja negativo.”

Coisas ruins: =(

• TDD – Ainda somos newbies
• Poucos comentários no código
• Problemas em definir nomes de métodos e variáveis
• Ninguém consegue ficar quieto

Coisas boas: =)

• As discussões  foram boas
• PYTHON!
• TDD – Aprendemos mais
• Aprendemos calcular média ponderada
• Resolvemos o problema
• Planejamento foi melhor que o anterior
• Cronômetro
• Ambiente preparado com antecedência

O próximo vai ser em Ruby!

• Data: 14/11/2009
• Horário: 10:00 hrs
• Participantes: Leandro Cervelin, Joacir, Renato, Fagner, João e Fábio
• Problema: Somar números romanos
• Linguagem: PHP
• Formato: Randori

Hoje realizamos o 1º Dojo Marília, o Renato levou 2 problemas (somar números romanos e anagrama) e o Joacir mais 1 ( jokey-poo), totalizando 3 problemas. Foi feita uma votação entre todos os participantes para a escolha de 1 problema  e o eleito foi: somar número romanos. A proposta do problema era que o usuário entrasse com 2 valores (números romanos), por exemplo V + V (5 + 5), e como resultado teria a soma dos dois valores que no caso seria X (10).  O formato utilizado para este Dojo foi o Randori e teve duração de 2 hrs.

Retrospectiva

A melhorar:

• Planejamento ruím
• Faltou foco no problema
• Demora na preparação do ambiente

Lições aprendidas:

• TDD
• Conhecimento em PHP
• PHP Unit

Considerações:

Por ser o 1º Dojo realizado tivemos algumas dificuldades como por exemplo evitar palpites da platéia quando os testes estavam em vermelho, talvez pela dificuldade do problema que foi gerada pela falta de planejamento e de foco no problema.  Tirando isso, o Dojo realmente foi muito divertido! Dos 6 participantes, todos gostaram bastante e saíram crédulos de que este formato de aprendizagem (brincar aprendendo) realmente funciona.

O Dojo será realizado quinzenalmente. Até o próximo!