Ponto no polígono

Esse sábado vamos nos reunir para tentar resolver o problema de decidir se um ponto está dentro de um polígono qualquer.


Ainda não pesquisamos sobre as possíveis soluções. Essa imagem foi achada ao acaso.

Esse problema foi motivada pois vamos precisar de um algoritmo como esse para implementar uma cerca eletrônica para automómeis, no projeto karmonitor, que estamos rodando no Laico-CIC-UnB.

Como teremos alguns novatos, vamos começar com uma apresentação rápida sobre Dojo (15min). Então, quem estiver indo pela primeira vez, chegue cedo!

Nos encontraremos no LINF, para codar das 9:00 às 12:00.

São todos muito bem vindos!
Até agora confirmados:

1. Bruno Rolim
2. Bruno Rosa
3. Bruno Pedroso
4. Estêvão Passarinho
5. Ian Gallina
6. Eduardo Marques
7. Lucas Santos

8. Tharsis

========
ATA:

Código:
http://github.com/brunopedroso/dojo_ponto_poligono

Participaram
- Bruno Pedroso
- Bruno Rolim
- Bruno Mendonça
- André Teixeira
- Estêvão Passarinho
- Ian Gallina
- Eduardo Marques


:-)

- Ruby
- Quorum bom, gente nova
- Ambiente do Laico bom
- problema interessante

:-(

- ficou muito tempo com teste quebrado (passo muito grande entre a implementação stub e a verdadeira)
- pareceu que a gente burlou o TDD em algum sentido
- demorou a chegar todo mundo
- tivemos que mudar de sala (no-LINF, no-BT504)
- faltou café
- faltou música
- até agora o código tá espaguetado
- faltou quadro branco
- teve gente q confirmou e não veio (Tharsis, Tulio)
- B.Mendonça e André ficaram calados

comentários
- teclado do mac ainda é problema?
- podíamos fazer uma planejadinha a cada par.

Primos em java e ruby

Sessões do dia 17 de outubro de 2009

O que foi planejado:
no CEUB - bloco um
Palestra introdutória e kata rápido (série de cosenos)


no LINF
problema: continuando o "piratas", em Java:
http://github.com/tulios/dojo-brasilia-piratas

9:30
1 - Ian Gallina
2 - Bruno Pedroso
3 - Túlio (ainda vou confirmar)
4 - Tharsis
5 - Julio
6 - Bruno Rolim

----------
O que foi realizado:

Fizemos a apresentação no CEUB e começamos a resolver o problema dos primos em Java. Tivemos várias discussões com a turma.

Participaram:
- Bruno Pedroso
- Bruno Rolim
- Willi (parte)
- Ian
- Julio

Começamos no LINF às 10:00. Resolvemos implementar o mesmo problema, só que em ruby, com rspec. Terminamos o problema antes das 11:00.

O código está em http://github.com/brunopedroso/dojo_primes_ruby_rspec

Participaram:
- Bruno Pedroso
- Bruno Rolim
- Tharsis
- Ian
- Julio


Retrospectiva:

:-)
- código super enxuto
- resolvemos rápido
- ruby é muito doido
- rspec é fácil
- tdd bem passo a passo
- sábado de manhã é bem melhor!!!

