The BileBlog

I’m a fan of java.net. I’m a occasional and regular participant in a number of projects on it. I like the principles behind the service, and always recommend it to people looking for java project hosting.

However, it certainly has its warts. For anyone who has engaged in a back and forth with the poor community managers at Sun, every problem boils to one simple issue. Collabnet are a bunch of spastic moneygrubbing incompetent shirtlifting perlwanks.

Matt Raible for example bemoaned the lack of customization for the navigation, because only the criminally insane and genitally challenged would use the despicable bugzilla or revolting forums that collabnet offers. It’s perfectly sensible to want to customise said links to your own saner issue tracker (yes, even JIRA is a step forward here) or your forums (Jive, another astoundingly greedy bunch of bendoverandpayushaha types, who at least have something worth charging for.)

Another example. Let’s say you’d like a cvs tarball of your repository, so you can run fisheye on it, for the purposes of gawping at pretty graphs that mean nothing. A perfectly legitimate way of pretending to do something useful. Even the turdhaus of sourceforge offers such a service. Collabnet though will only hand over such a thing if you send them enough money to feed an American family of couchpotatos.

It’s surprising, really, that a company such as Sun, with its proud tradition of eating their own dogfood and sticking to java technology, chooses to go with such an ungodly stench of perl and open source jizz splattered all over such a public site. I can understand it if collab at least offered these services in return for publicity, but Sun pays horrific amounts of money to that bunch of spineless slashdot Iwanttofondleericraymond’smoustachewhilebeingfistedbypaulgraham types.

Needless to say, the thing performs terribly too, and in the fine tradition of ever Sun site that has ever existed, thoroughly ignores any amount of rampant clicking on ‘remember me’ type buttons. At least in that case, java.net is merely following a tradition at Sun that has been around for the last 9 years or so, rather than heaping new insults on the hapless users who just want to be able to log in periodically out of sheer boredom.

Of course, there’s no subversion support (too expensive, I bet), and the integration between the various components is as much as one can expect from a bunch of hobbyist tools cobbled together by oily teenagers.

Of course, the real punishment is dished out to those naive or arrogant enough to think that they might want their project documentation available on java.net itself. The time and effort that collabnet has spent to ensure that anyone with such filthy habits is ‘cured’ of them is impressive to say the least. It’s easier to tattoo your bottom with small print documentation and visit ever user interested than actually make anything available on there. At least in the tattoo you do get to make some of the decisions involved in layout and design.

Still, as evil and worthy of mutilation, death, and torture as collabnet might be, Sun does its fair share towards ensuring the user experience is anything but enjoyable. Authorizing projects takes, if you’re lucky, a week or six. Finding a sympathetic community manager to a particular problem is a crapshoot; if you luck out and find one who cares, chances are they’re about to leave Sun, be promoted/demoted to something less/more important, or go on a two month vacation with no email access without notifying anyone.

Remind me to never buy any product that’s a repackaging of existing open sores crap. The people who are always, always trying to pull a fast one and con someone out of some money, and are only ever motivated by being paid to piss around incompetently. I wish collabnet nothing but ill, and hope that everyone involved with them gets what they truly deserve one day. Brian Behlendaft, may you disappear up your own lardass one day.

I spent the weekend working on the TestNG IDEA plugin, and I was struck, time and time again, by how abysmal the so called IDEA ‘open’ API is.

Setting aside what a cruel joke it is referring to the api as anything vaguely ‘open’, it’s astounding, nay, horrifying how difficult it is to work with.

For one thing, there is next to no documentation about it. The fact that the way to write a plugin is to find another one and copy it should be setting off many alarm bells at IDEA HQ. I’m fairly aware of the goings on in idealand, and have yet to hear of a definitive plugin quickstart that’s well known and publicised.

On the plus side, you do get the source (or at least stubs) for big chunks of the openapi package. Needless to say, this is far from comprehensive, and in most cases the sources do not contain any sort of documentation, or are simply existent. There are a ton of classes that are in the openapi package that stubbornly refuse to go anywhere near the source jar.

Figuring out how to accomplish any given thing is an worthy contender for the ‘experience most likely to cause fastest genitalia shrinkage from full arousal’ award. For all the grand ideas that one might have, invariably the implementation is either well hidden away as an IDEA internal, exposed very poorly, or plain old badly written with no thought for reuse.

Classes are often very oddly placed. For example, we have BrowseModuleValueActionListener. This is actually a fairly useful class that allows you to tie a dialog box to the browse button of a textfield. What package would such a class be in? I doubt even the most creative amongst you would choose com.intellij.execution.junit2.configuration.

Even funnier of course are the typos. The refactoring support means you can consistently have a badly named class without ever noticing. Witness the nonsensical SeachScope class.

Much of my time was spent wiping off the hot tears of rage and dismay time and time again as I struggled to find out how to get something to happen, or more often, flailed about pathetically trying to figure out why something isn’t happening. Ultimately the only surefire method seemed to be helpless flailing and random clicking until eventually Something Happens. The plugin devkit makes this far less painful than it used to be, but it still doesn’t strike me as the most efficient mode of development; click&pray. I saw enough red circles of doom to last me a few months. I cursed Russians, I wished ill on the lovely city of Prague. Most of all I wished that those guys hadn’t taken vows of stfu about the damn api.

If JetBrains is serious about attacking the eclipse plugin market, then the openapi needs a lot more love. It is currently a neglected abused child only fit for pointing and laughing at, and the occasional bout of sexually deviant behaviour instead of the tender lovemaking that one can imagine exists in this cruel cruel world of ours. It’s a terrible shame given the power than is available and the huge scope for IDE enhancements that don’t belong in the core.

