I bolded the part that bothers me. No warnings. Double-updating the same value in the same row in the same statement throws no warnings (never mind errors!). I haven't checked the ANSI standard to see if this is mentioned, but it sure is worth noting.

I have an iPhone. I'm finding myself very prone to snapping photos now, whereas before I was completely unlikely to tote a camera. I also discovered that Movable Type works just fine on the iPhone, I even posted an entry on my personal blog from it while we were at the ice cream place.

But you know what? I want to put up a photo I just blogged. But transferring a photo via anything but email is a pain. Enter perl. I whipped up a perl script to receive iphone photo email, piped via procmail, and save the photo attachment to a path, then email back the phone address with the filename it used. Just make sure you set the path in the script to somewhere down from your DocumentRoot, and then you can immediately reference the photo with an img tag.

Now I can photoblog directly from the phone, which is pretty fun.

Requires
sendmail (for the outbound msg, but I bet you could adapt any other mail program)
perl
MIME::Parser
procmail

Here's the relevent part of my procmail entry (note that photoblog is an alias that goes to my user account via /etc/aliases):

I definitely like it so far, although I was unimpressed with battery the first day. It really should be engineered to survive one day of hard use. I was charging it until late last night. I watched youtube from it in bed for about 30 minutes, had a total of 14 hrs of standby, and then about 6 or so hours of use (mostly as an ipod, small bit of phone). It died while I was talking to my wife en route home.

Rumor has it that bluetooth, and the "prompt" wlan networks features both suck up a lot of bandwidth, so I may try to keep those off when possible. (I'm going to turn bluetooth off while driving, damnit, but I don't really need it otherwise).

Javascript objects do not stay instantiated when passed into setTimeout. setTimeout() is unavoidable, but I often find that when implementing behaviors which need objects, you're forced into one of two nasty choices:

Give everything an id, and pass that id into setTimeout in order to maintain some sort of scope

Watch everything lose context when passing through setTimeout

Not pretty choices.

But dojo.hang.hitch() solves that problem, gloriously. dojo.lang.hitch lets you attach a function to run IN THE SCOPE of an object.

What's great is that this lets you run events on things without IDs. I dynamically instantiate a lot of elements in the DOM with document.createElement, and there's often no NEED to assign an id except for issues like this; handling events. Now, with DOJO's hitching, you can deal with your objects while preserving context through setTimeout calls.