22.06.08
Posted in Dojo, DojoSabado, Erlang
at 11:37 pm
by adolfo
Como tínhamos uma nova participante, a sessão começou com a apresentação do Dojo. Logo depois, o Fabs deu uma introdução sobre Erlang, a linguagem com a qual estamos realizando os Dojos de sábado. Em seguida, sorteamos a carta da criatividade e deu “Put a lion in your heart”. Passadas as formalidades iniciais, escolhemos um problema: calcular o produto escalar entre 2 vetores. É um problema simples, porém foi muito bom para praticarmos a linguagem ainda nova para nós, TDD, passos de bebê e outras coisas legais que fazemos no Dojo.
Vamos ao problema: dados dois vetores (V1 e V2), deveríamos calcular o produto escalar entre eles, ou seja:
V1 = (a, b, c)
V2 = (a´, b´, c´)
V1 . V2 = a . a´ + b . b´ + c . c´
Discutimos um pouco e fomos logo à prática. Durante a sessão, as interrupções no vermelho foram freqüentes e bem-vindas. Precisamos disso para que o Fabs, quando estivesse na platéia, pudesse tirar as nossas dúvidas a respeito da linguagem. A sessão fluiu muito bem assim, até que chegamos a um código que resolvia o nosso problema. Ficamos tão empolgados que passamos a brincar de escrever testes com vetores diferentes só pra ver passar.
Com uns 30 minutos para a chegada da retrospectiva, resolvemos mudar a implementação para fazer os cálculos de forma distribuída. A nossa intenção era criar uma árvore binária, de modo que as folhas realizassem a multiplicação de 2 elementos dos vetores de entrada, a raiz de cada subárvore fizesse a soma das suas folhas e a raiz da árvore somasse os seus filhos. Acho que uma imagem pode ajudar:
Desta forma, as multiplicações das folhas da árvore poderiam ser feitas por processos diferentes e, enfim, testaríamos o processamento distribuído, característico de Erlang. Começamos o trabalho mas não fomos muito longe pois era hora da retrospectiva.
Retrospectiva
Coisas Legais:
- Atingimos mais do que o esperado. O nosso código “ProdutoEscalarChain” resolveu o problema
- Codamos bastante (estávamos em 3 pessoas somente)
- O problema simples permitiu que aprendessemos bastantes coisas de Erlang
- Gente nova no Dojo
- O bloco “receive … end” do Erlang
- A analogia que o Fabs fez entre Classes e Mensagens
- O Fabs explica bem
Coisas não legais:
- Pouca gente nesta sessão
- Erlang tem uma sintaxe estranha
- Ter que fazer vários “receive … end” para receber o retorno de mais de 1 spawn (pode ser que a linguagem permita manipular o retorno de mais de 1 spawn em um único “receive … end”. Precisamos estudar mais a linguagem para utilizar melhor os seus recursos)
- A letra do Fabs é feia (ele mesmo quem escreveu isso)
Ainda deu tempo de discutirmos um pouco do porquê do Dojo ter fluido tão bem neste sábado. Com certeza, o número reduzido de pessoas ajudou. É um desafio nosso encontrar uma maneira de manter a fluidez e produtividade em sessões com mais gente.
Por fim, o Fabs ficou de disponibilizar o PDF da primeira parte do livro de Erlang, o que ele já fez. O arquivo pode ser baixado do grupo ou diretamente de http://www.erlang.org/download/erlang-book-part1.pdf
Permalink
18.06.08
Posted in C, Dojo
at 6:12 pm
by marivb
Esse relato foi escrito pelo Yoshi, estreando como escriba no blog. Legal!!
Tiramos a carta “Venda seu peixe”. Nada mais próprio para um dia onde, numa situação inédita, os problemas eram exatamente os mesmo do dojo anterior, mas com um porém: Se repetísse-mos “Overlapping areas”, continuaríamos do ponto que paramos – para melhor ou para pior. E isso só seria possível por que todos os presentes estavam… Presentes na sessão anterior.
Eram então os problemas: Eternal Truths, Water Flow e Overlapping Areas.
O Yoshi resolveu abraçar a causa da carta e vender a idéia de, finalmente, terminar um problema no Dojo. Como isso, sugeriu Water Flow – incontestavelmente o problema para a situação.
Aberta a votação, ficou evidente que ninguém estava interessado em procurar pela verdade eterna nos labirintos sagrados. A votação então ficou empatada, aguardando o voto da Mari para a decisão. Visivelmente o Yoshi vendeu seu peixe, uma vez que o empate só se deu por que ele traiu seus persuadidos e votou no outro problema, após ser persuadido pelo Thiago a votar no Retorno de “Overlapping Areas”. (Pode isso? Vai entender…) Frente a esse quadro, a Mari resolveu por escolher um outro inédito: repetir um problema no dojo. (Teria ela também sido persuadida pelo Thiago? Ou pelo Yoshi, que virou a casaca dele mesmo? Enfim…)
Como o problema era conhecido, buscamos sua ToDo-List para recomeçar. Lembrávamos de um problema com o qsort, mas não estava claro qual. Como os testes feitos na sessão anterior passaram prontamente, pareceu que estava tudo sobre controle… Ledo engano.
Nosso novo alegre Dojo Unit, agora colorido, não estava com um assert_same funcional. Percebemos isso quando ele disse ok para um teste que… Não estava ok. Demos um svn revert nele e migramos para o velho e sóbrio dojo unit do dojo 40.
Superados os problemas de recomeçar, logo nos deparamos novamente com o estranho problema do quicksort, e este foi resolvido. Moral da hstória? Macros são úteis, mas… COLOQUE PARÊNTESES! Avançamos mais um pouco no problema: começamos a criar os eventos em X para verificar quais retângulos cruzam a linha de varredura. Com isso, ao soar o gongo para nossa retrospectiva, nosso ToDo-List ficou assim:
- Estrutura de Dados para armazenar os retâgulos
- Ordenar os retângulos pelo eixo x (varrer coordenadas ‘x’ dos retângulos)
- Guardar os retângulos que cruzam a linha de varredura
- Calcular quantos retângulos interessam e guardar o máximo.
- Calcular a área
Retrospectiva
Coisas Legais:
- O algoritmo Scanline, apesar de sua complexidade, despertou o interesse de muitos.
- Continuar o problema também teve uma unisitada popularidade.
- Dojo Unit colorido ficou mó legal!
- O quick sort e seus ponteiros tambem tiveram seu destaque, tanto pela notação quanto pelo seu funcionamento.
- Macros são legais, mas… USE PARENTESES!
- Alternativa simples para listas ligadas com alocação dinâmica de data ***vetor
Coisas não legais:
- Retomar do ponto de parada não é fácil
- Mesmo retomando, não terminamos
- Dojo Unit colorido estava bonitinho, mas ainda não pudemos usa-lo
- Estrutura de dados do scanline é complexa
- Ainda não sabemos testar malloc e free…
- Fim de semestre: muito cansaço e poucas pessoas
Durante a (espera pela) pizza, discutimos algumas coisinhas:
Por que não usar o == ao invés de assert_same? Infelizmente não estamos em C++ e, portanto não podemos sobrecarregar o operador. Um uso ingênuo de == não compararia toda a estrutura e, portanto, não daria o resultado esperado…
Para aproveitar melhor o parking lot, devemos distribuir os postits brancos no começo. Assim podermos anotar as dúvidas on-line e não deixar nada de lado!
Permalink
Posted in DojoSabado, Erlang
at 5:54 pm
by marivb
- Data: 07/Junho/2008
- Participantes: Bruno, Fabricio, Helio, Lucas, Cecilia, Mariana e Hugo
- Kata/Randori: Números de Fibonacci e Produto escalar, em Erlang com EUnit
- Código Fonte: http://dojo_sp.googlegroups.com/web/01SAB-introErlang.tar.gz
- Fotos: http://picasaweb.google.com/fabriciosn/DojoSBado07062008
Na primeira edição do Dojo de sábado, apenas o Fabrício tinha explorado uma linguagem desconhecida, o Erlang. Ele não tinha um Kata pronto, mas propôs apresentar o que sabia sobre a linguagem. Começamos bem simples, resolvendo o problema de calcular números de Fibonacci. Vimos um pouco de sintaxe, o básico da biblioteca de testes, como rodar os programas, como definir funções, entre outras coisas.
A seguir, pedimos por um exemplo mais complexo – que usasse algo listas, algum condicional ou até troca de mensagens. Então Fabricio apresentou uma versão bem simples do produto escalar entre vetores, usando listas e troca de mensagens entre processos. A implementação foi linear, e o grupo queria tentar uma abordagem pelo menos um pouco mais concorrente.
Discutimos um pouco as alternativas, e esboçamos a “árvore de execução” que a gente queria atingir. Na parte final do Dojo, mudamos para o formato Randori para tentar implementar uma solução na abordagem sugerida. Mas antes de terminarmos o problema, terminou o tempo, e partimos pra retrospectiva.
Retrospectiva
O que foi bom:
- Alguém estudou uma linguagem nova, e apesar de não ser um Kata completo. Talvez por isso, notamos que Dojo com Erlang fluiu melhor que com Lua
- O paradigma de Erlang é muito diferente de tudo que já usamos no Dojo anteriormente. É mais funcional e mais orientado a programas paralelos. Aprendemos um pouco sobre ambos os conceitos ao experimentar a linguagem.
- O formato Kata + Randori funcionou bem para uma primeira exploração da linguagem.
- Tinha um bom número de pessoas (Dojo de sábado não foi um fracasso )
Além disso, aprendemos:
O que atrapalhou:
- Várias pessoas estavam com sono (sábado de manhã é difícil…
)
- Pouco conhecimento da linguagem atrapalha um pouco – não entendemos os motivos de erros, e não entendemos por que falhou o último teste
- Formato de exploração é estranho – em alguns momentos não sabíamos o que fazer a seguir
- Erlang nos parece estranha
Parking lot:
São dúvidas que ficaram em aberto, sugestões para reuniões futuras, etc:
- Como rodar os programas de maneira concorrente? Como preparar um ambiente de execução?
- Encontrar problemas para resolver com concorrência / problemas paralelizáveis
- Idéia de problema: chat em Erlang
- Dá pra receber mensagens em qualquer ordem?
Permalink
07.06.08
Posted in C, Dojo
at 11:10 pm
by adolfo
- Data: 04/06/2008
- Participantes: Thiago, Mari, Hugo, Yoshi, Breno e Adolfo
- Randori: Overlapping Areas em C, com o Dojo Unit Test
A sessão começou com o sorteio da carta “Have Something at Stake”. Depois da leitura da carta e de uma breve história de pescadores contada pelo Yoshi (embora tudo leve a crer, acho que não era mentira), fomos à tradicional votação. Os 7 votos do Eternal Truths e os 3 do Water Flow não foram suficientes para vencer os 8 votos do Overlapping Areas. Escolhido o predador pro nosso aquário, começamos a discutir o problema.
A encrenca consiste, resumidamente, em determinar a soma das áreas das regiões em que há maior sobreposição de retângulos. No exemplo acima, teríamos que somar a área batizada de “E3″ com a “G3″.
A nossa discussão foi mais longa do que as que temos usualmente. O Yoshi surgiu com uma boa idéia para resolvermos o problema. Depois de algumas explicações e um debate, a Mari nos explicou um algoritmo, usado no Archimedes, que chamamos de “Scan Line”. Misturamos as idéias do Yoshi, o algoritmo da Mari, os pitacos de todo mundo e conseguimos a nossa lista de atividades para serem feitas:
ToDo List:
- Estrutura de Dados para armazenar os retâgulos
- Ordenar os retângulos pelo eixo x (varrer coordenadas ‘x’ dos retângulos)
- Guardar os retângulos que cruzam a linha de varredura
- Calcular quantos retângulos interessam e guardar o máximo.
- Calcular a área
Hora de codar: começamos a implementar o que havíamos discutido e as idéias e observações interessantes não pararam de se manifestar. O andamento das coisas estava tão envolvente que quase não percebemos a chegada da retrospectiva.
Retrospectiva (em resumo)
O que podemos melhorar?
- O problema era longo. Só conseguimos chegar ao segundo item da nossa lista de atividades e, ainda assim, não foi possível resolver um problema com a função QSort.
- Gastamos muito tempo na discussão do problema e tivemos pouco tempo para codar (embora tenhamos conseguido fazer o rodízio de todos os participantes).
- Um teste falhando deixou todo mundo com uma pulga atrás da orelha. Todos estávamos curiosos para entender o comportamento inesperado quando o gongo da retrospectiva tocou.
- Precisamos ser mais pontuais. A sessão começou às 20:20, quando deveria ter sido iniciada às 20:00.
O que foi legal?
- Muitas pessoas gostaram do problema. Tecemos elogios às discussões surgidas, aos desenhos e à dinâmica que a sessão teve com um problema diferente. Nos divertimos.
- A Dojo Unit não dá mais problema de make. A nossa biblioteca de testes está ficando bem legal.
- A sessão foi dinâmica, estamos percebendo que está ficando mais rápido de codar (os 7 minutos estão sendo respeitados)
- Gostamos de aprender a respeito do “Scan Line”
- Elogios à função QSort do C
- Bastantes pessoas, o que significa que o Dojo de quarta continua. Esta discussão surgiu por conta do Dojo que agora também acontece aos sábados.
- SSH not so safe no Debian
Encafifamentos
Durante a pizza, discutimos alguns assuntos:
- Não devemos fazer testes para evitar erros conhecidos? Em alguns momentos forçamos o teste. Qual o seu propósito? Os testes pegam erros não previstos.
- Conversamos sobre a Dojo Unit, que agora está com as features implementadas pelo Hugo.
- Novamente falamos a respeito da questão “terminar a resolução do problema ou focar nas discussões, na melhor implementação, nas práticas do Dojo, etc”.
- Por fim, falamos um pouco sobre as diferenças entre TDD e BDD.
Bom, depois desta sessão empolgante, acho que podemos dizer que o predador no aquário realmente aumentou a nossa motivação. Até a próxima, portanto!!!
Permalink
