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!

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.

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. : (

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!

]]> http://dojomarilia.com.br/?feed=rss2&p=42 0 http://dojomarilia.com.br/?p=25 http://dojomarilia.com.br/?p=25#comments Tue, 15 Dec 2009 11:20:00 +0000 leandro http://dojomarilia.com.br/?p=25

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.

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!

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!