the candler blog

Remote Blogging with Octopress

Technology

It’s time again to blog about blogging. I wanted to share a bit about my Octopress setup, specifically how I was able to travel to SXSW this year with nothing but my iPad and could still update this site (most of the time). Tuck in, I’m going to head into some nerdy weeds here.

Octopress is a static blog generator based on Jekyll. I switched the candler blog to it from Wordpress back in January, but only after I confirmed that I would be able to run the site from my iPad. This is roughly what I came up with back then. The short of it:

  • Write a new post on iOS in a Dropbox plain text editor and save it to /Dropbox/path/to/site/source/_posts
  • Generate and commit the site via SSH to a private repository hosted on Beanstalk
  • Auto-deploy the public folder to my Web server

Here’s how it’s done.

Dropbox

Any Octopress site is basically a single folder full of ruby scripts, your original Markdown writings and the complete HTML site that gets generated every time you write a new post. On my computer, it just looks like any other folder with a series of sub-folders and files within it. The final site, which gets written to a folder called public, is what I push out to my server; it’s what you’re reading right now.

The entirety of the site lives in my Dropbox folder on my Mac at home. That means the source documents, the “guts” of Octopress that actually generate the site, and the final site itself are all synced up to Dropbox. One advantage here is that my site gets backed up to Dropbox’s servers, but that’s not the real reason I use this method.

Almost every iOS writing app worth its salt can sync documents via Dropbox. Since Octopress posts are simply plain text files with the .markdown extension, I am able to access my posts on my iPhone and iPad from anywhere. Thanks to some TextExpander snippets I made (another post for another day) I can quickly create new posts in any of these editors.

When I write a new post and it syncs to Dropbox, it will automatically sync back to my Mac at home. From there, I need to generate and push the site.

SSH

OS X makes it fairly straightforward to allow SSH tunneling on your Mac. This Mac|Life article offers a decent walk-through of how to turn SSH on and use your router’s port forwarding features to allow you remote access. This may all sound like a bit much, but I promise, if you can use the command line well enough to run an Octopress site, this is a piece of cake.

Once SSH is turned on and your machine is accessible, you can access your machine (securely, mind you) from anywhere in the world via a command line. On iOS, I use the excellent Prompt from Panic to SSH into my home Mac. Once I’m connected, then I can generate and push my site right from the Dropbox folder.

Here’s the main wrench in the works. This remote workflow hinges on your home Mac being on all the time, or at least when you want to post remotely. There are some hurdles to making sure that happens including keeping your machine from falling to sleep, making sure there’s a bit of ventilation where your Mac is so it doesn’t melt and making sure that the Internet connection goes uninterrupted. Unfortunately, this last one is my biggest headache because of a Lion Wifi bug that I can’t seem to stamp out. Yes, I could hard-wire my iMac to my router, but, well, I haven’t.1

Lucky for me, I had someone at home I could annoy to reconnect the Wifi when OS X Lion decided it didn’t want to be online anymore.

Beanstalk

Octopress’s documentation offers a few ways to deploy your site to a Web host. It basically boils down to pushing your site out to a Git repository with front-facing capabilities, like Github Pages or Heroku. I cut my teeth on Heroku deployments, which I highly recommend for a free way to learn the ropes of Git and Octopress. Ultimately it was untenable for my site. I needed a solution that would work with my current Web host.

Enter Beanstalk, an incredibly simple version control host. I use Beanstalk to host a private Git repository. Using their built-in deployment tools, I can automatically send only the changes made to the public folder to my Web host over FTP. You can set it to do this on every commit or you can use a special tag in the commit message to let specify which commits should be deployed. Once the changes get pushed, my site is updated, and that’s it.

Seriously Backed Up

It may seem like overkill, but the Dropbox and Beanstalk duo provide multiple layers of site backups that far outweigh any kind of precaution I used to take with Wordpress. Not only is the site hosted on my home computer (and any local backups I retain), but 100% of the code, including older commits, are hosted both on Dropbox’s servers and on Beanstalk’s. Furthermore, Beanstalk keeps its own backups, outlined in their documentation:

For all paying accounts Beanstalk automatically sends incremental backups to a remote data center every 10 minutes to ensure minimal loss in case the primary system fails completely or is corrupted.

Again, that’s 100% of the Octopress install, not just the front-facing public folder. Beanstalk’s lowest tier is $15 per month for 3 GB of storage, which is far more than I conceive using in the near future for my site. Comparatively, Vaultpress, Automattic’s official Wordpress backup solution, introductory tier costs $15 per month. Beanstalk, of course, is much more than backups. Check out their features page for what else you can use it for.

Remarks

I get that this is a bit convoluted and imperfect, but it works for me. This breakdown leaves out a few details that I would like to write about later, namely using TextExpander snippets for Octopress syntax, creating git aliases to streamline command line posting and which iOS writing apps fit into this workflow the best. Eventually, I’d like to cover those topics more in depth.

For now, I’d love to hear whatever remote workflows readers may have come up with. Happy static blogging.

  1. There are a slew of ways to solve this, namely getting a real hosted solution up and running or sending a Mac Mini to Mac Mini Colo. But I’m focusing on my little plan here.

Comments