Ideas + Software Engineering

Book review: JBoss RichFaces 3.3

2009-12-06T02:45:00.001-08:00

Several weeks ago Packt Publishing marketing department came into contact with me in order to review a book they've just delivered: JBoss RichFaces 3.3. As you can see if you read my blogs, I've been using that technology for several years now and I was obviously interested on the book, so I accepted their invitation.
The company I work for runs several projects involving RichFaces now. We like using bleeding edge technology, we are JBoss partners, early adopters in general. For the last weeks me and my team have been using the book as reference for our work, and I'll summarize here our conclusions.
First of all I must admit I don't use to like technical books, so I'll be a hard reviewer. Don't get me wrong, there're many great ones out there ("In Action" series, for example), but it's difficult to catch my eye. Every open source project I'm user of is well documented. Seam, RichFaces, jBPM... Almost every JBoss project have great documentation: good reference manuals, javadoc, and even better source code. I'm not interested on undocumented software. For example, I quit Dojo framework because of that. I love deep, classic books, like Peopleware or The Mythical Man Month, books that would be read for decades. Technical books, on the contrary, have shorter lifetimes.

The book

The book guides the reader into building a new project from the very beginning (environment, deployment) to the end (skinning and so on). Book structure is like this:

Introduction and environment configuration.
Application development.
Advanced techniques: skinning, components...
Tag reference.

The good

When you begin programming JSF and RichFaces things can turn complicated. There's not "jsf-blank.war", and IDE support isn't always that useful. This book focuses on teaching you on building up an application from the beginning, and I think it succeds on it. You can think on this book like a detailed tutorial which will teach you on everything you need to begin working with RichFaces.
Java Enterprise Edition developing can be cumbersome: it takes a while to begin, and you need many components to work together until you get the app running. The book helps you on configuring RichFaces several ways: on its own, with Seam, with Facelets... It's quite complete.
It covers almost everything of the framework. If you follow it you'll use most components and features. Even more valuable, you'll learn to use the right tool the right time.
This is probably the book I'd have needed two years ago when I began using RichFaces. Blogs and online tutorials are not this comprehensive.

The bad

This is a learning book. It's aimed on people who wants to learn to use RichFaces, and it's good on it. But it's not that useful if you are already using it, or if reference documentation is good enough for you.
Sometimes it looks like a reduced reference version. For example, I'm using CDK (Component Development Kit), and its chapter is smaller and less detailed than the original reference. Sometimes this detail pruning leads to errors (version numbers is not something you should ignore when you're working with Java).
The appendix, the component reference, is useless. It's just a list of available components with an small paragraph. It shouldn't have been included.

The ugly

IMHO RichFaces is the best Ajax JSF library right now. 3.3.x branch is stable, mature and full featured. Nevertheless, JSF 2.0 is almost with us, and it will lead to RichFaces 4. It will be a big leap forward for standarization and ease of use. If you learn RichFaces 3.3 now you'll find 100% of it valuable for the following version, but the book loses a little bit of its value as reference.

In sort

In sort, if you want to learn RichFaces right now (wise choice) and you want to be guided through it, this is the book for you. If you're already a RichFaces developer, probably not.

You can download a sample chapter: RichFaces Skin Customization.

PD: as you will have probably realized, I'm not a native English speaker. Please let me know every language mistake I've made ;).

Designing an arquitecture (I/IV): current situation study

2008-10-16T08:36:00.000-07:00

First of all, please feel free of correct me not only technically but also linguistically, this is part of my English training :) If you can read Spanish you might prefer the Spanish version.

One year and a half ago I begun what has been my most complex, important and interesting professional experience: improving software development technique at an organization. This is a good time to look backwards.

I'll do it within four chapters:

I: current (one year an a half ago) situation study.

II: altertatives selection.

III: solution deployment.

IV: conclusions.

0. Precedents

