Blog Tech, Part 2 - Serving and Hosting on Jekyll and Heroku

October 28, 2013

Jekyll, Heroku, and Puma

OK, so I've established that I want to write in Markdown. How does that narrow the blogging software field? It leaves a bunch of solutions available. Heck, there's even a WordPress plugin that lets you write in Markdown. But, damn it, I'm tired of managing it, and I really don't want to have to touch PHP any more.

I looked around, and noticed that Brett Terpstra (there's that name again!) seemed to really like, and then finally settle on, Jekyll. I looked into it in some more detail, and also settled on it pretty quickly.

Technology One: Jekyll

I decided on Jekyll because:

  • Its back end is written in Ruby, so it's really easy (and desirable) for me to tweak and contribute to it.
  • It's open source, under an MIT License - my favorite. I'll get into that someday…
  • It doesn't use a database. That means that the files of record are the Markdown file that I (gasp!) check in.
    • Yes, that means that my blog comments are under revision control (git).
  • The pages are generated statically. That's fine with me - it's a blog, not a shopping site.
  • It integrates well with GitHub Pages. Even though I'm not hosting this blog from GitHub, I love love love GitHub, so I figured "why not learn this tool that can work there, as well?"

Technology Two: Heroku

Now that I had a technology in mind, I had to decide where to host it. Even though GitHub was an option, I wanted to host somewhere where I'd have to do a little bit of work, and actually learn something. That's (half of) the point!

The previous iteration of this blog was hosted in DreamHost. Great if I need ftp access, full shell access, cron jobs, etc. But I had a pretty turnkey solution in Jekyll, so I decided that Heroku was a good fit.

A bit of investigation showed that there were some Heroku Buildpacks that would perform all of the static file generation at upload, without requiring me to log in and run the static file generator by hand. Score!

Technology Three: Puma

Of course, there were problems. Eventually, I found a solution to my problems, thanks to Jesse B. Hannah; serve the files via Rack using the Puma server on Heroku.

I was curious about the Puma server, so again I investigated. Turns out that it's on fire, according to New Relic's October 2013 State of the Stack: Ruby Edition. I gave Jesse's guide a try, and voila, I was serving Jekyll from my Heroku account!

At this point, things were working in a really bare-bones way. Basic HTML with no styles, served from a pretty generic-looking Heroku URL, with no JavaScript. Obviously, there's still some work to do, which I'll describe in a few days…

comments powered by Disqus