The Crazy XML Chart

Several folks told me today they liked the recent XML-related posts (on RDF and webservices), so I thought I should pass along the crazy XML chart that’s been floating around recently.

It has a few questionable things on it — like GIF, PNG, and JPEG — but the point is: if one were to be a master of XML, all these crazy things would be pies you’d have your fingers in.

I like XML, don’t get me wrong. It just gets overwhelming and it’s easy — often, too easy — for XML to become a golden hammer.

Apple's Asia-Pacific VP Interview:

“Coming from a Wintel world, I was pleasantly surprised to see a very heightened passion in the people who work in the company. They have the feeling that ‘I work for a creative and innovative company.'”

As a result, Ho’s management challenges are not about motivating executives. Rather, he focuses on dealing with the diverse and sometimes opinionated people whom Apple attracts: “The challenge is to manage a group of creative, passionate people. I want to harness the creative energies of every individual in the organisation.”

Java I/O Sucks Goat Ass

I’ve said it before, and I’ll say it ’till I loose my voice: I fucking hate Java I/O. All I want to do is get all the contents of whatever’s in a stream, a reader, buffer, or whatever the hell else I have a handle on. Can I just call something like the below:

String contents = new File("somefile.txt").getAllMyShit();

Of course the fuck not! I have to keep track of byte arrays, char arrays, or some stupid ass shit in a while block. I just want the God damned content, I don’t care how the JDK gets it out of there.

OK, I feel better now.

Late Night Heraclitus:

If one does not expect the unexpected one will not find it out, since it is not to be searched out, and is difficult to compass.

I’ve been thinking about old Mr. “Everything is fire” recently. I’m not sure why, but he’s always fun reading, e.g.,

  • Sea is the most pure and the most polluted water; for fishes it is drinkable and salutary, but for men it is undrinkable and deleterious.
  • Disease makes health pleasant and good, hunger satiety, weariness rest. (A fine tagline for The Gay Science.)
  • Heraclitus somewhere says that all things are in process and nothing stays still, and likening existing things to the stream of a river he says that you would not step twice into the same river.

"Is the Semantic Web Hype?":

The following statements are nonsense
“RDF is more semantic than XML”
“RDF allows us to reason concretely about the real world”
“The power of RDF is its semantic model”

I came across this excellent presentation by Mark Butler, of HP, today. It manages to explain RDF and the semantic web through concise lists and quotes from the XML/RDF world.

Watching the RDF wheel spin around in the proverbial mud has always been interesting, but disappointing. There’s an ass-load of text — or “churn” as some call it — spent explaing what seems like a simple concept, i.e.,

RDF Term Example
Predicate Created by
Object Coté

S.S. Abstraction

In the more concrete coding world, we have the concept of “over-abstraction”: basically, the design for something is so high-level and abstract that it’s useless for any practical application. Ed dubbed this concept the “S.S. Abstraction.” Usually when the S.S. Abstraction docks at your port, you spend a lot of time writing and talking about design before writing a prototype or executing any code; that is, there are completly groundless design claims made. You’d think that programmers are very scientific and numbers oriented, but after just a slight dip in the stream, you realize that we’re very superstitious, non-Baconian type people: we practically follow our own form of computational voodoo.

Back to RDF…

After reading the presentation, esp. the quotes pulled from XML big-wigs, my feelings that RDF is an example of the S.S. Abstraction in the standards world seem sound: the RDF standard appears to be evolving without enough testing for it’s usability as a technology; that is, how useful and easy it is for programmers to use RDF.

On a brighter note, it is a very young standard, and there does seem to be quite a bit of self-corrective kick-backing going on. As one of the quotes in the presentation says,

25 years ago, Ed Feigenbaum described
Terry Winograd’s work (on Artificial
Intelligence) as a “breakthrough in

I worry that web services and the semantic
web, in their reliance on effective
computational semantics are vulnerable to
the same criticism.

If I May be so Brazen: "Webservices…ugh!"

All of these concerns and recommendations are exactly what make my stomach curl when I think of webservices, e.g.,

Design the interface as a dictionary, though not as an object based wrapper around dictionaries (ie prefer a Map over a Bean). I’ve seen Python and Lisp code that does this well as they have good support for meta-class hacking; and it’s sometimes called data-driven programming in the Lisp world.

