11.11.08
Posted in Dojo, Haskell, Kata
at 7:39 am
by flores
- Data: 10/11/2008, no IME – USP
- Participantes: Pedro, Thiago, Hugo, Jorge, R, Flores, Fabs, Mari, Marcelo, Bruno Gola, Renato, Carlos e Ricardo.
- Kata: Blocks por Mari
- Carta da Criatividade: Experimente uma idéia aleatória.
- Código: Estará disponível em breve.
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”.
Permalink
25.04.08
Posted in DojoTarde, SmallTalk
at 3:06 pm
by flores
Participantes: Hugo, Mari, Flores, Breno
Problema: The Next Palindrome
Linguagem: Smalltalk
Ambiente: Squeak
Fonte: dojotarde04-palin
Por termos resolvido um problema muito fácil no Dojo anterior, resolvemos pegar um problema um pouco mais difícil.
Ao invés de criar uma classe com a implementação do Next Palindrome, o Hugo sugeriu criarmos um método NextPalindrome na classe de inteiros de Small Talk. O que no fim das contas se mostrou ser algo legal: nunca haviamos feito nada deste tipo em algum outro Dojo Tarde.
Uma estratégia sugerida pelo Hugo para resolvermos o problema foi irmos comparando os dígitos a partir da metade com seu correspondente e ir montando o próximo palíndromo.
Inicialmente começamos tratando os casos para um dígito: para números de 1 a 8 é trivial pois o próximo palíndromo é o próximo número. Prosseguindo: tentamos fazer o caso do 9, com resposta esperada 11, mas infelizmente sentimos que qualquer solução, mesmo não tão elegante, talvez precisasse de mais código. Colocamos então esse teste no Expected Failures e continuamos nossa programação para tratar os casos de dois dígitos. Decidimos converter o número para string, para assim acessar mais facilmente cada dígito. Para a solução de dois dígitos, utilizamos a idéia de que o próximo palíndromo seria o próximo múltiplo de 11 a partir do número. Para três dígitos, tentamos implementar o algoritmo pensado anteriormente tratando primeiro os casos que só necessitávamos mexer no número do meio (como 808), mas acabou nosso tempo de programação.
Achamos um “bug” no test Runner do Squeak: quando temos uma Expected Failure, um código sem “Failures” fica com cor amarela no Test Runner, enquanto um código com “Failures” fica com cor verde.
Coisas Boas: Implementação de Mensagem em classe “raíz”+, SmallTalk++, digitAt, Method Finder, raisedTo, Blog, “121 at: 2″.
Coisas Ruins: Pouca Gente++, Test Runner Bugado+++, Falta de Precedência Confunde, Sono++, Controlar o tempo com o celular é ruim, Fugimos do Algoritmo (?), Fugimos do Baby Step(?), Problema não tão complicado mas não terminamos, código feio, “String at: 2 asString asInteger”++.
A se pensar: Como trazer mais gente? Utilizar algoritmos já conhecidos de primeira ou ir construindo o algoritmo aos poucos?
Permalink
10.04.08
Posted in DojoTarde, SmallTalk
at 2:55 pm
by flores
Participantes: Hugo, Mari, Flores, Mário
Problema: Tex Quotes
Linguagem: Smalltalk
Ambiente: Squeak
Fonte: dojotarde03-texquotes1
Como estávamos preocupados pelo fato de não estarmos conseguindo resolver problemas simples no Dojo Tarde, escolhemos um problema bem simples.
O principal desafio foi como resolver um problema inicialmente de programação procedural utilizando SmallTalk e conseqüentemente orientação a objeto.
Primeiramente, fizemos métodos que trocavam ” por “ ou ´´ dependendo de uma variável booleana denominada aspasAbertas. O Hugo, para deixar o problema mais orientado a objeto, sugeriu fazermos um substituidor esquerdo e um substituidor direito para substituir as aspas dependendo do caso. Em uma refatoração, foi sugerido que as duas classes de substituidor (direito e esquerdo) herdarem de uma classe substituidor. Também tivemos que aprender como funciona o escape de caracteres em Smalltalk.
Como estávamos tratando caracteres simples como strings, ao tentarmos fazer o teste da validação que quebrava uma string em caracteres, tivemos que passar os caracteres como string.
Coisas boas/aprendizados: Smalltalk, Orientação a Objeto, Polimorfismo, Herança, Terminamos um Problema, Tempo compatível, caracter a pode ser escrito como $a.
Coisas ruins: Pouca gente (3x), tela do Mac escurecendo, Responsabilidade Concentrada (escriba, encarregado do projetor, “abridor” de sala, moderador).
Coisas a se pensar: Como atrair mais gente ?, Kata no próximo Dojo!
Semana que vem tem Dojo no FISL!
Permalink
