19.10.08

UberDojo02 no Coding Dojo 55

Posted in Haskell, Ruby, UberDojo at 9:48 am by hugo

Na última segunda-feira rolou a edição número 55 do Coding Dojo. Ela foi, em muitos sentidos, especial. Para começar, o Danilo Sato estava presente acompanhado de um colega da Toughtworks, George Malamidis. Além disso, o dojo não foi realizado no IME/USP e sim na casa do Thiago Colucci (que fica “perto” da USP). Por fim, o dojo foi feito no formato UberDojo que vou explicar a seguir.

Usamos duas mesas que representaram duas linguagens (Haskell e Ruby) e cada lado da mesa representou um problema (Bank OCR e Minesweeper). Tivemos então 4 notebooks nos quais 4 pares codaram ao mesmo tempo. Tivemos turnos de 7 minutos como sempre e, ao término do turno, o co-piloto virava piloto, o piloto ia para a “platéia” e alguém da platéia virava co-piloto. Isso era feito tentando evitar que as duplas se repetissem e que as pessoas caissem no mesmo conjunto problema/linguagem muito freqüentemente. Fizemos isso durante pouco mais de uma hora e estávamos em 10 pessoas da velha guarda (Danilo, Thiago além de Fabricio, Jacqueline, Yoshi, Mariana, Breno, Adolfo e eu) e 4 novatos (George, Renato Willi, Bruno Pedroso e Rafael Schouery). Assim sempre sobravam 6 pessoas não programando para fazer as pizzas que acompanharam (Yoshi, Breno e Jac principalmente cuidaram disso, valeu!) e aprender um pouco vendo os outros programarem.

Demoramos um bocado para escolher os problemas e linguagens assim como para configurar o ambiente inicial nas quatro máquinas para que eles ficassem fáceis de usar para todos. Os turnos foram muito intensos e a galera estava em animada e falando alto procurando ajuda do pessoal que estava livre. Rolou uma boa troca de conhecimentos apesar de não ter tido o telão. O pessoal se divertiu bastante inclusive os novatos que agüentaram muito bem o tranco apesar de terem achado o tempo dos turnos muito curtos.

Em retrospectiva, percebemos que boa parte dos nossos problemas vieram da pressa para tentar dar passos grandes e não gastar um tempinho explicando ao novo co-piloto o que estava acontecendo e quais eram os próximos passos. Também concordamos que esse exercício requer participantes que já saibam bem trabalhar com TDD (Desenvolvimento Dirigido por Testes) e que, apesar de ser mais divertido e excitante que o dojo normal, não podemos manter esse formato em todas as sessões. Decidimos então que faríamos uma sessão desse tipo por mês. Também gostaríamos de ter feito uma retrospectiva mais adequada (ficou só na conversa a retrospectiva que fizemos).

Acho que é isso. Se tentarem isso, por favor, mandem-nos feedback a respeito.
Até o próximo dojo pessoal!

13.10.08

SuperDojo1 – Minesweeper

Posted in Ruby, UberDojo, python at 6:21 pm by adolfo

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

Posted in Dojo, Haskell at 5:02 pm by leo

Escolhemos um problema simples para, na verdade, aprender a ler da entrada padrão e escrever na saída padrão com Haskell.

Read the rest of this entry »

07.10.08

Dojo 52 – Trits original

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.

01.10.08

Dojo 45 (nas férias) – Whitespace

Posted in Dojo at 6:48 pm by breno

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