Dojo@IFF em Junho! Edições [11][12][13] e [14]

segunda-feira, 5 julho 2010

Começamos com o dojo aqui no IFF no final do ano passado. Tivemos férias, voltamos… E paramos por quase 2 meses! 😦

E a lista DojoRio crescendo, agitada, cheia de idéias, sempre interessante…

O tempo estava curto, ainda está muito curto. Mas enfim voltamos mesmo! Com vontade! \o//

Com o mesmo objetivo de nos divertir e aprender juntos! (admito, eu estava com saudades!)

No post anterior falei das edições antigas (que demoramos a relatar) e nesse vou falar das quatro últimas edições mais atuais -o último mês- e agora vamos manter os relatos Dojo@IFF semanais!

.

Dia 09-06-2010

Problema: Palavras Primas -> Código / Fotos

Fizemos o Dojo numa linguagem exclusiva (HÁ!).

Foi em Coral, uma adaptação do Python que o ‘traduz’ para português!

A galera toda curte escrever python e poder fazer isso no nosso idioma foi bem legal!
O Dojo foi show! A Coral não é usada ainda, então, colocá-la a prova foi bem interessante.
O bom de ter usado a Coral: encontramos alguns erros! rs Isso foi bom porque foi legal vê-los serem corrigidos e entender como os comandos python são sobrescritos por ela e saber um pouquinho de como ela foi criada (com a presença ilustre do criador da parada! Valeu, Gustavo).
.
O problema Palavras Primas foi um que o Mario Jorge Valle vinha pedindo há muitos Dojos (a parte engraçada: ele pede esse problema há vários Dojos e nem participou desse em que, afinal, decidimos fazer!).
O problema funciona assim: para descobrir se uma palavra era prima, nós tivemos que atribuir um valor para cada letra da palavra, seguindo a ordem alfabética (A=1; B=2; C=3 …) e depois verificar se a soma das letras era um número primo.
Um problema bem simples, mas que foi legal de ser desenvolvido pois a maioria da galera presente tava começando a programar há pouco e também a participar do Dojo, então todos puderam participar e opinar bastante (Bem no clima que a gente curte :D)
Concluí­mos o problema, com um pequeno ‘roubo’ do Gustavo no final (que ficou 2 tempos no teclado!)
.
Foi bem legal para o recomeço dos Dojos do IFF! E esperamos mais para os próximos e contamos com a galera toda para dar continuidade e frequência!
.
Retrospectiva:

Well, well
  • Usamos Coral (linguagem nova e exclusiva, mas isso também foi ruim!)
  • Todos participaram
  • Corrigimos bugs na linguagem
  • Resolvemos o problema

WTF?

  • Gustavo roubou no final
  • Usamos coral (ruim por causa dos bugs, mas isso também foi bom!)
  • O note que usamos tava dando uns bugs malucos
  • Atraso no início e no fim
Participantes:
Caio
Gustavo
Marianna
Rebeca

Ricardo

Dojo 09-06-2010

Participantes do IFF do dia 09-06-2010

.
Dia 16-06-2010

Problema: Happy Numbers -> Código / Fotos

Tivemos um problema muito interessante nesta quarta-fria-feira!
Por coincidência, pegamos o mesmo problema que o pessoal do Dojo@Niteroi pegou no dia seguinte, o Happy Numbers, trazido pelo RuhanFA.
.
Resolvemos com recursividade (cŕeditos aqui ao DouglasCamata que mandou bem nesse Dojo =D) e muita discussão em grupo sobre o problema!
Aprendemos algumas coisas legais do python (tinha malucos lá querendo usar reduces, lambdas, milhões de list comprehensions… rs)
Uma coisa legal nesse Dojo foi o uso da should-dsl para fazer as expectations, fazendo os testes ficarem mais bonitos e legíveis, como esse:
.
def test_felicidade_de_um(self):

Numero(1) |should| be_feliz

.

Retrospectiva

(7) = Happy

  • Problema legal =)
  • Muita gente
  • Clean Code
  • Discussão legal
  • Shoul-dsl
  • Hora extra com lanchinho \o

