I’ve been too blown away by the horror of the sniper story to post a lot about it (I lived for six years in Northern Virginia, just a few miles from the last killing in Seven Corners). But the Slacktivist has provided some grim perspective on the identity of the killer:

“...one thing we can be pretty sure of: the sniper isn’t a black man.

.... How can we be sure of that?

The killer's vehicle is described as ‘a white, Chevy Astro van with a burned-out or broken left tail light.’

No black man could drive around for two weeks with a busted tail light without getting pulled over by police.”

Thanks to Evan, whose blog I’ve inexplicably not been reading, for the pointer.

After the big release of 1.0.3a on Tuesday, a reader in England found some bugs I had missed in the first go-round with Manila Envelope on Jaguar. Specifically, people using the software for the first time can’t post!

The problem was a result of two things. First, the problem with Jaguar requiring plain text for XML-RPC extended into an additional function call that I hadn’t investigated, one that passed a URL as one of its parameters. This particular call only happens if no successful calls to the server have been made before, so I didn’t catch it in my haste to release 1.0.3a. Once again the importance of thorough testing...

Second, I made a big fuss about the importance of separating user interaction from business logic back in February, but didn’t catch all the problem areas. This particular problem was caused by a function that returned a string value. In the first implementation, I had the calling functions make the assumption that an empty string meant an error had occurred. Only problem: if the calling function in the UI is handling error notification and I’m returning a single empty string parameter, there’s no way to provide detailed error information.

This is where I miss “pass by reference” in other programming languages. It then becomes simple: you pass in a variable to be transformed by the method, and you check a return value for success or failure. Instead, I am using multiple return values:
return {true, callResult}which means I have to use AppleScript’s copy syntax instead of a simple set. Ah, growing pains.