So I just thought I was funny when dropping in this small (albeit most dull) statement in my close to straight positive, short reference to Doug Dunn's book Java Rules.

Theauthorhimself just commented on my blog asking for an explanation on the usage of the word 'dull'.

Well, obviously I was trying to express some kind of negative vibes around the book, and just used the word that in my limited knowledge of the English language had the appropriate association to the feeling.

Using more then one word [and after clearly saying that I think this book is the absolute reference work to Java that every serious developer should have on his desk (honestly)] to describe my (only) negative experience with the book: readin' it was a (tough, dull?) job. It wasn't any fun. It was plain hard work, and more then once I really had to put myself to it. I'm quite a heavy all-reader type of guy and am easily grabbed by books in general. I also remember reading more then one technical book that actually made me smile or brought the ideas in such a way that I just couldn't put it down. I was hoping for the same with Java Rules. It didn't work out. Concluding: To me this book however has taken the place of the universal telephone book on Java: every number is in the book (and regarding the many Java books I've read my feeling is that a lot of numbers are only in this book), but you look up what you need and you don't expect to have an exciting evening reading it from front to back.

Getting more and more addicted to maven, there is just one thing that keeps on hurting and that is the UberCryptic errormessages you get from the beast.

$ maven xdoc:transform
 __  __
|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0

build:start:

xdoc:init:

xdoc:transform:
xdoc:init:

xdoc:copy-resources:
    [copy] Copying 4 files to C:\ot\out\projects\eclipse\Schaubroeck_OTAdvies\atlas\target\docs\style
    [copy] Copying 94 files to C:\ot\out\projects\eclipse\Schaubroeck_OTAdvies\atlas\target\docs\image

BUILD FAILED
File...... C:\app\cygwin\home\mpo\.maven\cache\maven-xdoc-plugin-1.8\plugin.jelly
Element... attainGoal
Line...... 687
Column.... 48
No goal [:register]
Total time: 11 seconds
Finished at: Mon Aug 16 10:27:21 CEST 2004

Q: How to translate the above in plain human language?

A: (lightning and mist, dark lights, bats flying around and a deep voiced evel grin saying:) You are eternally doomed! Woahahah!!!

In my case "No goal [:register]" *obviously* meant stupid me forgetting to remove this default section from some sample project.xml I snatched:

    <reports>
        <report />
    </reports>

I found this quite fast by just diffing the project.xml to one that is working...

At home I'm struggling with setting up a new linux box on some new hardware that probably got me excited a tad too much: default backport of the 2.6 kernel image for debian-woody will just randomly reboot my box (the sarge distro does the same). Over some randomly googled and vaguely similar forum posts I got the hint to compile the kernel myself with disabled PNPBIOS. More cryptographic talents got me to actually build it by tweaking .config to exclude some drivers that seemed to use too much stack. And now the only next thing I need to figure out is how to actually get my new network device up and running (module seems to be tg3, that and 8139too I've selected to be included in the kernel, don't ask why). After that I hope to be checking if the other one and the USB still works correctly. After that I could really get into doing the stuff I needed to do :-(

Where does this put us? I'm quite sure our beloved Cocoon will often make the same mistakes, remaining 'oysterly' sealed to anyone but those that almost devote their life to finding the pearl inside... Does this remain the last big challenge for open source in general, or is this where the commercial service offering around it naturally fits in?

Anyway, in terms of self-help I'd better check out how I can get some more serious logging out of maven for cases like this. This evening I'll get into the quest for some pointer to installing, testing, checking drivers for the linux 2.6 kernel for debian woody... whish me luck translating hints, ideas and random clues... How did people do this before Google?

Adrian poses the test-question for the real value of unit testing.

There was no hesitation on my mind: "grab those tests" (even if that means you loose that code). Some argumentation and association:

• (Executable) Test (-scenario')s contain the formal interpretation of the informal requirements or expected features. Delving through the nuance of written text, cutting the knots and making the decissions is in there, and that *is* the time consuming part.
• I even associate it to some personal interpretation of cluetrain: true invention is not in formulating the answers, but in asking the right questions. (Well cluetrain would probably just state that you have to be out there, listening to the questions. And associating even further: IMHO the hard-core anti-pattent guys pretty much chant a variation of that same theme.)
• Finally: Good code never stays around anyway: it has to be changed and lived through. Good code happily accepts to be replaced by better code.

Well, the man still does it... check out this weeks series... you'ld have to admit the brilliance of the term "near-sighted visionaries".

What does one take in the morning to have such things pop up in your head?

Some interesting recent reads:

• Bertrand on rhino shell
• Stefano on Semantic web specs
• Sam with some tests on URI equivalency (and more by clicking through the comments...)
• Observations from Paul Graham via Brian