August 2004

« July 2004 | Main Index | Archives | September 2004 »

30
Aug

Today's error message comes from the Sybase jConnect JDBC drivers (v5.2):

com.sybase.jdbc2.utils.UnimplementedOperationException: The method com.sybase.jdbc2.jdbc.SybPreparedStatement.setCharacterStream( int, java.io.Reader, int) has not been completed and should not be called.

"We thank you for calling this method. All of our programmers are busy right now, but if you wait, then some day one of them might get around to fully implementing all of the methods in the JDBC2 specification. Phew, there sure are a lot of them!

"Until then, console yourself by thinking of all the methods that we have finished writing.

"Share and enjoy!"

Update: They seem to have got around to implementing this method by version 5.5

From a news.com article, Jim Allchin points out that even now Microsoft have been forced to strip WinFS (the database-backed "find where you dropped your car-keys" filesystem) out of Longhorn in order to make the 2006 ship date (The Register cites anonymous sources claiming that the new composited UI, Avalon, is also in danger), there are still a lot of great new features awaiting users two years hence:

Still, he said, dubbing Longhorn without WinFS as "Shorthorn" is "derogatory," because the operating system "is packed full of capabilities." Some of the features he mentioned were "great roaming support," .Net Framework 2.0, "new browsing capabilities," the "fresh" user interface, improved migrations and deployments, "more resilience to malware" and "a new photo experience."

Phew, am I glad to hear that. I was starting to get worried that my poor, benighted Windows-using brethren would be forced to wait another five years for their new photo experience.

I was going to point out how suspicious it was that Scoble has vanished for this particular weekend, but I'm afraid someone would think I was being serious.

Schadenfreude is such an ugly thing.

Java Is DoomedIt all started on the SyXPAC mailing-list. We were discussing possible future activities for Geek Night, and I half-jokingly mentioned I was considering doing a presentation called "Why My Brain Likes Ruby".

Of course, somebody called my bluff, and on Friday night, when I was collapsing at home on account of having been woken up at 5am by a cat every day of the week, I pulled up Keynote and started playing around. And if you're browsing with images turned on, you can see what popped out of my tired and slightly beer-assisted subconscious.

As an aside, I can't begin to describe how much of a boon the Google image search is when you're messing around with slideware. Looking for a picture of a guy in a fire-proof suit? Look no further!

The rest was this slide's fault. I have no idea where it came from, but damn it's fun. Immediately, out poured what can only be described as half abstract, half manifesto:

"Why My Brain Likes Ruby"

I'm not a Ruby expert. I hack Java for a living, and it's likely to stay that way for the foreseeable future. With the reference manuals close at hand, though, I can throw together a credible Ruby program.

More importantly, whenever I start hacking Ruby, I am overwhelmed by the feeling that this is... right. And I find myself going back to Java and thinking "Why does this language keep getting in my way?"

You won't come out of this presentation knowing Ruby, but you might come out wanting to learn it. You may just as well come out thinking that I am a dangerous lunatic, or in the words of Hani Suleiman: "the kind of person who is amused by shiny baubles".

"Why My Brain Likes Ruby" is an attempt to prompt discussion through blatant flamebait, and one man's incredibly biased opinions:

  • Does the language really make a difference?
  • Static typing: belt or straitjacket?
  • How did Perl go from enfant terrible to tired has-been in just five years?
  • Will we still be writing Java code in ten years, and if so, should we just slit our wrists now?
  • And if we have time, and haven't broken out into physical violence by this point: why should Sun open-source the JVM?

For your comfort and convenience, this presentation should only be consumed after a couple of beers.

I'm almost hoping my second bluff is called, and someone asks me to present the damn thing. It might be fun.

A newsday.com article on the new Sony hard-disk walkman spake thusly:

In 25 years, when I look back at the history of online music distribution and Sony's role in it, I'll Google "ATRAC."

How's that for an implicit assumption? "In 25 years... I'll Google..."

I guess one of the things about becoming a verb is that it ensures you at least some form of immortality.

Music to Code By

  • 10:25 AM

Yesterday, it was Ministry. There's something about repetitive industrial white noise while you're working. It's like having noise-cancelling headphones: it blocks out all distractions without itself getting in the way:

Soon i discovered that this rock thing was true.
Jerry Lee Lewis was the devil.
Jesus was an architect previous to his career as a prophet.
All of a sudden, I found myself in love with the world;
So there was only one thing that I could do:
Was ding a ding dang my dang a long ling long.

