echo "hey, it works" > /dev/null

I’ve been a vi and Vim user for a long time. As such, my most productive writing comes when I’m using my beloved modal editor. I’m also a long-time Mutt user, the main attraction being that I can edit my mail with Vim. Recently, I’ve started using GMail for my non-academic mail, so I can more cleanly drop into academic mode without distraction.

GMail is much better than Mutt at a couple of important things, the most obvious being search. Searching all your mail is a pain to set up in Mutt, but the simplest thing in GMail. Mutt is also quite slow opening large mailboxes, and it’s impossible to save the same message in multiple ‘places’, as you can with GMail’s labels.

But I really missed being able to write email in Vim. Good email communication requires chopping out stuff that’s irrelevant to your reply, and snipping that stuff and keeping it readable is infinitely easier in Vim than in the pointy clicky world of a browser’s textarea¹.

While editing a long and involved email today, I pined on identica for Vim editing in GMail. I wasn’t really expecting anyone to be able to suggest how I might achieve that but I quickly got a couple of useful leads. penryu suggested vimperator, which was supported by notjosh. Vimperator is an extension that makes Firefox behave in a kind of Vim-like way. I gave it a try but I couldn’t work out how to use it as an editor for textareas², and it seemed to have a bug (or possibly a conflict with the diigo toolbar) that meant I couldn’t see anything I entered in Normal mode. So I ditched vimperator.

I had a small side journey looking at jsvi, a JavaScript reimplementation of vi, which I might revisit later to make a jQuery plugin, and extend that into a Habari plugin, but decided that was more than I wanted to do for the moment.

Next, screwtape and gavincarr suggested the It’s All Text extension for Firefox. I managed to get that hooked up to MacVim (I couldn’t get gvim to work) using the full path to the MacVim binary, in my case /Applications/MacPorts/MacVim.app/Contents/MacOS/MacVim. It seemed a little flaky in that it would only send the textarea to the buffer, and save edited content back, if MacVim wasn’t open beforehand. That was okay because I use console Vim for everything else, and I can set MacVim to quit when the last window closes.

So, I was almost completely happy. The one down side was that I had been using Fluid to make a site-specific browser for GMail, which keeps my mail separate from my browser and seems to help keep Firefox’s memory usage under control. But then, as I poked around MacVim’s preferences I saw this.

I’m willing to risk it for the moment. Enabling the external editor means I can have Fluid + GMail + Vim. Using the It’s All Text Firefox extension means I can use Vim to edit wiki pages or write blog posts, like I’m doing with this one right now. And all that means I’m pretty happy.

1. This is not your opportunity to say that it’s even easier in emacs or textmate or notepad or whatever, because it’s my blog and I like Vim, so there. ↩
2. Later, frt told me that you can achieve this with :set guioptions+=mT. I didn’t try it, but I may revisit Vimperator in the future. ↩

When I was in primary school, every kid in my school did an Ishihara test. It was a one-off thing, and I don't know who carried it out or what the purpose was, but it showed there were three colour blind pupils; my younger brother and I were two of them.

I can't remember when or how I found out I was colour blind, but I already knew before I took the test, and while the identity of the three wasn't announced everyone seemed to know it was me. Kids ask a million questions.

If you're going to have a disability, colour blindness is probably the one you'd choose. It's had very little effect on my life. I can't see the numbers in the dots. I'm more likely to talk about things in terms of their shape or position than their colour, even if it's not a colour I have trouble with, so if someone says, "You see the blue car?" I might respond, "You mean the third one along?" And when people find out I'm colour blind they often say, "What colour is my jumper? What colour is that book?" That kind of misses the point, because the problem is distinguishing colours from each other.

Apparently there are different kinds of colour blind. I don't know what kind I am because none of the descriptions and tests ever seem to match up for me, but I must admit I've never really taken the effort to find out. Like I say, it doesn't effect me that much.

In the left-hand image, I see nothing at all, just a textured background. That suggests I have Deuteranopia (also known as Daltonism), but the description sounds somewhat more severe than my experience. I can see the numbers in the other two images (Protanopia and Tritanopia). They're both very vague, especially the middle image, but maybe that's the way they are for people with normal vision. Are they all clear to you? Hover over the images to see what the numbers are.

