Quality assurance with Sonar

It's incredible how unknown a tool like Sonar is yet. I guess Gradle suffers the same destiny. After all, they're both similar in their intent, improve the quality of your software. It seems lots of people know about unit testing (not so many about code coverage), less know about tools like Checkstyle or FindBugs (static analysis of code) and just a minority are aware of other esoteric metrics like cyclomatic complexity. And even the few that use all of them do not extract all the value that a dashboard provides. That's what Sonar handles, it will take your project and stress it showing the results in a visually appealing site. With no extra work from you, the only requirement is to use Ant or, preferably, Maven.

But seeing is believing so I'll try to convince you showing the whole process and what kind of enhancements you'll be getting. As the demo project I've chosen IWebMvc2. I've nearly finished the development by now so it's a perfect timing to improve quality. In addition it's a complex web application made of three different sub-projects so something must arise. IMHO the quality of the code is pretty good, in theory I just want proofs...did I just say humble? ;-).

The first task is downloading the project and installing it. It's trivial believe me (well as long as you know how to unpack an archive...). To run Sonar just go to the bin folder, select your OS and execute the provided script. Trivial again. Sonar show be accessible (although empty) at http://localhost:9000 by now. Go there and login with admin/admin. Select configuration and under Quality Profiles click on Sonar way with Findbugs: set as default.

Next step is to build our project and include the Sonar phase. This is done typing:

mvn clean compile sonar:sonar

Pretty easy, wasn't it? If the project was built successfully the console was updated and shows something like:

A quick glance reveals a row per project analyzed indicating the number of rules violated and the coverage of the unit tests. There's a little bug with the latest JDK and Cobertura that reports 0% coverage always. As a workaround use JDK6_Update13 for example. The build time reflects how long ago was this information retrieved (not how long took the build itself, tricky). One click on the project shows the dashboard (this is a trimmed version):

Here's the bread and butter! All kind of metrics! From the whole project. The graphic displays the number of modules (JARs) and the relative size of each one. It's used to drill down and get module specific statistics. In fact, every link allows to navigate to new pages with deeper details.

Our task is to improve the quality of the project (bit by bit) so we can navigate to the Violations section and get a detailed report of the problems:

The rules are divided in several areas, some are require while others are optional. Selecting one rule gives the complete list of locations where the code fails to comply. Selecting one of those locations highlights the code:

In the above example Sonar has detected a private method that is never called. For performance and maintainability it should be removed altogether. Now, this is not true at all because I KNOW this method is called using reflection. So I should just ignore this error (caution! static analysis tools are not perfect!). Otherwise I could simply open an IDE and correct the mistake.

Of course Sonar remembers previous scenarios and can track the project life cycle (time machine they call it). Ideally you should be tying Sonar with a Continuous Integration server (out-of-the-box includes a Hudson plug-in).

I'm not gonna lie, quality requires effort. Even if you're an outstanding programmer. Sonar will just help (a lot actually) by providing visual and reporting tools but expect a slow (sometime tedious) climb to the top. Fortunately, in the end, it pays dividends.

Finally...Maven

I've always been a happy Ant user. Even more so since Ivy has been available. Obviously that puts me in one side of the fence and I've been a very proactive supporter of that kind of project configuration. I must admit that included some rants about Maven here and there. In my biased opinion Maven lacked the flexibility that Ant provided and it was all about dependency management which was handled fine by Ivy. Probably my lack of confidence (knowledge) with the tool had some influence there too.

Four things made me reconsider my position: Hudson, Sonar, Netbeans 6.7 and the amount of time I was spending writing scripts. At work I had to install a CI server a couple of weeks ago and I was not using CruiseControl if at all possible (bad bad memories, I guess). That left Hudson as the best option (well, for me). I spent some time through the documentation and quickly realized that Maven was quite more straightforward than Ant this time. I needed a quality tool as well and Sonar has always been on my radar. Sonar works (again) out-of-the-box with Maven and requires some extra configuration with Ant. Being the lazy developer that I am I decided to test Maven with one project and see the results.

My first impression was pretty favorable. Migrating a simple Java project was a breeze and setting the job in Hudson trivial. I had the statistics online in less than half an hour. Finally I was understanding what was so good with Maven. It was not transitive dependency management, it was Convention over Configuration with the added benefit that other people where writing very interesting plugins for me. With absolutely no work on my side I had an automated build, quality control (testing plus quality assurance) and Jetty running. By now, I was in love with Maven. In more detail:

• Zero configuration
  So much time lost with Ant refurbishing the same scripts time and again...


