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.

Participei hoje do SP Python Day, evento organizado pelo Fórum Impacta de Tecnologia da Informação, realizado nas dependências da Faculdade Impacta. A galera participou em peso, lotando 3 auditórios da faculdade (um principal com os palestrantes e outros dois com transmissão simultânea). Foi muito bom reencontrar os amigos e ver o grande interesse do público na linguagem Python.

Apresentei sobre Django e Google App Engine, palestra que seria do Andrews Medina, que não conseguiu viajar para São Paulo a tempo. A palestra foi bem introdutória e teórica, mostrando o que o Django é capaz de fazer. Infelizmente não deu tempo de mostrar em tempo real como se cria uma aplicação em Django, mas fica para próxima oportunidade.

Se você participou da palestra e deseja obter os slides, segue abaixo com link para download.

Download do PDF

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:

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

Os frameworks para desenvolvimento web como o Django possuem um ótimo ORM, facilitando muito a criação de aplicações rápidas e eficientes. Da mesma forma que facilita o desenvolvimento, atrapalha em alguns pontos, como por exemplo se o desenvolvedor desejar utilizar mais de um banco de dados para a mesma aplicação. Embora seja possível fazer, as alterações no settings e no código fogem um pouco dos padrões do framework.

Existe uma forma bastante simples para dividir a carga do banco de dados entre vários servidores sem mexer em nada na aplicação. As alterações são feitas diretamente no banco de dados e ficam totalmente transparentes para o framework, é uma mão na roda para escalar melhor as aplicações. O MySQL possui um storage engine chamado Federated, que é o responsável por acessar tabelas remotas como se fossem tabelas locais do banco de dados, digamos assim, funciona como uma espécie de NFS mas para tabelas do MySQL.

Para fazer a solução funcionar, primeiro passo é verificar se os seus servidores MySQL suportam o engine Federated. Para isso, basta o comando show engines; Se encontrar a linha FEDERATED YES, é sinal que o seu banco suporta.

Em segundo lugar, basta criar no seu banco uma tabela com o mesmo layout da tabela que deseja acessar remotamente. O layout precisa ser idêntico, senão não funciona. No final, basta definir como engine Federated e passar os parâmetros de acesso, algo como: ENGINE=FEDERATED CONNECTION=’mysql://user@192.168.1.1/banco/tabela’

Dessa forma você consegue ter acesso a uma tabela remota, como se fosse local. Essa solução é excelente para quem trabalha com frameworks que possuem o próprio ORM.

Veja mais informações detalhadas sobre o assunto nesse artigo do MySQL Brasil.

Ontem comecei a brincar com o famoso Google AppEngine, queria subir uma página em Django para entender melhor como funciona e testar a performance, utilizando todo o cluster de processamento do Google.

Confesso que foi mais fácil do que eu imaginava. O próprio SDK fornecido pelo Google já contém o Django e é possível trabalhar quase como se tivesse rodando Django em outros servidores. As alterações estão na forma de trabalhar com models (é necessário utilizar a DataStore API) e algumas limitações impostas pelo Google, alterando o funcionamento padrão de alguns módulos Python para retornarem uma exception (basicamente ele não aceita nada que faça gravação em disco ou que utilize chamadas via rede).

Estou criando um pequeno tutorial e assim que estiver pronto, será publicado aqui no Blog.

É com grande pesar que anuncio a minha ausência ao FISL desse ano. Aguardei muito por esse evento sendo que até ganhei um espaço na grade para palestrar sobre um assunto que adoro e estou inteiramente dedicado a mais de um ano em estudar e fazer aplicações práticas em vários projetos: o Django!

Por motivos profissionais, não vou conseguir aproveitar o FISL desse ano. Estou inteiramente dedicado a um projeto (o Vericia, feito em Django) que me demanda muito tempo e está passando por uma fase de crescimento bastante acentuada, exigindo minha inteira dedicação. O ponto positivo é que o projeto está crescendo, o ponto negativo é que bem na época do FISL vou precisar me envolver em planejamentos e alterações técnicas para permitir que esse crescimento não prejudique a atual estrutura.

O FISL sempre foi bastante significativo para mim. Acompanho e participo do evento desde suas primeiras edições, fiz muitos amigos, conheci muita gente e cheguei a participar ativamente da associação que organiza o evento, na época que morava em Porto Alegre. Esse ano não estarei fisicamente no evento, mas certamente vou acompanhar cada detalhe através de blogs, notícias, twitter, irc, etc.

Ahh, sobre a palestra de Django. A mesma vai existir e será ministrada pelo amigo Andrews Medina. Fico bastante confortável por um membro bastante ativo e experiente da comunidade Django assumir a palestra. Quero pedir a todos que participem  e aprendam mais sobre essa maravilhoso framework que é o Django. Agradeço ao Andrews por entender a minha dificuldade de tempo e assumir o compromisso, tenho certeza que o conteúdo será excelente e certamente vai trazer muito conhecimento a quem estiver presente!

Não foi dessa vez, mas espero participar dos próximos!

A mais de um ano comprei um espaço na DreamHost, que é um ótimo serviço de hospedagem, oferece um espaço quase infinito, muita transferência e um preço bastante reduzido. Desconfiei bastante no começo, mas nesse quase um ano, o serviço nunca me deixou fora do ar.

O grande problema da DreamHost é se você precisa de configurações personalizadas, como rodar sites com Django e outros frameworks web. Com acesso shell, você pode configurar seu próprio python, instalar seus módulos e fazer o site funcionar, mas a performance cai bastante. A DreamHost utiliza FastCGI para controlar os processos, não tem mod_python e é necessário perder bastante tempo para ter essa receita funcionando. O pior é o acesso via browser, a performance cai bastante.

Semana passada iniciei minha missão de procurar outro hosting, que não fosse tão caro e que permitisse a instalação simples do Django sem tanta gambiarra como na DreamHost. Conversei com bastante gente, li vários relatos e decidir por criar uma conta na WebFaction. O preço é bem semelhante a da DreamHost, mas não liberam tanto espaço em disco (mas para mim, o plano básico atende perfeitamente) e tem a grande vantagem de você controlar totalmente seu ambiente, inclusive inicializar a parar os processos do Apache, ter seu próprio httpd.conf, etc. Era tudo que precisava.

Apesar de ser um host compartilhado, as configurações são tão flexíveis que parece um dedicado. Ter a própria instância do Apache é uma mão na roda, poder mexer no httpd.conf a hora que quiser é muito bom. As instâncias podem ser configuradas com mod_python ou outros módulos que o usuário desejar. O painel de controles não é tão amigável, demorei alguns minutos para entender como funciona (criação de domínios, criação de aplicações e websites). É necessário seguir uma determinada ordem para que o site funciona de maneira adequada. É possível hospedar vários domínios na mesma conta além de escolher entre MySQL e PostGres.

O suporte é bastante eficiente. No meu primeiro dia de acesso, notei uma lentidão fora do comum, mas percebi que a máquina da WebFaction estava bastante tranquila. Enviei um email (sábado de tarde) para o suporte, cerca de 1 hora depois veio a resposta, dizendo que havia um problema em um dos roteadores e que naquele momento deveria estar corrigido. Dito e feito, não tive mais problemas.

Quem deseja se aventurar em Django na WebFaction, existe um screencast disponível aqui.

Não pretendo cancelar minha conta na DreamHost, acho válido ter uma redundância, mas botei fé no serviço da WebFaction e para quem tem diversos projetos que não exigem muitos recursos (como eu que tenho alguns projetos pessoais), é uma ótima escolha.

Referência.