VX Development Blog

Overview

At VXSoft, we've always believed that a technical development blog is an incredibly important tool. It's how our developers can express their thoughts, show off what they've accomplished, and basically serve as the technical face of the company.

So, why are we talking about this? Well, I'm going to tell you the short, slightly ridiculous story of how we've managed our blog engine over the years—and how we finally pulled the plug on complexity and ended up with Pelican.

The Shadow of Blogspot: An Age of Lost Knowledge

Our very first attempt at a development blog was strictly for internal use, and in a moment of questionable judgment, we decided to use Google Blogspot. I'm pretty sure that was the worst idea we ever had, but hey, at least we had a blog up and running fast. We didn't even have a Google Corporate Account back then (we were hosting our own mail server!), so we just used our personal Gmail accounts. The security team loved that. 😉

The hardest part of running any blog, of course, is maintaining the discipline to write and publish content regularly. We tried to make it work, though! We used it for internal tutorials, guidelines, and even as a low-key communication platform—sharing a cool song or useful tutorial links.

Anyway, after a couple of years, the inevitable happened: we somehow managed to get the account suspended by Google, or something equally chaotic occurred.

And some things that should not have been forgotten were lost. History became legend. Legend became myth. And for two and a half years, the blog passed out of all knowledge. 😀

The Mines of Wordpress: Corruption and Abandonment

For our second, still strictly internal, version of the dev blog, we thought: Wordpress is THE engine! Naturally, we decided to self-host it. Since we were developing in PHP at the time, picking Wordpress felt like the path of least resistance.

Setting it up was super easy. Writing a post was... somewhat easy. But keeping it updated, along with the "couple of plugins" we decided were mandatory? That was the start of the headache. Wordpress is so much more than a blogging engine; it always feels like it's built for every possible use case except simple blogging. Maybe it's a web-portal constructor? A built-in online store with payment integration? Who knows.

(Some will argue, but let's be honest, some are always arguing.)

And so, another chapter closed. Our self-hosted blog eventually got old, outdated, and fell victim to some non-natural cataclysm—the server stopped working, the VM got corrupted, or some other technical horror struck.

And again... some things that should not have been forgotten were lost. History became legend. Legend became myth. And for two and a half years, the blog passed out of all knowledge. 😀

The Relapse: Back to the Perilous Paths

What? Why?!

Well, after another couple of years, we felt the urgent need to reincarnate our blog. The reasons were all the same, only more intense! Our SecOps team wanted a place to post about incidents or cool findings, and our QA team was eager to share their experience writing automated tests and running them on something like a Selenium Grid.

This time, however, we had switched from self-hosted email to a proper Google Corporate Account (Gmail, Drive, and... Blogspot?). This made setup even easier—just park a domain, and boom, you’re there. And we were there.

The major difference this time was that the blog was public, and overall, it wasn't bad. The problem? The Blogspot editor (it sucked, to be short) and the deep, unsettling feeling that absolutely nobody at Google cared about Blogspot anymore. And we all know what happens to the services Google isn't actively proud of.

You might think that some things that should not have been forgotten were lost again, BUT not this time! :) This time, we were done with the cycle. We decided to solve the issue of the blog and its content once and for all, and that’s when we started actively searching for a sustainable, liberating solution.

The Fellowship of the Repo: A New Path is Chosen

After researching and discussing for a while, we finally decided to address the core issue: the pattern of forgetting and losing our content. As a software development company, we have one and only one sacred, holy thing that we preserve with our lives: the source code repository. We realized that anything once committed to the repo, backed up, and version-controlled would genuinely not be forgotten and lost.

With that truth established, the only remaining decision was which static site generator (SSG) we should use to convert our blog posts (written in something like reStructuredText or Markdown) into lightweight static web pages.

Here's a short list of popular SSGs we considered: Astro, Hugo, Zola, 11ty, and Jekyll.

You'll notice that we entirely neglected this highly popular list and instead decided to use Pelican.

Why Pelican, you ask? The answer is simple and satisfying: because years ago, we proudly changed our software development stack from PHP to Python!

Pelican is super easy to install, easy to use, great for building content, and simple to deploy (even though it doesn't need to handle the deployment itself). You might argue that Hugo is the most popular static site compiler, but then again, there is 'Go' in HuGo... and it's definitely not 'Huthon' or something similar. 😁

The Return of the Content: Settling in Python's Realm

And here we are! I’m writing our very first blog post in reStructuredText (reST) after successfully switching to our new blog engine: Pelican.

Luckily for us, this time we managed to save our content. Blogspot has a tool to export everything as an RSS feed XML, and from there, you can use one of the available converters to extract your data as reST or Markdown. After a small debate, we chose reST as the "source code" for our posts. Why? Because it’s a richer format than Markdown and, mostly, because it was introduced by the Python community (remember the "Huthon" joke?).

Converters are good—they handle the dirty, annoying part for you—but they aren't magic. To get decent, perfectly formatted reST or Markdown, you absolutely need to review the converted results. It’s not a pleasant job, but what’s the alternative? Lose everything again? Nope.

After clearing and tidying the content, you face the next hard and tedious job: a theme! Sure, Pelican supports themes, and you can find dozens of open-source options. But if you have a specific design in mind—or, like us, you want to customize one—choosing (or building) the right one becomes a project in itself. We had a clear vision: super minimalistic, mobile-friendly, JS-free (as much as one can), and fully compliant with HTML5 and CSS3.

After reading and analyzing a lot of open-source themes, I decided to take the base simple theme and customize it heavily. You are now looking at the result! I encourage you to inspect the CSS and HTML; we think we did a decent job keeping the theme structure minimalistic.

The final piece of the puzzle is content safety. The storage for all our blog posts is now our sacred code repository: Subversion. It is monitored and backed up regularly, so losing content is finally a thing of the past. To top it off, we constructed a CI/CD pipeline for automatically building and publishing new posts to VXSoft Development Blog.

This is it, folks! I anticipate follow-up posts coming soon, diving into our Pelican theme structure and blog deployment routines.

Stay tuned!