• Dependency management
  I found Maven quite easier to handle than Ivy. I really really missed the master configuration of Ivy though (it saves time when you don't want transitivity for any reason).


• IDE support
  Today all major IDEs include seamless integration with Maven2. Latest Netbeans release, in particular, works wonders (the reactor plugin is awesome). Ivy support is scarce by contrast.


• Redistribution
  I've had to invest quite some work, many times, to offer Ant+Ivy scripts along with different project files (Eclipse, Netbeans, IDEA) to appease all kind of users. Not any longer. POMs are treated as first class citizens everywhere now. With the added benefit that I'll be able to upload the builds to the central repository.


• Future
  I'm under the impression that things like OSGi will be pretty much simpler with this approach.

All in all, I'm leaving Ant. For good. I can't say anything but praises about Ant, it's been years of comradery. And yes, it's a somewhat sad situation but I can't help seeing it obsolete, overridden..

Web framework comparison - Prototyping

Some may say I have a biased opinion on the topic at hand. True. I hereby declare that I have a clear preference for dojo+DWR+Spring MVC. But I happen to have a cruel client as well and when they asked me to prepare a comparison between several modern web frameworks they purposely left Spring behind. The aim here was to build quick prototypes of enterprise applications to test new ideas proposed by the business people. Obviously they current architecture is a little bit outdated and not suitable for the task.

They gave me a blank sheet to start although they did mention Ruby On Rails and GWT. The first one was in the origin of everything, a new board member had recently joined the company and in his former position they were using RoR for the task. The second was probably due to the fact that several projects had spawned recently with Flex+BlazeDS as the client side technology but noone was really sure if it was the right path.

Given this requirements I selected Seam, AribaWeb and Grails as well.

Obviously this is not an apples-to-apples comparison. Ariba and Seam are both full Java stacks. RoR and Grails are server side backends very oriented to relational database repositories. While GWT is a RIA tool to layout views in pure Java with some communication middleware, like say, dojo+DWR or, as already mentioned, Flex+BlazeDS could be.

But it makes for an interesting analysis anyway.

The criteria to elect the champion contain the following points:

• Learning curve
  We are talking about three hundred programmers that haven't ever coded in anything but JSF 1.1. Let's make the jump feasible.


• Prototyping
  How suited for the task is the project? A scripting language seems better to throw something quickly even though it's not maintainable later. On the other hand, a good IDE with good component integration, a drag'n drop visual editor and a preview screen makes stupidly easy to churn pages.


• Productivity
  How good are the APIs and third party libraries? How much code and configuration is needed to kick start a project? How easily is to connect client and server development?


• CRUD
  Enterprise applications today always need to interact with a persistent backend.


• Killer features
  Selling points for the upper management. What does this framework better? Where does it really shine? What unique characteristics does it put on the table?


• Weakness
  And what about these...?


• Maturity, popularity
  Is it a safe choice? Will it be around in the not so distant future?

There were others but neither as interesting (licensing, standardization) nor useful to you (migration, code reusability) so these make a good list. I'm not posting the tabular data for two reasons, first it depends heavily on the weights you assign to each column and second it's subjective and I don't want to start a flame war.

But here are my personal conclussions.

In the first round both RoR and GWT fell off the roaster but for very different reasons. In the case of RoR it scored very well in every technical category but, even if I could use it, the truth is a company like this is pretty commited to Java/JEE and such a rupture means time and money. And they're both scarce this days. Maybe for highly innovative teams in core areas but not as a general purpose tool. GWT didn't fare equally well. First for a RIA builder it lacks a decent widget library. Then I like DWR remoting better(biased again?). And finally it shuns standards like a plague. With this conditioning you're better served by Flex. Any day.

The second round saw, and this was a suprise, Grails fail. Grails happens to have the same punch as Rails and then some more. A great ORM that simplifies greatly CRUD operations (nothing really can beat code generation and a book.save()), scripting capabilities, joint compilation, Spring et al. Unfortunately it lacks a matching client plug-in. Flex is not there yet and dojo is too much work for a solution specifically looking for speed of development. The syntax is concise but many times awkward and in general Groovy/Grails still lack maturity (IDE support is minimum, plug-ins quality varies greatly, too many bugs yet). I guess you get used to Java's 24 months release cycle with bullet proof quality. Groovy is different in this aspect. I have good feelings about it (more with SpringSource behind the projects) but it takes time.

The two final candidates provide the full stack, client and server. Seam is IMHO more powerful and a safer choice in general. The people behind Seam are the same that participate in several JSRs and other high profile projects like Hibernate. JBOSS has always been a very active OSS player and the quality of the components (EJB3, Richfaces, JBOSS Tools, Hibernate) is out of question. There's very little bad I can say about Ariba. It's new (very new) in the OSS space and the look&feel is not spectacular (subjective I know). That last bit was important because you want the wow factor when showing a innovative project to the final user. I have to admit that JSF weighed in favor of Seam here but in the end it was a worthy winner for us this time. Kudos to them!

Book review - Spring Web Flow Web Development

This article was promoted to JavaLobby as well

Right now there are two trends to develop web applications, either you choose the RIA model or a conversational approach. In the former, say Flex with Cairgorm, both the model and the state is handled by the client. In the later, the server manages the scope sending a view to the browser which acts as a renderer. Of course, interactivity has improved over the years and nowadays partial requests are a must to improve user experience. Spring WebFlow is the SpringSource approach to a server side (work/page) flow management for web applications and Spring Web Flow Web Development, the book, (I could think of better names!) tries to explain how to leverage it.

The task is not minor because, let's face it, Java is a very complex platform and to start with WebFlow you should have a good understanding of JEE (at least JSF and the Servlet APIs), Spring and MVC in general. AJAX is welcome as well. The book, of course, can't help you there (you'd need a whole collection for that). This is not for novices! Fortunately a lot of people have learned JEE and Spring through the years and it's a matter of learning Webflow step by step but in depth.

Now, here the book shines. I like the formating, very clear and clean, and the language, simple and direct. I would have changed the chapter structure a little though. I missed individual chapters for persistence (Security has one) and Spring MVC (Faces has one) and I would have reordered some things here and there (configuration is scattered) but that's subjective and overall the steps make sense. The concepts (flow, action, state, transition, continuation) are well defined and you get a grasp pretty soon but some times the book is too comprehensive like when enumerating the methods and fields of the available variables (messageContext, flowExecutionContext et al). This makes for a hard reading but it will be invaluable as a reference book to some. I prefer IDEs for that task though. In the same sense I missed more diagrams and graphs (I'm not referring to UML class diagrams here). In a book about flows it should be pretty easy to plot concepts using some circles here and there. In my mind, circles are not less valuable than XML snippets (the book has tons of these don't worry) and the reader will gladly accept some pictures to clarify concepts (and thank you for them). Nothing too fancy, this one (extracted from the book) is more than enough:


In summary, the book is extensive and a great tool to learn first, and as a reference guide later, to Spring Webflow. It's dense and it explains lots of concepts in depth. Be warned that to extract all value this book requires previous knowledge of complex notions, among them: Spring, JSF, AJAX, persistence/ORM, Security, unit testing and probably more. The authors have made the effort to introduce all these libraries/skills when they're first used but that just lessens the burden (a bit). All in all, an easy candidate to recommend to those who need to extract all the power that Webflow 2 has to offer or teams that are about to start a new project and need an initial push with the technology.

PhoneGap, my new toy

The best thing about being a consultant is the fact that you have to work for different clients and different projects all the time. My last assignment included a lot of Flex and, now, mobile development.

Being a lazy developer, as I am, I tried to find similarities with web development which, well, feels comfortable. PhoneGap is a OSS project to build cross-mobile (native) applications using the familiar HTML/CSS/Javascript stack. It currently targets Android, iPhone and BlackBerry. This last one was the most important for me this time and, unfortunately, the one that was lagging behind, with a poor overall situation (the maintainer had abandoned development).

No problem, that's the beauty of Open Source development! A quick look at the code (because that's actually the best available documentation) and I got a good idea of the intents both in iPhone, the core platform, and BlackBerry. It seemed that many lines were copied from the BlackBerry documentation and did not serve any obvious purpose. Given that the current code was failing to execute in the simulator I started to refactor...here and there, you know? By the afternoon I had a preview version with a Javascript Hello World and I was pretty happy. I sent the code to the PhoneGap team and got a warm welcome and some advice. Another day and I've been able to submit to the mailing list a working implementation of part of the API: telephony, vibration, location (GPS) and device information. Not bad for a couple of days! Even more so knowing it was my first mobile development ever (a fellow co-worker had to show me the use of the simulator...endless shame).

And now for Windows Mobile...a much bigger job given that there's no code to start with. An implementation from scratch and with C#. Too daunting a task indeed! Let's see how it turns out.

Google App Engine account active

I've been lucky I guess. I've been looking for affordable Java hosting options for ages and now Google offers me a great alternative for free. I'm just installing the required SDKs and plug-ins. From there some changes to the core of IWebMvc2 to get security going and I hope to be able to create a home page with the demo application running! Thanks Google.

Update: It won't be that easy I guess. Missing Hibernate support (though JPA is available) means loosing all the related functionality (validator, search, extensions to the standard, ...). Some parts can be swapped with little effort but I'll have to devise something for the rest. Good times ahead

IWebMvc2 stable release available

A quick post just to mention I've compiled and uploaded a new IWebMvc2 version. Although it includes a Beta version of dojo most things work (minor issues with image preview in IE remain). It packages two new widgets, Panel and Chart (though the later is considered preliminary and it's not enabled in the demo). The Panel widget allows a user to freely move content around the screen, collapse it or drag&drop it to enabled zones.

Apart from those this release includes loads of bug fixes and is nearly final. It's been tested under FF3+, IE 7/8, Chrome and Safari with good results (of course, report any issues you can find).

The demo application is composed of several pages this time (instead of the CRUD widget alone) so the developer can see how widget composition does work. In addition this time I've chosen a full download (instead of Ivy) to achieve a better user experience when just evaluating the framework. It should be much faster this time, with a boot time under a minute (unfortunately HSQLDB still needs to be populated on startup).

My next steps include a deep evaluation of other Java web frameworks including Grails, Ariba Web and Oracle ADF Faces. Obviously each of those have unique characteristics difficult to replicate (and, well, more workforce) but that makes for an interesting goal, doesn't it?

I hope you enjoy it!