Este sábado teve o primeiro dojo de 2012, fazia quase um ano que não tinha um encontro. O pessoal estava MUITO animado, todos de bom humor e participativos. Isso ajudou bastante na integração do grupo.

O problema proposto foi levemente modificado para aumentar a dificuldade. A resolução do problema ocorreu de forma correta, começamos devagar e com uma solução não escalável, depois finalizamos com uma solução mais elegante. Por uma questão de tempo não conseguimos refatorar a criação do dicionário. A nossa ideia era tirar aquela configuração das letras que estava hard-coded e fazer uma solução com menos linhas. Porém o objetivo foi cumprido, finalizamos o kata.

Mudanças

Ficou combinado de que o dojo será mensal ao invés de quinzenal, vamos ver se conseguimos manter um dojo por mês, se der certo e o pessoal animar, talvez voltemos a fazer quinzenal. Além disso, teve bastante elogios quanto ao horário, parece que 14hrs foi mais aceito do que 8hrs.

Tivemos vários pontos negativos que são fáceis de resolver, então é provável que nenhum deles volte a ocorrer no próximo encontro.

No fim do dojo foi sugerido a utilização de uma outra linguagem. Um dos novos participantes (infelizmente esqueci de pegar o nome…) comentou que trabalha com C e Python. Talvez no próximo encontro façamos em uma destas linguagens ou alguma outra.

Estas e outras questões serão discutidas no Google Groups.

Enfim, foi muito bom rever o pessoal, acredito que todos tenham gostado. Nos vemos no próximo mês!

Olá pessoal.

O Igor está dando aulas de Programação Orientada a Objetos na SOCIESC e convidou o pessoal do JoinvilleDojo para fazer um Dojo com a turma dele.

Apesar de que tivemos poucos participantes, os poucos que foram se mostraram empenhados e determinados a resolver o problema proposto no início da sessão. Aliás, a dinâmica funcionou melhor do que eu imaginava.

O problema escolhido foi o do Caixa Eletrônico. No início eu quis mostrar como funciona o Baby Steps e fiz algo que confundiu a todos, digo isso pois ficamos umas duas rodadas sem sair do lugar. Mais para frente o Igor assumiu como co-piloto e direcionou-os para o caminho certo. Feito isso o desenvolvimento fluiu de maneira agradável e sustentável. Mais e mais testes iam aparecendo, o código começou a tomar forma e às 11:30 nós haviámos finalizado.

Houve também uma última rodada de refatoração onde o Adriano fez um negócio maluco que eu duvidava que ia funcionar. Mas no fim da refatoração os testes ficaram todos verdes e demos o problema como concluído.

Deixo aqui meu obrigado ao Igor pela oportunidade e meus parabéns aos alunos de BSI pelo ânimo e vontade de participar, afinal, acordar às 8 da manhã em um sábado de sol nublado para ir programar em grupo não é para qualquer um.

Resumindo, foi show! :-)

Retrospectiva

• Data: 03/02/2011
• Horário: 20:00 às 22:00
• Particpantes: Igor, Guilherme, Marcos, Murilo, Cláudia
• Problema: Problema do Miojo
• Ambiente: C# 4.0, MSUnit, e Windows 7
• Código: Dojo #11 - 101.74 KB
• Formato: Randori

Este foi o primeiro de muitos Dojos de 2011. Os problemas sugeridos foram Problema do Miojo e Lâmpadas no Corredor, ambos retirados do site DojoPuzzles. Depois de uma votação rápida decidimos resolver o problema do miojo. Não vou explicar o problema pois o próprio site já explica de forma bastante clara e divertida.

O dojo durou duas horas sendo que cada participante programou apenas uma vez, durante 7 minutos cada. Fazendo uma matemática básica, temos:
6 (pessoas) x 7 minutos (revezamento) =  42 minutos.

Se ficamos 42 minutos programando, o que fizemos o resto das 1 hora e 16 minutos?

Resposta: escrevendo, desenhando, modelando, calculando, comendo trakinas, bebendo coca-cola e tentando colocar o ar-condicionado em uma temperatura agradável.

Foi um problema de quebrar a cabeça, tivemos que deixar o computador de lado e partir para a folha A4. O resultado foi bem legal, tivemos 3 soluções diferentes e que prometiam resolver o problema. Terminamos o dojo às 22:00 com 6 testes verdes e 1 vermelho.

