Safe from the Losing Fight

At the risk of becoming part of something trendy (which my nerd contract expressly prohibits), I’ve finally ditched Wordpress in favor of static solution. Unlike everyone else though I’m not ditching it for performance reasons, because honestly, I don’t get enough traffic to bring down London bridge, which, according to a song I once heard is constantly falling down.

No, what prompted this change was my Wordpress install getting hacked for a third time (to inject spam links, of course). It’s not entirely Wordpress’s fault; each time my version was out of date, despite Wordpress making updating to the latest version super easy. Unfortunately I don’t go the Wordpress admin panel every day to check for updates, so I’m routinely out of date.

All of which to say, I needed something other than Wordpress to get around my update delinquency. Specifically here’s what I wanted:

• Little to no code running on the server, with a strong preference for none. No database, either.

• It should generate a static site, from flat text files.

• It should be able to import all my Wordpress entries

• Support the Wordpress site/link structure so that it wouldn’t break existing links into the site.

And a couple of nice to haves:

• Support some version of Wordpress themes, or at least make it easy to port them.

• Work with MarsEdit

In other words, I wanted Wordpress without the Wordpress.

There were a couple of solutions that got close, but none that did all that I wanted. So, being an engineer, I decided to write my own, which I codenamed Postword. I actually started the project back the last time I got hacked, and even used an early prototype for the blog on Hearts & Tactics.

Postword is more or less a collection of Ruby scripts. It has one to take a Wordpress XML file and convert it into a bunch of flat files (one for each post) that can be processed later by the build script. The flat files are nothing special; they have mail like headers for the categories and title, and then body which is just text with some HTML markup allowed. The build script takes these flat files and builds a full site that looks like Wordpress site structure wise. The script is unique in that it supports the idea of themes, whose API just happens to be the exact subset of Wordpress APIs that my custom Wordpress theme happens to use.

And that’s all Postword was up until a couple of days ago. But if was going to use Postword on this site, which I update somewhat frequently, I needed to reduce the friction. The first thing to do was to write a publish script that pushed the local static site to my server via FTP. I wrote my own script in Ruby, which actually turned out to be not that bad, since I could make a lot of assumptions. The important one was that the local site was always the truth. Which meant if the local and remote ever differed, the local overwrites the remote, and if the remote had a file which the local didn’t the remote gets deleted. In effect, the site becomes self-healing.

The last piece of the puzzle was create a local server that MarsEdit could talk to. MarsEdit supports a lot of different APIs, so I had to decide which one to implement. Wordpress was an obvious choice, but it offered a lot of functionality to I didn’t have or want, plus it was more complex than the others. I decided on MetaWeblog, with the Blogger API as a fall back for when MarsEdit tried to delete a post. It was surprisingly easy to implement, since almost all of the functionality was already in the other scripts, and Ruby provides an XMLRPC server out of the box.

The really nice part of all this is I now have the entire source to this site (flat post files + images + build scripts) in one Mercurial repository. I can download that and publish from any machine, as well as have instant back ups.

Not to say Postword isn’t without its flaws. The build script is slow; it takes a little while to generate all those archive pages that Wordpress creates on the fly. And if the build script is slow the publish script is glacial. When posting from MarsEdit, I can’t actually call the publish function after building the site, because MarsEdit will time out on the HTTP connection. That said, the pros easily outweigh the cons for me.

All in all, I’m tickled pink about how Postword turned out.

I’ve been meaning to write about some of the major problems that I have with the App Store, both the Mac and iOS varieties. But honestly, I don’t have a whole lot to add to what Wil Shipley and Craig Hockenberry have already said. Instead, I’ll link to the bugs I’ve written up, and encourage you to do the same.

• The App Stores need to support upgrade pricing. rdar://11131356 or Open Radar

• The App Stores need to support free trials. rdar://11133210 or Open Radar

• The App Stores need to support tracking statistics. rdar://11133330 or Open Radar

• The App Stores need better discoverability of apps. rdar://11133573 or Open Radar

I know there’s been a lot of pessimism about writing up Radars lately, including from yours truly. But the truth is filing bugs is the only official way Apple will listen, so the pragmatic side of me wins out. It’s not that I necessarily think filing bugs will cause a change, but it’s the only possible way of affecting changing that’s been given to me.

Recently Apple has been closing a lot of Radars with the response of:

We are closing this bug since our engineers are aware of the issue and will continue to track it.

This baffles me for a couple of reasons:

1. Isn’t the point of Radar (a bug database) to track issues that you’re aware of? If not in Radar, how are Apple engineers tracking them? Storing them in /dev/null?

2. Of course your engineers are aware of the issue, I freakin’ told them about it.

So I’m not sure what Apple means by this response. Word on the street (by which I mean Twitter, since we engineers certainly don’t go outside, much less into the street), is that it’s supposed to be a “polite” way of saying “we’re not going to fix it.” But I’m not sure why they wouldn’t just say “it works as intended”, which is what they used to say, or simply “it will not be fixed.” Have engineers gotten more sensitive over the years and Apple is afraid of rejecting them, fearing Foxconn style suicides? (Note to Apple: if I sign an affidavit stating my office is only one story high, will you tell me the real reason why the bug is being closed?)

Regardless, Apple is already so opaque when giving feedback about bugs, that a lot of engineers have given up filing bugs in the first place. Apple doesn’t seem to grasp that we’re doing them a favor by telling them where their bugs are. Radars seem to be treated more as an annoyance, than as valuable feedback.

But my main problem with “our engineers are aware of the issue” response is it’s very unclear what Apple’s trying to say. Even if they rejected the bug report in the past, even if it was for a lame reason, you knew where it stood and could do a minimal amount of tracking of it via the Radar. But now there’s not even that.

So to get to the bottom of this issue, and to increase the chances of irony, I’ve filed a Radar (Bug # 10777677, non-Apple people see OpenRadar). I’ll let you know if Apple engineers are aware of the problem and if they’ll continue to track it.