Dojo@PUCC #2

Na última quinta-feira (07/04), um grupo de alunos da PUCC realizou o seu segundo Coding Dojo, desta vez o com um visitante de fora da PUCC (o Renne).

De acordo com eles, a sala já está reservado toda quinta-feira das 17h30 às 19h e um pouquinho para o Dojo@PUCC no prédio H10, sala 611 na PUCC Campus I. Quem estiver interessado apareça lá, ou mande uma mensagem na nossa lista de discussão para mais informações.

Os participantes

O código (ou parte dele)

O código (ou parte dele)

E o que foi feito???

O que foi bom:

  • Membro experiente em Dojo (Renne)
  • Muitos problemas para escolher
  • Python (nova linguagem)
  • Problema bem legal
  • As conversas

O que foi ruim:

  • Tempo ++++ 😦
  • Falta de pessoas

Sugestões:

  • Divulgar em várias turmas e externamente à PUCC

O que aconteceu no Dojo #14

Na semana passada (01/02) aconteceu o décima-quarto Dojo na Unicamp.

Participantes:

O que foi bom:

  • vim + Python
  • vim
  • vim

O que foi ruim:

  • Antecipação da solução do problema
  • Falta de especificação da entrada do problema
  • vim

Sugestões:

  • Começar as 18h fica melhor

O que aconteceu no Dojo #13

Já passou algum tempo, mas só hoje consegui escrever como foi o décimo-terceiro Dojo na Unicamp. O encontro ocorreu no dia 25/01 e como já faz algum tempinho, não vou saber descrever o andamento muito bem. Infelizmente poucas pessoas apareceram, mas estamos ao menos mantendo uma freqüência nos encontros. Espero que com a volta as aulas na Unicamp consigamos aumentar um pouco mais a participação.

Sobre o problema:

  • Linguagem escolhida: Python
  • Problemas: Troco
  • Editor escolhido: vim
  • O código gerado: Troco

Participantes:

O que foi bom:

  • Live coding ++
  • Python
  • vim +++
  • Troca de experiência sobre vim

O que foi ruim:

  • Faltou domínio do vim (ou isso foi bom)
  • Problema simples
  • Poucas pessoas

Sugestões:

  • Configurar o vim previamente
  • Repositório do grupo no github

O que aconteceu no Dojo #12

Ontem (18/01) aconteceu o décimo-terceiro décimo-segundo (obrigado Andrea, havia pulado um) Dojo na Unicamp. Desta vez a maior parte do pessoal nunca havia participado de um Dojo, o que por um lado é bom (mais pessoas se interessando pelo encontro) e por outro lado ruim (onde está o pessoal das antigas?). Mas acredito que no próximo teremos mais pessoas novas e “veteranos” do Dojo juntos.

Como a maioria era novata em um Dojo, foi feita uma apresentação rápida dos objetivos e da dinâmica do Dojo, além de comentar um pouco sobre TDD. Após escolhemos o problema do FizzBuzz (que é bem simples), para que os “novatos” entendessem mais facilmente a dinâmica.

Devido a simplicidade do problema, resolvemos ele rapidamente, o que deu oportunidade de iniciarmos um novo problema (Nomes de Autores de Obras Bibliográficas) e, como todos já estavam bem mais confortáveis com a forma de pensar no problema o desenvolvimento foi mais rápido e dinâmico.

Das conversas no pré-Dojo e no pós-Dojo surgiu uma idéia muito interessante de tentarmos organizar um Dojo em outro lugar de Campinas (provavelmente na Unip), em outra data (provavelmente sábado) para que pessoas que têm dificuldade com os horários ou com o acesso à Unicamp possam ter oportunidade de participar e, se conseguirmos manter a regularidade, toda semana termos ao menos duas opções de sessões de Dojo para participar. Espero continuar com essa conversa através da lista 🙂

Participantes:

O que foi bom:

  • A escolha da linguagem (Python) ++
  • Ubuntu +
  • Conhecer o Dojo
  • Práticas de programação diferentes em Python
  • Conhecer o pessoal
  • Pessoas novas apareceram

O que foi ruim:

  • Velocidade no início
  • Problemas simples ++
  • Pessoas antigas não vieram

Sugestões:

  • Mais tempo (talvez no sábado) ++
  • Emacs ou outra IDE
  • Novos problemas
  • vim

Relato do Dojo #11

Esse foi o Dojo organizado mais rápido até agora. Depois de uma troca rápida de e-mails na lista, 6 pessoas se dispuseram a participar do Dojo, e apesar da correria foi um ótimo encontro.

Logo após a escolha do problema fizemos uma discussão de qual caminho iríamos seguir no seu desenvolvimento. Definimos um conjunto de suposições para facilitar o desenvolvimento:

  • Tokens válidos: números, ‘+’, ‘-‘, ‘*’, ‘/’, ‘.’, ‘(‘ e ‘)’
  • A entrada sempre era uma expressão válida
  • Os espaços em branco na expressão de entrada seriamo ignorados

