I'm currently using Forrest to document the evaluation of various O/R frameworks I did for my current employer. In fact, I started with a MS Word document, but I got pale in the foresight of twiddling with headers and fonts to get something presentable. Then I decided just to go for it. It rocks. I had to find out a bit how the <link> tag works a bit, but that's forgotten already.

I'm curious what my readers will think of it when I present it to them next week... I'll keep you posted.

Outer Web Thought Log: Cluefull people get rewarded and It's happening: Bruno is about to become Apache committer. Outerthought now has one business analyst (aka "feature-spawner"), one architect (aka "modelisator") and one developer (aka "worker"), who are all committers. I guess that makes them the first single-company Apache waterfall ;-) Congrats, Bruno!

Ow man, games like the one Bruggen is referring to, are just too addictive for me... I've only went cold turkey on Sokoban (again) 2 months ago, and I'll have a hard time not playing this til 2 o'clock. AM, that is. Thanks, Rik!

I've just applied the Enkoder script. While it will not kill the spambots forever (and while they will still be able to find my email address from various other web resources), I hope it will at least slow them down.

Intriguing: Introducing the Dvorak Keyboard. Although it seems to be one of those geek "look how cool I am" things, it's interesting. I've switched my keyboard and typed something in notepad to get a feeling, and it felt good... Using the "one-arm" Dvorak layout would even look cooler for innocent bystanders, but I think it would expose your hand to RSI a bit too much (using the same hand all the time). Although... left-hand Dvorak and the mouse in the right hand would spare me a lot of keyboard-mouse switching...

Danno wants to earn big bucks ;-)

While of course I'm interested in this too, it is in the end that the real danger lies:

just because you can monkey around with J2EE middleware doesn't mean you are worth one tenth of the money that is spent on you

I've been pondering this for a while now. Most of the companies that hire contractors, are not capable of making a distinction between a good and a bad programmer. So how are good programmers able to prove they're good? How can you (honestly) prove that you're actually ten times more productive than the next guy/gal in line, who asks only half of the fee you ask?

BTW, nobody should have a problem convincing somebody with mere buzzword throwing. It's a weapon the next in line will use too, so don't be afraid/shy/"political correct" to do it.

Another tip: when asked "how well do you know X?", don't be afraid to say "very well!". I've experienced situations when I answered "well, I've been playing around with it, but it's not really my area of expertise.", while the next in line just said "I know it!", but didn't know where the start button was, so to speak.

Probably it's not plain dishonesty of those people. The more you know, the more you know what you don't know. I want to explain this to you: imagine that everything there is to know, is a plane. The things you know, is a filled circle in that plane. Now, imagine a small circle. It has a small boundary, so for somebody inside that circle, it is just to say "there is little that I see that I don't know yet". And imagine a BIG circle. It has a very BIG boundary. A person in a big circle will be more apt to say "There is much I don't know yet." Which doesn't mean he knows less, only that he sees more that there still is to know. (I hope this is a bit clear. Courtesy of a teacher in high school. It's a bit more clear when drawn on a chalk board, I guess.)

So to conclude: when presenting your knowledge, don't concentrate on everything you don't know, but on everything you do know. Now if only I could do this in practice instead of in theory ...

I encountered my first mayor stumble in getting Hibernate to do what I want it to do.

We have a database which has business data as primary keys. Those keys are (wisely) encapsulated in objects (in the Java code, that is). Now, Hibernate recommends not to use business data as primary keys, but says it still is allowed. I'm glad to hear that. Now I'm just figuring out how to tell Hibernate that it should use our class while doing the mapping. I already found out that it had to implement UserType. But the documentation of the UserType interface seems to be a bit scarce in what exactly every method is doing. So now I'm stuck with a

cirrus.hibernate.PropertyAccessException: IllegalArgumentException occurred while calling: argument type mismatch setter of X

