Do one thing, do it well. This is the unix philosophy. An awesome, minimalist approach to software development which resonates strongly with me. Straying from the philosophy has always been a costly endeavour in the long run for me. Tearing up blog after blog because I want something that ‘just works’. Well, this blog now ‘just works’.
And this is how I did it.
Whenever a project seems to fail, it’s time to do take a step back and analyse what’s actually going on. Why isn’t this going according to plan? Well, let’s check out the workflow for writing a simple post;
Zero productivity setup: achieved!
What I really wanted was simple enough: to spout some ideas in a text file and throw it online later. But this CMS just got in the way. Or, rather, I got in my own way - and the CMS let me.
If you’ve ever read an ebook on your tablet you probably know what I’m talking about. Sure, you can read a book on it. But it can do SO much more!
Yes, it potentially could. And that’s why I read ebooks on an e-reader folks. And that’s also why I simply don’t use wordpress or some other bulky feature-full CMS for my simple blog (anymore).
Let’s break it down - keeping in mind my profound love (or rather, need) for the ‘do one thing - do it well’ method.
I want to be able to jot down my thoughts anywhere, and fast! Even when not connected to the internet - as train and plane trips are ideal for this sort of thing.
When writing, I want a realtime experience without delays, stutters or lag. I don’t want to depend on some specific format or editor to edit my posts and drafts.
I want this blog-page-thing to be blazingly fast.
Posts need to be version controlled.
The entire blog needs close to 100% uptime.
There should be minimal to no overhead with regards to updating, upgrading and there should be no collateral maintenance (plugins, themes etc).
I want to be able to hack on the code if the situation requires it (SEO, social, gimmicks etc).
We can solve points 1 and 2 by just using markdown. This format is familiar to me, and every text editor in existence basically fulfills the requirements I gave here. The third and fifth point, speed and uptime, simply require us to use some form of CDN with caching. The sixth point, no overhead, would mean that we’d be limited to only static sites - as basically any content management system will become outdated over time and will require some form of maintenance. But then again, the seventh point means we’ll still need to use some kind of solution for dynamically generating said static content.
So our technical requirements then look somewhat like this:
Use markdown to write posts (functional req 1, 2)
Use a CDN for the frontend (functional req. 3, 5)
Use Git for version controlling the posts. (functional req 4)
Use some form of static site generator. (functional req 6, 7)
Hexo is a node.js based solution for generating (pseudo-)static sites. But the beauty of Hexo really becomes apparent once you use it to publish your site to github pages.
Editing a post just becomes part of the same workflow we use day-in day-out. Open up the repository, fire up our favourite editor and edit the existing post, or create a new one. Commit the changes, push, and voila! You have your source-controlled, markdown written posts. Awesome!
Want to deploy what you’ve made to github pages? No problem. Just setup your
_config.yml, and type
hexo generate --deploy. And done!
Now blogging has just become part of my daily development workflow. Added benefits are that github uses their CDN to present your site worldwide. Oh, and of course it’s lightning fast and free.
So, what do you think - are you ready for some hacker blogging?