Pythonologia

Pra variar as coisas andaram paradas por aqui, não? É que muita coisa mudou desde o último post.

A maior mudança que aconteceu foi a minha saída do INdT. Pois é, eu sou doido mesmo afinal deixei de trabalhar no melhor lugar pra se trabalhar com tecnologia no país hoje. O que eu fazia lá era massa, o ambiente era massa, o suporte do INdT era massa, os amigos que fiz por lá foram muitos… então você me pergunta: “Porque você saiu?”.

Por uma série de pequenos motivos que vão desde “eu não gostei de Recife” até “o meu plano era de ficar lá só por um período” e passando por “eu já fiz as coisas que eu queria ter feito e era o momento de dar essa chance a outra pessoa” eu achei melhor voltar para Curitiba.

Saí de lá mas continuo admirando o trabalho que eles estão fazendo e torcendo para que eles consigam criar um modelo que possa ser copiado por mais empresas de tecnologia no país.

Com minha saída do INdT eu também me mudei pra Curitiba voltando para a cidade de onde saí. Estou provisoriamente na casa da sogra :P. Em junho, quando o contrato de locação dos meus inquilinos terminar, eu volto pra minha casa “oficial”.

Outra mudança legal que ocorreu foi a de que comprei um Macbook e estou usando o OS X. Sim, eu praticamente abandonei o Linux. Criei até o bordão de que agora eu “Odeio Linux!” (mentira, óbvio).

Estou sofrendo pra me readaptar ao universo Apple. Readaptar porque eu já usei o MacOS 9 por anos seguidos nos PowerMacs 9100, 9500, 8100, etc. Naquela época o hardware era impressionante e o software horrível. Agora as coisas mudaram muito pra melhor. Por baixo da carinha bonita do OS X bate um coração Unix (BSD) e com isso eu tenho o melhor dos dois mundos: a praticidade de uma bela interface gráfica e um terminal com Vim e Python pra trabalhar

Também comprei outros tantos “brinquedinhos” eletrônicos pra mim tais como um N95 e um headset estéreo bluetooth também da Nokia entre outros que provavelmente serão alvos de algum review por aqui.

Detalhes maiores sobre as minhas últimas aventuras serão distribuídos no 9o. FISL em Porto Alegre entre os dias 17 e 19 de abril. Me esperem por lá.

Nota off-topic: Acabei de receber o livro Shell Script Profissional (site do livro) do meu amigo Aurélio. Ele me enviou de presente e com ele e mãos já deu pra perceber que a capa ficou show, o tamanho dele (480 páginas) dá uma cara de “obra definitiva” para o assunto e o acabamento e diagramação que a editora Novatec dá aos livros dela (que é padronizado) merecem vários elogios.

Boa parte do meu dia-a-dia de desenvolvedor é gasto em proramando em Python. Gosto de estar sempre atualizado com o que há de novo para essa linguagem e para isso saio instalando tudo o que aparece para para experimentar. Além de Python o Linux também faz parte da minha vida e uso ele quase 100% do meu tempo (em vias de mudar para o OS X).

A plataforma Python, de uns tempos pra cá, vêm padronizando os arquivos Eggs para distribuição de aplicações e bibliotecas. Em conjunto com o PyPI (Python Package Index) e o utilitário easy_install (que é parte do framework setuptools) é possível instalar componentes Python com apenas um comando.

A facilidade para instalar esses pacotes é enorme mas removê-los é chato porque envolve a edição de alguns arquivos texto, e ter permissão de escrita no diretório de bibliotecas do Python (permissão que também é necessária para a instalar o pacote).

Cada pacote instalado acrescenta uma entrada ao sys.path do Python fazendo com que o tempo para importar um módulo aumente um pouco mais (cada uma dessas entradas é consultada em busca do módulo e se você der uma olhada na saída do strace verá que a procura por um módulo envolve vários passos).

O Linux que eu uso (Ubuntu) precisa ter um ambiente Python estável, já que grande parte de suas aplicações roda em cima dessa linguagem, ou seja, danificar esse ambiente pode atrapalhar todo o funcionamento do sistema.

