Alguns achados na web...

Encotrei um site muito legal!
Mas muito mesmo... é um agregador de feeds que junta os posts/etc mais recentes dos melhores (?) sites de diversas categorias.

Para todos nós sem tempo de fazer qualquer coisa, é uma boa pedida. O engraçado é como inventamos soluções para resolver problemas surgidos das soluções que demos para outros problemas...

Inventamos os feeds para nos polpar tempo, mas eles começaram a ser muitos e nos tomar tempo lendo cada coisa interessante. Daí os agregadores, as recomendações personalizadas, ...

Bem, chega de papo furado. O site que encontrei é o Alltop:

http://alltop.com

E a partir dele, na categoria programming, encontrei um post muito legal sobre bugs e Scrum. Fala sobre como abordar a inevitável existência de bugs, e como enquadrar isso dentro do sprint.
Nos mesmo site, tem um post sobre um vídeo explicando Scrum em menos de 10 minutos!

São eles:

http://agilesoftwaredevelopment.com/blog/janusz-gorycki/stories-battlefield-2-my-god-its-full-bugs
e
http://agilesoftwaredevelopment.com/blog/artem/scrum-under-10-minutes-video

Também vale a pena olhar a categoria de user interfaces.

Domingo de treinamento Scrum

Continuando meu relato sobre o treinamento de Scrum que tivemos na globo.com neste final de semana, agora vou falar do segundo dia.

No fim do sábado estávamos falando sobre os Papéis de Scrum, e foi esse tema que iniciou a manhã de domingo. Já no sábado tivemos bastante discussão sobre como isso estava sendo feito na globo.com e como acreditamos que deveria ser.

A problemática está em torno de que os papéis do processo não são como posições ou cargos na empresa. Pelo que pude perceber com o pouco tempo de empresa e com o contato com o pessoal que participou do treinamento, isso não está tão claro para todos os times. Muitos Scrum Masters eram gerentes no processo cascata, e não aderiram a Agilidade. Vestem a roupa do Scrum mas continuam empurrando o processo.

Isso vai contra a idéia do processo/sistema puxado vs. empurrado. No empurrado, as pessoas são designadas a cumprir tarefas, tem a estrutura hierárquica forçando o funcionamento do sistema, enquanto que no puxado, cada um assume a responsabilidade que lhe cabe.

Uma analogia industrial seria falar de uma fábrica em que uma máquina recebe como entrada matéria-prima e retorna algo processado para seguir para uma nova máquina. As máquinas não estão em sincronia, e se a segunda tem capacidade de trabalho menor que a primeira, teremos a formação de um gargalo.
No processo puxado, a última máquina, quando livre, solicita insumo da anterior, que recursivamente vai pedindo material da máquina que lhe precede.

Retomando os papéis, no Scrum temos o Scrum Master, o Product Owner e a Team/Equipe.
As responsabilidades são as seguintes:

• Scrum Master
• Cuidar da Equipe
• Trabalhar com o Product Owner
• Revomer impedimentos
• Manter o processo funcionando
• Socializar Scrum na Organização

• Equipe
• Estimar o tamanho dos itens do Backlog (conjunto de tarefas a serem realizadas)
• Assumir compromisso com a entrega de um incremento de software funcional
• e entregá-lo
• Manter o seu próprio progresso (com o auxílio do Scrum Master)
• Auto-organizados, responsáveis pela entrega daquilo prometido para o Product Owner

• Product Owner
• Trabalhar numa visão compartilhada
• Levantar requisitos
• Gerenciar e priorizar o Product Backlog
• Aceitar o Software no final de cada interação
• Gerenciar o Release Plan
• Responsável pela lucratividade do projeto (ROI)

Ontem, segunda-feira, tive a oportunidade de conversar com um amigo, o Bruno Nascimento, que é gerente numa empresa de desenvolvimento, sobre essa problemática de quem deve assumir cada responsabilidade. Ele me contou que ele tem que conferir e homologar cada código que um desenvolvedor gera, num trabalho manual e centralizado em suas mãos.

Quer dizer que a responsabilidade do código não está na mão da equipe, e sim do gerente. Esse formato acaba causando o efeito "mijada", quando o gerente é cobrado por um software bugado, e ele então passa a culpa para os seus subordinados (a mijada descendo as escadas...), e por aí vai até chegar no pobre coitado estagiário que estava lá trabalhando insatisfeito, fazendo coisas por obrigação, mas que não interferiam diretamente na vida dele (a não ser pela já esperada mijada).

Essa situação pode ser diferente se a responsabilidade de entregar código testado for da equipe. Eles vão se certificar de fazer seu melhor, e sabem que são os responsáveis diretos pela falha. O problema é que estamos sempre procurando alguém para culparmos, e esse alguém sempre precisa de outro alguém para passar a culpa e tirar o seu da reta... É um processo defensivo, não jogamos para ganhar, e sim para esconder o fracasso que estamos temendo. Devemos jogar para ganhar!

Finalizada a discussão sobre os papéis e como colocar na cabeça dos que não querem ter seu queijo mexido que não podemos continuar com a mentalidade anterior, fizemos uma lista dos impedimentos mais comuns que temos no nosso dia-a-dia. E seguimos falando de como implementar o Scrum, das reuniões de planejamento (Estimation Meeting, Planning Meeting, Daily Meeting, Sprint Review).


Foi o momento para falar do conceito de "done" ou "pronto". Já vi discussões sobre isso em diversas listas sobre Agile, nacionais ou internacionais, e o que acaba acontecendo é que cada um tem uma opinião e que funciona. Alguns consideram pronto quando a equipe termina as tarefas da história, outros quando o P.O. aceita, outros quando está em produção, etc.
O importante é ter um conceito bem definido e difundido dentro da equipe, de forma que todos saibam qual é o objetivo, onde "parar" pois o software já está hmm.... pronto!

Fizemos uma atividade de escrever User Stories (estórias) para um Terminal de Auto-Atendimento, identificando o tipo de usuário a que se destina a estória, a funcionalidade e o benefício que esta traz.

As estórias são "lembretes para um conversa futura". Surgiu com o pessoal de Extreme Programming (XP), como forma de indicar o que o software deve fazer. Seria, para os que querem uma comparação, uma forma simples de declarar os casos de uso.

Então, separados em 4 equipes, escremos os cartões (estórias...) com o que nossos terminais deveriam ter/fazer e, em seguida, cada grupo apresentou suas idéias e como cada uma delas funcionava do ponto de vista do usuário, que benefício ele teria caso aquele estória fosse implementada.

Chegou então o momento em que falamos sobre planejar. No XP sabemos que mais vale o ato de planejar do que seguir um plano (que pode se mostrar incoerente com a realidade).
O Juan Bernabó fez essa distinção através de duas outras palavras: estratégia e tática.
Usou o exemplo de uma guerra: um geral pode definir a estratégia de um ataque anos antes do mesmo ser realizado. A estratégia é o "pra que?". A razão de invadir o país pode ser "para conquistar território", para "lutar contra o terror", etc...

Agora a tática, o "como?", se definida 5 anos antes do ataque, só garante uma coisa: o fracasso. Em pouco tempo o campo de batalha pode mudar drasticamente. Fontes de energia podem ser construídas, bases militares mudam de local, sistemas de comunicação mudam, enfim, não podemos prever como será um país com anos de antecedência... nem mesmo meses..., se o ataque fosse mesmo acontecer, a tática seria definida o mais tarde possível. Vem então mais uma idéia do Lean, de evitar tomar decisões cedo, tomá-las sempre no último momento possível.

Posteriormente falamos das estimativas, e do Planning Poker. Em equipe, estimamos pontos para nosso projeto de caixa eletrônico. Neste momento surgiu alguma dificuldade em acertar o valor relativo que a equipe definia para cada item. Com a ajuda do Juan conseguimos entrar num consenso, poderiam jogar valores sem nos preocupar tanto e ir ajustando os pesos de cada item ao longo das outras estimativas.

Então foi mais ou menos assim: pegamos uma estória por vez, e para aquela história colocávamos na mesa uma carta do Planning Poker, como o valor que julgávamos apropriado (0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100 ou "?"). Se o conseso fosse imediato, o a complexidade da estória estava definida (lembrando que não estimamos tempo...). Caso houvesse disparidade, os extremos explicavam porque colocaram um valor mais baixo ou alto e então novamente jogávamos as cartas, visando o consenso.

