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

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?

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?

 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:

1. Usar somente um nível de identação por método.
2. Não usar a palavra reservada ‘else’.
3. Envolver os tipos primitivos e Strings.
4. Usar somene 1 ponto por linha de código.
5. Não abreviar nomes.
6. Manter entidades pequenas.
7. Não usar mais que duas variáveis de instância na classe.
8. Usar classes de coleções que sejam as mais genéricas.
9. 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

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

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

• 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.

Codando

Foi feita uma ToDo List para discutir o approach de como armazenar as entradas, descobrir a altura final da pilha e saber se uma caixa estava dentro de outra.

Durante a discussão conversamos muito mais sobre como obter a solução do que como encaminhar a solução! Surgiram questionamentos posteriores sobre a utilidade da Todo List e até que ponto uma ToDo List é necessária? A partir de quando ela começa a atrapalhar a solução do problema?

Durante a implementação conseguimos definir o tamanho de uma caixa e quando passamos a nos preocupar em como empilhar as caixa surgiram os problemas. Tentamos empilhar as caixas mas não conseguimos muitos sucesso. Patinamos por um bom tempo até que resolvemos fazer uma parada no meio da reunião para entender quais eram as dificuldades.

Percebemos que tinhamos alguns problemas para passagem de argumentos, confusões do interpretador e depois da discussão resolvemos ignorar o metodo empilha por não apresentar um comportamento definido.

Quando retomamos a implementação tinhamos definido novas funcionalidades do problema, como pedestal e o método junta, que deveria juntar ou 2 caixas, ou 1 caixa há um pedestal.
No final da sessão acabamos conseguindo fazer o junta se comportar de forma recursiva, mas não chegamos na solução!

A carta da criatividade não paraceu muito útil nesse problema e algumas pessoas chegaram um pouco mais atrasadas por causa do geocaching.

Retrospectiva

Pontos positivos

• Commit a cada passo
• Pausa no meio da reunião foi muito importante
• Aprendemos novas caracteristicas/funcionalidades da linguagem
• Durante uma refatoração acabamos perdendo uma implementação bem interessante do either e do otherwise
• Algumas sugestões interessantes de como melhorar o ambiente
• Alguns sugeriram de tentar fazer um geocaching junto com o dojo

Pontos negativos

• Questionamentos sobre descarte de código inútil, funcionamento da Box Recursiva
• Não existe infinite test para Haskell
• Complicações da linguagem e muito computador paralelo
• Comida chegou MUITO cedo!

Parking Lot:

• Sugestão de realizar o dojo de natal num restaurante no formato Uber Dojo!

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.

O Problema

Recebemos uma lista de pessoas no formato <nome> <sobrenome> <email>, e devemos sortear o amigo secreto para que uma pessoa não sorteie outra que seja da sua família (mesmo sobrenome).

Decidimos também que se não for possível fazer o sorteio respeitando a regra de não ter amigos da mesma família, então sorteia-se quebrando a regra, pois é mais importante ter o amigo secreto do que respeitar a regra!

Mas nem avançamos tanto assim no problema…

Codando

O primeiro teste foi fácil e direto ao ponto: quando temos duas pessoas apenas, uma tira a outra e pronto. Partimos então para ver como sorteia para três pessoas de famílias diferentes. Os problemas começaram por aqui, apesar que demoramos para perceber… passos grandes demais, e no fim vimos também que tinha mais de uma resposta possível e precisávamos levar isso em conta nos testes. Factível.

Quando chegamos no teste para quatro pessoas… foi aí que paramos de avançar no código. Por que com quatro pessoas existem várias respostas possíveis, e na tentativa de enumerar todas a gente não tinha certeza que alguma possibilidade não tinha escapado. Sugeriu-se então testar propriedades da resposta produzida, mas tais testes eram complexos e sugeriu-se portanto criar métodos de teste auxiliares, testando-os com TDD. Estranho… mas foi isso que fizemos até o fim da sessão de código.

Retrospectiva

Primeiro as coisas boas:

• Tinha muita gente (quase batemos nosso recorde de 16 pessoas) e tinha gente nova também
• Logo, tinha muito post-it e muita pizza
• Pessoal gostou de Python, alguns aprenderam um pouco, outros lembraram
• Os commits não atrapalham o andar da sessão
• Foi muito divertido, e o problema era bem interessante
• Aprendemos que pessoas[:-1] pega todos os elementos menos o último do vetor de nomes
• E aprendemos que enumerate(pessoas) permite iterar em pares (i, nome) de índices e valores no vetor pessoas

Por outro lado:

• Talvez por que tinha muita gente, experimentamos um burburinho no vermelho que não tinha faz um tempo, com direito a platéia usando computador e tudo o mais. Não aguentamos ficar quietos!
• Relacionado a isso, alguns sentiram falta das conversas do Uber Dojo.
• Ainda por conta do número de pessoas, nem todo mundo pode codar. 7 minutos parece muito tempo em um grupo maior.
• Python de novo?
• Pequenas dificuldades com a linguagem atrapalham (discutimos isso também no Parking Lot)
• Quem já sabe python bate o olho na mensagem de erro e entende, sem dar tempo para todos lerem.
• Não ficamos convencidos de que todos os participantes entendiam o que estava acontecendo a todo momento.
• Talvez com razão, pois alguns não entenderam o motivo do método auxiliar para testes.
• Começamos com atraso.
• Tivemos alguns passos “gigantes” tanto no começo quanto no fim. Faltou lembrar de simplicidade e baby steps.
• O problema era “ruim” por envolver um sorteio e exigir assim que houvessem várias respostas possíveis. Na verdade o ruim foi que não percebemos isso no começo, o que nos pegou totalmente desprevinidos no meio da sessão. Teria sido um bom dia para experimentar a “pausa no meio”, mas não fizemos.
• Os testes eram muito trabalhosos, tão complexos que a gente nem chegou no problema.

