Here’s a little ditty about Ted’s blog, new and old. In case you were wondering.
Back in 2005, having wanted to move away from my own home-grown Java Servlet/JSP-based blogging system (and that was a fun little implementation, let me tell you about it sometime), I decided to go with something out-of-the-box. Basic decision-making criteria anybody has around whether to “build vs buy” were in play here: what I wanted wasn’t really all that different from what anybody else needed, and I couldn’t justify the time required to build and maintain my own bespoke system, particularly since I just wanted to blog more, not write blogging software more.
So after asking around for a bit, I ended up installing dasBlog, a popular .NET-based blogging system. It was nice, and since I was having a new website commissioned for me (again, buy vs build here), I asked the designer to “skin” the blog in the same style as the website. That’s how TedNeward.com came into being, and the corresponding dasBlog blog system–which many of you afterwards told me you sort of hated, from a colors and fonts and other aesthetic criteria perspective–came into existence with it.
Fast forward ten years.
Frankly, the system had grown creaky and kind of painful. Yeah, OK, so it was nifty and cool back in 2005–heck, it had support for a feature I really thought I wanted: the ability to email a blog post in to the engine and have it posted! How cool! I could write blog posts offline (while on an airplane, perhaps!), and then poof, upon landing and reconnecting to the Internet, the email would whisk off, and without even my paying attention, blog post!
That offline-editing capability that I thought I really wanted… yeah, I never really used it. I set it up, sure, but then promptly forgot the particular “rules” the email had to follow in order to work correctly (Subject has to be prefixed with blah, To must be written like blah, and so on). So that never really panned out.
More importantly, though, it was always in the back of my mind that dasBlog’s architecture was a teensy bit suspect.
Effective Enterprise Architecture
See, here’s the funny thing about a blog: it’s a read-mostly system. For every single web hit that contains some kind of data that changes the system (a la a new blog post), there’s hundreds if not thousands of hits that are entirely read-only (a la you, dear reader). That means that the decision to re-render the page to be sent back is really a ton of wasted work. Ideally, a system in this situation would cache off the work spent doing the rendering, and only re-render on demand.
This cache can also be known as “saved HTML files” to the lay person. In many respects, that’s the best kind of cache, because the system can simply pipe the HTML directly down the pipe, with no additional processing required. Should somebody edit the blog post, the system can re-render the HTML, write it to disk, and we’re back to piping what is essentially static HTML right down the pipe again on a new (read) request.
This was actually (sort of) what my first blog system did: each time I inserted a new blog post, it wrote a new JSP file to the disk. If I edited the post, it loaded the JSP into a giant text box for editing, and then when I submitted it, it wrote the contents of the text box back into the JSP file, and lo and behold, we were back to (almost) straight rendering.
(The first blog actually was an attempt to see if that “rewrite JSP files” could and would actually work in a production environment, particularly if I used servlet filters–instead of servlets themselves–to do the various “controller” kinds of things. That way, the URL to a given blog post was a straight JSP page URL, which seemed the hip and cool thing at the time.)
And the thing is, dasBlog didn’t do any of this “caching” or “pre-rendering”; every time you hit the engine, it was re-rendering the HTML from scratch, which always struck me as a waste of CPU cycles and memory. But it worked, and I was happy, for about a decade.
Until it didn’t.
You’ve all noticed it–the system as of late had gotten kinda slow. Wasn’t sure why (was it the blog engine, was it the amount of stuff it was hosting, was it the hosting provider, …?), and honestly, didn’t really care why. It was time to move on.
But… I have all these cool incoming links to my blog, particularly around the Vietnam of Computer Science post, and Lord knows I don’t want to lose those. (For crying out loud, how many times do you get linked from Wikipedia?!?) So I needed something that would preserve the old links (or at least redirect correctly), but I really wanted to get back to just straight static HTML if I could. And it would be nice if somehow I could get “pretty” URLs, instead of these (now-considered) ugly URLs that contain file extension information.
So I put the call out onto Twitter, and lo and behold, the answer came back: Jekyll (the gold standard for most folks), and Hugo, which my buddy Matt Stine suggested, and which happens to be written in Go, not that I really cared too much about that. (One wise guy suggested Perl; I promised him coal in his stocking in return. That was the extent of my concern over implementation.)
Hugo has worked out pretty well, so far–being a static site system, I write content as Markdown files, and then ask Hugo (a command-line tool) to re-gen the entire site. (I have mixed feelings about that–on the one hand, I understand why, but on the other, it feels wasteful most of the time.) Then, since I’m now trying to do most of my static site hosting at site44, I just copy the files over to the appropriate folder inside my Dropbox (to which site44 is attached), and lo and behold, I have deployed.
I had to write some kind of transformative script to take the old dasBlog XML files and convert them over to Hugo’s Markdown format, but that was pretty easy; getting the old aliases and categories into the front matter was the trickier parts, and I gave up on a perfect 100% port–as long as the script got 90% of the aliases right, I was happy, and hand-corrected the remainder to match what the old dasBlog engine had generated.
What didn’t come over
I didn’t want obstacles to stand in my way, so I deliberately chose to leave comments behind. (They’re still preserved in the old dasBlog files, if I ever want to try and pull them out and attach them, though.) A static site system can have comments, but not the same way that blogs like dasBlog stored them; systems like Disqus or Discourse tend to fill in the blanks here, and frankly they do a better job with comments than dasBlog ever did, so I’m OK with losing the (often contentious) comments of the last decade in exchange for a more powerful, consistent and SEOable system now. And hooking Disqus up took literally five minutes: sign up for Disqus, put my website in, generate a UID for it, plug that in to the Hugo theme I’m using, and voila! I have comments.
Can’t really beat that.
There’s still a few things I need: analytics, for example. (Hello, Google Analytics!)
And, at some point, I want to actually move all of this over to my professional site, in order to allow me to have two blogs, one “professional” and the other “personal”, but that may be a pipe dream at this point; in theory, I’d like to have a blog attached to my named domain (tedneward.com) that isn’t tied to my professional life, but I don’t want to lose whatever branding I’ve created for myself if I can help it. shrug Something to worry about later.
In the meantime, the new system means it’s now much easier to blog again (yay), and my next step after this (very shortly after this) is to hook up the blog content directory (from which Hugo generates the site) in my source-control system to a CI system, so that now I can write a blog post, commit it, walk away, and the CI system will see the checkin, generate the site, and deploy the resulting static site to the proper Dropbox folder to deploy.
Wouldn’t that be COOL?