(2) = Unhappy

  • 2 pessoas não programaram
  • Falatório em momentos errado
  • Atraso no início e no fim

.

Participantes:

Caio
Douglas
Eduardo
Felipe

Rebeca
Ricardo
Rodrigo
Ruhan

Yasmim

Participantes do Dojo IFF de 16-06-2010

.

Dia 23-06-2010

Problema: Roleta Romana -> Código

Dia de brincar de Roleta Romana. Um outro problema bem legal trazido pelo RuhanFA.
A temática de ‘brincar de matar’ deixou os loucos presentes -me incluo aqui- bem animados e só saímos de lá as 21:30h!!! (meio psicopata isso… rs)
Ficamos um tempo analisando as entradas, definindo bem como seria a saída, o nome dos métodos e toda a estrutura do programa… Ok.
Ficamos tentando fazer com baby steps como manda o figurino, mas foram se formando ifs e mais ifs e então acabamos caindo na questão que sempre detona tudo: deixamos os baby steps pra lá e fomos tentar resolver tudo de uma vez. Vieram idéias de um jeito, de outro, de outro… E acabou que, devido a complexidade, acreditamos que chegamos a uma solução próxima a final, mas… Os testes feitos no Dojo acabaram  não passando! Mas mesmo que não terminados, assim eles estão postos no GitHub.
.
Eu acabei o Dojo intrigada e resolvi fazer os testes passarem…. Então, o código com os testes passando, está aqui (foi por pouco mesmo, como imaginávamos!).
.
Retrospectiva:

Vivo

  • Maneiras diferentes de resolver o mesmo problema
  • Problema desafiador
  • Respeitamos as regras de falar/não falar nas horas corretas
  • Bastante discussão sobre o problea
  • Extrapolamos muito! (1 hora!) o tempo

