Just sitting outside, having a drink, just watching the world pass by...It really has been, and keeps on being, a splendid way to pick up interesting people :-)

This evening my new favourite information game (to be combined with real working in fact) gave me this, adding these two:

• On the Goodness of Unicode
• Characters vs. Bytes

to my list of things I will read when old-fashion-traveling (aprox 9 hours: car-train-boat-bus-subway) to London on the day they are cleaning the Chunnel and thus are not operating the EuroStar (sigh)

Bertrand looks in his crystal ball and sees what this year will bring...

So I got into the example of the much cited wiki-page, and have been poking around a bit in the code here and there, a lot more to investigate, and hopefully be doing it soon...

I've somewhat set the original existential feelings asside and went in through the door of pragmatics... still I'ld have to conclude that I'm missing some more application-object oriented contracts in the whole of Cocoon... and it's quite well reflected by the /* FIXME */ remarks lingering in the code here and there... How are we to 'address' business objects that need to be influencing the cocoon pipeline?

See, if your pipeline needs to mingle itself with some xml or xslt there is the wealth of cocoon: and whatnot stuff to declare in the @src's of the sitemap... if what needs to be sliced in is a true Java Object (be it bean, form-model, js wrapper object, continuation,...) then suddenly the nice and obvious addressing scheme is to be replaced with mysterious (i.e. conspired behind the controlling back of the sitemap) strings as Map keys into (pick randomly one out of) Environment, ObjectModel, Request and Session... [and euh, "bean-dict" and "kont" are quite inspirationless choices indeed :-)]

It's too vague as an idea, but maybe some source of the kind object: could be giving access to an object space declared by the sitemap (for reading and writing).... of course current sources are quite targetted to being wrappers around inputstreams...

Or am I trying to compare apples with pears?

Mmm, Maybe just the definition of clever 's should tackle that?Just have to sit and think some more...

In the mean time, actively hoping Betrand's ball is right...

You know, this blogging is realy nerds only.

Patrick send me this article. It's about the big why question again.... some answers popping up:

• ... indeed just because we can. -- To boldly go where they can't even beam you up.
• ... just for the fun ! -- The reason I like most.
• ... since we all happen to do it? -- The self fulfilment theory.

So, how is my mental health rating if my immidiate association with the article was in fact Julie Andrews?

Getting into my climbing gear for today...

A young dad and a digital camera...

Enjoying Rik enjoying himself enjoying his daughter...

Yawn.

I was lagging behind (10th April), but then again: I only found Bertrand yesterday in my list of 'related sites'. He picked up the topic from cocoon-dev mails in half february already, adding these interesting quotes to the simplicity theme:

• "Perfection is achieved not when there's nothing more to add, but when there's nothing left to remove" -- Antione de Saint-Exupéry (did notice this quote before on Sylvain's weblog of course)
• "things should be made as simple as possible, but no simpler" -- Albert Einstein.
• "I'm writing you this long letter because I lack the time of writing a shorter one" -- Blaise Pascal

*update* And an other late entry from Sylvain:

•  "Simple things should be simple, complex things should be possible" -- Alan Kay (the same guy mentioning "The best way to predict the future is to invent it"

In fact, who was the one saying 'less is more' ? Ah, the architect pointed to by memories of Barcelona.

Hm, I remember me and my wife finding The Pavilion boring :-) Probably holiday life in Barcelona was already simple enough?

A new one in the baby series: MIT joined the world, yesterday-evening. This baby-girl makes the score slide back to 6-2 (boys vs girls since I started keeping up the score) That score is expected to run back to 8-2 before the end of the month by the way: strength to Karen and Gladys.

Knowing, Rik, there is a fair chance you'll be able to read all about Mit in his blog, as soon as he finds his words back...

Just to let these two indepedent postings meat again :-)

Upon general request, another Java mind-puzzle. Try to predict what this one does:

14 public class Main2 { 

15 

16 public static void main(String[] args) { 

17 TestImpl ti = new TestImpl(); 

18 ti.act("Me"); 

19 ((Test)ti).act("You"); 

20 ((Testje)ti).act("Him"); 

21 } 

22 } 

23 

24 interface Test { 

25 public void act(Object o); 

26 } 

27 

28 class Testje { 

29 public void act(String s){ 

30 System.out.println("String - Base: " + s); 

31 } 

32 } 

33 

34 class TestImpl extends Testje implements Test { 

35 public void act(Object o){ 

36 System.out.println("Object: " + o); 

37 } 

38 public void act(String s){ 

39 System.out.println("String: " + s); 

40 } 

41 }

