I have an Aperture library named ‘Fish and Stirling Engines’. It contains pictures of fish… and Stirling engines.
They’re not very good photos.
For giggles, another exploration in this series is a completely different animal, namely Octopress. Now, I’m not a complete stranger to command-line static site generators – I built StoryCog.com in StaticMatic, later adding a blog using the same templates and stylesheet driven by Melody (the open-source Movable Type 4 fork). Both are now dead projects, so I’ve some interest in revamping that site too.
Problems strike immediately, as the Octopress install instructions require a recent Git (currently: some old crap), and RVM (broken, somewhere). These are easy enough to fix, but in installing Ruby 1.9.something under a new RVM I seem to have nuked my gem set. Which means I’ve now completely broken StaticMatic. Oh, drat. This, incidentally, is why normal, sane, well-adjusted people shy away from command-line tools. If you live in them every day then all is well, but if you only sort-of understand them there are so many ways of screwing things up by accident, it’s just not funny.
Aaanyway: with the prerequisites sorted, time to move onto Octopress itself. And it works. OK, so I had some path problems with the configuration system, but once I’d got those sorted rsync deploy locally worked well, and the default output is pretty nice. I’m a big fan of the prebuilt video player, too. That’s the sort of thing that makes my life an awful lot simpler.
The rake/Jekyll import from WordPress worked well, and in principle I could redeploy my blog on Octopress almost immediately. So why haven’t I? Well, I may yet, but my hesitations at the moment are about time.
Publish time is an issue. On my Mac Pro, rebuilding after adding a new post takes about four minutes. It’s a single-threaded sort of thing, so I suspect my laptop would be slightly quicker (SSD, and all that), but I’m concerned that’s long enough to discourage quick posting. I note with interest that one of my favourite bloggers, having jumped to Octopress, set up a Kirby blog for quick posts. Well, to replace a Tumblr, but the point remains.
My other time issue is tinkering and learning time. While the default theme looks nice enough, it’s not completely to my taste. Delving into it is where the wheels start to come off, for me – hence my brief post yesterday. Notably, there’s precious little documentation and very few code comments on what the heck is going on in the templates and stylesheets. I love Compass, but I need help getting my head around someone else’s code of this complexity, and I suspect this is why so many Octopress blogs have stuck with the default.
Now, they’ve also stuck with the defaults because there’s plain good decision-making involved here. Octopress is opinionated software, and while I don’t agree with the choice made by the Hibari folks, most of Octopress slots nicely into my thinking about blogging. Which is cool.
I doubt I’m going to take the plunge just yet, but it’s good to know the option exists. It’s a radical platform, but I can see why so many geeks are enjoying it.
My assumption, when embarking on this little series of posts, was that I’d jot a few brief notes about the blog engine alternatives I explored by way of review. Pretty much, that would be that.
Trouble is, each of the projects I’m trying is more-or-less freeware, built and maintained by volunteers. They’ve made decisions based on how they want to use their product, and to a some extent any ‘review’ I might offer would be more a comparison between my preferences and intentions and theirs. Which is of stuff all use to anyone else.
So the short version of this post is: I wanted to like Habari, I really did. But I’m not using it because… well… I don’t. I’m sure it’s great. But it’s not for me. Here’s an example:
This is the top-level Habari menu, and pretty much the main bit of interface offered up by the system. I thought this sort of menu was cool when I first saw it in NeXTSTEP circa. 1992, but in practice I find the waggling-the-mouse-like-a-gear-lever dog-leg manoeuvre annoying as anything.
The apparent goal is to present a thoroughly minimal interface, to get out of the way as much as possible. That’s admirable, but there’s always a trade-off involved in simplicity, and for me this falls too far on the side of ‘absent’ rather than ‘simplified.’ Besides, poke only a little deeper and you quickly stumble across modal dialogue pop-ups. Habari is not, at this stage, impressing me as a system which aligns with my ideas of good taste.
Importing my blog archive (from a WordPress database) was seamless and trivial, which is great. But can I find an off-the-shelf theme I like? No. Not even vaguely. Now, again, I have very particular tastes here, but almost everything in the theme repository looks like dodgy ports from WordPress circa 2009. It’s not at all clear which remain maintained.
OK, so let’s take a brief look at how themes are built. I’ve never been a fan of WordPress’ ‘pepper PHP throughout the template’ approach, much preferring Movable Type’s template tags. Intriguingly, Habari offers both alternatives, the former via RawPHPEngine, the latter via HiEngine. But:
If you’re looking to start building themes in Habari, and you’re not accustomed to building templates using a syntax similar to this, then you should most definitely not use HiEngine. Instead, you should look into the native PHP support provided by RawPHPEngine, which is faster and better at teaching you real PHP, which can be useful when creating more complex themes.
Ouch. Yeah, we’re not going to agree on that. Heck, the last few sites I’ve built I’ve done pretty much in HAML, I’ve really no interest in going back to
?php if ( blah
) ? … whatever …
Upshot: Habari might be great, but I’m not the right user for it.