Por fim, para terminar o treinamento, executamos 2 sprints no "Jogo da Velocidade", que nada mais era que o XPGame com um nome diferente!
Foi legal trabalhar em equipe, conhecer pessoas novas e trocar idéias.

Do sábado para o domingo, assisti a um vídeo da palestra do Bardusco sobre a implantação do Scrum na globo.com, que me ajudou a entender melhor "aonde estamos". Já havia lido sobre a transição nos diversos blogs, mas ouvir o Bardusco pareceu mais interessante.

Enfim, um final de semana muito bom! (Enquanto meus amigos da universidade se divertiam em Arraial do Cabo... haha)

O que me espera em 2009?

Assisti a apresentação do Danilo Bardusco na Falando Em Agile sobre a implantação do Scrum na globo.com.

O post original está aqui: http://blog.bardusco.com/2008/10/25/falando-em-agile-2008/

Lá pelos 32 minutos de vídeo, ele começa a contar que o foco para 2009 são práticas de engenharia, como Pair Programming, TDD, deploy automático, etc.
O Labase foi um lar por me dar toda essa base, e será muito bom poder implementar isso na globo.com, trabalhando para milhões de usuários, e fazendo trabalho de qualidade em um ambiente muito agradável.

Uma semana de globo.com e Dinâmicas Ágeis (Scrum)

Na quinta-feira completei 1 semana na globo.com!
Estou muito feliz com o novo ambiente de trabalho, sem largar o Labase no NCE/UFRJ.

A propósito, a experiência adquirida durante um ano e meio no Labase tem sido muito relevante em minha vida e carreira. Como se não bastasse Agile no ambiente de trabalho, sempre me identifiquei com as metodologias a ponto de aplicar diversas coisas na minha vida pessoal.

Lá no Labase nós somos uma equipe de Extreme Programming (XP), porém meus estudos na área de metodologias de desenvolvimento e gerenciamento de projetos sempre foi com uma visão mais abrangente, de forma que fui procurar entender os métodos tradicionais, o waterfall, o RUP, e outras "estranhezas sem sentido". E no mundo ágil, apesar de simpatizar totalmente com o XP, e encarar as práticas técnicas que assustam muitos desenvolvedores, também acabei vendo o Scrum, que tem sido melhor vendido no Brasil se comparado ao XP.

Tudo isso para tentar entender melhor como funciona da dinâmica atual do mercado, porque o modelo tradicional é o que é, porque precisamos mudar a mentalidade, e como eu posso impactar positivamente essa mudança de paradigma.

O marketing do Scrum tem sido mais feliz, parece que XP é extremo demais para pessoas normais... E lá na globo.com nós seguimos o Scrum. Bem, como pode ser constatado em outros blogs, entamos em processo de implantação do Scrum, de mudança da mentalidade de muita gente. Alguns compram a idéia do Agile e fazem funcionar, outros já ficam com medo e acabam querendo proteger seu trabalho a todo custo... o medo de evoluir, ou de ser descartado... vai entender.

O fato é que a globo.com tem investido pesado em treinamentos e consultorias. E trabalhamos com o que há de melhor no mercado, com o pessoal da Teamware, na maioria das vezes representada pela pessoa do Juan Bernabó. Eu conheci o Juan numa palestra em agosto.
Apesar do pouco tempo de empresa, já estou participando de um desses treinamentos neste final de semana. O Juan realizou conosco algumas dinâmicas, e pudemos conversar, discutir diversos aspectos aplicados à nossa realidade.

Voltando a experiência no Labase, foi lá que me deparei pela primeira vez com o mundo Ágil, e me apaixonei. Quem conversa comigo talvez já tenha ouvido meu relato de que a cada instante que aprendo mais eu falo "ué, e não é assim que funciona a engenharia de software tradicional?!"... ou coisas do tipo...

E no Labase não ficamos só no papel, nós procurarmos vencer as dificuldades (muitas vezes impostas por ainda estarmos cursando nossa graduação), e tive o grande prazer de nos últimos meses estar numa posição de liderança que muito agregou.

Como contei em outro post, nós realizamos no NCE a dinâmica do XPGame em uma versão adaptada para os alunos do mestrado, e pretendemos fazer nessa semana (agora com data marcada!) uma dinâmica da Fábrica de Aviões.

Bem, hoje no treinamento da Teamware adicionei em minha bagagem mais dois itens interessantes. Primeiro nós realizamos uma atividade de criação de um folder para marcianos.
Era uma atividade introdutória, muito relevante para perceber que precisamos ter muito claro o conceito de "pronto" (quando uma tarefa está concluída), o foco no que o cliente quer, trabalhar no produto entregável que traz valor para o cliente ao invés de gerar especificações, etc.

A outra dinâmica foi a das bolas de tênis. Tínhamos um conjunto de bolas, e cada bola que passasse na mão de todos os participantes e voltasse para o primeiro contaria um ponto. O objetivo era obter o maior número de pontos possíveis no time-box de 2 minutos.
A restrição é que as bolas não poderiam ser passadas para um pessoa imediatamente ao seu lado de forma conduzida.

Fizemos seis sprints, e em cada um deles tínhamos que estimar um mínimo e um máximo para o número de pontos que conseguiríamos entregar. Como de se esperar, a primeira estimativa foi muito difícil, pois não fazíamos idéia da complexidade da tarefa. Estimamos entre 5 e 10 bolas.
Entregamos 12 bolas, passando as bolas em zigue-zague num corredor de pessoas e o último lançava a bola de volta ao primeiro para completar o ponto.

Vimos que poderíamos melhor bastante, e de fato melhoramos, chegando a entregar 87 pontos no quinto sprint. Tudo fruto de trabalho em equipe, de uma equipe auto-gerida e que cuidou a cada interação da melhoria da sua forma de trabalhar, de seu processo. Diferente do que conhecemos como "mundo real", não tem uma pessoa de fora de dizendo como fazer algo no qual você é especialista. Não existe o papel do gerente ou que quer seja ditando como você deve fazer seu trabalho.

Esta atividade foi citada diversas vezes durante a apresentação do Scrum e dos papéis no Scrum, e junto a toda discussão tiramos algumas dúvidas de como aplicar tudo aquilo em nossas equipes, como fazer a metodologia funcionar de verdade.

Foi um sábado muito proveitoso, e amanhã tem mais!

Instalando e usando o Capistrano no Ubuntu Linux - Parte 2

Depois de instalarmos o Capistrano hoje pela manhã [1], chegou a hora de usar!

No momento não estamos desenvolvendo em Rails, o framework que tornaria o uso do Capistrano natural. Porém, o Capistrano não é limitado a framework ou linguagem.
Então, vamos configurar o deploy automático de uma aplicação web em TurboGears / Python.

Primeiro criamos um projeto TG básico:

$ tg-admin quickstart
Enter project name: lifeatmymind
Enter package name [lifeatmymind]:
Do you need Identity (usernames/passwords) in this project? [no]
...
$ cd lifeatmymind/

Criamos o diretório config só para termos um dos arquivos que o Capistrano irá criar:

$ mkdir config

E rodamos o comando para preparar o Capistrano para fazer deploy da aplicação: capify.

$ capify .
[add] writing `./Capfile'
[add] writing `./config/deploy.rb'
[done] capified!

Infelizmente tivemos que interromper nossa tarde por alguns problemas.
Ainda faltam alguns passos para efetivamente colocarmos o Capistrano em ação:

• Configurar nosso repositório SVN
• Configurar o apache2 (ou instalar o nginx)
  
• Configurar o Capistrano
• Ver se tudo funciona :D
  

Por hora, existe um tutorial oficial que pode dar uma noção do que fazer [2].

[1] http://lifeatmymind.blogspot.com/2008/12/instalando-e-usando-o-capistrano-no.html
[2] http://www.capify.org/getting-started/from-the-beginning

Síntese de voz usando Python

