Forecasting the future of technology has always been an entertaining but fruitless game. Nothing looks more dated than yesterday’s edition of Tomorrow’s World. But history can teach us something useful: not to fixate on the idea of the next big thing, the isolated technological miracle that utterly transforms some part of economic life with barely a ripple elsewhere. Instead, when we try to imagine the future, the past offers two lessons. First, the most influential new technologies are often humble and cheap. Mere affordability often counts for more than the beguiling complexity of an organic robot such as Rachael. Second, new inventions do not appear in isolation, as Rachael and her fellow androids did. Instead, as we struggle to use them to their best advantage, they profoundly reshape the societies around us.
This is such a great article from Tim Harford, a must read to understand how we have been always wrong while foreseeing where the technology is moving. Especially important is the fact that it was never the big-bang technological advances that changed the world.
But many world-changing inventions hide in plain sight in much the same way — too cheap to remark on, even as they quietly reorder everything.
Tim calls it the “toilet paper principle”. Again, so apt. He has a detailed run-down of many such important, but often overlooked events that deeply affected the multiple phases of industrial revolutions. Do read this article. It is a nice summary of what we have been getting wrong about the technology over time. Also, it lets us reevaluate our perspective and beliefs on where we see the advances to be coming from.
Everyday, I have a lot many thoughts about Medium these days. For some reason, I find it is turning out to be not so good a platform for writers. Unfortunately, even the reading experience is slowly degrading.
The posts there are too disparate, with the platform really struggling to present them in an easy-to-comprehend manner. Especially the fiction. A dark emotional rant on life is placed right next to an erotica. Yes, erotica.
For some reason, Medium has no strict and defined policy around how to publish, tag and present these NSFW posts. It just is no reader’s paradise if one has to be fully attentive and on look out for these posts and people around you. Sigh! By the way that option you have to “Show fewer stories like this”? Yeah, about that. It does not work. Not sure if Medium team even has any backend logic coded for that. Bruh!
And don’t even get me started on how horrible Medium is for writing on the go.
Yes, that is a help document on “How to write?”. On an iPad. Not really sure what all is involved in writing a post on Medium that it can’t be done with Safari on iPad. Dumbfounded.
I have recently converted my blog to a website and, as I have already documented, I serve it as a static website. I have preferred this approach over a dynamic one that gets driven by a full-fledged blogging software or a publishing platform. Of course, these were not the only possible options. As is so well captured by Christopher Heng at his website1, the options are just too many.
It wasn’t an easy call to select one, it never is. Every option one chooses has its own advantages and disadvantages. And, of course, going with a standalone website builder and serving the content as pureHTML had its own too. For me, though, benefits really outweighed the challenges.
Why choose a static website for blogs?
A static website is nothing but a string of HTML pages served by a hosted web server. Every document, blog post or update is a plain HTML page. Given this simplicity of existence, it has some key benefits that attracted me.
Improved performance, security and ease of use are just a few of the reasons static site generators are so appealing.
The most noticeable is performance. HTTP servers are very good at sending files—so good, in fact, that you can effectively serve the same number of pages with a fraction of the memory and CPU needed for a dynamic site.
I have already seen this benefit realised with the performance of my website too.
These benefits should attract every blogger out there looking for a simple manageable solution for their blogs. Then why aren’t all blogs served as static website? The answer is, of course, nothing’s perfect and static websites are not for all. They bring with themselves a list of challenges.
Creating static pages needs a bit of programming skill, and a lot of interest to slog it out over web design and development. In the longer run, maintaining these pages can become cumbersome if they are to be updated even so slightly, every now and then. Especially, if all you care about is the text you write, what gets placed around it is really not of much an interest to you. All you want to do is write and publish. You don’t want to awaken the web dev in you every time you want your footer to be updated or a page to be added.
Ironically, a rush to dynamic websites to solve this challenge is totally counter to what you really care about, the text. The text is light, the page carrying them needs to be the same. To have these generated every time someone requests for them2 is just too costly. And to have them stored as database entries is just too messy. It is text, it needs to be stored as text.
Hugo (and the likes) provides a nice middle ground. Smashing Magazine summarizes it well.
Each generator takes a repository with plain-text files, runs one or more compilation phases, and spits out a folder with a static website that can be hosted anywhere. No PHP or database needed.
Hugo takes caching a step further and all HTML files are rendered on your computer. You can review the files locally before copying them to the computer hosting the HTTP server.
Isn’t it, after all, better to make the whole user-facing part of your website into a cache of servable HTML pages and have it generated and deployed locally — without loading the server with a programming runtime or a database? This is exactly what Hugo enables.
This helps to design, build, test and maintain the website without much of a hassle. And with Hugo, I have already hit all the benefits of a static website I mentioned above, bypassing the challenges it presents. A one-time effort to design and build the website is handled with little pain; now I can focus on writing.
Workflow to write, especially on mobile
There is another challenge with such websites that are built locally and served statically - all they contain is the final product, the HTMLs. Any change needs to be followed by a rebuild and redeploy. There is no online CMS to handle your content from a browser, especially no WYSIWYG3 web editor to create or modify your posts. Of course, one way to handle this is to deploy a separate light-weight CMS.
But for blogging, there is a simple way. All you need is a continuous deployment setup and a couple of applications to handle writing and publishing your posts. I have already explained how Netlify has helped me achieve the first part. Below is how I circumvent the second challenge4.
Write: It is important you can write from multiple places, especially your mobile devices. Web editors of the blogging platforms allow you just that, keeping your drafts ready for you to pick up from where you left earlier. A static website lacks this and so calls for some other alternatives.
I use iA Writer to write all my posts. It has apps for all the platforms I own, iOS and macOS. It allows me to focus mainly on writing, automatically saving all the words as I write them. It also keeps all the posts synced up across all the devices, granting me the convenience of cross-device writing that web editors enable. I find it goes even a step further as it provides me a consistent experience across all the platforms, as compared to the messy state of online writing — more on this later.
Deploy: Doing this from desktop was always trivial; handling this from mobile was what puzzled me. However I managed to get a workable solution. Once I have the post ready, I use Git2Go to push the final Markdown (.md) files to my Git repository. Net
lify does the rest, making the post available at the website. Any minor modifications, it is just an update with iA Writer to these .md files and a push via Git2Go.
Workflow: Though it is easy to say just write at one place and push to repository, it would be a significant effort to get a file, as per Hugo-defined format, ready for writing. Any generator needs some added metadata, front matter in Hugo land, embedded along with the content to create a serve-ready HTML. Adding this to every post I write would have been a downer; especially with my intention of writing different types of posts - fiction, non-fiction and links.
It needed Workflow, I mean literally. The Workflow app is a boon for anyone who wants to automate common tasks on iOS. It is a powerful tool with hundreds of actions that can be easily stitched together to create a workflow — one that can handle complex tasks with a single click. For example, here’s my workflow to get a link post ready.
Once I find a link I want to share and add some comment on, I open it in Safari and just copy the content I want to comment on
I trigger the relevant workflow from the share sheet
Workflow then
fetches the template for the link post
adds the link to the metadata as the source URL
adds the current date and time as the post date
adds the title I provide (or the title of original post if none provided)
takes the content from clipboard, adds to the content body
saves the file and opens it in iA Writer to be edited further
Once the post is ready to be published, I just export the post as Markdown from iA Writer and import it to Git2Go in the content section.
Commit & Push, and the link post is ready on the website.
This is just one such workflow. I have managed to create one each for every type of posts I write. Workflow does the routine heavy lifting for me, allowing me to focus on writing.
I know just this effort might be overwhelming for many. The act of building, managing and updating the static websites is not everybody’s cup of tea. However, for me, I have found that this triplet of enablers - iA Writer, Git2Go and Workflow - serves me well. I have never been so satisfied with either the website or the process involved in publishing to it. I am pretty confident this setup, with minor modifications, will last long.
Heng’s website “theSiteWizard” is really a great resource for anyone interested in building or maintaining their own websites. It doesn’t matter the scale — be it for an individual blog or a full fletched website for your group.↩
Of course, the dynamic generators, especially the CMSes like Wordpress and other, do handle this well now-a-days by caching the HTML pages to avoid the unnecessary delays of generating and delivering the pages to the end users.↩
I focus mainly on the platforms I own i.e. iOS and macOS. Of course, if you have a different set of devices, your solution may vary, or may not exists at all (chances are slim for that though).↩
Ganeshotsav. The festival that brings families together. The festival that makes everyone forget about their individual differences and work with a sole purpose to welcome Lord Ganesh to their homes, their region. No one holds any grudge against anyone for a few days when Bappa is with them. Everyone contributes just towards making the event better.
It starts with planning Bappa’s welcome; families plan together.
Then its about implementing; families implement their plans together.
And then it is all about fun; and of course again, families have fun together.
Lord Ganesh brought our family together this time again. And I am sure He was smiling his happy smile looking at the family enjoying His presence. Ganpati Bappa Morya!
Historical it was tagged. It had so much of hype and so much of build-up. It really was surprising how much big of an event it was made. And of course, given I inadvertently end up consuming more news blurbs from US, I had logged, wondering where, of all the possible sources streaming this event live, should I catch this event as it happens.
I am happy I did. It indeed was an event with a style. Eclipses are always captivating, they make you realise of your order & significance in nature’s canvas. And given it happened in US gave this one the best opportunity to be caught in all its glory. And of course I wanted to Journal all the best posts about it. Starting with mine.
Sana hated Joel. It was not because he was a terrible person. It was, rather, for exactly the opposite reason. He was a gem of a person.
He always adorned his face with a wide, charming smile. A smile that captivated everyone, but was neither an attempt at hiding some innate stupidness nor a craving for being characterised as “the cheery guy”. It was all authentic. At work, he was best at what he did - extremely smart and diligent. He mesmerised everyone in the team, inside or the outside, with his knowledge and his stories. Sana had not yet come across a single topic which had him stumped.
Sana, on the other hand, was miserably inadequate at work. She rarely completed stuff assigned to her on her own, helping others was unthinkable. She wasn’t too keen either, as it involved interacting with them. As part of a group, she was perceived to be the pensive dumbo. She rarely added anything to a conversation, but got always swayed by everyone’s perspective. More often than not, she left a conversation being bitter for her inability to contribute.
Not Joel. He was never seen fussed. Outside of work, he dialled his impressiveness up a notch. He was a terrific singer — Sana believed he was good enough to be a lead singer of any band. Every party had a performance from the cheery guy. Him, strumming guitar, and his soulful crooning.
Sana had no interests, no passions. She was into her late twenties, and she had no profile to boast of. Every attempt of hers to break free was shot down mercilessly by her fate. Some by the fateful accident that took her family away. Some by the untimely fire that took her friends away. Fate never allowed Sana to be the unfettered child, burdening her always with the needs of ever debasing circumstances.
“Sana?”
Sana was woken up by a collective shrill around her. Everyone was looking at her. And she, through her teary eyes, had been looking at Joel, a usual guitar in his hand. She, then, heard Joel speak.
“Yes, her. She is a great singer. I have heard her croon many times.”
Fate, over her life, had nurtured Sana to be a grouchy wench. Sana hated Joel for dissuading her from being herself.
In the bitcoin economy, time really is money. Every 10 minutes or so, mining machines compete with each other to solve a math problem to win 12.5 bitcoins, a reward set by the bitcoin software. The work is akin to trying out billions of combinations of numbers on a safe. The miner who gets the right combination the fastest unlocks the safe. The more machines you have, the greater your chances of earning coins.
The whole economy around bitcoins (“the stateless digital currency whose total market value has more than quadrupled this year to $70 billion”) mesmerises me. It is as if a whole parallel universe exists — a universe where not just the currency, but the rules and the rulers transcend the limits of the real world. It stumps me though to think that whoever is capable of owning huge wearhouses, being called mines now, that host nearly unlimited processing power will soon govern this universe. And the most prestigious job available would be to tend to the machines generating this power.
Machines at the mine break all the time, given there are 25,000 devices. It’s a game of whack-a-mole: After one is fixed, another broken machine crops up. “I just try my best to check as many as possible,” said Hou, who tends to the machines daily from 8:30am to 6:30pm.
All day and night, using laptops, they monitor the status of the machines, and go into “the field”—the eight buildings that house them—to check on malfunctioning ones.
As a side note, I read this and feel automation is banging on the doors to dismantle the life of these so called miners. This parallel universe will not be run as it is today. Disruption is waiting to happen when everything of a world goes digital.
I have become a big fan of the Mc Sweeney’s publication. Every day brings a new satire, a new angle, new humor to the terrible events in the world. Here’s their satirical take on Mr. President’s horrible tweet. “As you can see on this X-ray, the tumor is currently about the size of a baseball in an all-white baseball league. I could surgically remove it as soon as tomorrow afternoon. However, I will not be doing that. I view this tumor as an important symbol of your body’s history and heritage. Removing the tumor would be yet another example of misguided medical correctness in today’s liberal America. I protest this surgery and refuse to whitewash your rich medical history. The tumor must be kept prominently displayed inside your body.”
This is my personal place, a destination where one can find every thought I ever post on the web, anywhere. At times it originates, and so just exists, here. There are also times when it’s published at someotherplaces first, but is also made available here. It has been in existence since 2008 and just like every year, this time too I wanted another fresh start for this place.
I have already documented all the history behind and the context for the existence of this site and this page. Here, I intend to document all there’s to know about this site.
Before I get to the details, this is what I set to achieve when I began.
A website designed, in and out, to my liking, with every knob controlled by me.
A landing page with a brief about me and the site. One that clearly links to the key content.
Clean and simple experience, while reading a post or navigating the site.
Consistent writing experience, preferably offline, across mobile and desktop.
Source control for the whole place. No fallouts from brain freezes.
I do not believe what I sought out was that complex. So I was confident I could get this working.
Here’s the TL;DR version of what I have achieved. 1.This My old site was built with Hugo — it is extremely simple, highly customisable, well documented and has an active community. It’s difficult to beat all of that. ∞ 2. The look and layout of this site is themed by an extremely personalised port of the original ‘ghostwriter’ theme. I intend to open-source the same soon. ∞ 3. The source for the complete website along with all the posts, as markdown files, resides in GitHub. Every change to this setup is driven as it would be in a standard git project. ∞ 4. Contents from Squarespace were exported into a Wordpress package first. They were converted into markdown files using ExitWP. Followed by cleanup. And deploy. ∞ 5. This site is deployed by Netlify. With continuous deployment and one-click SSL for custom domains possible with minimum configuration, the choice was pretty simple. ∞
Core Engine - Hugo
I had always wanted to attempt a site creation from scratch, but I failed miserably every single time. Given I had ample time before my Squarespace subscription expired, I attempted it again this time. I believe I did not fail. This is a static site, built with Hugo. It was the ease with which I could get a site running on my dev environment via Hugo that convinced me about the viability of this whole project. If you do not believe, just head over to the Hugo docs for a quick start and begin. You will have a site running by step two. It is that easy.
You would have also realised how well document the whole framework is from your visit to the quick start guide. There is nothing that you want to achieve that isn’t documented. In addition, given that Hugo is written in GoLang, it gave me an opportunity to learn a new language. Post that, every need of mine to get the things just right was just a code snippet away.
For example, find below a snippet for fetching a list of random five articles. Yes, it is easy. And a lot powerful.
{{ $pag := where .Data.Pages "type" "post" } } {{ range (shuffle $pag | first 5) } } {{ ....custom.... } } {{ end } }
And if it does turn out that there is some tricky edge case that you just can’t get your head around (or you are being plain, simple lazy), there is a thriving community of fellow users which is extremely active and a lot helpful.
TL;DR: Hugo is simple, highly customisable, well documented and has an active community. It’s difficult to beat that.
Personalising the look & layout
Once I had the core finalised, I shifted my attention to personalising the site. And again Hugo comes with a lot of good looking themes — extremely minimalistic to fully loaded. You will always find the one for your liking there.
If you, like me, do not find one that ticks all the boxes for you, you can select any that is closest and get to personalising. All the themes come with the source code. So if it suits you, let the developer in you go wild.
I began with a theme “Ghostwriter”. It was simple and I could see how it can be extended to enable every aspect that I wanted to achieve. So I began working. After a week of customisation, I could finally see the site shaping up just the way I imagined.
I intend to soon open source the changes I have made to the original theme. I am working on cleaning up the source and committing. All the enhancements and personalisations added to the theme are available at Github. If you like the theme that you see and if you are using Hugo for building your Static website, you can download and use the theme from here.
TL;DR: The look and layout of this site is themed with an extremely personalised and open-sourced port of the original ‘ghostwriter’ theme. I intend to open-source the same soon.
Cushioning against brain freeze
Yes. Commits and port. I am not letting another of my brain freeze moments to spoil all the efforts the put in over the years. Refer the history section I mentioned in my introduction above.
So whole website is a git project. It is currently maintained as a private repository at GitHub. Every change, major or minor is committed. Every milestone is tagged as release. And every major enhancement is pull request. No, I am not taking any risk with myself this time. Here is a snapshot for the effort that has gone in to bring the v1 of this site.
Do I intend to make the source of this website public? Well, initially I wanted to do just that. However, I do want to keep my messy drafts, be it to the posts or the website, just to myself. I could not find a public way to achieve that. So as of now, the source stays private.
TL;DR: The source for the complete website along with all the posts, as markdown files, resides in GitHub. Every change to this setup is driven as it would be in a standard git project.
Migrating the content
Talking about the posts, I had to bring the old entries along from Squarespace. After all, this is also a place for my writings. I would not want to loose any of my old ones1.
This time, though, I did not have the luxury of the out-of-box imports. I had to do it on my own. Well, I did have a couple of points playing on my side.
I have been writing all my posts in markdown format and exporting them as required.
Current setup with Hugo is all markdown driven, where every content exists as a .md file.
So, all I had to do was find a way to export the content from Squarespace as markdown files. I wish it was that simple; it wasn’t. The only option that Squarespace supports for export is as a Wordpress package. However, anyone who has been blogging for even a slightest of time would know Wordpress package should be fine. Because there is nothing to be done with a Wordpress package that no one else has already tried. Just getting markdown files out of that must be a cakewalk. Markdown, after all, is a geek’s solution.
And as I thought, it already is handled. ExitWP is a great tool to migrate a Wordpress blog to a static site. It is introduced as a tool to convert to “the jekyll blog engine”. But that should be fine. Both Jekyll and Hugo use markdown files as content.
After going through the steps as documented at the git repo for ExitWP, I had all the content available as markdown files2. It did need the below minor cleanup.
Images had to be handled separately. All references were to the Squarespace domain. Thankfully, I maintain a credit link with every image to the original one. So I just had to re-download, compress and deploy them.
Front matter needed porting to the Hugo standard. I did weigh in the option to write a script to do that. But then ended up siding on doing it manually.
Post content did need some minor fixing. ExitWP has some issue handling and regenerating the emphasis, especially around symbols (for example, quotation marks, dashes etc).
Deploy the post, test each one from the post link on dev and I had all my content back. Thanks to this effort, I believe I never have to worry about porting out my content ever. Every published copy of a post stays as a raw file with me.
TL;DR: Export contents from Squarespace to Wordpress package. Use ExitWP to convert it into markdown files. Cleanup. Deploy.
Deploying with Netlify
Once I had a site running on dev and tested multiple times to bring it to my liking, I had to start thinking on a place to deploy it. And of course, Hugo has all the possible options well documented.
As my code was in GitHub, the first option I tried was to deploy it on GitHub Pages. I configured Hugo to generate the static pages in a defined directory (configured as submodule for the GitHub pages repository). I built my site, pushed the changes and deployed, and it all looked fine. However, there was just one problem — the deployment workflow was a bit messy. In addition there were few more niggles3.
There is no provision for SSL with custom domains. So they cannot yet be delivered over secure http.
Auto-triggering for build and deploy had to be configured as web hooks.
Given the deployment workflow, publishing from mobile was just out of question.
On reading some more, I found a far simpler option in Netlify. Again I will let the official document explain itself.
Netlify builds, deploys and hosts your front end. It provides continuous deployment services, global CDN, ultra-fast DNS, atomic deploys, instant cache invalidation, one-click SSL, a browser-based interface, a CLI, and many other features for managing your Hugo website.
One might say jargon, but there are key needs I had which GitHub pages just didn’t handle — a couple being continuous deployment and one-click SSL. So I did another deployment with Netlify and again fell for the simplicity of the things involved. No configuration head-ache. No custom workflow to handle the built site separately.
Write Frontend Code. Push it. We handle the rest.
Yes it, indeed, is that easy. It doesn’t matter then where you push to the repository from, mobile or desktop.
There is one issue with the Hugo documentation though. One does not need to trigger a build command with Hugo version number appended in it. Just configure a parameter in the build for the version of your Hugo environment.
Once the Netlify account was created and the continuous deployment for the site setup, I just followed the documentation for using custom domain and setting up SSL. The site was live.
TL;DR: The deployment of this site is handled by Netlify. With continuous deployment and one-click SSL for custom domains possible with minimum configuration, the choice was pretty simple.
Change log
So to summarise, I have first releasable version of this website ready. Built with Hugo. Themed with Ghostwriter. Run with Netlify. And of course, it is just v1.
Musings Et Al. v1: First version of the website with all the clogs designed and working as planned. It hosts below custom features.
Support for write-up section on homepage driven by config.toml
Support for headshot on the homepage
Support for displaying the latest featured post on homepage
Support for link posts (via refs param in front matter)
Support for related post along below the content of a post
Link to the image credit (via imgsrc param in front matter)
As a side note, all my old posts still exist on Wordpress. You can read them here.↩
I did face some difficulties while installing the dependencies. In case you hit them too, just download them from the official sites and have them available in the classpath. It doesn’t matter the approach is crude, it should get the work done.↩
In case you do want to go a head with GitHub Pages, I would suggest you go ahead with the option of deploying from the master branch itself. Hugo documents this as the last option. But I feel this is simpler and a viable option.↩
As I read this, I sat there with a chill down my spine. “Terror is not an unjustified reaction to knowing this virus exists. We have no room to be wrong about this. None. We can be wrong about other things. If smallpox got out, it would be unfortunate, but it has a fourteen-day incubation period, it’s easy to recognize, and we would stop it. Much the same is true with sars. But with flu you are infectious before you even know you are sick. And when it gets out it is gone.”https://twitter.com/statuses/896659144819695617