Just out of interest, I did a hue senstitivity test recently. Normal vision would show no bars.

So, long story short, that's why my blog theme is predominantly red¹.

1. Yes, that's a joke ↩

I thought the topic of offensive presentations at professional tech conferences was beat to death before, but apparently there are still some out there who don't get it. Recently, the GoGaRuCo incident stirred up controversy, and now this monstrosity has occurred.

It's Really Not That Difficult.

You should read the full post. This disgusting sexism masquerading as edgy is just unbelievable. I'm almost speechless. The "monstrosity" is really over-the-top gross. What is it with some blokes ?

I logged in to eMusic recently to find this message:

In July, your eMusic plan will change. Please read the announcement for details on how this change affects your account.

Oh, yeah, my year is up. I guess my plan will go up in price a bit. Well, I'm paying $US12 a month for my 50 downloads now, so going up a few bucks is fine. On to the details.

On your next account refresh Jul 5, 2009, your plan will change to the new eMusic Bi-Annual 210 plan, which gives you 210 downloads for $95.90 every 180 days.

It took me a little while to absorb that. Let's convert it into the same units as I was paying. 180 days, let's call that 6 months, so $95.90/6 = $US16 a month, and 210/6 = 35 downloads a month. Oh, they did offer a 15 download booster pack, which means I'd get one more month at the same number of downloads.

Right. Okay. So the new plan new plan gives me 30% reduced service for 30% higher price. I'm actually not very happy about that. I'm not making any judgment about whether it's a reasonable deal, that's not the point. Such a drastic change to my existing terms is just unreasonable.

When I contacted eMusic to tell them I would have been happy with a price rise, even of 30%, but that such a significant change was very disappointing, I got a mostly canned response¹ telling me the terms of the new plan, "we truly value loyal customers," and the reason for the change was to:

... enable us to better compensate all of our labels, plus add new content from Sony starting in July, and even more new labels in the future.

I've had no problem finding any amount of music I like, so the addition of Sony thrills me not at all. If the new plan was what was available when I originally signed up, I might have been happy, but that's not the case. It's like a car salesman doubling the price after the test drive².

eMusic may well be the cheapest way to find music, but they've lost my faith. I cancelled my subscription this morning and started looking elsewhere for music.

