I finally got around to modernizing this old site, which has included moving from WordPress to a statically-generated, Amazon-hosted site based on Pelican and Bootstrap 3.

I’ll write more about the site’s implementation later because I ended up diving into different areas I think are worth documenting, such as extending Pelican via plugins and some specific issues with hosting a static site on top of Amazon AWS. For now, suffice it to say that if you find any files missing please let me know, as this is probably something I’ve simply forgotten to copy over to the new site.

(Support for IE 8 and older is right out, on the other hand; use IE 10 or better to preserve your sanity.)

I just found a great web site providing a better Kindle content search than what’s baked into Amazon: eReaderIQ.com. You can search by price, publication date, reading level, and whether the book you want is in the public domain, among other things.

For example, this query lists only free Kindle books in the public domain. Very handy.

Once again I’ve up and moved my whole little site here to a new platform — Wordpress 3, this time around, on top of Nginx + PHP-FPM + (obviously) MySQL on FreeBSD 8.1. I think I’m making a tradition of tearing down the site and rebuilding it from scratch once every, what, two years? Or maybe I’ll actually manage to keep it fresh this time around…

Heh.

Anyway, I could ramble on forever about why I ditched Movable Type and went with friggin’ WordPress. (What kind of wannabe hipster web developer doesn’t roll his or her own Django / Rails / whatever blogging software? And PHP?! Son, I am disappoint.) But that’s not what this post is about. This post is about a minor detail of how I exported the old site from MT.

You see, Movable Type supports text entry in Markdown format. And it’s cool and groovy and way better than typing out HTML by hand, but the problem is that when you ask MT to export your site, it exports your Markdown posts as unprocessed Markdown, not as HTML. So when you then attempt to import this into a program that doesn’t understand Markdown (e.g., WordPress), you end up with something resembling an explosion in a punctuation factory.

But as usual, Perl to the rescue. Pipe your Movable Type export file through the following simple script (you may need to install Text::Markdown from CPAN or your friendly neighborhood package manager first):

#!/usr/bin/perl

# mt-export-markdown.pl: Process Movable Type export files
# containing Markdown posts into pure HTML.
#
# Mark Shroyer
# Mon Oct 11 01:37:52 EDT 2010

use warnings;
use strict;

use Text::Markdown qw(markdown);

while (<>) {
    print $_;
    if ( /^(?:EXTENDED )?BODY:$/ ) {
        my $source = '';
        while (<>) {
            last if ( /^-{5}$/ );
            $source .= $_;
        }

        if ( $source =~ /^</ ) {
            # If body looks like it's already HTML, just echo it
            print $source;
        }
        else {
            # Otherwise run it through the Markdown formatter
            print markdown($source);
        }
    }
}

That done, simply import the resulting file as usual with WordPress’s Movable Type and TypePad Importer.

Now that Firefox 3.5 is out, I wanted to get it running on my 64-bit Debian 5.0 laptop—but there’s no 3.5 package in Sid yet, as of July 2, and mozilla.com only carries 32-bit binary tarballs for Linux. So I had to build Firefox 3.5 from source. Fortunately this turned out to be a lot less painful than I had imagined; this post will show you how I did it, in case you’re in a similar spot.

$ sudo apt-get install build-essential libidl-dev autoconf2.13
$ sudo apt-get build-dep iceweasel

$ sudo apt-get install mercurial

$ hg clone http://hg.mozilla.org/releases/mozilla-1.9.1 \
mozilla-1.9.1

$ cd mozilla-1.9.1
$ hg checkout -r FIREFOX_3_5_RELEASE

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-firefox
ac_add_options --prefix=/opt/firefox
ac_add_options --enable-application=browser
ac_add_options --with-system-zlib
ac_add_options --with-system-jpeg
ac_add_options --enable-optimize
ac_add_options --enable-official-branding
ac_add_options --enable-canvas
ac_add_options --enable-strip
ac_add_options --disable-tests
ac_add_options --disable-installer
ac_add_options --disable-accessibility
ac_add_options --enable-xinerama
ac_add_options --with-default-mozilla-five-home=/usr/lib/firefox-3.5

$ make -f client.mk build

$ sudo make -f client.mk install

$ /opt/firefox/bin/firefox

$ hg pull
$ hg checkout -r FIREFOX_3_5_1_RELEASE
$ make -f client.mk build
$ sudo make -f client.mk install

This evening I had the chance to download Google’s newly-released (and by “released” I mean “beta”… hey, it’s Google) web browser, Chrome, and give it a try. They weren’t kidding when they said V8, the new JavaScript virtual machine in Chrome, should raise the bar for next-generation JavaScript implementations: it’s fast. How fast?

