Springleton Adventures!

10 days into my new job and so far I haven't pissed of anybody (of note). Not bad for me, but give it time, give it time.

First day on the job I couldn't keep my yapper clamped, and I started spouting off on Spring and after a good natured debate on third party code with my boss (the Sushi King) I found myself saddled with a Spring evaluation project. DOH!!! When will I learn.

So after a few days struggling with JBoss and its MBean microkernel architecture I got onto the Spring thing. I had a fair amount of trouble with JBoss class loaders and how it affected Spring and especially Spring resource locations, but I ran across the JBoss Spring Deployer and it got rid of all my class loader troubles.

So my eval project consisted of taking one of my project's MBean services and Springifying it. My coworker referred to it as making 'Springletons' - I kinda like the play on words. Once I got past JBoss class loading it turned into a very straightforward Spring conversion. That is to say, I wrote no new code (well not till later, see below), eliminated 9 of 17 classes, and deleted rafts of transaction and other resource management glue code.

The cost was the introduction of a standard Spring XML configuration file, a 60 line file. I exchanged some 500 lines of Java code for that, so I would call it a good trade. In addition, about 1/2 of the XML file is common/shared code, so I only needed about 30 lines of XML configuration to specifically code this piece.

So I go to review the code with the Sushi King early next week. He is a hard core roll-your-own coder, and its hard to anticipate what he won't like about my results, but I am sure there will be something. But, as I cheerfully note, he will either like it and buy me lunch or I will be swimming with the fishes. Oh-oh, wait - he likes sushi. Maybe we should do this code review remotely?

Java IDEs and other religious wars

Well I have started a new contract, and as always the first few days of a new job is always Environment Hell. There are servers, vpns, dns names, drives, passwords, and endless other configuration details to get right, and the cursory overview at lightning speed my new boss gave me was par for the course, and hopelessly inadequate. Same old same old there.

And as always happens the first day of a new job, the little battle regarding what Java IDE we were to use played itself out with glum predictability. "What IDE do you prefer" said my boss, vainly attempting a casual air - but the nervous tic around his eye and the sudden lack of breathing around the room told me that there was only one right answer. And many, many wrong ones.

I took a deep breath, briefly considered just guessing which IDE he wanted me to answer with, but in a second of reckless abandon (which I deeply regret) I looked bravely in his eye and answered truthfully.

It was the wrong answer. Woefully, deeply wrong.

His face fell, and as he half-heartedly tried to look reasonable, condenscending, forgiving, indignant and hard-line all at once, I sat back in my chair and resigned myself to yet another lecture on why HIS IDE was the only one worthy of consideration, and all the reasons why it far surpassed my hopelessly worthless favorite.

Long experience taught me to sit quietly and nod often. We had entered into that most dangerous of holy wars, the question of "The Best Java IDE". There is no winner of this ideological conflict, there is only opinions and personal preferences. Years ago I came to the conclusion that there is no Java IDE that conclusively is the best for all people in all situations. Further, many scars and many fruitless wars have taught me that there is no way to win this battle.

The question I often ponder is - why must there be a 'designated IDE' for a project? Almost always these days there is nothing specific about a project that would make it fly or crash depending on the IDE, and frankly, in this day and age of feature races and competition, there is hardly a feature in one IDE that every other major one could not claim to also have.

My very good friend volunteers for the JBuilder IDE, providing early beta testing and many other tasks that foster the improvement of the JBuilder community. We remain good friends despite the fact that I would rather use Notepad and the command line than JBuilder, and she would rather cut her fingers off and weave baskets with her nose than use my favorite IDE. Which one of us right? Well neither of course. IDE's are clearly a matter of personal preference. Why waste time and effort on forcing a particular choice on anybody?

Whats that? Am I using the IDE demanded by my new boss? Well... I installed it so I must be. Right? :-)

Insecure Geeks... is it still really all about the size of your hard drive?

I am still working my way through a few tests on the JavaBlackBelt site, an 'open certification' kind of site that (some tell me) has been around for a while now. I have done a couple of the simple tests to get my 'yellow belt', the lowest level certification they will give me without having to invest a great deal of time in designing tests, questions, comments and so on. I am not yet certain its worth the effort, and it appears the emphasis at JavaBlackBelt is much more on test design than test taking. The equivalent would be telling someone to use Hibernate but they could not do a pre-fetch query unless they submitted 3 code enhancements to the codebase first. A little onerous, I am thinking.