Today, it's Tom Waits. I don't have as good an explanation for this, but that's alright: Waits is one of those people who just is, without needing explanation:

Will you sell me one of those if I shave my head?
Get me out of town is what fireball said.
Never trust a man in a blue trench coat,
Never drive a car when you're dead.

Back in Perth, it was The Chemical Brothers and The Prodigy; but hell, it was 1999 and we were young and carefree.

Alan:

It's times like this I wish I'd never learnt Python. I'd be a much happier Java programmer.

Charles:

ignorance.equals(bliss)

Alan:

StateOfMind bliss = new Ignorance();

Alan:

StateOfMind bliss = StateOfMindFactory.createIgnorance();

Charles:

<bean id="mind" class="com.example.brain.Mind">
   <property name="state">
     <ref local="bliss"/>
  </property>
</bean>

<bean id="bliss" class="com.example.brian.states.Ignorance"
  autowire="true"/>

Alan:

try {
  MindState bliss = new Ignorance()
} catch (RealityException e) {
  LOGGER.error("The users are wising up");
}

Charles:

try {
  MindState bliss = new Ignorance();
} catch (Throwable t)
  // TODO: exception handling
}

alt.cred

  • 9:57 PM

How your 90's alt.rock crediblity can hold out for six songs... then come crashing down in a painful heap:

This is a visual gag, I'm afraid.

Bo, in response to my last post, had a few interesting things to say:

I've never met any piece of 'content' in the real world that could render itself as HTML. This doesn't even make sense for the majority of content (images, sounds). I can't think of a single reason why a 'Content' object would have a 'asHTML' object. Such a conversion method should certainly depend only on the public state of the object and not any of its private state or capabilities. I find the entire idea of a 'Content' class pretty strange. What methods does it have? getId() and getTitle()? Since these aren't behavioral methods at all, at best you should only have a Content interface.

Please, gentle readers of this weblog. Offer me the simple courtesy of assuming I am not completely stupid. If you don't feel able to offer me this courtesy, then why are you wasting your time reading the feeble scratchings of an idiot?

I don't feel it should be necessary for me to have to explain in excruciating detail that in the context I was writing, there are perfectly good reasons for having a Content object, and perfectly good reasons for it to behave the way it does, and even perfectly good reasons that any translation to a format other than HTML must actually be done via HTML.

The task of 'Given a Content object find me a Renderer object that can render it' depends on a million different things--are we operating in headless mode, what medium are we rendering to, what format are we rendering to, are we rendering to a remote or local client, what level of detail are we rendering, etc etc.

Would it come as a shock to discover that not one -- not a single one of these "million different things" applies to the case I was describing? Would it come as more of a shock to discover that if any of them did, I might in fact have mentioned them?

If I were in an uncharitable mood, I might suggest that this is a perfect example of why so many otherwise intelligent people write baroque, unuseable code: the feeling that you have to cater for a million possible conditions that in actuality will never happen, just so you can say your code is architecturally pure.

However, when I was studying Philosophy, I was introduced to the Principle of Charity:

If a participant's argument is reformulated by an opponent, it should be expressed in the strongest possible version that is consistent with the original intention of the arguer. If there is any question about that intention or about implicit parts of the argument, the arguer should be given the benefit of any doubt in the reformulation.

Simply put, there's no point going into a discussion unless you assume that the person you are disagreeing with has a clue. If you don't debate the strongest possible form of your opponent's position, all that's going to happen is that it will be reformulated the next day, invalidating any objections you based on those uncharitable assumptions, and wasting both your and their time.

IOC Conundrum

  • 3:54 PM

Using Spring, I've encountered an interesting architectural conundrum.

Say, just as a random example, that your application is centered around the Content class, which is the superclass of all, well, content. One of the obvious things you want to do here is that you want to send an 'asHTML' message to your content object and get the HTML back.

However, the rendering of a Content's content as HTML is a pretty complicated process, involving a somewhat nightmare-ish parser and runtime-loadable macros. So the renderer is an entirely separate component. This would mean that the Content class would have to delegate the rendering to the Renderer component, still no big deal.

Enter IOC/Dependency Injection. Now, each individual instance of the Content class needs to be injected with the renderer component by the IOC framework before any rendering can be performed. This is still possible: we're using Hibernate, so one solution would be to use Hibernate's lifecycle interfaces to ensure each Content object is auto-wired with its dependent components from the Spring context when the entity is loaded.

