techearl.com · since 2014
I'm Ishan Karunaratne, a tech architect and software engineer with twenty-plus years across software, Linux systems, and DevOps. I started building this blog back in 2000, while I was still in university, driven by a desire to explore technology and showcase what I was learning. At the time it wasn't about publishing content, it was about experimenting with tools, platforms, and languages. I started with basic HTML pages and gradually worked my way through phpNuke, PostNuke, Mambo, Drupal, WordPress, and Joomla, eventually settling on a mix of Joomla and WordPress.
It took 14 years before I actually shipped techearl.com, but I was writing the entire time. I kept building and rebuilding the site, taking long breaks in between, and never quite launching. The articles piled up regardless. I still have hundreds of them sitting unpublished.
Finally, in 2014, I decided to stop chasing the "perfect" setup and just get something live. That's when the first version of techearl.com went online.
Even after launching, I couldn't resist experimenting. I explored headless setups, tried out different frameworks, and tweaked workflows, but I struggled to find an approach I truly liked. I wrote a lot of content during this time, but most of it stayed in draft mode, never making it to the site.
One of the biggest challenges I faced was keeping my content decoupled from the platform I was using. The structure and formatting of my writing would often get tied to the specific CMS or framework, making it hard to maintain or repurpose.
Eventually I found a workable solution with Markdown. I'll be honest, I wasn't a fan of it at first. But I kept running into it while experimenting with headless setups, and it became the obvious choice, so I started converting my posts from WordPress to Markdown. That's a laborious job, and I'm still working through it. You might ask why I don't just write a script to do it. I wish it were that simple. The point is that I made that bet in 2014, and who would have guessed that Markdown would become the document format of the future, the thing nearly everyone touches today, knowingly or not, every time they talk to an AI.
Markdown isn't perfect (you can't do much in terms of formatting), but it gave me a way to separate content from the platform. To push its boundaries I adopted Markdown eXtended (MDX), which gave me more control over presentation while keeping the content portable. Now I can write in a way that feels clean, future-proof, and easy to move to another system if I ever need to.
Currently, I'm using Next.js. I wanted the flexibility of React to create components and found Next.js to be the best backend to achieve my goals. Naturally, I tried GatsbyJS before settling on Next.js. I loved GatsbyJS, but Next.js fit better for my needs. Using MDX with Next.js, however, came with its own set of challenges. I added ShikiJS for syntax highlighting, which complicated things further. Even now, on Next.js 16, the MDX documentation is practically useless for a setup like mine. But here we are.
One thing worth explaining: if you see posts here with old dates, that's deliberate. A lot of them I wrote years ago and they sat in drafts. I'm publishing each one with its original date for context, since that's when the work actually happened, and then updating the content and the "Updated" date as I clean it up. So a piece from 2016 might appear today, still dated 2016, but refreshed for how things work now. Some are admittedly outdated when they first go up; I'd rather bring them current over time than let years of writing go to waste.
The main purpose of this blog is to share my knowledge of software development and DevOps, from my perspective, using the tools I rely on daily. It's also a practical resource for me, a central repository where I can quickly find and copy-paste commands or code snippets.
There are plenty of blogs you can copy a snippet out of. What I really wanted to build is something you can work in directly: change the example to match what you're doing right now, then copy that exact text straight into your terminal or your code and get the result you want. No copying first and forgetting to swap a value, or changing the wrong thing on the way. You see it clearly before you copy it, so mistakes are easy to spot, and because it persists via localStorage, your version is still there when you come back. Less redoing the same thing over and over.
This blog is as much for me as it is for anyone else, helping me stay organized and, hopefully, helping others along the way.