I recently attended the 25th annual Chaos Communications Congress in Berlin, Germany. It’s always exciting to attend these events and get an international perspective on how the world is unfolding.

I have a Nokia N81 phone for which I wanted to update the firmware. This is much more difficult than it needs to be, because Nokia’s firmware updater runs only under Windows, and I don’t like to have Windows on my computer.

So, here goes the story of my adventures in proprietary software.

PBCore is an XML metadata standard for public broadcasters. It is design to store metadata about multimedia objects (files, tapes, and so on), and to enable broadcasters, producers, and others to exchange that metadata.

Working with Dave Rice of the WNET digital archive, I’ve been developing a tool (an early demo of which is online) to perform basic CRUD and import/export on PBCore data.

While there have been a few users of PBCore as an internal schema for storing metadata, cases where PBCore has lived up to its promise and actually been used to exchange metadata have been relatively rare to date.

However, as this starts to change, it is becoming more important that users adhere strictly to the PBCore specification. It can be difficult or impossible for users to exchange data if the recipient’s tool can’t read the output of the sender’s.

Hello, and welcome to the roasting vermicelli blog.

Like many tech blogs, this one will start off with a self-referential post explaining its own operation.

This blog is built on Webby, an “ASCII Alchemy” website building system which relies on familiar Ruby technologies (erb, RedCloth, haml, etc.) to build static HTML websites. This means you can use your favorite text editor to manage your site, take advantage of a template system in order to avoid repeating yourself, and generate a collection of HTML files is super-easy to host on any webserver. Webby will never replace the full-sized content management frameworks, but for small, simple sites, it’s great. My first Webby project was club-mate.us, and now I’m hooked.

(ikiwiki, a “wiki compiler”, is similar in many ways to Webby. But it does more than I need, it seems harder to configure, and I’m already familiar with making webpages in Ruby, so Webby had a smaller learning curve for me.)

Another benefit of having a website comprised of text sources which can be “compiled” is that you can stick the whole thing in a version control system such as git or svn. You can browse the git repository for this site if you like.

Webby comes with a simple “deploy” task which will rsync your built website over to your server, but this is sort of an inelegant approach to the deployment problem. Instead, I’d prefer my site to automatically be built whenever I check it into my git repository. Here’s how I set that up.

I’m using gitosis to host my git repositories. It offers an access-control layer, gitweb integration, and some other niceties.

So, first I created the site on my laptop, added a project to gitosis, and committed the initial revision.

Next, I logged into the webserver and created a clone of my repository from which the content will be served. I want gitosis to be able to update the site, so I make this clone owned by the gitosis user:

   1  cd /var/www
   2  sudo git clone /srv/gitosis/repositories/vermicelli.git vermicelli
   3  sudo chown -R gitosis:gitosis vermicelli

Then—and here’s the magic—I put this script in /srv/gitosis/repositories/vermicelli.git/hooks/post-update:

   1  #!/bin/sh
   2  
   3  WORKDIR=/var/www/vermicelli
   4  export GIT_DIR=$WORKDIR/.git
   5  pushd $WORKDIR > /dev/null
   6  # git is quite noisy even with the --quiet flag...
   7  git pull --quiet > /dev/null
   8  /usr/bin/webby build
   9  popd > /dev/null

Make sure that the script has the execute bit turned on, or git will ignore it. The magic here is the need to set the GIT_DIR variable—without it, the git pull fails with a confusing error message.

If you’re allowing access to your repository with http, you probably want to add exec git-update-server-info to the end of the script.

Finally, I configured my webserver to have a document root of /var/www/vermicelli/output.

Now, whenever I push changes to my git repository, the website is automatically built and made available!