O Murilo e a Cláudia levaram o código para casa e terminaram durante a noite. Detalhe, recebi o código às 1:30 AM (vício? insônia?). O código do download acima está com todos os testes passando além de estar comentado para melhor entendimento.

Gostaria de agradecer ao Igor por ter cedido o espaço da sua empresa para a realização do encontro. Obrigado!

Retrospectiva

Positivos

• Bom Kata (x3)
• Boa interação e colaboração dos participantes (x3)
• Bom Local (x2)
• Coca-Cola e Comida (x2)
• Boa solução para o Kata
• Ferramentas novas de testes
• Gerou bastante discussão
• Código ficou limpo
• Paciência para criação de um modelo antes do código

Negativos

• Não terminamos o problema (x2)
• Calor (x2)
• Pessoas faltando
• SharpTestEx não funcionou
• Faltou tempo
• Problema não estimulou o desenvolvimento de técnicas, ficou apenas na parte lógica
• Faltou quadro branco

Desta vez começou bem atrasado, mas quem chegou cedo aproveitou para bater um papo bacana sobre carreira e o mercado de TI. Além disso, percebemos que precisamos definir melhor alguns itens do Joinville Dojo, tanto para fortalecer o grupo quanto para atrair mais participantes.

Começamos às 19:40, novamente levamos 3 sugestões de Kata sendo elas Minesweeper, Bowling Kata e o Australian Voting.

Ficamos entre a primeira e a última, mas ficou decidido fazer primeiro o campo minado e se sobrasse algum tempo, fariamos algum outro. Este problema consiste em, dado um campo minado de X por Y e algumas bombas espalhadas nele, nosso software deveria ser capaz de identificar os valores corretos de cada um dos outros campos (conforme regras do jogo Campo Minado).

Desta vez tivemos auxílio do quadro branco e ajudou bastante para termos nossas primeiras idéias do que precisaríamos fazer para resolver o problema. Foi decidido, por exemplo, que as bombas teriam valor -1 ao invés de utilizar o caracter ‘*’ conforme sugerido pelo problema.

Começamos bem devagar, alguns testes pareciam muito inúteis e repetidos, mas conforme fomos evoluindo estes testes simples ajudaram a nos guiar quando tínhamos alguma implementação mais complicada para fazer. Apesar de considerarmos concluído, acabou faltando uma refatoração no ‘Get’ da matriz, na forma que o cálculo era feito e também no desenho da classe. Gostaríamos de ter feito o acesso à matriz assim:

campo[1][3]

ao invés de:

campo.Matriz[1][3]

Faltou tempo…

Dojo concluido. Chegou o momento de parar de falar ‘teste’, ‘matriz’, ‘índice’ e outras coisas de ‘Dev’, fomos ao Opa Bier socializar um pouco. Porém, ao ver a pizza quadrada, foi impossível não fazer o comentário de que ela parecia uma matriz 3 por 3, HAHA.

Retrospectiva

Positivos

• Bom kata (x3)
• Antigos participantes voltaram (x2)
• Vários participantes (x2)
• Interatividade (x2)
• Vai ter pós-dojo (com cerveja)
• Participação intensa entre piloto e co-piloto
• Diversas sugestões
• Utilizaçao do quadro branco
• Revezamento
• Todos os testes passaram
• Boa experiência
• Ótimo local

Negativos

• Nem todos participaram (x5)
• Dojo começou atrasado (x3)
• Fome (x2)
• Ausência de confirmados (x2)
• Rever com o grupo a estratégia de elaboração
• Horário muito próxima das 18h
• Mal contato do cabo do Datashow
• Gostaria que houvesse as palestras
• Assert estranhos
• Praticamos de forma precário o TDD, Refactor, Baby Steps, etc
• Evoluímos muito devagar
• Muita conversa paralela

Próximo dojo será em 2011! Boas festas e aproveitem bastante, 2011 promete!

Levamos 3 sugestões de Kata, sendo eles Pile of Boxes, Bowling Kata e o Número de Ernos.

