Posted On: 2018-10-29
There are a few changes to the website that are currently still work-in progress. The most visible of these changes will be a new section to the home page, which will list the latest blog post. I am looking forward to this, as it's one of several site-related improvements that I've been wanting to do over the past few years. Unfortunately, I wasn't able to get everything sorted out in time for the update to go live today, so instead I will just say it is "coming soon". All that being said, I'd like to go a bit into why these changes are taking extra time, as I think there are some interesting lessons in it.
Most internet sites, this one included, are fundamentally just code running on a server somewhere. Typically, that code is written so that
when it receives certain signals from the internet (the request for the webpage) it sends a certain signal (the content of the webpage) in response.
(As a small aside, most web sites use one of several standard technologies for dealing with the network activity itself - these technologies instead
represent the request as an abstraction, such as GET blog which, in turn, the authors of the site's content use to determine what content should be in the response.)
Since a website is just code on a server, the code can be changed and the server will update its behavior accordingly.
The challenge of this, of course, is that if the code does not behave the way it was intended to then the website will behave incorrectly (or fail completely.)
There are many ways to mitigate this risk. A common one is to separate data from the code, and limit the amount of behavior that can be controlled by that data. One example of this is a blog: typically the contents of the blog (text, images, links, etc) are stored as data, and are strictly limited in how they can interact with the rest of the website. Whenever new blog posts are added, that is new data, but the actual code remains the same. In contrast to the data, the code actually running the blog has essentially no limits on what it can do, but it is seldom updated. As you can imagine, this approach works great for people writing blogs, but is inadequate for people creating the actual code for the blog engine.
A second common way to mitigate risk is to create a duplicate of the server and test the changes to the code there. (When this approach is used, the server[s] that are actually in use are typically called "production", and I will use that same term here.) Depending on the approach, this can be more or less expensive (a new server is typically quite expensive, but using virtual machines or containers can be cheaper alternatives.) In general, this approach is more effective the more similar the duplicate is to production, and this is often used multiple times on the same change, with varying amounts of similarity. For example, changes are often immediately tested, typically on the machine being used to author those changes. Later, once the developer has more confidence in the changes, they are moved to a server where they can be tested in a setup that more closely approximates production. (This is sometimes done multiple times, especially in large, bureaucratic organizations.) Some organizations even have multiple production servers, and are able to send apply changes to some (but not all) of the servers, and then monitor the change before deciding whether to apply it to all the servers. (This approach is typically called a Canary Release.)
On this particular site, I have setup a decent separation between data and code. Blog posts can be updated as data, and new prototypes are (mostly) just data updates as well. Unfortunately, I don't yet have a good setup for testing out a duplicate of the server code (aside from the machine I am authoring it on, which is quite different from production.) As a result, substantial changes to the site are quite risky, and I am (at present) limited in how thoroughly I can test them. For the many years during which this was a hobby, I simply accepted that limitation. Since this site is now the public face of my full-time work, I have been working towards being able to safely test these substantial changes, and I am optimistic that it will come together soon.
Hopefully this window into managing a website is interesting and/or useful. If you have any thoughts or feedback about any of this, please let me know.
Thank you,
Mark