It takes a massive hiccup in the daily operations of the digital world to force one to take a full accounting of what one has wrought over time. Over the two decades of web work that I’ve done, I’ve created and managed (and deleted) quite a few websites. I’ve built custom servers and tools and installed off-the-shelf blogs for personal and professional use. It’s old hat and maintaining the infrastructure for all of that work was not something I spent a lot of time thinking about… at least until DreamHost changed the machinery supporting their VPS hosting plan over ten weeks ago.
After discovering that their workaround solution did not support my Git/LFS server, I signed up for their DreamCompute plan to see if this platform could host all of my various bespoke services. After spending weeks coming up to speed and transferring gigabytes of code and data, I can now say that I am a happy customer again. I did have to learn and relearn quite a few things about maintaining a server and its software environment, but the time spent migrating the various code and data associated with it all to new servers was worth it. I have switched everything to the new environment and it all works… all 34 websites across 3 domains.
Yes, you read that right. 34. Phew… An accounting of all of my work proceeds from here.
Brick Mill Games, LLC
Brick Mill Games, LLC is a partnership formed between myself and Paul Chicoine, an old wargaming friend of mine. We met at Phoenix Technologies when we were both BIOS engineers back in the late 80s.
Without going into too much background detail, Paul and I are developing a double-blind wargame with computer support, the latter acting as the all-seeing arbiter and referee. In our game system, reconnaissance is not only possible but a requirement for successful military operations. This sort of system requires coding of both the browser-based client and the server back end.
The Crux Application Server
The Crux (pronounced “croo”) Application Server was a garage project I began in 2005 after reading a technical article on the inner workings of the XMLRPC protocol used by WordPress when it was brand-new blogging software. After reading the article, I thought to myself, “That thing is full of security holes. There’s got to be a better way.” (Turns out, I was correct in my assessment. WordPress sites began to suffer from DoS attacks soon after and continued for quite some time.)
The Crux system relies on a service specification system. In order to publish a service, a specification for that service must be written. This specification is then compiled into two Ruby code files: a service code module and a contract code module. The service module acts as the front-end to the incoming service request and handles such things as user credential checking, if specified, and input parameter sanitization. The latter is done by comparing the incoming data against the contract parameters. If the incoming request passes these tests, then the data is passed to the actual code libraries which get the work done.
The Crux system has come a long way since its humble beginnings in 2005. The original transport format was XML, which then added YAML support, which then switched to JSON. Service data consists of JSON data packets and/or binary resources, depending on the service specification. Credential tokens rely on JWTs. Communcations are handled via the typical HTTP 2.0 protocol, though WebSockets support is on the drawing board to support push notifications and SMS support will be added to support two-factor authentication of user logins.
In addition to the Ruby-based service handling code, the Crux system contains an embedded Javascript web site called IMDE, or Integrated Management / Development Environment (pronounced “im-dee”). IMDE contains site configuration and management code which allows for service developers to compile the specifications and test the services directly. It is somewhat archaic in that service developers need to login to the server directly and edit the specification files as IMDE has no built-in editor, but addressing that lack is also in the Crux pipeline.
BMG has two Crux servers in operation, each at their own URLs, in their own subdomains: a production server and a development server. The production server is several Crux versions behind, but supports a dice rolling server, which is also at its own URL. The development Crux server is up and running to support TOCS application development and there is also a developmental dice application that is updated to support Crux application changes.
Subdomain / Website Count: 4.
TOCS: Tactical Operations Command System
TOCS is the double-blind wargame system being developed by Brick Mill Games, LLC. It is composed of at least two web-based applications, with some additional test applications.
The TOCS application is the game playing application. Once completed some time before the next century(!), users will be able to purchase and/or play games against other opponents on-line. It is under constant development as most, if not all, of the code is written in-house.
The MDK application is the Module Development Kit. When completed, it will allow module developers to create game module which can be played within the TOCS system. It has only begun development within the past year or so. Pete Willey, an ex-Qualcomm coder and fellow NH hiker, has joined the project to bring the MDK to fruition. While Brick Mill Games has the data for three modules completed, all of that data is in a format which was suitable for paper game production (the original goal of the project), not on-line game production. The MDK will eventually become the single source of truth for module data and Paul and I can get out of the spreadsheet creation and transmogrification business.
The DevFX application is a code module test harness. To support TOCS and MDK app development, there is a raft of Javascript code modules under development. They are:
- XAPI: “eXtensible API” (pronounced “zappy”): extensions to various DOM and Fetch API functions
- Crux: the Crux server interface library
- Cartesia: 2D Geometry Functions
- PixMill: 2D Graphics Functions
- WebFX: User Interface Controls
- TFX: TOCS-specific User Interface and Data Management Controls
Each of these applications / test harnesses require their own URL / subdomain and comprise a “sandbox”. With three developers each requiring their own sandbox, we have a total of nine websites / URLs to support development.
Additionally, the TOCS and MDK apps have their own production URLs as well, though they are not being used at the moment.
Subdomain / Website Count: 15.
Database Support
The Crux application server requires a database to store its data into. Under the original DreamHost hosting system, DreamHost provided a database management tool called phpmyadmin with which to create and management databases. With the move to DreamCompute platform, I needed to install my own copy of phpmyadmin, though “need” is not strict. I could have done without, but it would make administration and development more difficult.
This tool requires its own URL.
Subdomain / Website Count: 16.
Support Sites
Brick Mill Games has its own set of code repository, wiki, blog and other documentation sites. Even though the blog has been quiet since 2023, it still needed to be migrated and supported. This set comprises seven additional URLs.
Among the code repository sites are the infamous Git/LFS site as well as its own rubygems site.
Subdomain / Website Count: 23.
Kenware / Mill #6
I maintain two domains for personal use: kenware.com and mill6.online. This set of websites consist of this blog, a wiki, a Ruby code repository, genealogy and other sites related to boardgame projects in various states of development.
Final Subdomain / Website Count: 34.
Epilog
It was a lot of work. Migrating the existing code files and data from the original machines to the new servers took time and effort. Learning new systems, installing new software, defining user policies and permissions and managing it all added a lot of overhead in a short amount of time.
I’m still not done. With the dismantling of the VPS servers, I no longer need to pay for the VPS hosting plan. As multi-year plans were paid for up front, we are relying on DreamHost’s policy of a pro-rated refund. Other billing complications remain.
Finally, three days ago, I discovered that the mill6.com domain became available. I only took mill6.online at the time because mill6.com was unavailable. So I bought it. Now that the mill6.com domain is under my control, I will be migrating mill6.online to mill6.com over the next couple of weeks.
It never ends. Who needs a day job?