Dammit. FireFox had a real go at my sanity today. It seems, empiraclly anyway, that if your FireFox extension's RDF file is called anything other than install.rdf, then when you close the session it's loaded from, FireFox nukes your extension.

This is annoying, at best, when that's your working copy. Thank goodness for source control.

Another weird one last night. Incredible degree of detail as always.

I decided to relocate to a nearby globular cluster to pursue a woman I was attracted to. She stayed on a deserted planet, called Land's End, in the region of said cluster, and there was enough commerce in the sector that I figured I had a reasonable chance of finding work.

I remember distinctly arriving on a planet, a little confused about how I got there since I didn't have a passport. Shortly thereafter I was approached by a stranger who presented me with my passport and some local currency (no idea why). I remember queuing for a while to buy tickets out to Land's End, and at one point standing outside overwhelmed by the sheer number of stars in the night sky (being in the center of a globular cluster, this was to be expected).

The really disturbing thing about way out dreams like this one is how real they feel and how dislocated from reality I feel when I wake up. It always take me a few hours to reintegrate after one like this.

Came home yesterday with a nose that was killing me. Odd on its own because I don't normally suffer from things like hayfever. So I took two Advil CS tablets.

It's the only way to fly.

Perhaps that contributed to my weird dream last night. Let's see if I
can summarise this without laughing. I went for a job interview, which meant I had to dress up. I remember being worried that my current boss would notice and ask questions. I accepted the job and started the following day. It turns out the "offices" were our old place in Joburg. In addition, my new boss appeared to be my standard 6 (grade 8) Maths teacher.

The job paid the same as my current salary. I remember double checking this quite distinctly. Brief segue to a mountain biking scene which I can't explain and seemed totally unrelated to the rest of the dream (although there was a small tie in later on). The work itself was a little less obvious. It seemed to involve a large selection of drugs, alcoholic beverages and small chocolates, but not for consumption. I never really found out but I was either supposed to sweep the big black (CIA style) SUVs for them and collect them, or plant them in the cars. My colleagues refused to tell me. At one point one of them seemed to get quite mad and charge me only to all on his face when I sidestepped and tripped him. He seemed upset that I'd cut him off while mountain biking (I told you it would tie in).

No. I have no idea.

I've been playing with a little side-project. It's a FireFox extension that presents a simple UI to users, and makes requests on their behalf (AJAX-style) in response to various interactions. It's basically an in-browser rich client. In the process I've had the chance to get a closer look at XUL and dust off my JavaScript skills.

Some first thoughts.

Basically, the model is not much different from DHTML (HTML+JS). This in itself isn't a bad thing, but it does mean you're not far away from much of the (organic) clunkiness that model has inherent in it. XUL basically provides a richer set of UI controls that HTML does (perhaps a more apt comparison is XHTML since it's an XML dialect, whereas HTML is, well, a loose collection of accreted XML-like tags). Unfortunately, many of the problems in how HTML (and to some degree this is still true for XHTML) is handled are still present. It seems like very little validation, beyond wellformedness and limited tag checking, is actually performed. And there seems to be some sort of attempt to "degrade" gracefully. Unfortunately, all this means is that when you cock up and get something wrong in your XUL scripts you experience weird behaviour that seems almost correct. Two examples bit me. One was duplicate (nested) treeview tags. This produced a squashed listbox with the correct column titles but with broken event handling. Another was specifying the wrong width and height attributes for a vertical splitter control, which resulted in all of the surrounding controls being suppressed.

Frankly, I'd rather just deal with errors than be forced into a binary search to determine what I've cocked up. And there's no good reason it can't be done.

JavaScript still has a number of oddities. The biggest of these is using object method as callbacks. Passing this.foo as a "function pointer" breaks because this is evaluated in the context of the caller, and foo generally doesn't exist on that object (assuming it's an object). So you're forced to do stupid things like assign this to a local and write an anonymous wrapper function that invokes the correct method on this new object handle. Broken.

