I realize that I haven't written in some time. There are a couple of reasons for this. First we had the recession hit. I was one of many given my walking papers when the company which employed me down-sized, first by 25% then another 20% in a second round. Now, I don't believe it prudent to panic and shed employees as soon as a potential problem arises. I've always believed that the re-manning process can be far more expensive than the cost of retention. You lose so much knowledge and experience in down-sizing that it can take literally years to recover. Better to have offered temporary wage reductions, IMHO. But the "powers that be" must know what they're doing, right? So why do I rarely see the executive numbers decline during these exercises?

I was (mostly) unemployed for fourteen months. As most of you know, seeking a new position is challenging at the best of times, made even more difficult when you're unemployed. A distressing trend I've seen recently (when I was on the hiring side of the table) is resume padding. Hiring managers are requiring experience with every technology under the sun, almost as though they're merely checking boxes on a form. So it makes sense to include a wide range of acronyms on ones resume, as long as you have experience with the technology! It was amazing to me to have people come in claiming all manner of knowledge when it turns out that they'd merely read about it. Sorry, but that doesn't cut it!

So during the height (or depth, as you will) of the recession you had unrealistic requirements on the hiring side and resume padding on the applicant side. Since posted positions would typically receive hundreds of applications, the first step would be to winnow-out those without the requisite skills. So if you reduce the potential pool down to ten and find that none actually have the skills claimed, you have one of two choices: pick the best of the worst or start over. Since interviewing takes time (and costs money) many companies chose the first option. Most disappointing, not to mention that employers lost out on seeing some very qualified candidates. Too bad that those also had the integrity to only include on their resumes the technologies with which they had practical experience.

The other reason for my lapse is that I've been very busy over the past year. I secured a contract position with a small company which has kept me hopping ever since. I had to create a complete development environment from scratch. It includes Eclipse (with plug-ins like subclipse,) subversion, ant, Xdoclet, CruiseControl for continuous integration and Selenium. I introduced Glassfish to the mix so that we could rapidly and individually deploy and test ears. I developed loosely- coupled applications using JMS and webservices. I also introduced iBATIS for the persistence layer. Finally, I introduced mySQL as a capable, open-source RDBMS which permits each developer to have their own local copy of the project database.

Quite frankly, the opportunity to create a technoloy mix from scratch was wonderful. I spend a significant amount of time and effort evaluating software. I find out what works and what doesn't through real-world testing, writing applications to fully test capabilities. But there are only so many hours in a day and so I can't evaluate every package out there. I have to keep my ear to the ground and only investigate tools which have potential. And that's why I've arrived at a suite of tools which work well together and facilitate the development of robust, n-tier JEE applications. So let me tell you about a couple of things I've been working on recently.

JavaServer Faces

From the number of articles I've written, it's obvious that I'm a big fan of Struts and Tiles. It's a powerful MVC framework which is ideal for a wide range of applications. But JSF provides so much more! Where you still have to do a lot of "grunt work" with Struts, JSF eliminates much of the heavy lifting. It incorporates support for so many of the capabilities you'd have to manually develop for Struts. From form field value conversion and injection to validation and I18N, JSF is a worthy successor to Struts. That's not to say that Struts is obselete; as others have written, if you have in-house expertise with Struts then you don't have to throw out the baby with the bath water. You would be advised, however, to utilize JSF in any new projects.

In JSF you use backing beans instead of ActionForms. The mutator methods are invoked by the framework so you don't have to programatically retrieve the form values. You can concentrate on your action events instead. If you have the luxury of form specifications with field names and types you can even do as I did and write a utility which consumes the specifications and generates the majority of the backing bean code, including all the accessors and muators required. Flesh out the result and you can develop backing beans in short order. Look for commonalities and you might be able to reuse the same backing bean in a number of pages; just use different action methods.

Refactoring is something all good Java developers should be doing at all times. I found that there were a subset of functions which most backing bean could benefit from, e.g. retrieving messages from bundles. Rather than coding this in the individual backing beans, I created an abstract backing bean which provided the common functionality. All the other backing beans inherit from this class and so we eliminate code duplication. We can reduce development time and can ensure correctness. As with Struts, however, there are a number of details which are not immediately apparent. I'm currently writing an article which will discuss some tips and tricks for using JSF effectively.

Virtualization

This is another hot topic of late. As processors become ever more powerful, it becomes possible to consolidate multiple servers into a single physical box. Businesses can significantly reduce the number of servers in their "farms" by utilizing virtualization and running servers as "virtual machines". Contemporary functionality allows for the near-instantaneous creation of new VMs from saved images. With the right technology you can even migrate running VMs among physical servers in a "cloud". Need to increase the number of web servers for a new release? Either create new VMs on existing servers or add some new iron to the cloud and carve out new VMs there.

There are two companies which I consider to be the leaders in this field: VMWare and Citrix. While I've since been informed that there is a free version of VMWare, when I started my evaluations the only freeware I found was Citix's XenServer. I bought myself a new AMD hex-core processor and new motherboard which supported that and DDR3 memory. I populated it with 8GB of RAM and threw in a couple of Hitachi 1TB SATAII drives. This was to be my test-bed for installing and configuring XenServer. I eventually created a number of different VMs ranging from Windows Server 2008 to RHEL4 and Fedora 14. It was easy to allocate memory and carve out drives from the storage repository.

So it works and works well. The only thing is that I found that there isn't a great deal of useful technical information available on the 'net. While XenServer is stand-alone, Xen is also available for a variety of Linux versions. Most of the people posting to the 'net are what I like to think of as "bleeding-edge" developers. Brilliant as they are, they seem to be mostly utilizing the Linux variant. As such, most articles pertain to Xen 3.x rather than XenServer 5.5 or 5.6. When I encountered what I though to be a fairly standard configuration, I was disappointed to find not a single article which addressed the desired configuration.

Fortunately, I have the background to be able to address these issues. With my familiarity with Linux (XenServer is fundamentally Linux) along with knowledge of and experience with the gamut of networking protocols, I was able to arrive at the steps necessary to make the configuration work. I even wrote an in-depth article on the steps required which you will be able to find in my technology folder. Citrix provides "commercial support" for XenServer ($) and I have little doubt that their experts would have been able to steer me in the right direction. But this is supposed to be open-source and it turned out to be a valuable learning experience anyway.

While I don't consider myself to be a XenServer "expert", I've done enough work with the product to imagine that there wouldn't be any situations which could not be successfully addressed, given time. I don't currently have the resources to implement the cloud since many of my servers are dedicated to certain roles, e.g. database servers, FTP servers, HTTP servers, etc. I have neither the time nor the inclination to perform the migration which would be required. That said, having the hex-core processor available is certainly handy for creating new VMs for specific purposes such as evaluating software. When the evaluation is complete I can archive the VM and delete it, freeing up processor cores, memory and storage repository space.

January 23rd, 2011

Copyright 2011 by Phil Selby