Quem gosta de shell já deve ter pensado algo do tipo: e se eu pudesse usar os serviços do Google via linha de comando? Pois é, isso agora é possível. O Google surpreendeu mais uma vez e lançou o GoogleCL,  uma coleção de  ferramentas feitas em Python para administrar via shell alguns serviços como Blogger,  Agenda, Contatos, Documentos, Picasa e Youtube.

Veja o que é possível fazer com essa ferramenta:

1. Criar um post no Blogger: $ google blogger post –title “Título” “Conteúdo do Post”
2. Criar um compromisso no calendário: $ google calendar add “Almoço com a família at noon tomorrow” (a data e alguns parâmetros precisam ser em inglês)
3. Exportar os contatos para um arquivo CSV: $ google contacts list name,email > contatos.csv
4. Criar um álbum no Picasa e adicionar todas as fotos de um diretório no HD: $ google picasa create –album “Viagem para Manaus” ~/photos/viagem_manaus/*.jpg
5. Enviar um vídeo do seu HD diretamente para o Youtube: $ google youtube post –category Screencast aprenda_python.avi

Como instalar

Na página http://code.google.com/p/googlecl/ é possível encontrar as versões .tar.gz e .deb (Debian/Ubuntu). É necessário instalar a dependência python-gdata para que a ferramenta funcione. No Ubuntu, um sudo apt-get install python-gdata resolve o problema.

Como funciona

A ferramenta faz o acesso via OAUTH. Na primeira vez que você digitar o comando apropriado, será solicitado um acesso pelo navegador para fazer a autorização. Você deverá copiar e colar aquela URL no navegador, fazer a autorização, depois voltar no shell e dar um enter para continuar. Só precisa fazer isso uma vez por aplicação (Blogger, Calendar, Youtube). Com o acesso feito via OAUTH, não é necessário digitar a senha no terminal, então a senha não ficará gravada em nenhum lugar.

A lista dos comandos e opções para cada serviço pode ser obtida em http://code.google.com/p/googlecl/wiki/ExampleScripts

Gostei muito dessa ferramenta, permite inclusive a criação de diversos scripts para automatizar determinadas tarefas, como adicionar um lembrete na agenda, enviar um lote de fotos para o Picasa ou vídeos para o Youtube com poucas linhas de código. Fica a dica!

Estou desde o começo deste ano acompanhando o hype dos bancos de dados orientados a documento, também chamado de NoSQL (embora não goste muito deste termo). Como bom curioso, resolvi testar algumas variações como o CouchDB e MongoDB, onde acabei me identificando mais com o segundo. Gostei da praticidade e rapidez em fazer as coisas com ele, também a performance me chamou muito a atenção, tem uma boa biblioteca Python e a documentação é muito objetiva, com exemplos de uso. Esses pontos foram decisivos para a escolha.

Com um banco de dados orientado a documentos, não existe a necessidade de criar o modelo das tabelas, basta definir um documento (estilo JSON) e inserir na base. Esses documentos podem ter campos a mais ou a menos dependendo da necessidade e tudo pode ser indexado e encontrado facilmente.

Estou trabalhando em um projeto onde é necessário indexar uma grande quantidade de informações e documentos. O problema é que muitos documentos não seguem um padrão e existe a necessidade de estar alimentando a base a todo instante com novas informações. Já desenvolvi modelos de busca neste estilo utilizando o Xapian, que é uma excelente ferramenta. Porém a performance fica bastante prejudicada quando a base é atualizada várias vezes ao dia, pois o Xapian mantém muito bem sua performance quando sua base (Quartz) está com os índices devidamente criados e compactados. Ficar atualizando esses índices o tempo todo prejudica a aplicação.

Fiz um teste importando todos esse volume de informações em uma base do MongoDB. Fiquei surpreso pela rapidez em importar os dados, cheguei a acreditar que tivesse acontecido algum problema durante a importação. Mas mexendo no banco, pude observar que tudo foi importado. Com algumas ferramentas desenvolvidas em Python, é possível alimentar a base a todo instante com novas informações e percebi que isso não atrapalha a performance das consultas. Mais um ponto a favor do MongoDB.

A aplicação frontend está sendo desenvolvida em Django, que não suporta oficialmente o MongoDB, mas utilizando módulos externos, é possível fazer o Django falar com MongoDB sem muita dificuldade. Cheguei a testar o MongoEngine e outras receitas (como nos posts integrating MongoDB and Django e Python, Django e MongoDB) mas para meu caso, foi mais fácil usar as ferramentas desenvolvidas internamente em Python para inserir e buscar valores da base.

De uma forma geral o MongoDB é uma ótima solução para armazenar e buscar um volume grande de documentos. Não posso dizer que é melhor ou pior que um banco de dados relacional, tudo depende do modelo de negócio, da aplicação e do que pretende fazer com as informações. Cada caso é um caso, seria muito injusto em dizer que vou substituir todas minhas aplicações de banco de dados relacional para o banco de dados orientado a documentos. Mas os testes serviram para mostrar não é apenas um hype, os bancos orientados a documentos podem ser uma ótima solução para casos mais complexos, que não dependem apenas de um simples CRUD.

De bônus, vale a leitura do post Choosing a non-relational database; why we migrated from MySQL to MongoDB, estou totalmente de acordo com as opiniões do autor e passei por situações bem parecidas.

Nos próximos dias publicarei mais informações sobre MongoDB e um pequeno tutorial. Se desejar ser informado, aproveite para assinar o conteúdo desse blog, basta inserir seu e-mail no campo logo abaixo deste post (e-mails só serão enviados quando existir atualização de conteúdo do blog).

Em novembro de 2009 publiquei minhas impressões sobre o CouchDB, já que estou desde então estudando banco de dados NoSQL para aplicações bem específicas. Permaneci por alguns meses estudando o CouchDB, que é mantido pela Apache Foundation e realizei diversos testes. O banco de dados se demonstrou bem eficiente para o modelo de aplicação que estou trabalhando, no caso a performance foi bem superior ao MySQL, já que tenho um volume de informações enorme e o fato de trabalhar com documentos — para esta minha aplicação específica — foi o que me chamou a atenção para um banco de dados estilo NoSQL.

Resolvi dar uma espiadinha em outro banco de dados no mesmo estilo, o MongoDB. Instalei no meu ambiente e realizei os mesmos testes. No CouchDB demorei muito tempo para realizar algumas operações simples, enquanto que no MongoDB, realizei  os mesmos procedimentos de maneira mais rápida e sem me enroscar nas configurações e na manutenção do banco. Em termos de performance — no caso da minha aplicação — os dois bancos se mostraram praticamente iguais.

Embora o CouchDB também tenha bibliotecas para trabalhar em Python, a do MongoDB parece ser mais simples e direta. Pelo menos me identifiquei melhor com sua biblioteca e consegui adaptar minha aplicação rapidamente para trabalhar com o MongoDB, descartando o tempo que levei para o aprendizado e leitura das documentações, demorei menos tempo para desenvolver um script totalmente funcional para MongoDB do que para CouchDB. Isso não quer dizer que o CouchDB seja ruim e ainda não tenho o volume de informações necessárias para fazer um benchmark ou dar opinião sobre qual é melhor.

É muito simples trabalhar em Python com o MongoDB, veja um exemplo:

#!/usr/bin/python

from pymongo import Connection
import datetime

con = Connection('localhost', 27017)
db = con['teste01']

user = {"nome":"Fulano",
        "sobrenome":"de Tal",
        "email":"fulano@detal.net",
        "data_inclusao": datetime.datetime.now()}

# Insere
users = db.users
users.insert(user)

O código acima cria um banco no MongoDB (veja as instruções para instalação e veja também a documentação Python para MongoDB) e insere um registro no dict user para o banco de dados. Como o trabalho é feito em um banco de dados não relacional, não há necessidades de definir o layout da tabela. O layout é definido à medida que os documentos são definidos e é flexível, podendo ser alterada a qualquer momento.

A pesquisa na base de dados pode ser feita com o seguinte código:

#!/usr/bin/python

from pymongo import Connection

con = Connection('localhost', 27017)
db = con['teste01']

# Pesquisa um só
users = db.users
a = users.find_one({"email":"fulano@detal.net"})
print a

# Pesquisa varios
for u in users.find():
    print u['nome'], u['email']

Entre o CouchDB e o MongoDB eu me identifiquei mais com o segundo. Consegui fazer as tarefas de forma mais rápida e eficiente. Mas o primeiro também é um ótimo banco, merece ser estudado. Provavelmente continuarei meus estudos e desenvolvendo a pesquisa em cima do MongoDB, pois tem uma documentação um pouco melhor e mais ferramentas para trabalhar na base de dados.

O próximo passo é integrar uma aplicação Django no MongoDB. Mas isso é motivo para outro post!

Não posso deixar de divulgar a grande iniciativa do Luiz Eduardo Borges em disponibilizar a segunda versão do livro Python para Desenvolvedores sob licença Creative Commons. Ainda não li todo o livro, mas pelo índice já dá para perceber que é um grande material, leitura indispensável para programadores de outras linguagens que desejam conhecer Python ou até mesmo programadores Python que desejam aperfeiçoar seus conhecimentos.

Uma leitura técnica como esta, além de revigorante é bastante inspiradora. Por mais experiência que alguém tenha sobre uma determinada tecnologia, ao ler um ótimo material como este, é possível aprender novas técnicas ou melhorar procedimentos já utilizados. Então vale muito a leitura, além de tudo está sob licença CC.

O download do livro pode ser feito na página Python para Desenvolvedores no próprio site do Ark4n ou se tiver alguma dificuldade no download, fiz um mirror do livro. Clique aqui para baixar do mirror.

Em uma apresentação do Luciano Ramalho, observei que estava utilizando o Sphinx (não confunda com o SphinxSearch) para gerar sua documentação e apresentação. Logo que voltei para o escritório, resolvir dar uma fuçada na ferramenta e simplesmente caiu como uma luva. É uma maneira bastante simples de criar documentações, principalmente de projetos desenvolvidos em Python. Sempre utilizei diversas técnicas para documentar meus projetos, desde Wiki, Texinfo e até LaTex, mas só de pensar em criar toda uma documentação em LaTeX, desanima um pouco.

O Sphinx nada mais é que uma ferramenta que pega um documento escrito em reStrucutredText, compila e gera saída em diversos formatos, como html e até mesmo LaTeX (que pode ser facilmente transformado em PDF). É realmente muito rápido e simples criar uma documentação, que pode estar dentro dos códigos Python. A linguagem de marcação “rst” é simples de ser lida e escrita, não tem todas as complexidades (embora bem completas) de um LaTeX.

Passei a fazer um teste com a ferramenta e adotei em alguns projetos, depois de um tempo utilizando, já posso afirmar que é bem simples e eficiente e toda documentação (que são arquivos texto, seguindo marcação rst) pode ser facilmente controlada por um Bazaar ou SVN (ou outro de sua preferência).

Se você gosta de Emacs, existe um suporte rst para Emacs, o que torna a tarefa de documentar ainda mais facil. Com vários atalhos e funcionalidades, documentar nunca foi tão rápido e menos chato.

Mais informações: Sphinx Python Documentation Generator

Fazer gráficos em Python não é uma tarefa difícil. Existem várias bibliotecas com este objetivo, como a Matplotlib, SciPy e outras proprietárias como ChartDirector. As duas primeiras são bem científicas e muito bem documentadas, a terceira é uma solução proprietária, mas oferecer gráficos de vários formatos.

O grande problema da Matplotlib e SciPy é a customização. Seus gráficos padrões são, digamos, não muito bonitos, embora atenda muito bem o seu objetivo principal. Uma outra alternativa é o Gnuplot, que também é excelente, mas também cai no problema da customização para exibir gráficos mais elegantes em sites que muitas vezes são gerados on the fly. O problema dessas bibliotacas é a necessidade de muito código para fazer gráficos simples, sem contar no trabalho de customização para criar gráficos mais bonitos, com degradês e outras frescuras que alegram os olhos dos visitantes.

Descobri a pouco tempo o CairoPlot, uma biblioteca bastante simples, criada por brasileiros e que utiliza a PyCairo para criar seis tipos de gráficos, incluindo gráficos em pizza, donut, barras, linhas, etc. O que mais me impressionou na biblioteca é a simplicidade, com poucas linhas é possível gerar gráficos bonitos e elegantes como o exemplo abaixo:

É uma mão na roda para quem precisa criar gráficos on the fly em sites ou utilizá-los em apresentações.

O download pode ser feito através de um branch do Bazaar, da seguinte forma:

bzr branch lp:cairoplot/1.1

Depois de baixar, basta seguir os exemplos no site da CairoPlot ou estudar o arquivo test.py. Se você conhece Python, em poucos minutos estará criando seus próprios gráficos.

Mais informações: http://linil.wordpress.com/2008/09/16/cairoplot-11/

Post relacionado: Utilizando o Bazaar VCS

Python é uma linguagem de programação que está crescendo muito. O mercado está aquecido e faltam bons profissionais. Conheço algumas empresas (algumas de grande porte) que estão a procura desses profissionais, com salários e benefícios interessantes, mas a tarefa de encontrar esses profissionais nem sempre é muito simples.

Se você tem interesse em aprender a linguagem e fazer networking com profissionais Python, terá duas oportunidades entre os meses de agosto e setembro em São Paulo e no Rio de Janeiro. São dois eventos, o primeiro será organizado na Impacta em São Paulo e no Rio de Janeiro, o mais esperado de todos: a PyConBrasil que é nada mais e nada menos que o maior evento Python da América Latina.

O evento de divulgação Python na Impacta acontecerá no dia 30 de Agosto em São Paulo e a PyConBrasil nos dias 18, 19 e 20 de Setembro no Rio de Janeiro.

São duas oportunidades imperdíveis!

Para maiores informações, consulte o site de cada evento:

FITI – Fórum Impacta de Tecnologia da Informação

PyConBrasil 2008 no Rio de Janeiro

Estou bastante satisfeito com o Bazaar como sistema de controle de versões em alguns projetos pessoais. Estou bastante satisfeito com ele, em vários pontos estou achando bem melhor que o SVN, que ainda utilizo em alguns projetos.

Como publiquei nesse post, o Bazaar tem alguns recursos que facilitam muito minha vida. Além de ter outros detalhes que me agradam, como ser todo em Python por exemplo. Resolvi criar um ambiente Trac totalmente integrado ao Bazaar, confesso que no começo fiquei bastante perdido porque a documentação não é muito clara, mas com um pouco de persistência consegui fazer o Trac funcionar do jeito que precisava, com o Bazaar perfeitamente integrado. Para evitar a via crucis de outras pessoas, estou publicando esse mini tutorial para fazer o Trac funcionar com Bazaar em um servidor Ubuntu Hardy, utilizando seus pacotes nativos e em cima do mod_python. Lembrando que o Ubuntu já oferece um pacote chamado trac-bzr que possui algumas alterações para rodar o Trac com Bazaar sem precisar ficar adicionando módulos a parte ou mexendo no código do Trac.

Primeiro vamos instalar os pacotes:

aptitude install apache2 libapache2-mod-python trac-bzr

Agora é hora de criar um ambiente Trac. Eu escolhi o diretório /var/trac/projeto para ser o diretório do Trac e /var/trac/bzr para ser o repositório do Bazaar, mas fique a vontade para determinar onde deseja colocá-lo:

mkdir /var/trac
mkdir /var/trac/bzr
trac-admin /var/trac/projeto initenv

Preste atenção que o Trac vai solicitar algumas informações. Preencha da forma que desejar, mas na hora que perguntar o tipo de repositório que deseja, coloque bzr ao invés de svn e informe o caminho /var/trac/bzr quando for solicitado da localização do repositório.

Agora vamos configurar o Trac. É onde tem um truquezinho para fazer tudo funcionar. Adicione no final do arquivo /var/trac/projeto/conf/trac.ini a seguinte linha:

[components]
tracbzr.* = enabled

Feito isso, é hora de configurar o Apache. No /etc/apache2/sites-available/default, adicione o seguinte bloco:

<Location /trac>
SetHandler mod_python
PythonInterpreter main_interpreter
PythonHandler trac.web.modpython_frontend
PythonOption TracEnv /var/trac/projeto
</Location>

Dê um restart no Apache e se tudo deu certo, ao acessar no seu navegador o endereço http://seuservidor/trac, devará ver a tela de início do Trac.

Dai o resto é com você. Sempre que fizer um push no Bazaar para o seu repositório, poderá acompanhar tudo pelo Trac. Fica a dica !

Estou a procura de bons profissionais para trabalharem comigo em alguns projetos que participo. A princípio, necessito de profissioanais com conhecimentos em Python (Django), Webdesigner (HTML, CSS, JavaScript, Ajax e Design em sí) e DBA para banco de dados MySQL. De preferência que seja um candidato que more no eixo São Paulo – Rio de Janeiro ou que tenha disponibilidade de passar alguns dias nessas cidades. Boa parte do trabalho poderá ser feita via Home Office, portanto o canditado deverá possuir uma boa estrutura de trabalho (computador ou notebook e acesso a banda larga) e disponibilidade para viagens esporádicas para São Paulo e/ou Rio de Janeiro. Abaixo os requisitos desejados para essas três vagas:

Comum para todas as vagas:

• Conhecimentos em software livre (de preferência Ubuntu ou Debian);
• Inglês técnico;
• Disponibilidade para viagens em território nacional (e possivelmente internacional);
• Ser organizado, saber trabalhar em equipe e principalmente administrar bem seu tempo quando trabalhando em home office.

Requisitos para o profissional Python Django:

• Estar familiarizado com a estrutura Ubuntu/Debian, saber o básico de empacotamento (DEB);
• Experiência comprovada em desenvolvimento Python e Django (enviar amostras de trabalho);
• Experiência em sistemas de controle de versão (Subversion e Bazaar);
• Conhecimentos de Apache, mod_python e virtual host;
• Entender conceitos de alta disponibilidade e escalabilidade;
• Será um Plus se o canditato possuir certificação LPI;

Requisitos para a vaga de Webdesigner:

• Experiência comprovada em desenvolvimento visual de sites (enviar amostras de trabalhos/portfolio);
• Experiência comprovada em HTML limpo, compatível com as normas W3C e CSS;
• Conhecimentos básicos de JavaScript, de preferência biblioteca jQuery;
• Experiência em desenvolver sites compatíveis para os principais navegadores (Firefox, Safari e Internet Explorer);
• Conhecimento de FTP/SSH;
• Será um Plus se o candidato conhecer o sistema de templates do Django;

Requisitos para a vaga de DBA MySQL:

• Experiência comprovada em MySQL (MyISAM);
• Entender bem conceitos de escalabilidade e alta disponibilidade;
• Experiência com MySQL em Ubuntu/Debian;
• Conhecimentos de sistema de pacotes (DEB);
• Será um Plus se o canditato conhecer o sistema ORM do Django;
• Será um Plus se o candidato possuir certificação LPI nível I e II;

Se você se encaixa com uma das vagas acima, deseja fazer trabalhos de freelancers para uma empresa de startup web,  (e possivelmente ser efetivado se superar expectativas), com salários compatíveis (ou maior, caso você tenha uma boa experiência) envie seu curriculum vitae com referências de trabalhos já desenvolvidos por você para carreira arroba trianguli.com.br. Só serão aceitos curriculums em formato TXT ou PDF. Qualquer outro formato será descartado.

Mais informações:

Estou utilizando o Bazaar VCS a algumas semanas, tanto para avaliar sua eficácia quanto para implementar em projetos que já estou trabalhando. Na minha atuação no Projeto GNU, sempre utilizei o CVS e acostumei com sua maneira de ser. Tinha coisas que não gostava, como o fato de ser apenas cliente servidor. Em outros projetos eu resolvi adotar o Subversion (SVN) e até então era meu sistema de controle de versão favorito.

Com o fato da distribuição Ubuntu utilizar amplamente o Bazaar, fiquei bastante curioso em testá-lo e ver quais eram as principais diferenças com o SVN. Logo no início já gostei de alguns pontos, como:

1. O Bazaar é todo feito em Python;
2. Tem o apoio da Canonical e é utilizado pelo Ubuntu no Launchpad;
3. Possui praticamente todos os recursos do SVN e CVS, só que alguns pontos são melhores;
4. Pode ser utilizado no esquema cliente-servidor ou apenas localmente no seu projeto, sem precisar de servidor;
5. Possui vários plugins que facilitam o trabalho e administração de código;
6. É possível interagir facilmente com as libs Python e escrever suas próprias extensões;
7. É possível integrar o Trac;
8. Possui o Olive, um frontend gráfico para o Bazaar e fácil de mexer;
9. Ao usar remotamente, é possível escolher qual protocolo de transferência, como ssh, sftp, http, ftp, http, etc;
10. A maioria das distribuições já têm o pacote para o Bazaar, assim como plataformas Macintosh e Windows.

Mas também tem alguns pontos negativos, como ainda não ter suporte para a maioria dos IDEs. Eu mesmo não consegui fazer o Emacs funcionar corretamente com o Bazaar, mas confesso que não testei todos os módulos elisp que encontrei na internet.

O seu uso é bastante simples, veja:

anderson@yoda:~/tmp/teste$ touch arquivo1.txt
anderson@yoda:~/tmp/teste$ touch arquivo2.txt
anderson@yoda:~/tmp/teste$ touch arquivo3.txt
anderson@yoda:~/tmp/teste$ bzr init
anderson@yoda:~/tmp/teste$ bzr add
added arquivo1.txt
added arquivo2.txt
added arquivo3.txt
anderson@yoda:~/tmp/teste$ bzr commit -m ‘Primeiro import’
Committing to: /home/anderson/tmp/teste/
added arquivo1.txt
added arquivo2.txt
added arquivo3.txt

Committed revision 1.

Explicando: Criei um diretório (teste), dentro dele criei 3 arquivos vazios. Dentro do diretório, dei um bzr init para criar o repositório, depois adicionei todo conteúdo do diretório (bzr add) e por último, um commit para registrar como primeiro import ao sistema de controle de versões.

Dessa forma é possível trabalhar localmente com um projeto e tê-lo dentro de um sistema de controle de versões. O resto é praticamente idêntico aos outros VCS, sempre que finalizar uma alteração basta dar um commit, veja:

anderson@yoda:~/tmp/teste$ echo “Alteracao em um arquivo” >> arquivo1.txt
anderson@yoda:~/tmp/teste$ bzr status
modified:
arquivo1.txt
anderson@yoda:~/tmp/teste$ bzr diff arquivo1.txt
=== modified file ‘arquivo1.txt’
— arquivo1.txt        2008-04-24 23:05:14 +0000
+++ arquivo1.txt        2008-04-24 23:09:51 +0000
@@ -0,0 +1,1 @@
+Alteracao em um arquivo

E por último, um commit:

anderson@yoda:~/tmp/teste$ bzr commit -m “Mudancas na estrutura do arquivo1.txt”
Committing to: /home/anderson/tmp/teste/
modified arquivo1.txt
Committed revision 2.

Veja o log de alterações:

anderson@yoda:~/tmp/teste$ bzr log
————————————————————
revno: 2
committer: Christiano Anderson <anderson@gnu.org>
branch nick: teste
timestamp: Thu 2008-04-24 20:10:24 -0300
message:
Mudancas na estrutura do arquivo1.txt
————————————————————
revno: 1
committer: Christiano Anderson <anderson@gnu.org>
branch nick: teste
timestamp: Thu 2008-04-24 20:05:14 -0300
message:
Primeiro import

Se quiser colocar o conteúdo desse repositório em algum servidor para que outras pessoas trabalhem, mas utilizando o sftp, basta:

bzr push sftp://usuario@servidor/path/para/repositorio

Depois para outras pessoas fazerem o checkout:

bzr co sftp://usuario@servidor/path/para/repositorio

e a partir daí trabalhar normamente com os bzr update e bzr commit para mandar novamente para o servidor. É possível também fazer commits offline de pois fazer um merge com o branch do servidor, para isso basta um

bzr commit –local

Fica a dica!