Introduction To The Introduction

I'm lazy. I run two WordPress blogs, and I don't keep their software up-to-date. I should upgrade within hours of the update being released, but it once took me months. In my defense, I'm busy. But that's a weak defense. I'm a computer professional. If my blogs got hacked it would be a professional embarrassment. If I can't keep my act together, I'll bet that most people are worse. (OK. I just took a break and updated both blogs. I had to. I couldn't publish this with my blogs not up-to-date.)

But I don't want to have to update WordPress again and again and again. I want something that basically supports itself. If I set up automatic payment to my web host, I want my website to continue forever. Software should not need regular maintenance. (If you've noticed that I'm writing a piece of software to avoid updating a piece of software, please keep it to yourself. Thinking about that makes me sad.)

I produce two types of things I want to publish on the web -- my words, and my photographs. So SPBS must be capable of supporting my blogging habit, my long-form essays, my poetry, and my photographs. It may become the SPCMS, but SPBS certainly sounds better to me.

Many things -- among them the possible purchase of Yahoo (and Flickr) by Microsoft, at the time this was written in Feb. 2008 -- make me realize that we really need to control our own data. It is not acceptable to me that my photographs and the metadata about them exist only on Flickr. (I have all the photos on my local hard drive, but there's tremendous value in the captions and other information on Flickr, which I have nowhere else.) So SPBS must be flexible enough to support many different kinds of content and the metadata about that content.

All programs are written by humans, and have bugs, at least at first. Most pieces of software have a slowly growing bug count. As old bugs are fixed, new features are added and new bugs creep in. And some old bugs are never reproduced or resolved.

But some software has such a narrow scope, and was written so well to begin with, and has been used for so long and passed through so many examinations that it is worn smooth, like a pebble in the water. I aspire for SPBS to be that. Knowing my own limits, that means I'll have to keep it simple and stupid.

No Web Interface? WTF?

Any piece of software I write WILL have bugs. Any bugs that are exposed to the outside world have the potential to be exploited. The only way to avoid that is to avoid exposing your code to the outside world. That's a large part of the philosophy behind SPBS. An SPBS blog can have all the Javascript, auto-generated pages, and other gimcrackery of any other blog. Though to be fair, you will undoubtedly give up some interactivity -- there's some things you can do with WordPress or Movable Type that you just won't be able to do with SPBS. And that's fine. If you need those things, use one of those products. SPBS has as few points of failure as possible, which tends to limit what you can do with it.

By using software to generate the blog, but using only actual HTML, CSS, and Javascript to display it to visitors, we avoid an entire class of attack. We become pretty-much impossible to hack. (Our web host could get hacked, which would get us hacked, but there's not much we can do to prevent that, other than choose a good web host. We're probably better off with almost any web host than we are hosting it ourselves, so the trade-off is worth it.)

This also means that you can use your favorite text editor to write blog posts -- use whatever you want; it's all good. If it can save plain text, it will work with SPBS. (If you don't have a favorite editor, you should get one. If you're on a Macintosh, TextMate is a sure bet. When I ran Windows, I loved TextEdit.)

Since you're editing and processing the files on your local computer, you'll use scp or ftp or rsync to publish files to the web host -- making SPBS compatible with almost every web host that's ever existed.

No Comments? That Blows!

Yep. Hard to dance around that one. I'd really rather have a full-fledged comment system. Even voting and moderation, like Slashdot. And I may write a really simple comment system in the future. But it would be REALLY hard to convince myself that any web-facing code is so simple and bulletproof that I can consider it maintenance-free.

So here's what I've come up with as a least-sucky alternative: embed a Google AJAX search box where the comments would normally go, showing the pages that link to that particular page.

To find all the pages that link to Mark Pilgrim's "Don't F--- The Babysitter" blog entry, you would construct a Google search like this:

link:http://diveintomark.org/archives/2004/06/16/babysitter

This does add a dependency on Google, but it's for comments -- which aren't a core function of the blog. And if the blog were unmaintained and Google changed their API so the search no longer worked, people could still do it themselves off the site. (We'll use the same reasoning when we produce a search feature for the blog.)

People have to write comments on their own blogs, linking to the post they're commenting on, and their comment would show up in the Google results sooner or later. It's not ideal, but it works, in a bare-minimum sort of way, and does enable the kind of conversation that blogs are supposed to be about.

In addition, this makes the elimination of spam and the ranking of comments Google's problem. That's vastly preferable to having that be SPBS' problem.

No Database? What You Smoking?

Databases can get corrupted. They sometimes need maintenance. And they're just one more moving part in a universe determined to destroy moving parts. Plus, they can be a bottleneck. Database issues are behind most sites that die under the Slashdot/Digg/Reddit/whatever effect. The database was at the heart of Twitter's problems. By cutting out the database, we again avoid an entire class of problems.

This is partly inspired by some of Tim Bray's writings, particularly this one on the design of his comment system.

There's nothing I can do to make a blog immune from a denial-of-service attack -- but this step, more than almost any other, helps mitigate the impact on hosting providers. As Tim Bray said in the link above, "systems are some of the world’s most thoroughly-debugged and battle-hardened code. Also, most modern operating systems are really quite clever at noticing when part of the filesystem is getting hammered and caching the whole thing in memory, so you may never go near a disk." A system based on static HTML and CSS would probably be stable under loads that would take down most database-driven sites. (I'll be doing testing on this in the future, comparing SPBS to WordPress and Movable Type.)

You're Not Going to Make Me Do Everything Myself, Are You?

No, don't worry. There's a couple of principles we'll adopt to keep your workload minimal. This is about laziness, remember?

First, of all, we believe in DRY. (Don't Repeat Yourself) You'll have to know some HTML and CSS to put an SPBS site together, but once you get the framework going, you'll be writing entries in Markdown (which is as simple as it gets) and then running a script to publish them to the web. (SPBS has a pro-command-line bias, at the moment.)

I'll also probably put together some automation to integrate with TextMate -- and possibly MarsEdit as well. But it'll be open sourced, so anyone can integrate it with anything.

No Authentication? How Do I Have Editors, Writers, Etc. Work on My Site?

Authentication is hard. Your web host already provides authentication in the form of ssh or ftp logins, so we're not reinventing the wheel. We use that built-in mechanism to control "write" access to SPBS. You might be able to hack something together using file-system permissions to support multiple people. But really if you need a robust system that supports multiple authors, editors, contributors, etc., then SPBS isn't for you. It's primarily designed for one-person blogs. That's the sweet spot where ease-of-maintenance and "surviving being ignored" really pay off.

What Are the System Requirements?

As few as possible. This will work with almost any web host that has ever existed. (The only requirement on the host side is support for SCP/SFTP, and the ability to serve out .html and .css files. If your web host can't do that, they aren't a web host.) I'm building this as a framework around open-source tools built by other people. And those tools are SO much easier to use on Linux, even compared to OS X, that that's probably where I'll do the development of the client-side tools at first. Once I've got the Linux version going, I can probably be expected to create an OS X version. If you want it to run on something else, port it yourself.

I'm Too Lazy to Do Backups

Me too. Once you get over the shame and humiliation of being a backup-slob, you can deal with your limitations. One key design element of SPBS is that there are no backups. There's no need -- backups are all about making sure everything is in at least two places, and by design we'll ensure that nothing is only in one place, ever. (Except for brief periods while you're changing things. But once the publish process finishes, your data should be fully redundant.)

Should I Use SPBS for My Own Blog?

At the moment, absolutely not. I'm not even using it for my own blog. As it approaches completion (or at least, not completely sucking), I'll start asking if anyone wants to alpha test. But since this is so closely tailored to my own needs, it may not be useful to anyone else. We'll see.