Foi unânime a escolha do Pile of Boxes que consite em empilhar um número X de caixas e determinar a altura da pilha. Acontece que as caixas possuem a parte de cima aberta, se você tentar empilhar uma caixa menor em cima de uma caixa maior, a caixa menor é inserida dentro da caixa menor ao invés de empilhar. No problema proposto pelo site, as caixas não tinham fundo, no nosso caso, como queríamos fazer algo mais real, decidimos usar caixas com fundo :)

Apresentei a todos o SpecFlow, uma ferramenta em .Net para escrita de testes seguindo o Behavior Driven Development. Os testes ficaram bem legíveis, nos preocupamos ao máximo para escrevê-los na linguagem de negócio, sem utilizar termos técnicos como ‘exceção’ ou ‘deve retornar false’. Pelo visto foi aprovado por todos e devemos usar mais vezes nas próximas sessões.

A resolução do problema no início se mostrou simples, mas no final chegamos a conclusão que era mais complicado do que esperávamos. No meio da codificação, para não ter que criar muitos loops e diversas variáveis ‘Int’, resolvemos usar um pouco os recursos de OO e criamos uma classe ‘Caixa’, afinal, se o problema falava em empilhar caixas, fazia MUITO sentido ter uma classe que representa tal objeto. Essa super refatoração levou um bom tempo de trabalho e por isso o resultado final ficou com alguns testes falhando, infelizmente, não conseguimos concluir completamente o Kata. Ponto Importante para o próximo dojo: foi levantado a sugestão de fazermos uma modelágem ágil no whiteboard antes de começar a codificar.

Se alguém quiser terminar o Kata e publicar aqui no blog me avisa que eu atualizo este post. Discutimos também o que faremos no último dojo do ano, mais informações em breve no nosso Google Groups, vai ser legal, fique atento :)

Apenas 4 pessoas confirmaram mas tivemos 6 pessoas presentes, muito bom.

Se eu esqueci de algum fato importante, por favor coloquem nos comentários, vamos movimentar isso.

UPDATE: O Anderson levou o Kata para casa e conseguiu terminar, atualizei o download com a versão dele, quem tiver curiosidade para ver como ficou, olha lá. Parábens! :D

Retrospectiva

Positivos

• Kata Interessante (x4)
• Dinâmico e Interativo (x4)
• Houve revesamento (x3)
• Horário bom (x2)
• Todos participaram (x2)
• Novos participantes (x2)
• Teve bebida
• Gostei do local
• Usamos OO
• Ninguém reclamou do teclado
• SpecFlow funcionou 100%
• Veio mais pessoas do que o esperado
• Mudança de estratégia de programação
• Não faltou comida

Negativos

• Não finalizamos (x4)
• Poucas pessoas (x3)
• Começamos atrasado (x2)
• Não tivemos auxílio do quadro branco (x2)
• Chocolate começou a enjoar
• Co-piloto tomou posse do controle
• Teste inúteis
• Falta de conhecimento de Regex
• Projetor falhando
• Local difícil de encontrar
• Faltou definir melhor antes de programar
• Demora na atualização do Blog

Sugestão

• Escrever o texto do blog após o Dojo
• Tirar mais fotos e printscreen

Olá pessoal, algumas semanas atrás fomos convidados pela SOCIESC para fazermos uma sessão Coding Dojo com o pessoal do Ensino Técnico do curso de Informática.

Essa sessão ocorreu ontem, quarta-feira, na parte da noite lá na SOCIESC do Boa Vista. São alunos que estão no último semestre do curso, preparando-se para a apresentação do TEX (Trabalho Experimental), um mini-TCC.

A sessão começou um pouco tarde devido a um problema no projetor, tudo foi resolvido quando um aluno chegou, tirou o cabo de força e re-colocou. Porque a gente não pensou nisso antes? Enfim, iniciou então com uma apresentação minha sobre Chaos Report e Extreme Programming. Em seguida o Igor falou do Coding Dojo e o Carlos Júlio terminou apresentando os Katas que tínhamos disponíveis.

Eu havia preparado um ambiente Java e outro de C# na minha máquina. Deixamos livre a escolha de qualquer uma das duas ferramentas, e a eleita pelos alunos foi Java. Falando em java, foi a primeira vez que usamos Java no Joinville Dojo.

Pulando um pouco alguns pontos, de maneira geral, o dojo foi muito bom. Algumas regras foram quebradas, inclusive por mim. Chegamos a conclusão que não tinha como o Dojo andar sem quebrar as regras do silêncio, em alguns momentos era necessário nossa intervenção. Eram cerca de 30 pessoas, então seguir a regra do silêncio por parte dos participantes também não era fácil.