Na apresentação que fiz com o Neno na PythonCampus no dia 6 de novembro [1], mostramos um script para falar para a platéia. A autoria é do Neno, eu apenas pedi para publicar.

Uma pena que só funciona em Windows (depende do comtypes [2]). Para rodar em linux poderíamos usar o eSpeak, o mesmo sintetizador usado pelo Orca.

# -*- coding: utf-8 -*-
import comtypes.client

tts = comtypes.client.CreateObject("sapi.SPVoice")

frase1 = (u"Oi comunidade Python! Este é um exemplo do Python utilizando sintetizador de voz. "
u"É possível desenvolver programas com fala para cegos utilizarem o computador em Python.")
print frase1
tts.Speak(frase1)

v = tts.GetVoices()
totalDeVoz = len(v)

frase2 = u"Este computador tem %d vozes instaladas, são elas:" % totalDeVoz
print frase2
tts.Speak(frase2)

#pega o nome da voz de numero 0
nomeVoz = v[0].GetDescription()
#Lista o nome de todas as vozes instaladas
for i in v:
print i.GetDescription()

#Sintetiza o nome de todas as vozes instaladas
for i in v:
x = tts.Speak(i.GetDescription())

[1] http://lifeatmymind.blogspot.com/2008/11/palestra-na-python-campus.html
[2] http://downloads.sourceforge.net/comtypes/comtypes-0.5.2.win32.exe

Instalando e usando o Capistrano no Ubuntu Linux - Parte 1

Hoje resolvemos testar o Capistrano [1] como nova solução para fazer deploy automático das nossas aplicações web do Labase [2].
Partindo de um Ubuntu 8.04 sem o Ruby [3] instalado, o procedimento é o seguinte:

$ sudo apt-get install ruby irb rdoc rubygems

ou

Sistema > Administração > Synaptic
E procure os pacotes ruby, irb, rdoc e rubygems, marque para instalação e clique em "aplicar" (botão verde).

Agora podemos usar o RubyGems para instalar o Capistrano.
O site do Capistrano é enfático em dizer que basta uma linha.
No terminal, digite:

$ sudo gem install capistrano

Bem, isso deveria ter funcionado! Mas não deu certo, pois o pacote RubyGems do repositório do Ubuntu vem dos mantenedores do Debian, e está numa versão muito antiga (0.9.4). Precisamos da versão 1.3.1, que instalamos assim [4]:

$ wget http://rubyforge.org/frs/download.php/45905/rubygems-1.3.1.tgz
$ tar xzf rubygems-1.3.1.tgz
$ cd rubygems-1.3.1
$ sudo ruby setup.rb
$ gem -v
bash: gem: comando não encontrado

Mas...

$ gem1.8 -v
1.3.1

O que aconteceu é que o rubygems instalou o script em /usr/bin/gem1.8, e não /usr/bin/gem como esperado. Então, basta criar um link simbólico:

$ sudo ln -s /usr/bin/gem1.8 /usr/bin/gem
$ gem -v
1.3.1

Com isso, agora conseguiremos instalar o Capistrano:

$ sudo gem install capistrano
Successfully installed net-ssh-2.0.4
Successfully installed net-sftp-2.0.1
Successfully installed net-scp-1.0.1
Successfully installed net-ssh-gateway-1.0.0
Successfully installed highline-1.5.0
Successfully installed capistrano-2.5.2
6 gems installed
Installing ri documentation for net-ssh-2.0.4...
Installing ri documentation for net-sftp-2.0.1...
Installing ri documentation for net-scp-1.0.1...
Installing ri documentation for net-ssh-gateway-1.0.0...
Installing ri documentation for highline-1.5.0...
Installing ri documentation for capistrano-2.5.2...
Installing RDoc documentation for net-ssh-2.0.4...
Installing RDoc documentation for net-sftp-2.0.1...
Installing RDoc documentation for net-scp-1.0.1...
Installing RDoc documentation for net-ssh-gateway-1.0.0...
Installing RDoc documentation for highline-1.5.0...
Installing RDoc documentation for capistrano-2.5.2...

E agora?

Lá vem a parte 2...

[1] http://www.capify.org
[2] http://labase.nce.ufrj.br
[3] http://www.ruby-lang.org
[4] Segundo solução postada aqui: http://intertwingly.net/blog/2008/11/23/RubyGems-1-3-1-on-Ubuntu-8-10

Primeira sessão do Dojo Rio

Ontem tivemos a nossa primeira reunião do Dojo Rio [1], no CEFET [2].

Depois de várias semanas mobilizando pessoas, tentando arrumar um lugar adequado para o encontro, e muito papo via lista de discussão, finalmente conseguimos tirar o projeto do papel!

Apesar do horário marcado ter sido 18:30, ficamos aguardando até 19:00 antes de começar -- um atraso de certa forma previsto para um primeiro dia, já que as pessoas não se conheciam direito.
Colocamos um pequeno cartaz (uma folha A4 :P) indicando onde estávamos e avisamos os seguranças da entrada do CEFET para que direcionassem os dojeiros para o lugar certo. Espero que ninguém tenha se perdido por falta de informação.
Para ficar registrado, estávamos no Pavilhão 1 (Informática), na sala 1. Para chegar lá, basta, após entrar no CEFET, seguir reto até o fim do corredor para chegar no Pavillhão 1, que fica à esquerda, e subir a escada metálica logo na entrada do pavilhão.

Antes de começar usamos alguns minutos para nos conhecermos um pouquinho e então, às 19:00, começamos com uma introdução ao Coding Dojo, proferida por mim. Os slides estão aqui.
Os presentes:

• Edino Moniz
• Lucas Teixeira
• Raphael Almeida
• Rodolfo Carvalho
  
• Valdir Monteiro

Finda a introdução, apresentei três problemas sugeridos para a sessão. Discutimos e resolvemos atacar o problema do Amigo Oculto, usando Python. A escolha da linguagem ficou por conta da simpatia que todos demonstraram em relação a ela e a minha familiaridade para poder ajudar o pessoal com os testes :D

Tivemos em torno de uma hora e quinze minutos para programar, fazendo turnos de sete minutos com cada par. Ao fim de um turno o co-piloto assumia o teclado, o piloto voltava para a platéia e alguém da platéia completava o par.

Nós usamos um pequeno script, o pydojo.py [3], para ajudar com os turnos. Encontrei esse programa no github do Dojo@SP, feito pelo pessoal da Async [4]. Trata-se de um ícone na bandeja do sistema com um contador. Ao término do turno ele dispara um alerta para trocar o par, e assim que a troca é feita a contagem reinicia. Fiz uma pequena modificação nele para aceitar o tempo de cada turno como parâmetro na linha de comando. Isso funcionou muito bem para a gente, e foi bem melhor que ficar controlando com cronômetro do relógio.

Estava previsto pararmos de programar 20:30, mas esticamos até 20:40, e depois tivemos nossa retrospectiva e discutimos alguns assuntos, como o próximo encontro (a ser confirmado para a próxima semana no mesmo local), e a seleção de linguagens e problemas.
Chegamos a um consenso de que funciona se as pessoas não tiverem acesso ao problema antes da hora, evitando que já cheguemos na sessão "treinados" para resolver. Então, por enquanto posso me comprometer em levar sugestões, e ficou também a idéia de montar um "banco de problemas". Bem, parece que o Dojo@SP já tem algo nesse sentido [5], que pode e deve servir de base para nós!

Voltando a retrospectiva, nossas idéias convergiram para:

:-)

• Conhecer pessoas
  
• Participação de todos
• Nenhum imprevisto!
• Python +
• TDD
  