Morto

  • Ver um problema mais fácil para a próxima, que dê para usar baby steps
  • Pouca gente
  • Não usamos should-dsl
  • Sem #horaextra
  • Começou tarde de novo
  • Extrapolamos muito! o tempo
  • Algumas pessoas foram embora antes do fim do Dojo
  • Sem foto =(

Participantes:


Dia 30-06-2010

Problema: WaterFlow -> Código / Fotos

O último Dojo do mês foi um Dojo bem rápido, com poucas pessoas, mas não menos interessante por isso!!!
O problema abordado ‘WaterFlow’ foi trazido pelo Weslleymberg.
Resolvemos ficar com uma abordagem bem simples do problema, pois tinhamos hora marcada para terminar.
Até onde nos propusemos fazer, terminamos. E o que fizemos foi: Tinhamos como entrada a quantidade de agua presente em dois recipientes, e considerando que tinhamos um cano que os ligava, tinhamos também que entrar com o fluxo de água suportado pelo cano por segundo. A resolução do problema foi determinar, num tempo X, qual seria a situação dos dois recipientes de água.
.
Como ficou simples, tivemos a idéia de continuar o problema no próximo Dojo, uma vez que julgamos que não vai ser difícil para a galera que não participou desse acompanhar a continuação! A idéia é tratarmos de um número X qualquer de recipientes, com um número Y qualquer de canos interligando-os.
Foi legal pois como tinha pouca gente, deu para cada um pega no teclado várias vezes e facilitou que as regras fossem cumpridas. Também fizemos com baby steps e vai ser possível continuar no próximo Dojo sem perda da idéia de que todos os presentes estejam totalmente cientes do problema completo e sua resolução.
.
PS: Foi o Dojo com maior índice relativo de mulheres de todos os tempos: 50% (rs)
.
Retrospectiva:
Flui
  • Finalizamos o que nos propusemos do problema
  • Pouco atraso
  • Pouca gente! (foi bom isso!)
  • Todo mundo programou
  • Respeito as regras
Não fluiu
  • Namoro do Dojo (nem teve isso, mas mandaram eu registrar..)
  • Pouca gente! (isso é ruim também…)
  • Estamos de novo sem sala definida (Dojo nômade!)
  • Sala com cheiro ruim
  • #HoraExtra (na verdade… #MinutosExtras! :D)
Participantes:

.

Participantes do Dojo de 30-06-2010

.

Até a próxima semana! 😀

Anúncios

Dojo IFF [8] [9] e [10]

quinta-feira, 17 junho 2010

Eu voltei, agora pra ficar. Porque aqui, aqui é o meu lugar…”

Dojo sobre IFF

O Coding Dojo Campos O Dojo IFF (já que desde 10-04-2010 não somos mais o único grupo de Dojo de Campos, tendo também a galera da UENF que tá mandando ver nos Dojos :D)  está de volta \o//

Nós nos reuniamos as quarta-feiras e voltamos na quarta passada (09-06-2010) a fazer isso.

Porém, antes de falar da quarta passada ou de ontem, como o último relato que publicamos aqui foi o do dia 24-03-2010, mas nós na verdade tivemos Dojo até o dia 14-04-2010, resumirei aqui, num mini flashback gigante os relatos de Dojos que ainda não foram postados e em breve posto sobre o Dojo do dia 09 e o de ontem!

.

Dia 31-03-2010

Problema: Converter Inteiros Para Romanos em Java -> Código e relato

Foi o primeiro Dojo Campos em Java e contamos com o Rodrigo Manhães para guiar-nos com a linguagem. Usamos JUnit4, Hamcrest e o Eclipse IDE. Decidimos pegar um problema simples, por ter pouca fluência na linguagem. O problema foi o de conveter números inteiros para números romanos. Contamos com a presença de um ex-colega de trabalho, Vanderson Mota (Argentino), que estava de passagem. Não terminamos o problema, mas chegamos num ponto razoável. Todo mundo ficou procurando uma lógica matemática pra fazer a conversão, mas ninguém encontrou e acabamos mapeando alguns números.

Participantes:

.

Dia 07-04-2010

Problema: Produto Escalar de Vetores em Python -> Código/relato/fotos

Tivemos um dojo muito animado e produtivo e bem didático nessa quarta! Tivemos problemas em configurar o Eclipse para usar Hamcrest e JUnit4, que foram as ferramentas de teste que usamos no dojo anterior… Então, acabamos desistindo do Java e optando por fazer em Python (sem muita resistência, diga-se de passagem!)

Levamos 3 problemas para escolher: Produto Escalar de Vetores, Amigo Secreto e Dama. A maioria queria o do Amigo Secreto, mas logo percebemos que teríamos de controlar uma coisa aleatória e isso ia dar uma complicada nas coisas. Complicada essa que seria bem válida, aprender um pouco sobre mocks, stubs e tal… Mas como tínhamos pessoas novas no dojo, optamos pelo mais simples, que no caso foi Produto Escalar de Vetores, que permitiria mostrar umas coisas próprias da linguagem e avançar mais no problema. E deixamos a questão de testar usando mocks e stubs para o futuro.

Como imaginávamos, terminamos o problema bem rápido por ser simples, o que foi bom, pois pudemos adicionar tratamento de erros e fazer um refactoring legal do código. Um valeuzão ao Hugo que mandou muito bem na didática da parada e deu um belo gás a galera =)

Ficamos por 1:30h mais ou menos e todo mundo programou \o/

Participantes:

Retrospectiva:

Cool:

  • Todo mundo programou
  • Teve gente nova \o/
  • Quase todos preferiram Python
  • #horaextra no Arpex (relato abaixo!)

Oh, shit:

  • Atrasou mesmo marcando pra mais tarde que o anterior
  • Trocamos de linguagem porque não configuramos o ambiente
  • Cabos de energia no meio do caminho

P.S.: Não podíamos dessa vez deixar de fazer também um pequeno relato da #horaextra! Fomos no forró do Arpex e a galera do #DojoCampos mostrou que tem gingado! Agora, além de ajudar na organização dos dojos, o nosso amigo Mario Jorge ficou encarregado de fazer um tutorial “Abc Do Forró” e disponibilizar para a galera!!!

É isso aê! Programação, aprendizado, diversão e amizade! 😉