In general I'm not overly impressed. It seems pretty cool, and it's reasonably easy to use XUL and JavaScript to produce some decent looking UIs but I don't see how they can possibly scale to larger projects.

This week's prize for idiocy goes to the V&A Waterfront here in Cape Town.

We had dinner there this evening, after failing to purchase tickets for a movie we were going to watch. It's a pretty standard Capetonian paid parking scenario: ticket at the entrance, pay before you leave. Somewhat more heftily priced, but otherwise pretty standard.

Except that of the five pay stations at the exit we used, four don't accept the "new" R10 or R20 note. These notes have been in circulation now for at least a couple of years, so they're hardly new. And the average parking ticket at the Waterfront will set you pack at least R10, so this strikes me as a completely ludicrous state of affairs.

Fucking idiots. There are no other words for it.

This caught us today and it's somewhat obscure so I figured I'd write it up for others on the off chance it saves someone some time. It's so weird I had to haul out irb and confirm it in isolation.

In summary, if a block 'local' variable shadows a variable in the containing scope then it is the variable in the containing scope. Take the following code as an example

   ...
   a = 42
   [1, 2, 3].each { |a| }
   puts a
   ...

I fully expected this to print out 42. It doesn't (try it). Instead, it prints out 3.

Why? Well, it seems as if a in the each block doesn't merely shadow a in the outer scope. When you reference a within the each block you're actually referencing a in the containing scope. Since the each block in this case simply sets a to each member of the list [1, 2, 3] a ends up being set to 3.

This makes a weird kind of sense when you think of the block as a closure. If you reference a variable defined in the containing scope that isn't one of the block parameters, you 'capture' that variable, and modifying it means modifying the original variable. The following example

   ...
   a = 42
   b = 10
   [1, 2, 3].each { |a| b += a }
   puts b
   ...

prints out 16.

I'm not yet sure if this is deliberate, or a bug in the ruby interpreter. I can see how some might argue it's legitimate behaviour, but it definitely violates the Principle of Least Surprise.

Finally, someone's put EC2 to good use.

Amazon EC2. Saving the world one FPS at a time.