:-(

• Nem todos dominavam a linguagem +
  
• Atraso para começar (previsto...) +
  
• Poucos presentes +
  
• Teclado e mouse de notebook

Agora precisamos criar um blog para o DojoRio, e um repositório para nosso código.
Continuando com o esquema de votação que temos adotado, escolheremos as ferramentas de acordo com a pesquisa [6].

Já estamos listados no codingdojo.org [7], faltando escrever um texto de verdade para nossa página lá. Também estamos no mapa dos Dojos no mundo [8].

Ah, com fome, antes de nos separarmos e irmos para casa, saboreamos o delicioso espetinho de frango próximo a saída do CEFET.

E assim foi nossa noite. Semana que vem tem mais!


[1] http://groups.google.com/group/dojo-rio
[2] CEFET-RJ, Maracanã - mapa http://tinyurl.com/5pnhyk
[3] http://github.com/dojosp/participant-s-projects/tree/master/Python-Tests/pydojo.py
[4] http://www.async.com.br
[5] http://groups.google.com/group/dojo_sp/web/fontes-de-problemas
[6] http://spreadsheets.google.com/viewform?key=p_t4vVH1AGOyPJtorZ9gpJA
[7] http://codingdojo.org/cgi-bin/wiki.pl?CodingDojos
[8] http://maps.google.com/maps/ms?ie=UTF&msa=0&msid=116400871369678060090.000453a8d6ee3a6d3b8fe

A apresentação / introdução ao dojo:

Intro Dojo Rio

View SlideShare presentation or Upload your own. (tags: codingdojo tdd)

Pyndorama

Meu projeto de iniciação científica no Labase começou através do Pyndorama, um software para a produção de aventuras textuais.
Felizmente o Labase sempre me proporcionou muito mais para fazer, e com isso o Pyndorama não recebeu toda a atenção que merecia (desculpa Lívia!).

Ainda assim, aprendi muito com o Pyndo. Padrões de projeto, testes, história dos jogos antigos! Ah, ele foi o primeiro projeto TurboGears com o qual tive contato.

Como parte do processo de iniciação científica, precisamos apresentar a sociedade o que foi feito no último ano. Então em poucos minutos mostrei algumas das principais mudanças que implementei no Pyndorama, e o que vislumbramos fazer no futuro.

Demorei para publicar esse post por causa das várias provas. A XXX Jornada Giulio Massarani de Iniciação Científica, Artística e Cultural foi há vinte dias.

Como se não bastasse, utilizei o Pyndorama para meu trabalho de fim de curso da cadeira de Computador e Sociedade, junto ao Gabriel Mendonça.
Nós entrevistamos o prof. Carlo Emmanoel e a mestranda Lívia Monnerat, ambos do Labase/NCE/UFRJ, para coletar informação sobre as origens do projeto.

Só a conversa com o Carlo levou mais de duas horas! E com isso reunimos muita coisa sobre a história NCE e do Carlo. Tanto que agora o Carlo me emprestou o livro "Construindo o Futuro Através da Educação - Do Fortran à Internet" de Tercio Pacitti (2003), que conta muito dos primórdios dos computadores e do papel do NCE e outras instituições. Mais leitura para as férias!

Resolvi publicar o documento com o trabalho, que contém também uma "transcrição despreocupada" das entrevistas com o Carlo e com a Lívia.

Os slides das apresentações deste mês e o link para o texto na na íntegra encontram-se abaixo:

2008/11/06 - Jornada de Iniciação Científica da UFRJ

Pyndorama

View SlideShare presentation or Upload your own. (tags: construcionism pygtk)

2008/11/25 - Trabalho do curso de Computador e Sociedade / UFRJ (slides)

Pyndorama

View SlideShare presentation or Upload your own. (tags: interactive_fiction nce)

2008/11/25 - Trabalho do curso de Computador e Sociedade / UFRJ (texto)
http://docs.google.com/Doc?id=...

Pyndorama
1. Introdução
Entendemos que para contar uma história que é fruto da imbricação de diversos aspectos, sejam estes técnicos, sociais, políticos, de mercado, entre outros, é preciso traçar os delineamentos de cada um deles e entender o funcionamento do sistema em sua forma integral. (...)

Dinâmica Ágil: Jogos Estatísticos

O Luiz Parzianello divulgou na lista do XPRio [1] um post em seu blog sobre dinâmicas ágeis, em especial sobre uma de sua autoria [2].

Ele sugere que a maioria das dinâmicas existentes " aborda a essência dos princípios ágeis de uma forma metafórica distante do modelo mental analítico predominante nos profissionais da área de software". E com isso o resultado não é totalmente satisfatório para o aprendizado e aplicação do novo conhecimento no dia-a-dia.

Concordo com o Luiz, já participei de algumas dinâmicas e tive a oportunidade de ajudar a organizar uma com alunos de mestrado do NCE/UFRJ, e a impressão que fica é de "e não é que isso funciona!". Em geral, sinto que as pessoas tem o seu queijo mexido... mas, o qual o resultado a longo prazo? Realmente uma aborgadem menos direta facilita que os conhecimentos fiquem guardados em um canto e não participem da rotina profissional.

Luiz realizou dinâmicas que chamou de "Jogos Estatísticos para a Promoção de Práticas Ágeis", tendo inclusive participado do evento Ágiles 2008.
Por hora, são três jogos baseados em:

• Modelos de produção Just-in-Time (Lotes de Produção x Produtividade)
• Teoria das Restrições (Eventos Dependentes x Produtividade)
• Teoria das Filas (Fluxo de Produção x Planejamento

As instruções para realização do primeiro jogo, o Lotes de Produção x Produtividade, já se encontra no blog do Luiz, espero que ele poste também sobre os outros jogos!
Confiram!

[1] http://br.groups.yahoo.com/group/xprio
[2] http://parzianello.blogspot.com/2008/08/jogos-estatsticos-lotes-de-produo-x.html

Dinâmica dos aviões

Mais uma vez visitei o blog do Flávio [1]. Ele sempre tem histórias muito legais, e numa ocasião ouvi falar dessa dinâmica também pelo seu blog.

O que valeu esse post é que o Flávio colocou fotos e vídeos da Dinâmica de aviões realizada na PUCRS dia 11/11/2008. Muito bom! Lá no mestrado do NCE queremos realizar essa dinâmica... quem sabe em breve se concretiza e eu posto aqui.

Já realizamos há um tempo uma versão personalizada do XPGame [2].
É isso, pouco tempo para elaborar muito :D
Na verdade, tenho feito várias coisas bacanas e não tenho arrumado tempo para "documentar o que está na minha mente"...

[1] http://mudandoumapequenaempresa.blogspot.com/2008/11/resultado-da-dinmica-de-avies-pucrs.html
[2] http://lifeatmymind.blogspot.com/2008/10/atividades-introdutrias-de-xp-em.html

Gmail voice and video chat!

Novidade no Gmail! Agora é possível usar a webcam direto da caixa de email. Muito bom!
Deu um friozinho na barriga antes de instalar o programa para fazer o vídeo funcionar, mas não pensei muito... só a possibilidade de ter vídeo na interface do Gmail foi suficiente para me convencer.

E não é que funcionou direito! Muito legal... excelente... agora o Skype ficou um passo para trás. (eBay, se cuida!)


Official Gmail Blog: Say hello to Gmail voice and video chat

Learn more »

A Neighborhood of Infinity: On writing Python one-liners.

Although most of my blog is in Portuguese, I knew somewhen I would start mixing languages and posting in English. So here it goes, my thoughts on one-liners...

Thanks to my academic advisor Carlo Emmanoel and his delicious, I was sent to a blog post [1] from sigfpe about Python one-liners.

Not that I really find it useful, but it's at least something interesting to play with. It's been a long time since I've first seen programmers challenging each other with mind breaking one-liners, usually trying to promote their favorite language.

The solution proposed by sigfpe make use of lambda forms, which, it seems, many people are not aware of -- as we can infer by the comments on the original post.
My approach to one-liners is way different.
Why tinker with lambdas when we can do it much simpler?

I'll show you how we can write ANY PYTHON CODE in only one line. Maybe you may argue that I have cheated, but it's pure core Python. Who cares about rules anyway?
The basic idea is to transform an arbitrary source-code into a single line string. Then, compile the string and exec it! I guess those two features of the language are also ignored by the majority of Python programmers.

So, let's do it to each example from the original post:

# we want to add 1 to all of the numbers from 0 to 19

def inc(n):
   return n+1

print "1.",map(inc,range(0,20))

# sigfpe's solution using lambda forms...

print "1.",map(lambda x:x+1,range(0,20))

# My solution with exec & compile...

exec compile('def inc(n):\n    return n+1\n\nprint "1.",map(inc,range(0,20))\n', '<string>', 'exec')

# Tricky idea on how to express local variables using lambdas

def f1(n):
   m = 2*n+1
   return m+m*m

print "2.",map(f1,range(0,20))

print "2.",map(lambda n:(lambda m:m+m*m)(2*n+1),range(0,20))

# Using exec & compile is inconvenient because it wastes too much space,
# since it keeps indentation whitespaces (that could be replaced by
# undesired \t's) and all the verbosity of multi-liners...

exec compile('def f1(n):\n    m = 2*n+1\n    return m+m*m\n\nprint "2.",map(f1,range(0,20))\n', '<string>', 'exec')

def f(n):
   def g(n):
       return 2*n+1

   def h(n):
       return 3*n-2

   return g(h(g(h(n))))

print "3.",map(f,range(0,20))

print "3.",map(lambda n:(lambda g,h,n:g(h(g(h(n)))))(lambda n:2*n+1,lambda n:3*n-2,n),range(0,20))

# Also, note that the exec & compile method is "dumb", we are just writing
# multiline code in one line (escaping line breaks with \n), and calling
# our Python interpreter

exec compile('def f(n):\n    def g(n):\n        return 2*n+1\n\n    def h(n):\n        return 3*n-2\n\n    return g(h(g(h(n))))\n\nprint "3.",map(f,range(0,20))\n', '<string>', 'exec')

def fact(n):
    if n<=1:
        return 1
    else:
        return n*fact(n-1)

print "4.",map(fact,range(0,20))

print "4.",map(lambda n:(lambda f:f(f,n))(lambda f,n:{True:lambda:1,False:lambda:n*f(f,n-1)}[n<=1]()),range(0,20))

# In practice, there's no difference between the code written in multiple lines
# and my naive approach to one-liners. There may be problems trying to run
# lengthier code, where that trivial solution won't work.

exec compile('def fact(n):\n    if n<=1:\n        return 1\n    else:\n        return n*fact(n-1)\n\nprint "4.",map(fact,range(0,20))\n', '<string>', 'exec')

The process is so mechanical and immediate that I've written a short script:

'''
onelify.py :: Transform arbitrary Python code into an one-liner equivalent.

2008/11/09 - Initial release

Rodolfo Henrique Carvalho :: lifeatmymind.blogspot.com
'''

def onelinefy(code):
   return "exec compile(%s, '<string>', 'exec')" % (repr(code),)

[1] A Neighborhood of Infinity: On writing Python one-liners.

UPDATE: 2008/12/26 - Now using Google Code Prettifier for syntax coloring!

A Neighborhood of Infinity: On writing Python one-liners.

Graças ao meu orientador Carlo Emmanoel, cheguei a um post [1] no blog do sigfpe sobre como escrever programas em Python em apenas uma linha.

Não que eu ache isso realmente útil, mas é no mínimo um desafio interessante. É de longa data, e independente de linguagem, ver programadores tentando mostrar as qualidades de sua linguagem predileta, e um dos "recursos" em pauta costuma sempre ser os one-liners...

A solução proposta pelo sigfpe é centrada no uso de lambdas (e impressionante como tem gente que não conhece isso no Python, como explicitado por alguns dos comentários no post original). Porém, assim que li o título do post na minha inbox do delicious, tive uma idéia diferente.

É simples, mas permite escrever QUALQUER CÓDIGO em apenas uma linha. Não sei se vão falar que "burlei as regras", porém é uso de Python puro, logo, para mim está valendo!
Basicamente, podemos pegar um trecho qualquer de código-fonte e transformá-lo em uma string. Uma string pode ser arbitrariamente grande e sempre caber em uma única linha.
Em seguida, usamos o provavelmente também pouco conhecido statement exec para executar a string com o código.

Vamos fazer isso para cada exemplo do post original:

# Primeiro o código original da função que retorna um incremento
# de um número executada para 20 números

def inc(n):
  return n+1

print "1.",map(inc,range(0,20))

# E a solução usando lambda...

print "1.",map(lambda x:x+1,range(0,20))

# Minha solução usando exec...

exec compile('def inc(n):\n    return n+1\n\nprint "1.",map(inc,range(0,20))\n', '<string>', 'exec')

# Aqui a idéia para simular variáveis locais com lambdas

def f1(n):
  m = 2*n+1
  return m+m*m

print "2.",map(f1,range(0,20))

print "2.",map(lambda n:(lambda m:m+m*m)(2*n+1),range(0,20))

# A solução com exec é inconveniente pois ocupa muito espaço,
# já que é preciso preservar os espaços em branco da indentação

exec compile('def f1(n):\n    m = 2*n+1\n    return m+m*m\n\nprint "2.",map(f1,range(0,20))\n', '<string>', 'exec')

def f(n):
  def g(n):
      return 2*n+1

  def h(n):
      return 3*n-2

  return g(h(g(h(n))))

print "3.",map(f,range(0,20))

print "3.",map(lambda n:(lambda g,h,n:g(h(g(h(n)))))(lambda n:2*n+1,lambda n:3*n-2,n),range(0,20))

# Note também que a solução com exec é "burra", estamos apenas escrevendo
# o código com quantidade de linhas arbitrárias em uma única linha e mandando
# o Python interpretar

exec compile('def f(n):\n    def g(n):\n        return 2*n+1\n\n    def h(n):\n        return 3*n-2\n\n    return g(h(g(h(n))))\n\nprint "3.",map(f,range(0,20))\n', '<string>', 'exec')

def fact(n):
   if n<=1:         return 1     else:         return n*fact(n-1)  print "4.",map(fact,range(0,20))  print "4.",map(lambda n:(lambda f:f(f,n))(lambda f,n:{True:lambda:1,False:lambda:n*f(f,n-1)}[n<=1]()),range(0,20))  # Na prática não há diferença entre o código em várias linhas e o código # one-liner. Podem ocorrer problemas para trechos de código mais longo, # onde a abordagem trivial de pegar e string do código e rodar não vai funcionar  exec compile('def fact(n):\n    if n<=1:\n        return 1\n    else:\n        return n*fact(n-1)\n\nprint "4.",map(fact,range(0,20))\n', '<string>', 'exec')

O processo é realmente mecânico e imediato, tanto que criei um pequenino script:

'''
onelify.py :: Transform arbitrary Python code into an one-liner equivalent.

2008/11/09 - Initial release

Rodolfo Henrique Carvalho :: lifeatmymind.blogspot.com
'''

def onelinefy(code):
  return "exec compile(%s, '<string>', 'exec')" % (repr(code),)

[1] A Neighborhood of Infinity: On writing Python one-liners.

UPDATE: 2008/12/26 - Agora usando o Google Code Prettifier para colorir a sintaxe!

Primeiras impressões sobre Google Reader

Olá, pessoal!
Já faz algum tempo que não escrevo nada por aqui. O Rodolfo está dando um banho em número de posts e para tentar compensar o atraso, resolvi escrever sobre minhas primeiras impressões no Google Reader. (Pra falar a verdade já cheguei a usar o gerenciador de feeds há um tempo atrás, mas não tinha muita paciência pra administrá-lo.)

Retornei hoje ao Google Reader para ver as novidades, e gostei do que vi.

Pontos positivos:
. A inclusão de novas fontes é bem simples, bastando para isso capturar a url do feed.

. A possibilidade de compartilhamento de itens é bem interessante. Se o usuário possuir um profile com foto fica mais interessante ainda. Você pode visualizar todos os itens e identificar rapidamente os indicados por uma pessoa em especial.

. Bem organizado, facilitando o aprendizado da ferramenta. (Apesar disso ser um pouco controverso, pois como diria Bruno Costa - professor do Departamento de Matemática Aplicada, UFRJ - "quanto mais conhecimento você tem, mais rápido você aprende")

Pontos negativos:
. O GR acha que sabe quando eu li um item no modo 'Expanded view', marcando tudo como lido.

Com saldo positivo, gostei do leitor de feeds e vou continuar experimentando.
Por ora, é só isso...


Deixem seus comentários!
Um abraço!

Slideshare.net

Já faz algum tempo que frequento o SlideShare para visualizar apresentações dos outros, sobre os mais variados temas, mas nunca tinha parado para criar uma conta.

Bem, criei. E com isso veio aquela sensação de compartilhar trabalhos antigos, por mais inúteis que possam ser. Minha página no SlideShare!

Uma das coisas que mais gostei é da possibilidade de fazer upload de vários arquivos de uma só vez (bulk upload). Queria muito que o Gmail fosse assim! Ouviu Google?
A ferramenta também lidou muito bem com arquivos ODP (OpenOffice.org Impress), enquanto vivi tentativas frustadas para salvar o mesmo arquivo como PDF ou converter para PPT (o fundo ficava desalinhado).

O SlideShare, como o próprio nome sugere, também é excelente para compartilhar. Dentre as diversas opções, posso colocar os slides no blog, como fiz com a palestra sobre TurboGears e DOSVOX. Foi muito rápido e fácil criar minha conta, valeu a pena!

Palestra na Python Campus

Ontem fiz uma apresentação no evento Python Campus, realizado no campus Candelária da Universidade Gama Filho.
Claro, não seria nada sem a espetacular performance do Neno Albernaz. Juntos mostramos o desenvolvimento de aplicações web em Python, utilizando o TurboGears, por pessoas com deficiência visual, com auxílio do sistema DOSVOX.

Já faz algum tempo que vejo o Neno usar o DOSVOX, e sempre fiquei impressionado com a alta produtividade. Essa semana instalei na minha máquina e já fiquei viciado, mesmo possuindo minhas capacidades visuais.
Atualmente o DOSVOX é implementado em Pascal, porém o projeto tende a ser reimplementado em Python e se tornar multiplataforma.
Espero poder contribuir com código!

A palestra foi empolgante. O público se interessou bastante pelo DOSVOX, e o TurboGears ficou ofuscado com razão.
Gargalhadas foram ouvidas quando mostramos alguns dos joguinhos presentes no DOSVOX, a maioria com um toque de humor.
Espero que possamos apresentar mais palestras juntos no futuro.

Seguem os slides no meu slideshare.net:

Desenvolvimento Web com TurboGears e DOSVOX

View SlideShare presentation or Upload your own. (tags: dosvox turbogears)

Python Campus

Amanhã começa o Python Campus - Gama Filho, primeiro evento da comunidade PythOnRio! Esperamos que seja o início de uma sequência de eventos nas universidades cariocas.

Eu serei palestrante na quinta-feira!

A participação é gratuita e não está restrita à alunos da Gama Filho, todos estão convidados.
Para os alunos da Universidade Gama Filho, o evento contará como horas de atividade complementar.

Local
Universidade Gama Filho, unidade Centro-Candelária
Avenida Presidente Vargas, 62 - Centro-RJ

Data
05 e 06/11/2008 (quarta e quinta-feira)

Horário
18h30 às 22h00

Mais informações e pré-inscrição:
http://ugf.br/index.php?q=evento/1225/view

Google Ads everywhere

Nossa, quero deixar aqui meu protesto. No fim de semana fui usar o Google Maps e reparei que agora no rodapé dos mapas aparecem anúncios patrocinados...
O mesmo mal atacou o Orkut já faz um tempo, uma imensa caixa de advertisement.
Tudo bem que o Google é movido pela propaganda, mas depois de nos aprisionar, nos educar a usar seus serviços, eles resolveram colocar os odiados ads por toda parte!?!?!

É... eu nunca chamei o Google de evil, porém pelo menos agora posso dizer que estão mais boring...

Atividades introdutórias de XP em treinamentos

Depois de um post do Adam Wildavsky na lista de XP [1], resolvi guardar uma coleção de links para atividades que podem ser utilizadas para introduzir equipes ao Extreme Programming e Métodos Ágeis em geral, além de também servirem para treinar alguns conceitos e princípios.
Ótimo para "mexer no queijo" das pessoas, colocar uma pulga atrás da orelha e trazer mais gente para a reflexão sobre como desenvolvemos software.

Lá no mestrado do NCE já participei aplicando uma versão personalizada do XPGame, foi uma experência muito interessante. Espero que possamos fazer mais!

• http://csis.pace.edu/~bergin/xp/planninggame.html
• http://c2.com/cgi/wiki?ExtremeHour
• http://tech.groups.yahoo.com/group/extremeprogramming/message/60139
• http://xp.be/xpgame.html
• http://blog.excastle.com/2006/07/24/agile-2006-the-lego-xp-game/
• http://sites.google.com/site/tddproblems/

[1] extremeprogramming@yahoogroups.com

Update 2008/11/25: outra atividade interessante é a Dinâmica dos aviões
Update 2008/11/26: mais uma, Jogos Estatísticos

Coding Dojo no Rio

Desde a PyCon Brasil 2008 (realizada aqui no Rio), no mês passado, que fiquei super empolgado em fazermos um Coding Dojo no Rio.
Como bem disse o Cláudio Berrondo, o Dojo é a "a peladinha semanal para programadores"!
Então por que não seguir os passos de nossos amigos paulistas e de outras regiões [5]?
Apesar de já ter lido sobre o assunto antes, minha primeira prática foi na PyCon, sob comando do Hugo Corbucci, que mandou muito bem por sinal.
Nosso Dojo da PyCon não foi gravado, mas tem um vídeo em que o Hugo explica direitinho qual é a idéia [1]. Outros links interessantes em [2] e [3].

Para conseguir juntar um pessoal, espalhei a notícia na PythOnRio, e na XPRio, além de divulgar para amigos da UFRJ. Alguns interessados se apresentaram, e agora só falta marcamos uma "sede".
Pensei a princípio na UFRJ, mas o problema lá é a dificuldade de transporte. Um local que se mostrou muito bom é a Universidade Veiga de Almeida, campus Tijuca, onde foi realizado a PyCon. O pessoal lá foi muito receptivo, e será muito bom se eles nos adotarem ;)

Para começar, além do local também precisamos de uma data. Para agilizar as coisas, criei o grupo Dojo Rio [4]. Todos os interessados são bem-vindos!
Vamos juntar forças com Pythonistas, Agilistas, XPeiros, e demais tribos, todos interessados em boas práticas de desenvolvimento de software, e porque não boas horas de diversão!

[1] http://video.google.com/videoplay?docid=-9174018775255486687
[2] http://www.agilbits.com.br/material/DojoIntroPyconBrasil2008.pdf
[3] http://codingdojo.org/
[4] http://groups.google.com/group/dojo-rio
[5] http://codingdojo.org/cgi-bin/wiki.pl?CodingDojos

Foto da PyCon Brasil 2008 (Rio de Janeiro)

Eis aqui a maravilhosa comunidade Python!
A PyCon Brasil trás ótimos desdobramentos... união da comunidade carioca PythOnRio, novos eventos, dojo!

http://pyconbrasil.com.br/



Clique aqui para ver em tamanho grande!

Porque Python importa?

Como aquecimento para a PyCon Brasil 2008, comecei a ver vídeos da edição anterior do evento. Concordo com o palestrante que o mercado só pensa no tal do Java...
E eu? Eu quero mudar o mercado!

Mais vídeos aqui.

PyCon Brasil

Está chegando a PyCon Brasil... não vejo a hora do evento começar!



http://pyconbrasil.com.br

Vamos usar o Firefox?

Bem, eu não precisaria dizer isto, mas acho um absurdo ver o mundo usando o IE... ele é tão patético...

Aproveitando o passeio pelo Vimeo do Ian, lá vai um video comparando o FF 3.0.1 com o IE 8 beta 1.

Internet Explorer 8 vs Firefox 3 from IanProCastsCoUk on Vimeo.

Django 1.0 e Google Chrome

Como todos que estão ao meu redor sabem, estou super empolgado com o lançamento oficial do Django 1.0. Eu realmente gostaria de estar lá em Mountain View no dia 6 para comemorar!

O Ian Ozsvald, co-fundador do ShowMeDo, postou no grupo django-users um screencast de 1 minuto para mostrar como o Django é legal! Hora de trazer os amigos!
O post original no site do Ian: http://ianozsvald.com/2008/09/04/django-in-under-a-minute-screencast/

Django In Under A Minute from IanProCastsCoUk on Vimeo.

O screencast também está disponível no Vimeo, ShowMeDo e YouTube.

Além do mais, o Ian usou o novíssimo Google Chrome nas "filmagens". Eu instalei o Chrome ontem em uma máquina virtual para testar. A primeira impressão foi boa, apesar de algumas estranhezas com a renderização. Bem, nada que me faça largar o Firefox :D, não neste momento.

Engraçado foi descobrir que o Chrome desconfia até mesmo da página do Gmail! Vejam só o que aconteceu:

Como conversar com Delicious usando Python

Olá, leitor!

Hoje pretendo compartilhar com você, o que aprendi há poucas horas.

Meu objetivo era conversar com o Delicious, após ter sido apresentado ao livro: Programming Collective Inteligence - Building Smart Web 2.0 Applications - O'REILLY.
A solução que apresento se baseia fortemente neste livro, mas incluo aqui algumas facilidades, como um guia passo-a-passo.
Não pretendo discutir muito, apenas demonstrar os passos básicos para se começar.

Para conversarmos com o Delicious nos utilizaremos* da API: Pydelicious e Universal Feed Parser.


Preparando o terreno:

1. Criando uma pasta temporária:
$ mkdir tmp

2. Entrando na pasta temporária:
$ cd tmp

3. Baixando o Universal Feed Parser:
$ sudo svn checkout http://feedparser.googlecode.com/svn/trunk/ feedparser-read-only
(relaxe um pouco, pense na vida, isso demora...)

4. Entrando no diretório feedparser:
$ cd feedparser-read-only/feedparser

5. Instalando:
$ sudo python setup.py install

6. Retornando para o diretório anterior:
$ cd -

7. Baixando o Pydelicious:
$ sudo svn checkout http://pydelicious.googlecode.com/svn/trunk/ pydelicious-read-only

8. Entrando no diretório recém-criado:
$ cd pydelicious-read-only

9. Instalando:
$ sudo python setup.py install

10. Saindo da pasta temporária:
$ cd ../..

11. Removendo a pasta temporária:
$ rm -rf tmp

Com tudo preparado, podemos começar!!!


Começa a brincadeira:

12. Abra seu interpretador Python:
$ python

13. Faça como a seguir:

>>> import pydelicious
>>> pydelicious.get_popular(tag='software')

[{'count': '', 'extended': '', 'hash': '', 'description': u'Rohos Mini Drive', 'tags': u'opensource portable privacy security software windows', 'href': u'http://www.rohos.com/free-encryption/', 'user': u'kaiwan', 'dt': u'2007-01-17T03:53:42Z'}, ...

Pronto!!
Perguntamos ao Delicious quais os sites mais populares com a tag 'software' e ele nos retorna justamente um dicionário com o que pedimos! Simples assim.
Acabamos de conversar com o Delicious!!!



Seguem mais alguns exemplos úteis...

Incluindo um bookmark em seu delicious:

pydelicious.add('usuario', 'senha', 'http://www.site.com/que/gostei', description="Site que gostei", tags="", extended="", dt="", replace="no")


Resgatando os posts de um usuário qualquer:

pydelicious.get_userposts('usuario')


Agora é só brincar com os métodos disponíveis na API!!!
Espero que tenham gostado. E perdoem qualquer lapso; é meu primeiro post.
Deixem seus comentários!
Um grande abraço!


* De antemão, estou assumindo que você já tenha um interpretador Python ( utilizo a versão 2.5.2 ) instalado e esteja em ambiente Linux (utilizo Ubuntu 8.04 - Hardy Heron), conectado à internet.

Django Templates + Dreamweaver

Resolvi fazer uma rápida pesquisa para saber o que é possível fazer para editar Templates do Django num editor como o Dreamweaver, depois que uma amiga expressou a vontade de usar tal ferramenta para criar o layout de um site.

Para começar, por filosofia, a linguagem de templates do Django não tenta ser amigável a editores WYSIWYG, como o Dreamweaver:

http://www.djangoproject.com/documentation/design_philosophies/

Assume designer competence

The template system shouldn’t be designed so that templates necessarily are displayed nicely in WYSIWYG editors such as Dreamweaver. That is too severe of a limitation and wouldn’t allow the syntax to be as nice as it is. Django expects template authors are comfortable editing HTML directly.

No meu caso, eu assumo competência para usar um editor de textos normal, ou usar o Dreamweaver em modo Code View (pelas funcionalidades do editor, como code-completion, code-folding, referência à mão, busca e substituição, etc), porém, de fato, nem todos os desenvolvedores trabalham assim.

Li o post do Mark Ramm sobre "user-friendly templates", e confirmei que temos aí uma grande questão de opinião. Uns defendendo linguagens que utilizam atributos em tags, como estou acostumado a usar no TurboGears, e outros mostrando vantagens notadamente no sistema do Django, com marcação própria. Eu estou aprendendo a gostar da abordagem do Django, pela quantidade reduzida de código que preciso escrever. Tudo bem que os templates em Kid geralmente são feitos copiando um já existente para garantir o código repetitivo de doctypes, xml namespaces, e resto da estrutura básica, mas a simplicidade de escrever arquivos pequenos, só com aquilo que realmente interessa, é tentador!

A propósito, a breve discussão do Mark com o Simon Willison sobre como eles estão usando AJAX me trouxe várias idéias! Já faz algum tempo que não brinco com AJAX pra valer, entretanto recentemente dei uma opinada no código de uma amiga que está desenvolvendo uma aplicação de redes sociais, e agora tenho novidades para acrescentar.

Ainda não tenho experiência suficiente no Django para saber se na hora de manter o código essa simplificação trará alguma dificuldade. A princípio, creio que não, já que geralmente me encontro usando o Firebug contra páginas servidas localmente (nunca abri um arquivo .kid no Firefox para 'debugar' e não consigo imaginar alguém fazendo isso). Além do mais, o Kid também tem herança, e com isso os arquivos que manipulamos não são exatamente o que teremos de output na tela, pensando na visualização do layout com CSS, por exemplo.

Por fim, o Beshr Kayali desenvolveu uma extensão para o Dreamweaver, DjangoExt, que promete facilitar a vida. Eu não tive paciência de me cadastrar no site da Adobe só para baixar essa extensão. Se alguém tiver o arquivo, por favor entre em contato.

Desfazendo mudanças em um repositório SVN

Uma das vantagens de usar um sistema de controle de versão, como o Subversion, é a possibilidade de voltar atrás quando uma alteração foi indesejada.
Costumo falar para meus amigos que devemos commitar o código freqüentemente, sempre, sempre, sempre. O trabalho deve ser feito de forma incremental, uma pequena tarefas/alteração por vez, em passos de bebê.

Para desfazer uma mudança já commitada no repositório, basta seguir os passos descritos aqui: http://svnbook.red-bean.com/en/1.1/ch04s04.html

Suponha que você está trabalhando numa cópia de trabalho de /calc/trunk, e então descobre que uma mudança feita na revisão 303, que alterou o arquivo integer.c, está completamente equivocada. A alteração nunca deveria ter sido commitada. Você pode utilizar o comando svn merge para "desfazer" a mudança na sua cópia de trabalho, e depois commitar a modificação local para o repositório. Tudo que você precisa fazer é especificar uma diferenciação reversa:

$ svn merge -r 303:302 http://svn.example.com/repos/calc/trunk
U  integer.c

$ svn status
M  integer.c

$ svn diff
…
# verifique se a alteração indesejada foi removida
…

$ svn commit -m "Desfazendo mudança commitada em r303."
Sending        integer.c
Transmitting file data .
Committed revision 350.

Uma revisão no repositório funciona como um grupo específico de alterações (changesets). Usando a opção -r, você está pedindo que o svn merge aplique um changeset, ou um conjunto deles, a sua cópia de trabalho local. No caso acima, aplicamos o changeset #303 de forma reversa.

Lembre-se que ao desfazer uma mudança, é recomendável usar o svn status e svn diff para confirmar que seu trabalho está no estado correto, e depois usar o svn commit para enviar a versão final ao repositório.

Se você está pensando: "eu não desfiz um commit de verdade, certo? A mudança ainda está lá na revisão 303. Se alguém fizer checkout de uma versão entre 303 e 349, verão a mudança indesejada!"
Isso mesmo, o svn merge apenas "remove" a mudança indesejada do HEAD (última revisão) do repositório.

Dica extra:

Para saber qual a versão atual do repositório, use o comando svn info.
Exemplos:

• Informações úteis sobre um arquivo:

$ svn info foo.c
Path: foo.c
Name: foo.c
URL: http://svn.red-bean.com/repos/test/foo.c
Revision: 4417
Node Kind: file
Schedule: normal
Last Changed Author: sally
Last Changed Rev: 20
Last Changed Date: 2003-01-13 16:43:13 -0600 (Mon, 13 Jan 2003)
Text Last Updated: 2003-01-16 21:18:16 -0600 (Thu, 16 Jan 2003)
Properties Last Updated: 2003-01-13 21:50:19 -0600 (Mon, 13 Jan 2003)
Checksum: /3L38YwzhT93BWvgpdF6Zw==

Informação sobre diretórios:

$ svn info vendors
Path: trunk
URL: http://svn.red-bean.com/repos/test/vendors
Revision: 19
Node Kind: directory
Schedule: normal
Last Changed Author: harry
Last Changed Rev: 19
Last Changed Date: 2003-01-16 23:21:19 -0600 (Thu, 16 Jan 2003)

Mais Django!

Definitivamente vou começar a usar Django.
Tudo que vi recentemente tem me empolgado bastante, e acabei reunindo algumas informações úteis:

Django, documentação 100% em sincronia com o código no repositório svn!
http://www.djangoproject.com/documentation/

Um livro, escrito pelos autores do framework, gratuito:
http://www.djangobook.com

Django roda no Jython!
http://code.djangoproject.com/wiki/DjangoAndJython

Várias aplicações prontas (código que se integra ao seu projeto para desempenhar funções corriqueiras)!
http://pinax.hotcluboffrance.com/apps/

Novidades no meu delicious.com:
http://delicious.com/rhcarvalho/django

• http://pinaxproject.com/
• http://code.google.com/p/django-hotclub/
• http://www.djangosnippets.org/
• http://42topics.com/Django/
  

E tem mais:

Django é muito mais popular que o Turbogears!

turbogears 0.07 django 1.00

http://google.com/trends?q=turbogears%2C+django%2C+&ctab=0&geo=all&date=all&sort=1


Django é tão *hot* quanto J2EE, e em ritmo crescente, enquanto o Java está decadente!

j2ee

7.00

django

1.00

http://google.com/trends?q=j2ee%2C+django%2C+&ctab=0&geo=all&date=all&sort=1


Acredito que dá para juntar templates e aplicações prontas para acelerar o desenvolvimento.
O projeto Pinax é muito interessante nesse sentido.

Até a próxima!

Palestra sobre Scrum com a Teamware

Hoje fui com o Ronald, da minha equipe no Labase e o Gustavo, companheiro de empresa júnior Fluxo Consultoria a uma palestra da Teamware sobre Scrum. Muito bom conhecer pessoalmente o Juan Bernabó, depois de ouvi-lo em alguns podcasts. A introdução ministrada pelo Eduardo Coppo também foi excepcional. Gostei de ver o pessoal ter o seu queijo mexido, as abordagens ágeis realmente fazem as pessoas pararem para refletir.

Eu não tenho dúvida que para o tipo de coisa que gosto de fazer não tem processo cascata que dê conta. Lá no Labase estamos gradualmente colocando a equipe nos eixos, e está sendo muito engrandecedor seguir as boas práticas, aprender coisas que ninguém ouve falar durante a graduação (infelizmente).

O engraçado é que ontem eu proferi uma mini-palestra sobre abordagens ágeis para um pessoal da Fluxo, e alguns dos slides que o Bernabó apresentou também estavam na mini palestra! Claro que nada melhor que ouvir de alguém mais experiente a complementação ao meu discurso. Note que na minha apresentação procurei não entrar em tantos detalhes de software, e sim apenas cutucar em poucos minutos os ouvintes falando mais sobre "princípios gerais".

A invenção do computador

Esse foi o tema do texto escrito por Pierre Lévy que li nesse fim de semana.
A história é razoavelmente longa, mas certamente poderia ser uma coletânea de livros se assim desejado.

O computador nasceu no período de guerra, e, como as bombas nucleares, serviu para o mal, para aterrorizar e destruir. Todavia, o conhecimento neste momento adquirido é o que garante o bem-estar, o retardo indefinido do próximo conflito mundial, e que multiplica nossos poderes e inteligência.

O desenvolvimento de máquinas que automatizam e aceleram cálculos precede a Segunda Guerra Mundial, logo esta não pode ser dada como tese única para o surgimento dos computadores. Estes não prosperaram nem no Japão nem na Alemanha, pois foram destruídos pela guerra. Foi ela que financiou projetos nos EUA, e por isso, antes de construir equipamentos de seus interesses, cientistas tiveram que produzir encomendas do governo orientadas a aplicações militares.

Apesar de a pesquisa militar ter contribuído para o desenvolvimento das primeiras calculadoras eletrônicas, a bomba atômica de urânio foi construída sem o auxílio de qualquer computador. Essa época favorável a invenções permitiu que teorias e objetos técnicos fossem repensados e então ganhassem novos fins não-militares.

A criação dos computadores não é creditada a ninguém em especial, mas sim a alguns homens que contribuíram para tal. Destaca-se Charles Babbage, Alan Turing e John von Neumann, todos eles matemáticos. Babbage construiu máquinas de calcular, inclusive introduzindo funções de memória, objetivando construir tabelas náuticas, astronômicas e matemáticas exatas, pois as que existiam na época eram tomadas de erros.

Turing foi mais um teórico, e não deu contribuições diretas para os computadores digitais, nem para a construção de autômatos concretos. Já von Neumann redigiu o primeiro documento onde se descrevem a disposição interna e os princípios de funcionamento dos computadores modernos.

A história dos computadores também pode ser descrita pela natureza dos materiais empregados em cada época. Primeiro as máquinas mecânicas, depois eletromecânicas, eletrônicas e, por fim, os computadores. A evolução na eletrônica se deu com o tubo de vácuo, originando o transistor e os circuitos impressos. Isso sem contar o desenvolvimento das áreas de linguagem de programação, software, dispositivos de comunicação e implicações sociais.

A invenção técnica do que é a informática deveu-se a uma sucessão de fatos desordenados e reutilizações, contrastando com as idéias de algoritmo ou de mecanismo predeterminado a que está associada.

A história da informática é uma espécie de meta-rede irregular na qual cada nó define e interpreta à sua maneira, em função dos seus fins, a topologia da mesma. Cada um reinterpreta o passado e projeta um futuro segundo suas vontades. Assim, nenhum precursor ou fundador tem pertinência relevante.

Comentários pessoais:

Pierre Lévy é um Tunisiano de 52 anos, residente no Canadá. Ele é conhecido por seus estudos sobre inteligência coletiva e sociedades baseadas no conhecimento. Lévy é um nome importante na “cibercultura”.

Notei que a invenção do computador não pode ser analisada a partir de uma visão simplista. Ela se deve a uma complexa mistura de fatos, estudos e invenções, englobando o aspecto social, técnico, científico e militar.

Lévy mostra como a guerra influenciou a tecnologia, e vice-versa, e isso me deixa num estado de dúvida. Será que para construirmos, evoluirmos, precisamos de tanto terror, tanta morte, tanta destruição? Não poderiam razões mais benéficas provocar inovações em grande escala? Parece que o homem precisa sofrer para, então, usar sua inteligência para o bem.

Há uma tabela comparativa que mostra o quanto a velocidade de processamento evoluiu com o surgimentos de novas máquinas. Enquanto um homem levaria mais de dois dias para calcular a trajetória de uma bala, um computador mecânico levaria apenas duas horas. Não obstante, o ENIAC levaria apenas três segundos, um valor impensável com a tecnologia do início do século XX.

Quanto um nome para destacar como o criador do computador, concordo com o autor no argumento de que não é possível identificar alguém que tenha idealizado e construído a máquina que usamos hoje, com propósitos bem definidos e sem utilizar-se de outros equipamentos eletrônicos previamente construídos. O computador claramente não é uma máquina que foi construída “from scratch”.