Semana Alagoana de Software Livre

Ontem de noite eu cheguei em casa depois de ter ido à Maceió ministrar 2 palestras na I Semana Alagoana de Software Livre.

Ao desembarcar lá no dia 26 para o primeiro dia do evento fui logo recebido pelo Maurício Teixeira (netmask) e aguardamos por um instante no aeroporto até que o Hélio Chissini, que também participaria do evento, chegasse.

A partir daí foi tudo festa. A primeira edição da Semana Alagoana de Software Livre foi organizada pelos alunos de graduação da FAL em conjunto com os integrantes do LUG-AL. Por ser a primeira edição do evento a programação não era muito extensa (3 palestras por dia) mais alguns mini-cursos e uma install fest que ocorreu no último dia do evento.

Eles também experimentaram um modelo diferente dos outros eventos colocando todas as apresentações no período noturno. Isso ficou muito legal porque permitiu que pessoas que trabalham durante o dia pudessem participar do evento. É uma idéia genial que sem dúvida poderia ser copiada por outros eventos do mesmo tipo.

Como o evento foi organizado pela turma de Sistemas de Informação da FAL eles cobraram a inscrição para o evento e para os mini-cursos ministrados. Também venderam ingressos para uma festa que encerraria o evento e camisetas. A verba arrecadada será usada para cobrir os gastos com a festa de formatura da turma.

Levando-se em conta que foi o primeiro evento deles, que o LUG-AL ainda não tem muitos integrantes e o evento foi pago, o público presente foi excepcional. Segundo os organizadores estiveram presentes uma média de 200 pessoas/dia.

O tratamento dispensado aos palestrantes (eu incluso) merece uma referência à parte. Me cansei de ouvir o nosso “guia turístico” (netmask) repetir: “Palestrante aqui é rei!”.

Eles nos hospedaram em um hotél “5 estrelas” (não sei se são cinco estrelas porque o hotel tem apenas 1 mês de funcionamento e acho que não foram catalogados pela Embratur) que dispunha de TV de LCD e ar-condicionado inteligente em todos os quartos que ficavam de frente para uma das praias mais bonitas de todo o Brasil.

Frequentamos os melhores bares e restaurantes da cidade e as contas simplesmente não chegavam às nossas mãos para serem pagas. A organização do evento arcou com todas as nossas despesas.

Fica aqui o meu agradecimento ao pessoal de Maceió que organizou o evento (em especial para o Maurício) e a recomendação para todos aqueles que queiram fazer um evento de sucesso que se inspirem no trabalho que essa turma fez.

Turbogears, Django e Plone

Nesse feriado resolvi dedicar um tempo para testar os frameworks de desenvolvimento Web disponíveis em Python para poder escolher um deles e iniciar o desenvolvimento de um pequeno sistema para cadatro de “Palestras e Palestrantes”. Para essa tarefa escolhi os 3 frameworks mais usados atualmente: TurboGears, Django e Zope/Plone (o Plone não é um framework, mas vou tratá-lo assim para simplificar o texto).

Eu já conhecia um pouco esses frameworks e até já tinha um preferido (TurboGears) e um outro com o qual já tinha um certo preconceito (Zope/Plone). O preconceito com o Zope/Plone nasceu com outras tentativas de aprender a usá-lo.

O Sistema

A idéia do sistema é permitir que a gente possa cadastrar os arquivos com as palestras e cursos ministrados por uma equipe e juntamente com esses arquivos manter informações relacionadas à essas palestras tais como: palestrantes/professores aptos, público-alvo, requisitos da sala de apresentação, etc.

Posteriormente o sistema também permitiria cadastrar datas de eventos, dados sobre as viagens dos palestrantes/professores e posterior mente fazer a solicitação de reembolso para as despesas destes.

O que foi feito

Apesar do sistema ter um escopo relativamente pequeno seria complicado conseguir terminá-lo em um único final de semana (mesmo prolongado) levando em conta que eu iria aprender e testar todos os frameworks que utilizaria. Então resumi o teste apenas ao cadastro de palestras. A parte estética do software também não seria importante mas uma avaliação sobre como usar as linguagens de template de cada framework fazia parte da experiência. Em alguns casos eu sequer terminei a implementação porque já tinha compreendido o funcionamento do framework e não havia mais a necessidade de finalizar o teste.

A seqüência que usei para os testes foi: Plone, TurboGears e Django.

O Plone

