Rubénerd!

Mac legend Brent Simmons writing "How We Work Together":

To swim with the current these days is to use git. But I like Mercurial better — and I think Mercurial is to Macintosh as git is to Windows. That’s probably not fair or rational, but it doesn’t really matter, since both git and Mercurial are excellent systems.

I have similar sentiments. While I find Mercurial to be a far better fit personally, I made the switch to Git largely because most of my favourite projects now use it. Which is to say, they use Github.

I do have a couple of private hg repos on Bitbucket, but I'll probably be making the switch to Git soon. A smarter person could juggle both systems, but I prefer just using the one. Heck I only just stopped using SVN for my personal projects last year, and CVS for my FreeBSD updates.

Good heavens, remember CVS? I may prefer Mercurial, but wow Git is a lovely warm cup of tea compared to that!

It's with a heavy, nostalgic heart that I bid farewell to the Camino web browser. According to the last blog post on the Camino site, it's no longer being actively developed.

Camino was Mozilla done right on the Mac. It took the same Gecko rendering engine from Firefox, wrapped it in native Mac Cocoa instead of XUL, added keychain support, and a bunch of other useful Mac features. It had a quintessentially Aqua icon, and tastefully coloured toolbar buttons that dared to challenge the plain toolbars of Safari.

I loved Firefox on Windows and *nix, but was less than impressed with its performace on my iBook G3 with Panther and Tiger in the early 2000s. I made the switch, and only moved back to Firefox on my Macs a few years ago. I like having all my security and privacy extensions back in Firefox, but I still think the user experience in Camino is superior.

I wish all the developers the best in their newer, greener pastures in Safari, Firefox and Chrome development. And thank you.

How I've been doing it:

for (; s1Begin != s1End; s1Begin++) {
    if (*s1Begin != *s2Begin)
        return false;
    s2Begin++;
}
return true;

And how I saw my UTS lecturer Gordon Lingard do it:

for (; s1Begin != s1End; s1Begin++, s2Begin++)
    if (*s1Begin != *s2Begin)
        return false;
return true;

Provided one has overloaded the == operator:

if (mind == blown)
    cout << rubenerd.post() << endl;

As for the photo? I didn't make it, it's from Wikibooks. Or at least, it used to be in 2007. Well played in any case ;).

No, I'm not referring to dating Jekyll, I'm already taken. I'm also not referring to those fruits that oddly enough I don't care for.

I couldn't figure out why posts with a defined date weren't appearing in my local Jekyll install. In the YAML matter, I'd written it as such:

date: 2005-01-24 12:00:36

Some more astute readers may already see the problem, but I was scratching my head late at night wondering why.

Turns out, you need to define the timezone:

date: 2005-01-24 12:00:36 +1000

It makes sense. If my base is UTC, that time I defined above wouldn't have happened yet, and I had configured Jekyll to not post items from the future. I mean, I'm not part of the USS Relativity's crew or anything.

If you have Perl warnings enabled (like a good developer), chances are you've seen something like this when executing your script:

Wide character in print at ./[file].pl line [x].

As with everything in Perl, there are Many Ways™ to deal with this.

The first is to include the following line along with your regular Perl boilerplate. I always write my scripts and text files in UTF8, so this merely enforces UTF8 output.

binmode(STDOUT, ":utf8");

This will deal with those warnings, and let you get on with your work.

An alternative is to enforce UTF8 for STDIN and STDERR, as well as STDOUT with this line.

use open qw/:std :utf8/;

And of course, there's always a trusty environment variable.

export PERL_UNICODE=SDL

Updating to the latest version of Jekyll, I got the following error when attempting to migrate a WXR file:

You must install the 'jekyll-import' gem before continuing.
* Do this by running `gem install jekyll-import`.
* Or if you need root privileges, run `sudo gem install jekyll-import`.

Sure enough, along with an entirely new site, Jekyll now uses importers instead of migrators, which reside in their own gem. Unfortunately, attempting to install this resulted in a new error.

ready % gem install jekyll-import
ERROR:  Could not find a valid gem 'jekyll-import' (>= 0) in any repository
ERROR:  Possible alternatives: jekyll-ebook, jekyll-epub, jekyll-reposter, module-import

It turns out that jekyll-import is still technically in beta, so needs to be installed thusly:

ready % gem install jekyll-import --pre