I had been working with J2EE technologies, both profesionally and at home. I had previously done some things with PHP, and I liked to be up-to-date at industry innovations (RoR, Python...), altough I couldn't devote time in depth. Everything I did was, more or less, for decision taking management applications (I can't talk on real-time systems or high technology electronics, sorry).
From this experience I build up some axioms that I use to suppose as certain (altough when you're in computing you know the only right answer is 'it depends'):

Layer separation is a Good Thing:

There must be a dumb data access layer, decisionless, just to communicate with the database. It should essentially have just 4 CRUD methods.
The bussiness rules layer, above data, under presentation, is where you code specifications rules, from application data flow to data control ("who can see/edit what when").
Dependencies goes downwards, data, upwards.

Don't Repeat Yourself (DRY).

Corolary: don't cut'n'paste.

If you can choose, PHP, RoR or similar for small applications. For complex applications, J2EE.

Please don't begin a flamewar :) Yes, I know you can do far better things with other languages. Nevertheless, with Java you have great tools, great documentation, great libraries... and it's easier to control if you have to manage many people. Yes, of course, 4 great Python programmers will do a far better app that 10 mediocre Java ones, but this wasn't my case, you know what I mean ;).

Writing Java snippets at JSPs is bad.
Ajax is A Good Thing. If you do it by hand it might be good, but it's much better if a library provides you it..

Corolary: ajaxifying data is (probably) more efficient (from a networking point of view), ajaxifying interface is (probably) more productive (from a project manager point of view).

I. Current Situation Study

It was late 2oo6. Struts (Action, 1) begun feeling old, and 'Ajax' was the term you should say at an interview if you wanted to catch the attention. JSF already had its bulletproof bad health, just like now. A myriad of web frameworks (Spring Web, Wicket, Web Works, Tapestry...) waited its actual death to begin bragging. Microsoft, after his war against Sun, had published .NET, and every manager question was J2EE oe .NET?. Dojo was The Javascript Library, with his "no documentation at all" (or "document just a little, badly...) policy. If you wanted to keep a geek conversation, you had to know how cool RoR was, or that Google had broken every convention with GWT.

When I got to the new company I found a situation... well... uncommon. The whole World tried optimizing productivity and improving product quality with Java libraries, but they were developing with plain old servlets plus JSP, with embedded SQL... We belonged to another company (lets call it 'the supercompany') who imposed some other problems:

Old IDE:

Bad CVS client. It was no problem for the supercompany because they held the code at shared folders (sad but true), but it was for us, forcing us to use an external application.
Development on a different server, not the same as the production one.

Propietary server, badly documented.
In-house developed framework:

Classes generating HTML (forcing us to do things like new DropDown() at jsps).
One layer design, even with SQL at JSPs.
Wrappers for existing classes (we couldn't even access the actual Connection object).
Unavailability of source code.
Outdated documentation.
No standard library, not even Log4J or any other logging system.
Undocumented, hidden dependency on session variables.
Internet Explorer only.

This restrictions had led to many antipatterns:

Tons of repeated code.
Javascript only form validation.

After doing a first application "the old way" I was given a chance of doing a brand new design, a new arquitecture, a new framework.

Chrome first impressions

2008-09-02T12:10:00.000-07:00

First 5-minute impressions:

It has downloaded and installed seamless and quick, importing Firefox configuration.
I have three tabs (start one, Chrome presentation and this blogger one), and 4 processes at the task manager. Total, 95MB. Firefox, with the same tabs, 60MB. They've already said that one tab - one process model would have some startup overcharge. I don't mind if it cleans memory as good as it should.
Vista windows look... but optimized. No right, left or bottom border, and tabs are placed on the title bar, smaller than XP standard ones. Clean UI.
Quick start page displays also last searches.
Flickr Organizr works REALLY fast, and it doesn't make browser stop at all... Javascript is the key and reason of being of Chrome, that's sure...
Moving through tabs isn't fast, it's instantaneous.
Flash works from the very beginning.

Stay tuned :)

Google Chrome: web operative system

2008-09-02T11:30:00.000-07:00

You all know a browser has almost nothing in common with the traditional operative system concept, but if applications keep on their current trend of being at web the browser will be our application runtime environment.
This is why Google (is going to) publish Chrome, and they say it in a subtle way at page 4 of the comic: "we're applying the same kind of process isolation you find in modern operative systems".
It also shows some other interesting things:

When they build the core a bot test it against "millions of pages". Can you imagine testing against the n most used pages?
They've built a Javascript virtual machine which is a JIT compilar which produces machine code.
'Omnibox': the knowledge they've gained with its search box is applied to the URL bar address. Seems terribly simple and useful.
Silent mode for being traceless.
They critizise Vista security model, which allows reading upwards at the security stack, in spite of having sensible information at the middle of it. Chrome, isn't based at levels but at a sandbox where code can only retrieve information user explicitally gives. They compare Chrome again against a OS instead of a browser.
Plugin isolation at a different process.
Blacklisting.
Development improvements will be integrated at Google Gears. This way other browsers can still benefit Google improvements, and applications can be cross-browser compilant. But, if Chrome has a much bigger throughput, Gears will crawl instead of running on them (IMHO)...
At page 36 they state they believe Open Source, not standards (at least not at their 'unifing' function): "Open standards are one way to help all browsers get better. The team has also done some interesting things with speed, stability and the ui, like the new tab page. Some of them might become standards, some might not. But since it's open source other browser developers cant take what they want out of it".

IMHO tis is true... in part. If you "unstandar"what browsers do, pages won't behave the same way. Nevertheless, also IMHO, this is the right way of thinking. Standards are slow and burocracy limited.

Let's see what it has to offer... Reading the comic has created a great envy on me. It must be great working at Google pushing the limits of the web instead of struggling with its limitations!

BlewSpace: blog geolocation (put your blog in the map!)

2007-12-16T05:12:00.000-08:00

Is geolocation interesting information? Have you ever wanted to geolocate a blog? BlewSpace is a new Google Maps mashup which aims geolocating every blog out there. It might not be considered geolocation but georegistration, but in the end there's a map full of blogs so you can place yours. You can register your blogs for people to locate it. You can also categorize it, and even ping it (so I can't register other people blogs and say it's about crap).
It's still in early beta (2.0 fashion ;) ), and there's an interesting wishlist you can increase.
From a commercial point of view I think BlewSpace has some interesting potential, specially for bloggers meeting arrangement. When BlewSpace activates spatial querying you could list the blogs at your city, for example.
Geolocation makes Web 2.0 communities more tangible. They're not only groups of virtual avatars, but actual people, some of them living next to you.

Richfaces 3.1 RC6

2007-09-11T09:23:00.000-07:00

Today, Richfaces 3.1 RC6 has been released. It's not the final, stable version (which was promised for 9/6), but at least you can finally visit Richfaces 3.1 Demos. This is a long awaited version for all of us who use this library because it finally includes a must-have: calendar component.

For those who doesn't know Richfaces, I'll just say it's an Ajax-powered JSF component library, just like ICEFaces. I tried both some months, and I chose Richfaces.

Main new features:

rich:calendar - until now, a reason to use ICEFaces instead of Ajax4JSF + RichFaces
rich:message and rich:messages, replacements for h:message and h:messages.
rich:tooltip
rich:scrollableDataTable

Last but not least, Ajax4JSF and Richfaces have merged. This is good for users (having a library is easier and more comfortable than having two), but it's important from a marketing point of view: they can now say Richfaces has 50+ components, so they can compete against ICEFaces in a numerical fashion. You know, I realize this is just marketing, but this kind of comparisons are important for newcomers.

First RichFaces application on Netbeans 6

2007-08-22T00:26:00.000-07:00

As part of almost sadomasochistic effort vocational software developer have, I'm doing a brief introduction to developing with RichFaces, from new IDE installation until minimal working application. The aim is not doing a tutorial, neither howto nor step by step (if you're reading this I suppose you don't want anybody to tell you to press 'next').

I've recently installed Red Hat Developer Studio beta 1, but I think it's still interesting using Richfaces on other IDEs so you don't have to switch between environments.

1.- Download last version of NetBeans 6 M10.
2.- Download last builds of RichFaces and Ajax4JSF, including sources (it contains javadoc and allows you to debug). They're merging soon in one only project.

**I'm using unstable versions because I'm at home, don't tell your boss to do this if you don't want to be fired ;).

3.- During the 180MB download you'd take a look at Richfaces and Ajax4JSF developer guides.

4.- Launch installer. Just some notes during the installation:

Tell installer to configure Tomcat 6.
Change default passwords and ports and write them down.

5.- Open Netbeans and create a new Web project running on recently installed SJSAS 9. Activate JSF.
6.- Press F6 for running the server, deploying and opening a browser. It should show 'JavaServer Faces' inside an html H1 element.

7.- Untar RichFaces, which contains both Ajax4JSF and RichFaces.
8.- Create a new library with those jars and add it to the project: project properties --> libraries --> add --> manage --> new library. Add both binary jars and sources.
9.- Apply the needed changes for a Richfaces application: add web.xml configuration and richfaces taglib.
10.- Restart application server. During the boot you could say hello at Richfaces users forum. You're going to use it very much, and Richfaces developers have been infinitely patient with me :). I had never seen such a good support in an OpenSource project.

11.- Ooops, first error! NoClassDefFound because of absence of Commons Logging, del que depende. You must add the following libraries:

commons-logging (bundled with Netbeansincluída con NetBeans)
commons-digester (download)
commons-collections (download)
commons-beanutils (download)

12.- Restart the server and ¡voila!

Nothing spectacular, but it'a a beginning.

Red Hat Developer Studio first contact

2007-08-14T10:34:00.000-07:00

I've been working on a relative small project for some months ago (more than a year). Since I began it on the Old Days it was done with Struts + Hibernate. Since then J2EE community has evolved very much, and there are some technologies that make my old fashioned design look old. More specifically, I want Ajax for my users.

I wanted to migrate it to a JSF + RichFaces + Seam + Hibernate arquitecture, but I wanted to wait until Red Hat Developer Studio was released, since it supports every technology I want to use. That day is finally here, and you can download Red Hat Developer Studio Beta 1. In this post I'll tell you about its installation and my first minutes with it (real time). This is neither a deep review of RHDS (can't be, yet) nor a study on Seam (same) or a J2EE for dummies guide. Hope somebody finds is interesting.

