Bye-Bye Jekyll
What can I say? The only constant is change, and I’m alright with that. I have decided to switch from using Jekyll to Hugo for the site, and with that I’ve decided to switch the theme I’m using as well. While I lose my “landing page”, I think this works just fine.
So why did I change things? To be completely honest, it was an efficiency issue. I liked the Jekyll themes more than the Hugo themes, but to be fair I was also looking for darker, two column themes for the site. However once I started using Jekyll, I quickly left the “honeymoon” phase you experience when you start using new tech, and I started to get a bit frustrated.
What I Didn’t Like
Let me be clear right off the bat - Jekyll is a great static site generation system and it just works. I had no issue starting things up and going rather quickly. Themes were easy to install, although I have to say I wasn’t a fan on how you used themes with Jekyll. Essentially you have to pick a theme, download it, copy it to your main site and start manipulating it. This would make switching themes later a bit trickier, but it was hardly the worse thing in the world.
Where things started to really break down for me was in two areas:
- The infrastructure requirements.
- The incremental build process.
Infrastructure Requirements
Jekyll is a Ruby-based static site generator, meaning you need to have Ruby installed locally in order to use it. I run Windows for my main machines, so I had to install a few hundred MB worth of Ruby to get Jekyll to work. Again, nothing wrong with Ruby (I mean Metasploit is written in Ruby, so I’m not about to start throwing stones here) but I am trying to watch the space on my hard drive because I’m old and that’s just how I like it! And yes, being a former Java developer the irony of that statement is not lost on me.
Starting up Jekyll is another beast altogether. Rather than something like jekyll build or jekyll server, you must use bundle exec jekyll build or bundle exec jekyll serve --incremental. If I planned on continuing with Jekyll, then I absolutely would have written either an alias or other script to just do this for me in a single command.
Unfortunately that will never happen, and it’s all because of this next thing.
Incremental Build Process
I’m a huge fan of the watch command available to most modern build systems today. Basically you run your build, but you have a process watching the file system for changes and the build system quickly recompiles and re-deploys for you. I used to use JRebel to do this years ago with Java applications, which was a huge boon for those of us doing backend Java development work and wanting to avoid the whole compile, package, deploy process manually. Thankfully Jekyll offered this up as well! This is awesome since I like to write, save, and preview my work regularly just to make sure my Markdown skills are up-to-snuff. And it’s great, but only when it works. Unfortunately for me, it wasn’t often.
I found myself constantly staring and the same old code, over and over again. Worse was when I went to write something new and it didn’t show up on the landing page. I realized that drafts and posts that were dated for a future date wouldn’t show up by default, so I adjusted the configs to help with that, and it did work sometimes.
Unfortunately I ran into one major drawback that really bothered me. I found that I had to stop the server, run a bundle exec jekyll clean first, then go back and run bundle exec jeckyll serve --incremental to get new posts to show up. At first I thought I could live with this, but I was wrong. Since I was setting up the site and I had a few new pages that I was building, this happened more often than not. Would I have the same use case as this blog rolls on? Not likely, but it happened enough that I wanted to find something else. Build times are fast, often a few seconds, but the fact that I had to jump through hoops to get my site up and running was upsetting. I decided I wanted to try something else.
Welcome to Hugo
I actually looked at Pelican and Hexo in addition to Hugo. MkDocs was also floated to me as another alternative, but I decided to go with Hugo. I liked the themes, and I liked the way I could filter them a lot more than the endless scrolling I was doing with other frameworks and their respective themes.
I actually found the same theme from Jekyll ported to Hugo! In fact there were at least 3 variants of it that were ported to Hugo! Overall they were a lot easier to use than the ones in Jekyll, but there was still something about them I didn’t like. There was some difficulty in lining up icons just right, and somehow the layout suddenly seemed stuffy to me. It’s similar to when you move a couch to another part of the room and you don’t like it. Same feeling. So I decided it was time to find something new. The final result is what you see before you! This is the Hugo Future Imperfect Slim theme, and I think it fits what I was looking for just fine.
Migration Madness
Migrating from Jekyll to Hugo was about the easiest thing I had ever done! The configuration for this new Hugo theme was as simple as copying over a sample configuration file, setting up a git submodule (shudder), and typing in hugo server. That’s it. I copied over my Markdown files as they were from Jekyll, and everything just worked. There were some minor tweaks since not all the pages mapped (for example, the category and tag pages didn’t have equivalents in this new theme), and of course the path for the images was different. Headers for each page needed a small tweak as well, but I’m not 100% convinced that was required.
Not only was the command to compile and go into a watch mode for Hugo shorter, it was faster too. A few milliseconds to compile and launch everything! There was no need to install Ruby, and I stuck with the Windows executable for Hugo rather than using one of the other package managers they listed for Windows. I’m not doing any Go development at the moment, so I’m not going to install any of their tools if I can avoid it. I just downloaded the executable, added it to my path, and now we’re off to the races!
Do you want to know the best part? The incremental build system just works. Nothing fancy, no need to restart, clean, purge caches, or anything else. It just works. And just like Jekyll, I can do all my editing within Visual Studio Code. I must say, Microsoft really does make some of the nicest editors on the market.
Technical Goodies
Some of you may be interested in how I’m hosting this blog or why I didn’t go with WordPress, or just stick with the existing WordPress site I have for the podcast. Allow me to start with the latter, then move on to the former.
Why Not WordPress
I don’t like WordPress. I use it for the podcast because there is a great plug-in called Seriously Simple Podcasting that takes care of a lot of the heavy lifting. I already had a VPS for some other projects I was doing years ago, so I figured it was easy enough to re-use it for a podcast platform. Since I didn’t like some of the hosting options for podcasts, I figured I’d give it a go on my own. Old habits die hard you see, since I used to do some DevOps work in addition to my security duties back in the day. This naturally meant I had more faith in myself than anyone else. Yes, I’m still regretting that decision due to the extra overhead.
This leads to the reason why I didn’t want to use WordPress. The maintenance of WordPress alone, not to mention the underlying host, is a lot of work. I also wanted something distinct from the podcast, which is why I have a new domain and all the rest for this blog. While the podcast is collaborative considering the number of guests I bring on, I want this blog to be an homage to myself and my own personal work. So yeah, I needed a separation from my other venture.
There’s nothing wrong with WordPress. A few people told me about a static site plugin for WordPress, which is awesome! The only downside is that I need to have a WordPress installation to use it, and well … no thank you.
How I’m Hosting Now
I’m running a bit of an experiment with this blog, and it’s something I’ve wanted to do for at least a few years now. I’m completely serverless, hosting this through a collection of Amazon Web Services (AWS) services. Here’s the breakdown of what AWS is charging me for:
- S3 for file hosting
- Cloudfront for CDN/Web Hosting
- Lambda for some routing help
- Route 53 for DNS
- IAM for user management
Now I’m not going to go into technical detail on each of these steps here, but if you’re interested, check out this blog post for details. Marcelo does a nice write-up on the same type of setup that I did. His section on why Cloudfront and S3 don’t always get along with smart URLs definitely saved me a lot of frustration.
In addition to using AWS, I’m storing my source in GitHub and I’m using CircleCI for my continuous deployment system! That took a bit of trial-and-error to get working, since I’m used to Jenkins myself, but I must admit it’s a nice setup. Obviously I can tinker with this stuff endlessly, but I’m happy with what I have right now. Good enough is an appropriate phrase for what I have for a simple blog. Naturally I do have a private Trello board for enhancements, but those can wait for another day
Long story short, using Hugo with AWS is awesome. Very little for me to worry about, and I can keep my costs microscopic compared to traditional hosting or even VPS-based hosting. Plus since everything is static, I only have to worry about website defacements, but hopefully even that is limited. The process for the blog is now very simple. I write, I push to GitHub, I get an email if something is off in my Markdown, and CircleCI will handle pushing out regular updates for me. It’s a nice system.
That’s about it! Thanks for checking out the blog again, and I hope you like the new layout. Apologies to those who have to re-subscribe to the RSS feed, but in all honesty it’s a small price to pay, and I figured it’s the cost of being an early adopter. Take care.