Isso tudo junto com o fato de que adoro experimentar as novidades do mundo Python faziam com que meu Python ficasse totalmente poluído com versões bleeding edge de bibliotecas que muitas vezes são incompatíveis com as versões “oficialmente suportadas” pelo pessoal que faz o Ubuntu.

Seria necessário um jeito fácil de se criar ambientes isolados do Python usando como base a própria instalação do sistema para que eu pudesse fazer esses testes e experiências sem danificá-lo. Não ficar replicando cópias de Python pela máquina também seria interessante.

E então surge a solução…

Parece engraçado mas no mesmo dia que perdi horas “arrumando” o Python em meu computador eu li no blog do Ian Bicking que ele tinha desenvolvido um programinha que fazia exatamente o que eu precisava: o virtualenv.

O uso do virtualenv é extremamente simples e direto. Basta instalar, executar e ativar.

Instalação

Se você está usando Ubuntu ou Debian:

sudo apt-get install python-setuptools
sudo easy_install virtualenv

Se não está:

wget http://peak.telecommunity.com/dist/ez_setup.py
sudo python ez_setup.py

Criando o ambiente

Para criar um ambiente basta executar o virtualenv e passar como parâmetro o nome do diretório onde tal ambiente será instalado:

virtualenv meu_python

Esse comando irá criar um diretório chamado meu_python com os diretórios:

• bin - executável do interpretador, o script easy_install e o arquivo activate que será usado para “ativar” o ambiente. Quando o ambiente está “ativo” os executáveis dos aplicativos Python são instalados aqui também.
• lib - a árvore com links simbólicos e/ou cópias de todos os módulos e bibliotecas do Python. Quando esse ambiente está “ativo” os módulos e pacotes serão sempre instalados dentro desse diretório.
• include - dentro desse diretório estão os links simbólicos para todos os headers do Python que são necessários para se compilar extensões escritas em C para ele.

Ativando o ambiente para usar

Para usar esse ambiente recém-criado é necessário ativá-lo. para isso basta executar o seguinte comando:

source meu_python/bin/activate

Esse comando irá adicionar o diretório meu_python/bin no PATH da sua sessão e mudar o prompt para que você possa distinguir visualmente quando este ambiente está ativo.

Atenção: O virtualenv não cria o link simbólico python -> python2.5, portanto, se precisar dele você terá que criá-lo à mão com o seguinte comando

(cd meu_python/bin; ln -s python2.5 python; hash -r)

Depois disso é só sair instalando as coisas sem a menor preocupação.

PS. Eu não testei o virtualenv no Windows nem no Mac OS X mas no site do projeto é possível notar que tem gente usando ele também nessas duas plataformas, portanto, eu acho que ele também funcione corretamente nelas.

O uso de testes no desenvolvimento de software já vem me acompanhando desde que trabalhei com Smalltalk na Objective Solutions. O sistema de testes que eles tinham lá chegava muito próximo do que eu idealizo para um sistema de testes.

Recentemente eu li o livro Test-Driven Development do Kent Beck e resolvi experimentar TDD de forma radical em um projeto pessoal em que estou desenvolvendo em Python. O meu sentimento geral sobre o uso de TDD é a de que estou programando num ritmo bem mais lento do que costumo ter mas com a certeza absoluta de que estou seguindo pelo caminho correto.

Como os detalhes de implementação desse projeto não estão muito claros em minha cabeça o uso de TDD está se mostrando ideal, mas não recomendo para o desenvolvimento de uma aplicação na qual você já tenha uma boa idéia de como implementar pois ela realmente ‘desacelera’ o seu ritmo. Mas atenção: estou desaconselhando o uso de TDD e não a criação de testes! Nos projetos onde é possível desenvolver testes é fundamental fazê-lo.

Mas voltando ao assunto deste post eu adoraria ver uma ferramenta para Python com as seguintes funcionalidades:

1. Suportar testes escritos com xUnit (unittest) e doctests.
2. Vir junto com framework xUnit mais poderoso que o unittest padrão do Python. O py.test tem umas idéias legais. Juntar outras bibliotecas auxiliares, tais como o mocker, também seria legal.
3. Ter um sistema de discovery automático para testes (ex. nose).
4. Ter uma interface texto para uso em servidores de testes.
5. Ter uma interface gráfica para uso do desenvolvedor.
6. Suportar execução distribuída de testes. Ainda não preciso disso mas estou prevendo que precisarei no futuro.
7. Integração com algum software de lint (ex. pylint).
8. Integração com sistemas de teste de cobertura (ex. coverage).
9. Emitir relatório sobre a qualidade do código (baseado na análise do lint), da cobertura dos testes, do tempo de execução dos testes e, em caso de falha, o traceback do erro.
10. Permitir a execução do pdb caso algum teste falhe.
11. Integração com o mecanismo de persistência de objetos (ORM, OODBMS, …) para permitir a criação de savepoints (aka subtransactions) para testes que precisam construir cenários com muitos objetos. Criando esses savepoints um teste poderia fazer um rollback parcial dos objetos criados/alterados pelo teste executado anteriormente. Eu usei essa integração na Objective e garanto que era muito útil além de diminuir o tempo para execução dos testes de forma colossal.

Modelo da interface gráfica dessa aplicação^*.

Esse é o sistema dos meus sonhos e acredito que, conforme o desenvolvimento do meu projeto avance, eu acabe com algo muito parecido nas mãos. Mas se alguém quiser começar antes eu prometo que usarei e, caso me sobre tempo, ajudarei no desenvolvimento

Quem sabe um dia esse carinha trabalhe integrado a um SCM, ao reviewboard e a um sistema de issue tracker… mas chega de viagem, hora de voltar ao trabalho.

^* Note que ainda está faltando uma Treeview para selecionar o módulo cujo código fonte será exibido.

Pra não dar muito trabalho pra escrever esse artigo não vou ficar fazendo links para a discussão que se iniciou com um post sobre o modelos de negócios com SL. Para quem quiser mais detalhes sigam os links do br-linux.org.

O Software Livre apareceu na minha vida a partir do ano 2000 quando fui contratado pela Conectiva S/A (Mandriva) para integrar a equipe de P&D e trabalhar no desenvolvimento do Conectiva Linux. Poderia dizer que eu já mexia com isso antes mas estaria exagerando já que o máximo que eu fazia era disponibilizar os códigos fonte de meus softwares (feitos em Clipper Summer’87 :)) para meus clientes. São só 8 anos mas tempo o suficiente para entender e ver muitas coisas acontecerem.

De 2000 pra cá passei por muitas empreitadas e passei por lugares onde recebi apelido de ‘xiita’ (por causo do entusiasmo pelo SL) e sou tratado como ‘traidor do movimento’ quando digo que sonho em ter um Apple rodando OS X.

Fazendo uma retrospectiva por todos esses 8 anos eu posso perceber uma certa coerência entre meus ideais e minhas atitudes. Evidentemente algumas idéias mudaram e outras atitudes também mas a essência permaneceu a mesma: Eu gosto de software bom.

Ser livre ou proprietário é só um dos critérios (importantes) que uso para avaliar a qualidade de um software. Se eu gosto de um software proprietário e acho que o valor cobrado por ele é correto eu certamente pagarei. Já comprei licenças de software para meu antigo Palm, licença para o Nero Burning ROM, anti-vírus NOD32, e até mesmo a do Windows OEM que veio com meu Notebook (nesse caso eu não acho o software bom, mas ele era necessário para rodar o Nero :))… mas jamais comprarei uma licença do Microsoft Office (detalhe: sou fanático por planilhas eletrônicas desde o 1-2-3 e acho o Excel a melhor planilha que existe atualmente).

Eu também tenho alguns softwares piratas rodando na máquina com Windows (principalmente a alternativa ao GIMP :P) e isso é algo que me deixa desconfortável pois sou daqueles radicais que acham que pirataria é contravenção. Prometo adquirir esse software assim que surgir uma promoção para estudante (ele é muito caro mas vale o preço).

O critério do software bom serve para definir minhas escolhas no uso de um software mas faço toda a força do mundo para que os softwares que desenvolvo sejam Livres ou, no mínimo, OpenSource. Mesmo que seja um software desenvolvido no trabalho. Meu histórico de desenvolvimento de sofware livre é pequeno e nenhum deles “emplacou” mas isso não fez com que eu deixasse de acreditar no modelo pois, afinal, eu os desenvolvo principalmente para os meus propósitos (ou para os propósitos da empresa onde trabalho). Se outros acharem útil e quiserem colaborar ótimo mas caso contrário está bom também.