:-(
- faltou refatorar o nome das variáveis
- problema muito simples

Continuando o Bowling em C

Esse sábado o dojo aconteceu no LINF - laboratório de informática, na UnB.

Estamos continuando o problema do bowling, usando linguagem C.

Dessa vez apareceu pouca gente. Apenas eu (Bruno), o Célio e o Ian. O que não foi de todo ruim. Ficamos os 3 na frente da máquina, fazendo um triple-programming e revezando o teclado na hora que dava vontade. O código fluiu bem também, porque com menos gente precisamos parar menos pra discutir e explicar... Tudo tem sempre um lado bom e um lado ruim.


Duas "manobras" se fizeram notar durante essa seção. A primeira dela vem de uma característica da linguagem C: a de ser muito, muito, muito liberal. Acontece que precisamos escrever testes com que normalmente não nos preocuparíamos em linguagens como Java, Ruby, Python, etc.

Veja bem: tínhamos uma função que recebia uma string, representando a série de jogadas de um jogador. Alguma coisa como:

"1: 2 3, 4 5, 0 4, 10, 9 1, 3 4 "

Aí começamos ignorando os primeiros caracteres ("1:_") transformando o resto num array de inteiros, para seguir processando.


Quando implementamos a regra do spare, fizemos de modo simples, somando os elementos subsequentes:



Vimos então a necessidade de garantir que o programa não leria os elementos subsequentes além da capacidade do array.

Acontece que em C um array nada mais é do que um ponteiro para o primeiro elemento do array. Cabe ao programador gerenciar a leitura do array apenas até o tamanho alocado.



Isso quer dizer que, do jeito que estava nossa implementação, no caso de passarmos um placar incompleto, com um spare no final (tipo "1: 1 2, 3 4, 9 1") nosso programa deveria no mínimo responder que não é possível calcular o placar, ao invés de somar a próxima posição do array (que não existia), calcular o valor errado e retornar, como se nada tivesse acontecido.

Só que aí - eis a nossa surpresa - nosso teste simplesmente passava, calculando o valor corretamente. Porque?

Simples: por sorte, a próxima posição de memória depois do nosso array [1,2,3,4,9,1] estava com o valor zero, e o programa acabava acertando o resultado :-P

Só que, veja bem: não podíamos nos satisfazer com isso. Nosso teste passava na sorte! Como podíamos escrever um teste que definitivamente falhava, mostrando o erro no programa?

Fizemos assim: com os testes todos passando (por sorte...) refatoramos o código para extrair da função principal uma outra que fazia o mesmo trabalho, mas recebendo um array de inteiros e o seu tamanho:



Com isso, pudemos testar esse método menor passando um array com 5 posições, com a última tendo valor diferente de zero, mas passando um tamanho de array 4. Isso simula a situação em que a posição de memória subsequente ao array não está com valor zero, e consguimos deflagrar o erro :-)



Zas!

Bem, a segunda manobra radical desse sábado se deu no laço for principal da lógica que fazia a conta do placar. Acompanhe:

Antes:


Depois:


Mudamos o significado do contador principal, para contar de frame por frame. O interessante é que só percebemos que seria melhor assim depois que precisamos passar a guardar o número do frame, para não nos perdermos com os frames de strike, que só tem uma bola ao invés de duas.

Depois disso, ainda refatoramos isso mais adiante, para que a função (não é método ;-] ) que convertia a string em array de inteiros completasse as segundas bolas dos frames de strike com zeros.

Isso ajudou com o problema que tínhamos naquela hora. Mas será que vai ajudar quando chegarmos à regra de calcular os strikes? E qndo chegar a hora de calcularmos um décimos frame com 3 bolas?

:-*

O tempo dirá! Sábado que vem a gente descobre.

O código completo desse problema está em
http://github.com/brunopedroso/bowling_dojo_c/tree/master

Para participar das próximas sessões, marque presença em nossa lista:
http://groups.google.com/group/dojo-brasilia

see ya.

Retomando as atividades

Opa,

Hoje nor reunimos novamente, depois de algumas semanas sem atividades.

Começamos o problema do bowling, pois haviam novos participantes no Dojo. Apesar disso, na hora de começar ficamos nos perguntando qual linguagem usaríamos e... Decidimos usar C - o que complicou um pouco as coisas.


Por um lado foi bem legal, pois muita gente (como eu) não programava em C há um bom tempo. Incrivel como a linguagem é burocrática e solta... Depois de um tempo programando em Java e Ruby a gente desacostuma... :-P

Não conseguimos andar muito, pois perdemos algum tempo levantando o ambiente e colocando os testes pra rodar.
Por estarmos há um tempo sem codar, e por ter bastante gente nova, acho que distraímos e eu comecei codificando sozinho por quase uma hora :-P . Comecei com uns testes de aceitação não automáticos, o que também não foi muito bonito...
A verdade é que eu queria chegar logo na parte do cálculo da pontuação (e largar pra trás a parte de arquivos e talz) pra o pessoal novato ver. Mas não sei se o balanço foi positivo não.. Não faça isso em casa! :-)

Terminamos de codar meio tarde, então a retrospectiva não foi das mais produtivas também.

Apesar disso tudo, foi ótimo ter voltado à atividade!

O código foi parar em http://github.com/brunopedroso/bowling_dojo_c/tree/master
A ata será publicada em http://groups.google.com/group/dojo-brasilia/web assim que eu conseguir criar uma nova página lá ;-)

Até a próxima o/