Conversando com o Carlos Júlio ao final do Dojo, concluímos que foi muito assunto para 3 horas. TDD, Refactor, Java, Pair Programming, JUnit etc. Além disso, foi proposto um Kata de dificuldade média, o que dificultou o aprendizado. Quando fizermos novamente um Coding Dojo para um público que nunca participou de um, decidimos trazer katas pequenos, simples e já bastante utilizados, como o FizzBuzz, Números Romanos, Tratamento de URL, etc.

A retrospectiva ficou assim:
Obs.: Alguns items foram omitidos pois fugiram do contexto.
Obs2.: Alguns items foram agrupados.

Positivos:

- Troca de conhecimento (x6)
- Problema foi bom (x4)
- Relembrei de matérias passadas (x4)
- Mais conhecimento adquirido (x3)
- Trouxeram novidades (x3)
- Programação interativa é legal (x3)
- Organização (x2)
- Estimula o aprendizado (x2)
- Boa apresentação (x2)
- Gostei do Dojo
- Foi interessante pois saiu da nossa rotina
- Domínio do assunto
- Auxílio durante a sessão
- Incentivo aos profissionais
- Práticas Eficientes
- Todos aprenderam algo novo

Negativos:

- Problema muito complicado (x5)
- Falta de participação da turma (x4)
- Não foi dado nenhuma dica de como resolver
- NULL  ( esse foi criativo :D )
- Não lembrava de como programar em Java
- Deveria mostrar o programa certo no final da sessão
- Queria que fosse C#
- Saimos sem concluir

Este dojo começou com um pouco de atraso e a falta de alguns participantes confirmados. Apesar disso, o desenvolvimento do kata foi produtivo. Tivemos uma boa interação da equipe e ótimas idéias que ajudaram na solução do problema.

O kata escolhido parecia ser muito simples. Dado um tamanho de coluna e um texto, retornar o número de linhas e as próprias linhas. Também conhecido pelo nome de “Quebrar-Linhas” em muitos editores de texto. As palavras não podiam ser cortadas no meio e deveriam ser enviada para a próxima linha conforme necessidade.

Conforme foi surgindo a solução do problema, o kata começou a se tornar complexo. Tivemos algumas dificuldades, porém com a boa sinergia da equipe, conseguimos finalizar o Kata.

A definição dos responsáveis por organizar o próximo encontro, data e local será feita através do grupo nesta thread. Fiquem atentos e participem.

Retrospectiva

Negativos:

Positivos:

• Boa quantidade de pessoas
• Respeitando as regras
• Hardware funcionando(4x)
• Participantes novos(4x)
• Kata bom(2x)
• Bastante participação(3x)
• Muitos Testes(2x)
• Boa dinâmica(2x)
• Concluímos Kata(2x)

Este encontro não foi possível realizar o dojo devido a falta de acesso a sala. A pessoa responsável por trazer a chave não pode comparecer e ficamos sem local para realizar. Temos que evoluir a idéia de compartilhamento de funções no grupo.

Mesmo sem local, juntamos umas mesas na cantina e fizemos a apresentação do dojo. Por decisão dos participantes e devido ao local, decidimos fazer o dojo em outra data. Apesar de não conseguir realizar o dojo, conseguimos fazer uma dinâmica muito legal.

Discutimos diversos assuntos, entre eles, melhorias no grupo, grupo de estudo, compartilhamento de funções do grupo, local do grupo. Segue abaixo um resumo dos assuntos discutidos:

• Troca de telefone entre os participantes do grupo.
• Mais de uma pessoa responsável pela chave da sala.
• Fazer o grupo de estudo separado do coding dojo.
• Termos mais um local para realização. O Igor consegue a sala no SENAI Norte.
• Realização de um evento em Joinville.
• Falta de participantes confirmados.

Ficou previsto o próximo dojo para o dia 16/10/2010. O responsável por trazer os chocolates e a organização continuam os mesmos.

Este encontro foi bem produtivo, todos participaram e praticamos bem baby steps e TDD, estamos evoluindo muito bem.

