My article on using Apache Derby (aka Cloudscape) in JBuilder has finally been published.

Apache Derby is a pure Java™ database, like JDataStore. Since the future of JDataStore is uncertain (read the JBuilder 2006 release notes), it is probably a good idea to investigate all your options.

I attended the No Fluff, Just Stuff symposium this past weekend in my home town of Calgary. It was great. I expected nothing less, after having attended the 2003 version in Denver in May 2003. If you’ve been attending JavaOne year after year, then I suggest you take a break next year and try out a No Fluff Just Stuff symposium, especially if one is making an appearance in your home town. It’s better. It’s focused. No vendors. No fluff. Just speakers who are all published authors and acknowledged experts in their fields. I’ll be making more posts on some of the more interesting tidbits later this week. Stay tuned.

Well, this is my first ever BorCon. Quite interesting, given that we have a brand-spanking new version of JBuilder. Since I’ve been holding off on re-designing one of my older web applications pending the release of JSF, I decided it would be good to concentrate on the JSF sessions. On the weekend, I attended an excellent tutorial by Jeff Swisher on JSF. Since he’s actually been implementing JSF solutions for months now, he had a lot of great information to impart. I particularly liked the way he contrived errors in his examples, in order to illustrate the causes of some of the more obscure error messages that are generated by the JSF framework. Valuable stuff. It’ll save me hours, if not days, tracking down problems once I get going.

The next JSF session I attended was given by Karl Ewald. Since he was one of the Borland developers who worked on the JBuilder JSF support, I had high hopes for this session, and I was not disappointed. Interestingly, unlike Jeff Swisher, who spent most of his time messing about in the faces configuration editor, Karl used the new “Flow” tab on his JSP examples. He showed us how to “sketch out” an entire web application in minutes, generating skeleton artifacts as he went. Wow. A completely different kind of work-flow, but I liked it, and I think it will be a huge productivity booster.

Now, I just have to find a little free time to start using this stuff myself…

For years, I’ve been diligently erasing all traces of pre- and post-fix naming conventions from the source code under my control. I’ve always hated it. The argument I most commonly make for this is that, IMO, it makes the code less readable. Now, in a happy coincidence, I have been reminded about this topic, when I have actual proof to point at to back it up.

Now, “readable” is a very subjective term. Some people would insist that the prefix “m_” provides additional semantic meaning to the field, telling you that you are dealing with a class field instead of a parameter or local variable. In Java, so does “this.”. Others would add tags like “str” to the beginnings of every String field name. Again, yes, it adds semantic meaning, but any decent IDE will provide the same information in several different forms (tooltips, find definition, etc) without the extra baggage.

So, what about this proof? Consider the following:

Aoccdrnig to rsaerech, it dseon’t mttear in waht odrer the ltteers in a wrod are, the olny iroptmant tihng is taht the fsirt and lsat lteetr be at the rghit pclae. The rset can be a taottl mses and you can sitll raed it wouthit any perbolms.

Now, I hope you see where I am going. The real problem with all these pre- and post-fix notations is that they screw up that first/last letter recognition that seems to be hard-wired into readers of the English language, mostly because of some redundancy features of English. (See the links at the bottom of this post for more information about this.) So, there you have it. Proof that readability in your code is diminished by the use of pre- and post-fix naming conventions.

So let’s all get out there and start improving the readability of our code. JBuilder has some nice Rename Refactorings to help. ;-)

References Comments from a researcher at Cambridge A letter purportedly from the original researcher of the topic

And thanks to Anders for the inspiration from his new CafePress shop.

As a follow-on to my first post about Java applications…now here is a nice looking app. And useful, too.

http://www.jformdesigner.com/demos/

I was recently involved in a development effort where the plan was to rewrite the client-side software in Java, to make it portable. Some members of the development team were reluctant to even consider Java, because the applications “look so bad”. They hadn’t seen any recent Java Swing applications. I had. You should take a good hard look at some of the work highlighted by the Swing Sightings page – http://java.sun.com/products/jfc/tsc/sightings/.

I was especially delighted by an old favorite of mine - ViewletBuilder. It is a fine example of a mature Java Swing application, which has just gotten better and better over the years.

Another eye-opener is Techdigm Office 2.0. Hey, look Mom, you can create an Office suite of applications using Java!

So, the next time someone starts spouting that drivel about Java applications “looking bad”, you know where to send them. The only reason for Java applications to look bad these days is poor programming. Let’s make sure we do our best to fix that.