Tabblo: A Aplicação Matadora para Fotologs e Álbuns Digitais

Eis que surge o campeão das aplicações da web 2.0 para álbuns de fotos e demais usos relacionados com imagens digitais. O nome do mais novo web 2.0 killer app é Tabblo. O ambiente foi desenvolvido em Django com ampla utilização de Ajax e uma interface que é simplesmente ótima.

Isso demonstra o quanto é viável utilizar o Django no desenvolvimento de aplicações web, principalmente se na hora de desenvolver as interfaces e templates houver a preocupação com a adoção de tecnologias que favoreçam a usabilidade.

Não vou nem tecer muitos comentários a respeito, vá até o site, cadastre-se e faça alguns testes. Duvido que não irá passar a usar o Tabblo como ambiente para seus álbuns de fotos. 😉


Java Sucks! Comparativo lado-a-lado de Frameworks para Aplicações Web

Encontrei um vídeo ontem que faz uma comparação direta entre diversas abordagens de desenvolvimento de aplicações para web e que chega a uma conclusão bastante ácida: “Java não é apropriado para o desenvolvimento de aplicações web”. O vídeo em questão foi feito por um profissional que trabalha com desenvolvimento de aplicações no Jet Propulsion Lab da NASA, está disponível no endereço http://oodt.jpl.nasa.gov/better-web-app.mov e tem 378,5 MB.

Como o vídeo é relativamente grande e está em inglês, o que pode prejudicar o seu correto entendimento, apesar da linguagem simples e descontraída do palestrante, vou transcrever abaixo alguns trechos juntamente com os screenshots.

