Project Zero
A alguns dias atrás, a IBM anunciou o Project Zero.
Como estou de férias, não me dei ao trabalho de ir olhar até que lesse dois textos relacionados ao projeto, um do Mark Pilgrim e um do Joe Gregorio. Isso me motivou a ler mais alguns textos sobre o assunto e dar uma boa olhada no site do projeto.
Antes de mais nada, digo que ainda estou baixando ele para testar, ou seja, não coloquei um único dedo nele ainda. O que se segue é uma mistura de comentários sobre os dois textos supracitados e um pouco de opinião própria.
O texto do Mark, como lhe é de costume, é ácido. Muito mais que o do Joe, mas tem algumas coisas que eu dou razão. A idéia de community-driven commercial development é tosca, mesmo que exista um bugzilla público, como o Joe aponta.
Ter transparência no desenvolvimento é desejado, e muito bacana. Mas o projeto teria muito mais benefício se fosse aberto. Open Source. O Joe fala que ainda tem muito a ser desenvolvido. Se aberto, se beneficiaria muito mais da comunidade do que apenas bug reports.
A IBM tem experiência suficiente nessa área. Já abriu o Eclipse e muito código para a Apache Software Foundation. Poderia ter aberto o Project Zero. Mesmo que não de imediato. Que criasse um plano e fosse aos poucos abrindo as partes do projeto, permitindo colaboração direta gradativa. A Sun e o Google tem feito isso com muito sucesso.
Muito da documentação está escrita em “corporativês”, o que dificulta a leitura, pelo menos para mim. E olha que eu leio muita coisa em “corporativês” e, vez ou outra, preciso escrever também. Ainda assim não é natural para mim. Ainda bem.
Por outro lado, existem os pontos positivos. Um que o Joe ressaltou e eu concordo plenamente é o fato de usar outras linguagens, Groovy e PHP, dentro de uma JVM, e não apenas Java. Existe um bom momentum ao redor desse conceito e eu acho isso excelente. Tenho uma certa aversão aos grandes stacks criados para se construir aplicações “corporativas” e ao apego ao Java, como se fosse a única linguagem que preste para esse tipo de aplicação.
Nesse caso, embora sempre exista o argumento revolucionário, no sentido de simplesmente abandonar tudo e migrar para um modelo mais simples, para linguagens e sistemas mais eficientes, isso — na minha pequena experiência nesse mundo — não funciona tão bem quanto no papel.
Por outro lado, ir pervertendo aos poucos os grandes stacks me parece um plano bem melhor, e muito mais difícil de derrubar.
Outro ponto é o suporte REST, também citado pelo Joe. Tenho as minhas ressalvas nesse ponto, porque meu entendimento é que, para utilizar o estilo REST de arquitetura, o desenvolvedor precisa ter uma mentalidade um tanto quanto diferente, pensar diferente, e não apenas plugins.
REST não é apenas permitir acesso direto à dados via URI. Esse é um dos pontos que vira-e-mexe, é revisitado. O entendimento de REST muitas vezes se limita a exposição de recursos através de URIs e se negligencia o uso de hipermídia como máquina de estado.
Porém, ao criar um ferramental que facilita a criação de interfaces REST nativamente, sem maiores complicações, ajuda — aos poucos — a mudar a mentalidade de quem desenvolve. É o mesmo caso do PHP e Groovy. Mudanças gradativas são sempre mais fáceis de serem assimiladas.
Não sou capaz de prever se o projeto vai ter algum, nenhum ou todo o sucesso desejado. Mas não custa nada dar uma olhada para estabelecer uma opinião mais fundamentada — e não só baseada no que eu andei lendo. Ainda mais que é dog food e, se cumprir o que promete, pode ser uma excelente ferramenta para o dia-a-dia profissional.
E para finalizar, esse post é a minha visão sobre o assunto, não da IBM, mas acho que isso não precisa mais ser dito, certo?
Feed com os comentários desse post.
