The BileBlog

Ahh, the wonders of hindsight! Remember yesteryear, when things were fresh and new, and the sweet sweet stench of innovation hung heavy in the air? Such promise, such hope! So many little API’s poking their shy little heads out of various birthing orifices. So many developers running around like cute little headless chickens hoping for a pat or nod of approval from an ignorant, shiteating-grin-wearing crowd.

Well, let’s catch up with some of those happy events and persons, and see what they’re up to now…

The first stop on this sordid little tour of the past sees us visiting the hapless Jon Tirsen. Once a promising young developer of dubious Swedish/Norwegian origins, he quickly found a home that could put up with his severe Attention Deficit Disorder (ADD) at ThoughtWorks. Remember when he cooed and oohed and aahed and excreted happy juices rubywards? Remember when he managed to get onto the frontpage of TSS with his ruby continuous integration tool, DamageControl? Well, the poor kid’s ADD was so severe that even his employer thought it’s best if he’s just put away from harm’s way, and promptly shipped him to the penal colony down under, while defanging him by putting him to work on such menial tasks as build tools.

As for DamageControl, the only user is codehaus. In fact, it’s such a pathetic failure of a tool than even the incredibly undiscerning eye of the codehaus folks is becoming more and more annoyed at this tool that manages to fall over more often than crazybob in Vegas.

No pointing and laughing at Tirsen is complete without some measure of pointing and laughing at his cohort/sidekick/puppetmaster Aslak Hellesoy.

Poor Aslak’s only legitimate claim to fame is STILL only xdoclet. After stalling horribly on xdoclet 2, he went on to join ThoughtWorks and underachieve in a surprising number of projects. First we had picocontainer (remember THAT?!), then DamageControl, and finally a series of hilarious TDD tools in a sad and desperate last bid attempt for some kind of recognition. It’s so sad seeing great men fall so low, but a key part of playing this game is knowing when to quit. If you’re now writing silly TDD toys that delete code (and don’t actually work) then you’re well well past that point of quitting with dignity.

Of course, this being Java, we should visit some tools as well as persons of dubious character. The first stop is in fact somewhat of a happy note!

It turns out that after a year of whimpery sad death throes, Jakarta Avalon has finally given up the ghost. It’s so nice to see projects dying, a sign that out there in the great developer wilderness, a few lone voices of discontent and misery can in fact push through and get something (un)done.

Next up we have Maven. Remember when people were excited about it and thought it was some kind of competition to ant? Remember when people used to actually defend it? Well, the current state of play is that even jakarta hardcores are complaining and bitching about it. Maven 1 devs now flail about hopelessly on their silly plugins, while some make half-assed attempts in maven 2’s general direction. I’m sure The ADD crowd with piddly toy projects will soon move to this new version, and no doubt then join the huge mass of mavenmockers out there.

Finally, groovy! Remember when people thought it was cool? Remember when some smart people said they’d turn it into a proper spec? Well, those days are long gone. One of the few smart people involved in that ungodly tripe, Sam Pullara, has moved onto bigger and better things. James Strachan of course is still cursed with the attention span of a gnat, and is now busy churning out Active projects through some new cockamamy moneymaking scheme. The JSR has not moved one little bit beyond forming an expert group. What an expert group too! Note the lack of a single language expert. I can’t think of a single JSR blessed with such a high hobbyist to expert ratio; A dubious honour at best.

So, what other spectacular failures have there been? Any news of other misfit hasbeens that should be made public and some more humiliation poured on their already quite miserable existence?

What is it with open sores projects and usability? I am baffled by all the energy and effort expended by any open sores project with a UI to avoid usability and principles of good design at all costs.

Maybe it’s a subconscious effort to emulate linux. Just as children will adopt the bad habits of their parents, java open source fuckwits will emulate the linux approach to UI; a disgusting soup of every possible ingredient ever conceived by man or nature coupled with a sickening obsession with every ugly default possible.

Today’s vomit lands on a tool that seems to be gaining some popularity; FindBugs.

In addition to the open source curse, FindBugs is unfortunate enough to have been conceived as an academic project. Those facts combined have meant the kiss of death for this poor little app.

Where does one start? Well, lets first create a project. Here’s the first mystery. You have 3 areas, one of which contains ‘archives or directories’, the second of which contains source directories, and the third is for classpath. Now, I’ve only been doing java for about 8 years, so I might not be familiar with all the lingo, but how on earth is a ‘archive or directory’ different from ‘classpath’? Of course, there are no hints or tooltips as to what should go in these areas.

