Skip to main content

God bless the tools that support well your process

Posted by fabriziogiudici on January 24, 2007 at 3:17 PM PST

Well, my last blog post was about the Rio plugin of Mistral, and ended with an open (and expected) problem related to performance - something that I thought I'd have addressed in the next post. But as often happens, other commitments prevented me from completing the next step in the planned time - I think we'll have to wait two or three weeks still.

In the meantime, I'm busy - among other things - with two small projects (to be precise, a tiny one and a small one, which anyhow is just the first phase of something that should evolve in future in a very interesting stuff). Both are related to imaging and both make use of Mistral, even though they just need its basic features. I'm taking the chance of another little diversion from my main blog topics and I'm going to talk about the process (you know, I'm a big fan of it, it's the process that saves a project rather than cool language syntax :-P ) and how a good tool should support it.The latter project is a web application which manages photos. Nothing really complex, but the customer is really focused on the UI interface, which must be user friendly and also aesthetically appealing (it happens that the aesthetics of the user interface is one of the higher risks in the project). As the time span of this first part of the project is pretty short and the budget limited, an agile approach for documenting the specifications is important. Documenting an UI with a lots of natural language in a classic SRS (System Requirements Specifications) is really expensive and probably useless, as you're wasting a lot of time and the customer would probably make a lot of changes only after seeing something (have you ever heard of IKIWISI? "I'll know it when i see it").

In this case, the better documentation is the UI itself. This means that collecting the specifications and designing the UI should be done at the same time; this means that you must design the UI together with the customer. This in turn requires:

  1. A web technology with a good separation between code and HTML design;
  2. A good IDE that makes it very fast the "edit - compile - deploy" cycle

It turned out that two very good choices for this project were Wicket for the former problem and NetBeans for the latter. It's the first time I'm using NetBeans on a web based project (with the exclusion of some workshops and classes about J2EE, in the last year I've been using it mostly for a RCP application). I'm really satisfied with it: not only NetBeans is able to support me out-of-the-box, without ever requiring the Enterprise Pack (for my project Tomcat is enough), but supporting hot-redeployment with the embedded Tomcat I need only a couple of seconds after saving the changes to source files and then I see them live in the browser. And this comes with just a few mouse clicks for creating a web project and just hitting one button for (re)deploying the application.

PS And the customer likes this way of working very much.

Technorati tags: NetBeans, Wicket

Related Topics >>