Archive for November, 2007


If we can do this, anything is possible

Holy cow. We did it!

Three months ago a couple of guys in a bar were talking about how cool it would be to do a Java conference in Dublin. Many sleepless nights and countless emails later, 350 people attended the inaugural IJTC! The response was overwhelming. We had a world class lineup, the logistics ran like clockwork, the speakers and delegates had a great time. Awesome!

The thing that I got from it, was that it doesn’t matter whether you run a JUG, contribute to open source, blog or whatever. Just participate. Start something. Engage in community.

Next year, bigger, better, and even more fun.

Photos coming soon. Now I’m off to show the guys around Dublin.

Opening night

Yesterday’s event worked out really well. We had about 100 people in the theater take part in opening evening. My welcome speech was nothing to be worried about – I forgot half of what I was going to say, but that’s OK – it just gives me some opening words this morning.

Joel’s keynote presentation on how to build blue ribbon products was great fun and really informative. I have never seen PowerPoint used like that – hats must go off. Apparently there was some stress in getting him to the airport, I’ll have to get the full story today.

The panel discussion was very insightful. Covering everything from the impact of the new OSX distribution not upgrading its JVM to the JSR standards versus open source innovation, the future it seems is anything but clear. To know what to recommend, learn and implement will always be a matter of personal judgment and experience. The only way to keep up, is to engage and be aware of the landscape of competing products in the landscape. It’s one of the huge challenges of a career in IT, and one that should be enjoyed and embraced.

The first day of presentations kicks off in an hour and a half. I have to have a quick shower and get out to Cineworld. We are starting right on the dot today, but it will be a challenge getting everybody in to the first session by 9:15 – the Irish tendency for being casual with time really test your nerves. It’s not a party guys, fashionably late doesn’t work here. Lol \o/

Tonight is the night!

I am about to head off to the IJTC. It’s an incredible feeling to know that we have managed to put together a conference in only 3 months! We are expecting well over 200 delegates this evening, and even though I am MCing the event this evening, I am not in the least bit nervous. Tonight represent the climax of a hugely busy period in the lives of all of us organizers, and there is nothing for it but to go for it, let the chips fall where they may and have an awesome time.

See you there!

Unit testing with JAXB

I hit a snag when unit testing some code that makes use of JAXB generated objects. JAXB does not generate setters for collections :P This means that you cannot do the following:

Parent parent = new Parent();
List<Child> children = new ArrayList<Child>();
children.add(new Child());
parent.setChildren(children); // there's no setter method!

Instead, the following will do the trick, since JAXB guarantees that getChildren() will always return a Collection:

Parent parent = new Parent();
List<Child> children = new ArrayList<Child>();
children.add(new Child());
parent.getChildren().addAll(children);

Hope this saves someone some frustration.

Rich UI -> Component Based

A client of mine is developing a web application. The framework decision was made up front – Spring Webflow/MVC. I like Webflow. Its state machine based continuations concept is very cool. It lets you easy deal with things like back buttons, switching into a side piece of application flow (think needing to log in before continuing on to a section of the site) and maintaining a history of the state of a flow (where going back means using the application state as it was at that point in time). In short it’s pretty powerful stuff.

Only one problem – the application front end has been prototyped and signed off on by analysts used to working with desktop software.

Put simply, it’s expected to do some pretty crazy stuff. Think multiple layers of tabs, where the user can switch between different parts of the app without saving, navigating around fields from a central list of items that need correcting. Erk! The amount of hoops that have been had to be jumped through to get the requirements working have been huge, and it only keeps getting more complex. Without Webflow, I can’t imagine how something of this complexity could have been addressed. Classic web frameworks wouldn’t help on this one without some serious
bastardization.

The thing is, while Webflow makes it achievable, it’s not the right tool for the job. The interface requirements are too complex to easily do this stuff. Using a framework that ties you to the request based programming paradigm is the wrong way to go.

Put simply, we wouldn’t have the same sort of problems if the system we are building was constructed on a component based framework like Tapestry, JSF, or Wicket. Components have state, the page is composed of them and you react to events – “the button was clicked”. No more
request. No more session. Need to pull together info from multiple tabs? No worries – do it when the “I’m finished” button has been clicked. It takes a big mind shift to step away web concepts, but it’s worth it. At the very worst, there’s a new piece of kit in your toolkit that you can select for the task at hand.

As your tools become more capable, the requirements from your clients get more demanding. Your next web app interface won’t look like the last one you did. It will look like the latest whizz-bang offering from the latest flash in the pan start-up. Your clients use the net. They can see what others are doing. They expect that you can deliver the same. This is especially the case for internally used desktop replacement apps. If you don’t have the tools, you’re in for some late nights.

If it looks like a desktop app running in a browser, forget your father’s MVC framework – it’s just won’t cut the mustard.

It seems like a happy coincidence for Ruby on Rails that Web 2.0 apps emphasise simplicity. Classic MVC is not up to the task of rich UI.