At the time of writing, this works in my bog standard RubyGems environment on Mac OS X 10.8.3, with the following dependencies and docs installed:

Fetching: fastercsv-1.5.5.gem (100%)
Fetching: nokogiri-1.5.9.gem (100%)
Building native extensions.  This could take a while...
Fetching: jekyll-import-0.1.0.beta1.gem (100%)
Successfully installed fastercsv-1.5.5
Successfully installed nokogiri-1.5.9
Successfully installed jekyll-import-0.1.0.beta1
3 gems installed
Installing ri documentation for fastercsv-1.5.5...
Installing ri documentation for nokogiri-1.5.9...
Installing ri documentation for jekyll-import-0.1.0.beta1...
Installing RDoc documentation for fastercsv-1.5.5...
Installing RDoc documentation for nokogiri-1.5.9...
Installing RDoc documentation for jekyll-import-0.1.0.beta1...

Don't you love headlines that can be answered so easily? From Infoworld, one of my favourite sources of whitepapers which I read for a hobby because I'm a nerd:

The Ponemon Institute's research study, entitled "The TCO of Software vs. Hardware-based Full Disk Encryption," claims to provide an answer. The study, conducted last year, polled more than 1,300 IT and IT security professionals in four countries -- the United States, the United Kingdom, Germany, and Japan -- for detailed information about their use of and expectations for hardware-based full-disk encryption.

Perhaps its because I had a long day, but I reread that paragraph at least five times, and I kept seeing "Pokémon Institute".

The results, recently reanalyzed with new insights provided in a follow-up paper, showed that full-disk encryption came at a fair cost, in big part because of the time and labor involved in deploying it. But the perceived benefits for using full-disk encryption far outweighed those costs.

An interesting read, but nothing surprising. Whole drive encryption would have added tremendous computational overhead to already slow machines back in the day, but today there really aren't any good [technical] reasons for eschewing (gesundheit) it.

From an enterprise perspective, the biggest arguments I've heard against it have been those initial deployment costs, and the added potential complexity for data recovery. That's not a problem though, because everyone backs up. R-right?

Then there's the issue of vendor support, or lack thereof. Mac OS X, the BSDs and all major Linux distributions ship with whole drive encryption as a configuration option, but Microsoft's BitLocker is only offered on the non-consumer flavours of Vista, 7 and 8.

It's regrettable Microsoft places more importance on artificial product differentiation than the privacy of their home customers' data. No catching 'em all today.

Don't download the Windows Cisco Packet Tracer, then put it in your lowest spec VM to save precious SSD space, then let the installer run without problems, then try running it. It won't work.

This has been a public service announcement by me.

Perhaps its a remnant of my dial-up days, but I'm one of those old fashioned people that keeps local copies of all the stuff I download. Saves me having to download them again if I need to reinstall.

In the case of Xcode 4.x, components are downloaded and installed from the Preferences screen, but you can still keep the downloaded disk images by navigating to:

~/Library/Caches/com.apple.dt.Xcode/Downloads/

Ironically enough, I only remembered this again when I was going through my home folder backups, and realised my Caches folder was way larger than it should be.

After hearing about it on my beloved 5by5 Back to Work, I finally started using TextExpander. Today, I realised it can be used with my lifehacking language of choice.

Way of the future

TextExpander lets you assign blocks of text (or even images) to a shortcut you assign. For example, when I type ;nc it expands out to all my ncurses boilerplate. ;sig expands to my name, address, email, EARLs and phone numbers. You could leave it at that, and be crazy productive.

But you don't have to stop there. If you create a new shortcut and choose choose "Context: Shell Script" from the top of the editing box, you can write shell scripts to process stuff. I ignored it initially, largely for the same reason I eschew (gesundheit) most Western fast food. I can eat it, but I prefer other things.

Earning some Siracusa cred

On a hunch this morning, I decided to test the limits of this "Context: Shell Script" box and enter some Perl (which of course I inserted with its own TextExpander shortcut!):

#!/usr/local/bin/perl [...]
print("Hello, world");

When I typed my ;test shortcut, Hello was inserted in it's place.

Oh. My. SCIENCE.

That's right, TextExpander took the output from this Perl script, and used it in the substitution. Think of the possibilities. No, seriously, think of them.

I've used Perl scripts, a Dock shortcut and the Mac pasteboard to automate and send results to where I want since 2004. Now I'm going to go through them all and see how I can make TextExpander shortcuts for all of them.