Website design and rationale

This website is powered by a custom page generator. There are many page generators like this and in a lot of ways they are very much a dime a dozen which probably prompts the discussion of why? Or the question of...it's 2026 why you are hosting this on a VPS with the respective system administration overhead that comes with. Or even the question of why does this site look like it's from the early 2000s.

I find it interesting when companies design technology for their own business use over years. As someone who likewise had written a lot of custom software for her own needs and deployed a lot of software in general onto her network I find myself in a similar boat. So this is the origin of why the tech was chosen that it was...the multiple iterations of my website...and the rationale behind all of it.

Page generator origin (why it's here)

The original website originally designed as basic CMS system which I wrote from scratch. Effectively a simple REST API (in Node.js...11 years ago this was a pretty hot tech, and it would later set me up to move cross-country) and a SPA application running with bootstrap and AngularJS 1.0. Yes this was...2015. The intent of this was to deploy a website that demonstrated my abilities as I was a fairly junior engineer and it was a fairly good example. At this point in time I even had simulators running for mobile apps as well as iframes to websites I had worked on.

For a period of time I would also maintain a technical blog hosted on WordPress about my web developer and system administration escapades which I want to say this was in 2016. Most of these articles are just historical artifacts today hence why you do not see them now as the structure of this site is more intended to tell a story of what has been worked on with connecting technologies rather than things that are no longer current. I have however rewritten a few sections into the site in respective areas such as old projects or industry stories that have aged well. Eventually I would go to work at a small consulting firm who which was targeting to become a billion-dollar company (we did and were acquired) and I would go move to being an engineering lead at NCR (filing a couple patents). I also transitioned around this time which was a time-consuming process. As a result I didn't have time to blog...rather I wrote down my stories unpolished so they could one day be shared as when I had time again I intended to spin a blog back up.

After this I migrated to Drupal (around 2018) and this made a lot of sense. I had enough of a portfolio that my interest shifted more to just having a clean way to update what I was working on rather than a raw template\presentation of what I had built. The problem with this of course is... Drupal does have vulnerabilities from time to time and with the increased risk of cybersecurity exploits over the following years I increasingly began to feel that having an exposed admin panel sitting on the internet was an insanely high risk. And let's be entirely host...comments on my articles are going to be left on things like Hacker News or Bluesky not directly on the blog in 2026.

I moved to a single plain HTML page by 2024 with my move to California. There was a very simple reason for this...I was going to a lot of dev conferences looking for work in San Francisco and I needed something that would load very quickly, get the information across, is optimized to load over low bandwidth environments (ex congested networks, thick walls in a dev meetup, flaky Wi-Fi in a hotel, etc.) and was unlikely to fail (web servers serving files have been a thing for decades)...and a replica or snapshot is trivial. Also after a decade in the field this website doesn't need to be an elegant example of application design rather it should serve the goal of showing my information the most effectively. And to be candid, moving to northern California meant a pretty decent burn on my finances so taking the opportunity to minimize my server expenses (because a static page is why less computationally expensive to server) made a lot of sense.

In late 2025 my employer (a small company working on hypervisors for ARM) would have a budget shortfall due to declining sales which resulted in myself and a number of my peers loosing our positions. I also was supposed to go under the knife for a surgical procedure in 4 months (I would be bedridden for 2 months, and it would take another month before all my medical complications would clear...add another for all restrictions to be removed to live life again). Timing didn't go well, but that's life. It would be 2026 by the time I could work again.

Over these 8 months I built a lot of insane projects, found multiple issues in open source projects (had closed door conversations with regarding some of these), sharpened skills to a knife, rebuilt my home lab, and opted to go through and document everything I had done over a decade long career (or more appropriately turn my scattered notes into something that was a tangible story) as well as document all the insane things I had worked on. As I had already determined that a CMS was not the correct decision for me due to computation costs, load times, and security I opted to stay with static pages. There is one issue though with static pages...when you have as many things I have done (and continue to do) editing a plain HTML page really doesn't make any sense at all as it's way too much time.

Page generator design

Some context is needed here, many page generators are written in languages that don't parallelize well or at all for that matter and most have a very biased direction in which they expect you to write your site. Like I don't want to mess with themes, waiting on builds, or digging through documentation\examples that long term break between versions. I thought this because I don't need much in terms of a website; all I need in terms of page generation is a template system for Markdown files, variable\template injection for HTML, and a clean way to load in JS when I inevitably do need it for some insane feature. This isn't really that much in terms of features.

Additionally, I wanted complete control over the site was created... I wanted fundamentally a website that told my story as an engineer, inventor, and a person. I could not find a way to do that cleanly in an existing page generator. The reason for this is my career path hasn't been completely traditional...I started working in the industry at 18, had my own company in my early 20s, did not start in a tech hub rather I started in rural Indiana...my entry into the industry is as much the story of what I have done as it is the tech I have created, so a simple portfolio just isn't the right medium today and my resume covers that anyway. And candidly... I prefer to be authentically myself on my website and platforms, but I want to ensure the folks just here for the technology (or professional accomplishments can also see that) so I needed a way to cleanly separate that info out.

Due to the number of things I do technically in my spare time and my desire to include parts of my personal life in here I've found myself writing a lot of pages\information. For this reason I need to be able to quickly write something with a nice human-readable editor and deploy this within seconds. So logically we end up with Markdown for detailed write-ups and content that changes a lot. This also lowers the barrier to writing things up so I never end up with a situation where I have months or years of stories to tell that I end up spending days writing up to catchup on years later.

Additionally, as I have a history of doing insane things like putting apps I worked on running in simulators on my website I really need a clean way to easily drop in HTML with some basic templating (for the header and footer) whenever I need it. This is where a lot of people would say ok...I need to load in React, Vue, etc...but why? Using a full JavaScript library or framework here will increase load times due to the JS payload, and it couples the entire website to a framework which might be outdated (or will require updates to keep running to deprecations) in a couple of years. Rather...the cleanest approach here is just plain HTML with very light templating, ex: % %PAGE_CONTENT(html/footer.html)% % to load another HTML file or % %PAGE_CONTENT(out/SCO.html)% % to load a file generated from Markdown into the HTML. And if I decide to load JS into a single page that is quite trivial for me to do because the templating has the dependencies like CSS separate % %PAGE_CONTENT(html/deps.html)% %

For the curious this is what the site index looks like:

<!doctype html> <html> % %PAGE_CONTENT(html/deps.html)% % <body class="bg-gray-800"> % %PAGE_CONTENT(html/header.html)% % <div class="page-content text-center flex"> <div class="flex-1"></div> <div class="flex-10">% %PAGE_CONTENT(html/index.html)% %</div> <div class="flex-1"></div> </div> % %PAGE_CONTENT(html/footer.html)% % </body> </html>

I also wanted to support dynamic injection of variables into say templates and the like so using certain variables set by the page generator in a template like % %BUILD_VERSION% % or the % %COMMIT% % will automatically inject the respective value. The pattern of % % is in many ways a special case, within the page generator we go over each line in the template and if this string is detected we exact everything between the two sets of % % and then perform a string operation on this. If there is a ( present we can infer that this is like a function in the page generator, currently the only function is PAGE_CONTENT() which takes the path to a file and embeds it into the current template. In many ways this is very similar to a basic DSL or interpreter and is a very good fit here because the overhead of writing out a full block of code each time is simply not worth the complexity. If you're curious about basic DSL (domain specific language design) you can take a look at my write-up here.

The language choice is intentional as well. Because I had a fairly decent number of files (due to a lot of projects over a decade long career), templating system\DSL, markdown conversion, and just a general interest to learn something new I opted to write the page generator in Rust. The reason for this is the execution time is going to be fairly quick, and it can be easily parallelized down the road if performance becomes an issue.

The execution time is exceptionally important for me not because I pay for CI runners, but because my entire CI\CD for all my projects is self-hosted on largely consumer hardware and I prefer to commit frequently. What this means is if I make 5 changes in an hour and I commit each of them I will loose that amount of compute on a cluster that will not scale past it's physical nodes until the builds are done. However, because my CI\CD is on K8s I can just build on whatever is on free compute so a short window of multithreaded compute is very preferred for my network. My CI\CD was largely built from scratch as a custom git runner and the network is mostly built on consumer hardware (repurposed old PCs, eBay finds, hardware trades, cheap mini pcs, etc). On this note any time a change is made to the local git repo hosted on Gitea it is build and deployed then rsynced to the website.

VPS and hosting architecture

The biggest reason for this is I do not want vendor lock-in. I have run multiple different operating systems, over a dozen languages, and deployed to more platforms than I care to admit. Technologies change, platforms changes, companies come\go, and sometimes things just get nuked from orbit for no reason (like hardware failures). Having just a set of flat files one can upload anywhere and a very lightweight set of backend services when needed is very much preferred.

The other reason is I have entire home lab with spare compute and creating secure tunnels into the lab or automated jobs that process the data locally is not difficult. A purely flat file host would mean I do not have that option for my more insane projects when I opt to deploy them. And besides, the server upgrades are done daily as part of the regular cluster upgrades.

Regarding OS choice this is an unusual one here. This server is running Alpine Linux due to the size, lack of preinstalled software, and general low hardware requirements. On this same token the server only has your core Linux utilities, binaries for my own projects, and a nginx deployment which hosts the files for this site.

Site design

The design of this site is more intended to flow as a story, a showcase of my respective technical abilities, and personal notes on my life. It has no reason to be fancy, and I loose a lot by making it fancy with respect to things like page load time. And at this point in my career and my life it doesn't need to be fancy because I feel the work speaks for itself. In spite of the fact it is 2026 this site can load on dial-up and this is 100% intentional so that even the weakest connection in the densest conference means my site will load when I text a technical write-up to a peer.