19.10.08
Novo domínio do Dojo!
Nosso blog agora está em outro domínio. O novo domínio é http://www.dojosp.org
Obrigado e desculpe-nos pelo inconveniente 
13.10.08
SuperDojo1 - Minesweeper
- Data: 11/10/2008, no Encontro Ágil
- Participantes: Hugo, Mari, R, Jac, Fabs, Bruno, Thiago, Daniel, Adolfo e 2 novos participantes (cujos nomes eu não sei. Alguém??)
- Randori (SuperDojo): Minesweeper. Utilizamos Ruby com RSpec em um note. Python em outro.
- Código: código em Python (de um dos notes presentes)
No último sábado, a AgilCoop promoveu o 1o. Encontro Ágil. Um dos pontos positivos, a meu ver, foi a disponibilização de uma sala destinada a debates de temas fora da grade do evento. E foi nesta sala, chamada de Open Space, que aconteceu o nosso primeiro SuperDojo.
Nesta nova modalidade, que só pode ser executada na forma de randori, a brincadeira é feita com um computador e sem telão. Escolhido o problema, piloto e co-piloto se reúnem no único computador ligado e codam, enquanto a platéia fala de assuntos diversos. Passados os 7 minutos habituais, o piloto vai para a platéia, o co-piloto assume o teclado e alguém da platéia, após 7 minutos de um papo descontraído, é surpreendido com aquele código legado. É bem interessante e desafiadora esta experiência de ser inserido num contexto e ter que continuar o problema tendo 7 minutos para aprender o código e mais 7 para colocar suas idéias nele.
Contamos um pouco do funcionamento das nossas reuniões para os novos participantes do grupo. Foi boa surpresa saber que eles ouviram falar do Dojo, encontraram informações no site do Danilo, e já realizaram duas sessões na empresa em que trabalham. Reafirmamos aqui o convite para que participem também das nossas sessões às segundas-feira, 20 horas, no IME/USP.
Em seguida, escolhemos o problema do campo minado e resolvemos programar em Ruby. Tivemos muito pouco tempo para codar, por conta da proximidade do encerramento do evento. Logo nos primeiros rodízios, o Fabs começou a resolver o mesmo problema com o Bruno em Python, em outro computador. Neste momento, não sei mais se estavámos no meio de um SuperDojo ou de um UberDojo.
Particularmente, eu achei a experiência muito desafiadora e divertida. Não é muito fácil se concentrar com o pessoal falando de vários assuntos e se ver no meio de um problema já começado e tendo 14 minutos para conviver com ele. Achei muito legal esta nova modalidade. Tomara que possamos praticá-la novamente!!
E vocês o que acharam? Que tal fazer a retrospectiva e parking lot nos comentários deste post?
09.10.08
Dojo 54: Dominando Entrada e Saída padrão no Haskell
- Data: 06/10/2008
- Participantes: Thiago, Hugo, Mari, Leo, Jac
- Randori: The 3n+1 problem. Utilizamos Haskell com HUnit.
- Carta de criatividade: “Fight for it”
- Código: http://github.com/dojosp/participant-s-projects/tree/master/54-stdin-haskell
Escolhemos um problema simples para, na verdade, aprender a ler da entrada padrão e escrever na saída padrão com Haskell.
07.10.08
Dojo 52 - Trits original
Mais um relato pelo Thiago. Muito bem & muito obrigada!! XD
- Data: 22/09/2008
- Participantes: Thiago, R, Hugo, Mari, Leo, Yoshi e Breno
- Randori: Problema Setun (ou conhecido também chamado de Trits original), retirado da segunda seletiva da XII Maratona de Programação da USP. Utilizamos Haskell com HUnit.
- Carta de criatividade: “Find What’s out of Whack”
- Código: http://github.com/dojosp/participant-s-projects/tree/master/52-setun
O problema: receber um número inteiro e devolver sua representação em uma base ternária, cujos algarismos válidos são “+”, “0″ e “-” (de valor, respectivamente, 1, 0 e -1). Um número nesta base ternária (ou seja, um “trit”) representado como a1a2…ak tem valor igual a a13k + a23(k-1) + … + ak-131 + ak30. Por exemplo, o trit “+0-” tem valor 1*32 + 0*31 + (-1)*30 = 8.
Após resolvermos em um dojo passado o problema inverso, ou seja, dado um número formado por Trits, convertê-lo para a base decimal, resolvemos encarar o problema original (denominado de Setun).
Iniciamos uma pequena discussão de qual seria a abordagem ideal. Assim ficou decidido que necessitaríamos de uma função que dado um número, retornasse a maior potência de três deste número. Começamos daí.
Codando
Apesar da abordagem “mandar” fazermos uma função que nos dava a maior potência de três de um número, ficou muito claro para todos que, na verdade, cada um tinha entendido uma coisa do que fazer de verdade. Portanto os primeiros a codarem levaram o problema para o lado de que a maior potência era o maior expoente com base três que coubesse no número dado. No entanto os que vieram depois entenderam que era o resultado de três elevado a este expoente.
Esta confusão no levou a um impasse de tal forma que chegou um momento que todos estavam “palpitando” no código, e os “coders” lá da frente ficaram perdidos e travados. Foi então que percebemos que havia algo muito errado, mas não paramos para tomar nenhuma atitude. Ao invés disso seguimos em frente com testes e código.
Mas já era tarde e não evoluímos muito mais, terminamos com uma função que devolvia potência propriamente dita e não o expoente de três. Além desta função, não andamos muito na resolução do problema propriamente dito.
Retrospectiva
Como tínhamos decidido no dojo anterior, iríamos pensar mais nos problemas do dojo (Post-its vermelhos) do que nas coisas que estão andando bem.
Dentre os pontos positivos mencionados:
- Elogios à Haskell, principalmente ao fato de podermos escrever “x | x < 3″ lendo “x, tal que x menor que 3″;
- Atalhos do Emacs;
- O equipamento de modelar vidro finalmente chegou para o Yoshi, ampulheta do Dojo em breve;
- Aprendemos bastante sobre o problema;
- Fizemos um git reverse na mão;
Dos pontos negativos, foram citados:
- Não definimos e seguimos uma abordagem única;
- Atrasos de pessoas;
- git revert não funcionou;
- Deveríamos usar o TAB no Emacs, ele identa;
- Perdemos tempo fazendo otimizações, ou pensando nelas;
- Desatenção fez com que escrevêssemos testes “inúteis”;
- “O que fazer quando os testes saem dos trilhos?”;
- Pessoas perdidas durante a resolução;
- Planejamento foi furado;
Ficamos ainda com algumas discussões para o Parking lot, como sempre.
- TV Dojo: Muitas pessoas de fora do dojo estão nos pressionando para criarmos algum vídeo para que eles possam assistir como é o nosso Dojo. Ficou decidido que iríamos dar um jeito de arrumar ao menos duas câmeras para filmarmos uma sessão, sessão esta que seria uma espécie de Randori//Kata, pois iríamos resolver um problema já conhecido e de fácil entendimento para todos, mas seria resolvido no estilo Randori.
- Dojo em silêncio é igual a Dojo pouco produtivo? A resposta geral foi não. O fato do problema ser “enrolado” e a abordagem-mal-desenhada foi o que gerou o silêncio e o pouco desenvolvimento de código, a lição foi: problema simples (pequeno) não significa problema fácil.
01.10.08
Dojo 45 (nas férias) - Whitespace
Relato muito bem escrito pelo Breno, mas publicado pela Mari pois o Breno demorou muito pra publicar!
- Data: 4/08/2008
- Participantes: Thiago, Breno, R
- Sem código no dia
- Ambiente: Ubuntu Linux (Thiago)
Não tivemos quórum para um Randori, e como achávamos que não possuíamos muita proficiência em Erlang, e sem querer voltar para C, decidimos usar o dojo do dia 4 para explorar um pouco novas linguagens.
No último Dojo, um das decisões foi que, mesmo que decidíssemos continuar com Erlang, precisaríamos de alguém para atuar como guru, ou não conseguiríamos progredir tão facilmente. Animados com essa idéia, e cursando Inteligência Artificial neste semestre, R e Breno decidiram tentar programar em Prolog com TDD, e propor, mais à frente do semestre, que fosse a linguagem do Dojo por algumas sessões, quando ganharem prática e puderem servir de gurus.
Entretanto, o acesso à Internet no Laptop do Thiago foi feito pela UspNet sem fio, mais lenta do que o acesso via cabo de rede. Enquanto os pacotes do SWI-Prolog eram baixados, verificamos que existe uma Unit Test para Prolog. Mas ela não vem por padrão, devendo ser baixada à parte. Ao baixarmos, era necessário transformar de um pacote Red Hat para um pacote Debian, e o alien, programa responsável por esse passo, se recusava a funcionar adequadamente. Depois de baixar o pacote de novo, procurar por possíveis problemas, etc, nos convencemos que não seria possível disponibilizar um ambiente para Prolog, decidimos chutar o pau da barraca e programar em Whitespace - aliás, surgiu a idéia de fazer um Dojo com linguagens esotéricas.
Apanhamos um pouco, tanto do emacs, que teimava em escrever [SPC] em vez de pôr um espaço na tela e [LF] em vez de enter quando tentamos dar copy-and-paste de um código em Whitespace. Até que percebemos que o emacs estava no modo WS, como do próprio Whitespace, em que toda instrução que usa o topo da pilha também o remove do topo. E, ao fim, conseguimos entender o comportamento das instruções de whitespace melhor do que fazer a instalação da plunit. Coisas da vida.
Retrospectiva
Coisas Legais:
- Existe unit test para Prolog! Mais uma linguagem candidata a participar do Dojo, com possíveis gurus.
- Whitespace é uma espécie de assembly
- Mudar de linguagem é divertido
- Emacs tem até modo whitespace
Coisas Ruins:
- Pouca Gente
- Unit Test de Prolog é meio chata de instalar. Talvez seja melhor pegar o source.
- Quase todo comando de Whitespace faz um pop implícito
Parking Lot:
Idéias de problemas: WebServer e Celular
17.09.08
Dojo 51 - Trits
- Data: 15/09/2008
- Participantes: Thiago, R, Hugo, Mari, Lameiro, Pac-Man, Vitor, Ramiro e Breno
- Randori: Problema dos Trits (na verdade, um derivado), retirado da segunda seletiva da XII Maratona de Programação da USP. Utilizamos Haskell com HUnit
- Carta de criatividade: “Challenge The Rules”
- Código: Ainda não está online.
A votação inicial escolheu o problema dos “Trits”: receber um número inteiro e devolver sua representação em uma base ternária, cujos algarismos válidos são “+”, “0″ e “-” (de valor, respectivamente, 1, 0 e -1). Um número nesta base ternária (ou seja, um “trit”) representado como a1a2…ak tem valor igual a a1*3^k + a2*3^(k-1) + … + ak-1*3^1 + ak*3^0. Por exemplo, o trit “+0-” tem valor 1*3^2 + 0*3^1 + (-1)*3^0 = 8.
Encarando (e mudando) o problema
Começamos a discutir a abordagem para o problema, mas não surgiu nenhum caminho óbvio. O Hugo sugeriu, então, começarmos resolvendo o problema invertido (e mais simples): dado um trit, devolver seu valor inteiro. Como tínhamos alguns convidados, fizemos uma breve introdução ao Dojo antes de partirmos para o problema, e alguns esclarecimentos ao longo da sessão. Mas mantivemos as janelas de 7 minutos, com o ciclo “teste, código, teste, commit”. O código em Haskell foi evoluindo naturalmente, e soluções contendo “if” e estruturas semelhante saltaram à vista e foram rapidamente substituídas por construções mais eminentemente funcionais.
Quase ao final do horário, com todos os participantes já tendo comandado o teclado, terminamos a solução do problema, e todos se disseram confortáveis com a abrangência dos testes. Partimos para uma otimização da solução, que, a esta altura, calculava o tamanho do trit a cada passo da recursão, mas não conseguimos terminar em tempo.
Retrospectiva
Assim como no dojo anterior, a quantidade de cartões amarelos foi bem maior do que a de vermelhos (e chegamos a redimensionar os espaços de cada um, para que os amarelos coubessem no foco do projetor). Apesar de ser um indicador de que todos estão se divertindo, foi sugerido que talvez estejamos sendo complacente demais, e que devíamos nos focar mais em procurar oportunidades de melhoria. Foi mencionado um palestrante da AgileConf, que mencionou que, no Japão, nas retrospectivas só se discutiam os vermelhos; elogios ficavam para a hora de lazer. Levantou-se a idéia, então, de, nas nossas retrospectivas, discutirmos primeiro os vermelhos, e só discutirmos os amarelos e o parking lot junto com a comida.
Dentre os pontos positivos mencionados:
- A presença dos convidados (dois do Rio de Janeiro e um de Curitiba)
- Os convidados mencionaram que gostaram bastante das cartas de criatividade e da dinâmica do dojo
- Mais elogios ao Haskell
- O problema interessante e a solução a que chegamos
Dos pontos negativos, foram citados:
- não resolvemos o problema que escolhemos no início, mas o problema inverso.
- falta de música (!). Foi colocado no vermelho e no parking lot.
- avançamos um pouco no horário
- muita conversa
- foi sentida a falta da Jac, e das polarizações Yoshi vs. Fabs.
- falta de comentários no código (mas este ponto foi comentado em seguida, e foi mencionado que a idéia é que os testes sejam documentação adequada para o código produzido a partir deles).
Parking lot + Pizza
Uma característica particular deste dojo, elogiada na retrospectiva e discutida ao final, foi que cada um pôde escolher utilizar o editor de sua preferência (desde que fosse vi ou emacs, nada de smultron!) na sua vez de comandar o teclado. Isto gerou alguma demora nas transições, quando o piloto precisava iniciar e fazer as configurações mínimas em seu ambiente, mas, de resto, funcionou surpreendentemente bem, embora nem todos tenham ficado satisfeitos.
Ao fim, todos nos divertimos muito, solucionamos o problema e estamos mais confortáveis com Haskell. Foi bom termos convidados, que pareceram gostar bastante da experiência. Esperamos que iniciem seus próprios dojos!
14.09.08
Dojo 50 - Caim e Abel Lemos
- Data: 08/09/2008
- Participantes: Mari, Thiago, Jac, Hugo, Adolfo, Fabs (o desertor), Yoshi, R e Léo
- Randori: Problema do sanduíche, retirado da segunda seletiva da XII Maratona de Programação da USP. Utilizamos Haskell com HUnit
- Carta da inspiração: “Focus on the real truth”
- Código: repositório do Dojo no github
O problema deste último Dojo era a respeito de dois irmãos que brigavam porque um deles se sentia injustiçado pela divisão de um sanduíche-íche. Se bem me lembro, o chef que havia preparado o lanche argumentava que a divisão fora justa e dizia ser possível provar que a quantidade de recheio contida nas partes era idêntica. E como isso era possível? Bem, se a minha memória não estiver me traindo, a entrada era a primeira linha de uma matriz quadrada e a descrição do problema nos dizia como montar o resto da matriz e também como calcular a quantidade de recheio em uma parte do nosso sanduíche-matriz.
Encarando o problema
Com o problema definido, o nosso primeiro objetivo era montar a matriz. Teste, código, teste, commit no git. Este ciclo foi mantido com a já comprovada e importante rigidez dos 7 minutos. Conseguimos fazer com que todos os participantes codassem pelo menos uma vez, até que, pouco antes da hora da retrospectiva, começamos a discutir se o cálculo do produto cartesiano resolveria o nosso problema. Não conseguimos esta resposta pois a ampulheta (mal Yoshi :)) o relógio já apontava a hora da retrospectiva.
Reclamações, elogios e incômodos
Ao dar a primeira olhada para os post-its, me surpreendi com o número de cartões verdes: era 3 vezes maior que o número de cartões vermelhos, o que indica que estamos conseguindo melhorar nossas sessões.
Os pontos positivos:
- Muitos elogios à linguagem. Pelo jeito, todo mundo está gostando de Haskell
- Elogios a algumas particularidades da linguagem, como “produto cartesiano em uma linha curta”, “sintaxe semelhante à linguagem matemática” e “bloco let pode facilitar a estruturação de idéias”
- O problema era legal
- Gente nova (Léo e R, que voltou ao Dojo e o reconheceram)
- Pessoas de bom humor e querendo ir logo ao Outback
Os pontos negativos:
- Ficamos muito longe de solucionar o problema
- Tentamos alguns passos muito grandes, o que resultou em grandes refatorações
- O ‘let’ é uma boa prática mas provavelmente indica que o passo é muito grande
- Produto Cartesiano x Produto Matricial
- Alguém pegando no pé da Mari porque ela é defensora extremista da linguagem
Parking Lot:
- Por que não podemos tirar 2 elementos do começo da lista?
- Dojo “round-the-table”, alta concentração, no restaurante!!!
Feeding the coders!
Terminada a retrospectiva, fomos ao Outback comemorar o aniversário da Jac e do Thiago. O Fabs, só na hora da comida, se juntou a nós. Comemos pão, carne, batatas, cebolas e ainda ganhamos 2 sorteves para cantar o parabéns aos aniversariantes. E assim, depois de códigos, risadas, comidas e doces, voltamos felizes para nossas casas.
05.09.08
Dojo 49 - Conhecendo Haskell
Relato escrito pelo Thiago - escreveu rápido e bem, quase dá pra ouvir ele falando! Valeu, Thiago, está de parabéns!!
- Data: 01/09/2008 (PARABÉNS JAC!!!)
- Participantes: Thiago, Yoshi, Hugo, Mari, Jac e Breno
- Kata: Introdução a Haskell, pela Mari
- Código: http://groups.google.com/group/dojo_sp/web/49-haskell-intro.zip
Empolgada pelo Dojo de Paris, a Mari resolveu apresentar uma introdução básica à Haskell para que quando ela for apresentar o Kata de verdade não ficassemos totalmente perdidos, como já aconteceu.
Portanto ela apresentou Haskell “formalmente”, dizendo que é uma linguagem funcional e lazy. Em sequida explicou os termos para as pessoas que não os conheciam:
- “…funcional pois tudo é função…”
- “…lazy porque ela só calcula o que for necessário quando for necessário…”
Feito isto iniciamos a parte legal: Código!
Codando
Mostrando no interpretador de Haskell como fazemos “atribuições” em “variáveis” (entre aspas porque na linguagem não ocorrem atribuições e as variáveis não variam depois de definidas), depois como criamos uma função no próprio interpretador. Função esta que explicitava o fato de ser lazy.
Depois de sabermos o básico do básico de Haskell, iniciamos um “micro-problema”: Calcular um fatorial.
Para calcular o fatorial iniciamos o TDD, e com baby-steps aprendemos o pattern matching das funções, e como este recurso deixa fácil, rápido e compreensível o “cheating” de fazer passar MUITO rapidamente qualquer teste (colocando o valor esperado como valor de retorno de uma funcao que recebe exatamente os valores testados para ela). Este fato foi mais comentado na “Retrospectiva”. Juntamente com o pattern matching discutimos como o uso de “lembrança” (ou “cache” sem invalidar) em uma linguagem funcional e lazy pode ser algo extremamente útil e poderoso, já que uma vez calculado um valor, não precisamos recalculá-lo.
Além disso, com o fatorial funcionando entendemos como funcionam os tipos de variáveis, e como controlar o uso das funções com estes tipos. Aqui começou a abstração interessante e nada trivial sobre a linguagem. Terminada a parte do fatorial, entramos na parte de estrutura de dados: Como calcular a soma dos elementos de uma lista.
Assim vimos novamente a combinação “pattern macthing de funções + recursão”, além de entender como controlar os elementos da lista com funções de primeiro, e resto da lista, além do “mágico” pattern macthing da lista, separando facilmente os elementos da lista.
E foi neste ponto que uma grande discussão próspera começou. Como usar a função ‘foldr’.
Para começar, a Mari mostrou o tipo da função. O que depois provou-se um GIANT-Step, pois consigo trouxe a idéia da função Lambda, ‘+’ como sendo uma função binária com “bagunça” nos parâmetros, como podemos usar o “mais” de mais de uma maneira, e assim o caos se perpetuou, já que pouquíssimas pessoas continuavam entendendo. Mas graças à paciência de Hugo e Mari tudo se resolveu rapidamente.
Começaram explicando como funciona (não o que é de verdade) uma função lambda, e como todos parâmetros de uma função se tornam no final uma função Lambda, e com várias chamadas de funções obscuras resultamos na funçao desejada.
Depois de claro como era o tipo e para que serve o ‘foldr’, vimos como esta é uma ferramenta poderosa e muito útil na iteração de listas.
Em seguida a Mari continuou mostrando o map e o filter. e assim percebemos o baby-step invertido… Já que estas últimas funções foram rapidamente compreendidas.
Neste ponto a Pizza chegou!
Retrospectiva
Como de praxe, para “atazanar” um certo membro do Dojo, fizemos retrospectiva COM comida… ^^
Aqui entendemos muito bem (mas não completamente) o conceito da Função Lambda e quão dificil é compreendê-la de fato. Para esta explicação o Hugo mostrou um Jogo apresentado na Agile 2008 para entender como funcionam as funções em Haskell.
Depois de um bom tempo desenhando na lousa e depois que todos tinham compreendido os conceitos, partimos para o outor assunto interessante: Roubando para o teste passar rápido.
Para fazer isto, podemos usar if’s e else’s para retornar logo de cara o valor esperado, ou simples e elegantemente usar o pattern macthing das funções. Esta tática foi motrada aos nossos “intercambistas” no dojo de Paris.
Lá eles fazem com que o teste passe extremamente rápido, assim tudo que mexe na estrutura e otimização do código, incluindo aqui algoritmos desconhecidos, faz parte da refatoração. Percebemos que é bom treinar deste modo, pois nossa refatoração só causa um efeito “estético” no código, quase nunca alterando o método de resolução do problema.
Assim ficou decidido que iremos tentar de vez em quando usar esta técnica “apelona”.
Depois de falarmos muito e de barriga cheia, cada um tomou seu rumo e assim terminou nosso dojo de número aproximadamente igual a 49.
22.08.08
Dojo Férias 2 - Sunny Mountains
Relato escrito pela Jac - finalmente vamos saber um pouco do que aconteceu nas férias! Valeu, Jac!
- Data: 14/07/2008
- Participantes: Fabs, Yoshi, Tiago, Paulo, R, Adolfo, Jac
- Randori: Sunny Mountains, em Erlang com Eunit
- Código fonte: http://groups.google.com/group/dojo_sp/web/erlang-1407.tar.gz
Escolhemos repetir o mesmo problema da reunião anterior, devido ao desafio e as dificuldades enfrentadas com os cálculos matemáticos (regras de 3 avançadas!).
Tiramos a carta “Change Its Name” que alertava sobre a escolha das palavras para o encaminhamento da solução. Não sei se a carta teve muita relevância para chegar na solução mas com certeza a mudança do approach foi muito importante para conseguirmos terminar o problema.
Antes de iniciarmos, discutimos mais detalhadamente o problema, fizemos alguns desenhos na lousa para esclarecer e rever os pontos de dificuldade e uma pessoa ficou responsável pelos cálculos matemáticos, que foi realmente importante para que o grupos pudesse prestar mais atenção ao código que estava sendo escrito.
No final do problema fizemos um teste de aceitação com os valores que estavam no site mas não conseguimos a correspondência de resultados pois o problema não seguia estritamente o enunciado no qual as montanhas eram iluminadas à leste pelo sol enquanto no nosso problema as montanhas eram iluminadas à oeste, o que alterava a soma das áreas iluminadas das montanhas.
Apesar disso, as pessoas ficaram bastante satisfeitas por terminar o problema.
Retrospectiva
Coisas Legais:
- A discussão do approach antes de começar o problema foi importante para chegar na solução
- O stick to it do tempo foi importante para que todos pudessem codar
- As pessoas estão progredindo no aprendizado de Erlang
- Todos gostaram de terminar um problema
- Tivemos mais pessoas presentes
- As pessoas estão compreendendo melhor os baby steps
Curiosidades de sintaxes - IF:
if
Guard1 ->
Sequence1 ;
Guard2 ->
Sequence2 ;
...
end
Coisas não legais:
- Faltou guru para erlang
- Problema ao seguir regras do enunciado
- Não conseguimos rodar o teste de aceitação
- Característica de paralelismo da linguagem foi pouco explorada
- Faltaram problemas distribuídos
- O problema foi resolvido mas não de acordo com o enunciado, não sendo possível rodar o teste de aceitação do site.
Parking Lot:
- Horário de término do dojo => Estamos terminando muito tarde!
20.08.08
Dojo 47 - Jaspion! e a Maratona de Programação
- Data: 18/08/2008
- Participantes: Jac, Adolfo, Thiago, Mari, Breno, Hugo, Paulo, Yoshi e Gustavo
- Randori: Problema K (Jaspion) da seletiva do IME para a Maratona de Programação
- Código fonte: http://dojo_sp.googlegroups.com/web/47-JASPION.zip
No dia anterior ao Dojo, domingo, aconteceu no IME a seletiva para a Maratona de Programação. Para quem não conhece, é uma prova muito divertida que ocorre todo ano, na qual equipes de no máximo 3 pessoas têm por volta de 5 horas para resolver uma série de problemas. Como 4 dos 9 que apareceram no Dojo segunda participaram dessa prova, eles sugeriram um dos problemas da prova, que acabou sendo escolhido para resolvermos.
Após explicar o problema, votamos também na linguagem a ser utilizada, entre um monte de opções (talvez opções demais) - desde Perl até Smalltalk. A escolhida pela galera foi Java, uma das linguagens que pode ser utilizada na maratona (as outras são C e C++).
O Problema
Resumindo a historinha de 2 parágrafos que introduz o problema (infelizmente não tem uma versão online da prova), o objetivo é traduzir letras de músicas em japonês para o português, usando um dicionário de palavras em japonês para expressões em português. O problema parecia fácil, apesar de durante a prova de domingo poucos grupos terem conseguido sucesso na solução. Isso só aumentou a vontade do pessoal do Dojo de terminar a implementação, inclusive com leitura da entrada!
A entrada consistia do seguinte formato: primeiro um número T de instâncias a serem processadas. Depois, cada instância começa com dois inteiros M e N indicando respectivamente o número de palavras no dicionário e o número de linhas da música. A seguir, são dados M pares de linhas, sendo a primeira linha do par uma palavra em japonês (sem espaços) e a segunda, uma expressão em português (podendo ter espaços). Depois disso, vinham as N linhas da música. Uma observação importante é que, se uma palavra da música não estivesse no dicionário, ela deveria ser deixada sem tradução, isto é, copiada exatamente para a saída. Por fim, todas as palavras tanto do dicionário quanto da música consistem apenas de letras minúsculas.
Por exemplo…
Para a entrada:
1
1 1
oi
tchau pessoal
oi do dojo oi
A saída esperada é:
tchau pessoal do dojo tchau pessoal
A Solução
Assim que começamos, percebemos que o problema de fato parecia fácil. Terminamos rapidamente a parte de tradução, que é o centro do problema. Restava apenas a leitura de entrada, e partimos para isso.
Para não ter que lidar de fato com leitura de entrada, o que não é desejado em testes unitários, fizemos um mock bem simples de InputStream, tornando-o capaz de fornecer a entrada desejada para o código. Com esse mock, conseguimos ler as duplas de palavras que formam o dicionário, mas paramos por aí pois o tempo já tinha acabado.
Retrospectiva
A retrospectiva foi repleta de coisas boas (como o fato de o Hugo e a Mari - eu!! - estarem de volta, e de termos bastante gente) e discussões interessantes.
Como pontos positivos:
- O texto do problema, que recebemos durante a prova no dia anterior, estava circulando entre a platéia. Isso facilitou resolver dúvidas que alguém tivesse de forma rápida e sem interromper o par programando para ter que consultar o problema no navegador.
- Seguimos à risca a troca de pares, dando um bom ritmo ao código, mas fizemos algumas pausas (do cronômetro mesmo) pra explicar em pontos quando a maioria ficava perdido (por exemplo pra explicar o mock). Mal podemos esperar pela nossa ampulheta!!!
Além disso, vários pontos foram considerados como algo bom e ruim ao mesmo tempo! As discussões interessantes que tivemos foram:
+ Votar na linguagem foi muito bom, pois não queremos mais ficar presos a uma linguagem apenas durante um tempão…
– Por outro lado, a maneira como fizemos nesse Dojo demorou, roubou do nosso tempo valioso para fazer o que é mais divertido, que é codar…
!! Então sugerimos de escolher a linguagem ao mesmo tempo do problema, ou seja, ao sugerir um problema já sugerimos a linguagem a ser utilizada. Podemos algumas vezes sugerir o mesmo problema em duas linguagens, mas sem exagerar no número de opções. Assim, podemos variar de linguagem fazendo apenas uma votação.
+ A sessão foi bem calma e tivemos silêncio no vermelho, o que é raro…
– Mas algumas pessoas não gostaram disso, acharam que faltou animação e disseram que dava para ouvir o barulho do projetor…
? Será que devemos pedir pro Fabs não faltar mais?
+ O problema era interessante e factível, e o tempo rendeu bem…
– Mas mesmo assim não terminamos, apesar de chegar muito perto, e ficamos todos curiosos para saber se a nossa solução passaria ou não nos testes do juiz.
+ Aprendemos um jeito rápido e fácil de fazer um mock…
– Porém, alguns acharam esse jeito muito, muito feio!!
? Seria interessante vermos algumas bibliotecas de mock no Dojo?
+ Java foi considerada uma boa escolha para o problema, e as pessoas ficaram felizes de usar o Eclipse…
– Porém constatamos que leitura de entrada em Java ainda é muito ruim! E além disso, algumas pessoas não estão confortáveis com a linguagem e sentiram que isso atrapalhou o entendimento e fluxo do Dojo
? Será que a falta de fluência é um problema? A maioria concordou que aprender e treinar novas linguagens faz parte dos objetivos de vir ao Dojo, e que as dúvidas devem ser resolvidas conforme elas acontecem.
Por fim, falamos dos itens no Parking Lot (aliás muito bem utilizado, passando itens da retrospectiva para o Parking Lot se percebíamos que tinha mais coisa a conversar a respeito):
- “Como testar o armazenamento de dados por um objeto sem ter de conhecer a implementação de uma ED interna a ele?”
Por exemplo, nosso objeto deveria armazenar um par de uma palavra em japonês e uma expressão em português, como um mapa ou dicionário. Porém, para efeitos de testes, queríamos que a forma de armazenar isso fosse invisível. Então, como testar o método de armazenamento se a única coisa que ele faz é interna e não podemos enxergar? Ou seja, ele produz um efeito colateral, e concluímos que a única maneira de testá-lo seria através de outro método da classe, por exemplo um método que diz se uma determinada palavra está no dicionário. Se trata de um teste caixa preta. - “Sugestão: pausa no meio”
Seguindo práticas aprendidas com o pessoal do Dojo Paris e na Agile 2008, eu sugeri essa prática de fazer uma pausa no meio da sessão para discutir se tivemos dúvidas até o momento, discutir o rumo que a solução está tomando e se queremos mudá-lo. O pessoal topou tentar, ressaltando que acham que a pausa só deve ser feita se alguém tiver dúvida ou algum problema com o rumo das coisas - ou seja, não queremos parar só por parar. - “Usar controle de versão Git do Dojo”
Outra idéia que veio de fora é de, durante a sessão do Dojo, fazer commits regulares para um repositório de controle de versões, como o repositório Git que já temos. Com isso, os passos tomados durante o Randori ficariam automaticamente salvos e além disso não seria mais necessário subir o código final para nosso espaço no Google Groups. - Por fim, eu reclamei que não tivemos nenhum post das reuniões de julho (e se alguém lê esse blog, deve ter reclamado também), e perguntei pro pessoal se eles tinham idéia de alguma outra maneira para capturar o relato das nossas reuniões. Isso casou razoavelmente bem com a idéia anterior, do repositório, dado que podemos usar um arquivo para comentários ou até a própria mensagem em cada commit para “gravar” como foi a reunião. Assim, o trabalho do escriba ficaria consideravelmente menor (será?), precisando apenas juntar esses comentários e passar os principais pontos da retrospectiva para cá.