Começamos com testes simples, para separar a expressão em tokens e caminhando pela solução, a complexidade do problema ia aparecendo gradualmente (o que gerou boas discussões durante todo o Dojo sobre a forma de implementar). Chegamos num ponto onde algumas expressões eram calculadas corretamente, mas como o Dojo já estava durando muito (e todos estavam com fome), resolvemos encerrá-lo.

O pós-dojo ia ser com comida mexicana no Salamandra em Barão Geraldo, mas como ele estava fechado, acabamos no Subway, e como o problema realmente era muito interessante, estavamos indo embora e ainda tivemos algumas idéias de como terminá-lo.

A solução do problema já está bem encaminhada, e o código-fonte disponível para quem quiser completá-lo. Se alguém quiser discutir o problema na lista, fique a vontade também 🙂

Participantes:

Pontos positivos:

  • Site do Renne (<a>http://dojopuzzles.com</a&gt;)
  • Teclado bom
  • Maior público que nos últimos
  • Python ++
  • Dojo longo
  • Todos participaram bastante
  • Ctrl+P / Ctrl + N (atalhos do vim)
  • Marcado em cima da hora e ainda teve bom público
  • Problema complexo divisível em etapas distintas
  • vim +++
  • Local (IC)
  • “as vezes precisamos escrever testes mesmo achando que eles já vão passar no código existente”. Isso entra em contraste com a visão de “escrever testes que não passam, para faze-los passar”. (comentário do JS via lista dojo-campinas)

Pontos negativos:

  • Platéia inquieta +++
  • Marcado em cima da hora
  • Fome +++
  • vim
  • demorou muito
  • horário do começo (poderia ser às 19h)
  • divisão de colunas da folha de retrospectiva do Dojo
  • pessoas sem bandejar ficam com fome
  • Dojo longo
  • Alto carbon footprint no pós-dojo

Sugestões:

  • Criar uma guest account preparada para o Dojo (cores de Terminal)

Coding Dojo #10 – Dojo de Natal

Hoje (dia 21/12) tivemos o nosso Dojo de Natal, e apesar de poucos participantes, foi muito divertido. Como estavamos em poucas pessoas, uma nova forma de codificação ágil foi inventada somente para este Dojo: o Trio Programming, onde temos a figura de dois co-pilotos ao invés de um só 🙂

Pela primeira vez também conseguimos fazer um Pós-Dojo, onde aproveitamos a super-promoção de terça-feira da Batataria Suiça em Barão Geraldo onde pudemos comer 4 batatas pelo preço de duas. Espero que nos próximos possamos repetir a dose.

Desta vez não conseguimos terminar o problema, mas ele está disponível para quem quiser continuá-lo. O problema:

Participantes:

Pontos positivos:

  • Python +++
  • Muitas risadas
  • Battataria Suiça no Pós-Dojo
  • Trio Programming

Pontos negativos:

  • Poucas pessoas
  • O teclado do notebook do Renne
  • Pouco tempo

Sugestões:

  • Sempre fazer um pós-dojo 🙂

Como semana que vem a maioria das pessoas estará viajando (menos eu que terei que trabalhar), este será o último Dojo de 2010. Espero que no próximo ano possamos realizar muitos encontros, com mais participantes e em mais lugares diferentes em Campinas. Feliz Natal! E Feliz Ano Novo.

Coding Dojo #9

Ontem conseguimos finalmente realizar o nono Dojo em Campinas. O local foi o de sempre (sala 352 do IC-Unicamp) e felizmente pessoas novas estão começando a participar e os participantes antigos não estão sumindo.

A novidade deste encontro foi que finalmente conseguimos trocar um pouco a linguagem. Os Dojos anteriores foram quase todos resolvidos usando a linguagem Python, principalmente porque no meu computador eu não tinha nenhum ambiente de testes configurado para outras linguagens.

Desta vez havia alguém (o Ricardo Panaggio) que tinha no seu notebook várias versões de Ruby instaladas. Então pudemos aprender um pouquinho de Ruby!

O problema escolhido:

Passo-a-passo fomos entendendo melhor o problema e aprendendo um pouco mais sobre o Ruby o RSpec e quase no final, o Fábio deu uma idéia para refatorar o código de testes onde conseguimos simplificar muito a definição e execução de novos casos de testes (vejam o resultado no nosso repositório). O código está disponível no nosso repositório.

Participantes:

Pontos positivos:

  • Aprendemos uma linguagem nova.
  • Apredi muito mais RSpec do que imaginava que sabia.
  • Reloginho.
  • Trocamos de linguagem ++.
  • Estamos conseguindo manter a freqüência nos encontros.

Pontos negativos:

  • Praticamente ninguém conhecia a linguagem, mas depois de alguns minutos todo mundo ‘pegou’.
  • Imaginava que ajudaria muito mais do que eu podia.
  • Demoramos para configurar a máquina.
  • Colocar a documentação da API para consulta rápida.

Sugestões:

  • Colocar o problema em outra tela ou impresso ajudaria. ++