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).

Não poupo críticas ao Django, este excelente framework em Python tem me ajudado a concluir todos meus projetos relacionados a web, se tornou o padrão de desenvolvimento da Trianguli, empresa onde trabalho. O lema do Django “The web framework for perfectionists with deadlines” faz muito sentido e tem auxiliado muito a Trianguli a cumprir seus deveres para com seus clientes.

Confesso que nunca gostei muito dos módulos de formulários (forms) do Django, sempre optei em fazer meu formulários na mão para adapta-los melhor ao layout e não correr riscos de ter algum resultado inesperado de layout, mas os formulários são uma mão na roda para validação e até melhorar a segurança do site. Outro dia estava realizando uma pesquisa rotineira e acabei encontrando o Uni-Form, um conjunto de CSS e JavaScript (depende do jQuery) que cria formulários de uma maneira mais elegante, incluindo sua validação. O Uni-Form é altamente personalizável e seu código está muito bem elaborado e validado via W3C. Pesquisando mais um pouco, encontrei o django-uni-form, que faz a integração do Uni-Form ao Django, permitindo seu uso rapidamente em um projeto Django existente, com poucas modificações no código. O django-uni-form pode substituir o modelo de formulários do Django e trabalhar com divs ao invés de tabelas. Com poucas alterações no CSS, é possível ter um ganho de tempo significativo em projetos Django que exigem muitos formulários.

Sua instalação e uso são bastante simples. Basta fazer o download na página do django-uni-form no GitHub e descompactar o diretório uni-form para dentro do projeto Django. Depois basta adicioná-lo no INSTALLED_APPS no settings.py (seuprojeto.uni_form) e por último copiar os arquivos que estão dentro do “media” (uni-form.css, uni-form-generic.css, uni-form.jquery.js) para seu diretório de arquivos estáticos.

Seu uso é simples, no template dos formulários basta adicionar as linhas referentes ao CSS do uni-form mais o uni-form.jquery.js (é necessário ter o jQuery) e logo no início do template incluir a tag {% load uni_form %}.

Feito isso, basta chamar seu formulário como {{ form|as_uni_form }}. Se der tudo certo, o resultado será algo como:

E a validação dos campos terá um resultado como o abaixo:

Você pode personalizar o estilo de cores editando os arquivos CSS do uni-form.

Fica a dica!

Fiquei bastante sumido durante as duas últimas semanas. Estou me dedicando em adaptar alguns projetos para o Django 1.0, versão muito esperada que foi lançada recentemente. Por serem projetos de produção, optei por sempre respeitar e seguir as versões estáveis do Django, mesmo sabendo que existe um comprometimento grande por parte dos desenvolvedores em relação a estabilidade e segurança das versões em SVN. Em laboratório, mantenho as duas versões (a estável e a SVN, utilizada para testar novas features e avaliar as melhorias).

O bom de fazer essa atualização de código é aproveitar a oportunidade e colocar em prática um ‘code refactoring‘, otimizando as aplicações e aproveitando a oportunidade para corrigir bugs e padronizar diversas funções.

O Django 1.0 tem várias novidades e muda muita coisa em relação ao 0.96, por isso nem sempre um código feito para a versão 0.96 vai funcionar de primeira na 1.0, mas a adaptação vale a pena, pois a nova versão está sensacional. Como eu já estava acompanhando as evoluções através do SVN, a migração não está sendo difícil porque já sei tudo que mudou, mas no meu caso é demorada porque diversos pontos das aplicações que mantenho são complexas e dependem de outras aplicações externas. A integração precisa ser muito bem testada e depurada antes de subir para produção e esse processo toma muito tempo e exige total dedicação.

Por este e outros motivos, talvez fique um pouco ausente das listas e participação na comunidade durante as próximas semanas. Tenho muito trabalho pela frente, mas estou muito satisfeito por ter escolhido o Django como ferramenta de trabalho. O dia a dia está me provando o quanto esse framework é poderoso.

Migrei todos meus projetos pessoais que estavam em Subversion para o Bazaar-vcs e tenho utilizado esse excelente VCS a alguns meses. Uma das coisas que senti falta foi a integração com o meu editor favorito, o Emacs. No pacote emacs-snapshot do Ubuntu, o editor já vem com suporte pronto ao Svn, porém ainda não tem uma integração para o Bazaar. Procurei por diversos lugares alguma receita pronta para integrar o Bazaar ao Emacs e facilitar algumas tarefas de desenvolvimento. Testei várias soluções sem muito sucesso, até que cheguei ao site DVC, que disponibiliza um pacote que integra não apenas o Bazaar, mas outros VCS ao Emacs, como GIT, Mercurial, GNUArch entre outros.

Para instalar, pegue a última versão do DVC em um branch Bazaar:

bzr get http://bzr.xsteve.at/dvc/

Entre no diretório e digite autoconf para que seja criado o configure. Depois rode o configure e make.

Agora basta adicionar o dvc-load.el ao seu ~/.emacs com a seguinte linha:

(load-file "/caminho/para/o/dvc/dvc-load.el")

Pronto! Quando abrir novamente o Emacs, já terá a integração com o Bazaar. Para testar, basta ir até algum diretório de projeto Bazaar e digitar M-x bzr-status

Tem muita gente falando do Google App Engine, realmente a idéia é bastante interessante e não é complicado para desenvolver uma aplicação (se você tiver conhecimentos de Python). Aproveitar todo o poder de processamento do Google para criar páginas dinâmicas sem se preocupar com a infra estrutura de alta disponibilidade é o sonho de qualquer desenvolvedor. Com a versão gratuita do Google App Engine já é possível desenvolver boas aplicações e logo o Google oferecerá uma versão premium (paga) onde será possível comprar mais recursos.

Criei uma pequena aplicação no Google App Engine usando Django, meu laboratório virtual, ainda não tem nada de útil porque está faltando tempo, mas logo pretendo disponibilizar um tutorial e algumas dicas para melhor aproveitar essa ferramenta.

Se você deseja conhecer melhor o App Engine, o ShowMeDo disponibilizou uma seção com alguns vídeos que explicam passo a passo como criar uma aplicação. Veja os vídeos aqui (em inglês).

Referência.

Aprenda Python

Django Sprint é um evento online, organizado pela comunidade de desenvolvedores Django. O principal objetivo é reunir desenvolvedores de todo mundo para discutir melhorias, tratar correções/bugs e pensar em novos recursos. Se você nunca colaborou com Django, mas tem vontade, essa será sua chance de assumir responsabilidades com o grupo e pegar alguma tarefa para trabalhar em cima.

Se deseja participar, basta adicionar seu nome no Wiki.

O evento acontece em um canal de IRC, informado no Wiki acima.