Preamble

The quote, “Failing to plan is planning to fail”, which has been widely attributed to Benjamin Franklin serves as an appropriate jumping off point for this post. A couple of weeks have passed following the Hello, World post, and the endorphins from the “Wow! It works!” (or “eureka”) moment have worn off. So, in an effort to stay true to the purpose sentiment in the aforementioned post, let us settle down, and plan what is next on the horizon. Essentially creating a Roadmap for this blog.

Here is a quick summary of that purpose:

• Working on writing consistency, or rather, practicing technical writing
• Learning / Distilling information

A quick expansion on the latter, in an ideal world (and perhaps with substantial practice) the writing style of this blog, and the content within, will hopefully be digestible by all readers, regardless of their technical acumen. Ultimately aiming to make the problem solving aspects, and the subsequent knowledge sharing enjoyable and entertaining.

That being said, let us break down what is to be expected in the coming while.

Breaking down 42 65 6e 6e 6f

A way in which we can plan what is coming next, is by (critically) analyzing the construction of this very site. Getting this site running was nothing more than a weekend “self-hack”. Nothing more than indulging a curiosity stemming from a “how does it work, what does it require, and how quickly can it be done?” train of thought. The idea of this site, was an abstract goal aimed at satisfying that curiosity.

Note: The “it” in this train of thought, was particularly around Cloud Platform providers. This blogging website, (at the time) merely stemmed from the need to have something to display - as well as needing somewhere to note down thoughts.

As with most rushed things, various shortcuts were taken, and less than ideal solutions implemented, all in the name of a “let’s just get it working” sentiment. Looking forward, we should start by looking at making things sustainable, and less “experimental”.

A somewhat specific high-level overview

Following is a somewhat detailed overview of the inner workings, of what makes these posts visible to you, the reader. Starting, with this crude diagram:

Breaking this down:

1. The content (i.e the text) of the blog is written on a Linux laptop in Visual Studio Code, using Markdown.
2. The Markdown content is passed through an open-source static site generator, called Hugo.
3. The static site generator, transforms the Markdown content and outputs the various files (HTML, CSS etc.) that make up a website.
4. This output is version controlled to GitHub.
5. The same output, is then manually copied over to a Google Cloud storage container.
6. Lastly, this output is then made accessible via a Google Cloud load-balancer.

In order to get this website running, one of the “big evils” had to be chosen for a Cloud provider, arguments could be made to utilize Microsoft’s Azure, or Amazon’s AWS - however, at the end of the day, the “big evil” chosen was Google.

Note: It is worth noting here, that a “self-host” solution is not off the cards, and maybe something that will be visited in the distant future. This would likely form part of a multi-series of blog posts.

Highlighting areas of improvement

Reflecting on the high-level overview, we can already notice areas of improvement, and areas where we can explore, learn and let our general curiosity take over. All of which will form part of our Roadmap for future content for this blog. We can roughly categorize these areas in two groups, with some natural overlap. These being:

• Streamlining content processing: think of this as all the processes required to get the content from the laptop to the internet.
• Learning by doing: these will be activities where we can investigate (and perhaps build) some of the components that are utilized in the very process itself.

Let us flesh this out.

Streamlining content processing

Once a post for this blog has been written in Markdown the following happens:

1. The content is passed to a static site generator (in Learning by doing we can explore how these generators work).
2. The generator’s output is version controlled - this is not entirely useful. By version controlling the output, we essentially lock ourselves into the tool that generates the content. More importantly what we should be version controlling is the markdown files. This is our “raw input”.
3. The generated out put is manually uploaded to the Google Storage Account. We can put on our problem solving hats and automate this (spoiler: we will in a future post).

There are plenty of manual operations that happen here, that we can automate away, which will greatly streamline the process of uploading new content to the blog.

Learning by doing

Looking ahead, at some future content, we can explore topics like:

1. How do static site generators work?
2. Making our own static site generator (potentially spanning multiple posts)

To roughly expand on this, building a static site generator will require:

• An understanding of static site generators.
• Planning and scoping our static site generator (what are the requirements / constraints / features that we’d like).
• Planning and designing a website, the generator naturally needs to know what to generate.

What is next

By looking at the current situation, we have been able to find some good ideas for future posts. Naturally, exploring these future topics, also opens us up to the organic process of discovering new topics. This is our Roadmap, and it can be as rigid or as flexible as is required.

Conclusion

This was a considerably longer post - hopefully, though, it was somewhat educational and entertaining. By looking at something that was cobbled together in a weekend, we have been able to plan some future content, and set some goals / objectives. In each subsequent post, we can expand on the reasons and justifications for each of the actions.

For now - this is it, check back (at some point) to see if we have undertaken one of our Roadmap items.