Monday January 30, 2006To Sun: java.net is not a spooge receptacle What has happened to java.net? From being a mildly interesting place full of boring blogs all related to java in some way or another, it seems to have become the darling facial recipient of certain teams within Sun. Now maybe I'm old fashioned, I like giving a facial as much as the next guy, but really, watching one in progress just doesn't do it for me. There's something reasonably unpleasant about seeing a nice girl bukakked, I must confess.
Java.net is that nice girl. She just wants to be friendly, maybe help out with the odd reacharound, the odd swallow, and whatnot. She's not quite trollopy enough to merit a full on facial extravaganza.
For the last few months, not a day goes by without both the Netbeans and Glassfish teams burbling on about how great their shit is. It's become such a yawnfest that I think by now, most readers have developed some kind of Pavlovian reaction and immediately twitch towards the delete key, some other bookmark, or simply pass out when seeing one of these too-common entries.
The problem is further compounded by the fact that this junk is sharted out all over javablogs too. It's impossible to escape. I realise you Sun people think that embracing blogging is now a by-word for marketoids, but you're going too far. Instead of actually trying any of your products now, I'm eager to avoid them and encourage everyone I know to do likewise, as punishment for your dirty marketing habits.
Sure, it'd be interesting to play with ejb3 persistence. You know what's not interesting though? Being told to do so only in glassfish. Why not do what any sane ejb3 vendor might do, and market the fact that the persistence layer is now pluggable, and show people how to take the relevant bits from glassfish and use them in a real-world container? Instead, we're regaled with such great titbits as 'we're now migrating to maven2 on an ad-hoc basis', and 'blahblah glassfish documentation' and 'glassfish makes my penis look pretty'. Don't even get me started on the various JSF fapperies going on. Does anyone other than the odd book author and training consultant still use that stuff?
As for you Netbeans people, you have nothing useful to offer. Please just go play with your genitalia in private, like god intended. No, I don't want to use a command-line ant-based build structure that is Netbeans friendly. Nor do I give a flying fuck about Netbeans responsiveness. I particularly do not need 10 different Netbeans fuckfaces pointing out to me that 5.0 RC2 is now out.
It's a shame, really. java.net could be a very useful resource, and often has surprisingly good content. The way forward though lies in putting up more barriers between Sun and the content. How valuable really is it for a Sun employee (JSF spec lead) to blog about how great Netbeans' support is?
Javablogs.com for example has always had an unofficial 'no commercial blogs' policy. It's a shame that this has gone a bit lax lately and they aren't culling out the endless glassfish/netbeans posts, or the tedious 'JDeveloper version 10.3.2.1.2.3beta2EAPpeniswagglefrotfrot is out tomorrow' type posts by certain Oracle types.
If you want your content read, Netbeans/glassfish type people, try to give yourself some credibility by trying to be a little bit more subtle, and not turning every post into a 'isn't my product great' spoogefest. You're all smart guys, and I'm sure you have opinions and interests beyond the tedium of your daily jobs to share with the rest of us.
On a side note, I'm talking at TSSJS in Vegas in March, so make sure you don't show up unless you're prepared to do much pointing and laughing. (2006-01-30 15:08:58.0)
Tuesday January 03, 2006Servlet 2.5, the bad, the ugly, and the pointless It's a testament to the power and arrogance of the servlet expert group that they can produce such an abysmally inadequate iteration with such impunity. While the rest of the EE platform (note, it's EE, or Java EE, not JEE as random turdburglaring wankstain X would have you believe) is busy ensuring that it lives up to the 'ease of use' mission, the web tier is still hilariously full of idiotic ideas and pathetic half assed efforts in the general direction of usability.
So what's actually new? Well, pretty much nothing. All the fuss about annotation support is simply piggybacking off the work of other groups. There isn't a single annotation that the servlet group has come up with. They just support the bare minimum of injections that the Java EE platform requires, such as @Resource, @PostConstruct, and other random junk from JSR-250 (common annotations). You'd think they'd have at least glanced over the efforts of the EJB group and the web services groups, and come up with things like @Servlet and @Filter, but no such luck.
In an excellent spit in the face of all things java, we also have a bizarre 'full' attribute for web.xml's root web-app element. Whatever happened to descriptive attributes? What's so bad about instead specifying something like skip-annotation-scan="true"? It's certainly an impressive leap of faith for anyone to equate full is true to lazy class loading. This is merely one example of the EG's general flatulence in the general direction of usability.
Next up we have some pointless syntactic sugar to allow multiple servlets mapped to a pattern, or multiple patterns mapped to a servlet/filter. Thank jeebus you wankers spent the last 12 months working on this, it's certainly been worth the wait. Surely the community will applaud the wise investment of your time, and be grateful for this huge leap forward that seems to have taken you the better part of a year.
The error handling issue (you can call setStatus in an error page) was one I lobbied for, and I'm certainly amazed that this group of highly talented and insightful individuals actually added something useful to the spec. Given the rest of their work though, I'll simply attribute it to a freak accident of nature.
It's impressive to see that the group has gone out of its way to avoid adding anything useful. I've had three conversations with separate experts on the EG lobbying for the addition of ServletContext.getContextPath(). Every one of them was enthusiastic about it and thought it'd be a very useful method to add, needless to say, that has next to nothing to do with whether it'll actually be added. At the time of writing, there is no mention of such an addition. (for any random Servlet EG members passing by, I dare you to give me a single good reason as to why such a method should not exist.)
Similarly, multipart support is still nowhere to be seen. Jason Hunter probably thinks that there are still idiots out there who use his solution, and so would be keen to avoid the spec stepping over his turf (and what better position to ensure that from than within the expert group itself).
The servlet group, much like the JSF group, has bizarre powers, for political reasons. In the case of servlets at least, they've been a victim of their own success, so there is a lot of inertia and resistance to change. The JSF group derives its power from Microsoft's existence and success, and Sun's baffling habit of attempting to mirror everything Microsoft does and ram it down a highly reluctant community's throat via rounding up the most incompetent people it could find and hurling them at the problem. In both cases, the Men Upstairs at Sun should round up these so called experts, and let the beatings commence until they finally agree to play nice with the rest of the world.
Tuesday December 13, 2005ApacheCon: Shale Due to some freak accident, I find myself at the last day or two of ApacheCon. I'm actually here for JCP reasons, but I figured I might as well find a few talks to point and laugh at.
So the first disaster I stumble into is Craig Mcflaflaweewomjibberploppy's Shale talk. I walked in halfway during this talk, and probably unsurprisingly, the demo being shown looked like it had escaped from 1998. The demo was shale validation, and how it can be server or client side. The client side validation was shown using, wait for it...ALERT boxes. Craigy clearly cares nothing for web 2.0, web 1.1, or web 1.0.
Craigy then goes on to talk about tiles. It's so hard to take this stuff seriously. Does anyone actually use tiles? Even delta.com runs sitemesh. The tiles stuff is the usual horrific sprawl of xml, and Craig is his endearing incoherent self.
I haven't been to any other talks, so maybe this is par for the course for apachecon, but the screens are absolutely abysmal. Craig is showing his IDE< and the text is so blurry and vague that I can't even figure out what IDE he's using. He keeps saying how clever it all is and gesturing wildly in the general direction of what I think is some xml, but of course, the poor audience sees nothing at all beyond some blurry gibberish.
Next up we see some tapestry inspired crud, with the idea of writing html pages and plopping an array of jsfid attributes for the dynamic poop. The demo involves changing the colour of error messages. I feel pretty bad for Craig, as this demo is a great example of why everything he ever writes is so astoundingly unusable. The process goes something like this: find the right id for your element, go to some xml file, find the right item, go to the error messages, find the class, go to the style, REDEPLOY the app, then see your colour change! Of course, Craig realises how much work this is, so happily points out that it wouldn't be possible without open source. Most perplexing.
Craig's guiding principles seem to be COD; confuse, obfuscate, and disempower. The more levels of indirection you have, the better your framework. Users that call the framework apparently find that confusing, scary, and pants-filling. He thinks users would rather have frameworks call user code. Every API that this man has ever produced adheres to these principles. The six people in the world who know better look on incredulously, as both Apache and Sun allow this smut to propagate and pollute our beloved java landscape.
At least there are some smart people in the audience, I can see at least 3 people who look very asleep, and I think one of them is a fat man who is about to start snoring, and some guy just stormed off in disgust.
Clearly I'm not the target audience for this talk. The thoughts I'm left with after attending this talk boil down neatly into: wtf is shale's relationship to struts and/or webwork?
Friday December 09, 2005Web TwoPointSchmoe If there's one thing a time machine would come handy for right about now, it'd be to go back and stab Tim FuckFace O'Reilly with sufficient vigour and zest to prevent the calamity that is the web 2.0 buzzword.
Maybe it isn't surprising, after all, It's been proven time and time again that I'm in the tiny minority of people in blogwankland that remains skeptical, reality based, and decidedly anti-danglyshinyobject. Of course, I'm comforted by the fact that the silent majority is likely also on my team, and that our tech landscape has thoroughly earned the abysmally low expectations the world has of it due to the shiny object brigade.
So what's so bad about Web 2.0? Well, it's such an astoundingly meaningless term. If you speak to anyone advocating this pile of fetid excreta, you'll find them launching into disturbing contortions and obscene limb flailing in a pathetic attempt at coherently tying together a number of unrelated topics. If you really need a visual, picture a group of adults with severe Downe's Syndrome attempting to twitch in time to some death metal. Their fat limbs jutting angrily, bereft of any centralised control mechanism. Their slack jawed faces staring blankly at horrors only they can see, drooling foolishly in the forlorn and impossibly distant hope of a brighter happier world.
Yes web 2.0 people, that's you. Why, you probably wonder, given your collectively pitiful mental acumen. I'll tell you, it's because your desperate need to gawp at everything and anything in front of you is downright offensive to humanity. Maybe some examples will help illustrate the point.
AJAX. It's amazing how many people think that AJAX is pixie dust. I've lost count of the horrific usability of 80% of the shit that ajaxian.com spooges over, for example. Granted, that site isn't really to be taken seriously for anything more than its grinning idiot approach (count the smileys, if you don't believe me). It is however an accurate reflection of the AJAX mentality.
Dion Hinchcliffe in fact, quite unintentionally, beautifully captures what it is that makes Web 2.0 twats so worthy of a bit of friendly hooded-crucified-with-electrodes-on-genitalia-while-standing-on-some-sort-of-box action. Apparently he thinks that 'Web 2.0 represents best practices'. Ohyeah? If these best practices are so obvious, why are there more AJAX frameworks now than java web frameworks? Why is it that every single AJAXified app behaves in bizarre and unintuitive ways, on the rare chance that it actually works on more than one browser? Why is it that whenever the AJAX behaviour is not subtle or in the background, users feel confused, sad, and start crying like little girls? Why are all the lemmings desperately trying to find design patterns and a method to the madness?
Dion's 'Quality is maximised, waste is minimised' assertion is breathtaking in its naive audacity. The fact that he cited 37signals is testament enough to how divorced he is from reality. I know of 5 people who have tried 37signal's basecamp. None of these are techies, and every single one of them had an awful experience, and spends their time telling anyone who'd listen that it is, without a doubt, the worst project management tool they've ever encountered. The 'simpler means higher quality' line is also ludicrous. Simpler for who? Simpler to code has nothing to do with simpler for the user.
All Web 2.0 chozgobblers think that all they have to do is be Googly and their problems will dissapear. Sure, it'd be great if we could all churn out toys like google, an endless parade of what happens when you have too much money, too much time, and few revenue streams. Just never forget that what makes all those toys feasible has nothing to do with Web 2.0; it's boring old AdWords and AdSense.
There's no doubt that ajax, tagging, semantic fappery and all that other gibberish have some potential. Ultimately though, there is no revolution, nor even an evolution. It's simply the ability to toss in a few more tools in the toolbox. Specialised tools, that can be effective when used against the right obstacle. Nothing more, nothing less.
Thursday November 24, 2005Web services guest bile Today's entry is a guest bile courtesy of Mr Clean. The submission was edited slightly to match the high standard of pottymouthed gibberish you're all used to, so the disruption in style and content should be minimal.
You are a developer, and we want to stab you in the genitalia with a wooden spoon. We never much cared for the nitty-gritty of coding, so instead we represent our company on the W3C, because it's fun, exciting, and saves us from actually having to use anything in the real world. You know you can trust us, who else would come up with anything as clever as the DOM API? You on the other hand have stuck to menial development, wearing out braces and semicolons on your rubbery keyboards, and for that, we laugh, point, and fling wet bottomburps in your general direction.
You are powerless to stop us. Powerless we say! Your plan to "put a web service in front of it, should be relatively easy, a few days max." will rank alongside "this is the Titanic, we don't swerve for icebergs", and "a short occupation quickly leading to an independent democracy in Iraq with soldiers worrying about candy and flower related injuries", in the Naivety Hall of Fame.
Let's start with WSDL - Web Service Duplication Language. The schema says it is the product of IBM and Microsoft, so you will anticipate some typing will be needed. This is confirmed as you navigate from the schema element, to message with it's parts, to the portType with operations and inputs and outputs, to the binding with it's own with operations, and inputs, and outputs. "Boy," you think, "I bet this is really flexible, glad they did not make things more direct!". All of these have names, and a simple process of trial and error will show you which names have to refer other names, and which are going to end up in the generated Java. If we used the relational constraints features in the schema for WSDL, that would make things too obvious, thus minimising the fun and challenge of the whole endeavour.
Namespaces in XML are good, so more namespaces must be better. WSDL has many, and these can be especially fun when dealing with the output of a WSDL generator or an IDE. Let's use the same URI for different things, and for the hell of it, let's confusingly use the same names for messages and suchlike so you'll never figure out the cardinalities and relationships. XML being human readable is an outdated concept anyway, and a string of gibberish characters is just as good these days. What they lack in coherence they can make up for in verbosity.
Let us turn to the Java aspects and JAX-RPC. Now, what you want to do is bind the entire XML structure to generated Java classes. Yes you do. No really. Binding is the one true path. Any XML Schema can be bound to Java classes, unless the schema does something silly, like use the features of schema to produce a well designed, tight schema. What was the W3C thinking, designing schema for documents, instead of just remote procedure calls? XML for documents? Why would anyone do that?
The schema will be nice and small anyway, because web services are always used for stock tickers. Anything else is out of scope. You have a stock symbol and a price and that can easily be bound to a few small Java classes. An intelligent young gentleman like yourself would not try to use a complicated schema, now would you? What is that you say? "The format and schema to be used are already defined"? Oh, we are in a pickle. Hope that schema is not an industry standard, designed by a committee, where everyone gets a go at putting a feature in. We would not like to work with an object model like that in our Java. It is not like you can write or have already written your own parsing functionality. No, binding is the one true path.
Why the fixation with XML binding? We created the glorious JAXB, and you snivelling runts ignored it. Well, now you will have no choice. You have your business objects, and you have your XML. So naturally what you need is another separate bunch of Java objects, bound to the schema, which you can navigate to copy the data into your business objects. A one megabyte, industry standard, pile of crap schema becomes twenty megabytes of lovely JAXB source. There are lots of crappy names and packages, and classes for anonymous schema types. Do not ask us for a DOM, you weakly-typed peon. You may however have SOAPElement objects, provided you hack the WSDL in an implementation specific way, and are prepared to deal with old versions of this bastard child of JAXM called SAAJ, that are completely separate from the normal Java APIs like DOM. Actually, lets then make a new version which does extend all the DOM crap, because we can. Now that we've managed to sucker a bunch of you into using JAXB, we've identified the idiots for the smart people. We can now go ahead and introduce JAXB2, which is aimed at the less braindamaged of you despicable developers.
Why use old versions of the SOAPElement classes? Well, J2EE 1.4 is a bit new, now isn't it? So you are stuck on Websphere 5.x or Weblogic 8.1. (not one of the poor peoples app. servers), and there is no J2EE standard for web services in those. So now you get to learn how (or whether) IBM and BEA programmers think, and you must code accordingly. Dreams of reuse evaporate. You could try switching in an alternative SOAP library, with all the endless hilarity that that entails. You could try using SAAJ and forego JAX-RPC, but you must deal with more factory construction than southern China, and SAAJ does not tell you how to hook-up a service implementation in J2EE, just how to call one. SAAJ is fact is baffling in its pointlessness, all in all.
JAX-RPC will be better in version 2.0. We have changed the name, but not because we rogered the first versions and there is a stigma. It can't be any worse, so we can guarantee gratitude and praise. You are a developer, and we want to stab you in the genitalia with a wooden
spoon. (2005-11-24 11:16:03.0)
Thursday November 03, 2005Mergere vs Maven So Maven 2.0 was sharted out recently by that grand posse of intellectual giants that make up the employees of Mergere. It promises speed, agility, and is probably even better than ruby. Along the way, Mergere also revamped its website to include more marketoid content, and a more serious attempt at sounding at least relevantly ridiculous, as opposed to merely spastic in a vague and unspecified context.
The trouble is, it's still impossible to find out what these people do. if you ask anyone 'in the know', you'd be reassured that it's not 'just' maven 2 and yet another tawdry attempt at a continuous integration product. They provide 'more', for some unspecified and suitably arm-wavy value of 'more'.
Wisely missing from the dubious offerings at hand is a price list. Fear not though, someone seems to have accidentally said the wrong thing to the wrong reporter, and we now know that Mergere's price starts at $25k. So what does this actually buy you? Well, it's very unclear. It does guarantee you entry into the rather dubious league of brain damaged product purchasers, for one thing. You'd probably still feel inferior to your fellow league members though, as you're unlikely to even get a shiny box or CD for all your hard earned greenbacks. Seriously though, has anyone paid these monkeys for anything? Is anyone even thinking of it? Please step up so we can all point and laugh.
According to the website though, you will get 'help with maven'. So basically, Mergere's goal is to help you use maven. Except of course that if Maven is indeed as great as said naive wankstains insist, then why on earth would you need to pay someone to tell you how to use it?
There seems to be a very culty freakish community of ex-jboss people floating around who keep spinning their wheels doing stupid things. I realise that I'm probably lumping in a lot of different people (many of whom had nothing to do with jboss), but it's bizarre that all the guys involved in Geronimo/maven/smattering of codehaus dangleberries/simula labs/logicblaze seem to be, well, in bed with one another. The fact that 15 minutes into a Geronimo talk the speaker starts discussing maven is rather disturbing. Exactly how many appserver presentations spend their time saying how great ant is? Is that the best they have to offer? Surely there's more than a mildly disturbing jbossian inferiority complex?
Speaking of Geronimo, does anyone else find it hilarious that IBM has taken a big fat unlubricated shiny black object and stuck it into some strictly one-way orifices? The entry level, worst of the worst, cheapo piece of crap dogshit appserver they offer now is something that builds on Geronimo. The crack addicts in the Apache camp might view this as a good thing, but really, the message the rest of us are getting is 'don't touch geronimo with a barge-pole, it's not even good enough for IBM to give away for free without having to build a bunch of stuff on top to make it useful enough'. Presentations are now spearheaded by IBM lackeys, and developers are (quite rightfully, given the intellectual acumen of the people involved) being shoved aside or trotted out for appropriate party line poopage.
It's sad seeing so much time and effort wasted on the wrong things. It's sad seeing the one of the prime motivations for Geronimo (according to the Geronimo book) is that 'it's from Apache'. It's inexplicable how nobody seems to notice the cognitive dissonance between their 'we don't suffer from NIH' chants yet spend thousands of man hours living and breathing NIH (Harmony, Geronimo being prime examples).
While I'm on a tangent utterly unrelated to my original rant, I'd like to digress even further and encourage you all to join the JCP and vote for me, I'm running again this year. All you have to do to join is fax an 11 page document, and sign in two places, hop on one foot, tweak your nose, and wave unmentionables in the general direction of Sun at specific times of the month while clad in a strategically placed pink sock. Whatever you do, please do NOT vote for a company, the Executive Committee has enough corporate representation!
Sunday October 23, 2005TSS bringing out the best in us Sure, I'm a big fan of Java. Yes, I do sneer, point, and laugh at all those Ruby naysayers, there is however something deeply offensive about leaches on the java society like Bruce Tate and his ilk.
By all means brucey, go forth and shove a Ruby glowstick in every orifice of yours you can find. You can squeal along like a stuck pig with your fellow foreign object aficionados, and we'll even think it's cute. If you want to be taken seriously though, injecting a dose of realism in your deranged ravings will get you a long way.
So, some clarifications are due perhaps. First of all, if you write an application in 4 months in any language, rewriting it in any other will take you significantly shorter, assuming you're doing a direct rewrite.
Secondly, in two months, RoR's dominance will STILL be a question. It's an up and coming tool, fit for certain things, it's not the solution to world peace, and even if it were, it'd take a hell of a lot more than two months to get there. You with your pathetic little books and dirty shilling might find it perfectly adequate for all your sexual needs; many others do not, and some of those, dare I say it, will not.
So if you're so unhappy with Java, and have seen the light, perhaps you'd care to just Go Away, and we'll see how long you last without your endless Java whoring. Move on to your greener pastures, I assure you you will not be missed nor mourned. If you do want to stay in our playground though, you'd have to do a lot better than constantly shit in the corner like some overgrown child sans potty training. I realise you have books you need to sell, but you're doing yourself no favours by arguing with that insane glint of religion in your beady royalty counting little eyes. Set down that crack pipe before it's too late and you lose the last shreds of credibility you've ever had.
So now that I have that off my chest (inspired by Bruce's endless whinging on his 'Beyond Java' thread on TSS), it's time to whine about TSS a bit.
Exactly what genius thought it'd be a good idea to allow Kirk Pepperdine to post news stories? Granted, TSS is generally one of the dirtier toilets of javaland, where every passer by gets to deposit his own personal collection of dangleberries and tagnuts, but really Kirky, it's NOT your personal blog.
Kirk has the dubious honour of being the only editor that I know of at TSS who has managed to get a story pulled by a more senior editor. Kirk, in his infinite wisdom, decided that what he finds funny is the last word of Funny, and TSS, armpit that it is, should be treated no better than his personal blog. For shame Kirk, for shame. See, it's one thing if we could say it's an isolated incident. Sadly, at the time of writing, almost every story on the frontpage by Kirk is about as useful or relevant as Andy Oliver in a conversation, and about as considered and well thought out as Gavin Fleury in, well, anything. We have a story about Geronimo (the little container that, if it had a mouth, would be screaming for euthanasia 24/7) choosing a logo, another amazingly non-humorous piece about 'Samy', and a new job for Ward Cunningham. The best the guy can hope for is to induce a yawnfest, and that's when he isn't out trying to convince everyone that he is indeed the most close minded person in javaland.
Kirk, you might know your way around java performance, if I were you though, I'd avoid speaking up about anything else, or you'll ruin that mystique you have, and suddenly show everyone that you're just another loudmouth who refuses to ever learn anything, and believes that his anus delivers golden eggs instead of foetid log shaped lumps of unpleasantness.
Java benefits tremendously from competing technologies. It's always good to be forced to re-evaluate one's approach to almost anything. There can be a rich, vibrant, and dynamic discussion and exchange of ideas. The one thing I caution all you spastic self-appointed 'thought leaders' is not to insult your audience. We're not your dirty little congregation who need some kind of holy book or religious nonsense. Treat us with respect, and we're a lot more likely to take you seriously.
Sunday October 16, 2005Ceki Gülcü's logging fetish 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.
Indeed, our umlaut laden hero has been a busy little ferret. Disgusted with the evil he wrought in log4j, he then went on to invent a whole host of logging frameworks. After a futile attempt at an enterprise logging project, he went on give birth to a stillborn bloody carcass by the name of ugli. ugli was universal logging, and everyone laughed heartily when he suggested that people switch to it. Even the intellectual giants (har har) at Apache scorned this pointless new API.
Undaunted, brave little Ceki decided instead to rename his project to slf4j, figuring that a project without the magical 4j suffix has no hope of success.
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.
Nlog4j is basically log4j with some classes ripped out. SimpleLogger is basically a more obscure way of calling System.out.println.
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!' (2005-10-16 19:22:14.0)
Thursday October 06, 2005Joblogging There's something so tiresome and odious about employees blogging about their products. It smacks of a certain amount of desperation and sleaze, and is always hugely biased and usually surprisingly uninformative and uninteresting.
One product that has recently discovered this particular marketing channel is NetBeans. The Sun people who go out of their way to pretend to post impartial third party opinion/woweeisntthisgreat pieces about netbeans are loathsome little toads.
I mean really, how can you be so endlessly amazed at your own product? How can you, day in and day out, be surprised by how great it is? One can understand a 3 year old boy finding their genitalia a source of endless fascination, but you people are grown men, for the love of god.
It's not like the product they're plugging is even that good. I actually went through the hassle of trying out the beta just released. On OSX, the experience is as much of a pleasant surprise as being ambushed by a big black man wielding a variety of baby jesus buttplugs intent on putting them to good use.
For one thing, the installer on OSX simply....does....not...work. Launching the IDE requires navigating to a bin dir and using the command line. Bad sign. Creating a new project proceeded to vomit up an IndexArrayOutOfBoundsException, and the scanning project classpaths subtle info message in the corner (which should be a blocking op, considering you can do sweet fuck all while it's happening) takes about the same amount of time growing a colony of antisocial angry midgets would.
Eventually when the scanning is complete....nothing happens. That's right, maybe due to earlier exception, netbeans sharted itself and had no idea wtf to do next. So I reopen the project, and lo and behold, I can type stuff!
Clearly unsatisfied with the misery it's inflicted on me, and intent on teaching me exactly what 'slow' really means, it then proceeds to spank me for my impertinence in trying to use autocompletion. I press buttons, I sit, I wait, I pace, I contemplate how best to gain some sexual gratification, and eventually the little window pops up. Alright, fair enough, it's the first time it visits the classpath, so I can deal with it, I'm a big boy. Alas, it is not to be. While further autocompletions to the same class are nice and zippy, that watching-paint-dry pause gleefully materialises again on every new class.
Of course, all this were fine if the UI made up in looks what it lacked in every other department. The OSXification attempt, while very clever, looks almost obscene compared to the native java L&F.; The tabbed pane is garish and gaudy, the toolbars cartoony and childish. While we're looking in that area, what linguistic guru came up with the tooltips? If you hove over the close button, the tooltip, helpfully enough, says 'close button'. Likewise if you hover over other buttons in tool windows, it's always 'blah button'. Gosh, thank god you're pointing out that it's a button, I might have mistaken it for a textfield or a pigeon trapped in the screen.
So please NetBeans people, lay off. Your IDE has its plus points, but we don't need to be reminded daily of its existence. You're discrediting whatever actual value you might have to offer with this constant waggling of genitalia in the general direction of everyone and their dog.
Wednesday September 14, 2005The Black Art of Good Design I'm willing to bet that any reader of this blog is likely to think of themselves as a savvy developer type who can, before breakfast, design any number of APIs, implementing said APIs, and swindle a bunch of people out of a ton of money along the way.
What has struck me recently however (beyond the fact that the above assertion is analogous to 90% of people claiming that 90% of people are stupid) is the orthogonality of coding and design.
There are a ton of developers who can write a mean algorithm. They can identify a problem and manage to digest the salient points with enough success to plop out an implementation that does exactly what it says on the tin.
Interesting enough though, this has sweet FA to do with design. Yes, the piece of software performs its function beautifully, efficiently, and one could argue, elegantly. That says absolutely nothing about its design.
Java, specifically, goes a long way towards ramming down a set of design principles. Said principles are followed fairly blindly by most practitioners. The OSS world is awash with examples of people who have read the right books, but have absolutely no skill or talent at conceptualising or grokking the underlying principles behind the books. To them, the design pattern is an end goal, not a tool. To pick one example (out of thousands), look at Matt Raible's OSS efforts. It has inheritance! It uses PATTERNS! It is LIGHTWEIGHT! Yet, I'd argue that it's very badly designed (if you don't believe me, just try getting it to do anything other than the very very basics.)
So what's the acid test for a good design? I have no idea. The closest I could come up with is A good design allows your code to do things you never expected it to have to do. It's not about 'oh I'll add an interface here so I can plop in different implementations' when there's no sane reason you'd ever need more than one implementation, for example. Having made that assertion though, I'd imagine it's pretty clear by now that I have no solution or fix. If you're into that sort of thing, you can try befriending a fowlerbot, working your way to the top, then perhaps running your genitalia over his beard in the hope of getting some use out of the smug bigoted little fucker.
Another example (sorry Cedric) is TestNG. Cedric is pretty good at design, the code for TNG is on the whole quite good, but there are definitely some points where one could argue that bad design decisions were made. For example, there are interfaces for simple objects that have both getters and setters specified, which makes creating a read-only implementation pretty unpleasant. I'd also argue that putting getter+setter style methods in an interface is an implementation leak anyway, mind you. The upshot of this bad design is that the remote API for getting back TNG results is different to the local JVM API, and thus two sets of classes have to be maintained as a result of this bad design.
Another example is method ordering. There is currently a need for TNG to (internally) choose a different invocation order for the total set of test methods, but the design as it stands currently makes this change very difficult and tricky. Thus, another bad design!
On the other hand, there are plenty of other well designed areas which have been reused in some fairly unexpected ways, all of which points to decent design.
TDD for example has an interesting approach to design. It assumes, up front, that you can't design your way out of a wet paper bag. You write tests that ensure the system does exactly what it's supposed to do, nothing more and nothing less. You want to change things? You do it the brute force way by stomping all over your codebase and endlessly refactoring, it's a lot more work but, in theory, any thoughtwanker can do it. Of course the downfall of THAT approach is that some portions of TDD STILL end up requiring someone intelligent, so you're back to square one of needing someone smart, instead of swappable sweatshop bodyparts.
Yet at the end of the day, a depressing majority of java codebases look like a 3 year old had sat down in front of a large bucket of design patterns and plucked a fistful and hurled them in the general direction of some code. Proving that the tooling approach can, at best, only help the mediocre claw their way up to the average.