If you haven’t yet deleted this miserable little app and fired off an angry email to its hapless developers by now, you’ll notice the second bit of mindless cruelty they’ve chosen to inflict on the poor sap attempting to use it. While the file chooser allows for multiple files to be selected, the app itself will merrily ignore these and simply pick the last one you chose. I suppose that’s one way to discourage people from having lots of dependencies.

If by some freak accident of nature you’ve managed to last this long, it’s ready to finally ‘find bugs’. Here we have more unwelcome anal intrusions in the form of a modal progress dialog. The progress dialog will happily write things to the UI console, except that because it’s modal, you have no way of actually looking at all the things it’s whining about. Of course, the warnings are deliciously verbose too, with every line beginning with a full timestamp and the fully qualified class name of the internal handler that reported the issue. I am utterly baffled by this classname fetish that opensores projects have. What exactly do you people get from showing your classnames to your end users? Is it some kind of freakish penis waggling maneuver? A bizarre mating ritual? Emotional issues resulting from being beaten and molested as a child?

Of course, the modal progress dialog has a cancel button, and if you press it you get….another modal dialog, asking you to confirm. Now I’m no grizzled UI veteran, but in all my years of using computers, I have yet to find an OS with such a bizarre paradigm. Real innovation here guys, a modal dialog with one button, that confirms with another modal dialog when you press said button.

The default settings are also of highly dubious quality. Every time you return a Date field for example will cause findbugs to throw a hissy fit. Ignoring results from reading streams (something which is often perfectly legitimate) is also whineworthy.

Of course, should you wish to change these detectors, your eyes will be stabbed yet again with this unfathomable UI. You’re presented with a JTable where the detector fully qualified class names are listed, along with ’speed’ and ‘enabled’ columns. Of course, since it’s open source, nobody knows how to actually use a JTable, so the columns are all the exact same size. This results in every single class name being truncated, for your maximum viewing pleasure.

The problem is, the application’s functionality really isn’t that bad. The presentation and user interaction though is so astoundingly horrific that the only people who will ever take this seriously are the kind of tosspots who wouldn’t know elegance and clean design (whether it’s in UI or code) no matter how many times they’re clubbed on the head with it.

The one solace I have from all this is that it has nothing whatsoever to do with JSF, so hopefully Rick Hightower will stop working quite so hard at earning the coveted ‘most tedious windbag’ village idiot subcategory award.

I’m sure we’re all highly impressed that the fleury clan actually managed to get compliance for J2EE 1.4. When I heard the news, I naively and foolishly thought that their incompetent days are now over. This is the dawn of a new era in the dirty incestuous little family’s sordid history.

Of course, a 90mb (!!) download later, I’m very rudely corrected. Wary from bad past experience, I thought I’d first just unpack the server and run. No customisations, purely out of the box experience.

What do I find? Well, the console output (standard size console), is 73 pages long. Of those 73, 61 are stacktraces (it’s hard to tell, but it’s one exception that’s nested about 12 times). Nice to see they’re still letting the same old inbred halfwits code. Of the remaining 12 pages, I’m given some very crucial information about startup, stuff that will hugely aid debugging and my usage of said server, I’m sure.

I mean, who wouldn’t want to know a 800 character IOR corba unique identifier (or two)? Surely the fact that the patch URL is ‘null’ is of vital importance! Don’t even get me started on those bastards who think that ‘Initialized REST’ is a useless bit of info. Why, we should all refuse to use those cryptic servers who don’t tell us all these vital things we must know in order to use J2EE!

Anyway, in the time it took me to write this, server is now up. The shameless little runt even admits to taking 2m:31s:305ms just to start up, clean, without a single application deployment (by me anyway).

Let’s try shutdown….Not as bad now. A mere page and a half of output, and about 10 seconds. Why a server has to take 10 seconds to shut down when it doesn’t have anything deployed yet is a mystery best left unsolved.

So, armed with an ear, maybe it’s time to deploy something for shits and giggles and see what sort of evil that might bring forth. A deployer.sh and deployer.bat in the bin directory look most promising. Whoops, guess again. The scripts complain that there’s no deployer.jar in the current dir. One has to wonder at the marketing/packaging genius who thought to ship shell scripts for non-existent components.

The bin dir contains other misfits too. One doesn’t know whether to laugh or cry at the self-professed ‘primitive’ jboss_init_redhat.sh and jboss_init_suse.sh, with their cutesy hardcoded paths and lack of support for any kind of external config.

