The next talk I attended was a bit of a black sheep. It’s a J2ME talk for one, and for another, it’s not really about technology, code, or some guy flapping about helplessly at his IDE while we all patiently wait for something vaguely noteworthy to happen.

Despite the incoherent and faintly pretentious title, the talk, I grudgingly admit, is pretty good. Grudgingly, because I don’t like Eugene as a person (at least, on irc), he’s a little too creepy/nice/full of shit for my taste. As a speaker though, he’s interesting, engaging, and able to communicate in a non ‘gosh I’m a tech dude wtf am I doing up on a stage’ kinda style.

Still, personal feelings aside, he’s a rather good speaker, certainly compared to the competition so far. The talk is in fact also awfully interesting, since it deals with higher level issues surrounding J2ME.

Eugene covers all the pitfalls in the mobile Java ecosystem. These are often not technical, but political, or the result of various parties all eager to protect their turfs. I’m not an ME guy, so the talk was a bit of an eye opener onto that world. The ME world seems awfully full of NDAs, secretive partner deals, zealous API protectionist mentalities, and often trying to screw everyone both up and downstream of your slot in the stack in the aim of forcing the users to become coupled to your slice of the pie (whether it be OS, api, vendor, app vendor, retailer, etc).

There’s also an interesting discussion of a commercial application’s lifecycle, and how vendors and partners interact (with detrimental results) with various milestones of the process.

An interesting description of people’s interaction with mobile devices is to recognise and work with the fact that users exhibit ’snacking behaviour’, in terms of their expectations, demands, and usage. Applications that follow these principles are far more likely to succeed and result in happy user noises.

I had previously ranted about google code from the perspective of a user. Turns out, users have it easy compared to project owners/administrators. Google code is, without a shadow of a doubt, the worst online application I have ever seen from Google. It isn’t just bad by Google standards, it’s bad by any standard. In any sane company, the people responsible for delivering such an abysmal product would be taken out back and shot in the face, just to save humanity from the risk of them ever doing anything again.

Where does one start? Lets look at the cool new downloads feature they added once they realised how useless their shitty little python jizz is. So hosted projects can now offer downloads to users, all is good and well. These downloads however come with some interesting restrictions.

This dovetails nicely into the clusterfuck that is download tagging. The administrative menu is, to put it as kindly as possible, whimsical. Menu items and options are scattered about like goat pebbleturds on a mountain. The only option under ‘Advanced’ is ‘Delete this project’. How is that advanced functionality? If you go to administer (as an aside, what English language guru decided to choose a verb for a menu item when all the others are nouns?) then downloads, you’re presented with what amounts to gibberish.

I kid you not, you are shown a list of tags, and at the bottom, it says ‘Each download may have at most one label with each of these prefixes:’. What prefixes? What downloads? What the fuck are these labels for and what do I do with them? Maybe I’m particularly retarded, but I honestly have tried very hard to decipher this page, and still have no idea what the purpose of it is, or what I can achieve by using it.

Google code’s project hosting can be a poster child for anyone who ever wanted to justify assigning a project manager to a project. It’s a clear example of the inmates running the asylum, where the developers spent all their time on useless shit that happened to sexually gratify their sick sick fetishes, which happened to basically shit all over real users from a great great height.

The validation is childish and immature, and is easy to con into allowing you to enter invalid project values. Google is lucky that it’s such a useless and trivial app that it hasn’t been noticed by more malicious people, but I can honestly say that I dont know of any company where any application, internal or external, can be so shit and remain so shit for so long without anyone trying to fix it. Delivering a rushed project with many bugs and missing features is one thing, remaining that state a year on is a level of incompetence and idiocy that’s usually unacceptable in the real world. Those poor fuckers wouldn’t last a day if they had a real job in a real company.

No doubt someone will counter with the fact that thousands of people use Spring and all is well. Yes, thousands of people also used EJB2, oddly enough the very same places that switched to Spring. What are the chances of all these venues suddenly becoming full of wise intelligent developers who from now on will only make sensible sane well considered decisions?

