17.09.08
Posted in Dojo, Haskell
at 3:18 pm
by rbp
- 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: no repositório do dojo no github.
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!
Permalink
14.09.08
Posted in Dojo, Haskell
at 10:32 pm
by adolfo
- 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.
Permalink
05.09.08
Posted in Dojo, Haskell
at 11:27 am
by marivb
Relato escrito pelo Thiago – escreveu rápido e bem, quase dá pra ouvir ele falando! Valeu, Thiago, está de parabéns!!
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.
Permalink