Depois que assisti à uma apresentação do meu amigo Xiru durante a I PyConBrasil fiquei muito tentado a experimentar o Plone com Archetypes e o ArchGenXML (criado pelo próprio Xiru). Achei que era um bom momento para brincar com isso e em 1 dia eu coloquei um Zope e um Plone pra funcionar em minha máquina. Demorei todo esse tempo porque fazia questão de ter as últimas versões estáveis dos dois programas e porque gostaria de fazer a instalação manualmente a partir dos fontes (isso não é necessário pois existem scripts automatizados para instalação disponíveis no site do Plone).

A instalação foi fácil, mas colocar ela pra funcionar demorou um tempão. Os problemas que enfrentei basicamente eram relacionados à versão do Zope que eu estava usando e a versão de um “produto” chamado Five que acompanha o Plone. Para resolver este problema simplesmente instalei outra versão de Zope e tudo começou a funcionar perfeitamente.

Conferi no catálogo de produtos do Plone (produto é o nome dado às extensões no universo Zope/Plone) para verificar se já não existia um produto que fazia algo semelhante ao que eu precisava e encontrei algumas coisas interessantes para testar. Nada do que eu testei fazia exatamente o que eu queria mas certamente seria muito mais negócio adaptá-los à inventar algo novo.

Mas a minha intenção era brincar com o ArchGenXML e então decidi reinventar a roda só para sentir o gostinho de usá-lo. Se no futuro eu fosse escolher o Plone eu partiria para reaproveitar esses produtos existentes e provavelmente jogaria o que eu tinha feito fora.

Segui passo-a-passo o tutorial do ArchGenXML e posso confirmar: funciona. Desenhei o esboço da minha aplicação no Poseidon UML Community Edition (recomendação do próprio Xiru), gerei o código, instalei e usei. Foi simples assim. O único contratempo que enfrentei foi o de ter de lembrar de reiniciar o Plone depois de ter instalado uma versão nova do meu novo produto criado.

Como eu já disse eu desenvolvi um preconceito muito grande com a dupla Zope/Plone (mais por causa do Zope) e obviamente isso fez com que esse sistema saísse atrás na corrida pela minha escolha. Mas ele me surpreendeu. Durante essa semana vou fazer umas perguntas para o pessoal do TcheZope e dependendo do que eu ouvir o Plone será escolhido para o desenvolvimento deste sistema. Ter os meus dados armazenados em um banco de dados não-relacional também me deixou muito satisfeito.

Fiquei tão surpreso com o resultado que cheguei a pensar em abortar os outros testes. Mas aí a minha grande preocupação nasceu: enquanto as coisas estão funcionando conforme nos manuais tudo é maravilhoso. Mas e o dia que elas não funcionarem de acordo? Por essa razão julguei ser o momento de passar para a próxima tentativa: “TurboGears”.

O TurboGears

Eu acredito que tenha sido o momento que eu escolhi para testar o TurboGears que tenha feito eu me decepcionar muito com ele. O projeto está numa fase muito “agitada” onde uma versão nova está saindo, um livro novo está saindo, a documentação está sendo toda refeita, a documentação antiga está sendo jogada fora, o site está em reformas, a lista de discussões está atendendo à tudo isso e mais o suporte ao desenvolvimento… é o caos. Organizado… mas caos.
O projeto está passando por uma fase onde duas coisas estão misturadas: estabilização da API e decisão dos próximos passos. A API está estável, mas duas decisões relacionadas aos próximos passos podem trazer mudanças enormes no projeto.

Uma das decisões do pessoal do TurboGears é a de trocar o ORM SQLObject pelo SQLAlchemy. Eu mexi com o SQLAlchemy e recomendo. O SQLAlchemy apresenta uma grande robustez (devido aos testes automatizados que ele tem), a forma com que o projeto foi feito o tornou muito mais extensível que o SQLObject e a documentação dele é uma obra de arte.

O TurboGears já diz ter um bom suporte ao SQLAlchemy mas não confie nisso ainda:

1. O TurboGears usa um esquema de ActiveMapper do SQLAlchemy que foi criado pelos próprios desenvolvedores do TurboGears. O ActiveMapper permite fazer o ORM de uma maneira muito parecida com a do SQLObject mas ele ainda tem uma série de deficiências.
2. O mecanismo de Identity do TurboGears é extremamente dependente do mecanismo de ORM. Se o SQLAlchemy não está 100% no TurboGears o sistema de Identity também não está.
3. CatWalk, Toolbox, Designer, … e qualquer outra ferramenta do TurboGears que use o SQLObject não funciona com o SA ainda.

