While looking for a free web host for my new blog, I did a bit of research and very quickly found Netlify and CloudFlare as the top choices. I was certain that one of them would suit my needs, so I stopped the research and proceeded to evaluate just those two. In this post I give a summary of my experience evaluating them and I explain my eventual choice.

As of today, I have a brand new blog. (You are reading it right now.) The old posts are still here, but the look and feel, and everything under the hood, is different. Everything is still free for me, except the domain name.

To read why I transitioned from my old blog to this new blog, see Goodbye blogger!.

This post lists the technologies involved in editing and publishing my new blog.

My first attempt at blogging started in 2001, with a web-site entirely hand-made in HTML. It was crude, it had no commenting, and it was very difficult to maintain it, so it was necessarily tiny. Back then, finding a web host that was both free and would allow you to use your own domain name for free was quite difficult, so I had no option but to go with various questionable free hosting places. First it was united.net.kg. (Where kg is the top-level-domain of Kyrgyzstan.) Predictably, it one day just disappeared. Then, it was digitalrice.com. It had the same fate. Starting from 2007 and lasting until yesterday, I had been hosting my blog on blogger.com (formerly blogspot.com) which, luckily, has been stable.

Introduction

The term "technical debt" refers to messy source code, data, or architecture in a software system. It is commonly understood to represent a vague acknowledgement that the mess should probably be fixed by someone, somehow, sometime.

People hearing the term "technical debt" for the first time are likely to guess what it means, in broad terms, and to understand that it is undesirable; however, the real detriment lies in a concept which, although alluded to by the term, is not spelled out, and therefore hidden. As a result, people often fail to grasp the grave implications of technical debt.

This post sheds light at the hidden concept and shows the real problem with technical debt.

Abstract

Two distinctly different widely used meanings of the term code refactoring are identified and named:

• Changing how code works, without changing the requirements that it fulfills (refactoring in the weak sense)
• Changing how code is expressed, without changing how it works (refactoring in the strong sense)

Summary

Building upon the realization that conventional means of software design today amount to nothing more than fancy whiteboards, we examine the pitfalls, disadvantages, and consequences of designing software using such tools.

This post is support material for Towards Authoritative Software Design.