Archive for June, 2005

Friction, Tags, and Just Writing Something

In my last post, I talked about the forces that prevent me from writing blog posts- factors I collectively call friction. One of the things that I cited was a desire to get things done first- for example, to make some headway on a new project before discussing it. Another version of the same problem is the desire to work out an idea completely before trying to explain it. In this entry I’m going to try and throw caution to the wind, and write about some ideas which aren’t fully formed, but which have been rattling around in my skull for a while.

Another of my examples of friction was categorizing posts. When I first started this site, I wrote my posts in the browser, using the Blosxom plugin wikieditish. Due to the way wikieditish works, I had to come up with the URI of a post before writing a post. Because my URIs reflect my post category tree, that meant that I had to categorize my post and name it before the first word was written. This is a little extra friction at the beginning of the process, when I’m still trying to figure out how to an idea into words.

Today I use Blapp to write my posts, which lets me name and categorize my post after it is written. This has reduced the friction of starting a post, but I still encounter friction when I need to categroize my posts. My category system, which you can see in the “More” boxlet on the side of this page, is a hierarchical system that evolved mostly in the first few months of the site’s life. As time has gone on, I’ve regretted some of the decisions I’ve made, and I’ve been reluctant to add new categories, because they don’t fit into the existing structure as well as I’d like.

Blosxom supports both date-type URIs and category URIs; this post is available both ways:

(Edit: the date-style link seems to be busted at the moment, I’ll ty to track that down tommorow. But it should work). I decided to use the category model for all of my internal links, trackbacks, etc., because they are nicely hackable along the category axis. On the other hand, the date URIs are nicely hackable along the time axis.

The friction is really tied up in the category tree. Besides the issues with the hierarchy, sometimes a post seems to qualify for multiple categories. There are ways to hack this into Blosxom, but none of them are very elegant, and have the side effect of further polluting your URIspace with additional permalinks, one for each category a post is placed in.

A solution I’ve been mulling would address a couple of these points at once, and that is to move to a tag-based categorization scheme, a lá, flickr, et al. Using a tagging system, a post can be tagged with as many tags as needed. Category style URIs would give way to tag-based URIs, which are actually index URIs rather than permalinks. For example, to see all of the pages I’ve bookmarked via and tagged as webdev (web development), you can visit In this case, I think the best candidate for a permalink becomes the date-style URI.

Tagging has been a hot topic for a while, but I’m going to sidestep the entire debate over taxonomy vs. folksonomy and simply talk about ways such a system would be useful. The ability to cross-tag a post I’ve already mentioned. Another benefit is the ability to automatically provide links to related material in other places. For example, a post about web development could automatically include a list of recent articles from this site with the same tag, and a link to that tag’s index on

For another example, look at Technorati tags. This system allows you to tag posts in a way that lets Technorati aggregate your post with others that share that tag. A blogging system using tags could generate the Technorati tagging markup automatically, and could even show links to Technorati’s page for that tag (See Tantek’s site for an example of this in action.)

But why stop there? Another form of blogging friction I suffer is the need to link. I find it slowing and distracting when I’m writing a post to go hunt down URIs to things I want to link to- even related posts on my own site. Tags could help here as well, by adding tag lookup to authoring tools. If you haven’t used it lately, go check out the standard posting bookmarklet. If you have a account, click here to trigger it now for this page; your back button will bring you back. It has some cool new features, like a list of tag suggestions based on the content of the page being bookmarked (sometimes- if you don’t see suggestions, try it on some other pages). Now picture a blogging tool that analyzes as you type, suggests tags, and then suggests links to like-tagged content via services such as Technorati tags and, as well as posts from your own site. Instead of hunting down links, your authoring tool hunts them down for you. And with the groovy new Ajax stuff all the cool kids are playing with lately, you could even do this in a browser-based authoring tool.

I’ll wrap up for now with a teaser/segue to a future post- I’ve been toying with this idea for a while; and I’m of the opinion that as much as I like Blosxom, it’s not the right tool for this job. So, like scores of other wheel-reinventing programmers before me, I’m considering writing my own blogging software. But that’s another post.


If you’re a regular reader, you haven’t really been reading me regularly for a while now. This is because I haven’t been writing here on the site regularly for some time. The home page displays 10 articles at a time; as I’m writing this (prior to posting this), the oldest article is from March 22. Today is June 12; I’ve only managed 10 articles in the past 3 months.