É muito difícil ganhar dinheiro desenvolvendo e vendendo software livre e quando esse dinheiro começa a entrar nunca estará na mesma proporção da entrada financeira de um software proprietário. Mas ao tentar ganhar a vida “vendendo” software o autor precisará muito mais do que código para se sustentar. Ele precisará de muita criatividade, muita paciência, um bom planejamento, uma pitada de sorte e uma visão realista do mundo.

Idéias não faltam para que isso dê certo e muitas empresas espalhadas pelo mundo já comprovam isso, mas no Brasil a coisa ainda é um pouco mais complexa pois uma série de fatores como educação deficiente, preguiça, ‘malandragem/jeitinho’, ‘lei de Gerson’ e muito discurso dificultam o desenvolvimento de um modelo baseado no SL aqui no Brasil.

O próprio autor do manifesto citado no artigo do br-linux.org era um dos que passavam horas escrevendo seus “e-mails-discursos” ao invés de trabalhar no desenvolvimento de seu software. O software que ele desenvolveu também poderia ter sido feito em forma de colaboração para outros projetos (plugin pro Webmin?) mas não foi. Como um desenvolvedor pode querer colaboração para seu projeto se nem ele foi capaz de (ou se interessou em) colaborar com outro projeto?

Com relação à contribuição e à comunidade brasileira de SL: esqueça. A comunidade brasileira de desenvolvedores de SL é quase uma obra de ficção. O brasileiro quer “parasitar” o software livre. Ele quer usar o software “de graça” e não fazê-lo ou melhorá-lo. É evidentemente temos grandes excessões mas elas servem apenas para confirmar a regra.

Os brasileiros acham que usar SL e ficar repetindo as palavras do Stallman bastam, mas esquecem que software é feito de código e que sem ele nada vai existir ou melhorar.

Portanto os meus conselhos para quem quiser se envolver com o desenvolvimento de SL são:

1. colabore com algo que já exista!
2. se não existir ou não for possível colaborar: faça!
3. faça mais!
4. escreva, documente e desenvolva em inglês. Não use a língua portuguesa para não limitar os seus colaboradores a 0.
5. lance o software (divulgue-o em todos os lugares possíveis).
6. use-o.
7. não espere nada em troca.
8. não espere nada em troca mesmo (principalmente de brasileiros).

Acredite, você será recompensado.

Update: Eu reli o meu texto depois de publicá-lo e percebi que, apesar de ter citado a existência de desenvolvedores brasileiros que colaboram com SL, eu não dei a ênfase necessária (e até peguei um pouco pesado demais). Pois bem, existem desenvolvedores brasileiros de SL e a quantidade deles vêm aumentando recentemente mas navegando por sites especializados como o ohloh.net ou o sf.net é possível ver que ainda falta muito pra gente ser notado no meio das comunidades de SL.

Uma das coisas mais legais do universo do “Software Livre” são os eventos organizados para reunir fisicamente os colegas com os quais a gente trabalha somente pela Internet. Mais legal ainda é quando o evento tem um formato levemente diferenciado e promove muito mais a confraternização e o bate-papo entre os participantes do que as apresentações (que em alguns casos podem ser chatíssimas).

Agora imagina esse mesmo evento em um lugar paradisíaco, cercado de belas praias e com muito sol. Bom, né? Mas não acaba por aí.

Pense neste mesmo evento com participantes nacionais e internacionais que são famosos por trabalharem em projetos importantes de Software Livre.

Não é um evento utópico. É a Bossa Conference’08 que vai acontecer em Porto de Galinhas, PE e é promovido pelo INdT no intuito de se tornar o maior evento técnico de Software Livre e mobilidade do país.

Pra se ter uma idéia do que vocês irão encontrar lá (presenças já confirmadas):

