I’ve dusted off LazyLoad and made a few much-needed bug fixes and improvements. LazyLoad is a tiny (915 bytes minified and gzipped) JavaScript library with no dependencies that provides easy and painless support for JavaScript lazy-loading in Firefox 2.x, Firefox 3.x, IE6, IE7, Safari 3.x (including iPhone), and Opera 9.x. There are usage examples and downloads here.

Here’s how to get the latest version of MySQL (5.0.51b as of this writing) working with the MySQL/Ruby gem and the Apple-supported version of Ruby that comes with Mac OS X Leopard. These instructions are scattered around the Internets in various places, but I’m sick of searching for them every time I need them so I’m compiling them here in a single place for convenience.

First, download and install MySQL for Mac OS X 10.5 (x86). Don’t install the x86_64 build or Ruby will refuse to speak to it. If you’ve already installed the x86_64 build, backup your databases, install the x86 build on top of it, and restore your databases.

Once you’ve got the correct build of MySQL installed, pop open a terminal and run the following to install the MySQL/Ruby gem:

sudo env ARCHFLAGS="-arch i386" gem install mysql -- \
  --with-mysql-dir=/usr/local/mysql --with-mysql-lib=/usr/local/mysql/lib \
  --with-mysql-include=/usr/local/mysql/include

That should do the trick.

Earlier this month I suspected that FedEx may have invented time travel. If the tracking info on this package is to be believed, it would appear UPS has been doing some experiments of their own.

I’m convinced that the single most important factor in implementing a successful Internet video on demand service isn’t selection, video quality, or home theater integration; it’s bandwidth.

YouTube, the most successful Internet video service (at least in terms of overall usage), has gotten it right from the beginning. Their selection is limited to whatever crap users upload and the quality is horrible, but videos begin playing almost instantly and rarely get choppy.

Hulu and Netflix have also gotten this right and are successful despite suffering from a lack of home theater integration options and, in Netflix’s case, a laughably bad selection of content.

However, two players in this field seem to have gotten everything right except the bandwidth issue. Microsoft’s Xbox Live video service and Sony’s new PlayStation 3 video store both offer an excellent selection of recent movies and TV shows, many of them in gorgeous HD with Dolby Digital 5.1 audio, but both services suffer greatly from limited bandwidth.

On Xbox Live, videos often download fast enough to be watchable as long as you don’t mind waiting five to fifteen minutes before you can actually start the video. Occasionally, though, the service seems to fall flat on its face and you’ll be forced to wait an hour or more before you can start watching. Not exactly convenient when you just want to plop down on the couch with your dinner after a long day and watch a movie, but at least it doesn’t happen too often.

The just-launched PlayStation 3 video store is, in my experience, far worse. Like Xbox Live, it’s unable to even come close to taking advantage of my available bandwidth, but unlike Xbox Live, it tries to pretend that this isn’t an issue by allowing me to start watching the video instantly. Every so often the audio cuts out, then a moment or two later the video pauses (yes, in that order), and I’m forced to wait while the bytes trickle slowly in and the buffer fills back up. Then I have to manually rewind to the point where the audio cut out to hear what I missed.

Last night it took nearly an hour for the PS3 to download a half-hour standard definition TV episode (about 350MB) that cost me $1.99. The same episode is available for free on Hulu at the same quality and without the bandwidth problems. If I were less scrupulous (and I often am) I could download it from Usenet in about four minutes flat, since my Usenet provider doesn’t seem to have any problem saturating my bandwidth.

The astonishing thing about this is that bandwidth is ridiculously cheap these days. It’s surprising that Microsoft and Sony are allowing their otherwise excellent on-demand video services to suffer by ignoring such a basic component.

Jeff Atwood recently posted some thoughts on monkeypatching. Strangely, he only writes about one aspect of monkeypatching—modifying the functionality of a core language feature—and makes no mention of the much less dangerous and far more common use case, which is to modify the functionality of a third-party library.