A princípio, o problema resultaria em 2 métodos. Um deles fizemos até o fim e de várias formas. Começamos com um tratamento simples, passamos para uma formula matemática, evoluímos para uma contagem de caracteres e por fim finalizamos com uma pilha resolvendo tudo e de forma bem simples.

Como sempre dizemos: o Joinville Dojo é da comunidade para a comunidade e nada mais bacana para todos interagirem do que os participantes organizarem o evento.

Já tinhamos uma pessoa responsável por trazer os bombons, agora temos mais duas para a organização.

E os voluntários para o próximo Dojo são:

• Organização: Marcos e Julio
• Bombons: Igor

O objetivo da organização é montar o past, future e present (katas) e encontrar alguêm que tenha equipamento (notebook) para trazer. Com isto a interação será maior e todos estarão mais envolvidos com o projeto.

A bons meses atrás Guilherme e eu pensamos em montar um grupo de estudos. Alguns pessoas do Dojo vieram com a mesma sugestão, então resolvemos abrir para a comunidade também.

A idéia seria criar um grupo com as seguintes características:

Arquitetura:

• Domain Driven Design (Eric Evans)
• Enterprise Patterns (Martin Fowler)
• Design Patterns (Gang of Four – GoF)
• Princíos de S.O.L.I.D (Uncle Bob)
• Outros na mesma linha…

Linguagens e tecnologia:

• Clean Code (Uncle Bob)
• C#, Java, Ruby, Python, Haskell, Matlab, C, C++ …
• Silverlight, Flex, ORM, MVC, Test, Frameworks em geral …
• Behaviour Driven Development, Test Driven Development…
• Outros na mesma linha…

Aplicação de Eventos:

• Palestras
• Cursos
• Outros na mesma linha…

Apresentamos para os participantes no último Dojo e todos acharam a idéia bacana. Iremos evoluí-la nos próximos encontros.

Retrospectiva

Negativos:

- teclado internacional não é bom (x5) (teclado extendido na veia)

- mouse ruim (x5)

- falta dos participantes confirmados (x2)

- não terminamos o Kata (x2)

- pouco tempo (vamos começar as 9:30h o próximo)

- falta de disciplina no Dojo, mas estamos melhorando (este negativo foi anulado com o positivo… hehehe)

Positivos:

- todos participaram (x5)

- número bons de pessoas (x5)

- problema legal para resolver (x2)

- novos participantes (x2)

- sugestões frequêntes e pertinentes (x2)

- boas opções de katas (x2)

- foi seguido bem os princípios de TDD e Baby Steps

- boa integração entre os participantes

- melhorou a comunicação do co-piloto

- respeito aos pilotos

- organização

- bombons (este não poderia faltar)

Parabéns a todos os participantes. Hoje estarei iniciando a thread para o grupo de discussão, pois a do Dojo #7 o Guilherme já abriu. Estarei revendo as imagens do grupo também, logo estarão atualizadas.

Grande abraço a todos

Neste post vou explicar como funciona um Coding Dojo. O objetivo é que este post sirva de guia para quem está começando no Joinville Dojo (ou até mesmo em outro lugar), por conta disto espero atualizá-lo sempre que necessário.

1. Dojo

2. Coding Dojo

O Coding Dojo não é muito diferente disto, ele é uma reunião para estudar e praticar a arte do desenvolvimento de software. Os participantes estão lá para se divertir e praticam de forma expontânea afim de melhorar suas habilidades. O Dojo é um ambiente não competivivo, mas sim colaborativo. Todos os participantes possuem um objetivo em comum: resolver o problema que foi proposto no início da sessão. Para que isso seja possível, uma série de técnicas e práticas do Extreme Programming são utilizadas, como por exemplo Test Driven Development, Pair Programming,  Refactoring, Design Incremental, entre outros.

A motivação para se fazer um dojo é que a maioria dos desenvolvedores não possuem tempo para treinar. Fazendo uma analogia com um time de basquete, pode-se afirmar que o time de basquete treina todo dia, durantes semanas ou meses, para tentar ser o melhor no campeonato. Já um time de desenvolvedores participa de um campeonato diariamente, cada entrega é um jogo e você precisa dar o seu melhor para entregar algo com qualidade e no prazo estipulado. Quando é que este time treina para o próximo campeonato (projeto)?

