Zoë and I sailed from Gibraltar to Almerimar with my Mum this weekend. I use “sailed” a little loosely as there was essentially no wind, so we motored nearly all the way. Zoë had a fantastic time. The weather was lovely, and with so little wind, it was really easy to stop for a swim every so often (like when the water temperature sensor said 27°!). The highlight for me was sitting down for dinner in the setting sun and being joined by 40 or so dolphins. Highly recommended!
I just grabbed the new update to the Safari 4 preview, and I have to say it’s very zippy indeed. I ran SunSpider benchmarks on it and FireFox 3.0.1 on my Mac Pro. Safari 4 is on average 75% faster, but has many results that are in the 200 – 500% range.
The integration of the JS debugger is very elegant (Drosera has been rolled in), but I’m still looking forward to the appearance of FireBug for Safari, which someone is doing as a Google SoC project (S4 adds some FireBug hooks too).
All the new CSS funkiness from recent webkit nightlies is there too, and I suspect many an iPhone and widget developer is drooling over them…
There’s this enormous apache mod_rewrite bug that I ran into back in 2005, and to my dismay, it’s still there. Long-standing bugs are usually small edge cases that don’t affect many people, but this one is a monster that I suspects pretty much everyone that’s using mod_rewrite, and they’ve just been lucky in avoiding it. The basic issue is this: if you match params that require URL encoding to be safe, mod_rewrite will not rewrite the back-reference (that’s $1 below) correctly. So take this very simple redirect:
RewriteRule ^(.*)$ index.php?show=$1 [R]
so you hit http://www.example.com/a%2Fb and mod_rewrite neatly rewrites it as http://www.example.com/index.php?show=a/b! Notice that it has urldecoded the matched parameter in the replacement string.
I’ll bet that there are a zillion mod_rewrites out there that suffer from this fundamental problem and haven’t even noticed. If a few people voted for this to be fixed, it would probably go away…
Recently I’ve had a problem with subversion commits returning a ‘200 OK’ result, accompanied by a peculiar MERGE error (when I’m not doing a merge), but weirdly, the commit had actually made it into the repo. I’d googled for this a while ago with no success, but I had another try today and found this post. Thinking about it, I’d had this problem since updating to the very-very-long-awaited trac 0.11 release. So I tracked down the latest release of the trac-post-commit-hook script and installed that, and amazingly enough, it just works. Thank you UberGeek!