It's the Length Of The Compile/Debug Cycle, Stupid (with apologies to Bill Clinton)

More than anything, I blog this to remind myself of this, because I seem to forget it more often than I should:

"The single most important factor in the quality of an individual's software development is the length of the compile/debug cycle"

I don't know how many times I think to myself 'I could set up a proper environment in which to develop and test this change, but it's such a little thing I'll just fudge it'. Like I use the Ant build instead of the IDE build. Or I redeploy the EAR instead of setting up hot class replacement.

And every single time the 'little thing' requires far more compile/debug cycles than I expected, so the job either:

• takes way longer than it should
• gets done sloppily because you can't stomach umpteen more compile/debug cycles to tweak every last little pixel alignment

And every single time I wish I'd spent that little bit of extra time, upfront, to set up my environment efficiently.

This principle extends to the build/upload cycle too. If I can reduce the amount of stuff I have to re-upload to the server when I make a change, I can reduce the amount of time I have to get distracted and go surf slashdot, thereby 'context switching' my brain and slowing me down even more.

Anything that reduces that compile/debug cycle is gold. We've all known this for a long time, but I think we all often forget it again too.

Gah!

New Features in Eclipse 3.5

In an attempt to attract younger developers, the next version of Eclipse is to include Unlockable Achievements:

Beta testers are encouraged to submit their own Achievement ideas. Suggestions include:

• Anally Retentive: remove all warnings from your code. Yes, even those ones about serialVersionUID


• Saintly Patience: use BigDecimal for more than 5 minutes without wishing for operator overloading in Java


• Ant Fan: start an Ant build and watch it finish without visiting Slashdot in between

Update: this blog post was, of course, a joke. However it appears that 3 years later Microsoft has actually gone and done it!

Better Than Free: Metawidget v0.65

There was a time, years ago, when just having a $0 price tag on a piece of software would have sparked people's interest. Nowadays, the success of Open Source has meant that free is not enough.

For a new software project to be noticed, it doesn't just have to be free: it has to be well documented, well tested, have plenty of working examples, an attractive Web site and high quality code. And even then the competition is fierce: developers are busy people, and have very limited time to evaluate new technologies.

So the big feature in the new release of Metawidget, aside from a number of upgrades and enhancements (such as Commons Validator support), is a Live Demo that lets you immediately get in and start playing and coding with Metawidget. I'm hoping it's a great way to let people try it without having to download, unzip and read through the usual distribution.

The Live Demo uses an enhanced version of the Groovy 1.6 Console Applet to give you a fully working Java-like scripting environment. Everything is set up for you just to click Run. You can then fiddle with the code, even import your own business model classes on to the CLASSPATH to see how Metawidget renders them.

You can find the Live Demo here:

http://metawidget.org/live-demo

Also, special thanks to Gerardo Diazcorujo and Ryan Cornia for their help testing this release. Your continued feedback is invaluable to us. Please let us know what you think.

A Unified Theory

I just had an interesting exchange with the guys from the OpenXava project. We discussed differences in our two approaches, as well as those of other UI generation projects, and what it would take to unify them all under a JSR one day. I think we're a long way from that day, primarily because UI generation isn't particularly 'mainstream' yet (at least, not in the sense of ORM). Still, it's often said in physics that even though we don't know what the Unified Theory is, we know something about what features it must have.

Can we say something similar about UI generation? I'll list here all those features I think are being explored, either by Metawidget, OpenXava or one of the other projects, and see if we can update this page over the years to form consensus.

Static or Runtime

Should the generation happen statically or at runtime? If runtime, how do you allow customisation? If statically, how do you allow re-running the generation when the domain model changes (without losing any customisations)?

Static: n/a
Runtime: Metawidget, Naked Objects, Woko

Modeling Language

Should the generator have its own modeling language, which developers use to describe the UI, or should it try and derive the UI automatically? Do modeling languages introduce error-prone duplication? Is automatic derivation too inflexible? Is there enough metadata to drive automatic derivation, or do we have to 'guess and fill in the gaps'?

Yes: n/a
No: Metawidget, Naked Objects, Woko

Production or Prototype

Should we expect UI generation to be able to be used in production applications, or only during a prototyping phase?

Prototype: n/a
Production: Metawidget, Naked Objects, Woko

Customisation

What sort of customisations of the generated UI are important? Graphics? Layouts? How should we facilitate them?

Pluggable: Metawidget, Woko
Search-based: Naked Objects

Bounds of Generation

Should we try to automatically generate the whole UI, or just pieces of it? Is generating the whole UI flexible enough? Is just generating pieces useful enough?

