I'm not posting to this site anymore. For continued nerdiness, head on over to thomasborowski.de.

May 11, 2012

My Fully iPad-Based Baked Blog Setup

I recently launched Tap to Create, a blog about using the iPad to create things. Initially, I didn’t even think twice about powering the site with WordPress as it’s what powers most of my other sites (including this one). But I decided I wanted to walk the talk and use the iPad for research, writing, image editing and even small tweaks to the site. I also wanted to be able to use my favorite iPad text editor to write the posts because I wasn’t going to deal with the feature-laden, clumsy posting interfaces of the few dedicated blogging apps that are available for the iPad.

So I started looking for alternatives and quickly grew fond of the idea of a “baked blog”. One of the downsides of WordPress is that each page is dynamically generated upon being requested, which can put a rather heavy load on your server and also has some prerequisites regarding your web hosting package (namely: PHP, a database (e.g. MySQL) and mod_rewrite support). You can circumvent the performance problems at least to some extent by employing caching plugins, but that increases the complexity of an already fairly complex system. In any case, static HTML files are definitely easier to handle and hard to beat in terms of performance.

Pelican

There are several static blogging systems out there, such as Jekyll, Stacey and Laguna. You can even use desktop software such as VoodooPad to generate HTML and upload it to your server. What I ended up using is the Python-based Pelican. The main reasons for my choice were that it seemed fairly straightforward to setup, it uses a scripting language that’s easy to deploy and it’s actively maintained and supported.

Pelican lets you write your posts in either reStructured Text (which I frankly hadn’t heard of before finding out about Pelican) or Markdown and transform your source files into HTML by running them through a Jinja2-based templating engine. Upload the generated HTML files and the template to your web server, and you’re done.

Setup

First off, I installed Dropbox on my CentOS-based VPS. That way, the posts I write on the iPad in a Dropbox-enabled text editor get synced to my web server automatically. I could just as well install Pelican on my desktop Mac and generate the HTML output files there, but that would mean I’d have to upload them from there to my server, resulting in a rather cumbersome and not iPad-only workflow.

Then I installed Pelican on my web server. Pelican needs at least Python 2.6. If your web server runs an older version, like many CentOS–5-based VPS do (they run Python 2.4.3), you’ll have to install Python 2.6 or newer alongside the older version. You can’t just update Python on a CentOS 5 server as that will break systems that rely on Python 2.4.3, namely the package manager yum and cPanel.

With Python installed, installing Pelican was a matter of seconds via the package manager pip. I initially installed the latest “stable” version of Pelican (2.8), but after running into some issues I switched to using the latest master branch version from Pelican’s GitHub repository.

Workflow

I wanted my publishing workflow to be as streamlined as possible. I didn’t want to have to fiddle around with copying and pasting text from an editing app into a blogging app (the blogging apps themselves actually pretty much suck for writing; go figure) and I wanted to write as little HTML code as possible. I wanted to be able to write my posts in Markdown and then, at the press of a button, publish them. And I wanted to be able to do everything using just my iPad. In the end, I arrived at a setup similar to the Pelican-powered Calepin only that I host everything myself and I can use my own theme (Calepin doesn’t let you change the look & feel of your site). Here’s how it works.

I write my posts in Elements using Markdown and save them to a dedicated folder inside my Dropbox folder. If I want to include any images in my post, I stick them into the iPad’s camera roll and first use OneEdit to resize them and create thumbnails, if necessary. I then use iFiles to upload the image files to the images subfolder of the Dropbox folder I use for my posts. Pelican is configured to always copy this folder with its entire contents when it generates the site. I then just have to make sure that I include the right links to the images in my Markdown file.

Finally, I ssh into my server from my iPad using Prompt and run a shell script that runs Pelican with a config file that contains all the necessary parameters for creating the site. The output directory is set to the actual folder that contains all the files of the taptocreate.com site. I could just as well use a temporary directory to check things first and then use a shell script to copy everything into the final directory, but I’m lazy.

Conclusion

As you can see, the workflow of my setup is pretty straightforward. The hard part was setting everything up. Since CentOS 5 is fairly old I was constantly running into problems trying to get stuff to run. Then I was running into some quirks of the rather dated “stable” version of Pelican, which is version 2.8. After switching to the latest version from Github, my problems disappeared. So, at least in my case, the latest version should be considered stable.

What this little experiment has showed me is that it’s worth looking beyond WordPress. WordPress has its advantages, like a huge community, tons of plug-ins, themes, etc. But it also comes with lots of downsides like slow performance and high demands on your web server. And the iPad app is – still – pretty unusable. If you’re looking for a way to blog using just your iPad, I recommend you check out Pelican or one of the other baked-blog solutions out there. The worst thing that can happen is that you learn something new.

Potentially Related

Follow the author on Twitter
  • Pete

    Run incron on your server, have it watch the Dropbox directory, and it can run the pelican script whenever it detects a change. That way, your work is done basically as soon as you’ve finished everything locally.

    • Anonymous

      I thought about automating the site generation, but decided against it. I sometimes forget to make a post a draft and that could result in an unfinished post appearing on the site when I save the file. I’m more comfortable writing without having to worry about triggering any kind of automatism. And after all, site generation is just a matter of SSHing to my site (which is effortless since I use keys instead of a password) and executing one script. Takes no more than a minute.

      • http://downdb.net/ Pete Brown

        Yeah, I can see that. For me, it’s more about the frictionless publishing–the less I have to do, the more likely I am to do it. I got around the draft issue by creating a desktop alias to my Dropbox folder–I save my posts as I’m writing them to a drafts folder, and then when I’m ready to publish, I drag them onto the alias. Dropbox & incron takes it from there.

        Six of one, half-dozen of the other, I guess, and mostly about personal preference. Btw–since I didn’t say it in my initial reply, I found your post to be really helpful in getting my thoughts organized around my own setup. So thanks!

  • Joshua

    Hey, great post. I’m working on a similar setup, but Dropbox is a memory hog on my server. Have you noticed this at all?

    • Anonymous

      Yeah, Dropbox isn’t exactly frugal with the RAM. Topmost process in top on my server both for RAM and CPU usage. My virtual server has 1.25 GB so it’s not a huge issue, but for smaller servers it might be a bit tight, especially if you’re running other RAM-intensive processes like memcache or, for that matter, apache.

      • Joshua

        Cool, I just wanted to make sure I wasn’t missing something. Upgrading my hosting plan now. Any suggestions? This workflow feels like magic! Thanks for the reply!

Previous post:

Next post: