My current project has certainly proven to be a refreshing change. After countless projects in large organizations, culminating in experiencing enough red tape to seemingly circumvent the globe, working on project as part of a small team more capable of responding to feedback has been a breath of fresh air.

Swingin’.
*Thankfully* I’m finally working on an application whose primary interface is a rich Swing UI. Virtually all my web development experiences have attempted to mimic rich desktop interfaces in some way. The resounding belief among technicians on these projects was that the wrong UI was being employed for the task. It seemed ease of deployment and the trend towards web applications were the foundation for UI selection. Before the AJAXers of the world arc up, yes AJAX widens the scope of applications suitable for a web interface, but desktop applications will always have their place - I can’t see an advanced word processor being replaced by a web application anytime soon.

So it’s been a flashback to the heady days of Applet development via AWT, my original experiences in the Java landscape. During the experience I’ve been surveying the OS community for frameworks assisting with Swing development. Surprisingly, Swing hasn’t been impacted by a ‘Struts’ framework like web development has. It seems most OS efforts continue to be in handy UI components such as file choosers and tree views, the same sorts of components that were being sprouted for Delphi and C++ Builder many years ago.

It seems a handful of potentially useful Swing specific tools have sprouted though - Foxtrot and Spin address management of Swings event dispatching thread. Some tools compose UI’s via XML, lessening the burden of composing complex component layouts. Others offer trivial infrastructure to somewhat simplify event management. Still, none seem to offer significant value above sound OO concepts. It seems you could roll your own infrastructure to do similar jobs in a relatively short amount of time.

PicoContained.
One of the first principles I’ve instilled on my new assignment is the elimination of Lookups and Singletons in favour of Dependency Injection. To that end we initially employed PicoContainer, using NanoContainer to support an XML configuration. After the initial grief of discovering NanoContainer’s poorly documented schema, I soon encountered some nasty bugs in PicoContainer’s heirarchcal container features. So I chose to replace PicoContainer with a purpose built container, taking all of 1 day to complete. I appreciate that PicoContainer is a project that now accommodates many languages and means of configuration, but from my experience an ultimately limited set of it’s functionality is put to use. So much so that rolling your own implementation to accommodate your circumstances turns out to be a reasonable proposition.

Java Deprecated Objects (JDO).
Unfortunately, the team has inherited JDO as our persistence technology. Surely the best reason an organization could have to use JDO above other ORM tools (i.e. Hibernate) is that they made a significant investment in an initial implementation. In any other circumstance, given the controversy of overlapping JDO and EJB specifications that lead to delays in the acceptance of the JDO 2.0 specification, wiser heads would seek alternative persistence solutions. To a large degree I already consider the JDO specification deprecated, waiting to be superseded. Sure, if you’re already using it, maybe it’s easier to move with it. But if you have no legacy considerations, why choose a technology that’s already dated, especially given better solutions to the problem of persistence are available?

I have a couple of gripes about JDO’s API:

• The API is bloated. The key class (PersistenceManager) contains 55 methods. Granted, a fair amount of that is convenient function overloading, but the result is a cumbersome API.
• I really dislike the concept of ‘live’ objects. I much prefer explicitly saving an object. The JDO team seem to have acknowledged that some prefer this approach by introducing detach and attach features.

Granted these gripes are relatively minor and plenty of people have used JDO successfully for their persistence needs.

Big Mac.
So I’ve now had 2 weeks using a dual CPU Mac with Tiger for 9 to 5 use (ahhhh….it’s a tough life). The experience was pretty cool, but I encountered my fair share of problems. Above the usual keyboard layout complaints, here’s a few others:

• IntelliJ’s key bindings needed some serious surgery. Above the changes made by the IntelliJ team to accommodate not being able to use the first few function keys in Mac apps, there were a couple of key bindings out-of-the-box that plain old didn’t work. Some examples: F9 to resume a debugging session, and what the heck happened to Alt+D to ‘Do Refactor’? In all I’ve probably changed about 50ish key bindings to date.
• Why not support the Windows convention of using Ctrl for editor actions, like Ctrl+C for copy? I appreciate that traditional Mac users are acustomed to using the Mac key so it needs to be supported, but for cross-platform apps (i.e. IntelliJ) to not support both a generic and Mac specific keymap is madness. Admittedly, I’m being fanatical on this point as I’m a Java developer who changes operating system frequently.
• Running a headless JVM ends up presenting *** Attention *** Please attach debugger. Press any key to continue….. Nasty.

Still, 2 weeks and I’m just about hooked. The ‘eye candy’ factor is significant as well, it seems when I look at a Windows installation now, my first impression is that it’s, well….pixcelated.

I’ve recently come to the end of my first venture into contracting, a one year foray with the supply chain wing of a large international organization. It’s certainly been an adventure - one worthy of a blog entry.

It’s been a rocky road, venturing through various terrains, requiring copious levels of endurance.

Thoughts on Contracting.
Before the project I certainly had a naive perspective on contracting. The only experience I had with contractors was with recognized experts, brought into projects for a limited period of time to perform a very specialized task. For instance an Oracle DBA co-ordinating a massive data-load process, or a Rules Expert spreading knowledge to the team. However, the use of contractors in this environment was very different, contractors were brought in to provide general skills - developers, testers, analysts - essentially being plugged together in the hope of achieving the desired result with very little direction and direct management.

Indeed, I was initially shocked by the approach - or lack of it. Contractors bring with them their own ideals and practices - getting a co-ordinated approach out of individual approaches is a relatively difficult breakthrough at the best of times. Of course, being part of a full-time team in a software development or consulting environment is very different, usually these employees are educated towards a consistent approach - one methodology shared by all. Contractors moreso need to be educated on each project to get familiar with the approach and the organization. Unfortunately the project was somewhat challenged to the point where no approach had been decided, so trying to get contractors working in a unified manner was an impossible task.

Even worse was the attitude displayed by some of the contractors that obviously recognized the system (or lack of it) and took full advantage of it. Quality controls were at some stages in the project virtually non-existent, so it ultimately fell back to the values and morales of contractors to appropriately implement functionality. All this made me realize that some people in the industry are not concerned about acting in the best interest of their employers or colleagues. Some are interested in maximizing their importance and value ($) to the business. Others are looking to silently idle, blend-in with the furniture and try to pass as competent enough to earn an inflated salary. So it’s certainly been an experience that has jaded my perception of contractors. I’d encourage any organization to strongly screen contractors (after all they should justify there inflated salary) and to avoid employing more than a small percentage of contractors on a single project. They undoubtebly offer the best value when employed for a limited period of time as experts that educate or trouble-shoot and depart.

Dutch Employment Law.
It has alot to do with the contracting market here in The Netherlands. It is extremely difficult to fire any employee - a court must permit sacking any employee regardless of the circumstances. Consequently it is somewhat understandable that employers may prefer contractors over risking employing a full-timer that interviews well but can’t deliver. Still, employers shouldn’t use this as an excuse - evolve your interview process - invest in forming a process that exposes just how good candidates are at what their core responsibilities. If your process involves just answering questions - I’m sorry but answering questions is not the core responsibility of anyone in an IT organization. Get hands on, down and dirty.

Testing Beliefs.
Going solo (so to speak) was an acid test to my personal values and beliefs, in this case an opportunity for me to encourage the business to evolve processes - to interact with management in a very unconventional way from what I’m accustomed. This particularly involved moving from understanding and accepting XP from a developers perspective to trying to rationalize and justify it’s practices with management - an experience that served to fortify my belief in the process.

At various points in the project the technical challenge wasn’t there - now this has happened a few times in my career - so I started to find ways to fulfill my technical interests outside of the office. Long commuting times via public transport offered an ideal time to do that, experimenting with different technologies. All this proved to me I am a geek not interested in stagnating, and I see contracting as a particularly hazardous way of falling into this trap - it’s easy to focus on the bottom line, $’s in pocket - but you’ve gotta be forward thinking. In todays marketplace, especially the Java marketplace, the flavor of today may not taste so good in future months. If you do not learn and evolve you will limit your employment opportunities to large corporations unable to move with the times.

