Buon Anno!

É meus amigos. Na Itália o Anno Novello é um pouco diferente. Dopo da virada, muito vinno e muita bombinha nos pés do povo, atirados por crianças felizes e impacientes por diversão! Baita frio mas a bebida esquentou. Graças à cachaça que eu trouxe do Brasil e o vinno da Toscana! :)


A virada ao lado do Colosseo é divertidíssima!! Valeu muito a pena estar aqui para ver!
Já são 5 noites na Europa desde o dia 26 de dezembro e hoje, primeiro dia de 2008, já estou a caminho de Palermo, na Sicília (sul da Itália) para conhecer a Máfia Italiana. :D

Daqui a alguns dias mando outras fotos interessantes!

Um forte abraço para todos e... Auguri!!

Whiteboard dos frameworks Web

Neste post do Enter The Jboss Matrix, o autor Shaun Connolly apresenta o resultado de um whiteboard poll, sobre o uso de Application Servers e Web Frameworks. O resultado apresenta forte liderança pelo JBoss e JSF.


Vou falar aqui sobre os resultados da votação de Web Frameworks. Vendo este whiteboard, levanto algumas questões:

• Porque JSF é lider?
• Porque tem gente que ainda utiliza Struts e Struts 2?
• Quem são os malucos que utilizam Spring MVC?
• Que tipo de desenvolvedores utilizam Tapestry?
• Porque em tão pouco tempo, o uso do Wicket cresceu a ponto de ultrapassar Tapestry, Grails e Rails?

Perguntas pertinentes, que me arrisco a dar algumas respostas neste post que, sem dúvida será bem controverso. :)

Porque JSF é lider?
Para mim, o principal motivo é simples: JSF é uma especificação definida pelo JCP. Isto favorece a adoção por grandes empresas e projetos que preferem algo padronizado e que possui uma grande oferta de cursos, livros e produtos.

Mas me questiono: o JavaServer Faces puro (Reference Implementation) não tem nada demais. A produtividade com ele é baixa, o suporte das IDEs só é bom quando amarrado a componentes de terceiros e como comentei num post anterior, usa-se muito SOP (String Oriented Programing.) A solução para torná-lo verdadeiramente produtivo é sempre abraçar algum framework JSF mais robusto (leia-se: mais componentes e uma arquitetura engessada), como o JBoss Seam, Oracle ADF Faces ou o da Sun (experimente o NetBeans 6 e notará que vários componentes são específicos da Sun... não sei exatamente de onde vem, qual o projeto, mas sei que tem.)

Abraçar um produto JSF implica em se amarrar a este produto e seus componentes customizados, não podendo mudar de Vendor assim como é prometido pela especificação e tantos desenvolvedores, gerentes e arquitetos ainda, sendo enganados pelo marketing, acreditam.

Sei, e concordo, que há espaço para o JavaServer Faces, mas vamos parar com o euforismo de que JSF é produtivo, padronizado e livre de implementação, ok? Ninguem mais vai trabalhar com JSF RI. A solução será sempre escolher entre uma especialização ou outra (Seam, ADF, etc ...) para tornar essa máxima verdadeira.

Porque tem gente que ainda utiliza Struts e Struts 2?
Desenvolvi em Struts 1.x durante boa parte da minha carreira, e assim como postei da outra vez, acredito que foi-se o seu tempo. Entramos numa era de programação baseada em componentes, e não actions. Reutilização de código na composição de paginas agrupando componentes: este sim é o modelo de hoje (visto no JSF, no Tapestry, Wicket e alguns outros).

Então porque tem gente que ainda utiliza Struts e Struts 2? O primeiro é simples: manutenção. Tem muito sistema que foi feito em Struts e por falta de tempo ($$) não existe o interesse em migrar para outro framework (nem que fosse o Struts 2). O segundo fica difícil de dizer exatamente o porque, mas me arrisco a dizer que é pelo simples fato de ser a junção de duas fortes comunidades (Struts e WebWork) que são devotos do modelo Action-based. Esta comunidade está presa a um modelo de construção Web, onde se sintam confortáveis e confiantes na hora de construir suas telas. Eu entendo. Já me senti assim um dia... :) Mas só por um dia.

Acho que o número de projetos em Struts e Struts 2 diminuirá com o tempo. Minha previsão é que, assim que JSF 2.0 sair oficialmente, teremos uma queda drástica na adoção de Struts 2 como framework web para novos projetos. Deste modo, dois frameworks irmãos irão se encontrar no limbo da manutenção.

Quem são os malucos que utilizam Spring MVC?
Alguém ae utiliza Spring MVC? Por favor, comenta aqui quais os motivos que o levaram a adotá-lo! Porque eu não faço a menor idéia. Na minha opinião, é apenas um Action-based amarrado ao Spring. O que ele tem que outros frameworks neste modelo não oferecem?

Deixo a resposta desta pergunta para os comentários... :)