Did you predict this?

String: Me

Object: You

String: Him

If you did, then you are aware that overloading in Java is resolved at compile-time, while the run-time late-binding kicks in (only) in cases of inheritance.

There again is a fair amount of astonishment in this case, so I'ld like the setup be avoided, however I'm still doubthing on how to translate this knowledge into some general advice. Currently at:

Do not introduce overloaded versions for methods imposed on you by the interfaces you implement. You should in stead consider putting the overloaded version inside the interface itself. See it as ownership: the interface introducing a method name claims all rights on that used name.

This one bit me a long time ago, I just happened to remember while blogging the other one down... kind of trauma triggered memory :-)

By the way: tomk was so kind to point out that Effective Java has much more of these listed. My current Java must-read is the ever dull (but so right, and complete) Java Rules.

Found Fishbowl through my Google Relevance link today and found well expressed shared neurons.

Careful considered subclassing combined with helpfull overloading can easily lead to this:

java.lang.StackOverflowError 

 at java.lang.String.(String.java:422) 

 at java.lang.StringBuffer.toString(StringBuffer.java:1225) 

 at test.TestSub.act(Main.java:23) 

 at test.TestBase.act(Main.java:36) 

 at test.TestSub.act(Main.java:27)

 at test.TestSub.act(Main.java:23) 

 at test.TestBase.act(Main.java:36)

....

Code snippet to play this game at home:

 8 package test;

 9

14 public class Main {

15

16 public static void main(String[] args) {

17 (new TestSub()).act(5);

18 }

19 }

20

21 class TestSub extends TestBase{

22 public void act(int i) {

23 act(""+i); //changing this to super.act(i) solves the problem!

24 }

25

26 public void act(String s) {

27 super.act(s);

28 }

29 }

30

31 class TestBase {

32 public void act(int i){

33 System.out.println(i);

34 }

35 public void act(String s){

36 act(Integer.parseInt(s));

37 }

38 }

Lesson to learn:

• If you have overloaded methods in a class that is to be subclassed (not final) then you should make sure that the javadoc going with it clearly states how the internal overloading is done.
• If you are overriding methods, always check the baseclass javadoc for overloaded side-effects like this. And delegate to super instead of to an overloaded version on the same level.

By the way I got to learn this the hard way making my own XMLFilter with overriden: XMLFilterImpl.parse(String SystemId) AND XMLFilterImpl.parse(InputSource input).

The resolution is snap, the insight is immediate, the bite was nevertheless unexpected.

Since we mentioned lately we should start the queste for simplicity, I just wanted to share where I get my inspiration from

• For one: "Shaving helps": Ockham's Razor
• And often used in software mids: The 'Principle of Least Astonishment'!

Hey, Wikipedia links them too, plus making the great re-wording to 'principle of maximum boredom' - LOL

In any case to me it means: reduce the amount of 'arbitrary complexity' as Frederick P. Brooks Jr. defines it in his classic No Silver Bullet. (That and more goods by the way in his must-read: "The mythical Man-month: Essays on Software Engineering")

One practical way of getting to it is for sure to reduce the size of your public interface. Hide behind that Facade, reduce the number of verbs, and achieve the lowest SURFACE-TO-VOLUME Ratio (as explained in the Selfish Class) you can.

In fact it has lead me to the rule of the billiard balls: the contact-surface between your implementation classes should be likethe one between billiard balls: points, and not the big, even concave surfaces of two sponges hitting each other... "Let your classes be billiard balls!"

So, yeah, we could all get bored to death, but I would somewhat rate it higher then getting mad of frustration on the where?, what? why? of the next API to grasp.

Just had to link up this, for a friend with a particluar fondness of NPE's.

Classloader fun! This piece of code: (snippet from my XMLChainTask.java)

log("test : " + mpoObject.getClass().getName());

log("test : " + XMLFilterType.class.getName());

log("test : " + (XMLFilterType.class == mpoObject.getClass()));

XMLFilterType mpoFilter = (XMLFilterType)mpoObject;

kept on giving me:

test : XMLFilter{test([Marc=Portier])}

test : org.outerj.xml.filter.ant.XMLFilterType

test : org.outerj.xml.filter.ant.XMLFilterType

test : false

And the odd ClassCastException from the last line of code of course...

The only way two classes with exact names can be so 'different' is when they are loaded by different classloaders. The different classloaders is caused by ant looking at this:

The classloader that created the XMLChainTask.class ended loading also the refered XMLFilterType.class and thus resulting error...