Anyway, I took the 'Introductory OO test' and failed it. Shame on me, right? Well, first I only failed two questions, and I was only allowed to fail one. Missed it by.... THAT much! This blog is really about the style of questions that the test was presenting.

In an earlier blog on certification I mentioned that I would look forward to some kind of certification tests. Well, so far the ones at BlackBelt are definitely not the kind I am looking for. They are testing in a style I remember well from my school days (yes, I still remember my school days), and I felt the same sense of frustration answering these BlackBelt questions as I felt back then. In short, the questions were not testing my depth of knowledge, but instead focused on clever tricks to try and fool me into picking the wrong answers.

That in itself, while annoying and close to pointless, is not the main problem. I found the whole approach of reading a piece of code and describing why it would or would not compile absolutely a waste of time. Today's Java IDE's compile as you type, and even auto-complete statements with suggestions on how to remove the compile issue. Why would I bother trying to figure out if something can compile by 3 minutes of scrutiny to uncover the arcane subterfuge a tester has wrapped around a trivial compile bug when any IDE that is better than Notepad will highlight the error, autosuggest a fix and implement the fix with a single keystroke? What am I being tested on then?

It smacks of the geeky bravado I used to see in Computer Science school that used to make me sigh and go find some of my old Geology buddies to drink with. You know the guys I am talking about - the ones that organized Friday night programming contests. I remember hearing of one where the goal was to see who could write a C program that functioned as a Notepad in as few characters as possible - variables, syntax tokens, white space all counted. Doesn't anybody want to go to the sports bar and try and pick up the waitress anymore?

So I will keep trying a few more tests, and I hope I will eventually get to one that actually tries to test me on an aspect of programming design, implementation or execution that can't be auto-completed by an IDE faster than I can type. Otherwise its back to the bar. I am POSITIVE that waitress smiled at me, even before she saw the tip I left her....

So I am Java Architect. Believe me?

I remember doing some recruting for a body shop company I was working for a few years back. It was during the dot boom bubble, and we were hiring anybody who could demonstrate regular breathing (and a few that were dubious). I had offered to help HR assess the technical ability of the candidates as they went through the grist mill. We were gonna hire them, cuz we hired EVERYBODY, but it was helpful to know what they could actually do.

Anyway, one particular fella really stood out. He was in his early twenties, and had applied for the position of "Senior Architect" for a contract we were bidding on. Now, I fancied myself one of those too, but I wasn't no 20 something keener, I was the ripe old age of... well... I was older than that. I brought him in for an interview.

It turns out he had had precisely TWO paying jobs in his whole life (three if you counted summer work mowing lawns), and he had never actually programmed professionally in Java. I was somewhat incredulous, but he firmly stood by his assertion that he was perfectly qualified to be a Java Architect. I remember standing and getting ready to tell him he was ballsy but was still gonna get thrown out of my office, when it hit me.

Just exactly what is a Java Architect?

The IT industry has agonized for years about certifications. We are not like, for example, engineers who have the very well respected APEGGA regulating them in Alberta. APEGGA require all jobs that need an engineer to be certified by APEGGA as being qualified. Companies that do not employ APEGGA certifed engineers can be held liable for improperly built bridges, buildings and so on. Any engineer who wants to be employeed as one must pass the APEGGA certifcation.

One can see the benefits of certification immediately, but why hasn't the IT industry adopted certifcation? How many times have employers wished to hire programmers that were REALLY qualified? And frankly, how many times have I wished I could prove my qualifcations in some emperical fashion?

Well don't hold your breath. Real, reliable and dependable certification in the IT industry isn't coming any time soon. It changes too fast, the main players in certification (Microsoft, Sun, IBM etc) usually play it for profit motives alone, and IT is simply too diverse to come up with reliable measures of training and competence. By the time you have a set of tests constructed and agreed on technolgy has blown right past ya.

All that being said, the reason for this blog was that I stumbled across the JavaBlackBelt site today. Its a cool idea! The basic open source concept taken to the certification arena. Lots of tests on all kinds of Java technologies, including Ant, Struts, Web Services, EJBs, Hibernate and so on. I am going to take a few tests over the next while.

Until then, with respect to my brash young collegue... why am I a Java Architect?

Cuz I say I am!

Spring and Axis - How to beat the XML-Object impedance mismatch

Spring has a whole suite of handy helper objects that help with SOAP, JAX-RPC and Web Services, and in my opinion they are much more powerful than the terse but information-rich user manual gives them credit for.

