Yeah, it’s been a little quiet outside the mill. Inside, it’s been anything but. That’s on me. As I’ve stated numerous times before, once I get into a zone, or multiple zones simultaneously, I hunker down and posts like these get infrequent.

So, the standard excuse list still applies. Day job pressures and side project distractions continue. The former pulled me from a standard routine at work and put me on a customer-specific, time-sensitive project. With that successfully complete, I was looking forward to a return to the standard, controllable routine, but I’m getting shunted onto another time-sensitive project… possibly… we’ll see what the tea leaves reveal.

A decades-old question about the origins of my family name coupled with a time-sensitive offer from ancestry.com pulled me down the genealogy rabbit hole for the past three months. The good news is that I was able to trace my family tree back 13+ generations to France and other points, solving the mystery in time for my elderly parents to enjoy it. Thankfully, I was able to take advantage of all the good work done at Programme de Recherche en Démographie Historique (and its associate site Généalogie Québec), FamilySearch, Ancestry, and the amateur genealogists at WikiTree, NosOrigines and the French Canadian Descendants group on Facebook who have been collecting and cataloging and researching a lot of the older data so I didn’t have to. The research was fun, interesting and eye-opening as all historical research is (to me), but it was a major distraction. With the family lineage completed, I can focus again.

Crux

Crux is our home-grown web application framework. It began life as a thought experiment 15 or so years ago regarding possible security issues around a framework called XmlRPC, which eventually became the framework used by WordPress. I had read a tech article about its design and saw obvious security holes; the fact that WordPress sites were later hacked did not come as a surprise to me.

With our TOCS scenario research and module development support systems in place, Paul and I needed to start writing the game client. To do this, we need to flesh out the server-side services to support such work. Crux has been used by our dice roller for years now, but the software architecture itself needed to mature a bit as it grew from a simple publicly-accessible single-site system (the dice roller), to a credentialed, multi-app system.

Or, should I say, we needed to find out that Crux did not support such a system. There were things we didn’t know we didn’t know. Crux was an old side project that had been shelved numerous times in the past. As Paul and I started doing service & client development, we kept hitting hurdles that my old memories told me had been solved. They had been diagnosed and addressed, but not completely solved. All the initial coding had been done based on theory and the testing had been done using command-line Ruby scripts. Once we started hooking the system up to some real browser-based applications, including a real services sandbox testing app, the logic gaps appeared. They were easily fixed; as I said, they had been diagnosed in the past, but only partial solutions had been implemented. Fixing the “last mile” required hooking the system up to apps doing real work.

Ping

Ping is our services development sandbox app. We didn’t know we needed such a thing until I realized that my original Crux testing method of logging in to the server using the one login account and writing Ruby scripts on the server was not a good practice for team-based development. It certainly doesn’t test the API in its proper Javascript environment. Ping allows both Paul and me to call each individual service and see its result. It will also allow for rudimentary database browsing to see the results of these service calls on the database. It is a credentialed app, obviously, and an app that must exist within the Crux infrastructure outside of the game client.

Web Development Infrastructure

Doing development on a live, production server is also not good practice, whether you’re talking about the HTML/CSS/Javascript trifecta of the app or the services infrastructure. So we had to spend some time building both test services and test client sites. This took time as well as building good tools to support management of code files on the server that need to be copied back into our git repos.

Documentation & The Learning Curve

Most of this work has been inside my head, or living as a side project, for some time now. While I’m not an expert per se, I’m fluent enough in HTML/CSS/Javascript/Ruby/AJAX to be able to design and code this thing. But the entirety of what needs to be done is too large for any one person to do it. Paul has been coming up to speed on all of these technologies, none of which applies to his day job.

In order to help him get up to speed, and to get information out of my head, we needed to generate code documentation, not just for the web development aspects of our work, but for all of the code we’ve been writing. After looking at the available code documentation tools out there, most of which address one specific or one type of language, I decided to write my own multi-language code documentation tool.

Codoc is our multi-language code documentation tool and it supports C, Ruby and Javascript. Codoc works by examining the source files for specially-formatted comments and emits HTML web pages. These pages can then be hosted at a URL for our use. While not everything has been documented yet, the capability is there.

Onward

So we’re still busy behind the scenes. Still distracted at times, but we are still moving forward.