Que tipo de desenvolvedores utilizam Tapestry?
O tipo que quer correr riscos e gosta de seguir um Pastor. O risco de sair uma versão nova com mudanças tão grandes na API que o forçam a duas únicas opções: ficar largado na versão anterior ou migrar para a última. Se você não sabe, o Tapestry é escrito praticamente, por um único desenvolvedor chamado Howard Lewis Ship. Isso implica que, se o cara decidir (como já fez entre as versões T3, T4 e T5) ter idéias novas e implementá-las, ele o fará sem dó nem piedade da comunidade que utiliza o framework.

Minha sugestão: fique longe de frameworks sem compromisso com seus usuários.

Porque em tão pouco tempo, o uso do Wicket cresceu a ponto de ultrapassar Tapestry, Grails e Rails?
Foi uma surpresa para muitos, quando o framework foi incorporado pela Apache rapidamente. O processo na incubadora foi rápido, o que demonstra a maturidade e o compromisso dos desenvolvedores. Além disso, é notável ver que este compromisso é diário visto o número de dúvidas respondidas (muitas até instantâneas via IRC) pelos commiters e usuários avançados.

Não há como negar que a comunidade Wicket já está consolidada, ao ponto de ultrapassar a do Tapestry e Grails. Mas não basta ter comunidade (voltemos ao exemplo do Struts), é preciso mais que isso. Aos que já colocaram seus dedos em algum exemplo de Wicket, viram o quanto é produtivo e rápido a construção de telas e componentes genéricos. Mas ainda, não é isso que atrai novos adeptos ao framework. É divertido desenvolver com Wicket.

Foi-se o tempo de apanhar para XMLs e Strings escritas por engano. Ou de taglibs monstruosas cheias de parâmetros. O conceito de POJO + POH é o que faz a diferença em relação aos outros frameworks. Some isso a uma API bem moldada a ponto de ser comparada com a do Swing, e você terá uma facilidade incrível para entender os métodos e classes do framework.

Para 2008, o plano é apresentar ainda mais a capacidade do Wicket a vocês que frequentam este blog. Não que eu queira iniciar uma religião com isso, mas apenas mostrar que existem alternativas mais produtivas. :)

[]'s
miojo

Slides do Wicket

Eu sabia que haveria uma palestra no Javapolis deste ano sobre o Wicket, então fui atrás e caí de paraquedas no site SlideShare. O legal é que, não apenas encontrei os slides da palestra Wicket in Action, apresentada pelo Martijn Dashorst (um dos Core Commiters.) Aproveitei também para fazer o upload da minha palestra deste ano e incrementar ainda mais a quantidade de slides sobre o framework!

Com pressa em ver a palestra que o Martijn deu no Javapolis? Confere logo abaixo:

| View | Upload your own

[]'s!

Beowulf: 3D nas telonas!

Para quem nunca ouviu falar, Beowulf é um filme em IMAX 3D e isto significa usar aqueles óculos bizarros no cinema! O legal disso? Ter a sensação de estar dentro da tela. O filme estréia nos EUA dia 16 de Novembro, nesta Sexta-feira.

Não sei quando chega ao Brasil, nem se tem algum cinema com alta qualidade para este filme, mas sei que quero ver! Assista ao novo trailler:



Finalmente um filme 3D que não é para criancinhas!! Aquele "A Família do Futuro" é legalzinho, mas Beowulf é do caceta!

Java 7 with Chained Invocation

This weekend Claudio Miranda, a friend and co-worker of mine from Brasília, came to São Paulo to assist give a presentation about "Tools and Tips to Solve Performance Issues in Java Applications" (yes, this is his presentation name) at Conexão Java. After some beers and talks about Java, I introduced him an idea I have been thinking about for a few days.

In Ruby, the return statement is implicit. In Java, we always have to declare which return type the method has. But what's happening is that this kind of method declaration is becoming common these days:

class Foo {
   public Foo doSomething() {
       ...
       return this;
   }
   ...
}

This gives us a shortcut to do some chained invocations, for example:

Foo foo = new Foo().doSomething().doAnotherThing();

To give developers a better shortcut, my idea is to let them code methods with return type declared as "this":

    public this doSomething() {
       ...
   }

After I showed Claudio my idea, he told me somebody already thought something like that, and there's a lot more suggestions than just this one. So don't think this is a worthless improvement. Somebody else thinks the same as I do :D

The difference between my suggestion and the one from Matthias Ernst, is that void would continue to be void. No return. The use of this, which has the concept of the current object,
would be convenience and not something magic, as declaring void and expect that to return the object itself. Another great interesting point to look is the integration with Covariant Types.

Let's take the Bar example:

class Bar extends Foo {}

// with current JSL and explicit return this; this would not compile
Bar bar = new Bar().doSomething();

// to fix, you must explicitly cast the returning object
Bar bar = (Bar) new Bar().doSomething();

Mixing implicit return this and covariant types, no cast is needed and we would have chained invocations easily! Besides, this is a small change into Java Compiler. The generated bytecode should be compatible with Java 1.3. Comments?