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!
13 novembro 2007
12 novembro 2007
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:
This gives us a shortcut to do some chained invocations, for example:
To give developers a better shortcut, my idea is to let them code methods with return type declared as "this":
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. Anothergreat interesting point to look is the integration with Covariant Types.
Let's take the Bar example:
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?
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
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?
25 outubro 2007
JSF Today: Standards versus OSS
It's true to say that JavaServer Faces came to standardize the way developers build user interface, defining a common API to facilitate the creation of components for web development (and other things). For those who don't know, JSF 1.0 (or JSR-127) had Craig McClanahan as Co-Spec Leader together with Ed Burns.
Let me address one point here: I know Ed and he is cool, and I had a cheap talk with Craig at BrasilOne 2005. Both are cool and their work with the community is great. But I must say: JSF was born with the wrong Co-Spec leader.
So, what's the problem of having McClanahan as spec leader? Well, as you may noticed if you had some time with JSF already, the View tier is basically... Struts (version 1). And what's the problem with that? The web development process with Struts is painful, and for large projects can achieve a high level of difficulty and maintainability, by dealing with huge struts-config.xml files, Action Forms and, let's not forget, JSPs bloated with tags (libraries). How do I call this? The Triple Alliance.
Let's understand, from the developer perspective, what this mean. (this will require a flashback of Struts 1)
While coding, the developer has to look and take care of, at least, three files at the same time. And how these three files are connected? With SOP - String Oriented Programming. Yeah. He/She has to create an ActionForm (Java) and/or an Action (Java), declare it in struts-config (XML) and code/maintain the webpage (JSP: Java, Tag Libraries, HTML, etc...). And all properties, names, etc, are binded by typing their names/ids in fields, like:
Why I say Struts is not cool anymore and why JSF followed the wrong idea? Because the developer has to know a lot of things, has to control a lot of artifacts, do SOP coding and been dependent of tools. The conclusion: Struts solved several issues but created new ones (JSF). But I must agree, Struts had market acceptance in the past because it was simple to start developing web applications with it. And addressed a hole of ideas and solutions (MVC) that were needed at that time. Craig, contratulations, really. You did an outstanding work here.
I liked Struts, I worked with it for 2,5 years. But, it wasn't a standard. So, let's recapitulate: if we need a standard [to sell tools, training, courses, books, facilitate the introduction of vendors, and not forgetting the ease of components customization], why not stick with what already is a [market] standard? That's why Struts is the base of JSF's View tier. Is this cool? No it isn't!
They took a market standard and turned that into a specification. Tapestry 3 was there, Echo 1 too and both with very cool ideas. Shouldn't Ed and Craig took a look at them? Yes for sure! If JSF 1.0 was a compilation of Struts 1, Tapestry 3 and Echo 1, I think I wouldn't be here. Now, let's talk about the present...
JSF 1.2 (JSR 252) is targeted for JavaEE 5.0. And I don't even see JEE 4 in every customer I go, just like JSE 5, so try to imagine when JSF 1.2 will be world wide deployed. Again, standards are cool, but they lose speed. This spec was delivered at December, 19, 2006 and alternatives like Tapestry, Echo and others, including Wicket, are improving faster than JSF since that time.
OSS frameworks, specially Web Frameworks, keeps demonstrating that the key for a good software is innovation. And from innovation, comes productiveness, because everybody wants to do more with less time. But, to get to innovation, speed is important. Bureaucracy is the enemy!
What JSF 2.0 (JSR 314) offers, and will deliver only next year (target: JavaEE 6, after April 2008), you can get from any framework today. Google Web Toolkit is an example of that. Wicket is another good example. These frameworks grown up faster than anything else, because they aren't standards. They doesn't has to wait for a series of other specs to be launched.
[I can't forget to show you why I think Wicket is cool]
To have productiveness, there must be simplification in the development process and, from the developer perspective, simplification of coding. There's no Triple Alliance in Wicket. There is some SOP, yes, but not in the same way. There aren't tag libraries and no XMLs. It's pure Java and pure HTML. Take a look.
Ed, one advice: invite Eelco, Matijn and the hole crowd of Wicket commiters to a small talk! :D
Post note:
You may think this post is just FUD, you may even think it's just to promote other frameworks like Wicket, which I post about sometimes. But believe me, it's not.
The purpose of this post is to share with you, my ideas and thoughts of why JSF is not cool [yet], why it doesn't has the productiveness I want [and need] and why you should consider moving to some Non-Standard OSS Web Framework. Still, I hope newer releases of JSF, like 2.0, brings ideas from the frameworks I mentioned here.
Let me address one point here: I know Ed and he is cool, and I had a cheap talk with Craig at BrasilOne 2005. Both are cool and their work with the community is great. But I must say: JSF was born with the wrong Co-Spec leader.
So, what's the problem of having McClanahan as spec leader? Well, as you may noticed if you had some time with JSF already, the View tier is basically... Struts (version 1). And what's the problem with that? The web development process with Struts is painful, and for large projects can achieve a high level of difficulty and maintainability, by dealing with huge struts-config.xml files, Action Forms and, let's not forget, JSPs bloated with tags (libraries). How do I call this? The Triple Alliance.
Let's understand, from the developer perspective, what this mean. (this will require a flashback of Struts 1)
While coding, the developer has to look and take care of, at least, three files at the same time. And how these three files are connected? With SOP - String Oriented Programming. Yeah. He/She has to create an ActionForm (Java) and/or an Action (Java), declare it in struts-config (XML) and code/maintain the webpage (JSP: Java, Tag Libraries, HTML, etc...). And all properties, names, etc, are binded by typing their names/ids in fields, like:
struts-config: [..] name="myProperty"And this is the same process with JSF. You have to code JSP pages with Tag Libraries (XML), you have to code Managed Beans (Java) and you have to declare a lot of things within faces-config.xml. All that with SOP... Triple Alliance! Ok, you can develop JSF with tools, auto-completion, hints and many other features. But why should you need a tool to develop a JSF web application? We want simplicity in the first place, not toolability.
Java: getMyProperty()
JSP:
Why I say Struts is not cool anymore and why JSF followed the wrong idea? Because the developer has to know a lot of things, has to control a lot of artifacts, do SOP coding and been dependent of tools. The conclusion: Struts solved several issues but created new ones (JSF). But I must agree, Struts had market acceptance in the past because it was simple to start developing web applications with it. And addressed a hole of ideas and solutions (MVC) that were needed at that time. Craig, contratulations, really. You did an outstanding work here.
I liked Struts, I worked with it for 2,5 years. But, it wasn't a standard. So, let's recapitulate: if we need a standard [to sell tools, training, courses, books, facilitate the introduction of vendors, and not forgetting the ease of components customization], why not stick with what already is a [market] standard? That's why Struts is the base of JSF's View tier. Is this cool? No it isn't!
They took a market standard and turned that into a specification. Tapestry 3 was there, Echo 1 too and both with very cool ideas. Shouldn't Ed and Craig took a look at them? Yes for sure! If JSF 1.0 was a compilation of Struts 1, Tapestry 3 and Echo 1, I think I wouldn't be here. Now, let's talk about the present...
JSF 1.2 (JSR 252) is targeted for JavaEE 5.0. And I don't even see JEE 4 in every customer I go, just like JSE 5, so try to imagine when JSF 1.2 will be world wide deployed. Again, standards are cool, but they lose speed. This spec was delivered at December, 19, 2006 and alternatives like Tapestry, Echo and others, including Wicket, are improving faster than JSF since that time.
OSS frameworks, specially Web Frameworks, keeps demonstrating that the key for a good software is innovation. And from innovation, comes productiveness, because everybody wants to do more with less time. But, to get to innovation, speed is important. Bureaucracy is the enemy!
What JSF 2.0 (JSR 314) offers, and will deliver only next year (target: JavaEE 6, after April 2008), you can get from any framework today. Google Web Toolkit is an example of that. Wicket is another good example. These frameworks grown up faster than anything else, because they aren't standards. They doesn't has to wait for a series of other specs to be launched.
[I can't forget to show you why I think Wicket is cool]
To have productiveness, there must be simplification in the development process and, from the developer perspective, simplification of coding. There's no Triple Alliance in Wicket. There is some SOP, yes, but not in the same way. There aren't tag libraries and no XMLs. It's pure Java and pure HTML. Take a look.
Ed, one advice: invite Eelco, Matijn and the hole crowd of Wicket commiters to a small talk! :D
Post note:
You may think this post is just FUD, you may even think it's just to promote other frameworks like Wicket, which I post about sometimes. But believe me, it's not.
The purpose of this post is to share with you, my ideas and thoughts of why JSF is not cool [yet], why it doesn't has the productiveness I want [and need] and why you should consider moving to some Non-Standard OSS Web Framework. Still, I hope newer releases of JSF, like 2.0, brings ideas from the frameworks I mentioned here.
23 outubro 2007
Filosofia do Wicket
Eelco Hillenius, um dos Core Commiters do framework web Wicket, em um de seus insights sobre desenvolvimento Web:
[]'s!!
miojo
"Imagine being told that you can use Java as your programming language, but at the same time being told not to create your own classes. [...]Em português:
I fail to understand why that has to be different for UI development, and Wicket proves it doesn't have to be so."
"Imagine ouvir que você pode usar Java como linguagem de programação, mas ao mesmo tempo ouvir para não criar suas próprias classes. [...]Artigo completo
Não consigo entender porque precisa ser diferente para o desenvolvimento de UIs, e Wicket prova que não precisa ser."
[]'s!!
miojo
21 outubro 2007
Java BOPE v2.0
Alguns já devem ter visto esta versão. Eu particularmente prefiro esta abaixo, com algumas adaptações e acréscimos (além da censura, é claro):
PS: Quem quer rir, tem que fazer rir!!! :D
- Homem de preto, qual é a sua missão?!!
- É aprender Java sem precisar de certificação!!
Homem de preto, o que é que você faz?!!
- Eu faço código que assusta o Satanás!! - "Um de vocês é o car****! Um de vocês é o car****! Quem apagou todo o banco de dados foi você! Você que financia essa mer**, seu vi***!"
-- Programador, revoltado com gerente que pediu em uma semana trabalho de um mês e reclamou quando os bugs surgiram. - - Em Brasília existem 7 empresas de TI. Todas elas dominadas por gerentes burocratas armados de processos ineficientes até os dentes. O programador tem 3 opções: ou passa num concurso, ou começa a fazer POG, ou vai pra guerra. Eu já tava naquela guerra fazia tempo, meu parceiro. E precisava arranjar um substituto...
- ... na maior parte dos projetos, só chamam a gente quando a própria equipe do projeto não dá conta de resolver pois é, só que aqui no projeto, isso acontece o tempo todo.
- Conversa entre estagiário e gerente Nascimento
Nas.: "Quem fez isso aqui?"
Oreia.: "Não sei!"
Nas.: "Foi você!! Você que mantém essa por**! ... Seu vi***!"
Nas.: "Agora eu tenho que vir aqui e limpar a ME*** que você fez!" - Aula de Engenharia de Software com o Capitão Nascimento:
- O Processo Unificado foi criado por Phillip Kurtchen, e começa na concepção, do inglês Inception, que define escopo, que vai para a Elaboração, do inglês, Elaboration, que mitiga os riscos arquiteturais, que vai para a construção, do inglês Construction, que implementa os casos de uso, que vai para a transição, do inglês Transition, que vai para...
Coordenador: - Capitão, o recurso 23 dormiu, capitão!
- Sr. 23, segura essa por** desse projeto prioritário aqui, sr. 23. Se você dormir de novo, sr. 23, a por** do Grupo de Garantia da Qualidade vai te explodir, vai explodir seus colegas, vai me explodir, você não quer isso, não é sr. 23, o sr. não vai dormir de novo, não é sr. 23?
Rec. 23: - Não, senhor! ... - Capitão Nascimento chegando pra resolver problema de build para produção:
Todo mundo quietinho aí, não vai subir nada não!!! - Cap. Nascimento para o Analista que fez decomposição funcional no caso de uso:
Você não é analista, você é muleque!! - "Trinta horas pra resolver um bug de mer**? O senhor é um fanfarrão, senhor zero-meia! 30 minutos... Eu disse 30 minutos pra resolver essa mer**!"
- "Sr. Designer 32, tira esse preto desse layout por**!!!! Você é muleque!!!"
- "Capitão, o aspira 07 não quer fazer POG senhor!!!!"
"Ah, não quer fazer POG não é? Tá com nojinho é? O que você esperava, um diagrama de atividades, diagrama de sequência, caso de uso, documentação do projeto, wireframe e HTML? Pede pra sair!!! Pede pra sair!!!"
*** Segue a minha contribuição:
Capitão Nascimento e seus colegas avaliam a lista dos candidatos ao BOPE:
- E esse aqui? No currículo diz Desenvolvedor .NET...
- Esse eu conheço capitão! Vive deixando código lixo por ae! Aceita qualquer grana pra trabalhar com aqueles produtos...
- Esse já perdeu antes de começar... Vai sair no primeiro dia!
PS: Quem quer rir, tem que fazer rir!!! :D
Assinar:
Postagens (Atom)
| |||
| |||