The first blob post

At some point in time, I decided to expand my home lab. Add hosts, services and scripts that could be useful in my daily job or that could end up being a more lethal form of Skynet that eventually rules the Earth and enslave humanity. If you are a survivor in a dystopian future where everything is controlled by machines, I do not apologize.

Anyway…

What you see right now is just a boring test for a new website with integrated blog blob.

The workflow

Usually I would follow a complex procedure sending the website through the full staging environment.

Local -> Dev/Trunk -> Integration -> Internal Acceptance (QC) -> Pre-prod/demo –> Production/Live

This trusted workflow, rightfully used by many businesses, didn’t fit this website and probably isn’t a good fit for other very small teams. Using my trusted white board, I designed a much simpler process using appropriate technology.

Local -> Production/Live

This new philosophy is much simpler and faster, but it has a few issues. The most important one, which would be apparent to any decent elementary grade English teacher reading this article, is quality control. The second issue is related to any “coding” error I might make, any error of this sort would be published on the Internet and might break the website without any warning. Of course, there are many more issues with this procedure and no one in their right mind would use it for their business needs.

Instead I went back to my white board and chose to design something more efficient…

Local -> Internal Acceptance (QC) -> Production/Live

This updated process can be applied to two different kinds of updates.

1. Changes to website’s code
2. Changes to website’s content

From a basic point of view, I am now able to design a new feature, run some tests and then push the updated code in production. I can also follow the same workflow when I publish a new article.

Write a blob post -> Check spelling if everything loads -> Publish

---

The technology

I wanted something cheap, fast and secure. Putting those three criteria together was a major issue. A fast server is expensive, something secure needs a lot of time to configure/manage and time is money. Spending a lot of money was clearly not a “cheap” solution.

Searching for free hosting is usually a bad idea, you would end up reading very weird terms and conditions. There’s one “free” host that is both reputable and well-known: Github pages. You need to create a repository on Github in which you will host your content. This repository will be public unless you are ready to open your wallet.

The main issues with Github pages’ public repository is that everyone can see the code behind your website and that it doesn’t support server-side code (PHP, Python, ASP…). Static content only makes running a blog kind of annoying so I’m Hugo to generate HTML files from articles written in Markdown.