Ahhhh! To me — a type-safety, contract-based coding, OO nut — webservices are a massive step backwards into the procedural flaming swamp-world I despise.

JSR 174: Monitoring and Management Specification for the JVM:

A specification for APIs for monitoring and management of the JavaTM virtual machine. These APIs will provide Java applications, system management tools and RAS-related tools with the ability to monitor the health of the Java virtual machine as well as manage certain run-time controls…

. . .

The majority of the existing monitoring and management options and techniques are very limited, lack functionality, degrade performance, and are unreliable and non standard, leading to a multitude of disconnected solutions.

Demeter's Law Remix

I like this
version of Demeter’s Law
: “Don’t use more than one dot.” Yuh!

A longer version, and following explanation, can be found
at the Pragmatic Programmer’s site

What that means is that the more objects you talk to, the more you
run the risk of getting broken when one of them changes. So not only
do you want to say as little as possible, you don’t want to talk to
more objects than you need to either. In fact, according to the Law
of Demeter for Methods, any method of an object should only call
methods belonging to:

  1. itself.
  2. any parameters that were passed in to the method.
  3. any objects it created.
  4. any composite objects.

On a slightly related note, Zane recently emails:

Indeed, Henney suggested it himself
something like:;

you save yourself from unnecessarily having to create a
snapshot variable like:

Object snapshot =;

Yet, I maintain that the first piece of code is
actually quite dangerous. If you ever go multithreaded
and don’t explicitly protect your two calls with a
synchronization (which will degrade overall
efficiency), then you might be acting at on different
variables at different times depending on how the
iterator is coded and who has a handle on it.

To which my first response is, in the immortal re-phrasing by Kinman,
Iterator in this fashion is indeed a very bad
idea. But, what if the object wasn’t going to suddenly change state
because some schmuck-thread called next()?

Keep Returned Values

The rule of thumb I tend to follow is
that if I’m going to be using a return value from an object more than
once, I put it into a local variable, e.g.,
snapshot. This is more a code-readability issue than
anything else: it looks less cluttered. On the other hand, one could
successfully argue that it does seem to clutter up the code
more; what’s clutter and what’s not isn’t often black and white. (If you’re one of these people, you’re probably also nuts for
code like,

new DoSomething(new Date(), new String [] {"param1", "param2").execute();

That shit drives me crazy, but some folks like it.)

Query Once

On a more technical, and paranoid-design
school, note one doesn’t always know what a seemingly simple
getSnapShot() type method will do: it might be more than
an innocent JavaBean property, e.g., it might call across the network,
call into the DB, re-calculate the value, etc.

More importantly, you can’t predict what that method will do in the
future: getSnapShot() might be a simple JavaBean
property now, but someone might change it, making it more complex and
time intensive. Obviously, when making that kind of change, you’d want
to go through and check all the code that uses your new, slower
version of the method…but there’s always a wide gap between “want”
and actually doing: though good tools make finding calling code brain-dead
easy, programmer laziness often saps even the ability to right-click.


As a last item, assigning the return of
getSnapShot() to a local variable makes debugging
slightly easier: you can just inspect the local variable rather having
to get your debugger to execute getSnapShot() and show
the result. (The same goes for the parenthetical referenceless new
class instance example above.)

Traits of Testers vs. Developers (PDF)

Good testing is governed by the scientific model. The �theory�
being tested is that the software works. Testers design
experiments, as Kaner says in Testing Computer Software,
to see if they can falsify the �theory.� Good testers
know how to design experiments, and they often benefit
from previous study of the sciences. Good testers think empirically,
in terms of observed behavior.

Developing software, on the other hand, is much like
creating theories. Laws are specified and rules are applied.
Many developers have benefited from studying
mathematics. Good developers think theoretically.

Developers who are focusing on their theory of how
the software works might dismiss a bug report that describes
behavior not allowed by their software theory.
�That can�t happen; it�s not possible.� Good testers focus
on what actually happens, and like other experimenters,
keep detailed logs. �Well, it did happen; here are the circumstances.�
People who are used to thinking theoretically
have a hard time accepting aberrant behavior without
some kind of explanation. Good testers are skeptics,
whereas good developers are believers.

There’s several other good comparisons between testers and coders…and all in just 4 pages!