Ao participar de um dojo você estará adquirindo e compartilhando conhecimento, exercitando tanto habilidades humanas quanto técnicas, seu networking estará em constante crescimento e você estará preparado para resolver atividades do dia a dia.

3. Requisitos para o participante

Tem interesse em participar? Antes de ir à um dojo, certifique-se de que você tem:

• Desejo de aprender e compartilhar conhecimento;
• Respeito ao próximo;
• Humildade;
• Mente sempre aberta;
• Disciplina;
• Comprometimento;

Difícil? Não né. Você não precisa saber C#, Java, Ruby, Python, C, Haskell, TDD, Refactor. Nada! Tendo as características acima, você será bem vindo e bem recebido. Para quem já conhece todas estas linguagens e técnicas, lembre-se: compartilhar conhecimento traz mais crescimento do que se imagina. Além disso, sempre tem algo de novo que podemos aprender.

4. Como funciona o Coding Dojo

Um ambiente para fazer um coding dojo precisa de: 1 computador ligado a um projetor, de preferência com no mínimo 5 participantes, uma sala, um problema para ser resolvido (também chamado de Kata) e um contador de tempo (celular, relógio, algum software etc).

O Dojo inicia com uma apresentação de Passado, Presente e Futuro. No item ‘Passado’ é comentado como foi o último dojo, o resultado e a retrospectiva. No item ‘Presente’ é escolhido um Kata. No item ‘Futuro’ é discutido a data do próximo encontro.

Após definido o Kata, o Dojo começa com um Piloto e um Co-piloto. O papel de cada um deles é:

• Piloto: Escrever o código de teste e o código de produção;
• Co-piloto: Auxiliar o Piloto durante a escrita do código e comunicar aos demais participantes o que está acontencedo.

Isso é Pair Programming, duas cabeças pensando e apenas um computador. O Piloto fica no comando durante 7 minutos. Passado este tempo, o Co-piloto vira Piloto e algum outro participante assume o papel de Co-piloto.

Todo o código escrito pelo piloto deve seguir a técnica de Desenvolvimento Orientado a Teste (TDD). Recomendo fortemente que o link sobre este assunto seja lido. Este é um dos items mais importantes e mais usado em um Dojo, além disso, esta também é a técnica mais complicada de aplicar.

Caso você tenha lido o artigo acima, vai perceber que ele comenta sobre testes que falham (vermelho) e testes que passam (verde). Isso é bastante importante em um Dojo, pois enquanto o teste estiver falhando, APENAS o piloto e o co-piloto podem falar. Isso significa que o restante dos participantes devem ficar em silêncio até que os testes voltem a passar (verde) ou então o piloto ou o co-piloto solicitem ajuda. Isso se faz necessário para manter a concentração já que um teste falhando significa que temos um bug em nosso sistema. A partir do momento em que os testes voltam a ficar verde, qualquer pessoa pode (e deve) sugerir alterações, refatorações ou então inclusão de um novo caso de teste.

Esse ciclo é realizado até que acabe o tempo do Dojo ou o problema esteja resolvido completamente.

5. A retrospectiva

Após finalizado o tempo do Dojo vem a hora de fazermos a retrospectiva. Neste momento cada participante recebe dois post-its, no primeiro post-it é escrito todos os pontos positivos e no outros os pontos negativos da sessão de Dojo que acaba de ser finalizado. Tendo todos estes pontos são anotados, o próximo passo é fazer o possível para que no próximo Dojo os pontos negativos não se repitam.

6. Assuntos polêmicos

6.1. Escolha da linguagem de programação

Infelizmente na área de computação muitas pessoas ainda consideram linguagens de programação como se fosse religião, carregando sua bandeira e lutando (ou pregando) pela sua utilização e divulgação. No Dojo a linguagem escolhida é uma mera ferramenta, asism como a IDE e o sistema operacional.

O Dojo é aberto para qualquer linguagem e assim também devem ser os participantes. A única regra é que para se utilizar uma determinada linguagem, deve haver uma pessoa com experiência nesta linguagem para resolver dúvidas que podem surgir no decorrer do Dojo.

—

Basicamente este é o funcionamento da brincadeira. Talvez eu tenha esquecido de algum tópico, então se alguém tiver alguma dúvida ou sugestão para incrementar este post coloca um comentário ali em baixo que eu altero o post.

Obrigado.