Blog engine hot swap: from Wordpress to MicroClog
This entry marks the transition from my use of Wordpress software to a small monster of my own creation, which I have named MicroClog.
Of all the things I've lost...
I first switched to Wordpress, from Blogger, about three years ago.
For a long time, I felt that I wasn't crazy enough to write my own blog software. So, in a totally sane fashion, I:
Meticulously wrote all of my blog entries in reStructuredText, complete with metadata, in my own Mercurial repository
Converted that reStructuredText to HTML with my own custom extension to Docutils' rst2html capability
Copied and pasted the HTML from the rendered file into Wordpress
Updated the metadata in Wordpress by hand
Of course, with every edit, I repeated all of these steps.
Now, this wouldn't be so bad, if writing weren't such a damn perfectionist art. I'm not sure the average number of cycles I took around this loop of automation apathy for each blog entry, but I would guess it was around five. Each trip around the loop I hated it more.
They say that the definition of insanity is doing the same thing over and over again, but expecting different results.
Eventually, I snapped, and decided something had to be done. [*]
I think I've successfully channeled my gripes into the implementation of MicroClog. I hope that, ultimately, greasing the wheels on this process will help flush the 83 entries in my drafts folder (along with a small handful of unfulfilled promises to write something) out to the internet.
The idea behind MicroClog
Writing about code is a total pain in most blog engines. Writing in reStructuredText rocks.
MicroClog chooses reStructuredText over WYSIWYG/HTML editing and existing distributed revision control systems over a in-blog-engine revision control system. The current workflow for MicroClog is:
Write a blog entry in reStructuredText on your local machine
Commit and push the changes to a repository on the host server
The host server's repository hook renders entries that have changed
Entries designated for publishing are publicly visible
There's also ways to share drafts in a restricted fashion. I'm currently hacking together a "live preview" on the server side for the reST entries you're editing on the client side, using the fancy new server-sent events API.
Ultimately, there are a few simple tasks that I want to optimize for:
Start an entry and dump a stream-of-conscious text in it
Share draft entries with proofreaders
Converge on a publication by iterating a read-and-tweak cycle
I love writing in my text editor — especially when writing about code — but I also want to marginalize the advantages WYSIWYG has over markup by getting live previews as smooth as possible.
There are some more sordid incentives for me to have all my blog data easily queried and manipulated in a Django app. A few of the features I'd like to try adding in the future:
- First class updates
I would really like to support the idea of an "update" or "followup" as a first class feature — manually hacking old entries to point at newer ones with followup content is lame, and engine support for that kind of workflow isn't difficult.
- More widgets
I've always wanted to have a widget where I could select a handful of my hundred-odd drafts and generate a poll where users could select the title/intro blurb that was most interesting to them. Knowing what people are interested in reading gives me additional motivation.
- Decoupling syndication and entry labeling
I find that tying planet syndication directly to the feed generated for a label has been bothersome. Sometimes I feel like I want to syndicate an entry to a planet but that label isn't appropriate, or sometimes I don't want to syndicate an entry to a planet but I do want to use the label.
- Statistics pr0n
Because data is fun to look at. Some ideas I've had:
tf/idf style analysis to suggest tags automatically
Plot of entries correlated against start/publish date/time
Start-to-publish duration versus word count
The good left undone
I'm still writing the software out of a private repo, because I've perpetrated some epic hackery in the interest of shipping.
There's a bunch done, but there's a lot more cleanup, generalization, and feature implementation to do. My day job isn't at all webdev related, so if you're knowledgeable and interested in helping me generalize a system like this for public source release, feel free to get in touch!
Yes, I considered writing an extension to Wordpress, but I took a personal vow to stop writing PHP quite some time ago.