That problem makes it somewhat understandable that the Spring guys, in order to defend their fucked up theassness, deride annotations and proclaim that declarative xml goop is Rod’s Holy Word. Go forth and write xml, Rod proclaims, and the unwashed masses go forth and positively ooze angular brackets. Stupid fucks. Still, all is not lost, in cases where it’s possible to shoehorn annotations into Spring’s archaic innards, they’ll enthusiastically proclaim it Useful and Recommended, such as the @Transactional annotation.

The other common argument is ‘you don’t spend too much time in Spring’s xml compared to time spent in your code’. Sure, I also didn’t spend much time writing ejb2 descriptors either (xdoclet did it), yet everyone bitches about those. Why can’t we apply the same standards to Spring?

Fundamentally, Spring has a tough time accepting that the world has moved on, and that its approaches are starting to look a wee bit outdated. Even EE 5 in many cases looks more modern and usable than some of its approaches. Thanks to its widespread use, they can, much like the JBoss people, maintain an insular world view where they’re surrounded by sycophants who do nothing but bend over with a shiteating grin plastered over their sallow filthy faces.

Your configuration bean bullshit still doesn’t cut it, dependencies are best expressed where they belong, in the damn source code itself.

The fact that XML is, basically, a steaming pile of goatshit is not news. Many many people know this now, yet you have an awful number of people eager to grab a hold of some xml and perform deviant sexual activities in it, around it, and in between its elements.

The problem is that there are some good ideas out there that happen to use xml. Even though xml has nothing to do with the quality of the idea, xml somehow gets credit.

This has become quite apparent lately when participating in some Guice vs Spring debates. The fact of the matter is, Spring’s XML sucks unbelievable amounts of ass. Don’t buy the bullshit hype of Spring 2.0 improving its XML so it’s now all great. All it’s done is made it plausible that one might not jab oneself in the eye with a big black ribbed for his pleasure dildo when confronted with it. I cannot believe that a sane person would think that the Spring 1.x syntax is fit to deposit a big dogturd on, let alone use in any application you’d care to be associated with.

You either have to autowire (which is convenient but too magical as your project grows, not to mention fragile), or explicitly wire stuff in xml, miles away from the source code. Lets not even get started on how abysmal performance is once you’re using a real project with more than 3 beans, or heaven forbid, wiring up actions at runtime. You could play many a game of soggy biscuit while Spring figures out who needs what, when, and why.

Of course, the situation is conveniently disguised by the fact that tools such as IDEA natively grok Spring’s hellish configuration.

Atlassian has captured the hearts and eyes of developers everywhere. The one corner of the market they have not been able to penetrate so far is the minds of these developers.

The new strategy will pose a challenge for the young company, shifting the emphasis from pretty pictures to usefulness is a move fraught with danger, and some analysis are not optimistic. Joel of FogzBugz fame proclaimed ‘Atlassian is doomed to failure, how can any company that doesn’t spend time writing an ASP to PHP compiler to achieve platform independence ever get anywhere? FogzBugz has always focussed on functionality, our 3 customers are more than happy’.

Jiramike, one of the founders of Atlassian, discussed the change in strategy. ‘We’re sick and tired of being the pretty dumb blonde in Java,’ he sighed dramatically.

‘It’s time we move past the cutesy rounded corner and cartoonish icons, we’re a serious company now and I think the joke’s up, customers are demanding a new kind of application. Whereas before all we had to do is slap on a pastel hue and a Verdana font, this market now requires that we develop functionality and serve a business purposes.’

Not all is well with this new strategy however. Some developers at Atlassian have rebelled against this move, and have resigned in protest. A member of this rogue group recently proclaimed ‘I just want to fuck around with ruby now and then and read ajaxian and put in all that stuff, why tf are we switching from our core strengths?’

Atlassian customers however are cautiously optimistic. The open source side is obviously elated, and the codehaus core team was rumoured to be dancing naked in the streets, rubbing genitalia with strangers, in an odd departure from the standard practice of doing ‘comfort grouprubs’ as a consolation prize for either another useless project joins, or a useful project graduating to relevance by moving elsewhere.

How hard is it really to install lightweight pure Java DB? We have mckoi, we have hsqldb (in its various incarnations), and we even have a halfassed one from Apache (Derby). All of these (except derby, funnily enough) are very easy to download and install, and are perfectly adequate for testing and playing with and the odd bout of sexual experimentation for the curious.