FYI, this is a 2GB Centrino laptop running Gentoo.

STARTUP
1.- Download Red Hat Developer Studio Beta 1 for Linux: ~530MB! It's huge!
2.- Launch installation: java -jar rhdevstudio-linux-gtk-1.0.0.beta1.jar.
3.- Follow instructions. 3 minutes long, no important notes. It creates a beautiful red icon in my desktop :).
4.- Clicking the beautiful icon leads to an instant beautiful crash (one of those eclipse crash dialog) on my system (java 1.5.0_12 by default). I don't know why, but specifying java path manually solves the problem: ./eclipse -vm /opt/sun-jdk-1.5.0.12/bin/java.
5.- It begins with a migration (from JBoss Studio) wizard I can't take advantage of, so it gets closed after doing nothing. I suppose JBoss Studio users will appreciate it.

FIRST IMPRESSIONS
It looks exactly like you'd expect Eclipse look like after installing a bunch of plugins. RHDS perspective gives me a first joy: a RichFaces palette (no calendar yet, I'll have to wait). A quick look at "Manage Configuration" reveals it includes, among others, these plugins:

Dali (JPA).
EMF (Modeling).
JST (checked as it had problems, hope this doesn't turns severe).
WST.
Hibernate Tools.
JBoss stuff.
Shale tools.
Spring.

There are also some new (at least for me) perspectives probably interesting: jBPM PDL and JBoss AS. I'll go deeper on them other day.

FIRST PROJECT
My aim is starting a RichFaces + Seam + Hibernate (JPA) project from scratch. Theoretically this is the best IDE for this. Let's see if it succedes. From RHDS perspective:
1.- File --> New --> Seam Web Project.
2.- Add Java Persistence facet to the project.
3.- Create a database connection profile (mine's MySQL 5.0).

After a little browsing through views it gets slower and crashes ("double free or corruption"). I'll increase memory (eclipse.ini) and restart. Later it gets obvious that it's "Red Hat HTML Editor" (JSPs default one) which causes the problem. It's maybe related to a known issue at the FAQ. Nothing urgent, anyway.
Update: this problem has automagically vanished. I can use RHHE ok now, dunno why...

Project has a nice 'All JBoss Libraries' library which contains 50+ jars which will hopefully let me develop without worrying on jars (for a while at least). Something similar happens with 'Web App Libraries', which includes not only seam but also other must-have like facelets.

It has an error (red square). You can find the error at 'Problems' view: "no persistence.xml" file in project. That's wrong, since it's at src/META-INF. Well, let's deploy! Shift+Alt+X, R will run it on a server. Since it's not configured yet it asks me which. I choose bundled JBoss 4.2 and cross my fingers. Starting... crash! :-\ Sigh... Well... Something wrong with the database: "Apparently wrong driver class specified for URL: class: com.mysql.jdbc.Driver". It seems something doesn't like my mysql connector.

It finally got solved copying mysql connector at jboss-as/server/default/lib. First JBoss lesson learned. After that, the welcome page was accessible.

RH HTML Editor issue aside, RHDS seems promising. Is finally the time Java development meets Visual Whatever integration? Hope so...

Ave, Good Programmer!

2007-08-03T11:45:00.000-07:00

Some days ago I was in a room with some developers. I was grumbling, as usual, on something (I can't remember what). As usual, my idea of throwing my salary away and building an enterprise came out again. Some of them thought I was joking, but I said my intention was hiring only the best developers available and paying them double salary of what they can find at the city. I, as I've said before (in Spanish yet), believe the difference between the best and the others is spectacular. I've just read another worthless post: 10 Developers for the Price of one.
If I just could get four of five of them, paying double salary (or even more!), there would be margin to make big money, at the same time they get a great payslip and a gratifying job...

Dreaming's free, I suppose...

Deadlines

2007-07-29T22:40:00.000-07:00

Dilbert, actual as usual

JSF (A love and hate story, endless yet)

2007-07-27T23:22:00.000-07:00

When I first met JSF I was having another relationship. I had been for 2 years with Struts. In the beginning it seemed to me (Struts) dull and thorny (I had just had a long affair with PHP), but when I met its parents Validator and Tiles, I fell in love. I was convinced by their configuration-files-for-everything approach, and its action-oriented workflow seemed to be a natural way to develop MVC.

In a travel I was presented JSF, and the first sight couldn't be more half-hearted. I felt I was doing just the same, and with worse tag libraries. Furthermore, it was not alone, but came with Spring and IBatis, so breaking the ice was even more difficult. Thinking on components and events? What for?

Suddenly, a third one came into my way and everything turned clearer: Ajax. Everything made sense. A text field would never ever be an empty box until somebody presses a button. Now, a text field deploys suggestions, connects to the server to asynchronously validate itself, activates and disables page fragments... And if you want to develop this the good way, JSF is a must.

This is the beautiful part of every love story, but every good thing has a catch: JSF is a very limited standard in term of components (and I am not the only one who says it). JSF is only a framework you can use as basement for something really interesting. It was born in 2004 as Sun fix to the gap at presentation layer at J2EE, but it was not only until Ajax when people has invested on it.

Implementations (MyFaces, Sun RI, Facelets...), frameworks (Ajax4JSF, ICEFaces, Tobago...) and component libraries (RichFaces, Tomahawk, jMaki...) promise a lot, but managing to make them work together is often annoying. Bad documentation, incompatibilities, the need for betas, sandboxes, nightshots...

Despite it, I think JSF is the best choice for MVC if you want Ajax. More specifically, (MyFaces + Tomahawk (a must)) + (Ajax4JSF + RichFaces (really powerful)). First ones give an stable enough and comprehensive base set, and latter, the full power of Ajax.

P.D.: MyFaces won't stop. They've recently delivered 1.2. In the wiki there's a good amount of JSF, MyFaces and even integration with other libraries.

P.D.2: interesting graph on Ajax for different technologies.

It comes from a J2EE Framework comparative, really up-to-date.

DRY: brief guide to keep you dry

2007-07-25T23:25:00.000-07:00

Some years ago a Bachelor teacher told us there's enough with a few principles to explain most nature phenomena. Osmosis, conservation of energy and a few others can model most of the things we see.

I think it happens the same with computing. In spite of the huge amount of languages, libraries and platforms there are, the grounds which make them good tools are very similar. Maybe the most important among them is "DRY principle": Don't Repeat Yourself. Repeating implies more work (a good programmer should be lazy), duplicating errors, reducing code mantainability, making changes harder... Here it comes the great sentence: "Every time you copy-paste, Lord kills a kitten".

My work environment for the last years has been J2EE, and I use the following tools to keep me dry:

Hibernate: minimizes data access code.
Hibernate Validator: takes advantage of persistence specification to check form data correctness and shows user error messages. If you don't use Hibernate you should have a try on Commons Validator.

Templating and cutting up pages, whether Tiles (a must if you still use Struts) o Facelets (best reusing with JSF).

Intensive CSS for presentation. There's no good at "improving presentation with CSS". The best thing you can do is composing web pages structure with XHTML independently from presentation, delegating 99% to CSS (1% left is for IE hacking).

Ideas + Software Engineering

2007-07-25T10:41:00.000-07:00


/**
* Software developing blog.
*
* @author Juan Ignacio Sánchez Lara
* @version v0.00
* @since 070725
* @see http://iiso.blogspot.com/
*/
public class ISE extends Blog implements SoftwareDeveloping, J2EE {

   //TODO: funny comment for first post.

   //FIXME: missing funny jokes libraries

}