We're Hiring Again!

Here's the job ad we're posting. Following a successful first hire earlier this year, and increased investment from a leading Australian financial institution, we're hiring again. A chance to work from home, and work for me! What a dream job :)


Senior Java EE 5 (J2EE) Developer: $120,000 AUD + super

• Small, focused team


• Modern, well-crafted software


• Work in city or from home

A rare opportunity to join our small consultancy team. We have recently received substantial investment from a leading Australian financial institution and we must grow to meet demand.

You will work side-by-side with one of Australia's premier Java EE developers, and be intimately involved in all design decisions.

You will be a pragmatic programmer. Software development will be in your blood: a natural instinct. You must be passionate about Open Source and Java EE. You will demonstrate advanced analytical skills; an eye for elegance and craftmanship; a passion for refactoring, unit testing, and delivering secure and robust code.

Your skills will include many of the following:

• JBoss


• JSF/RichFaces


• XSL (T and FO) and XPath


• EJB 3/JMS


• JPA/SQL


• Metawidget


• HtmlUnit


• HTML/CSS

In addition, you will have excellent communication skills and be comfortable interacting with stakeholders at all levels.

Work from home will be offered providing that you can demonstrate an appropriate working environment. You must be a citizen or permanent resident of Australia.

To help us sort applicants, include your CV and a 1 page overview highlighting your suitability for the role. Links to examples of your work (eg. web sites you have built, blogs you have written, Open Source contributions etc) will be highly regarded.

Please send your application to jobs@kennardconsulting.com.

Retrofitting a UI: GatewayWarDeployment example

Adam Bien recently asked me to create a Metawidget example for his Java EE Patterns and Best Practices Kenai Repository, based on his Real World Java EE Patterns book.

In order to demonstrate the changes typically required to incorporate Metawidget into a project (and the code savings it typically brings) I retrofitted one of Adam's original projects, his GatewayWarDeployment example. I've called mine GatewayWarDeploymentWithMetawidget.

To view the new example:

1. Ensure you have Metawidget installed at its default location (/metawidget-1.05/metawidget.jar)


2. Get sources for the Java EE Patterns Kenai project in NetBeans using Team > Team Server > Get Sources... (see this screencast for detailed instructions)
3. Open the GatewayWarDeploymentWithMetawidget project

The example works just as before, but two files have been changed. The first is the managed bean, LoadView.java, which now includes Metawidget annotations and is therefore longer. The second is the UI page, createorder.xhtml, which now uses a <m:metawidget> tag and is therefore shorter:

LoadView.java	createorder.xhtml

In such a small example there is no overall saving in lines of code (larger examples have more dramatic savings). But there is still a significant reduction in duplicated declarations (field names, types, action names etc) and therefore reduced possibility of error when building (and maintaining) the UI. Note Metawidget is handling both the input boxes and the buttons, including enabling/disabling the buttons in line with the business logic. This is declared by the code:

@UiAction
@UiFacesAttribute( name = "read-only", expression = "#{load.emptyLoad}" )
public void dropLightest(){
   ...
}

Of course, this is not a great demonstration of all the features of Metawidget. More extensive examples can be found under the /examples folder of the Metawidget distribution. But hopefully it's enough to get people excited without confusing them with lots of code.

My thanks to Adam for his help and encouragement in developing this example!

Automatic Form Generator: Metawidget v1.05

Version 1.05 of Metawidget, the automatic form generator is now available! This release includes the following enhancements:

• Improved JSF 2 support (Mojarra 2.1 and MyFaces 2.0.3)
• Support for annotating private fields
• char support
• JSF2 AjaxProcessor
• Read-only actions now display as disabled buttons (rather than not displaying at all)
• Bug fixes, documentation and unit tests

As always, the best place to start is the Reference Documentation:

http://metawidget.org/doc/reference/en/pdf/metawidget.pdf

Your continued feedback is invaluable to us. Please download it and let us know what you think.

SeamForge: Latest Update

I'm growing a little uncomfortable with the direction SeamForge is taking. Here's an output from the latest build:

$ forge
   ____                          _____                   
  / ___|  ___  __ _ _ __ ___    |  ___|__  _ __ __ _  ___
  \___ \ / _ \/ _` | '_ ` _ \   | |_ / _ \| '__/ _` |/ _ \  \\
   ___) |  __/ (_| | | | | | |  |  _| (_) | | | (_| |  __/  //
  |____/ \___|\__,_|_| |_| |_|  |_|  \___/|_|  \__, |\___|
                                                |___/     

[no project] $ new-project

Greetings, Professor Falken. Would you like to play a game?

Rant: Who Designs These UI Frameworks Anyway?

I started a lively discussion over on Javalobby ranting about UI framework APIs.

Specifically: how come hardly any UI frameworks define their widgets in terms of interfaces, as opposed to abstract base classes? I listed off a dozen mainstream UI frameworks that do this, and was fortunate to get dozens of people responding with their thoughts. The key outcomes were:

• Some UI frameworks (albeit a minority) are interface-based. Examples include ItsNat, Vaadin
• Other frameworks have considered being interface-based (Swing), but on balance decided to use abstract classes. Neither is optimal: "when I was working on the Swing team at Sun Microsystems back in the early days of Java. Some people on the team were of the opinion that Component should be an interface and others that it was best as an abstract class. But really, neither sounded like a good choice"
• Abstract base classes limit future use cases. This is dangerous because "anything of strategic importance will be used in ways that the original designer cannot anticipate"
• The problem with a 'monolithic' interface is that it is cumbersome to evolve: "You will soon have IComponent, IComponent_v2, IComponent_v3"
• The problem with 'granular' interfaces is that you often have to pass around many of them together: "I found it to get problematic as I'd pass around something like (Sizable, Locatable) and then deep in the heart of the framework I realised I needed Focusable also, and I then had to go back up the stack chain and add it to all parameters"
• Java does not have a good way to bundle several 'granular' interfaces together, but other languages may (Scala traits): "It's not yet possible to write Component the way I really want to write it. To do that, you'd have to change Java."

Finally, I would like to apologise to any who were offended by the somewhat incendiary tone of my article. It was pitched as a 'rant' in order to encourage responses, but in no way was I suggesting the UI frameworks I listed were anything but successful - or that their creators were anything but intelligent, brilliant people.