.

Dia 14-04-2010

Problema: Brothers em  Java -> Código/relato

Mais uma vez tivemos problemas com sala e projetor. Havia a nossa sala, mas todos os projetores da coordenação de informática estavam em uso. Conseguimos uma sala na multimídia e fomos para lá. Apareceu muita gente nova, na verdade a maioria era novato no dojo. Usamos Java, como o combinado, e o Eclipe como IDE. O Hugo, levou um problema: CodeBreaker e Diego Manhães levou um outro: Brothers. A maioria preferiu tentar fazer o Brothers. Rodrigo começou o Dojo por ser a pessoa mais indicada a montar a estrutura do pacote Java, com Hamcrest e JUnit 4. Um ponto interessante foi que Rodrigo introduziu alguns javismos que muitos não conheciam. O dojo até que estava andando bem, os novatos programando, até que alguém chegou e disse que tinha reservado a sala naquele horário. Fizemos uma retrospectiva, trocamos algumas idéias e finalizamos o Dojo.

Participantes:

Então é isso… Fim do flashback e até o futuro!


Dojo UENF [6]

terça-feira, 25 maio 2010

No dia 18/05/2005 rolou o mais um Dojo UENF. Seguindo com a experiência do ShuryoKata, continuamos o problema do Dojo passado, o jogo de dominó.

Primeiro, em menos de 4 minutos, fizemos uma pequena retrospectiva sobre a implementação feita no Dojo anterior. Foi bom para quem não olhou o código antes de vir para o Dojo, dar uma relembrada e os dois participantes que não vieram ficarem situados.

Como tinham ficado dúvidas (dublês e exceção) do Dojo passado, a primeira coisa a ser feita foi colocar em prática o que aprendemos. Vimos que ainda não havia necessidade de utilizarmos dublês, mas fizemos ser levantada uma exceção na tentativa de se criar um dominó com menos de 2 ou mais de 4 jogadores.

Chegamos a conclusão de que realmente deveria existir uma classe peças, já que agora além de características, peça tinha comportamento. Assim, criamos essa classe e tivemos que fazer um refactoring legal.

Participantes

Retrospectiva

🙂

  • O problema está ficando mais legal
  • Participação da galera foi boa
  • Matamos as dúvidas do dojo passado

😦

  • Galera falando muito quando teste estava quebrado
  • Gedit mal configurado (Hugo tinha acabado de formatar o note e esqueceu de configurar o gedit no afterFormat)

Percebemos que ao crescer, o problema está ficando cada vez mais interessante, o design evolutivo está sendo maneiro e o refactoring está comendo solto.

Legal também foi ver que o pessoal que não estava no Dojo anterior conseguiu se situar bem e rápido, mesmo não tendo passado o olho no código antes.

Por enquanto a experiência esta sendo bem legal!

É isso ai! Até o próximo Dojo e rumo ao hexa!

[]’s


Dojo UENF [5]

domingo, 16 maio 2010

No dia 11/05/10 aconteceu o quinto Dojo UENF. Sempre seguimos o RandoriKata, mas desta vez propus algumas mudanças, o pessoal achou legal, e fizemos um Dojo diferente. Decidimos que vamos fazer o teste de usar esse formato de dojo como experiência. Se ficar legal continuamos a utilizá-lo, se não, voltamos a fazer o RandoriKata tradicional.

Continuamos com ruby e escolhemos fazer o jogo de dominó. Começamos definindo as regras do jogo, sem muitos problemas. Foi levantada a questão de criar uma classe peça ou não, e chegamos ao consenso de que a classe peça só teria características e não teria comportamentos, o que não caracteriza uma classe. Em um momento, pensamos em fazer um stub, mas não sabíamos como fazer. Decidimos criar o objeto real para darmos continuidade e refatorar na próxima sessão. Como fazer dublês em Ruby entrou na lista de dúvidas.
De acordo com as regras, um jogo de dominó só existe se tiverem no mínimo 2 e no máximo 4 jogadores. Decidimos então que ao instanciar um jogo, deveria ser feita essa validação e caso ela não fosse válida uma exceção seria levantada. Contudo não sabíamos como fazer isso em ruby, o que foi adicionado na lista de dúvidas e fizemos de uma outra maneira para na próxima sessão refatorarmos.

