Unfinished Again
.
San Francisco
At the time of writing, the last entry on this site was posted in 2010. That’s quite a long while. I’ve been blogging elsewhere instead: Tumblr, for example. This site has sat here in digital decay because of the ease of writing on different software.
In 2005 I switched away from my initial blogging platform—b2Evolution—and followed my friends to WordPress, which was clearly the way to go. (Oh, how we scoffed at Movable Type for its crusty static page generation and Perl.) Also, none of us had the time management, inclination, or understanding of blogs as a medium to go and write their own system.
It’s worth noting that as far as my experience with writing and technology went, building on WordPress worked out pretty well. I’ve written more, ever improving content to the point that I’m now quite pleased with my writing ability. I really enjoy the process of it, too. I’ve had various opportunities to write in other places and for other people as a result of the practice I’ve gotten from my blog. Currently I’m writing monthly for The Pastry Box.
Then two years ago, my final project for Yahoo involved moving WordPress into their internal infrastructure. I can’t understate the benefit of working with code I already know well.
The rot on this domain started for a handful of reasons, that in the shiny gleam of a new site are worth covering. It reflects the shift in what’s important about writing on the web for me.
Syntax.
I set up WordPress with Textile, so all my posts from 2004 through 2010 are written up in that syntax. But I found a preference for writing in Markdown; a cleaner, more logical syntax for my tastes. I needed a system that would support the old and new syntax choices simply.
Comments.
The commentary on commentary has been a popular meme already this year, but for me it boils down to three tangential things that arrive in the same place:
- Often the quality of comments left on my site are low. Of those that are of high quality, they’re trapped in a packed stream of all the others.
- Filtering spam is a ridiculous pass-time.
- Philosophically, I believe you should own your words. I think that ideally, everyone should have their own space on the web and they should respond to one another by expanding discussion with something of substance. I think that since hosted blog services are now commodities: Tumblr, WordPress, Posturous, et al, and that this is an accessible enough option for people. For communicating the proliferation of these distributed discussions (and for pieces of feedback that don’t warrant an entire post), we have made up for the automated spam infested failures of Trackback and Pingback with the manual, human success of Twitter.
Together, these justify not having comments on my blog. All the old discussions are still here—of course—and all have their original #comment-1234
permalinks on the pages, but they’ve been exported into the entries now, and I’m not hosting any subsequent discussion.
In place of commenting on the site, I’d like people to message me on Twitter (like this), or other systems (email, IM, etc.), and simply tell me about interesting follow-ups they have or have seen. I’m an admirer of other sites (such as Matt Gemmell’s, and John Gruber’s) who don’t have comments, but who make an effort to post follow-up entires documenting expansion and dissent. I’d like to give it a try.
Back-up Paranoia
The third big reason for wanting to move from WordPress is that I want to continue self-hosting my blog, on a VPS host, with all of the benefits of running my own software persistently on the internet, but I wanted to lower the risk to the content I’ve written. WordPress runs in a MySQL database. That database needs to be backed up often. I am negligent about doing this. Therefore, an architecture that enables me to keep my content safer is preferable.
This time, the answer to that is git. Git’s nature as a decentralized system means that everywhere the repository is checked out, all the data is there too. So on my Mac where I’m writing this post there’s an entire back-up of my site. I’m storing the repository for my site on GitHub, so there’s another copy there (plus whatever back-up strategy they have in place.) Then there’s another remote copy of my site on my webserver itself. Three copies easily created just to write a post. If I edit a post from the office, I’ll automatically create another back-up there, too.
The second benefit of the content being in git rather than a database is that the posts now exist not as a query of multiple tables, but as a single denormalised text file. The content of the posts and their metadata are accessible even after the front-end of the site is gone. It’s crude, but also intrinsically robust. With growing collective awareness of how frail the internet is (see Archive Team) this is a quality I value above most others. It’s logical to build this next experiment with my own site with that value at the center.
There’s an awful lot more to write about the how and why of building a site this way. There are costs to it to, of course. For now though, I’m really pleased with my redesign. There’s more to do, and it will never be “done”, but I rather hope you like what I’ve made. Here are some forthcoming post summaries that you should hassle me about if it seems like I’ve forgotten to write them:
- Experience with Jekyll, ruby, git and how everything currently in the back works. There are various hacks and plug-ins I’ve made for Jekyll I can repackage and share.
- The design philosophy behind the site. It’s very simple, and I want to draw attention to how and why. There’s no numerical pagination, for example.
- The downsides. Of course, there’s a cost to a crude data storage system, and one reliant on git, of all things. I need to write up the limitations I planned for, the ones I ran into later, and how I plan to fill the gaps.
Links
To share this entry, or reference it in commentary of your own, link to the following:
- Permalink: https://benward.uk/blog/unfinished-again
- Shortlink: https://bnwrd.me/1hpzp0
You can file issues or provide corrections: View Source on Github. Contributor credits.