Censored Opinions.
Admittedly, there’s been a few times over the last year where I’ve had blog entries screened and retrospectively I’ve decided not to publish them. Occasionally I’ve found situations and attitudes simply unacceptable and had to vent. While I advocate brutal honestly there is a limit to my brutality. I’m confident I’ve been able to express most of their important points to my colleagues and the community at large in a more constructive fashion than in the original blogs. Perhaps one-day I’ll be as shameless as the BileBlog but I’m grateful that day hasn’t come.

Moving On.
My next role promises to be challenging with plenty of development work, involving the use of Swing and JDO and a couple of other technologies I’m not intimately familiar with at this point. To top it off I’ll be working on a Mac - I’m very interested to see how my perspective on Mac’s as a 9 to 5 tool evolves. As a past-time/hobby, sure it’s rather cool on a Mac - but can it survive the 9 to 5 acid test?

For about the past year I’ve been occasionally looking at Fit. When I first heard about it I perceived it as the shiny new tool that would radically modify the way user acceptance scripts are traditionally created, specifically for web applications. I was under the impression both analysts and testers could use Fit to the run scripts against a web application. No more laborious amounts of tests scripts coded by developers – that was the analysts and testers job now.

Well, after trying to read the site numerous times, downloading it and playing with it, I plain gave up. The doco was terrible and the code certainly wasn’t self-documenting. I encountered some sites that mentioned jWebFit, an extension to Fit for jWebUnit, but I couldn’t uncover any useful information on that either. I walked away from it all under the impression Fit was immature and generally unusable. But I was still intrigued as I heard rumors of it being put to good use.

Thankfully Fit is now Fitter! The Fit site has now been updated and it contains plenty of doco and examples to guide you through the process of understanding Fit. There’s even a new book on the way explaining Fit and the business processes supporting its full use. The doco on the site is fairly concise - within around 15 minutes I had Fit up and running with some experiments of my own. Here’s my take on Fit:

• Depending on how you use it, developers may still be required to produce a fair amount of code – Fit fixtures that exercise code being tested.
• Fit is a testing framework that it is completely agnostic of the thing being tested. You could perform any test (unit, integration or acceptance) using Fit.

Looking at it simply, Fit is a way of expressing what code to run, what values to use and what results to expect, all via a HTML table. View it as a layer above code that returns results – importantly that code should not be asserting the expected result. That’s Fits job, Fit asserts the result and displays the assertion result in a table. What that code does it entirely up-to the developer, hence there can still be plenty of grunt-work to do. While it’s a cool tool that can be used to express tests simply, a fair amount of development effort could be expended ensuring Fit fixtures do the job required of your test scripts. But this could be said of any code that has the “difficult to test” odor.

Enter jWebFit. After digging around I’ve discovered it’s a Fit fixture or two built on jWebUnit facilitating jWebUnit tests being expressed via Fit tables/scripts. If Web Apps is your thing, jWebFit promises to cut-down the development effort required to get acceptance tests running through Fit. So my original belief in Fit is realized - less developer grunt-work for web application testing. But beware. It’s documentation is non-existent and it’s not official, it can only be downloaded from jWebUnit’s CVS repository. Robert Watkins has played the tune I’m leading to before - use it at your own risk. But hey, as always if it’s free you can’t complain.

From what I’ve discovered, teams pursuing a collaborative team structure with analysts, developers, and testers working closer together (in true XP fashion) should consider using Fit and/or jWebFit but be wary that they are immature. It’s definitely a “try before you buy-in” deal, they will not work in every team, especially teams lacking the skill to support and expand fixtures.

P.S. Interestingly, the Fit site recommends the use of Word for analysts/testers to produce tables. For a cheap kick I tried Open Office 2 but unfortunately it produces HTML tables with <th> tags not liked by Fit.