This weekend I’ve been reading Joel On Software. While I’ve read a number of Joel’s more frequently linked articles on his site (from which the book is culled), I’ve not read alot of his material, so picking up the book seemed like a good choice. I always prefer hardcopy for extended reading. One of the topics he expounds on at great length in the book is the need for writing good functional specs. I found this interesting, as I’ve recently been battling my inability to write at work- not on specs, but on documentation. Joel gives this advice:

Writing is a muscle. The more you write, the more you’ll be able to write. If you need to write specs and you can’t, start a journal, create a weblog, take a creative writing class, or just write a nice letter to every relative and college roommate you’ve blown off for the last 4 years. Anything that involves putting words down on paper will improve your spec writing skills.

(from Painless Functional Specifications – Part 1: Why Bother?)

And of course, he’s right. That’s one of the reasons I started this weblog. And yet I don’t write enough. I attribute this largely to friction – things that make the act of writing a blog entry more effort then necessary.

One example of friction is the posting interface- when I first started the site, I posted everything via a simple web form, which was functional but it required me to pick a category before writing the entry. This doesn’t sound like much friction, but friction is cumulative, and every little bit hurts. Also, editing large amounts of text in a browser edit box isn’t really alot of fun. Worst of all, I couldn’t begin a draft and leave it till later to finish – I could only post completed works.

Last December, I started using Michael McCraken’s Blapp, a dedicated OS X editor for Blosxom weblog posts. It lets me write locally, see a preview of my post using my own templates, I can write the entire post before assigning a category, and I can save my work without posting it. This all amounts to lower friction, and it has made it easier for me to write for this site.

Another source of friction is inertia- the less often I post, the harder it is to get around to posting. To that end, I’m going to challenge myself to post here more often. After the November Blogging Challenge, I’m not going to try and hold my self to a post a day. Instead, I’ll shoot for a post every other day.

Another source of friction has been concern over content; I’ve often tried to keep my posts to a certain technical scope (which at other times I’ve ignored wholesale), to this end I’ll try and loosen up what I post about. A special case of this problem is a certain aversion I have to the release early, release often mindset- when I have a project in mind that I might want to tackle, I have a need to get a certain amount of progress under my belt before talking about it. In my defense, this site contains a number of examples to the contrary- things I’ve posted with “more info to come later” which never came. Nonetheless, I’m going to try and follow Les Orchard‘s example, and post about whatever I’m currently tinkering with, even if it won’t come to fruition.

HOWTO See what’s changed in the file you’re editing in Emacs

Warning: Geek threshold exceeded. If you don’t know what Emacs is, this post will mean nothing to you.

I use Emacs as my primary editor these days, and I tend to have lots of buffers open at once. Every so often, I’ll go to close Emacs or just close some buffers, only to be alerted “Buffer XYZ modified; kill anyway? (y or n).

What? I opened that buffer 3 days ago. I don’t know if I should save those changes… what changed? Now, my copy of XEmacs has ediff, a very nice interactive diff tool. You can diff two buffers, two files, three files, buffers against revisions (if the file is under source code control), etc. What you can’t do is diff a buffer against the underlying file on the file system.

Now, I could save the buffer in question to a temporary location, and then ediff that against the original. But where’s the elegance in that? I wanted a better solution, so I asked Google.

I found the answer (well, most of it) in a 1996 post to comp.emacs by Larry Rosenberg. He offered a function for doing a quick diff of the current buffer against the underlying file system version. I bound this C-c d in emacs. I then expanded it just a bit. I often use context-diffs (diff -c), so I wanted the option, but for long lists of diffs, sometimes it’s just too much. So, I made it an option of the command. Invoked normally, it shows a plain diff. When prefixed with C-u (using my binding, this becomes C-u C-c d), it runs a context diff.

Just to be clear – Larry did all the real work back in 1996. But considering my understanding of elisp is only slightly better than my understanding of Sandskrit, I’m pleased with my modification.

Here’s the function definition, along with the keybinding, from my emacs init file:

(defun diff-buffer-against-file (context)
    "diff the current [edited] buffer and the file of the same name"
    (interactive "P")
    (let (  ($file buffer-file-name)
            ($tempFile "/tmp/emacs.diff")
            ($tempBuffer "emacs.diff"))
        (push-mark (point) t)
        (generate-new-buffer $tempFile)
        (copy-to-buffer $tempBuffer (point-min) (point-max))
        (set-buffer $tempBuffer)
        (write-file $tempFile)
        (shell-command (concat (if context "diff -c " "diff ") $file " " $tempFile))
        (kill-buffer $tempFile)

(global-set-key "\C-cd" 'diff-buffer-against-file)

Backing up a Windows Laptop with OS X

Update 9/10/2006: I’ve improved this procedure, and removed the need for NFS. See HOWTO Backup an Entire Windows Drive with OS X and Ubuntu for details.

My wife’s XP laptop continues to get slower. She’s had it for about 2 1/2 years, and it’s still running the original XP install, so no surprise that performance is lousy. I’ve considered dropping a desktop Linux install on it, but she has a couple of apps that still require Windows. For now, I decided to format her hard drive and revert it to factory condition with the restore CDs that came with the machine.

So now I needed to back up her machine. It doesn’t support Firewire or USB2, so external drives were out. In the past, I’ve always copied alot of files over the network, but this is time consuming, and usually error prone- If windows decides it can’t copy a file, the whole copy operation stops, and you have to figure out what has copied and what hasn’t.

I wanted something similar to Ghost. Ghost is a PC backup solution the PC admin folks at work used to use. It’s now a Symantec product, but I don’t think it was at the time. The original was great- a single floppy (we used floppies back then) would boot, connect to the network, and copy the entire hard drive to an image file on a network server. Modern versions allow you to grab files from inside the image; I don’t recall if the original did. This is a feature I need; I’m not restoring the whole image to a drive.

I tried to find an open source alternative (the current Symantec Ghost is overpriced, and I don’t trust Symantec software at all) without much luck. I found Partition Image for Linux, but the images can’t be opened for access to individual files. While researching, I came up with another idea… make a direct copy of the windows partition from a Linux Live CD (such as Knoppix) using dd. I figured the image might be mountable, just as you can mount an ISO CD image file.

A word about efficiency: This method copies the entire partion, empty blocks along with the rest. So, copying Sherri’s 27G partion would result in a 27G image file. However, I have the space on the iMac, the backup is only temporary, and I wanted to be sure I had everything. Seemed worth a shot.

In order to make the backup over the network, I needed to share a directory on the iMac as an NFS share, since I’d be connecting from a Linux Live CD. OS X supports this, but not via a nice little applet like with Windows Sharing. You need to fool around with netinfo, which I dislike, and run several daemons. Since this is only for temporary use, I decided not to get my hands too dirty, and found a shareware utility called NFSManager to handle the details for me. Once I had created an NFS share, it was time to use it.

I booted Sherri’s laptop using a Knoppix LiveCD, opened a shell, and mounted the NFS share (/Users/jclark/Netmount on the iMac):

sudo su
mdkir /mnt/mac
mount -t nfs /mnt/mac

The first line makes me root for the ensuing commands. I then make a mountpoint, and mount the NFS share to the mountpoint. Interestingly, when I ran the mount command, the command appear to hang, but opening another terminal showed that the mount worked.

The laptop only had one drive (C:) so I suspected that I only needed to backup /dev/hda1, but I checked it with QtParted just to be safe. QtParted is a GUI shell around GNU parted, and is accessible from the Knoppix start menu. I would have used parted from the command line, but couldn’t find it in the Knoppix install.

Once I had confirmed what I needed to backup, making the image was simple:

dd if=/dev/hda1 of=/mnt/mac/laptop_drive

The transfer rate was about 10G/hr, which isn’t too bad I suppose. When it was finally complete, I tried to mount it under OS X using the mount command, with no success. A little while later I realized I hadn’t specified to mount it via loopback (in other words, treat a file like a drive). After a few minutes trying to figure how to do this in OS X, I got lazy and Googled. One of my hits suggested an idea for opening a floppy image that seemed too good to be true, but I tried it anyway.

I renamed the image file, adding .img to the name, and then double clicked the icon in Finder. A few seconds later the drive image was mounted, and I had access to the entire drive backup. Very cool.

Now all I have to do is restore her factory drive image, clean off all the crap it came pre-loaded with, patch the crap out of XP, reinstall her software, and restore all of here files.

Maybe I should just buy her an iBook….