Tuesday, April 11, 2006

Web Syndication and Atom Feeds

Due to popular demand ;-) I added a web feed for my blog. [Much to my surprise I discovered today that there is at least one occasional reader of this blog besides me. Thanks for your kind words.]

I experimented with web feeds when I first heard about the Live Bookmarks feature of Firefox. It wasn't so long ago, and the process was straightforward: I created a few RSS 0.91 files, and filled them with bookmarks, each entry using a title, description and link tag.

Now I find that RSS has forked into two different formats, confusingly named “RSS 1.0” and “RSS 2.0”. (In fact, there are more versions of RSS.) A third contender, Atom has surfaced.

It seems Atom 1.0 is the most fashionable choice, so I wrote a script to generate an Atom feed for this blog.

Atom is more complicated than RSS 0.91. Dates must be included and have to be in RFC 3339 format. Unfortunately the date command in Debian stable is too old to support the --rfc-3339 switch, so instead I used

date +%Y-%m-%dT%H:%M:%S%z $* | sed 's/..$/:&/'

Some sort of ID is also required, and I'm not sure exactly what the purpose of this is. The specifications refer to some Internationalized Resource Identifier as defined by RFC 3987 but that's one standard too many for now. At the moment I use the relevant URL as the ID.

Ideally the mime-type of an Atom file should be served as “application/atom+xml”, which in Apache can be accomplished by adding

AddType application/atom+xml .atom

in a configuration file.

In a HTML file, one should add something like:

<link rel="alternate" type="application/atom+xml" title="Title" href="http://some.url/something.atom">

and perhaps also lines like:

<a href="http://some.url/something.atom"><img src="http://some.url/feed-icon-16x16.png" alt="Site Feed" height="16" width="16" /></a> <a href="http://some.url/something.atom">Site Feed</a>

where the feed icons can be downloaded from feedicons.com.

Monday, April 10, 2006

Git and Cogito

Somehow, I have managed to avoid revision control systems until recently. I set it up for a typical reason: I wanted to be able to work on my thesis from different computers without worrying too much about keeping different copies in sync. Also, it's nice to be able to keep track of my progress. I don't expect to ever revert to an older version, but seeing a detailed log of changes makes me feel I've accomplished something.

Perhaps it's a good thing I put off learning about version control for so long. Back when I first thought about using it, CVS was the most popular open-source choice, Subversion was immature, and Linus Torvalds didn't use any system for the Linux kernel.

Now a new generation of source control tools has materialized, and are being improved rapidly. Development of the Linux kernel has benefitted ever since Linus started used revision control systems years ago.

So it seems it is a better time than ever to delve into version control. The old systems were plagued with various flaws and annoyances. The latest systems resolve these issues, but I wouldn't know. I never used the older systems so I have no idea what the problems were.

Things have gone smoothly for me with Cogito (basically some shell scripts based around Linus Torvalds' git tool). Even though it's designed to be a distributed source code management tool, it works well for one person editing a few files.

The only problem is that I can't easily host the repository on my Debian-stable server since git is too new, though Debian backports exist. I could just use rsync, but this method is deprecated and highly discouraged. [Also explained in this git tutorial; search for “rsync”.]