Let’s talk about the steps behind my typical blog post:

1. visit my blog;
2. log in to the admin area;
3. find the “new post” page;
4. try to evolve a story in the comparatively tiny textarea provided for my thoughts;
5. invoke full-screen mode in the “rich text” editor, painfully aware that I hate both MS Word and typing in browser windows;
6. trigger at least one accidental “back” keyboard shortcut in my browser while trying to delete a line of text;
7. trigger at least one “open that closed tab back up please” keyboard shortcut in my browser while trying to undo a typo;

and so on and so forth. I eventually give up, fire up Byword or Sublime Text, write like a grown-up, and then copy-paste the result into the blog.

At that point, the blog’s editor decides that I can’t possibly have meant the formatting I typed, so reformats it so it can display it “properly”. Usually, that means messing up blockquotes or code snippets in the process.

It’s not long before this particularly twisted aversion therapy has robbed me of any desire to write.

You can’t always get what you want

Because here it is: I want to write. I don’t want to fight a losing battle with a web page that thinks it’s a text editor. I just want to make the clicky sound until the muse leaves me.

I just want to write.

This is a solved problem. It’s been solved for as long as computers have had screens that can display text. I have a text editor, and I have a filesystem.

But this is the problem that blogging software seems determined to solve again. We already know how to create and edit documents, and how to store them for distribution. Blogging software gets in the way of that. It’s an overcomplicated, user-hostile step wedged in between the thoughts in my head and the eyes in yours.

Build and be damned

And so I’m typing this in Byword, and you’ll read it on the internet in a nice template, and in between us are a few lines of Ruby. No, not those few lines. There’s no database. There’s no “admin area”. There’s a server, there’s some memory, and there are some documents.

Not a document store, documents. Text files.

My Ruby code started out traversing a directory, grabbing any markdown files in there, and loading them into a memory cache for display on the web. It progressed to understand a rudimentary file format:

• First line: title of the post
• Second line: “type” of the post, and an optional publication date
• Rest of the file: markdown content
• File name (minus extension): url slug

This was shipping to the web via a little Sinatra app, but it was easy enough to switch up to Rails because, you know, that’s my hammer, and my goodness this looks like a nail. I shoved it up on Heroku for now, and it ran like a charm.

The biggest problem with that approach was tying edits to code deploys. At that point, why not just write plain html files?

But hey, all I’m doing is grabbing some files from a directory, and loading them into memory. I could get those files from anywhere, and it turns out that Dropbox has a beautifully simple API.

The right feature instead of the wrong problem

So here I am: my blog grabs my posts from a directory on Dropbox, caches them, and serves them up as needed to you, my dear readers.

My process is now:

1. open a new text file on my MacBook, or on my iPad;
2. write

The real problem with blogging software, it turned out, is that there was just too damn much of it.