As Jeff points out, monkeypatching a core language feature is almost always a bad idea because the changes propagate to all running code rather than just your code. This is an excellent way to virtually guarantee strange, hard to debug problems, especially if you’re writing an application that uses one or more third-party libraries or frameworks. On the other hand, monkeypatching third-party code is usually less dangerous and the effects are easier to control, since your changes will only affect code that uses that particular library.

Before monkeypatching, you should always exhaust all other options in the following order:

1. If the change can be implemented in a reasonably elegant way without monkeypatching, do it that way (especially if it’s a change to a core language feature).
2. If the library or framework you want to change is open source and your change would benefit other users, make your change there and contribute it to the project as a normal patch.
3. If neither option is possible, then you may monkeypatch, but do so in as limited and careful a fashion as you can. Make the patch obvious; don’t hide it in the midst of a bunch of other code.

In all the open source code I’ve written to date, I’ve only ever needed to use a monkeypatch once. The patch in question is in Thoth, and it makes a very small change to the way Ramaze looks for a requested static file.

I implemented this as a monkeypatch because the feature is of limited use to most other Ramaze users and would have required significant changes to Ramaze if implemented in a generic way rather than in a way specific to Thoth’s needs. The patch is very limited in its scope; it only affects the instance of Ramaze on which Thoth—and nothing else—is running.

Even so, I still revisit this code every so often to reevaluate whether it should remain a monkeypatch or be added to Ramaze.

You’re not seeing things. I’ve given the site a facelift. Fixed layout, header photos, and sans-serif fonts are out; fluid layout and serifs are in. It was hard to let the photos go, but their static widths had been restricting my design choices for a while.

According to their website and a delivery notification email, FedEx left a package on my porch today at 3:26pm. This package contained the old decommissioned Jetpants server that UPS botched the delivery of when I originally shipped it to the hosting facility two years ago. Amazingly, the package that FedEx delivered at 3:26pm didn’t actually appear until 3:43pm.

What magic is this? Has FedEx invented time-delayed invisible packaging? Have they discovered the secret of time travel? Sadly, no. They’re merely incompetent.

When the driver appeared with the package at 3:43, Felicity asked him why I had received a delivery notification email at 3:26. After joking that she should lie and tell me that she hadn’t seen the package at first because “someone had moved it”, he said that he had scanned it as soon as he was in the neighborhood to “get a jump on it”.

Tell me, FedEx: what good does it do me to be notified that my package has been delivered 17 minutes before it’s actually delivered? When I discover, during that 17 minutes, that I have no package, what do you think my first reaction will be?

Privnote is a new web app making the rounds on Digg and other social networking sites. It allows you to post a note at a unique URL which you can then share with someone. The note is deleted once the URL is viewed. It’s a simple premise that, if used for sending love notes or other inconsequential messages, is cute and harmless. However, the developer of Privnote has irresponsibly crossed into dangerous territory by claiming on his blog that Privnote is secure enough to be used for sending “credit card information and root passwords”.

He goes on to claim that not even Privnote’s developers can read your secret notes:

What about the site administrators, you may ask, those ones who always seem to have “full power” over your data. Well, with Privnote, those cannot read your note either. The explanation is a bit more technical, but here it goes: When the note is received by the server, a note ID is created (the same ID you see in the link to read the note). The note contents is then encrypted and saved in the database but (and here’s the magic) the salt to encrypt the note is not the note ID but a hash of the note ID. Hashes “one way” so you cannot go back to the note ID from the hash. So the note gets stored in the DB encrypted with a token that only the person which has the note link can read it. Oh, and we also have web server access logs disabled which makes impossible for any administrator to decrypt the note contents. So, as you can see, the only person who has the key to decrypt it is the one who has the link to the note.

These are the excited hand-wavings of someone who either has a very poor understanding of logic or is maliciously trying to trick people into disclosing sensitive information. Either way, it’s a big red flashing warning that Privnote is a toy and should not be used for anything even remotely sensitive.

According to the developer’s description, each note has a unique id. The contents of the note are encrypted using a salt consisting of a one-way hash of this id. The id is also used in the URL to identify the note. Here’s where the hand-waving comes in: he claims that, since Privnote doesn’t store access logs and can’t see the URLs, they can’t figure out the decryption key and thus can’t decrypt the notes.