Snap ant code check comes to the rescue... inside org.apache.tools.ant.taskdefs.Definer.java there is this little hint to find:

How come even this gets more referers? (thx to freshly found Joeri)

• Gordon Weakliem
• James Strachan
• Uren.Dagen.Nachten (Joeri Cornille)
• Chris Winters
• manero.org (Tony Collen)

When I talked about the relevance of Knowledge (4th bullet), I wasn't fully aware that I was striking the nerve of 'The Second Superpower', regardless of how you define the term. The fact that meaning can be washed out becomes a sudden side effect of just manufacturing serendipity is quite striking.

I have to thank Sam for pointing out the relevance of this.

Bruno just pointed me to this:

"Amazon has both SOAP and REST interfaces to their web services, and 85%of their usage is of the REST interface."

Or was I stating something similar lately about the Slammer incident?

The real funny thing is, that the one pointing me to the article stressed on the "accountability" and "hostages" words and jokingly said he thought I'ld written the article.

Gosh, I even remember installing NT4 with a pile of +30 diskettes :-)

"Memory is a dog, randomly deciding to go and lie down somewhere." - Cees Noteboom (free translation from my memory of this Dutch author)

Well, I just might write those books one day...

but I will never write up a site with that less spelling mistakes, and so clear reading paragraphs. ;-)

Applause to Steven pulling it off, and rephrasing my minor content injections to something readable.

And a late thx to Kika|Mosh for the artwork/skin.

Game: find were this link should be added :-)

Our favourite google employee is carelessly throwing clues around. Jummy. Do you also wonder about the synaps trigger to include the Lake Tahoe picture?

Karma ends up in my shared memory again...I Remember making it to the 3rd round of the 1988 version of the Vlaamse Wiskunde Olympiade. I however do not any more share the braveness to face this years questions :-)

Quick scan of the rest of the wvo- site:

• Scary: the only 2nd round 1988 questions I seem to remember | recognise are the ones I failed. Ah, failure still haunting my dreams after all these years... :-)
• Interesting article (dutch though) on the Gulden Snede
• Humpf, no 3rd round questions posted...

Just checking out Rik on Mr. JBoss and reaction on the OSS debate. Hey, I knew we were thinking the same all along :-) Being on a somewhat tight schedule (XMLEurope Tutorial submission deadline) I'll keep it to some short 'here-here':

• I will write a book! Still waiting for the inspiration though :-) Should be Poems or a novell in any case, ... some escape from this technical stuff at last...
• Very true: There is no 100% cluetrain... Remember there is no truth. Even Mr. Bruggen is not 100% Rik, he's to a large part Katleen (wife), a bit his employer, I even think there is a part of me in there (and vice versa). Cluetrain just _is_ like so much other things... and you decide when it happens (to you) on a very granular basis. I run Windows 2000. I use MS Excel (and not only when it's coming out of the POI in xReporter). It runs next to XXE (great stuff by the way), cygwin, Eclipse, Apache Ant, Apache Tomcat, Apache Cocoon, Apache Forrest, ...
• Yes, there is nothing wrong with "paying for not knowing the details". I have to agree, my statement should have been "paying for not being alowed to knowing the details". We all know that (free | open)!= gratis , paying (with money and some faith) is a sensible way of keeping focus on what you really want to be focussing on (and it doesn't matter if you 'pay' a colleague or another company). The transaction should however not hand over your indepedence, nor should it make you think you are not any longer responsible yourself. (Remember the Slammer Worm? Microsoft posted an advertisement later on stating 'sysadmins should have known there was a patch available' Get it?) Keep in mind: "Caveat Emptor", and in the software world that means: hire services rather then buy products, and keep control (in my book that means: make sure you are alowed to know anything you might need). At least you should be ready for the next insourcing-outsourcing-insourcing cycle?
• JBoss organization uses open source as R&D and recruitment... Outerthought is a commercial organization as well, much of what we do is around a fair bit of knowledge. Keeping that up to level were we can help out and make a difference is what we achieve through the conversations at Apache.org. It is not a cheap investment. Knowledge again is not about 'eternal right or wrong' it is about what matters, what is talked about, what is driving people? Here and now. And rethinking that to maybe come across what was overlooked. Remember Google PageRank"? Maillist threads with no replys might be full of 'truth', they're just not as relevant as the others. The missing meta-data on your pages is provided by what is in between my 's. On the mailinglist there is someone else to complete your thoughts, or there is no one, showing the irrelevance.
• The question is not in creating better tools. Simplicity should come from the framework. Great thought to cary along...

But be sure about when to wish 'Happy New Year'.