A primeira impressão de utilizar a modalidade diferente foi boa. Ficamos com a expectativa de aprendermos o que não sabíamos para aplicar no Dojo seguinte e como o problema é legal, ficamos realmente com vontade de terminá-lo o que aumenta a vontade de que chegue logo o próximo Dojo.

Galera no Dojo UENF

Participantes

Retrospectiva

🙂

  • Nível do Problema e o problema em si
  • Todos participaram
  • O problema se desenvolveu num ritmo legal

😦

  • Passaram na porta e acharam que era pascal! Porra, pascal é sacanagem!

Dúvidas

  • Dublês (mock e stub)
  • Tratamento de exceção

Valeu galera! Até o próximo Dojo!

[]’s


Dojo UENF [4]

domingo, 16 maio 2010

No dia 04/05/10 aconteceu o quarto Dojo UENF. Continuamos a usar Ruby e o pessoal escolheu o problema da linguagem alienígena retirado do Google Code Jam.

Discutimos por algum tempo se iríamos usar regex ou não. Ficamos batendo cabeça por bastante tempo sobre detalhes da linguagem e fazendo muitos testes no irb para ver como as coisas funcionavam. Apesar do problemas ser bem legal, o desenvolvimento ficou muito amarrado e acabamos encerrando o Dojo mais cedo.

Galera presente até o fim

Participantes

Retrospectiva

🙂

  • Problema legal

😦

  • Não existia o master e ficamos batendo cabeça em detalhes da linguagem
  • Pouca gente

Bom, é isso ai. Até a próxima!

[]’s


Dojo UENF [3]

domingo, 16 maio 2010

No dia 20/04/10 aconteceu o terceiro Dojo UENF. Continuamos a usar Ruby e o pessoal escolheu o problema das lâmpadas no corredor.

Como deixei para fazer esse relato muito tempo depois (#fail), não me lembro exatamente como ele se desenvolveu, ainda mais que perdemos as fotos (#fail2) e não tem como saber quais foram os pontos positivos e negativos levantados na retrospectiva.

Rodrigo levantou um questionamento sobre como escrevíamos os testes no Dojo; como eles eram escritos de forma TDD e não BDD, ferindo o conceito de que o teste não é apenas um teste, mas sim uma especificação. Disso surgiu o arquivo __dojo.rb, que mostra como ele acha deveríamos escrever nossos testes. Essa discussão foi muito proveitosa e todos acabamos concordando que ele tinha razão.

Participantes

Retrospectiva

🙂

  • A discussão levantada por Rodrigo

😦

  • Perdemos as fotos
  • Deixamos para fazer o relato muito tempo depois

Por hoje é só. Até a próxima!

[]’s


Dojo UENF [2]

segunda-feira, 19 abril 2010

No dia 06/04/10 aconteceu o segundo Dojo UENF. Continuamos a usar Ruby e o pessoal escolheu o problema da soma de números romanos. Decidimos primeiro transformar o número romano em decimal, para posteriormente efetuar a soma. Seguindo essa abordagem convertemos do I ao XV e depois, cada piloto que entrava tentava resolver com uma abordagem diferente, não dando continuidade a implementações anteriores. Isso fez com que a resolução do problema não evoluísse, até que foi sugerida uma maneira genérica para resolver o problema, mais aí, era tarde demais.

Participantes:

Galera no Dojo UENF

Feedback:

🙂

  • Foco
  • Sem falatório
  • Nível do problema bom (entrada e saída definida)
  • Presença do livro de ruby
  • Pontualidade

😦

  • Muita dica no vermelho quando o piloto não solicitou
  • Com o passar do tempo os baby steps foram deixados de lado

Todas as fotos
Código

Para o próximo Dojo combinamos de levar uma grana para comprar umas pizzas e fazer um #horaextra.

Até o próximo Dojo!

[]’s