Django 1.0 beta1 liberado

Obedecendo o cronograma de liberação do Django 1.0, foi liberada na noite passada a primeira versão de teste “beta” do Django 1.0.

Para pegar uma cópia da 1.0 beta 1, vá até a página de downloads do Django, e procure ler as notas de liberação. Por favor, tenha em mente que essa versão não é destinada ao uso em produção, e é voltada para primariamente para desenvolvedores que estejam interessados em verificar os novos recursos na 1.0 e em ajudar a identificar e resolver  bugs antes da liberação da versão final. As versões 1.0 alpha e beta não receberão suporte a longo prazo e não serão atualizadas com correções de segurança, já que o seu principal propósito é servir como um alicerce no caminho para a liberação final do Django 1.0.

O próximo passo no caminho para o primeiro release candidate do Django 1.0, está agendado atualmente para 21 de Agosto. Se você gostaria de ajudar, por favor verifique a documentação para colaboradores e sinta-se a vontade para juntar-se a um dos sprints de desenvolvimento agendados para o período que antecede a 1.0; o cronograma completo está disponível no roteiro de liberação do Django 1.0.


Django 1.0 alpha liberado!

Agora é oficial. A versão 1.0 alpha do Django foi liberada!

Dentre as principais novidades estão:

  • Uma interface de administração completamente refatorada (newforms-admin);
  • Melhorias na manipulação do Unicode; e
  • Melhorias no ORM.

Para saber mais leia o anúncio oficial e os release notes.


Google App Engine: Eles fizeram denovo!

Foi lançado oficialmente ontem o mais novo projeto do Google, denominado Google App Engine, que consiste em permitir que desenvolvedores criem e hospedem aplicações web usando a infra-estrutura do Google. Já é possível aos 10.000 desenvolvedores que se inscreveram nessa primeira etapa, desenvolver aplicações usando Python, sendo que estão fornecendo a grande maioria das bibliotecas padrão, inclusive o Django e através de um framework web chamado webapp.

Recomendo assistir com atenção os vídeos abaixo:

O meu palpite é de que haverá uma integração direta entre o Google App Engine e o Google Sites, fornecendo um ecossistema completo para desenvolvimento de portais, intranets e aplicações web, com a possibilidade até mesmo de utilizar aplicações desenvolvidas por terceiros em seu próprio site.

E você? O que acha?


Palestras sobre Python no meio Acadêmico

Duas palestras muito interessantes sobre o uso de Python no meio acadêmico foram publicadas recentemente e eu achei interessante disponibilizá-las aqui também.

Vale a pena assistir!


Relato: Mini-curso – Ruby On Rails – Latinoware 2007

O mini curso que estava previsto para ter início às 15:00 e término às 20:00 do dia 13 teve uma duração bem menor do que a prevista onde foram abordados os principais aspectos do framework para desenvolvimento de aplicações Web Ruby On Rails. Inicialmente o ministrante fez uma demonstração de especificidades da linguagem Ruby, que é muito parecida com Python e demonstrações de como tudo na linguagem é composto por objetos que possuem métodos, inclusive os tipos primitivos de dados, o que é muito bom, pois associado ao fato de se tratar de uma linguagem dinâmica, ela é fortemente tipada e conta com tipagem dinâmica de dados. Essas características fazem do Ruby uma linguagem simples, poderosa e fácil, que pode ser utilizada para construir softwares complexos sem que o programador tenha tanto trabalho quanto teria se estivesse usando linguagens mais rudimentares como o Java, C ou Pascal, além de não exigir recompilações e todas as outras vantagens que são inerentes a linguagens dinâmicas como o Python, Perl e outras.

Ao iniciar a demonstração do framework própriamente dito, no caso o Ruby On Rails, ele demonstrou de maneira rápida as características prinicipais do framework e explicou como a filosofia de “Convention over Configuration” contribui para a criação de aplicações simples e eficazes.

O Ruby on Rails parte da premissa que um desenvolvedor cria seus softwares partindo do topo para a base, sendo que a definição da base de dados gera automáticamente as classes do sistema de forma dinâmica, sem geração de código, aumentando muito a produtividade do desenvolvedor. Infelizmente não foi possível desenvolver a aplicação de exemplo que havia sido proposta inicialmente, o que prejudicou o conteúdo do mini-curso, que acabou se transformando numa palestra um pouco mais aprofundada.