[Update: I'm not the only one annoyed. Complain.]
[Update: According to the press release, the new tracks will only be available to US subscribers anyway. All class.]

1. I know it was canned because I got the same reply when I emailed back. ↩
2. Ok, so it's not really like that, it's more like a hire drive deal where ... oh forget it. ↩

I don't tend to upgrade my operating system until there's compelling reason to do so. Backup for the beloved's desktop machine using Time Machine, screensharing through iChat to the beloved's dad's machine to help him learn to get around, and a couple of Leopard-only applications were the things that recently pushed me over the line to abandon Tiger.

While the issues I came up against weren't terrible, I can't say that the upgrade process went particularly smoothly, but then it turns out that I didn't follow the available advice. Not advice that apple provides when you buy Leopard, but advice you find when you're searching the web when the upgrade doesn't go well, like make sure you disconnect any firewire drives.

The first time through the upgrade hung at "About a minute" to go. I left it for more than eight hours with no progress and no log messages. I had all the data backed up, and I wasn't too concerned about losing things, so in the end I gave up and forced a reboot. I changed nothing, but the second time it managed to push through the last minute and upgrade in a reasonable time.

The first problem I now had was that the afformentioned firewire drive, on which I planned to automate backup, was not visible. I tried to troubleshoot for half an hour with no luck, then shut down, power cycled the drive, and restarted. Voila, fixed.

Next, Mail showed mailboxes but no mail and wouldn't quit without being forced into it. Another ten or so blind alleys, and I came across an article from Apple telling me to move a couple of plist files out of the way, restart Mail, and move them back. Not too hard once you know how, the fun is in getting there.

Now, after running for more than eight hours, the initial backup to Time Machine has managed to copy two and a half GB out of the 100 or so it needs to get through. Given that the default is to backup once an hour, let's hope it doesn't take that long every time (you have to edit a plist file to change how often Time Machine runs).

Seems email to my twofishcreative.com email address has been failing for at least the last few days. All is now fixed, and I have access to the backlog, but if you've sent me something that you think I should have responded to, please resend. Thanks to AndyC for bringing it to my attention.

I have split myself into too many pieces. I need to consolidate.

A friend who started his PhD at the same time as me, and finished a while ago, answered a question on LinkedIn recently. Paraphrased, the question was, "Why would someone do a PhD?" and his answer was something like, "Well, you get a title, and you never know, it may come in handy some day."

Compelling reasons, for sure.

This "WTF am I doing" moment, was brought to you by the universe.

A couple of days ago we released a new version of Habari. I think this release is particularly exciting, not just because of the more than 1000 improvements and bug fixes, but because of the main feature new included; Access Control Lists (ACL).

The ACL system gives plugin developers an extensible foundation for controlling who has access to things in a Habari installation, based on group membership. Here "access" means control over read, write, edit, and delete privileges, and "things" means, well anything you can think of, but it could be posts, or admin pages, or tags, or users, or content types, anything.

A default installation has three groups; admin, authenticated, and anonymous. The user that's created when you install Habari is put into the admin group, and has superuser privileges; they can do anything. If new users are created, they get put in the authenticated group. Anyone accessing Habari without signing in is in the anonymous group. Of course, new groups can also be created. There are a bunch of pre-defined access tokens that can be assigned to groups. Here's a few of them, as shown on a group page.

On top of the default tokens, plugins can add their own. For example, the simple private posts plugin that's now bundled with Habari creates a 'private' token, which can be used to restrict access to posts to people in groups with that token.

ACL::create_token('private','Permissions on posts marked as "private"');

With this code, there's an extra permission that can be assigned to groups.

The plugin also adds a checkbox to the publish page to mark a post private. Incredibly simple.

Without the ACL, the registration plugin just wouldn't have been possible. Users can now sign up to a Habari blog and be put in a group, with associated permissions. What group? Again, anything you can think of. Maybe they could rate posts, or mod comments, or write posts.

With the ACL, and Habari's support for content types, the possibilities are limited only by imagination. An author group with write but not publish permissions and an editor group with publish permissions and you've got a simple workflow. A wikipage content type and an editor group that can create and edit them, along with the registration plugin, and you've got a simple wiki. Hopefully you get the idea.

Owen has written a good overview of how Habari's ACL system works internally, if you want to get into the nitty gritty.

Because I keep forgetting how:

gem install gem_name --include-dependencies \ -p http://[user]:[pass]@[proxy_host]:[proxy_port]

You might also want to add additional gem sources. The normal command for this is gem sources -a [source_url] but the sources command unfortunately doesn't take a proxy parameter. You can directly add a source url to this line in gem/lib/rubygems/defaults.rb.
def self.default_sources %w[http://gems.rubyforge.org/] end

For example, I added github thus:
def self.default_sources %w[http://gems.rubyforge.org/ http://gems.github.com] end

This is of course horribly hacky. If you know of a better way, please tell me.

I spent the weekend hanging out with a bunch of geeks at the first ever StixCamp, which was held at Welshman's Reef Winery, just outside Newstead, Victoria. Everything was awesome, which was definitely the word of the weekend. I think it must have been muttered on average once every 3 and a half seconds.

I'm told by reliable sources that the wifi reached to the tents, but I restrained myself and just went to sleep.

Highlights for me were Paul Fenwick's talk, "Hacking Other People's Brains", Ron's tour of the winery, the discussion led by Dave Hall about "broadband" in the bush, the vegetarian omelette that Paul Fenwick made, meeting people I'd only talked to virtually, and generally talking geek with people.

Thanks to the awesome main organisers (Ben Balbo, Dave Hall, Kathy Reid, Donna Benjamin, Joshua May).