A nice little article (if a little old, now) from Scott Davies of aboutGroovy.com (via IBM Developerworks):

Grails and the mobile Web.

I was introduced to this a few years back by a colleague (thanks, Steve!). It has been a favourite ever since:

http://www.dynarch.c … m/projects/calendar/

There is now a Grails plugin, so there seems to be life in the old girl yet.

You need to be Blocking Unwanted Parasites with a Hosts File.

Trust me on this…

This is the last project I worked on at Energex/SPARQ; the "Universal Logging System."

The task was to produce a suite of applications capable of browsing the fairly substantial amount of live and historical/archived substation data.

Man, I gave myself trouble!

Like a fool, I insisted on the "buy not build" mantra right up to the point when it became clear that-wish as I might-it was really not possible to buy anything that could handle the type and quantity of data involved. To be more precise, the available budget was a few orders of magnitude smaller than the available commercial toolsets but the effect was the same.

So: having expended (wasted is a little too strong a term…there were some learning outcomes, after all) a fair amount of time attempting to bend the likes of Eclipse BIRT, Pentaho and Crystal Reports to my will, I was faced with having to build a large-ish integration framework and associated suite of applications from scratch in a compressed timeframe.

It goes against the grain but OK…time to start building from scratch.

I chose to use a graphing tool called TeeChart. TeeChart was recommended to me by a colleague who had used it before and trusted it. A few bugs aside, it works well and can handle lots of data quite nicely. As for the rest: Spring and Spring modules (Caching, Valang); a four instance JBoss cluster on RHEL4; JRockit as the JVM…

All went well, initially. I hummed along putting together a nice swing-based framework allowing for the integration of disparate datasources and it finally seemed like I was back on track.

Until this point, I had been building with Spring MVC/Webflow but I had wanted to "move on up the food chain" and get the company using JSF. I duly adopted RichFaces and set about building a nice, tabbed interface.

This hummed along for a while until a 'gotcha' appeared (you knew one would, didn't you…).

In my design, each tab in the UI would represent a parameter-entry form, designating the required datasource and associated query parameters. This could be templated out easily enough into small included files, would be quick and easy to understand and so would be correspondingly easy to build.

(You will see the sort of interface I was trying to get build when I get to the Swing app. that was part of the application suite, a bit later in this tale of woe.)

There is a little entry in the facelets FAQ entitled "I'm getting Duplicate ID Errors (and Bindings)":

This can be caused by a couple things. The first is when you use JSTL or logical predicates in your templates which add or remove components based on some volatile logic in your model. It's not so much the case that your component tree can't change between requests, but you do open opportunities for errors to occur. Sometimes explicitly providing id's to your components corrects this problem such that JSF has no way of accidentally assigning a duplicate.

The second way this can happen is when you using 'binding' attributes on your components. If you are binding components to anything other than request-scope, you can run into problems where components, and their assigned identifiers, get injected into another page, conflicting with their identifiers. Again, you can attempt to provide explicit id's to your components to avoid conflict and guarantee uniqueness, but it doesn't fix the greater issue with application/session scoped bindings:

1) UIComponents are not Serializable- and therefore cannot be clustered

2) UIComponents are not thread safe can cannot be used by multiple requests at once

Binding UIComponents to backing beans is actually something worth doing to ease particular use cases. Instead of using a session/application scoped bean, use a request-scoped composite mediator that receives your session beans and the UIComponent instance to coordinate behavior. The injection of your session-scoped beans can be managed with the faces-config managed-property or with any of the 3rd party extensions such as Spring 2.0 or Seam.

Those key-words that I have highlighted shot the whole UI down in flames. I was 80% of the way through and could not continue to use JSF. To this day, I have no solution, and I note that the FAQ entry remains.