A outra mudança é relacionada à linguagem de template Genshi que entra no lugar da linguagem Kid que deixará de ser padrão no TurboGears. Essa mudança tem menos impacto porque será possível usar as duas linguagens e uma se parece muito com a outra.

Depois de muita cabeçada conclui que ainda não dá pra usar o SA e então reiniciei meus testes usando o SQLObject mesmo.

A sorte do TurboGears é que ele é muito leve, fácil e descomplicado porque se eu fosse depender de documentação eu estaria perdido. A documentação do TurboGears sofre do mal da desorganização. Não falta documentação, mas ela está toda desencontrada, desatualizada, descentralizada, mal indexada, etc. A menos que você tenha saco de ficar assistindo um filminho (screencast) de 10 minutos para cada coisa que você queira aprender a fazer no TurboGears você irá sofrer.

Usando o código fonte e alguns exemplos (“Use the source Luke!“) eu consegui fazer uma parte considerável do teste com o TurboGears. Tive que brigar um pouco com o SQLObject mas isso aconteceu graças à minha ojeriza a bancos de dados relacionais. Odeio ter que pensar em minhas classes correntamente e depois sair serrando, picando e estripando para que elas caibam em tabelas.

Dos frameworks testados esse foi o que mais caiu em meu conceito porque você tem que lutar o tempo todo contra a documentação (isso inclui a documentação dos módulos de terceiro) e contra a falta de aplicações mais completas que sirvam de exemplo para aprender TurboGears.

A dica pros TurboGear-zeiros brasileiros que contribuem com este projeto é: mais atenção na documentação!

Django

Esse era o framework que eu menos conhecia e aparentemente ele é o favorito do Guido van Rossum. Também foi a minha maior surpresa (positiva) porque comecei a desenvolver os testes nele e quando vi tive que dar uma “pisada no freio” porque já estava quase terminando a aplicação toda. Tá, é um exagero. Mas é tão agradável desenvolver com o Django que me senti da mesma forma de quando comecei a programar em Python: feliz.

O tutorial do Django aberto no browser, o editor aberto no terminal, e código foi tudo o que precisei para o teste. Fui dormir às 4 da madrugada com uma sensação agradável de quem tinha se divertido programando.

O Django usa um ORM dele que é menos poderoso que o SQLAlchemy, mas é muito mais gostoso de usar do que o SQLObject. Ele também disponibiliza um monte de “tipos de dados” muito úteis como o FileField que permite criar campos com upload de arquivos e já informar em que diretório esse arquivo será armazenado (enquanto que no BD fica apenas o path para esse arquivo). Isso também não muda o fato de que o famigerado “banco-de-dados-jurássional” está ali.

A linguagem de template do Django também é feita pra ele. Funciona no mesmo esquema do PHP onde você coloca código Python no meio de tags HTML. Eu acho mais agradável fazer templates assim porque sou programador. Mas devo admitir que você tem que desenhar o template às cegas, já que não é possível ver esses templates no browser enquanto estamos desenhando (isso é possível com o Kid, Genshi, ZPT, … que funcionam com o TurboGears).

O sistema de mapeamento de URLs do Django é muito chato de configurar mas em pouco tempo você percebe que ele é extremamente poderoso. No TurboGears é muito mais simples lidar com isso porque você não tem o conceito de mapeamento mas eu não sei se essa forma de trabalhar não apresenta limitações (não consigo imaginar nenhuma limitação, mas talvez elas existam).

Considerações Finais

Vocês devem estar se perguntando: “E então, qual você escolheu?”. Eu ainda não escolhi. Tudo indica que o Django leva a taça. Mas os outros possuem algumas coisas que podem reverter esse quadro:

1. Plone – eu tenho amigos extremamente qualificados em Plone. Uma conversa de poucos minutos com eles pode eliminar uma série de dúvidas técnicas que tenho e ele seja escolhido por ser, entre os três, o que apresentou a maior facilidade de desenvolver todo o sistema.
2. TurboGears – Ainda tem a minha simpatia por ‘caber na minha cabeça’. O fator eu-posso-ajudar-nesse-projeto também pesa a favor dele porque é como os mazoquistas dizem: “Os maiores desafios trazem as maiores recompensas.”
3. Django – vou afundar mais a minha cabeça neste projeto para ver como ele funciona e ver se o coração dele condiz com a cara que ele me apresentou.

Nota do autor: Escrevi esse artigo às pressas e não pude revisar. Se encontrarem erros ou tiverem alguma idéia ou sugestão coloque no comentário. Pretendo com isso melhorar esse artigo para disponibilizar no PythonBrasil.