O colaborador convidado Igor Montagner é bacharelando em Ciências da Computação pelo IME/USP e esteve no FISL 9.0 conosco, onde a palestra sobre PyWeek e PyGame chamou sua atenção. Veja o que ele tem a contar sobre essa palestra!

A palestra sobre a PyWeek comecou explicando o que realmente é a PyWeek: uma oportunidade para a maioria das pessoas realmente terminarem um jogo.

As regras foram explicadas em seguida: basicamente, os times ou indivíduos (pode-se competir sozinho) devem, após votado um tema, desenvolver um jogo completo em apenas uma semana! E é claro que este jogo deve ser feito em python :)

Após esse tempo existe uma votação dos jogos e os resultados são anunciados.

Depois da introdução, os palestrantes Alejandro Cura e Héctor Sanchez fizeram uma espécie de estudo de caso de alguns jogos entregues por suas equipes para a PyWeek. Não vou falar aqui especificamente de nenhum jogo, mas sim comentar sobre as experiências passadas pelos palestrantes enquanto apresentavam seus jogos.

A primeira observação foi justamente que seus primeiros resultados não foram muito bons, mas, mesmo assim, conseguiram fazer jogos completos e divertidos. Um dos jogos apresentados não era, segundo o palestrante, muito legal e só depois da adição de melhores gráficos ficou mais agradável e divertido. Gostei dessa ênfase na importância da arte. Pode parecer meio óbvio, mas o visual conta bastante para a diversão do jogador e, neste caso, foi muito importante na obtenção de um resultado mais positivo.

Em compensação, outro projeto tinha gráficos mais polidos e história melhor, mas como, na minha opinião, a jogabilidade não era intuitiva, o jogo não se tornou divertido.

Os jogos ficaram mais completos nas últimas participações e tinham vários níveis e telas bonitas de game over e de nível completo. Os efeitos sonoros também foram muito bem feitos, contribuindo para o tom humorístico de todos os jogos apresentados.

A palestra chegou ao fim com os palestrantes convidando os brasileiros a participarem da PyWeek e comentando que esta é uma boa oportunidade de aprender Python.

Por causa desta competição, 250 novos jogos foram criados em Python. Uma conclusão interessante foi tirada: o objetivo de um jogo (e da PyWeek) é ser divertido e não é necessário ter gráficos excepcionais para isso.

Mais informações são encontradas em www.pygame.org e www.pyweek.org.

Obrigado pela colaboração, Igor!

Simultaneamente a essa palestra, estive na palestra sobre “Desenvolvimento ágil de software com XP e Scrum”, da qual falarei em um próximo post - em breve.

Posts Relacionados:

Assine nosso RSS feed!

Essa palestra iniciou com a motivação do tema: o jornalismo deveria ter os mesmos preceitos do software livre: colaboração, participação da comunidade, estudo e reuso de material, etc. Para isso, discutiu-se como ordenar uma colaboração do público de forma não autoritária e descentralizada.

A proposta é sempre publicar fontes da informação do texto gerado, oferecer liberdades de uso e cópia, mas restringindo seu uso comercial de forma a não fechar essa informação.

Assim, o que a diferenciaria do uso tradicional é que cada um teria as fontes necessárias para gerar um novo material sobre um determinado texto com sua leitura pessoal, diminuindo a parcialidade vista hoje nas fontes tradicionais.

Apesar das infelizes metáforas ligando programação a jornalismo (textos = programas, código fonte = fonte jornalística, fontes e jornalistas = arquitetura) e o tema não ter sido explicado de forma interessante, o tema é digno de discussão:

No fim das contas, um jornalismo livre causaria muitos textos de baixa qualidade e a falta de crítica do público poderia causar um efeito ruim ou esse mesmo jornalismo reduziria o tendenciamento da informação pelas grandes mídias?

Em opinião pessoal e em defesa de blogs muito bons que vemos pela internet, acho difícil acreditar que o conteúdo gerado por usuários seja pior do que o gerado pela mídia tradicional, se tivermos acesso às mesmas fontes.

Posts Relacionados:

Assine nosso RSS feed!

Ao entrar na sala John Maddog Hall, uma das maiores desse FISL, 5 minutos antes do início da palestra, eu esperava muitas coisas, mas certamente não esperava encontrar uma sala de palestras completamente lotada, com até mesmo pessoas de pé para assistir o Fabrício falar.

A motivação dessa palestra é algo também interessante: o palestrante sente que Rails acabou sendo o foco da trilha de Ruby e acha que a linguagem em si merecia mais destaque, embora mesmo sua palestra fale de Rails. A palestra ensinou Ruby básico, um pouco de rails e explicou que Ruby é baseado em Convention over configuration e usa MVC naturalmente - tudo isso demonstrado na construção de uma pequena aplicação funcional.

Passando por a criação de uma página com formulário simples e padrão de Ruby on Rails e seguindo incrementalmente e de forma bastante natural - fazendo alterações à medida que erros foram aparecendo e resolvendo-os. Não sei se propositalmente ou acidentalmente, mas os incontáveis erros que apareceram durante a palestra foram até instrutivos, já que o palestrante mostrou o que causava cada um deles e como eram resolvidos.

De passo em passo, de erro em erro e passando, eventualmente, pelo scaffold uma aplicação simples de perguntas com usuários. Apenas, uma pena, não deu tempo de terminar essa aplicação. A versão completa dessa aplicação pode ser vista clicando aqui: Aplicação de Perguntas.

Posts Relacionados:

Assine nosso RSS feed!

A palestra, não exatamente num formato normal, começou com uma votação sobre a linguagem (Ruby, Phyton ou Java) seguido de uma breve explicação sobre o Dojo.

Dos objetivos do dojo, passando por princípios como uso de TDD (test driven development) e não deixar sobrar dúvidas e com uma breve explicação sobre os dois estilos de dojo: Kata e Randori. Utilizaram, então, o Randori:

dojo.epistemol.net
Turnos de 5 a 7 minutos em pair programming. Quando troca, o programador em si sai e alguém da plateia entra como “co-piloto”. A platéia deve ficar em silêncio enquantos os testes não estiverem passando e podem comentar e criticar o código quando os testes passam. Além disso, se a dupla de programadores estiver completamente perdida, pode pedir ajuda da platéia.

Então, uma nova votação definiu o problema a ser resolvido: resolveríamos o problema Roman Numbers em Java. Após alguns problemas com o Eclipse e a JRE recém-instalada, começamos os turnos.

Definitivamente em baby-steps, começamos a implementação dos testes e do método conversor minimal para cada teste. Quando chegamos a 1:30 de palestras, foram passados cartões para que a platéia apontasse pontos positivos e negativos do Dojo e a retrospectiva completa e discutida deve estar em breve no site dojo.epistemol.net.

Algumas perguntas particularmente relevantes surgiram, também:

• Quantas pessoas no máximo participam de um Dojo?

  Tantas quantas forem possíveis mantendo o foco do grupo e o aprendizado. Quantos mais pessoas, menos o grupo, como um todo, aprende.

• Como são escolhidos os problemas para o Dojo?

  Normalmente, pega-se problemas prontos como em ACM-UVA arbitrariamente, de acordo com o grupo.

E também uma observação interessante:

“Em vivência acadêmica, temos contato com a maratona de programação, onde o foco é resolver rapidamente e sem se preocupar com beleza de código. O Dojo vai exatamente pelo lado contrário, se preocupando com a beleza do código e os testes e não com o tempo gasto ou com a completude do problema.”

Desculpe a citação não literal, mas acho que passei a idéia corretamente.

Posts Relacionados:

Assine nosso RSS feed!