I had to restart the UI using basic Spring MVC and foregoing all the AJAX-y goodness that Richfaces would have given me (yes, I could have picked another AJAX framework, but at this point I was well and truly shell-shocked and only wanted to hide under my desk. I definitely didn't want yet another setback).

I have to give it to my manager: he coped with all these setbacks admirably. Thank you, Gary!

Thus the application suite as shown above was developed.

And shown to the 'users.' They hated it!

There had been a long discussion over web-app vs. desktop app that had finally come down on the web-app side. Oh Well!

I had continually been showing the app to various "interested parties", tweaking and fiddling based on suggestions/feedback. The time to demo to the "world at large" rolled around. During the demo, one of my main contacts decided to go feral and panned everything about the project: the existing system was perfect; the new features weren't useful (to him); the colors (chosen to be precisely the same) were bad, etc., etc. In fact, it was all a complete disaster that proved how incompetent I and my colleagues were!

Once the dust had settled on this, two facts became obvious:
1. he was one of the developers of the old system and perhaps felt a little 'threatened'
2. his problem was not with the suite at all, but turned out to be with the settings established for IE6 by the corporate SOE policy.

In the end, much of the fuss came down to one little checkbox:

Once we had set up his IE6 to create new windows as needed, rather than reuse existing windows (and potentially lose what was happening in that window), all settled down.

One never know, does one!

Still, it was decided to 'deemphasise' the web-version (it was pretty much functionally complete, anyway) and start on a pure desktop UI that would talk to the middle tiers of the system but provide an IE6-free 'experience.'

This piccy shows the Swing-based desktop application:

This app used TeeChart (for its already-mentioned ability to handle large datasets, but also because it handles interactivity quite well) with a few SwingX components thrown in.

It is a shame that time/money eventually caught up with me and I didn't get to complete it.

On the other hand, I was exhausted and happy to see a halt. The project had been a sequence of disasters, technically and 'politically.'

I'll never trust JSF again, that's for sure.

I'm also more convinced than ever that "thou shalt never contemplate one-person projects."

From Bob Martin, Object Mentor Inc.: Craftsmanship and Ethics.

I would recommend that all managers and PMs (yes, and coders!) watch this.

And then follow up by reading this.

And then follow up by reading this.

Something I hear a lot, RTSJ (JSR-1/JSR-282) notwithstanding.

So what's this, then?

Lexecorp's Software project process and tools? page.

Just received this recommendation from Tony Obermeit via LinkedIn:

"Bob introduced me to Java at a training course back in 1997, I've also attended conferences overseas where he has presented and he has always been highly knowledgeable and well received. He knows his stuff!"
Service Category: IT Consultant
Year first hired: 1997
Top Qualities: Great Results, Expert, High Integrity

In a follow-up email, Tony went on to say:

"Thinking about what I said I realize I should have commented on what a solid foundation that initial java training has given me, it certainly has been a significant boost to my career."

Thanks Tony!

This time, the 'CoalCraft' System, circa 1999~2001.

I built this while working for the now-disbanded DSTC, alongside my colleage and good friend Dennis Remmer. We both continued our involvement after leaving DSTC (I set up Transentia and Dennis established eTwo; "expertise for an advanced internet")

CoalCraft is a modern distributed system that brings together providers of information of various resources (such as Coal Producers, Power Stations, Transport Schedulers, etc.) through a "brokering" service, to an arbitrary number of users. Information providers are able to maintain their own repository in its native format and provide a window into it by registering with a provider "map." Information users are able to access real-time information for analysis without requiring significant local system resources for data storage.

The following should give you an idea regarding how it was constructed and promoted:

CoalCraft has been constructed to be platform independent and is implemented in pure Java:
* CoalCraft's Object-Oriented construction makes it easily extensible and flexible.
* CoalCraft uses Java's Remote Method Invocation (RMI) system as the underlying distribution mechanism allowing Object-Oriented communication. This provides ease of development and makes it easy to 'plug' Providers into the system.
* The CoalCraft client application is constructed using Java's second-generation 'Swing' Graphical User Interface components and this allows for a sophisticated user interface.
* The CoalCraft client application exports data in XML, the upcoming standard format for data interchange. This keeps the system open and allows further processing of data obtained via the CoalCraft system to be carried out with ease.

Here's the obligatory piccy:

During the early 2000s, we schlepped the system around to various potential users (assisting the client) and even ran a small 'live' trial with some interested parties but in the end it didn't get anywhere (I think we needed a better spruiker and a bit more $$$ for P.R. than was available).

Still, it was "leading-edge" at the time and the client asked me to assist in preparing a patent application, which was a new thing for me so I guess it deserves a small footnote in history…such as the one just here.

A list of all content pages in Sun's The Java Tutorial.

http://java.sun.com/ … /reallybigindex.html.

Even though I have been programmng in Java for lo these many years (SDK 0.98 on a Mac Duo 280c; circa 1995/6), I've never seen this before.