There’s also the delightful ‘twiddle.sh’, which apparently allows you to ‘twiddle’ remote jboss instances. This sounds somewhat reminiscent of diddling said remote servers, and I’m not sure about you fleurites, but I for one would rather plop my genitalia on the wrong end of a piledriver than even think of any sexual activities with anything jbossian. Merely viewing the help output of this diddler will, of course, result in a twiddle.log file deposited in the current directory, with nothing but debug messages.

Deployment is still the painful arduous hope-and-pray-you-get-a-helpful-hint process we’ve all come to know and love. The smallest hiccup will cause the server to flail about wildly, spewing error messages with a frequency that is only matched by the number of new pointless codehaus projects every week. The error message themselves are as delightfully whimsical as they’ve always been. Random ObjectNames, with tantalisingly empty ‘I depend on:’ proclamations. The ‘Depends on me’ of course still impressively manages to insist that ejb’s within a module depend on a seemingly random other ejb in a far flung module that has absolutely no dependencies to anything. Hot redeployment of apps that failed to start up doesn’t work worth crap, the stacktraces seem longer, and the whole thing just makes you run to your nearest j2ee vendor and beg them to let you fling cash at them just to stop the pain.

There are some silver linings though. For one thing, JBoss 4.0 should serve as a great motivator for the Geronimo folks. It sets such a low bar that their goal actually seems attainable (as long as they avoid going after commercial vendors, who will wipe the floor with them). It’s also an excellent advert for BEA, IBM, and pretty much all the other players in the field. People who start with JBoss will learn to appreciate professional products so much more (alright, well maybe not websphere, but anything else).

For anyone having high expectations of JBoss 4.0, time to put them away. It’s the same old shit, just 9 times the size, half the speed (well, twice the slowness, to be accurate), 3 times the incompetence, and an order of magnitude more hype. Calling this ‘professional’ open source can only be a very very sick joke, or the most filthy example of doublespeak yet this year.

Still, to their credit, the jboss fucktards have realised one vital fact: it’s pointless to spend money on development or developers if you’re stick with a truly rotten team at the core, and much more useful for the ‘business’ if it were all poured into marketing, where the art of conning people is far far easier to perfect than with boring old code.

With the usual amount of flatulent fanfare, James Strachan launches another toy project. This time, it’s in the guise of…something to do with soap.

Now, this happened to be somewhat interesting for me because I’m sick of being shackled to GLUE for my soapy needs, given that it’s nigh on impossible to download the latest version these days (thank you webmethods for proving that despite my last run-in with you with your ‘enterprise MOM’ activeworks 6 years ago, you’re still a bunch of chozgobblers). Now Graham Glass might be the prettiest girl in javaland, but he basically bent over the java community and stuck it to them where it hurt.

Of course, the more drooly amongst you will suggest axis. You lot aren’t even worth spitting on, so let’s move on briskly.

Enter activesoap, a potentially up to date, well maintained, active project that might well give us the soap we need for our..hmm. What could one use soap for? Well, let’s say soapy titwanks, for the sake of argument.

Alas, my hopes were very quickly dashed, when the activesoap website managed to have so many words, that were all simply GIBBERISH.

Now, I’m no soap guru. I know what a soap call is, I know the structure of a soap message, I know the envelope, the header, and all that nonsense. So I was rather amazed at how confounded I was by the so called ‘documentation’ for activesoap.

Where does one start? activesoap apparently lets you implement soap intermediaries. What the poo are those? activesoap also has some kind of dodgy relationship going on with xmlbeans. xmlbeans are from BEA, what do they have to do with soap? Nary a link or explanation in sight!

Of course, to keep in the grand tradition of all amateur java soap attempts, there was, until a day or two ago, absolutely no mention of how this beast might be used client-side. The current example involves some of the now obligatory arm waving and xmlbean self-flagellation.

Given how the documentation is mostly nonsensical for anyone other than our beloved James, one might think that the ‘how it works’ link might shed some light on this little misfit. Alas, another hope dashed. We’re insulted even further with even more nonsense.

Speaking of links, why oh why do the title links on the left hand nav underline when you hover over them, yet are doggedly unclickable? Have you people learnt nothing about web pages since 1996? Do consistent predicable UI’s offend you? Is surprising your hapless users what you get your jollies off to?

I had initially intended on actually trying this pile of dogshit and maybe even using it. The website however has cured me of all such urges for now. To add insult to injury, this festering pile of unsavoury droppings is built using our favourite whipping boy, maven. Oh how I miss the days when OSS projects had a simple ‘javadocs’ link right on the homepage.

James, you’re a smart chap (despite the very debilitating handicap of having the attention span of a guppy), but please, please, when you feel like writing docs, do not think of it as a braindump, and target the damn thing at other people, not yourself.