Blogging, Statically Speaking

The concept of blogging using a staic site generator isn’t news. People have been doing such things for years, now. There are fantastic static site generators out there (Jekyll, Hugo, Pelican to name a few) and all have their unique features, quirks, and ugh moments.

I wrote a post a wrote a post a while back about moving over to Jekyll from WordPress. Within a couple weeks or so, I had moved back. I never posted why, but the reason boiled down to the generation time. It took Jekyll upwards of 90 seconds to two minutes to generate every time I wanted to updated something–anything, really. New to Jekyll 3, the --incremental argument didn’t do anything and I wasn’t comfortable leaving Jekyll running in --serve mode in the background1.

Needless to say my views on running this blog with a static site generator are a little jaded. Recently the idea of using Hugo (written in Go) was suggested and I gave it a whirl. Go was wasy easier to set up and get running. I also found myself looking at several front-end UIs that can be bolted onto Hugo so I don’t have to edit .md files all over the place then work out some git magic to push changes and have them be re-deployed2.

There was one component that I just couldn’t get into this potentially new workflow, though, and that was integrating any of my writing apps without having to also introduce manually saving an editing. I use Desk for writing my blog posts, including this one, and it does a killer job. Within a few clicks, my post is live and I didn’t have to git push a damn thing.

Really it seems as though I’m torn. I like the idea of speed and simplicity. I like the idea of not having to maintain a MySQL database and PHP. I don’t like the idea of trading that work (something I’m already super familiar with and have down pretty well for my needs) for a different kind of maintenance. I can deal with maintaining a server, but if it takes more than minimal effort to get a blog post up, I’m not sure I’d be interested in the alternative.

Did I mention the migration? Never have I ever had my 270 something (as I post this) posts all move over without at least moderate tweaking required. At this point, the amount of effort required to transition would negate any savings. And I’m kind of lazy.

I doubt I’m the only one that feels this way and I’m sure there are a ton of other ways to go about solving this problem. I might never go back to a static site generator, again, and I’m ok with that. If WordPress becomes faster, hooray! If it is no longer written in PHP, I’d feel even better about it. In the meantime, I’ll continue doing things the way I’ve done them since January 2015, almost 18 months ago.

1. As much as I don’t mind writing custom service scripts for systemd, I don’t feel like I should have to resort to that just to make a quick page update [↩](#fnref-3062-1) 2.  I did this with Jekyll, and I’ll share that in a future post. [↩](#fnref-3062-2)

Harder Than it Should Be: Jekyll Word Count

When I was running this site through WordPress, I had a plugin that would count the number of words each of my posts contained and give me some metrics. It was a pretty slick plugin and had all sorts of visuals.

With Jekyll, I don’t have such capabilities out of the box (or even remotely close to the box) so I went hunting for a plugin. I found one, and it works, but it’s slow, and I don’t really think there’s much that can be done about it. Given the static nature of Jekyll, it’s not really easy to save persistent information somewhere like in a database without also having a plugin for the database.

The plugin brought down my build to a crawl (140s over 13s) and GitHub didn’t whitelist the plugin, so it was pretty much a non-starter.

Needless to say, I pulled it, but if you want to see the commit where I added it, go here (then the subsequent commits here and hereHere’s where I pulled it).

For the record, before this post: 92,205 words. With this post: 92,392 words.

How I Made Jekyll Post Generation Just a Touch Easier

Now that I’m running my blog using Jekyll, one thing I’ve already found to be rather frustrating is the post generation process. I have a blank .md template I open, save in a new location, then edit, but that seems cumbersome, to me. What I decided to do instead is write a quick Ruby script that generated a post .md file for me based on the information I provide.

Thought Process

I wanted to keep it simple, and just do only what I really needed. I don’t need any fancy logic or checking. I know _posts will be there because I put post_generator.rb inside my Jekyll directory.

Working Example

Here’s my code as it stands inside right now:

It’s functional. It’s not clean and could be refactored a but, but it works.


A few things that came to mind after I finished: – Use the system date if none is provided – Re-format the title with title-casing. Without ActiveSupport in Rails, I’ll have to either require it as a gem or write something by hand. I’m thinking the former. – Allow the user to write the post right there in the command line and not have to open a text editor. – Allow the user to choose which text editor to use at the prompt (perhaps with detection?)

It’s a good first draft and it serves the purpose I had in mind. Here’s the GitHub repo.

page 1 of 2