Unfortunately, this is nonsense for the following reasons:

1. If a URL containing only a note id can be used to retrieve a note, then that note id must be stored in the database in order to be used for lookups.
2. Since the note id is stored in the database, anyone with access to the database and knowledge of the hashing algorithm used can recreate the hash value used to encrypt a note and can then decrypt that note.
3. The claim that Privnote doesn’t keep access logs is puzzling; why would access logs even matter if the notes are deleted once they’re accessed?

In other words, anyone with access to both the Privnote database (to retrieve note ids and encrypted contents) and the Privnote source code (to know which hashing algorithm is used) has full access to the decrypted contents of any note sent via Privnote, regardless of the developer’s claims.

It’s one thing for someone to provide a service like Privnote and say, “Your notes are secure as long as you trust us.” It’s another thing entirely for them to claim that even they can’t read your notes when, in fact, they can.

Update (July 06, 2008 @ 07:11 PM): The developer has posted a much more detailed followup correcting the mistakes in his original description of Privnote’s security measures.

As it turns out, they are indeed encrypting notes using cleartext note ids and then only storing the hashed id in the database. This ensures that someone in possession of the database cannot recover the note ids and thus cannot decrypt the notes, and is a much better implementation than the one described in the original post. However it still doesn’t guarantee that Privnote’s developers aren’t executing additional code to intercept notes before they’re encrypted.

I have no reason to believe they’re doing this—I get the impression they’re naïve rather than malicious—but as long as they continue to claim that they can’t possibly read the contents of the notes being passed through their system, they’re lying.

I bought a new car two weeks ago. It was a weird spur-of-the-moment pre-mid-life mid-life crisis sort of thing. I suddenly realized one evening that it had been a long time since I had done anything really irresponsible, and somehow that just didn’t feel right. So, the next afternoon, almost by accident, I swapped my sporty but somewhat reserved and almost respectable 2006 Subaru Impreza WRX wagon for a completely off the wall batshit insane 2008 Subaru Impreza WRX STi.

I regretted buying the car the instant I drove it off the lot. Not because it was a bad car, but because I stalled it twice in the process. It was literally my second time ever driving a car with a manual transmission. Somehow, in my haze of irresponsibility, I hadn’t thought that would be such a big deal, but it was.

That night I barely got any sleep. I knew I would have to drive the car to work in the morning, in traffic. For the next 48 hours, I was more full of anxiety than I’ve ever been in my life. I felt terrible. I couldn’t concentrate at work, because I knew that in a few hours I’d have to drive it again, and I’d be that guy—the asshole who stalls his sports car at a traffic light. There was none of the joy I had felt the first time I drove a WRX; just anxiety, insecurity, fear of failure.

As the days went by, though, I quickly got better. I graduated from incompetent to horrible, then from horrible to not very good. Today I graduated from not very good to halfway decent.

Coming home from work, I stopped at a stop sign and waited for a break in traffic. One finally appeared, but it was too small. I was still too slow on the clutch. There was no way I’d be able to make it. But something snapped. My feet rebelled against my brain. My left foot lifted to engage the clutch as my right foot depressed the throttle. The timing was perfect. The car launched like a rocket, merging perfectly into the break in traffic. Despite having been slammed back in my seat by the acceleration, I managed to shift smoothly into second, and then third.

Suddenly, for the first time since buying the car, I felt in control again. I was driving the car instead of being mocked by it. The joy I should have felt on the first day suddenly hit me, the anxiety left, and I remembered why three of the four cars I’ve bought have been WRXes. It was glorious.

It might have lasted, too, if I hadn’t realized half a mile later that my blinker was still on.

At home I use a Microsoft Natural Wireless Laser Mouse 6000. At work I use a Microsoft Comfort Optical Mouse 3000. For some reason, if I put my iPhone too close to the wired mouse, the mouse stops working. The phone has no effect at all on the wireless mouse. What’s going on here?