No início do vídeo é feito um teste em cada um dos frameworks, demonstrando na prática a sua utilização, que na minha opinião deixou um pouco a desejar já que a abordagem utilizada pelo programador em algumas situações não é a mais correta e ilustra muito pouco do que pode ser feito com as ferramentas testadas. Em síntese é feito a comparação do J2EE (primeiramente utilizando JSP + Servlets + Hibernate, do framework feito em Ruby, Ruby on Rails e dos frameworks feitos em Python, Zope + Plone, TurboGears e Django.

Na segunda parte do vídeo as comparações ficam mais interessantes, e seguem abaixo algumas imagens e comentários:

Inicialmente o que se propõe é o desenvolvimento de uma pequena aplicação em cada um dos frameworks apontados inicialmente, para isso foi escolhido um exemplo bastante simples, que sugere uma aplicação de gerenciamento de tempo, conforme o diagrama abaixo.


A primeira abordagem a ser testada é a do J2EE (JSP + Servlets + Hibernate), e o resultado pode ser visto abaixo:


A aplicação gerada só possue interface de inclusão de dados, não tem nenhum mecanismo de segurança, internacionalização, validação de dados, etc. O seu desenvolvimento custou ao desenvolvedor o seguinte:


Foram 499 linhas de código, 14 arquivos editados, muito XML e na hora de rodar a coisa decorreu da seguinte maneira:

Para concluir:


Tradução: “Quando tudo o que você tem é um martelo, todos os problemas se parecem com um prego.”

Em seguida é apresentada a solução em Ruby on Rails:


A aplicação gerada possue interface de inclusão, exclusão e listagem das informações, porém não tem nenhum mecanismo de segurança e internacionalização, etc. possuindo alguns recursos para validação de dados mas obrigando o desenvolvedor a trabalhar diretamente com as tabelas em MySQL. Em resumo, desenvolver uma aplicação em Ruby on Rails consiste em criar um bom banco de dados, seguir as regras impostas pela ferramenta e obter resultados simples, porém rápidos.


Como pode ser visto acima só foi necessário editar 3 arquivos, nenhuma edição de XML foi necessária e apenas 29 linhas de código foram necessárias para ter a aplicação funcionando. Na hora de rodar a aplicação também não houveram grandes problemas.

Depois do mamão com açucar do Ruby on Rail veio a vez do Zope+Plone, cujo resultado pode ser visto abaixo:


Para escrever a aplicação é necessário apenas criar um diagrama UML contendo tagged values que descrevem diversos aspectos da aplicação, dessa forma foi possível atingir o seguinte quadro:


A aplicação criada possui validação de dados, internacionalização, mecanismos de segurança, busca, criação de metadados e tudo mais, inclusive a pia da cozinha. Entretanto pode não ser tão fácil quanto foi mostrado no vídeo numa situação real do dia-a-dia, além do mais a curva de aprendizagem do Zope+Plone é muito alta, fazendo com que a obtenção de resultados rápidos seja dolorosa no início, mas é bastante recompensador quando se pode criar aplicações com tanta qualidade de maneira tão simples.

Também convém citar que o Zope não trabalha com bancos de dados relacionais nativamente, e que as informações ficam armazenadas em um banco de dados orientado a objetos chamado ZODB, cuja performance não é das mais atraentes, mas por oferecer mecanismos de alta disponibilidade pode ser considerada uma “ótima” ferramenta/ambiente de desenvolvimento.

Depois foi a vez do TurboGears, com resultados muito próximos aos do Ruby On Rails, cuja aplicação final é mostrada abaixo:


Finalmente é desenvolvida a solução com o Django:


O resultado final é bastante parecido com o do Zope+Plone, entretanto a plataforma não possui tantos recursos quanto o rival, mas tem a vantagem de ser mais simples, oferecer recursos de validação de dados, segurança, interface administrativa auto-gerada, internacionalização, etc. Outra grande vantagem do Django é o fato de trabalhar com bancos de dados relacionais e de apresentar uma sintaxe de código mais “Pythônica” do que os outros dois frameworks feitos em Python.


Como pode ser visto acima, apenas 19 linhas de código e a edição de um único arquivo foi necessária para criar a aplicação. Na hora de rodar o software o resultado foi o seguinte:


No momento em que deveria ser feita a demonstração dos resultados obtidos com a utilização do JBoss seguem os seguintes trechos:


Conclusão bastante dura para os “Javeiros”, mas apesar de ácida (eu tinha avisado) eu creio que seja bastante realista. Afinal de contas é necessário que exista simplicidade no desenvolvimento de aplicações, e isso sempre foi algo que faltou nas plataformas Java. Segue abaixo o quadro comparativo dos resultados obtidos:


Apenas um ponto está errado nesse quadro que mostra as 4 plataformas “alternativas” apresentadas, já que o Django possue templates e internacionalização e o TurboGears possue autenticação e internacionalização.

Caso ainda restem dúvidas sugiro que assistam ao vídeo e que testem cada uma das plataformas citadas. Estou certo que se surpreenderão com o que verão em cada uma delas e com o quanto de tempo poderiam poupar se usassem Python ou Ruby ao invés de Java em suas aplicações Web. Happy Coding!


CMS’s, frameworks e informações estruturadas

Passei um bom tempo dedicando-me à exaustiva jornada em procura por um sistema de gestão de conteúdos que possibilitasse a construção de um ambiente composto por informações estruturadas e não estruturadas. A primeira grande descoberta é que os CMS’s mais difundidos na Internet são muito enfaixados e que geralmente só conseguem dar conta sem grandes dores de cabeça daquilo para o qual foram originalmente desenvolvidos.

Depois de muito tempo em busca de um CMS’s que fosse capaz de manipular conteúdos estruturados com facilidade acabei descobrindo o Plone, em conseqüência disso me enveredei pelo Zope e aí a lista de acrônimos só foi aumentando, passando por DTML, TAL, ArcheTypes, ArchGenXML, Python Products, ZODB, Zeo Clients, Zeo Servers, Slots, Macros, Python Controllers, etc., ou seja, é possível obter grandes resultados com o chamado “PZP” (Python+Zope+Plone), entretanto é preciso estar disposto a vencer uma curva extremamente ingreme de aprendizagem, além de ter que conviver com uma abordagem que não envolve diretamente bancos de dados relacionais, passando pela utilização de adaptadores e todo tipo de parafernalha que parece que só é utilizada pela própria pessoa que escreveu o código, isso quando é utilizada (vide o caso do MySQLda e outros Database Adapters).

Voltei a fazer a minha peregrinação, conheci o Ruby on Rails (me dei conta que um CMS não poderia me antender naquele momento, devido ao aprendizado com o Zope e a simpatia que acabei criando com o Archetypes), achei interessante, mas ainda pouco funcional, já que a idéia é boa mas não vejo como poderia ser utilizado em projetos sérios sem oferecer uma série de características, além do mais a abordagem de criar aplicações apartir do banco de dados não me agrada, afinal de contas, se vou manipular objetos mais tarde porque não começar logo de uma vez com essa abordagem e abstrair o resto?

Por fim acabei descobrindo o Django, framework este que estou utilizando em um projeto e não tenho do que reclamar. Foi a escolha certa? Ainda não posso dizer, afinal de contas as mudanças na API e o fato de ainda não ter entrado em produção ainda me deixam com a pulga atrás da orelha, mas certamente foi a melhor opção até agora.