NSURL category to return the full path, with trailing slash and query parameters

@implementation NSURL (PathHelper)
    // getting a path without the trailing slash stripped is annoying.
    NSString *pathWithPrevervedTrailingSlash = [CFBridgingRelease(CFURLCopyPath((CFURLRef)self)) stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
    if (self.query) {
        return [NSString stringWithFormat:@"%@?%@", pathWithPrevervedTrailingSlash, self.query];
    } else {
        return pathWithPrevervedTrailingSlash;


Might even workโ€ฆ

A usable Shelf release

Right, Shelf has now reached version 0.0.6 – download it (there are newer versions out now – get those). It’s good enough that I’m running it full time now. Thanks to Mark Fowler, it can now pull clues from Firefox, which is a relief. I’ve also added Address Book and iChat support, although the iChat stuff is a little hokey – it assumes you’re not using tabbed chats, and that you speak English. Sorry. The iChat AppleScript dictionary is lousy.


It’s been suggested that I could work out twitter feed and Flickr photostream URLs about people based on their name / nick / email. I’m currently shying away from deriving too many things about a person magically. For instance, I could work out (and cache, obviously) a Flickr username for a person from their email address. Quite apart from the horrible privacy implications of sending the email addresses of everyone you read mail from to Flickr, I just don’t like the approach. I’d much rather encourage a rich address book with lots of data in it. This has the side-effect that Shelf will also recognise my Flickr page as belonging to me.


Update (2007/04/13) – DjangoKit got better since, you know. But everyone keeps linking here for some reason…

DjangoKit is a framework that will (eventually) allow me to package just
about any Django application as a stand-alone MacOS .app. I’ve been noodling
with the concept for a while now, but I was finally motivated to do something
after I saw Slingshot and started reading about Apollo and
related technologies. I’ve tried using Ruby and Rails, and tried again as a result of seeing Slingshot, but I really don’t enjoy it. I’m a Python
person, and most of my personal projects (including jerakeen.org itself)
are written in it, so it seemed like it would be easier to re-implement the interesting parts of Slingshot as a PyObjC app than re-write everything I care about in Rails. Also, I’m weird.

Like slingshot, the built .app gets a local (sqlite) database that works offline, but I’m not thinking at all about sync with a remote server. It’s an orthogonal problem that can be solved later. I also don’t care about non-mac users right now. Lots of the hard bits of the code are in the bundling system, and should be convertible into py2exe rules, so I won’t rule out doing the same thing for Windows, but this is a personal project, and I’m a mac weenie this month, so if you want it, you can do it. Likewise linux.

It’s early yet – I’ve only really spent a couple of days hacking on it – but I have a downloadable demo available – it’s an utterly trivial application, but demonstrates Django with a model, a generic view and a template, as well as the admin site that Django provides magically. The demo app source code is avaliable if you want to see how trivial the app is, or you can get the entire thing as source – both from my subversion repository. I’m not promising the thing will build for you, though. You’ll need PyObjC, Django and pysqlite2 installed, and they mustn’t be installed as eggs. Running setup.py the first time will generate a local database.sqlite with the tables for the app model. I haven’t solved the schema upgrade problem yet. ๐Ÿ™‚

The code is almost entirely nasty hacks, so beware, but it should be possible to clean it up and produce something more elegant. Eventually I want to be able to turn just about any Django application into a Mac application by writing a small config file describing it, but right now you should be able to ship your application by:

  • editing theproject/urls.py and adding a dispatcher for it
  • add the package name of your project to the packages line in setup.py
  • make sure your app is in your python library path
  • delete the local database.sqlite (so the models are regenerated)
  • Run python setup.py py2app

If you need media files shipped, try putting them in ./media, and they’ll be bundled with everything else, but this isn’t so well tested. The first time you run the app it’ll copy the database into ~/Application Support/DjangoKit/appname so you’ll also need to clean that folder out if you change the model.

Using the iSight for Adium / iChat

I have a lovely shiny office MacBook Pro sitting in front of me, and in the
middle of the top of the screen is this little annoying black square. It’s an
iSight camera, and it can always see me.

It’s annoying for two reasons. Firstly, it can always see me. There’s a little
light to tell you that it’s on, but it’s perfectly capable of blipping on
briefly without you noticing. But mostly it’s annoying because I hate
the thought of such a high-tech piece of technology just going to waste up there.

I really have no real use for this thing at all – I don’t obsessively
catalogue my book collection
, I don’t hold
frequent multi-person videoconference
, and I already have a
camera. I’ve also seen enough PhotoBooth
to last me my ENTIRE LIFE.
But merely having no good reason isn’t a good enough reason to stop me, so I
came up with a use for it.

DuckCall is an application that runs in
the background, and takes a picture of you every 30 seconds using the iSight.
Then it’ll set this picture to be your iChat or Adium ‘status picture’ thing –
the little picture of your head that other people see in their contact lists.
Setting away messages is so web1.0 – when I’m not at my computer, you know it,
because you can’t see me. It’ll also try to be smart – it won’t do
anything if neither app is running, for instance.

Naturally, it’s not perfect. For the Adium stuff to work, you need to be using
a recentish beta – the ones with the
single buddy icon shared between services. And it has a nice little
todo list, like all my projects.

The biggest thing wrong with it, though, is the Frankenstein nature of the thing. I write my crazy application prototypes in PyObjC because it’s very easy to get something working. But there are no Cocoa bindings for reading from the iSight (why??) so I shell out to an external tool and save a file from the iSight to disk. Then I use AppleScript to load the file from disk and set the icon of either of the IM apps that happen to be running (or both, I guess, if you’re weird). Using Python as the wrapper makes the app about 3 megabytes larger than it really should be. If someone wants to re-implement it in Objective C, that would be good.. ๐Ÿ™‚

Weirdy, I’m not sure if I like the philosophy of the app. I keep getting scared that it’ll take photos of me at bad times. Given my stated reluctance to publicise my life it’s odd that I even considered writing this thing. I comfort myself with the thought that no matter how stupid I look in this photo, it’ll be gone in 30 seconds, and most people will never see it…

Get it here and tell me what you think..

Blotter / Core Data

Wow, core data is shiny. James re-wrote (the core of) Blotter in 10 minutes using it, so after a bit of polish, I have a 0.9 release, written in pure ObjC/Core Data. Alas, you need 10.4 to run it, and XCode 2.1 to build it (an 800 meg download! ow) but that’s the cutting-edge future for you. Sigh.

Blotter 0.7

I discovered Cocoa bindings and verily, they are the greatest thing since sliced bread. Not that I’m very fond of sliced bread.

I’ve re-written Blotter from the ground up to take advantage of them – it’s much nicer and more reliable now, although I totally changed the back-end format, so anyone actually using it and wanting to upgrade is in for a shock. I don’t think anyone is, though. I mostly wrote it because I saw xPad and didn’t really want to pay for something that seemed so trivial..

Anyway, Blotter 0.7 release – it’s usable, although unhelpful the first time you start it. I use this app constantly, myself, so I like to think it’s reliable. I’ve certainly never lost data to it. (I’m doomed now, of course.)

Update (about an hour later)

Curses, 0.7.1, with some small fixes.

Flame 0.1

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.

Cool apps and Cocoa

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

London Perl Workshop talk

I gave a talk today at the London Perl Workshop, brilliantly organised by a shadowy cabal of mysterious figures. Every talk I saw was great, to the point that the inevitable clashes with other talks that I wanted to see were really annoying, but fortunately everything was filmed, so presumably there’ll be video of the talks I missed available at some point. Likewise, all the slides will be around at some point, but until then, my slides are here. Powerpoint, I’m afraid, it’s what the work laptop has, and 1.5 megs, because it’s full of pictures…