De qualquer forma, existem muitos materiais sobre Ruby on Rails e eu procurei listar alguns aqui para quem tiver interesse.

Site Oficial: http://www.rubyonrails.org/

Ruby On Rails Brasil: http://www.rubyonrails.com.br


Java Sucks! O Retorno

Lembram da polêmica sobre o primeiro vídeo elaborado por Sean Kelly, aquele sujeito que trabalha para a NASA e que parece não ir muito com a cara do Java, onde foram comparados vários frameworks para desenvolvimento de aplicações web? Pois então, ele fez de novo! Agora ele elaborou um vídeo mostrando em detalhes, para aqueles que não acreditaram, como é possível desenvolver uma aplicação que roda sobre o Plone sem escrever nenhuma linha de código.

O vídeo pode ser acessado no endereço http://www.archive.org/details/SeanKellyGettingYourFeetWetwithPlone e, a exemplo do primeiro vídeo, não poupa comentários ácidos sobre Java e uma boa dose de bom humor. Dessa vez não vou fazer uma análise como fiz do outro vídeo porque ele é bem menor e pode ser baixado e assistido na íntegra sem maiores problemas pela maioria.

No final do vídeo ele diz que vai incluir vários recursos na pequena aplicação que criou e publicar novos screencasts mostrando como é possível, mas acho que isso dificilmente irá acontecer, ou pelo menos, se acontecer, não trará tanta polêmica, porque é justamente no ponto em que ele parou que, digamos assim, a Cinderela perde o encanto, ou seja, é necessário escrever código. Mesmo assim, acho que o vídeo demonstra bem as possibilidades do Plone e, principalmente, do Archetypes, servindo como uma boa introdução à forma com que muita gente tem desenvolvido ótimas aplicações usando o Plone como base, dentre os quais eu gostaria de citar as que tem sido desenvolvidas pelo pessoal do Interlegis e que podem ser vistas/acessadas no endereço http://colab.interlegis.gov.br/.

Bom, aqui eu continuo seguindo o meu caminho com o Django e também disponibilizei o código fonte de um projeto que estou desenvolvendo em http://gnu.unipar.br. Então, viva a diversidade e Happy Coding! 😉


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!


Afinal de contas, o que é esse tal de AJAX?

Muito se tem falado sobre o AJAX, o barulho em torno dele é grande, assim como os Applets quando surgiram. O XML e JavaScript Assíncrono, também conhecido como AJAX (Asynchronous Javascript And XML), é na verdade uma nova abordagem para desenvolvimento de aplicações web mais ricas, interativas e responsivas. O AJAX não é realmente uma tecnologia, mas uma forma de utilizar várias tecnologias como HTML ou XHTML, CSS, JavaScript, DOM, XML, XSLT e o Objeto XMLHttpRequest.

O mecanismo de interação das aplicações web é diferente do das aplicações desktop tradicionais. Cada instância de uma página da web precisa se comunicar com o servidor para obter a resposta necessária para ser atualizada. Isso consome uma grande quantidade de tempo e reduz a qualidade da experiência do usuário.

Vamos imaginar uma aplicação que exibe fotos por exemplo. Como ela se encontra rodando no servidor web e não no lado do cliente, quando o usuário quer ver a próxima foto, a página inteira precisa ser montada do zero mesmo que 99% do seu conteúdo nunca se altere. Agora considere a mesma aplicação novamente, mas dessa vez rodando como uma aplicação desktop: Quando o usuário clica para ver a próxima foto, isso é feito tranquilamente e a aplicação só tem que exibir a foto, porque ela está rodando inteiramente no lado do cliente.

A diferença que existe entre o comportamento de aplicações web e aplicações desktop é anulada pelo AJAX já que ele é processado do lado do cliente. O AJAX pode ser utilizado para criar Rich Internet Applications (RIA) que podem ter a interface consistente de um componente da GUI do desktop rodando em um browser comum sem aumentar o tamanho das páginas.

Como o Ajax Funciona?