No Parking Lot, discutimos:

• Dojo na Globalcode – um convite do pessoal da Globalcode de fazer uma sessão no auditório deles lá na av. Paulista.
• Distribuir post-its no começo, para preenchermos durante a sessão.
• Quando a dupla tem problemas com sintaxe… a platéia deve ficar calada mesmo assim? Deve esperar eles pedirem ajuda? Ou deve ajudar mesmo sem o pedido, mostrando a mensagem de erro e ensinando o que significa?
• Como testar algo com resultado “aleatório”?
• “Parece difícil demais? Não entendeu direito? Parece mais complicado do que deveria? Tá errado!” – se alguém se sentir assim durante o Dojo, tem algo de errado acontecendo, deveríamos parar e ir com mais calma.

Falamos também de uma “checklist” de coisas pro Dojo, mas não houve muita aprovação da idéia pois achamos que não seria seguida. Discutimos também a idéia de “Dojo smells”, os maus cheiros do Dojo, que poderiam ajudar a gente, e outros, a identificar quando tem algo errado no ar.

Ah, e queremos reciclar os copos!

A terceira cadeira

Pessoal, enquanto escrevia esse post fiquei pensando e tive uma idéia… queria saber o que vocês acham!

E se tivéssemos uma terceira cadeira lá na frente? A qualquer momento, alguém da platéia poderia vir e sentar nessa cadeira, dando uma força pra dupla que está codando. Ele adquiri temporariamente o “direito” de falar no vermelho. É claro que essa pessoa não poderia codar e deveria sair logo da cadeira, mas seria uma maneira de organizar as sugestões que vem da platéia, principalmente no vermelho. Facilitaria também pra ajudar a dupla com problemas de sintaxe ou lembrar de dar um passo mais simples.

Pensei nisso pois tem um formato de open spaces que é parecido (uma roda de cadeiras, sempre deve ter uma vazia, só que em está sentado pode falar; se alguém senta na cadeira vazia, alguém que está sentado deve levantar). E também porque fazemos um pouco disso no Uber Dojo – ao longo da sessão, várias vezes acontece de alguém sentar com a dupla principal para ajudar ou simplesmente para olhar o que está acontecendo…

É uma idéia que precisa ser refinada com certeza, mas talvez seja legal. O que vocês acham?

Decidimos finalmente tentar implementar as clássicas funções map, filter e foldr em Haskell. Cada uma deve fazer o seguinte:

• map: recebe como parâmetros uma função unária (apenas um parâmetro) e uma lista, e devolve uma lista que é resultado de aplicar a função a cada elemento da lista passada como parâmetro. Por exemplo:
  map (+ 5) [2 0 4] devolve [7 5 9]
• filter: recebe como parâmetros um predicado (função unária que devolve True ou False) e uma lista, e devolve uma lista com os elementos da lista original que satisfazem o predicado (resposta True). Por exemplo:
  filter even [1 2 3 6 5] devolve [2 6]
• foldr: essa é mais complicadinha, e nem começamos a fazê-la, então nem vou explicar muito =P. Começando com um exemplo:
  foldr (+) 0 [1 2 3] devolve 6, que é a soma dos elementos da lista. Então, o foldr recebe uma fuinção binária (com dois parâmetros), um elemento “base” (0 no exemplo) e uma lista, e devolve o resultado de usar a função para “juntar” todos os elementos da lista.

Codando

Começamos pelo map que parecia mais fácil. O código cresceu num ritmo acelerado e bom (ou seja todos estavam acompanhando). Apesar de algumas dificuldades com as mensagens de erro, conseguimos contorná-las e terminar o map.

Em seguida atacamos o filter, no mesmo ritmo. Terminamos de implementar no horário, e decidimos não começar o foldr.

Retrospectiva

Reclamamos:

• Dos atrasos
• De não filmar a sessão (para quem quer conhecer)
• De não conseguirmos fazer commit no repositório remoto durante a reunião (o git estava dando um erro bizarro que ninguém conhecia)
• De erros do compilador Haskell que não entendemos (fomos forçados a declarar o tipo das funções para contorná-los)
• De problemas com o editor

E mais:

• O foldr não parece tão fácil quanto os outros
• Queremos aprender a implementação do even (verifica se um número é par)
• Queremos entender a diferença entre ~=? e ==

Por outro lado, aprendemos:

• :t coisa diz o tipo de coisa (no interpretador)
• a definir tipo de funções que recebem funções como parâmetro
• currying, ou seja, funções parciais “automáticas”
• o que é pattern matching e pattern overlapping
• import Char traz funções como isLower
• otherwise, uma palavra chave, é um alias para True – para alguns isso cheira a hack, para outros é açúcar sintático

Além disso, gostamos:

• que Haskell continua legal e está mais intuitivo
• que tivemos pessoas novas
• que terminamos map e filter
• que tivemos um ritmo bom e acelerado

No parking lot, discutimos os temas:

• Não explicamos dojo pro novato
• Pq precisamos indicar os tipos? (o que são os erros bizarros?)
• O que é “Char.isLower” ? Método? Tem algo a ver com P.O.O.?
• O main é uma função??

ps: Buscando links pra colocar neste artigo, descobri que existiu um cara chamado Haskell Curry, matemático e lógico norte-americano….

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”.

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 ^.^.

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!