This weekend Neil married his girlfriend of some time (they've been together almost as long as Andria and Riaan were) finally made it official.

The wedding was held in a small church in Kalk Bay, and the reception, oddly enough, was at Monkey Valley, the same venue where Andria and Riaan held theirs. Is two samples statistically significant?

This also marked the first time in some years since almost everyone in my immediate family was in the same country at the same time, along with recently-acquired and soon-to-be-acquired significant others. The only person missing this time around was Duncan. And despite all that we still failed miserably at getting everyone together for a single photo.

Congrats Neil and Shona, all our best for the years ahead and, Neil, consider yourself pwned.

You know. There was a time when I really enjoyed writing Java code. Indeed, if that weren't the case I'd hardly have invested the time I did writing Rox.

But these days I'm finding myself resenting it more and more (although to be honest I don't think Java's directly to blame).

If you've ever had to spend any time with JAXB, Axis, WSS4J (or WS-Security in any form) then perhaps you'll understand where I'm coming from. Part of it is the HammerFactoryFactory syndrome, which seems to proliferate in particular amongst the XML related Java libraries.

However, I think the rabbit hole goes deeper. Many of the Java XML related APIs are chasing some of the most "flexible" (which is usually just a synonym for complex) specifications ever produced. WS-Security and XML-DSIG with the associated XML canonicalization are cases in point. XML Schema is another. The latter is so complex that one XML.com article (which ranks pretty high on Google searches relating to XML Schema) suggests restricting your use of it to a substantially smaller subset. And at least one of the arguments for not using a particular feature (extension by type restriction) is based around the fact that that part of the specification is so complex that no validators (at the time of writing) enforce it. Anyone else hearing warning bells?

WS-Security is another great example. The idea is a single, well defined, approach to logically signing or encrypting XML documents. The idea is that you should be able to do this at the logical level, freeing systems from dealing with nasty things like encodings. Unfortunately, this means everyone has to agree on what the XML looks like before they can process it correctly. Enter XML canonicalization. Take a look at the spec. Now granted, this deals with dozens of difficult edge conditions introduced because you're dealing with XML, which means you're dealing with Unicode. But I'm yet to be convinced that this obeys the 80-20 rule. Sure, there are potentially cases where this is necessary, but the common cases would be well served by far, far simpler solutions. And given the complexity of implementing some of this stuff (or just figuring out how to use libraries that all to often reflect the underlying complexity in their own APIs) most are: eventually you stop, realise it will take an hour to roll your own solution versus a couple of days to get the "correct" solution working, and you give up and go trail blazing.

At the end of the day it all boils down to one thing. These "technologies" sound good on paper but break down in practice. Why should you have to spend days, or weeks getting the basic infrastructure for a web service working? Why should you have to ship a few megs of libraries in your client just to construct signed requests? What, in all honesty, are you winning?

I'm betting at least one person reading this is thinking something about interoperability, or reuse, or some such nonsense. Sure, in theory a shared, language and platform neutral specification means interoperability. But I'll tell you what happens in reality. In reality, these specifications are so overly general, so complex, that there's either no implementation for your language of choice, or there's only one or two.

Which means one of two options: stay with your language choice and roll your own, or switch to a language which has an implementation. The latter tends towards homogenous systems (at least at the language level) at which point interoperability becomes a moot point.

And anecdotal evidences suggests that the implementations of these specifications tends themselves to become monsters. Apache WSS4J (an implementation of WS-Security) is a great example. I challenge you to figure out how to use this to produce a SOAP request that's unencrypted, signed using an RSA private key, and includes the X509 certificate in the request in anything under a day. Even with Google handy. (And once you've done that swallow the fact that you can only make a single request with given credentials at a time because, guess what, credentials are static members.)

That last point deserves to be expanded on. Another reason I'm hating writing anything in Java right now probably has something to do with the frequency with which I've been forced to deal with Apache libraries. I cannot convey what a steaming pile of shit these libraries generally consist of. I'll leave it to Hani to do that. Some of the most blatant evils these libraries are guilty of include:

• Relying on external files for configuration. This forces you to cart these files around in some form within your own applications, often all sharing the root directory (assuming the library's even using the ClassLoader to load these files). Often these files are just an excuse to use XML somewhere. This makes it almost impossible to produce a clean API. Sun's JWSDP is guilty of this in a number of places too.
• Singletons/shared static data preventing multithreading. This comes up in a number of libraries and isn't limited to WSS4J. When I discover stuff like this I check Google to see if the community is up in arms about the kind of shit they're subject to. It's sad how often they haven't even noticed. A thread started by someone who did notice the WSS4J limitation I mentioned earned a response of "Try our latest release, we've done some refactoring and maybe this has been addressed" as if shifting some code around might somehow magically address bad design.
• A complete and utter lack of any useful documentation. Sure, this isn't limited to the Apache projects, way too many open source libraries suffer here, but the Apache libraries' APIs are so utterly beyond comprehension in so many cases that you're forced to go looking for docs (because trust me, you don't want to spend any time in their source code).

But desipte the fact that the Apache APIs are generally terrible, they seem to have won the Java community over (I'm not really sure what that says about the Java community; nothing good I'm afraid) so you're forced to drag commons-cli, commons-logging, commons-discovery, commons-httpclient, commons-kitchen-sink etc along with you. And they tend to depend on one another so that if you're forced to swallow one or two you often end up gagging on the whole caboodle.

So right now I'm not enjoying writing Java code. Give me Ruby. Hell, give me Python, Common Lisp, OCaml you name it. Anything that doesn't expect me to pass an XML configuration file to the HammerFactoryFactory component before I've even started.