In ALL cases, this should NOT be in the JDK. Why should one DB be blessed above all others? Did we learn nothing from the crimson fiasco? Mark also naively claims ‘Vendors of little DBs are already threatened by Derby whether or not a copy of it is co-bundled with the JDK. I don?t see how doing that fundamentally changes the picture for them.’ A clearly ludicrous claim; just look at how successful Tomcat is.

The branding of the whole thing is equally ludicrous. JavaDB? What next, renaming Glassfish to The Java Application Server and making obscene lawyery gestures at anyone wanting to refer to their appserver by that name?

I’m one of the few people I know who will publicly admit that he’s a Sun fan. I think they’re an excellent steward of Java, and have done a remarkable job in every way (except marketing of course, I can’t think of a company that’s more incompetent in terms of how they present themselves to the public or of the ludicrous stuff they seem to push).

How out of touch do you have to be to be ‘honestly surprised at the reaction to all this’ according to Mark? Have you people lost all respect for what we love and care about our platform, and felt that for the sake of consistency, you should whore the rest of the JDK and sell all your products NetBeans style? Come on, surely there are enough technically minded people still at Sun, who have some say and can prevent this travesty from taking place?

In a rather perplexing move, it’s announced that the Java 6 JDK will include Derby, the turdy little unwanted IBM poop plopped onto Apache (about par for the course, since large swathes of Apache seem to exit solely as an IBM marketing tool.)

What’s perplexing about this decision is how incredibly arbitrary it seems. I have yet to see a single rational justification of its inclusion, even from within Sun or from the community at large.

It’s one thing to suffer from the tyranny of the masses. We have plenty of cases of that in Javaland, do we really need to now add arbitrary bizarre decisions that not only pop up out of nowhere, but also have nothing at all do with the community?

Honestly, not even the JDK6 Expert Group decided on this addition. It’s literally as if someone at Sun woke up one day and thought ‘you know, I miss the old days when we could add random shit to the jdk without all this community and expert group nonsense, I’m going to sexually arouse myself now by doing just that’, in one of the most harmful public displays of nostalgia ever seen in a technical forum.

I honestly cannot conceive of a single reason for this. It doesn’t even make life easier for anyone. You can’t rely on it being there since it’s not in the JRE, you can’t actually do anything with it since you have to ram various awkwardly shaped objects into unexpected orifices to create a db and manage it using derby’s amateurish and unpleasant tools. It’ll work out of the box much the same way as an Oracle 8 install CD can be considered functional.

Now you’ll have to bend over and invite over a large group of chocolate log miners and perform things your mother would be very upset about just to upgrade your db. Of course, you WILL want to upgrade it. It has hundreds of open issues, and is clearly labeled alpha.

Even if those issues are miraculously addresses in the next few months, we’d still end up with more IBM shit in the JDK. Honestly, when will people finally realise that IBM has never produced anything of worth, beyond genius marketers? How many times must I mention java.util.Calendar and java.text before people start listening?

It’s a little disturbing seeing the agile crowd at work. In a relatively short period of time, an energetic group with potentially something new to offer has quickly sunk into a oft-derided group of greedy consultant used car salesman types.

Pair programming, TDD, XP, little bits of paper, incremental releases, smug turdy devs, all experimented with and eventually discarded like a used tampon. Pair programming is inefficient and wasteful when compared to individuals who don’t slack off, the little cards more often than not end up with the wrong things scribbled on them.

Is it possible to fix all that? Sure, but agile isn’t the way to do it, because the practices it espouses do not lend themselves to easy adoption. It’s a high barrier that continues to punish, and never rewards its participants beyond that air of smugness and that perplexing ‘I just shoved a big dildo up all my orifices and its strangely alluring’ look.

The reason for this disillusionment isn’t that hard to find. As many have noted, it’s rooted in the feeling of incredible disappointment when you realise that no time has been saved, your love life has not improved, and your customers are no happier when you follow this crap.