• Aaron Seigo - KDE4 / Qt4 em dispositivos móveis
• Alp Toker - Webkit
• Carl Worth - Cairo
• Denis Kenzior - Trolltech
• Harald Welte - ex-desenvolvedor do Openmoko
• John “J5″ Palmieri - D-Bus, OLPC e Tubes (RedHat)
• Lennart Poettering - Pulseaudio
• Marcel Holtmann - BlueZ
• Marcelo Oliveira - Canola (INdT)
• Øyvind Kolås - Clutter (Interfaces 3D)
• Rasterman - EFL (criador do Enlightenment)
• Zack Rusin - KDE, Mesa e Galium3D

E existe uma lista com outros nomes que precisam ser confirmados que incluem nomes de peso na comunidade. É só acompanhar o site e esperar novidades.

Depois de um primeiro semestre totalmente estranho em que eu não estava me sentindo bem profissionalmente, nem pessoalmente, comecei a organizar as minhas férias que seriam tiradas no mês de agosto e me permitiriam refletir sobre a vida, o universo e tudo mais por cerca de 30 dias.

Nunca tinha tirado férias em condições perfeitas até o agosto deste ano. Sempre faltou dinheiro, ânimo, ou planejamento para que as férias realmente servissem aos seus propósitos mais importantes: relaxar e refletir.

Fiquei 15 dias na casa da minha mãe. Fazia mais de 2 anos que não ia a São José do Rio Preto, onde ela, minha avó e muitos amigos moram, para relembrar momentos e reencontrar pessoas importantes em minha vida. Sete desses 15 dias eu passei “solteiro” pois meu filho e esposa seguiram viagem para São Paulo e Curitiba. Fiquei liberado para fazer tudo o que queria.

Durante esse período eu concluí que precisava passar para outras pessoas várias atividades que eu desenvolvia para que sobrasse tempo de tocar outro projeto que eu julgava mais importante, trabalhar melhor e ter um tempo para a família. Foi assim que resolvi me aposentar das atividades da Python Brasil. Agora ela está nas mãos de uma associação (quase) legalmente estabelecida e presidida pelo Luciano Ramalho que é um grande amigo e é extremamente qualificado para exercer essa função.

Ainda tem bastante gordura pra cortar e muita coisa chata que ocupa muito tempo mas sou obrigado a fazer (a porcaria da faculdade).

Nessa viagem eu também tive a certeza de que eu não gosto de morar aqui no Nordeste (especificamente em Recife) e que meu lugar é mesmo no Sul/Sudeste onde vivi minha infância, adolescência e onde formei minha família. Não é fácil mudar hábitos e atitudes que me acompanharam durante toda a construção do meu caráter simplesmente mudando entre lugares com culturas tão diferentes. Se existisse um culpado por minha não-adaptação à vida daqui certamente seria eu e não Recife/NE.

Ficou estabelecido então que 2008 será o ano da preparação para meu retorno pra casa. Torço para que todos os planos e idéias que eu tenho para essa mudança dêem certo pois, desta forma, eu poderia até mesmo continuar trabalhando no (ou para o) INdT. A satisfação que eu sinto em trabalhar para o INdT tem sido a única coisa que me segura aqui com toda a família. Se lá não fosse o melhor lugar onde já trabalhei eu teria voltado para casa antes.

No mês de dezembro fiz coisas legais também: confraternização da empresa num hotel supermassa, término de mais um semestre na porcaria da faculdade onde eu estudo, presentes muito legais (HD externo da esposa, DVD triplo Blade Runner de amigo secreto, DVD duplo Kraftwerk Minimum-Maximum do cunhado, livros Deus um delírio e The Long Tail de mim mesmo, Pendrive 1GB da Kingston também de mim mesmo, caixinha de quebra-cabeça da minha irmã, …) e fui no show do Paul van Dyk na nox aqui em Recife (foi tão massa que poderia facilmente virar um post separado aqui no blog).

Também já consegui autorização de verba para adquirir um eBook Reader da Sony (PRS-505) e um celular *bom* (N95 ou iPhone) para substituir o meu velho e detonado N-Gage NG.

Esse post é a versão Web de um e-mail que eu enviei para a lista de discussões da Python Brasil apenas coloquei os links (e fiz umas pequenas correções) para facilitar o acesso aos sites:

Pessoal,

O site BR-Linux lançou a pesquisa
“Favoritos da Comunidade Linux 2007″ que tenta coletar a visão dos
brasileiros sobre o universo do Linux e do Software Livre em geral.
O formulário está disponível em:

http://br-linux.org/linux/favoritos2007

A Associação Python Brasil está colaborando com a pesquisa e doou 3
kits contendo 1 livro Aprendendo Python, 1 camiseta do Plone e 1 DVD
com os vídeos das palestras das PyConBrasil 2005 e 2006 (o de 2007
ainda não saiu :)) cada.

Mas além disso podemos aproveitar a pesquisa para mostrar a força da
nossa comunidade aqui no Brasil apontando o nosso site como o
melhor site nacional, nossa lista de discussões[2] como melhor fórum
ou lista de e-mail, a PyConBrasil como melhor evento nacional, a
Associação Python Brasil na categoria grupo de usuários ou organização
livre nacional, e a linguagem Python como linguagem favorita.

Ufa, tem tanta coisa legal na nossa comunidade que permite a nossa
participação em 5 categorias diferentes!  

Além dessas categorias eu ainda indiquei “Aprendendo Python” como o
melhor livro.

Lembrando que nós temos mais de 2000 pessoas que assinam essa lista,
podemos obter bons resultados por lá  

Valeu,
Osvaldo

Espero que colocando essa mensagem aqui ela chegue às pessoas que gostam de Python mas não tem tempo de acompanhar a lista.

OpenBOSSA Labs and INdT proudly announce: Mamona 0.1!

Mamona is an embedded Linux distribution for ARM EABI. The main goal of the Mamona Project is to offer a completely open source alternative for the Maemo Platform.

We’re currently targeting the Internet Tablet devices from Nokia (N800 and N810) but we’ve plans to support more ARM-based devices in the future.

You can find more informations about the project here.

pt_BR

O OpenBOSSA Labs e o INdT orgulhosamente anunciam: Mamona 0.1!

Mamona é uma distribuição Linux para dispositivos embarcados que usam ARM EABI. O objetivo principal do projeto Mamona é oferecer uma alternativa completamente open source à plataforma Maemo.

Atualmente nós estamos visando os dispositivos Internet Tablets da Nokia (N800 e N810) mas nós temos planos de dar suporte para mais dispositivos baseados em ARM no futuro.

Você pode encontrar mais informações sobre o projeto aqui (inglês).

O laboratório de software (OpenBossa) do INdT, onde trabalho, está organizando treinamentos sobre a plataforma Maemo (Linux, Internet Tablets, Nokia, 770, N800, N810, …) totalmente “di grátis”.

Os treinamentos ocorrerão nos dias 20 e 21 de Novembro em Joinville, SC (na mesma SOCIESC onde tivemos a PyConBrasil 3). Nos dias 26 e 27 de Novembro o mesmo evento ocorrerá em Manaus na UFAM.

Ontem eu me aposentei da moderação da lista de discussões Python Brasil. Quem vai assumir o meu cargo vai ser o meu ajudante Pedro Werneck. E ele, por sua vez, será ajudado pelo recém “contratado” Andrews Medina.

O ritual de passagem da ferramenta de moderação usada na Python Brasil já foi até concluído.

Quando comecei na lista éramos 134 assinantes e estamos com 2099 agora. Antes éramos só um grupo de amigos e entusiastas. Hoje continuamos amigos e entusiastas mas também somos associados de uma organização formal que vai ter muito mais força para levar adiante os nossos projetos.

Essa aposentadoria é um dos passos rumo à minha redução de atividades na comunidade Python Brasil e de Software Livre em geral. Notem que irei reduzir consideravelmente as minhas atividades mas sempre serei um entusiasta de Python e do Software Livre em geral.

Essa decisão também tem uma relação com a chegada dos meus trinta anos de idade e tomou a sua forma final durante as minhas últimas férias.

Quero diminuir o número de coisas que faço para poder fazer melhor algumas outras coisas que andavam meio abandonadas: cuidar da família, desenvolver um projeto de software que ocupa meus pensamentos há muitos anos e fazer o meu trabalho melhorar aqui na empresa.