The above results are from Mozilla’s Dromaeo JavaScript performance test suite, so there’s little worry of this test being intentionally biased in Chrome’s favor. The scores above are the averages of five test executions on each web browser, running in the same Windows XP virtual machine on the same computer. Some notes:

• Each run of the test was performed in a fresh browser instance.
• IE 7 was unable to complete the test suite without crashing, although I am using a special, standalone version of IE 7 so this may be particular to my installation.
• In order to prevent IE 8 from complaining about the long JavaScript execution time, I set set the registry value MaxScriptStatements = (DWORD) 0xffffffff in the key \HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Styles.

So yes, Chrome does in fact have a much faster JavaScript engine than any other current web browser: in this test, more than eight times as fast as Firefox 3.0.1’s engine, and more than thirty times as fast as the latest beta of Internet Explorer 8. But how does the rest of the user experience stack up?

I want to love Chrome, I really do. Although currently a Firefox user, I am a huge fanboy of the KHTML / WebKit rendering engine due to its speed and superior standards compliance, and I was thrilled to see it put to good use as Chrome’s HTML renderer.

But as of yet, the user interface is far too constricting to make this a good general-purpose web browser. Here are some things that one cannot yet do in Chrome:

• Manage cookie and scripting settings on a per-domain basis…
• …or heck, disable JavaScript and plugins at all.
• Synchronize one’s bookmarks with copies of Chrome on other computers, à la Foxmarks or Opera Sync.
• Interactively inspect a web page’s DOM as with Firefox’s Firebug, or Opera’s Dragonfly.

The dearth of advanced features may be a real gotcha here: Chrome lacks both Firefox’s infinite extensibility and Opera’s rich built-in feature set, so power users spoiled by Opera or Firefox may never be satisfied with Google’s new browser, no matter how well it performs.

But even those of us with no interest in using Chrome itself stand to benefit from it in the long run. My hope is that Mozilla and others will take the best ideas in Chrome — most notably, V8’s performance optimizations and the browser’s comprehensive sandboxing model — and adopt them for future releases of their own web browsers. That way, we all win.

I finally got around to trying the Linux version of Opera 9.50, the newest version of the Opera web browser. Here’s what I think of it after a couple weeks of using Opera 9.50 as my main web browser, particularly how it compares to Firefox 3.0.

Things I like in the latest Opera:

• Tab management, particularly the “Create Follower Tab” feature: You can make a new tab in which any links from the current tab will be automatically opened. This can be great for reading the news.
• Site preferences: Manage cookie, JavaScript, and other preferences on a site-by-site basis from a single location.
• The new rendering engine has better CSS compliance than Firefox, and it seems to handle poorly-designed sites with much greater grace than in previous versions of Opera.
• Plugins such as Adobe Flash appear to be handled using a child process and IPC, making the browser resilient against Flash crashes. This can be done with Firefox too, but it requires the separate nspluginwrapper program, which isn’t installed by default on 32-bit versions of Ubuntu.

Things that I still prefer about Firefox 3.0:

• I initially loathed it, but the Awesome Bar has really grown on me. I miss it when I’m in Opera.
• Firefox automatically scales large images to fit within your browser window; if there’s an option to do this in Opera, I haven’t been able to find it.
• Firefox offers spell-as-you-type spell checking in text entry fields, whereas Opera (on Linux, anyway) only provides a “click here to check spelling” type of functionality.
• Firefox lets you preview RSS and Atom feeds before subscribing to them.
• Extensions: In some shape or form, Opera can perform the basic functionality provided by Firefox’s NoScript, Cookie Monster, Firebug, and Foxmarks extensions, but cannot match these addons’ full feature sets. Other Firefox addons, such as Live HTTP Headers, Adblock Plus, Unplug, and CustomizeGoogle, appear to have no analogues in Opera.
• Opera does not obey your local QT theme for the positioning of its scrollbar buttons, so you can’t easily use NeXT-style scrollbar buttons in Opera on Linux. (Firefox 3.0 obeys your GTK+ settings in this regard.)
• Opera’s stability has gotten much, much better since 9.26 and the 9.50 betas, but it still crashes every so often. Meanwhile, Firefox 3.0 has yet to fail me.

So that’s my little mini-review. If you haven’t given Opera a try yet, now would be a great time to do so. But if features and flexibility are of the utmost importance to you, you’ll probably end up sticking with Firefox.