LOGO faz 40 anos


O precursor dos softwares educativos e derivado da liguagem LISP nasceu há 40 anos atrás com o intuito de ensinar lógica, programação e princípios de geometria.

Hoje com a profusão de softwares educativos existentes a velha tartaruga ficou um pouco ultrapassada, mas é graças a essa criação de Seymour Papert que o status dos computadores como ferramentas educativas se consolidou e começou a se tornar parte de estratégias pedagógicas de ensino.

Hoje existem alguns substitutos interessantes, dentre os quais está, por exemplo, o Alice, que prima pelos mesmos princípios, mas que faz uso de recursos 3D.


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.