As aplicações AJAX usam um Motor AJAX que atua como uma camada de aplicação intermediária entre o usuário e o servidor web. Esse Motor AJAX é escrito totalmente em JavaScript e algumas vezes é colocado em um frame escondido. Nesse momento algumas pessoas podem concluir que a presença de uma camada intermediária irá tornar a aplicação menos responsiva, mas a verdade é que ocorre exatamente o oposto no caso do AJAX já que as aplicações resultantes da sua utilização são muito mais responsivas.

Como isso é possível? Quando uma página web é acessada pelo usuário pela primeira vez, o Motor AJAX é carregado pelo navegador. Esse motor é responsável por montar a interface do usuário a medida que vai obtendo dados do servidor web no formato XML utilizando o objeto XMLHttpRequest. Agora a aplicação inteira está rodando no Motor AJAX e não precisa montar a página no servidor. O Motor AJAX permite que a interação do usuário com a aplicação ocorra de forma assíncrona (independente da comunicação com o servidor). Isso significa que o usuário nunca será apresentado à uma janela em branco enquanto estiver esperando que o servidor faça alguma coisa.

Toolkits de desenvolvimento AJAX

Os Motores AJAX possuem códigos complexos escritos em JavaScript, e não é fácil escrever um sozinho. Felizmente, existem vários Toolkits de desenvolvimento desenvolvidos por terceiros para escrever aplicações web baseadas em AJAX. Os três listados abaixo não são exatamente uma lista significativa, mas são um bom lugar para se começar.

Aplicações Web desenvolvidas em AJAX

Assim que o AJAX ganhou popularidade ele saiu dos laboratórios e foi para os servidores de produção na forma de aplicações web reais, simples e complexas. Ele também se tornou uma das tecnologias favoritas no Google, o que pode ser visto nas várias aplicações que eles tem desenvolvido usando AJAX. Abaixo encontra-se uma pequena lista com algumas coisas nas quais o AJAX está sendo utilizado no mundo real.


Análise do Django

Como já falei aqui anteriormente o Django é um Framework para desenvolvimento de aplicações web escrito em Python que tem por objetivo simplificar a vida do desenvolvedor e possibilitar a criação de aplicações de forma limpa e organizada. Também havia prometido que descreveria a minha experiência com o framework e é por isso que resolvi escrever o texto abaixo.

O primeiro passo na utilização do Django foi fazer a sua instalação, o que não foi difícil, já que bastou seguir as instruções contidas no Tarball. Depois disso, como todo bom iniciante, parti para o processo de leitura do tutorial, disponível na área de documentação do site oficial, e repetição dos passos descritos em meu próprio equipamento.

A utilização é bastante simples, básicamente composta pelos seguintes passos:

  1. Inicialização do projeto, que é feita com o comando django-admin.py startproject projeto;
  2. Configuração da aplicação, que consiste em informar o endereço, login e senha, além do tipo (mysql, postgres, etc) da base de dados a ser utilizada pela aplicação, através da edição do arquivo settings.py;
  3. Criação da aplicação (um projeto pode ser composto por multiplas aplicações), o que é feito com o comando django-admin.py startapp aplicação;
  4. Definição das classes, editando o arquivo apps/aplicação/models/aplicação.py; e
  5. Instalação da aplicação, que é na verdade a geração das tabelas necessárias ao funcionamento da aplicação na base de dados indicada na configuração, o que é feito pelo comando django-admin.py install aplicação.

Omiti alguns detalhes do processo, como a configuração do settings.py para que a aplicação seja adicionada ao projeto e outros pequenos detalhes de implementação, já que não é essa a finalidade desse texto, mas basicamente é assim que a coisa funciona.

Com as devidas definições no modelo, parâmetros especiais, etc. é possível ter uma interface de gerenciamento de dados completa, com direito a mecanismo de busca, níveis de acesso, autenticação, filtragem, além das operações CRUD (Create, Recover, Update, Delete).

Depois da primeira experiência comecei a montar uma pequena aplicação de minha própria autoria (sempre recorrendo à documentação no site oficial) e posso dizer que:

É possível criar aplicações em minutos com o Django, entretanto ainda não comecei a mexer com as views (templates), mas posso garantir que pelo menos o “M” (model) e parte do “C” (controller) da triade MVC, sobre a qual está alicerçado o framework, são postas na tela com pouquissimo trabalho.

Pois bem. Nos próximos dias voltarei a dar notícias do Django por aqui. Python on Rails? Não sei… Mas pode ser até melhor.