I’ve gotten too many emails requesting this particularly hilarious entity be ‘reviewed’, peer pressure being what it is, I capitulated and decided to have a look at mergere.

Mergere, for those of you with better things to do with your lives than follow every ridiculous idea in javaland, is a new ‘venture’ where some VC type managed to con a bunch of maven developers into thinking they have the makings of a real product you could build a company around.

First, let’s even ignore how ridiculous the idea is, and evaluate this assertion based on the words of their own website. I’m sure that perusing it will make everything clear, and we’ll all think ‘aha! if only I thought of that!’

It’ll come as no surprise to anyone that whoever came up with the site content had nothing further from their mind. The site seems to have been written by a marketoid who once knew someone who had read a java tutorial. It promises us that the maven based solution stack will ‘eliminate most, if not all, human interaction at runtime.’ Now I’m no buildfile expert, but in all these years, I have perhaps come across one or two projects that require any human interaction between issuing the equivalent of ‘make’ or ‘ant’ to kick off the build process and have it spit out binaries of dubious quality.

The solution stack also, apparently, ensures that ‘builds run from start to finish without issues.’ As anyone who might have used maven knows all too painfully, this is about as truthful as claiming that swt is a great cross platform toolkit, or that bill berk is a great public speaker.

What’s even funnier is that these monkeys, like everyone else, are building a continuous integration tool. Perhaps there is a glimmer of hope here, as for some reason this field seems to attract the top tier of java retards; those who seem to have the shortest attention span and least ability. We have anthill (functional, but about as attractive as rod johnson’s moobs), beetlejuice (by Andy wannabethoughtwanker ‘if I rip off the jira look then I will be rich’ Pols, cute yet about as functional as a thoughtworker without a pair), damagecontrol (the only build tool I know of that can without fail bring down any machine it’s installed on, rock on ruby!), and of course, the perpetually dysfunctional cruise control.

On the plus side, the one place you can be sure of to run this pathetic pile of doggypoo is codehaus. Yep, the only people in the world stupid enough to run the most unstable and incompetently written build tool in existence (damagecontrol) will no doubt apply their highly selective acceptance criteria (it compiled, once) to this project, and deploy it.

I do feel some pity for the maven guys. They’re clearly a bunch of happyclappy clueless well intentioned oss hippie types who are being ruthlessly exploited into thinking they’ve achieved oss nirvana. You poor bastards are going to have a rude rude awakening in a year or so once your seed money runs out, and you’re back to whoring yourself on shitty little IT gigs and, no doubt, churning out more shitfests in the hope of ‘making it big.’

Of course, the business plan for anyone who has followed gluecode is blindingly obvious. Throw up enough smoke and mirrors to sell the whole thing off to someone even stupider. While that approach will obviously work with logicblaze (which compete with a number of commercial business friendly tools), I predict an astounding failure for mergere. Not only has nobody ever paid for this sort of thing, but there’s a delicious irony in offering commercial support services for maven too; any build tool that requires you to pay an expert to maintain is clearly badly written and should not be used in the first place. How many companies have made their name and money selling makefiles, or build.xml files?

A lot of the big boys provide shiny pretty tools to ‘help’ you do stuff. It’s rare to find a really expensive server/application that doesn’t give you ‘value-added’ gui’s that help you interact with the complex systems they have built. These gui’s of course ensure that there is a low barrier to entry, that you’re ‘empowering’ your business users, and allowing them to increase their ‘time to market’ and push up their ‘ROI’.

While these tools do provide a good selling point, more often than not they’re in direct conflict with the people expected to work with said system. I’m heartily sick of vendors pimping their latest gizmos with shiny demos and hordes of marketers squealing that ‘people buy with their eyes’. I’d like to stab those people in their eyes with a butter knife. Let’s see them buy ‘with their eyes’ then.

To me, any suite that mandates or ’strongly recommends’ a gui management tool is basically saying ‘look, our underlying configuration format sucks, it’s convoluted, awkward, and endlessly tedious to work with, if we let you use it, you will either laugh at us or want to murder us in our sleep’. Witness the call for struts consoles, that happened since people started to realize how retarded and obfuscated struts configuration is. Of course, products like JBoss have configuration that is so hopelessly fucked that even a config tool won’t save you there.

While working with a mouse and ineffectually faffing about with options and pictures to accomplish stuff is enjoyable and satisfying to effeminate developers, the manly developers are more likely to feel rage at being made to jump through hoops and treated like an invalid 3 year old. It’s insulting and offensive to be treated this way. Give me a simple set of configuration files that are human readable and editable so that I can stick to using a keyboard like god intended.

GUI Culprits include the horrific weblogic workshop, websphere’s I’m-going-to-chew-off-my-arm-now-to-distract-myself-from-the-pain deployment tools, and my current cross to bear, tibco’s just-stab-me-in-the-face-now-to-end-it-all schema designer tool. Why oh why can’t these tools be advertised as something that is available but very definitely not required? Why can’t there be clear documentation on how to accomplish stuff without these tools, or documents for the underlying mechanisms these tools use so that you can do things your own way if you wanted to? Admittedly, it’s a bit unfair bundling weblogic with the others as the workshop is a latecomer so the config files have had to be coherent and sensible previously, and life can move along reasonabely smoothly without the workshop.

So have your filthy gui tools for your sales force to pimp to gimboid managers, but if you want good will from the trenches, make sure you don’t insult the intelligence of the developers and document all your formats. That way they can use whatever they feel enhances their productivity the most, and thank your app for helping them do it. If you’re REALLY kind and loving, then spend some effort simplifying your configuration, so that the call for a big fancy gui simplify it never arises.