29.08.09
Posted in Ruby
at 3:29 pm
by raganhan
- Data: 25/08/2009
- Horário: 13h00
- Participantes: Firmo, Raganhan, Flores, Douglas, Suzana, Felipe, Samuel, Rentao, Vinicius, Atol
- Problema: Fizzbuzz
- Código: no github, em breve
- Formato: Kata
O Flores preparou um kata simples para mostrar rspec, um framework de BDD para ruby. Este kata é baseado numa brincadeira onde pessoas em crianças em circulo falam cada uma um número em ordem. 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 “Fizzbuzz”. O problema é fazer um programa que jogue esse jogo para números de 1 até 100.
Retrospectiva
Do ruim:
- Problema poderia ser mais difícil (x3)
- Randori é mais legal (x2)
- Faltou maior participação dos espectadores (x2)
- Pouca gente (pessoal do dojo de sábado não veio)
- Faltou o break
- Poderia ser mais rápido nos testes repetidos ( cinco_divide por exemplo )
- Mais dojos de tarde
Do bom:
- Babysteps
- Aprender sobre ruby (x3)
- Problema simples ajuda a entender melhor a linguagem
- Foi legal fazer algo bem simples para entender melhor TDD / BDD
- Presença de bixos
- Público ficou em silêncio
- Bastante gente
- Ver como o rspec funciona
- Dojo de tarde
- Flores explica bem
Uma coisa que foi bastante falada no final é que todo mundo quer mais dojos neste horário
Permalink
09.03.09
Posted in Dojo, SmallTalk
at 9:06 am
by marivb
- Data: 02/03/2009
- Participantes: Mari, Hugo, Yoshi, Fabricio, Thiago, Lucas, Jorge, Rafael, Breno, Ettore, Adolfo, Gianluca
- Problema: Biblioteca de testes estilo “BDD” em Smalltalk (Squeak)
- Código: no github
Insatisfeitos com o SUnit, escolhemos brincar de escrever uma biblioteca de testes mais ao estilo RSpec do Ruby, em Smalltalk. Começamos discutindo as possíveis sintaxes, decidindo por algo como:
(1 = 1) should: #beTrue
1 should: #= to: 1
A implementação foi rolando na classe Object mesmo, em uma categoria especial que adicionamos.
Retrospectiva
Do ruim:
- Problema muito difícil para o conhecimento coletivo do dojo
- SUnit não tem muitos recursos
- A linguagem não tem guru de verdade, ficamos um pouco travados
- Confundimos: testes, linguagem, ambiente – uma bagunça
- Post-its amarelos pequenininhos
- Muita conversa no vermelho: tava difícil?
- Sintaxe Smalltalk: mais de um argumento exige que tenha palavra entre os argumentos
- True é classe, true é singleton, otherwise não é true
- Não tem substring (ou não achamos)
- Faz tempo que não tem post no blog
==> resolvido!
Do bom:
- Squeak é igual à mãe do Fabs
- Muita novidade
- Terminamos com testes passando – malandramente, mas passando
- Method finder é da hora
- Save method WITH STYLE
- nil
- Reflexão: “perform: #bla with: arg”
- Smalltalk é legal, apesar de estranho
- Symbol é String
- Solução de bem poucas linhas
- Pessoas novas, bastante gente
- Dojo continua muito legal (OBAA! XD)
Das discussões que rolaram durante e depois:
- Por algum motivo o ambiente do Squeak lembrou o Fabricio do projeto Alice – aprendendo a programar em Java, no qual você escreve programas que controlam bonequinhos 3D para aprender a linguagem.
- Discutimos “Monkey patch“, ou seja, como colocar métodos no Object sem mudar o projeto Kernel do Squeak. Discutimos o conceito, mas não sabemos como fazer isso em Smalltalk, por isso adotamos a solução mais feia, que foi modificar o Kernel mesmo.
- Colocamos o método “should” no Object… ele deveria existir APENAS quando executando testes. Em produção, uma chamada a “should” deveria idealmente não ser reconhecida.
- Existe vida além do SUnit! Com um pouco de pesquisa, o Hugo acho o projeto SSpec que parece ser uma biblioteca de testes mais no estilo do que a gente queria. Legal! Como será a solução deles?
Permalink
Posted in Dojo, SmallTalk
at 8:39 am
by marivb
- Data: 09/02/2009
- Participantes: Breno, Mari, Jac, Hugo, André, Fernando, Paulo, Ettore, Marcos, Thiago
- Problema: Interpretador de Smalltalk em Smalltalk (Squeak)
- Código: ainda não está online
A idéia do problema era interpretar uma sequencia de comandos em Smalltalk fazendo parse do texto e tudo o mais. Começamos com a coisa mais simples – uma atribuição: “minhaVariavel := umValor“. Apesar de a maioria não saber a linguagem direito e de os que sabiam não lembrarem direito, o código foi evoluindo.
Retrospectiva
Do ruim:
- Avançamos muito pouco, apesar de fazer parte do aprendizado, queríamos ter avançado mais
- Não usamos controle de versões
- Falta conhecimento base em Smalltalk para aproveitar mais da sessão
- A falta de conhecimento também causa lentidão
- Precisamos muito do mouse pra programar no Squeak
- “Gurus” Smalltalk estavam enferrujados
- Confusão com as janelas do Squeak, resolução 800×600 não ajuda, ambiente estranho para a maioria
- Conversa paralela e dupla falando baixo
- Nem sempre a lista de “ToDo’s” dá tão certo
- Estamos na seca se problemas
Do bom:
- Método String >> findTokens do Squeak é o String.split() do Java
- String >> withBlanksTrimmed
- Linguagem nova: Squeak Smalltalk!
- Aprendemos ou relembramos SUnit
- Pessoas novas
- O problema, independente da linguagem, é muito interessante
- Foi uma sessão mais exploratória do que de costume
Do que discutimos com a pizza:
- Squeak em produção? Aplicações do Smalltalk?
- Como funciona o Method Finder? É mágica?
- Que tal um “breafing” da reunião na semana que antecede o encontro?
Permalink
12.12.08
Posted in Dojo, Haskell
at 10:32 pm
by ricardo
O Dojo iniciou com a votação do problema e da linguagem de programação. As linguagens sugeridas foram Haskell, Ruby e Java. A idéia de fazer o Dojo em java seria respeitando umas regras que o pessoal da Thoughtworks montou:
http://binstock.blogspot.com/2008/04/perfecting-oos-small-classes-and….
Essas 9 regras são exercícios para aperfeiçoar a escrita de boas implementações de Orientação a Objetos. São elas:
- Usar somente um nível de identação por método.
- Não usar a palavra reservada ‘else’.
- Envolver os tipos primitivos e Strings.
- Usar somene 1 ponto por linha de código.
- Não abreviar nomes.
- Manter entidades pequenas.
- Não usar mais que duas variáveis de instância na classe.
- Usar classes de coleções que sejam as mais genéricas.
- Não usar getters e setters.
Porém o problema escolhido por votação foi o Snap e a linguagem Haskell.
Problema
O problema Snap se trata de clicks (definidos como pontos) e desenhos de vértices. Sendo que se o click estiver em uma área de atração de um determinado ponto, a posição do click será a própria posição do ponto de atração. O site desse problema está detalhado aqui.
Codando
Teve uma novidade da rotação das duplas. Após os 7 minutos, entrava uma pessoa direto na programação e quem estava codando passaria a ser o “co-piloto”.
Para a resolução do problema, foram criados dois arquivos: Tests.hs (para os testes) e Snap.hs (implementação do problema). Bem ao estilo TDD, a classe de teste começou com as linhas:
Tests.hs
module Main where
import Test.HUnit
import Snap
main = runTestTT testes
testes = TestList [testeCalculaDistancias]
testeCalculaDistancias = TestList[
"Distancia entre um ponto e ele mesmo deveria ser 0" ~:
distancia (Ponto 0 0) (Ponto 0 0 ) ~?= 0
]
Esse código simplesmente significa que o teste vai assegurar que a distância entre o Ponto na posição x = 0 e y = 0, e outro Ponto na posição x = 0 e y = 0, a distância é zero (Linha 11). É claro, pois eles estão na mesma posição !
Disparando esse teste, vão ocorrer erros, pois não existe a definição de “Ponto” e “distância”. Portanto vamos implementá-los.
Snap.hs
module Snap where
data Ponto = Ponto Int Int
distancia :: Ponto -> Ponto -> Int
distancia _ _ = 0
Na linha 3 é definido o Ponto, que será representado por ‘Ponto’ seguido de dois valores numéricos (Int Int). Na linha 5 é definido a função ‘distância’ que recebe dois pontos por parâmetro. Na linha 6 diz que distância, que recebe qualquer coisa no primeiro parâmetro e qualquer coisa no segundo parâmetro, retorna 0 (zero). Agora o teste passa com sucesso!
Porém ainda não está correto dizer que a distância entre qualquer ponto é zero. Então vamos escrever mais testes.
Tests.hs
"Distancia entre o ponto 0 0 e 0 1 deveria ser 1" ~:
distancia (Ponto 0 0) (Ponto 0 1 ) ~?= 1
Incluindo essas duas linhas, agora o teste falha. A distância entre o ponto 0 0 e o ponto 0 1 é 1, porém o método ‘distancia’ sempre retorna zero. Vamos alterar a implementação desse método:
Snap.hs
distancia :: Ponto -> Ponto -> Int
distancia (Ponto 0 0) (Ponto 0 1 ) = 1
distancia (Ponto 0 0) (Ponto 0 2 ) = 2
distancia _ _ = 0
As linhas 2 e 3 foram incluídas e agora o teste passa! Porém, apesar de estarmos roubando para o teste passar, esses passos pequenos são muito importantes. São chamados de baby steps. Baby step é uma técnica de metodologias ágeis que facilita a simplicidade do código, pois só precisamos desenvolver o que é realmente necessário para passar no teste.
O ciclo do TDD é:
Portanto, agora que os testes estão passando, vamos refatorar para o código ficar menos hard coded. As linhas:
Snap.hs
distancia (Ponto 0 0) (Ponto 0 1 ) = 1
distancia (Ponto 0 0) (Ponto 0 2 ) = 2
distancia _ _ = 0
Podem agora ser substituídas por:
distancia (Ponto 0 a) (Ponto 0 b ) = b-a
Agora nossa regra está funcionando para vértices na vertical. Porém ainda não está pronto. Vamos escrever mais um teste:
Tests.hs
"Distancia entre o ponto 0 0 e 1 0 deveria ser 1" ~:
distancia (Ponto 0 0) (Ponto 1 0 ) ~?= 1
Está passando 2 testes mas esse último falha. Vamos à implementação para esse teste incluído passar:
Snap.hs
distancia :: Ponto -> Ponto -> Int
distancia (Ponto 0 a) (Ponto 0 b ) = b-a
distancia (Ponto a 0) (Ponto b 0 ) = b-a
Antes só passavam os testes para vértices na vertical. Agora está passando para vértices na horizontal também. Vamos fazer um teste e ver se passa na diagonal. Incluindo isso no teste ficaria:
Tests.hs
"Distancia entre o ponto 1 0 e 1 1 deveria ser 1" ~:
distancia (Ponto 1 0) (Ponto 1 1 ) ~?= 1
A implementação para passar nesse teste, ainda roubando, ficaria assim:
Snap.hs
distancia (Ponto 1 0) (Ponto 1 1 ) = 1
Essa implementação está hard coded, mas é importante que seja dessa maneira pois precisamos manter o foco em ficar verde no teste, e aí sim fazer a refatoração.
Ok, como os testes estão passando novamente e está tudo no verde, vamos refatorar. As linhas:
distancia (Ponto 0 a) (Ponto 0 b ) = b-a
distancia (Ponto a 0) (Ponto b 0 ) = b-a
distancia (Ponto 1 0) (Ponto 1 1 ) = 1
Porem ser substituídas pela linha:
distancia (Ponto x1 y1) (Ponto x2 y2 ) = x2-x1 + y2-y1
Tudo passando! Vamos escrever mais testes para ver se a regra está certa:
Tests.hs
"Distancia entre o ponto 0 3 e 4 0 deveria ser 5
distancia (Ponto 0 3) (Ponto 4 0 ) ~?= 5
Com esse teste o resultado falha, portanto a fórmula acima ainda não está pronta. O correto seria implementar o teorema de pitágoras para calcular a distância entre os pontos:
Snap.hs
data Ponto = Ponto Float Float
distancia :: Ponto -> Ponto -> Float
distancia (Ponto x1 y1) (Ponto x2 y2 ) = sqrt ((x2-x1)*(x2-x1) + (y2-y1)*(y2-y1))
Concluindo
Vamos parar por aqui. O problema ainda não está resolvido, mas mostrei esses passos para percebermos a importância do baby step e como a modelagem pode ficar melhor e com mais qualidade. Para ver o que foi codado, entre no site do Github aqui.
O TDD nos direciona para uma maior simplicidade para ser desenvolvido somente o necessário para passar no teste. Além de fornecer mais confiança para devidas refatorações.
Retrospectiva
No final teve, como de costume, a nossa retrospectiva e os pontos a melhorar foram:
• “Não precisa do b-a”, sobre um dos baby-steps que poderia ser desnecessário
• “Nano baby step => seguro mas muito lento”. Sobre passos muito pequenos.
• Alguns passos grandes/rápidos em alguns momentos.
• Faltaram mais explicações sobre o que é baby-step durante o código
• “Faltou tão pouco” para terminar o problema. Apesar que esse não é o objetivo final do Dojo.+
• Teve gente que não gostou desse esquema de rotação invertido.
• Projetor estava ruim.
• Baby-step? Não “grown-up wannabe steps”.
• Perdemos muito tempo criando templates do projeto.
• Emacs é melhor que Gedit para codar Haskell
Os pontos positivos foram:
• Tipos de dados no Haskell
• Haskell
• Pessoas gostaram no rodízio invertido.
• Problema legal, simples e bom para TDD
• Baby steps
• ” ˜ é sempre antes.” Sobre a notação no Haskell.
Assuntos em Parking lote foram
• TODOs ajudam ou atrapalham?
• Geradores do ruby são ótimos para gerar templates
Permalink
Posted in Dojo, Haskell
at 5:31 am
by marivb
Relato escrito pela Jac – obrigada, Jac!
- Data: 01/12/2008
- Participantes: Marcelo, Pedro, Thiago, Hugo, Mari, Jac, R, Aline, Bruno Gola
- Randori: Problema das Caixas Empilhadas (adaptado de Pile of Boxes). Utilizamos Haskell com HUnit.
- Carta de criatividade: “Listen your dreams”
- Código: http://github.com/dojosp/participant-s-projects/commits/master/59-pile-of-boxes
Problemas
Os problemas sugeridos foram:
- Caixas empilhadas: Dadas as dimensões de altura e largura de uma caixa com abertura no topo devemos empilhar as caixas. Se uma caixa menor for colocada em cima de uma caixa maior, a menor estará dentro da maior e a altura final da pilha é a altura da caixa maior.Se a caixa maior for colocada em cima da caixa menor, a altura final é a soma das alturas.
- Entertainment: Dada uma tabela de elementos char e uma posição da tabela que não seja um espaço em branco. Deve-se encontar os elementos identicos adjacentes recursivamente ao elemento escolhido e troca-los por espaços em branco. Depois de substituidos, os elementos restantes devem ser movidos para esquerda enquanto os espaços em branco são deslocados para direita e posteriormente devem ser deslocados para baixo enquanto os espaços em branco são deslocados para cima.
- Magnetics: Dado um ponto com sua região de atração, verificar se quando um clique for dado o clique pertence a região de atração do ponto e também verificar a distância mínima entre dois pontos. (Este problema está perto de se tornar o novo little bishops!!)
Entre os problemas sugeridos, o problema das caixas empilhadas foi o escolhido por ser o mais votado.
Read the rest of this entry »
Permalink
13.11.08
Posted in Dojo, python
at 8:33 am
by marivb
- Data: 03/11/2008
- Participantes: R, Leo, Breno, Jac, Mari, Marcelo, Gola, Lameiro, Thiago, Pedro, André, RIcardo, Bani, Juca, Hugo
- Problema: Amigo secreto sem sorteios na mesma família, em Python
- Código: http://github.com/dojosp/participant-s-projects/tree/master/57-secret-santa
Puxa, tinha realmente muitas pessoas nesse Dojo! Começamos com sugestões de três problemas interessantes, mas por votação descartamos “Corrida de vetores” e “Números espaçados” para fazer o amigo secreto sem sorteios na mesma família. O Natal se aproxima!
Votamos pela linguagem também, e no final Python ganhou de Haskell por 1 voto. Read the rest of this entry »
Permalink
Posted in Dojo, Haskell
at 7:00 am
by marivb
- Data: 29/09/2008
- Participantes: Hugo, R, João, Mari, Thiago, Yoshi, Breno
- Problema: map, filter e foldr em Haskell com HUnit (cuidado! Links da Wikipedia mostram implementação!)
- Código: http://github.com/dojosp/participant-s-projects/tree/master/53-haskell-basico
Decidimos finalmente tentar implementar as clássicas funções map, filter e foldr em Haskell. Cada uma deve fazer o seguinte: Read the rest of this entry »
Permalink
11.11.08
Posted in Dojo, Haskell, Kata
at 7:39 am
by flores
- Data: 10/11/2008, no IME – USP
- Participantes: Pedro, Thiago, Hugo, Jorge, R, Flores, Fabs, Mari, Marcelo, Bruno Gola, Renato, Carlos e Ricardo.
- Kata: Blocks por Mari
- Carta da Criatividade: Experimente uma idéia aleatória.
- Código: Estará disponível em breve.
Warm up
Um primeiro Parking Lot que apareceu foi sobre a numeração atual do Dojo, e acabamos por decidir que esse seria o Dojo 57. Após isso fizemos a escolha do problema. Inicialmente houveram quatro sugestões:
- Kata do Blocks
- Randori do Dama
- Randori do Entertainement
- Randori do Amigo Secreto: Um programa para sortear amigos secretos com um teste de aleatoriedade.
Fizemos a votação e o Kata ganhou. Perguntaram da onde vinha o problema Blocks, e a Mari nos disse que é o segundo mais fácil do UVA (só perdendo para o 3n+1). Após isso, sorteamos a carta da criatividade: “Experimente uma idéia aleatória”, que falava sobre um médico indígena e estratégias aleatórias de caças.
Coding Time
Inicialmente, a Mari criou o tipo de dados bloco e um construtor. Com os testes passando, foi feita uma refatoração para funcionar com um número arbitrário de blocos.
No Kata, a Mari começou a criar as operações, iniciando com a pile. Para essa operação, foi criada uma função para tirar um bloco do mundo. Depois criou uma função para devolver os blocos ao mundo recebendo o bloco que deveria voltar e sobre que bloco este deveria entrar, depois a implementou a Operação Pile Over. Infelizmente não terminamos o problema, mas por mais que pareça que fizemos pouco, o Hugo nos disse que para terminar tudo só precisaria implementar mais uma função e todo o resto seria simples de se implementar. Para cada implementação de função, estas ficaram meio grandes, mas se tornaram sucintas com uma boa refatoração, o que tornou o código mais fácil de entender.
A sintaxe de Haskell e os recursos funcionais nos deram a oportunidade de aprender coisas novas como o $, let, map, elem, span e outras coisas.
Retrospectiva
Dessa vez, as pessoas receberam os post-its e canetas no início do Dojo, para escreverem os pontos bons e ruins durante o Kata.
Como pontos positivos , os principais temas abordados foram:
- Haskell e coisas relacionadas a essa linguagem;
- Boas explicações;
- BrHackDay ;
- Pessoas Novas ;
- Pensar Funcional ;
- Refatoração Power ;
E como pontos negativos , podemos citar:
- Haskell e coisas relacionadas a essa linguagem ;
- Sem testes para o mundo ;
- Emacs ;
- Giant Step ;
- Repositório (foi movido para o Parking Lot) ;
- Conversa Paralela ;
- Monads (foi movido para o Parking Lot) ;
- Moedas do Fabrício;
E para o Parking Lot, os principais temas foram:
- Discussão do reposítório;
- Monads;
- Começar pelo in no let … in (isso é o Where na verdade);
- Remove recursivo;
- $ tem precedência mínima;
- Map, elem;
- \lambda;
- Set up para os testes;
- Stick to time?;
- Como construir Show e Eq complexos?;
O Dojo teve alguns momentos engraçados, como o Fabricio dar sua contribuição para a Pizza em moedas (gerando o ódio do Hugo), a explicação do Hugo de porquê o \lambda é representado por “\” (“é só tirar o pézinho”), mas a frase da noite foi dirigida ao Fabricio pelo R “Prum cara preguiçoso que nem você, Lazy Evaluation é ótimo”.
Permalink
03.11.08
Posted in Dojo, python
at 4:40 am
by fabsn
Durante a semana passada, estive no Latinoware a convite da associação Python Brasil, para realizar uma sessão de dojo em python, onde resolvemos o Entertainment, o mesmo problema do Uberdojo 3 (que ainda não tem post 
).
A sessão foi muito boa, não devendo nada para um dojo em São Paulo, tinha por volta de 20 pessoas dentre elas o pessoal da comunidade Python (Luciano Ramalho, Marco André, Ramiro Luz, JS e o Rodrigo) entre outros participantes do evento. A princípio havia uma diferença bem nítida entre os participantes, algumas pessoas, eu inclusive, sabiam pouco ou quase nada de python, ao passo que a outra parte era formada por gurus. Muitas coisas deram muito certo, o parking-lot por exemplo ajudou bastante, toda vez que alguém dispersava com alguma discussão, rapidamente transformávamos o tópico em um postit amarelo informando que o assunto seria discutido após a retrospectiva. Aplicamos estritamente a regra de 7 minutos, mas quando o piloto não conhecia muito de python, e eventualmente perdíamos tempo discutindo, dávamos 2 minutro extras.
A culpa é do Fabs foi uma maneira muito divertida e interessante de tirar o medo de errar da plateia, permitindo que o moderador/culpado (o Fabs :p) pudesse lembrar os participantes das práticas do dojo, se desculpando por não ter ensinado corretamente ^.^.
Acatando espertamente o conselho do Hugo, tivemos uma longa retrospectiva de mais de uma hora, e foi pouco. Haviam muitos post-its vermelhos, mas os participantes estavam felizes com isso. Na maior parte dos casos, esses vermelhos eram discussões interessantes ou duvidas do tipo como começar um dojo.
Basicamente, entre as coisas negativas tivemos o equipamento, o formato da sala e alguns detalhes como não ter lousa. Dentre os positivos, eu particularmente achei que o fato de ser um minicurso, em uma sala pequena com, contribui para tudo correr bem. De fato, fazer dojo como fizemos no fisl, com uma platéia de 200+ pessoas é muito mais difícil.
Não conseguimos discutir todo o parking lot -.-, pois estouraríamos o tempo.
Eu também gostei muito de Foz, principalmente das cataratas. Você pode ver fotos da viagem no meu picasa , enquanto o Fernando Meyer não paga a conta que nos deve no Flickr.
Provavelmente, lá para o fim da semana, haverá um post sobre a viagem, no blog do vidageek.
Por fim, gostaria de deixar em nome do dojo, meus mais sinceros agradecimentos ao pessoal da Associação Python Brasil, que pode proporcionar ao nosso dojo ser divulgado ao me levar para falar no evento.
Valeu ^.^.
Permalink
19.10.08
Posted in Haskell, Ruby, UberDojo
at 9:48 am
by hugo
Na última segunda-feira rolou a edição número 55 do Coding Dojo. Ela foi, em muitos sentidos, especial. Para começar, o Danilo Sato estava presente acompanhado de um colega da Toughtworks, George Malamidis. Além disso, o dojo não foi realizado no IME/USP e sim na casa do Thiago Colucci (que fica “perto” da USP). Por fim, o dojo foi feito no formato UberDojo que vou explicar a seguir.
Usamos duas mesas que representaram duas linguagens (Haskell e Ruby) e cada lado da mesa representou um problema (Bank OCR e Minesweeper). Tivemos então 4 notebooks nos quais 4 pares codaram ao mesmo tempo. Tivemos turnos de 7 minutos como sempre e, ao término do turno, o co-piloto virava piloto, o piloto ia para a “platéia” e alguém da platéia virava co-piloto. Isso era feito tentando evitar que as duplas se repetissem e que as pessoas caissem no mesmo conjunto problema/linguagem muito freqüentemente. Fizemos isso durante pouco mais de uma hora e estávamos em 10 pessoas da velha guarda (Danilo, Thiago além de Fabricio, Jacqueline, Yoshi, Mariana, Breno, Adolfo e eu) e 4 novatos (George, Renato Willi, Bruno Pedroso e Rafael Schouery). Assim sempre sobravam 6 pessoas não programando para fazer as pizzas que acompanharam (Yoshi, Breno e Jac principalmente cuidaram disso, valeu!) e aprender um pouco vendo os outros programarem.
Demoramos um bocado para escolher os problemas e linguagens assim como para configurar o ambiente inicial nas quatro máquinas para que eles ficassem fáceis de usar para todos. Os turnos foram muito intensos e a galera estava em animada e falando alto procurando ajuda do pessoal que estava livre. Rolou uma boa troca de conhecimentos apesar de não ter tido o telão. O pessoal se divertiu bastante inclusive os novatos que agüentaram muito bem o tranco apesar de terem achado o tempo dos turnos muito curtos.
Em retrospectiva, percebemos que boa parte dos nossos problemas vieram da pressa para tentar dar passos grandes e não gastar um tempinho explicando ao novo co-piloto o que estava acontecendo e quais eram os próximos passos. Também concordamos que esse exercício requer participantes que já saibam bem trabalhar com TDD (Desenvolvimento Dirigido por Testes) e que, apesar de ser mais divertido e excitante que o dojo normal, não podemos manter esse formato em todas as sessões. Decidimos então que faríamos uma sessão desse tipo por mês. Também gostaríamos de ter feito uma retrospectiva mais adequada (ficou só na conversa a retrospectiva que fizemos).
Acho que é isso. Se tentarem isso, por favor, mandem-nos feedback a respeito.
Até o próximo dojo pessoal!
Permalink