Whole UI: Naked Objects, Woko
Just pieces: Metawidget

Multiple Platforms

Is supporting multiple platforms (eg. desktop, web, mobile) important?

Yes: Naked Objects, Metawidget
No: Woko

Consistency

Given the same domain model, should we try and produce a consistent UI across all platforms? Does this risk a 'lowest common denominator'? Does tailoring uniquely to each platform introduce too much work for the developer?

Yes: n/a
No: Metawidget, Naked Objects

Diverse Architectures

Should the generator care about diverse architectures? Is mandating the technology stack of the application too restrictive? Or should we try to enforce 'good coding' that way? Does supporting multiple versions of everything introduce too much complexity? Is the ability to retrofit existing applications an important goal?

Yes: Metawidget
No: Naked Objects, Woko

Third Party Components

Should we support third-party UI components? What if they are not available on all platforms (eg. desktop, web)?

Support third-party: Metawidget
No explicit support: Naked Objects, Woko

Non-Domain Model Objects

Should we support modelling objects that are not strictly part of the domain? 'Solution space' objects, such as search screens that are user-centric (even role-centric) and not persisted to long-term storage?

Support non-domain model objects: Metawidget
No explicit support: Naked Objects

---

Convergence

Following conversations (some below, some in newer blog entries) with various parties, we note some convergence with future releases of products. Specifically:

Naked Objects: 4+ supports deriving metadata from different sources. Newer viewers may allow generating just pieces of the UI, and also modelling non-domain objects. Future versions want to support third-party components.

Woko: 2+ will allow more diverse architectures.

Generate User Interface Automatically: Metawidget v0.6

Version 0.6 of Metawidget, the tool that lets you generate user interfaces automatically, is now available. This release includes:

• JBoss jBPM support (see this blog entry)


• Swing AppFramework support (see this blog entry)


• JEXL support (see this blog entry)


• Upgraded GWT support (to 1.5.2)


• Upgraded Android support (to 1.0)

Special thanks to Rintcius Blok for his contributions to this release!

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.

Metawidget: Ready, Set, Action!

The new release of Metawidget furthers its philosophy of 'inspecting the existing back-end for as much information as possible' by going after actions.

So now, in addition to automatically generating and wiring up textboxes, checkboxes etc. based on the properties of your business model, it'll generate buttons based on the actions of your business model.

This support is all pluggable, of course. With this release we've included two plug-ins: one for JBoss jBPM and one for Swing AppFramework.

JBoss jBPM

If your back-end architecture uses JBoss jBPM to define pageflows...

<pageflow-definition name="newuser">
   <page name="contact">
      <transition name="prev" to="account" />
      <transition name="next" to="card" />
   </page>
</pageflow-definition>

...then you can now point a Metawidget at that pageflow...

<m:metawidget value="newuser.account"/>

...and it'll generate command buttons that are localized and wired up to the correct actions...


You can see this in action in the included DVD Store Example, which retrofits an existing Seam application to generate its input fields and command buttons automatically, reducing all that boilerplate code.

Swing AppFramework

If you're using the Swing AppFramework (JSR 296) to structure your Swing app...

@Action
public void save( ActionEvent event ) {
   mMetawidget.save();
}

...then you can now point a Metawidget at your business model, and it'll generate command buttons that are localized and wired up to the correct actions. You can see it in action in the included Car Demo.

You can further combine all this with the other pluggable inspectors, such as JexlInspector to easily and declaratively control your app's actions...

@UiAction
@UiJexlAttribute( name = HIDDEN, value = "${!this.readOnly}" )
public void edit() {
   ...
}

@UiAction
@UiJexlAttribute( name = HIDDEN, value = "${this.readOnly}" )
public void save() {
   ...
}

@UiAction
@UiJexlAttribute( name = HIDDEN, value = "${this.readOnly || this.newContact}" )
public void delete() {
   ...
}

@UiAction
@UiComesAfter( { "edit", "delete" } )
@UiJexlAttribute( name = "label", value = "Back", condition = "${this.readOnly}" )
public void cancel() {
   ...
}

This code is enough to generate:

• an Edit button that, when clicked, disappears in favour of...


• ...a Save button


• a Delete button that only appears if it's not a new business object


• a Cancel button, that says Back if the user has not edited anything yet

You can see it in action in the included Swing Address Book Example...


So now there are even more places Metawidget can inspect your existing back-end architecture and remove the need for you to write boilerplate code for your existing front-end framework!

Duplication in User Interfaces: 10 Questions

I'm trying to collect some data about the problem Metawidget is trying to solve. Please take a moment to complete this short survey. I'll post the results in a later blog.

---