In particular, during a recent project I stumbled across the part of the Spring manual that described how to set up a JAX-RPC proxy using CGIlib and a thin spring wrapper (the JaxRpcPortProxyFactoryBean class). I thought "hey I will give it a go" and in typical Spring fashion in perhaps 5 minutes I had a small test working that hit a very simple web service.

Adventures in Shirking My Work

With that encouraging result I turned my attention to the web service I was building at the time. The XML schema for this web service ran to several hundred lines, with a couple of dozen types including polymorphism and enumerations. The Spring JAX-RPC proxy had a simple method for specifying the XML-java mappings and I mentally cringed but started grunting my way through the glue code I needed to generate. I didn't get far - I just have never been good at menial tasks (some people would say that about my ability to do just about any task, but lets not go there, shall we?)

In an effort to avoid real work I started poking around in Spring source code, and it wasn't too long before I discovered that Spring uses the Axis JAX-RPC client to provide client-side web service connectivity. Hmmm.... I thought. I was already using Axis to serve my web service,
and I had managed to completely describe the Object-XML mappings in the Axis deployment description (WSDD file). It made me start to wonder - could I use the same type mappings for the Spring JAX-RPC client?

Working Hard to avoid Working Hard

There was a post-processing method on the JaxRpcPortProxyFactoryBean where the type mapping information could be loaded, and after a little experimentation I finally came up with:

protected void postProcessJaxRpcService(javax.xml.rpc.Service service){

DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();

factory.setValidating(false);

factory.setNamespaceAware(true);

try

{

DocumentBuilder builder = factory.newDocumentBuilder();

Document document = builder.parse(

  new ClassPathResource(classpathAccessibleWSDDFile).getInputStream());

WSDDService wsddService =

  new WSDDDocument(document).getDeployment().

     getWSDDService(new QName(wsddServiceName));

  if ( wsddService == null )

    throw new RuntimeException("No WSDD Service named \""+wsddServiceName+"\" was available");

  TypeMapping serviceTypeMappings = wsddService.getTypeMapping(SOAP_ENCODING_STYLE);

  TypeMappingRegistry registry = service.getTypeMappingRegistry();

  registry.register(SOAP_ENCODING_STYLE, serviceTypeMappings);

}

catch (Exception e)

{

throw new RuntimeException("failed", e);

}

}

In the above code, I simply used a couple of Axis calls to read the WSDD file, extract the TypeRegistry information and then hand it off to the Axis JAX-RPC client. It worked first time I managed to properly load the TypeRegistry, flawlessly. Again, typical Spring.

Waiting for the Flash to Hit Me

I was feeling pretty cheeky for the rest of the day, having managed to add a sophisticated JAG-RPC client to my arsenal with only a couple of lines of code. It wasn't till a couple of weeks later when I was about to add a second client (to a different web service) that I really realized how quickly I could put together just about any client from a valid WSDL file and a WSDD deployment descriptor.

I have 4 or 5 working clients now, including both RPC style and Document style web services. And all as a result of feeling too lazy one day to do my real job.

Is there a lesson there? Not one I would tell my kids.

Software Factories - doesn't anyone besides me think this is crazy??

The boys at Microsoft are at it again. The architects of Visual Studio Enterprise tools, Jack Greenfield and Kieth Short, are talking about Software Factories.

The concept behind software factories is full of the hypnotic song of the Sirens. We IT geeks automate everyone else's processes... why shouldn't we automate our own? Yes, that's right! We can reduce software production to recognizing patterns of requirements and then write factories that generate code to satisfy the requirements pattern. Simple. Heck, even a monkey could do that. Why hire IT professionals when you can get a high school student who will work cheap!!!! Watch your IT costs spiral down, cuz high school students will work for beer money.

We Have Seen This Wreck Before

Wake up Dorothy. This ain't Kansas! And all you mythology buffs will recall what actually happens to sailors who were seduced by the Sirens' song (with respect to Odysseus, the only recorded survivor). The whole concept behind software factories is misguided, and a yet another example of how a good idea (patterns) taken to an extreme can be extremely non sequitur.

Those of us old enough to recall programming in the early to mid 90's recall well the last time Microsoft tried to 'dumb down' programming. In the heady early days of Visual Basic programming managers rushed to apply the simple form application building framework to every application from garage based mail order systems to multi-national corporation asset management megasystems. Tech schools filled to the bursting with kids getting a 4 month diploma on how to program in VB, and CEOs smiled looking at whole office floors full of eager kids, all working for 25 bucks an hour, no benefits.

