( ? , qUeStIoNMaRk )

Joel wrote, as usual, a thoughtful and witty article on the web, standards, interoperability and the upcoming mother of all flame wars; this is a must-read for everyone concerned with web-related software development (web designers, web programmers, information architects, marketeers…) .

As usual, the idealists are 100% right in principle and, as usual, the pragmatists are right in practice. The flames will continue for years.

Joel goes into a lengthy explanation, driven by an extra-terrestrial catchy case study, of what are the possible “cardinalities” of “market standards” (One-to-One - all is fine and simple, One-to-Many - yet fine, Sequence-to-Many - a story of pain and backward compatibility, Many-to-Many - you know, PurePain ™), why a standard without a reference implementation it’s not that standard, and why in the long run being conservative in what you do, and being liberal in what you accept from the others potentially ends in deployment issues kicking your conservative yet liberal butt. In the meanwhile you get also acquainted with some real-world compatibility issues between rabbis from different ultra-orthodox communities:

If you’ve ever visited the ultra-orthodox Jewish communities of Jerusalem, all of whom agree in complete and utter adherence to every iota of Jewish law, you will discover that despite general agreement on what constitutes kosher food, that you will not find a rabbi from one ultra-orthodox community who is willing to eat at the home of a rabbi from a different ultra-orthodox community. And the web designers are discovering what the Jews of Mea Shearim have known for decades: just because you all agree to follow one book doesn’t ensure compatibility[…]

As a very brief personal memorandum: Real Standards must have Real Reference Implementations (because “reality siphons off excess complexity“¹) and although Postel’s Robustness Principle is (imho) still much valuable for the wide spread of the internet/web it has been able to sustain so far, it should be carefully balanced - “in medium stat virtus” - with having very, very strict standards and “components” positively obnoxious about pointing them all out to you; maybe we (as developers/engineers) should resort to some sort of “carrot and stick” principle.

NOTE ¹: The full citation from David H. Gelernter’s Mirror Worlds (a wonderful and fascinating book narrating a vision of computing and information of extraordinary elegance - that is by other words a good combination of simplicity and power) is:

“Information structures are, potentially, the most complicated structures known to man. Precisely because software is so easy to build, complexity is a deadly software killer.
The same problem exists for hardware machines, but it lacks comparable significance. Physical reality is the overflow valve that siphons off excess complexity before the whole system blows.[…]”.

Very brilliant movie, just a few memorable quotes.

A boy is given a horse on his 14th birthday. Everyone in the village says, ‘Oh how wonderful.’ But a Zen master who lives in the village says, ‘We shall see.’ The boy falls off the horse and breaks his foot. Everyone in the village says, ‘Oh how awful.’ The Zen master says, ‘We shall see.’ The village is thrown into war and all the young men have to go to war. But, because of the broken foot, the boy stays behind. Everyone says, ‘Oh, how wonderful.’ The Zen master says, ‘We shall see.’

“These things happened. They were glorious and they changed the world …
… and then we fucked up the end game”

(Editor’s note: pretty much fucked up - someone would dare to say)

more quotes from Charlie Wilson’s War…

Charles Nesbitt “Charlie” Wilson (on Wikipedia).

Just received via my diver club’s newsletter (SubAtlantide Cesena) a hint about storing on your cell phone as ICE (ICE1, ICE2, ICE3, … et cetera) the phonenumbers to call In case of emergency. On a first sight I thought: “Yeah that’s the way it should work!”, but after regaing control of myself in spite of my geekness, I figured an emergency situation: the last thing emergency personnel or someone giving first aid is going/would like to do is to figure out how your mobile phone works. Carrying a card with emergency contacts details in the wallet would be definetely better.
I googled for “ICE in case of emergency” to found out if that was a hoax. So I found ICE on wikipedia:

The ICE (In Case of Emergency) program was conceived by paramedic Bob Brotchie in May 2005. The idea behind the program is to enable first responders (paramedics, firefighters, police officers) to identify people and contact their next of kin to obtain important medical information.

and a link to the article (in italian) “ICE nel telefonino, salva davvero la vita?” written by Paolo Attivissimo, a wellknown italian blogger and IT writer, suggesting a “Ink&Paper” solution:

segnare su un cartoncino, su una tessera plastificata o su un ciondolo da tenere al collo le indicazioni d’emergenza. Questo permette di indicare non soltanto i numeri da contattare, ma anche informazioni forse più vitali, come il proprio gruppo sanguigno, eventuali allergie a medicinali o terapie in corso

Bottom line: If you feel comfortable storing some ICE info in your phone this is not a bad idea at all, but you’d better not to rely solely on it; carrying a plate or a card with the same info in your wallet/pocket is more pragmatic and effective.

Every now and then I find pleasant tasting this small bites of wisdom; those I appreciate most are brief, puzzling and enlightening. I find it an handy way to keep always with me the lessons I valued most, my believes, or simply my “humanitas”. A stoic would have said “Omnia mea mecum porto” (I carry with me all my belongings).

Every now and then I would be pleased to share some.

The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man.

George Bernard Shaw

I experienced another small enlightenment, linux administration related, when I discovered bash completition. This feature proves itself useful when you use quite often the shell: during system adminstration, software compilation/testing/deployment/whatever. To enable it, edit your ~/.bashrc file (where ~ means your home directory, e.g. /home/mfabbri), with your favorite editor and uncomment the lines following the one which states # enable programmable completion features .

More extensively from a shell (or a terminal window, as gnome-terminal):

$ vi /etc/bash.bashrc

find the lines :

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
#if [ -f /etc/bash_completion ]; then
# . /etc/bash_completion
#fi

and change them into

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if [ -f /etc/bash_completion ]; then
. /etc/bash_completion
fi

Logoff and login from your shell (if you are using a terminal, as gnome-terminal, restart it) , and you should be able to use completition not only for command/file names/program names, but also for program commands, for example digiting apt-get and pressing the [TAB] key should produce on the output a list of available actions as:

autoclean clean install update
build-dep dist-upgrade remove upgrade
check dselect-upgrade source

It works for many other programs, as cvs, subversion, darcs, ant, maven, java et cetera.
Java needs a special mention, use this feature with care, cause it scans the whole classpath searching for classes, so when it is dealing with huge classpaths it could slow down things a little.

As you may have noticed, you could also enable this feature system wide editing the same way the file /etc/bash.bashrc.

After man-months of hard fight between me and email clients, I discovered (through the kind contribution of a jini-users mailing list member) that long urls, that usually get wrapped by email clients, can survive without being wrapped if you put angular braces <> around them.

Simply Beautiful.

Getting the purpose of a software system right is an evergreen theme in software engineering, and one of the fuzziest issues in this beautiful discipline. My friend Marco some times ago posted a great toon on the subject, with a brief and sharp commentary.
On sunday Dilbert posted an awesome strip on the tensions between engineers, customers and requirements:

• engineers want customers to express requirements clearly, possibly in a non-ambigous language (a set of differential equations wuold be perfect ).
• customer wants engineers to guess what they are thinking their problem is.

This would seem a self-referencing non-terminating problem (sounds huge), but Dilbert has the perfect solution:

• As the designed software can do whatever the engineer designs it to do, the engineer should design a software to tell himself customer requirement.

Striking clear, not?