I hope I can get this solved soon. Refactoring the DB to use non-business primary keys is too big an investment for us ATM (certainly in the light of the fact that we're still evaluating Hibernate, and didn't take the "let's do it" decision yet).

Yet another "my Java tools" list. They seem to be very popular at the moment (like the "my cd collection" on each personal homepage some years ago?"). Anyway, to check out when time permits (there seem to be some on that list I didn't know of yet).

Looks like 5 minutes of fun: Good Old Adventures. Slashdotted at the moment. Hopefully I remember to check it out.

Erik pointed me (once again) to something that looked interesting: a pure Java Microsoft MSN Messenger clone. I got the files, unzipped, started, tried to login... and got disappointed again. The authors didn't provide any way to configure a HTTP proxy. This is the nth time I've seen it. It's kind of weird: every C, C++ or .NET application I get, has a "proxy settings" box somewhere. None of the Java programs have it. Is it that hard to configure proxies in Java (I've never tried it)? Or are most Java programmers using direct T1 lines?

Note: I know there is some arcane -D setting you can provide to use a HTTP proxy, but I forget every time what it is, and Google doesn't return too many useful hits on that one. It should be configurable anyways.

Note: This is in no way an attack on the authors of JMSN. It is just a general remark. My hope is that at least one Java programmer who is about to release some nifty code, now thinks "Ah, I'll quickly add that before I release".

I've just added a new toy in the left column. Most people will read this in an aggregator, I know, but I couldn't resist.

Quote of the day (from the Hibernate manual):

Unfortunately, Hibernate is flexible and supports several approaches.

Or how users and documenters don't see everything in the same perspective ;-)

For the "hmm, it might be useful some time" collection: Multiple Java Homes (via Ted Neward). The "root" article is also a good read: Comments re: "Sun's own engineers find Java'impractical'". Looks like the JavaBear is going into my blog roll (which I really should publish here one day).

I just wanted to thank everybody who commented on my JDO / O/R search-in-the-dark (including Joe -- if I've overlooked somebody, let me know. I still have to work on the refer(r)er-tracking of this blog).

It seems like everybody recommends Hibernate (with OJB as a close second). I will concentrate now on the first one. Thanks again, everybody!

dsuspense, aka Dominic Da Silva. His mug shot already makes me feel like summertime. Bring out the cockail shaker!

I'm currently looking for a solution to the Persistence Problem. Revisiting the O/R problem yet again. Currently, we're having a mechanism based on Value Objects and Data Access Objects which works quite well, except for the fact that it's a nightmare performance wise. In order to improve performance, we're writing custom Connection wrappers, parsing and reparsing statements to make them Prepared Statements, etc etc. Every improvement creates some "we have to remember to do that with new objects in the future", each of which can be easily forgotten and which omitment is not readily noticed.

An added complexity is that we need a system that works as good for batch processing (thousands of records at once, loaded from files) as for "online" processing (one at a time, with a user sitting at a screen), without copying all the business logic. It's easy to build a system that works A-OK for either, but not for both.

So somebody pointed me to JDO. It seems to be a good replacement for our DAO layer. Map your objects to a DB without too much complexity. But I'm quite hesitant: will it solve our performance problems? Will it be as easy to convert our application as it looks? Even worse: if we decide to go for JDO, do we need Sun's JDO spec, or is Castor's better? Sun's spec doesn't seem to have a free implementation, which makes it riskier to invest in that option. I've heard a lot of good of Castor, but it was about it's XML serialization. Are they as good in O/R mapping? I'm looking into it, but real-life experience would be very welcome. I'm kind of searching around in the dark, with a flashlight that only reveals positive points.

Jesse Ezell seems to say "you have to do more than 40 hours a week". I don't get it. Why would that be? Anyway, "doing hours" seems distant to me. I'm 24/7 busy with my job. I punch in and out at about 40 hours/week (most of the time even less), but when driving home, when eating, when going to sleep, when lining up in the grocery shop, ... I'm thinking about my job. It never ends.