Paul Maritz falou sobre as iniciativas infraestruturais da VMWare no desenvolvimento de Clouds (Nuvens) mais eficientes. Cloud Computing é a capacidade de implantar uma aplicação não em um servidor, mas em um sistema operacional virtualizado capaz de lhe fornecer um poder computacional pré-estabelecido provido por centenas de máquinas ligadas em uma grande rede de alta velocidade.
Maritz explanou acerca da necessidade dos desenvolvedores em criar aplicativos para serem hospedados e eventualmente portados entre nuvens privadas, terceirizadas a provedores ou mesmo pertencentes a mega coorporações como o Google. Vale um parênteses sobre a linha de raciocínio dele. A intenção das nuvens também é garantir uma maior produtividade, uma vez que não é responsabilidade da empresa que desenvolve o software instalar e configurar diversos recursos como frameworks de terceiros. Estes frameworks inclusive só existem para aumentar a produtividade dos desenvolvedores (Viu Glauber!!!). Por outro lado, eles geralmente trazem trade-offs de desempenho. É aí onde entram as nuvens. Em vez de você focar no tunning do servidor e eventualmente da configuração dos próprios frameworks, este trabalho é delegado aos administradores da nuvem e você vai poder cobrar por isso.
A fim de tornar as coisas mais próximas, a VMWare comprou no ano passado o Spring Framework, de Rod Johnson, uma popular alternativa aos desenvolvedores Java EE. O que isso traz de interessante pra gente? As nuvens virtualizadas com VMWare disponibilizarão de modo mais eficientes plataformas Java EE com Spring Framework habilitado. Por se tratar de um evento do Google, Maritz precisou vender seu peixe dizendo que o está integrando com o GWT no front-end e, embora não tenha dito, apresentou um slide onde sugere a adoção de sua infraestrutura no Google App Engine (Gae).
David Glazer convidou Ben Alex, do Spring Framework e Bruce Johnson, líder do GWT para falar sobre esta integração. Bruce começou falando sobre o poder do GWT em criar aplicações Ajax integradas com backends Java. Até aí nenhuma novidade. Depois, Ben apresentou o Roo, um terminal open source para desenvolvimento ágil de projetos Java com Spring ao estilo Python ou Ruby on Rails com respostas instantâneas e ferramentas de scaffolding. Não sei porque, mas nunca fui fã dessas coisas. Para quem não gosta de ter que abrir o console (especialmente usuários Windows que precisam correr para o sub-nitrato de pó de peido chamado DOS), há ainda o Springsource Tool Suite, um plugin Eclipse com integração total ao console Roo (no lugar no painel do console tradicional do Eclipse). O que me incomoda de verdade é essa geração automática de telas e classes de negócio por baixo dos panos. Fico me sentindo de fora da festa.
Bruce voltou para mostrar um pouco a experiência de navegação com uso de Ajax no GWT. Até aí nada de novo, inclusive tocou em um ponto que sempre discuto em minhas aulas de Javascript que é o vício adquirido pelos usuários nos idos tempos da velha Web, onde o botão voltar era essencial para carregar a tela anterior valendo-se do cache. Todo mundo sabe que requisições Ajax não atualizam o histórico do browser, até porque elas não atualizam toda a página (ou até mesmo nada visível na página). Assim, respostas Ajax que modifiquem de modo considerável o que está disposto em tela podem induzir o usuário a clicar no back do browser para voltar à tela anterior. Isso pode ser um problema. Eu costumo comparar o Gmail com o YahooMail (o das abas) e neste quesito, meu humilde ponto vai para o yahooMail, uma vez que sua idéia de abas não sugere o uso do back (para voltar, feche a aba ou clique na anterior do mesmo jeito que faria em uma aplicativo desktop como o Outlook Express). Convenhamos, é uma tremenda gambiarra do Gmail garantir o histórico do browser em requisições Ajax.
O ponto que o próprio Bruce admitiu ser mais interessante (talvez o único novo, à altura do evento) tenha sido a apresentação das ferramentas Web de profiling Spring Speed Tracer e Spring Insight para apontar gargalos de desempenho respectivamente no cliente e no servidor. Detalhe: são feitas em HTML5 e possuem uma experiência de navegação fantástica.
Quando eu já estava me perguntando se alguém vai falar sobre o Google App Engine ou o Android, David convidou Kevin Gibbs para falar mais sobre o Gae. Gibbs destacou o Google App Engine for Business, um novo modelo de negócio para empresas adotarem o Gae com mais afinco, principalmente quando se fala de bol$o.
Perdão mas esse novo formato de cobrança. $8.00 por usuário merece uma análise mais fria posterior. A princípio temos um primeiro caso onde o Google não conseguiu achar um bom plano de negócio e acabou encarecendo a vida do desenvolverdor. Tudo bem que há um limite de $1,000.00 por aplicação, mas se eu tiver apenas 100 usuários vou precisar pagar $800? Putz, ele devia visitar o Brasil. A idéia de uma plataforma gratuita até certo tamanho e cobrança posterior por tráfego parecia mais interessante. Passado o evento, vejamos como vai funcionar o modelo de negócio do Gae oficialmente.