..because I keep having to tell people about it.

If you like your terminals to be white-on-black, like me, you'll get annoyed, because when two terminals overlap, there's no visible line between them. Set your terminal background colour to ~3% grey, instead of pure black. You'll be able to make out the shadow of the upper terminal overlaid on the lower, which serves as a very good border, but the contrast in the terminal will still be very strong, you'll never notice it's not really black.

iTunes music sharing is a cool feature, and so naturally there are people out there who want to use it, without necessarily using iTunes itself. Personally, I use mt-daapd to share music from my house server to the various clients in the house, but I also have a use for an iTunes client. Specifically, I want to write one. This will require a python DAAP client library, which does not, as yet, exist, to the best of my knowledge. Pity.

My first step towards this goal is now here: md5daap is a python wrapper round a slightly modified md5 library, which implements the strange variant of MD5 that Apple requires for DAAP authentication. As per the README, I wrote none of the code. Lovely.

finally, I have a Bot::BasicBot::Pluggable release out. muttley's been bugging me for weeks, and the last release was in June 2003, which is ridiculous. When you just use things straight from the svn repository, you forget how long it is since you've done a release.

There's a Bot::BasicBot 0.60 release to go along with it, with better character set support, no massive improvements, though. I should push that guy to 1.0 soon...

ok, keeping your apache config files in subversion is a Good Idea. But keeping the config files that CONTROL THE SUBVERSION REPOSITORY in the SAME SUBVERSION SERVER probably isn't.

Finally, we have a public release of Flame. Getting this out the door has taken a while, but I'm very happy with it's current state, so let's see what the rest of the world thinks.. I have a project page here but the 'real' app page for linking is the husk.org one.

The more I play with XMLHTTPRequest, the more I'm convinced it'll be one of the biggest things to happen to the web in 10 years. The possiblities for utterly changing the way web interfaces work is astounding. It's aquiring the name Ajax, which annoys me, but it is easier to say than 'XMLHTTPRequest'. It's also hard to code using it - because everything has to be asyncronous, you're playing with some fairly different ways of programming. It feels similar to the change you get going from simple command-line or server apps to GUI apps with their callbacks, except moreso - you're getting callbacks from the user interacting with the web page, and callbacks from the requests you've made to the server side in the past. When someone comes up with a decent toolkit for writing this nicely, I'll be a happy person.

I now have a mostly-written framework in JS for making calls to a server in a known RESTian format, and getting XML back in another expected format, so I can hide lots of the details and treat it almost like async XMLRPC, but I'd forgotten how annoying JS is to program in. It's not a matter of 'develop on firefox, and it mostly works on other things', like CSS, you virtually have to develop simultaneously on three platforms to stand a chance. I've lent a friend my rhino, so I have to use the web to look everything up, and there are no decent web resources for this stuff. The best thing I've found so far is the Gecko DOM reference, but there's nothing on the language proper - when you're routinely playing in perl, python and php, remembering what todays syntax for iterating over the keys of a hash is is hard. I tend to just try things at random till it works, or crib from random downloaded snippets that seem to work. This doesn't make the cross-platform thing any easier, either.. :-)

Finally, the 2lmc spool is live with the new improved php version of the code, as opposed to the mod-perl thing it was running on before. Not that I have anything against mod-perl, I use the thing professionally, but it does lead to somewhat large processes, and on the (very) shared box that the spool is hosted on, being able to get rid of it would be a benefit. Thus the successive deaths of Hayfever and the old Spool code. Soon it will be a bright, clean, apache2-driven future.

I like this James Duncan Davidson article because it provides a lovely counterpoint to the 'the mac is a much smaller market, so you'll never make as much profit':

In a conversation with Rich last night, one point kept coming up: If he did his application for Windows, he would have to have a larger team - probably 5 or 10 developers instead of one. And a larger team would mean that he would need more start-up money and a whole host of other issues

Certainly I'm finding PyObjC and Cocoa such a ridiculously easy RAD tool that it's almost easier to start a new project and play with some code than it is to think about it first. I nearly have a little library of useful controls I can throw at things, too - I have an iPhoto-like view that lets me put lots of scaling images into a scroll view, at which point I can write some fun photo-site clients. As usual, the main problem is focus...