Genuine techies don’t react well to religion, usually. The agile crowd has committed the cardinal sin of stepping over the pragmatism line into the realm of faith. We’re surrounded now by the debris and detritus of less than successful agile projects. Instead of questioning the agile practices that might have contributed to the failure, agilists will instead scream out that the flaw is in the implementation, not the principles. Whatever happened to the scientific method? Why are the principles now held to be sacrosanct?

It’s that sort of attitude that makes normal people think that agilists are, on the whole, a bunch of greedy fuckheaded navelgazers more intent on group teenmasturbation than concern for fellow man. The irony of their very name is becoming apparent to all; there’s nothing agile about their thought processes or acceptance of external input.

Just say no to agile. Say yes to sane practices that work for your particular need.

For some inexplicable reason, I’m one of the external reviewers for this year’s JavaOne EE and Web tracks. The one thing that’s utterly perplexing about it is the dire quality of some submissions.

Tempting as it might be, I’m not going to name names. I’m not going to point out how many vendors pitches there are, or how much they suck. Instead I’m going to try and understand what on earth some submitters were thinking.

Do you really think that JavaOne attendees love to hear about how you solved problem X using your own technology, that nobody can actually use without dropping trow, bending over, and paying for the privilege of being molestered?

The open source crap is just as bad.  JavaOne isn’t some whore you can throw your dirty papers at for a quick show and tell. Nor is it a venue for you to idly gaze into your navel and pick out lint in public, musing on its quantity, quality, and what possible use it might have.

I don’t understand how hard it can be to put yourself in the shoes of the average attendee. The goal of this conference (and ANY good conference) is to help said user, NOT to help the vendor or presenter. The fact that you get to strut your stuff and waggle your genitalia at a few hundred people at a time is its own reward.

So given that the average reader here is a discerning (if somewhat mentally unfit) Java type person, with one finger on the pulse of the community, and another firmly in an orifice, I’d like to you know what you think. What would make a good talk?

Surprise surprise, google release yet another half baked idea, and techies everywhere bend over and demand that the biggest black object in sight be crammed up their orifices so they can ooh and ahh and generally behave like a bunch of desperate teenagers aching for a fisting.

This time it’s Google code, and I am astounded (though I should be used to this by now) that anyone in their right mind thinks that this is an improvement over anything equivalent that already exists.

What’s odd about this particular offering is that while Google stuff is generally useless and good for eye candy, it’s usually reasonably well executed. In this case it seems like they just rounded up a bunch of apache hippie types and let them futz about with this idea just to stop them from damaging anything important.

Trying out this pile of worthless gunk reveals even more flaws. Really basic stuff that shows that Google apparently has a severe QA engineer shortage, or thinks that for trivial toys like this, it doesn’t matter if it’s halfassed. For example, if a project has ‘Apache License 2.0′ specified, the link doesn’t go to the 2.0 license, but to the generic Apache licenses page.

This sloppiness is prevalent throughout the app. For example, all ‘home page’ type links go to code.google.com, but nothing pointing to the hosting home, code.google.com/hosting. You’d have to go all the way to the top, then drill down to get to the main entry point.

The form validation is also bizarrely crap. On the project creation page, the create project button is disabled unless you have a description and summary > 3 characters. All good and well, but if your project name is just one char, that’s fine, the button is enabled.

The issue tracker is somewhat interesting, I do like the freeform label support, but of course, for the sake of consistency with the rest of the app, it’s useless for any real world projects. There’s no way to add custom tags, so you can’t for example add tags for your specific versions. This of course means that for every single issues posted, the first comment you’ll get back from the developer is ‘err, so what version is this again?’

There’s also the issue of stupid defaulting in the issue tracker. I can click new issue, then click submit. There’s no detection for the default content being specified, so it’s very easy to spam a project with a ton of boilerplate issues.

Shame on you Google, but the real blame here is for all the Google fans who allow them to get away with such tawdry offerings.

 There’s something particularly endearing about standing in the lepers line at a particular session at JavaOne this year. The lepers line, in case you weren’t aware, is for the poor sods who showed up to a session thinking they had registered, when they in fact hadn’t. You stick you card on the cute little reader, and it flashes an angry accusatory red, insisting you have not registered. The nearest usher will then calmly but surely place you in the lepers line, where you get to shuffle about uncomfortabely and look like the dumb bastard who couldn’t figure out how to register, or was too lazy to do so.

