Tom Insam

Various libraries I played with yesterday, collated for my viewing pleasure. Mostly old, of course, but I want them in one place.

JSON-framework, by Stig, an excellent piece of JSON-parsing Objective-C which works perfectly on the iPhone.

Three20 is a useful collection of utility classes extracted from the iPhone facebook app. It had some problems with app rejection due to use of internal calls a while ago, but I presume that this is sorted out now. The latest XCode betas can check your app for this sort of problem before submission apparently anyway.

I had some issues with NSInvalidArgumentException crashes when running apps built with three20 - the trick is apparently to build with the -all_load linker flag. I don't know what this does, but it works.

Finally, this blog post and sample code is an excellent guide to putting not only routes, but quite a lot of other things onto a MapKit view. In the past I’ve used the excellent route-me native iPhone slippy map, but obviously there are some advantages to using the platform native map. I found the apple docs on Annotations confusing, and having a working example helped a lot.

Stars make search more invasive

Possibly Google didn't notice last time they did this and it went badly. Let's try again.

Stars sync with your Google Bookmarks and the Google Toolbar, so you can always see your list of starred items in one place and easily organize them.

HOW DARE THEY take a list of things I've saved in one context, and expose them in another context? You can't read my bookmarks when you're sitting next to me, but if I search for something and all my goat-mutilation bookmarks leap to the top of the results list I'm going to be upset.

What these guys have failed to understand about rejection is that it isn’t personal. If you’re a writer, you’re more or less constitutionally incapable of understanding that last sentence, if you think there’s any chance that it applies to you and your book; so please just imagine that I’m talking about rejections that happen to all those other writers who aren’t you.

Making Light: Slushkiller

After the huge rambling thing I did last time, let's see if I can be a little more focussed. This is how I deploy the static bits of my site.

I keep the source files in git - I have a copy in this github for convenient pointing/examples. I build the site with Jekyll, which uses _config.yml as its config file. This file is blank. This is because I like the defaults. In accordance with Jekyll defaults, the layout templates for the site are in _layouts.

In this directory, I run jekyll --auto . /tmp/jekyll, which processes the whole directory tree into /tmp/jekyll (just to keep it out of the way) - if a file starts with a YAML header it'll process it as a Jekyll source file, otherwise it'll just copy it straight across. The process also stays running (that's the --auto), watching for changes. This way I can edit source files and see changes instantly.

I build several domains-worth of pages at once using this tree. tom corresponds to and toys to To preview this on my local computer, I have a few entries in /etc/hosts: tom.movieos.local toys.movieos.local

and a local apache config file containing:

<Directory "/tmp/jekyll/">
    Options Indexes MultiViews FollowSymLinks
    AllowOverride None
    Order allow,deny
    Allow from all

<VirtualHost *:80>
  ServerName tom.movieos.local
  DocumentRoot /tmp/jekyll/tom

<VirtualHost *:80>
  ServerName toys.movieos.local
  DocumentRoot /tmp/jekyll/toys

This way, I can open http://tom.movieos.local. in my browser, and see the local processed files. Useful!

Just to keep things interesting, I also don't use CSS, I like to write sass. Now, there's a branch of Jekyll that knows about sass, but I can't get it to work - instead I use compass. config.rb in my site root is the compass configuration file. I run compass -w in the root of the repository and, like Jekyll, it will run and watch for changes, and rebuild the CSS files from the .sass files when I change them. Then Jekyll will see that they have changed and update the built site. More overhead, but it works very well.

When I'm happy, or whenever I've made some interesting changes, obviously I check things into the local git repository. Then I push the changes to the bare repository that lives on my colo. In that repository, I have a post-update hook:

unset GIT_DIR
  && cd /home/tomi/web/movieos
  && git pull
  && compass
  && jekyll . /home/tomi/web/movieos_generated

So. I unset GIT_DIR because I'm about to talk to a different repository and don't want to confuse things. Then I go to the directory where I have the source files checked out, and git pull to get them up to date. A single run of compass generates the CSS files in that directory, then I run jekyll to build the generated site.

Finally, Apache serves them. Rather than hard-code all my domains as I have locally, I'm more complicated on the server. I have a wildcard DNS entry that points * to the server. My apache config looks like this:

<VirtualHost *:80>
  # This virtualhost matches _anything_ in the domain
  ServerAlias *

  # not used
  DocumentRoot /home/tomi/web/movieos_generated/tom
  UseCanonicalName Off

  # match the first atom of the requested hostname, and serve files
  # out the directory with that name
  RewriteEngine on
  RewriteCond %{http_host} .
  RewriteCond %{http_host} ^([^.]+) [NC]
  RewriteRule ^(.*) /home/tomi/web/movieos_generated/%1$1 [L]

  DefaultType text/plain
  DirectoryIndex index.php index.html

This way, is served by files in /home/tomi/web/movieos_generated/tom, and likewise for all my other subdomains.

So that's it. A post-commit hook runs two sorts of processors over the source, building it into a directory tree that's served using Apache rewrite rules. Complicated and maybe fragile, but only at deploy time - because they're static files, once they're there, they stay there.