This Site

I'll be collecting information for this site primarily through navigation rather than searching. This is partly for amusement and also to foster deeper knowledge acquisition. I will likely at some point also look at producing a visualization of the resulting graph using something DOTy.

One of the initial roots for the search will be Martin Kleppmann's excellent Designing Data-Intensive Applications which is not only a great resource by itself but also a treasure trove of useful references. In addition to this I'll be using books that I have or discover at libraries and information read from assorted memberships to O'Reilly, ACM, IEEE and the New York Times.

Additionally this will be supplemented by research done in support of particular projects, where the paths to connect any such detached pieces of information will be sought over time.

The markup for this site will initially start as what is exported by Org mode, and then some practices and tricks may be borrowed from selected sources which will be listed here.

Initially the source for this site will be hosted on GitHub. I personally have more interest in some other alternatives which I'll look to explore for any projects that I publish, but GitHub is what I'm currently using for work and also is the most readily navigable service from my Information Collection approach, starting with some GitHub blog posts.

This site will first be hosted on GitHub Pages. This is a solid option overall and one I've used in the past. I will likely be looking to move away from it for reasons that will be elucidated if and when that happens (nothing overly important).

Google App Engine is a viable hosting option that came up fairly early in my information navigation and seems to potentially fit the right set of criteria. Google Cloud is also a technology I'll be using for work and one which I haven't spent too much time (like much of the industry I'm far more comfortable with AWS).

I used and evangelized GAE a fair amount quite a while ago (prior to and during the period when it went General Availability), and would be likely to use it again if I were looking to develop an appropriate app. While I'm currently looking to use the flexible model for containerized deployment I've generally been of the mindset that adapting designs to fit within the constraints of systems like GAE can provide significant upfront benefits. Often such technologies seem to turn people off as they preclude use or preferred hammers (which may or may not be a valid reason particularly within an organization). Similarly there may be some cases for which a particular type of technology is most appropriate but an awkward fit. Additionally I haven't run the numbers for GAE in particular but in most similar systems there's a break-even point after which it is likely to be far more cost effective to use something closer to the metal even after accounting for the operational overhead. But…as mentioned the upfront benefits can be substantial and other than cultural resistance (which isn't a concern for my personal projects) many of the other concerns are initially aspirational.

For this particular project I'll be looking to make use of the flexible environment as I'm very comfortable with dealing with containers and I'll be starting to use a non-supported runtime. This is likely to evolve into making use of a relatively standard container which is also not directly supported, so in both cases I'll be relying on a custom runtime. An enticing longer term plan may be to switch to Cloud Run as it is likely to be lower cost at low volume, but in the immediate term it seems like a distraction and I may also want to look at more static alternatives in the future.

I'm also coincidentally looking at Cloud Run for a work related project so that seems likely to slide it in place sooner.

I'll be looking to deploy this site as a static site hosted through nginx (open source) as outlined in the Google App Engine custom runtime quickstart. I've spent a fair amount of time fiddling with nginx and while I'm not particularly fond of their business model (particularly the somewhat crippled open source offering) the software itself has proven to be very robust and efficient with wide adoption…and I have assorted nginx stickers and T-shirts (one of which is black-on-black and probably my favorite tech shirt) so I should probably validate the swag by using the software. My past experience also gives me confidence that I can bend it to my wishes in some way or another and maybe learn some new tricks along the way (I already have a module sitting around to address the DNS resolution issue which may otherwise dissuade me).