And at first the screens rolled off the factory floors with smooth regularity. I recall one MS pundit proudly showing me how he could create an application and deploy it in 12 mouse clicks. But the bloom fell off the lily around the same time the second round of requirements rolled in. The simple bump-n-squirt applications that read from one or two tables and threw them up on a form were done, and now the wild eyed guys from accounting were asking for things like reconciliations from accounting tables... yes all 586 of them - including the daily transaction log, complete with its 1 million row (per day) detail records.

It was a great time to be a consultant. I spent about 3 good years moving through failed VB project after failed VB project, replacing cookie cutter VB forms having miles of domain logic embedded in button click handlers with conventional C++ (and eventually Java) programs. Yes they were more work to do. But they WORKED.

The Seven Percent Solution?

The funny thing about all this isn't that MS is going to try this again, 10 years later. Its more that people still fall for the Sirens' song. Software Engineering Process Techology estimates that roughly 25% of the cost of software across its lifecyle is spent in development activities, and only 7% in actual coding and unit testing.

What does that mean? It means that you discard your qualified IT staff for cheap and poorly trained replacements, you lose your ability to write mission critical software that is 'outside the box', you generate reams of hard to maintain code that cannot easily be changed, and you bind yourself irrevocably to MS products (since you no longer have the expertise to change to anything else).

All this to save up to 50% on your development costs. Sounds good eh? Worth it, right? Only till you find out that you reduced the total cost of your software by a whopping 3.5%.

Crazy.

Spring - when standards suit everyone but the people who use them

I have been working with Spring for well over a year now and I continue to be amazed.

Yes, like everyone else I am delighted at how well Rod and the folks have really captured a bunch of server side best practices and repackaged them into tight, easy to use and often simply beautiful services. And like everyone else, I am firmly strapped into the Inversion of Control a.k.a Dependency Injection bandwagon.

But. That is not what I am amazed at. Where the H-E-Double Hockey Sticks is J2EE? Anyone? Anyone?

While organizations like Spring are doing leprechaun dances and popping out great libraries like pennies from heaven, here is a huge gathering of the best and brightest server side minds in the Orion Arm and what are they doing with J2EE? Writing ever larger standards, stuck in furious and vicious infighting, bringing all useful progress to a halt. For example here is how the whole CMP war went:

• EJB 1 Team: we no need no steenkin CMP!
• EJB1.1 Team: oops... ok you can have your steenkin CMP if you just gotta
• EJB 2 Team: ok we know that CMP 1.1 sucked... THIS time we got it
• EJB 3 Team (act 1): ok we know that CMP 2 sucked... THIS time we got it
• EJB 3 Team (act 2): ok CMP 3 will be JDO-like... THIS time we got it
• EJB 3 Team (act 3): ok CMP 3 will be O/R-like... THIS time we got it

And container managed persistence is only one aspect of a whole suite of server side features that are either bulky and hard to get at in J2EE, or simply non existent. But man can you set up a hell of a deployment descriptor! (Aside: ever met a J2EE EJB deployer that WASN'T the guy that programmed it?)

So what happened? Some will tell you that vendors with an eye on excluding competition hijacked the J2ee standard and forced it into such complexity that only the biggest vendors could hope to comply. Others felt that as a world-wide standard solution styles that varied from North America to Europe made a single universal standard hopeless.

What ever the problem, one thing is clear. J2EE is rapidly being left behind, as new techniques and new technologies surge past them, making the problems J2EE used to solve trivial. While the Goliaths of the industry lumber and lurch their way through hundreds of pages of standards documents, bright, nimble and creative Davids skip around the server and spew startlingly simple code that is truely useful. And most of it is FREE.

Amazing. Like I told ya.

Welcome to my world

Hello world,

This is my first attempt at blogging! I am sure I am much more excited about it than all of you, but as you muddle through all of my musings you will, sooner or later, realize that you know far more about what I am talking about than I do.

Hmm. Probably sooner.

Anyway, I am a Java Architect with over 20 years experience in programming in general, over 10 years experience in OO. My first Java project used the 1.0.2 JDK, if you can believe it. This blog is going to be fairly wide ranging, from issues in develpment, issues in architecture all the way through to how I see IT and the world it lives in.

Get ready world..... here I am.

Jay