But what if you're pulling a few hundred or a thousand pieces of Content out of the database? A few wasted milliseconds resolving the object's dependencies becomes a few wasted seconds for a thousand objects1. Which is bad. Especially when the more of these content objects you're loading, the less likely it is that you're going to be rendering them as HTML in the first place.

At this point, you say screw it. Anyone who wants to render Content as HTML (despite the fact that being rendered as HTML is the raison d'etre of Content) can grab the Renderer themselves from Spring and pass the Content into it.

The price of this design decision is increased complexity. 3/4 of the system becomes dependent on the Renderer component. Ditto for the Security component, since for similar reasons you can't directly ask the Content object who is permitted to view it. And so on. Because you can't use your entity objects to do an object's primary function -- hiding complex implementation -- your system becomes a tangled web of component interdependencies.

To my mind, that makes the system brittle. Every change to a component has much more wide-reaching effects, and you end up duplicating a lot of code keeping the entities, and the component-derived metadata related to the entities in sync.

On the other hand, maybe this isn't the problem I think it is, and the alternative, complicating the entity objects by overloading them with large numbers of otherwise component-ised capabilities, is a cure worse than the disease.

I can't help thinking, though, that if I can come up with a clean solution to the problem, I might just be able to commit some significant acts of elegance on the codebase.

(Note: If you want to comment on this post, please try to do it in such a way that contributes to the sum of human knowledge. The answer isn't "Hibernate sucks", or "Spring sucks", or "IOC is a crutch for stupid people". Similarly, it doesn't matter if this is something that could almost certainly be solved with mix-ins in Ruby, because there are several good reasons I'm not programming in Ruby.)

Addendum: August 10th

I'm getting the feeling I misstated the problem. Or maybe I shouldn't have used that particular concrete example. People seem to be running away with the "What if I wanted to render the content as ASCII art?" question, which wasn't my intent at all.

The problem I was attempting to express was that with IoC, it's hard to give complex behaviour to an entity object. The entity can't (or at least shouldn't) discover system components for itself, and injecting (possibly unnecessary) dependencies into every single entity as it's retrieved from the ORM layer may be inefficient.

The result is a complex web of inter-component dependencies, because instead of saying "I can do this, this and this to a page", you instead have to say "I can do this to a page with the SecurityManager, this to a page with the LockManager, this to a page with the WikiStyleRenderer" and so on.

And yeah, generic method dispatch would probably work too, but I'm not using CLOS, nor am I likely to ever do so professionally.

1 I'm yet to time this, it's just a figure I pulled out of my asshat.

It happened again.

On Friday, I woke up with a pretty nasty cold. I grabbed some Paracetemol/Pseudoephedrine/Codeine tablets on the way in to work, and staggered somewhat unproductively through the day. By Friday night, I was in no state to do anything but stagger home and feel sorry for myself.

Saturday, well, Saturday was a write-off. Although I did end up discovering that televised Poker is really quite interesting, and can be particularly dramatic. Unfortunately, for the finals, they introduced this stupid 60 second shot-clock that annoyingly capped any real tension that could build up during a hand. If only Americans understood cricket, this sort of thing wouldn't be allowed to happen.

Sunday, I woke up feeling like I should just go back to bed. I went out to breakfast instead, but by the time I got home, my head was killing me. A few hours nap... didn't help. Pizza and bad television seemed to be rather useful, though.

I've found that Australian Idol is almost watchable, so long as you mute it whenever anyone's singing. If you do that, then it's all about complete strangers' life-long dreams being crushed in an instant, which is much more fun. (In the same way, Big Brother is also fun to watch if you ignore the competitive aspect, and approach it from the point of view of it being the televised torture of stupid people.)

Anyway, it's now Sunday night, and I'm feeling disgustingly healthy. The cold has lingered for precisely one weekend, and is about to deliver me back to the working week with only a few lingering symptoms.

Bastard.

I wouldn't be that annoyed if this didn't happen all the time. Whenever I get a cold, it almost inevitably starts on Friday, gets bad Friday afternoon, then spends the weekend making its way through my system.

On close examination, the explanation could be one of two things:

1. The universe is a heartless, unfeeling place, arranged (perhaps deliberately by some malicious demiurge) solely to make my life as annoying as possible.

2. I tend to go out on Wednesday nights and drink too much to notice that I'm walking home in the freezing cold, thus robbing my immune-system of any chance to defend itself right before the end of the week.

I still think number one is the most convincing, though.