Having been one of those rejects twice, I’d argue that the members of the line form a kind of silent (and often not so silent) bond. Sure, we don’t know how to navigate one of the most poorly written webapps for selecting and scheduling sessions, but by god, we’ll give it our best shot.

Pitifully, I managed to attend just one session yesterday (not including my own), so there’s not much to report on that front. However, this JavaOne is, perplexingly….vibrant? There’s a certain energy that seems to have been lacking recently. I’ve noticed more than one person comment on the quality of the talks and topics, and how much fewer of them seem to be pointless fluffy Sun penis wagglage marketing poop.

The linux distribution license thing announced yesterday is worthy of note; it’s always thrilling to see another nail hammered into Apache Harmony’s coffin. Why all the members of that project don’t just crawl into Stallman’s beard and die is a mystery as yet unsolved.

It’ll be at least interesting to see how the content evolves, given that some of the editors (well, one of) can barely string together a coherent sentence, and has the mental acumen of a small pebble

It’s a J2ME talk for one, and for another, it’s not really about technology, code, or some guy flapping about helplessly at his IDE while we all patiently wait for something vaguely noteworthy to happen.

Still, personal feelings aside, he’s a rather good speaker, certainly compared to the competition so far. The talk is in fact also awfully interesting, since it deals with higher level issues surrounding J2ME.

Eugene covers all the pitfalls in the mobile Java ecosystem. These are often not technical, but political, or the result of various parties all eager to protect their turfs. I’m not an ME guy, so the talk was a bit of an eye opener onto that world. The ME world seems awfully full of NDAs, secretive partner deals, zealous API protectionist mentalities, and often trying to screw everyone both up and downstream of your slot in the stack in the aim of forcing the users to become coupled to your slice of the pie (whether it be OS, api, vendor, app vendor, retailer, etc).

There’s also an interesting discussion of a commercial application’s lifecycle, and how vendors and partners interact (with detrimental results) with various milestones of the process.

An interesting description of people’s interaction with mobile devices is to recognise and work with the fact that users exhibit ’snacking behaviour’, in terms of their expectations, demands, and usage. Applications that follow these principles are far more likely to succeed and result in happy user noises.

All in all, a pretty decent talk, where I learnt that dealing with ME is an awful pain in areas that like being painfree.

The one thing you can say about the intarweb that we’ve all come to know and love is that it’s full of some very very bizarre people. Said people will more often than not manifest their deepest dirtiest wishes in the form of midget sex, goatse collages, lemonparty, horses doing unspeakable things to a variety of human orifices, and the shiny white boots of tubgirl. The content in itself isn’t necessarily that disturbing; more disturbing is those who find such material personal fetishfodder.

Of all these fetishes though, none are as freaky as our dear old Ceki’s logging obsession. We’re coming up to the 10th year anniversary of his initial logging spasm, and the little rumpranger shows no sign of tedium nor flagging of unmentionables.

Most people think that the freak just sharted out log4j and saw his creation, and pronounced that it was good. Most people are also exceptionally stupid, ignorant and naive, which perhaps explains the earlier perception.

So what is slf4j? Well, it’s a….facade for other logging systems! It’s a replacement for clogging! Now here’s the clever bit, instead of all that magical dynamic discovery mumbo jumbo, the binding from slf4j to a concrete implemention is done at….compile time! Want to switch logging implementations? Simple, recompile your app!

Of course, having written a logging api, the next natural step is to write a logging api api. slf4j of course does nothing by itself. Instead it has two implementations, nlog4j and SimpleLogger. By now, even the most hardened logging chozgobblers are likely suffering from serious shrinkage.

It’s amazing that after all these years, there are still some people who think that time and effort should be invested in more implementations of the same tired old ideas. Is this guy at all in touch with what goes on in the real world? Exactly how many cloggings does the world need anyway? Why oh why oh why do we need wrappers around logging libraries? Has anyone, ever, in the entire history of java, and in all the millions of projects out there, ever, ever switched a logging implementation, and thought ‘using clogging was such a good idea after all!’