A Brief Bit of Context
In 2011, shortly after moving to Denver, Colorado, I relaunched my blog. I had been, happily, using self-hosted Wordpress for a number of years. However, I felt I was missing out on a learning opportunity by not making a CMS for myself.
It was around this time that I had switched to writing in markdown for personal note taking. I was also interested in exploring a non-database approach; blog posts would be written as flat files. I had some ColdFusion framework scaffolding for application management I wanted to further noodle with and responsive web design was begging to be explored. In short, I didn’t just want a place to dump words; I wanted a sandbox to play in. Viola! A Blog!
I learned a lot, which was the point. But, as time passed, there were a number of wrinkles that didn’t have easy fixes without effort and/or host changes:
- URL’s maintained the “*.cfm” ColdFusion extension, something that was increasingly dated. URL rewriting was possible, but that seemed like a workaround for what should be naturally occuring behavior.
- Secure, encrypted communication (“HTTPS”) was problematic on my shared host, even in the age of Let’s Encrypt. Given that HTTPS actually is served faster, I was increasingly bothered I was not only insecure, but slower than I could be.
- I hadn’t gone far enough with the “static site” approach. Writing the articles in markdown was a start. But then processing them through a server continued to have all the security risks while netting none of the performance upside. Very little of what I was doing required run-time processing.
- Deployments felt dated. While development teams I collaborated with in my day job had shiny, new deployment pipelines, I was still setting up FTP (not even SFTP!) and overwriting files. This is minor (I don’t believe every passion project needs the complete continuous-integration-laptop-sticker-sheet). But it felt dated.
Static Site Rendering
The benefits of static site rendering are numerous:
- SPEED - There’s no processing server side; posts have already been reduced to the essential atomic units of the web: HTML, Javascript, and CSS. There’s something poetic to me about that.
- Security - While not so much an issue with my own coded CMS, I lived in constant fear of missing a zero-day Wordpress exploit patch and finding myself, along with clients, compromised. Reducing the number of moving parts significantly decreases the places where something might go wrong.
- Hosting - Rather than having to find, research, and deploy to increasingly rare ColdFusion hosts (or port to another language), I can post my content to anywhere that supports HTTP/JS/CSS. hosting. This becomes very compelling given that Github Pages, one option, is free.
Jekyll is great. Feed it html and markdown and out comes a blog. Moving over my custom pieces, already organized as one file per post, was trivial. It was just a matter of changing my custom XML, used to define titles, tags, etc. to Jekyll’s Front Matter YAML. Jekyll is written in Ruby but, for my purposes, it really doesn’t matter; I fire up a command line, capture my word-junk, and Jekyll does the rest. Kin Lane has been estolling the virtues of Jekyll for awhile. I’m just now catching up. Jekyll is free to download and run locally on your machine.
My New Writing Process
After I finish a piece, I push the resulting changes, rendered by Jekyll into static content, to a Github repo. This not only gives me a record of changes over time; it also populates a Github page. This means my blog is able to leverage the same hardened infrastructure that Github uses to run the rest of its operation. Github Pages is a free service for public repos.
Github page sites, understandably, have Github URLs by default. Maintaining my own domain name is important to me. If I should ever move, for whatever reason, I should be able to change the host without requiring everyone to update their links. A custom host, registered with Hover.com, is the abstraction that allows me to do that.
Unfortunately, Github Pages don’t easily enable SSL for custom domain names. For that, I added Cloudflare to the mix. Cloudflare is a CDN, or Content Delivery Network. They own a ton of hardware and geographically scatter it about. They then replicate content distributed through them to each of these nodes. When you make a request, the content is returned from the closest server, not whatever server the content originated from. The result is speed. But, not only that, Cloudflare can be configured so content can be delivered through its network via HTTPS, and not just HTTP. Given my needs, Cloudflare usage is free.
At this point, I can render a static site from markdown with Jekyll, deploy new updates via Git, host it on Github Pages, point to it with a custom domain, and secure it with Cloudflare. The last hurdle is take requests mistakenly made to HTTP URLs and reroute them to HTTPs (and thus avoiding the dreaded ‘mixed content’ browser nastigrams. Thankfully, Cloudflare saves the day here, too. I’ve got a smoking fast, secure, and reasonably sound site for the cost of a domain name and some elbow grease to put the bits together.
What’s Left to Do?
I have, in fits and starts, been porting over previous content to the new site. I have content from 2015 and newer moved. References to the REST API Notes newsletters go back to the beginning of 2016. More to do there but having a couple years worth of the most recent material is not nothing.
The design is spartan, at the moment. I’ll probably let this grow organically, as the need arises.
I also am missing sub-navigation dynamically driven by a tag. For example, in an article about APIs, I could drop in some script that would create in-line navigation that would link to my other pieces about APIs. If I wrote a new piece and used the specific tag, the navigation would be updated automagically. I still need to figure out how to make this work in a static-site generated workflow.
Doesn’t Medium Already Do All This?
After a thousand words, I’d assume the rational question would be “Why not just get a Medium blog”? Medium is great for enabling discovery. I also have load of respect for Ev Williams and his track record in making the web a great place for creators (Blogger, Odeo [which was ahead of its time], Twitter, and now Medium). But, increasingly, Medium seems like a failing experiment and less like a finished product. In trying to find a business model that works, Ev has acknowledged that successful web monetization pushes publishers to ‘all car crashes, all the time’. That really, really makes me nervous about the longevity of any content contributed there.
But I am privileged. After decades of practice, I can suss out the techno-gobbledygook and cobble together a working site. A vast majority either can’t - or won’t. We need more viable options, not experiments, for the creation, hosting, and discovery of ideas. Until one of those happens, however, I’ll continue to be here, figuring out how to make this work on my own.
Update 7/19/2017: Troy Hunt has a fantastic piece on CloudFlare and unhealthy security absolutism.
Update 7/20/2017: Another Troy Hunt piece, discussing why the web is quickly going to secure by default. I had heard about non-secured sites being punished in search engine rankings, but the browser implications are as compelling reason as any.
