How Very 1998 of Them

If you've read my blog for a while, you know that I've long since left GotDotNet for SourceForge. Generally, I've been more happy there, particularly because I far prefer CVS to the crazy contraption GDN has, but not all is rosy. To start with, I find that during the middle of the day, SF has lately been slow to the point of unusability. This is particularly painful when I'm trying to use the bug and feature tracking pages, which require several clicks to get what I'm looking for. Each click can take as long as 30 seconds.

At times I've thought that maybe I should just set up my own bug database. But then I'd have to evaluate the options, pick one, and then maintain it. Bleh. Still, it might be better than having to wait half a minute for each page to come back. Then, the other day, I stumbled across this, a feature of SF that lets you get the entire contents of a tracker in “XML” form. (More about the quotes in a second.)

Brilliant! With this, I figured I could suck the bug and feature databases onto my machine, then use Excel or InfoPath (if I ever figure out InfoPath) or whatever to browse the database quickly. I can't do updates, but often times all I want to do is read through a bug description or do a quick search, and a local export is perfect for that. So I sat down to automate download, got done with that in a few seconds (gotta love wget), and then went to load up the FlexWiki bug database in Excel.

XML Parse Error.

WTF? I ran it through one of the XML utilities I wrote, and found out that there was an unescaped “smart quote” in the text. Disturbing that it wound up in the export, but oh well - three seconds with “find and replace” fixed that. Fire it up in Excel again and...

XML Parse Error.

OK, now what? Well, it turns out that the smart quote issue was just the tip of the iceberg. Here's an exerpt from the exported file that shows the problem in all its glaring obviousness:

<detail>Produces this output (first </ol> not needed, second
opening of <ol> not needed).  If that was fixed then the
incorrect double <ul> should also be fixed (single <ul>)
as they would be no longer necessary. BTW:  also seen
here the unnecessary blank lines
</detail>

Note the numerous problems with this. Here it's unescaped HTML tags being produced verbatim, but unescaped & and < characters (not to mention the smart quotes) litter the export. This is a classic sign of XML being built via string concatenation, and it renders this export virtually useless for consumption - all the dangling close and open tags completely destroy the ability of any reasonable XML parser to work with this document. I would have thought this sort of thing went out with go-go boots, but here it is, right in my face, in 2005.

Sigh. It's a fairly simple fix to process the document with custom code to escape the “XML” well enough to be able to work with it, but I shouldn't have to. The moral of the story here is that if you find yourself doing something like this:

xml = “<foo>” + fooContents + “</foo>”;

then you should lose points on your programming license.

Beam Him Up

James Doohan, the actor who played Scotty on the original Star Trek series, died Wednesday of complications related to pneumonia. He was 85. I think it's safe to say that the chief engineer on the Enterprise was an iconic figure to a pretty good portion of our profession. I know for my part I quite often employ his trick of multiplying all my estimates by four. It's funny, but even when you tell people this is what you're doing, you still look good when you finish in half the time you said it would take you.

Hats off to Mr. Doohan for helping to create such an unforgettable character.

Convergence

As part of my undergraduate education, I spent a fair amount of time programming in Scheme, which is a dialect of LISP. At the time, I didn't really appreciate how truly powerful LISP is, but in the intervening years, as I've seen languages like C# and Java grow up, I've made or heard the comment “Yeah, LISP already has that” enough times to make me consider trying to program exclusively in LISP for a while. As was the case with my self-imposed switch to Test Driven Development, forcing myself to use a new technology is guaranteed to be a great way to learn something. The kicker, of course, is that I'd really miss the .NET libraries - at this stage of my career writing your own file IO routines is only fun for about ten minutes, and learning new ones is only slightly more fun.

Not that that's going to stop me from learning Ruby¹. You've probably heard the buzz around it lately - I certainly have. Buzz I can generally ignore, but when smart people like Brad get excited about something, I generally try to get around to looking into it sooner or later. Particularly when Scott raves about Watir, and I need something that looks a lot like that for several projects I'm working on. So yesterday I started to work through a pretty good Ruby tutorial on my way to playing with Watir, and I thought to myself, “Man, this looks a lot like LISP's child by a shell script mother.” Not the syntax - there Ruby and LISP are pretty different - but in a qualitative way that I have a hard time pinning down...they just “feel“ similar in how they deal with programming abstractions at a high level. I don't know: it's hard for me to express given how little Ruby I've done and how little LISP I've done lately.

Anyway, this morning I'm flipping through my aggregator entries, and I see this post from Pinku Surana about how it would be relatively easy for someone to knock out a LISP.NET implementation. Combine this with the fact that I'm basically between gigs right now, and I think the planets are aligning - it seems I'm being directed to learn a higher-level language. I just need some flaming letters on the mountainside to be sure. :)

---

1. Although it looks like there's a Ruby/.NET bridge - have to check that out at some point.