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 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
07.10.08
Posted in Dojo, Haskell
at 11:19 am
by marivb
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.
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
22.08.08
Posted in DojoSabado, Erlang
at 12:30 pm
by marivb
Relato escrito pela Jac – finalmente vamos saber um pouco do que aconteceu nas férias! Valeu, Jac!
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!
Permalink
20.08.08
Posted in Dojo, Java
at 5:08 pm
by marivb
- 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á.
Permalink
02.07.08
Posted in DojoSabado, Erlang
at 5:14 am
by marivb
Post escrito pela Jac, contribuindo como escriba pela primeira vez!
- Data: 21/06/2008
- Participantes: Hugo, Jac, Fabs, Lucas
- Randori: Produto escalar entre 2 vetores, em Erlang com Eunit
- Código fonte: http://dojo_sp.googlegroups.com/web/03SAB-ProdutoEscalarTree.tar.gz
- Fotos: http://picasaweb.google.com/fabriciosn/DojoSabado2106
Como era a primeira participação da Jac no Dojo de sábado o Fabs fez uma introdução sobre Erlang, a linguagem que esta sendo utilizada no Dojo. Depois sorteamos a carta de criatividade “Conform”, discutiusse que a idéia não era ficar conformado, mas agir de acordo, conforme o combinado.
Os problemas propostos foram multiplicação de matrizes e produto escalar.
A idéia inicial era tentar implementar a multiplicação de matrizes, mas como a linguagem não era muito conhecida pelos participantes, o problema de produto escalar foi votado para ser resolvido novamente.
Foi implementada a ideia discutida no último dojo, criar uma árvore binária em que as folhas realizassem a multiplicação de 2 elementos dos vetores de entrada e a cada raiz de uma subarvore soma-se suas folhas e a raiz da árvore somasse os seus filhos.
Retrospectiva
Coisas Legais:
- As pessoas gostaram de resolver o problema utilizando a característica de paralelismo da linguagem
- Há interessados em entender e explorar um pouco mais a característica de paralelismo da linguagem
- Descobrimos que a biblioteca já possuia uma implementação de lista e utilizamos o
split da biblioteca
- As pessoas gostaram de utilizar inlined receives
- O problema foi resolvido com folga de horário
Curiosidades de sintaxes:
- lists: -> importar lib de lista
- round -> arredondamento
- split -> importar lib de lista
Coisas não legais:
If apresenta uma sintaxe estranha- Não soubemos fazer divisão inteira e tivemos que utilizar o round
- Tivemos pouca gente
- Como acabamos cedo podiamos ter feio mais coisas, mas paramos de codar
- O dojo começou atrasado
- Alguns acham que o poderiamos começar um pouco mais tarde
- Não se sabe onde vão parar os erros do spawn
Parking Lot:
- Como rodar o programa em várias máquinas?
- Como realizar uma divisão inteira?
- Porque aparece um erro de crash dump e o programa roda?
- Os testes são escritos por macros. Como resolver este problema para utilizarmos variáveis?
?_assert: Porque o teste inicia com ?- Discutiu-se a diferença entre [A,B] e {A,B}
- Verificar a ordem de chegada das mensagens, com o disparo de processos que demandem tempos aleatórios
- Idéias de problemas: WebServer e Celular
Permalink
