It’s been a long, long time since I’ve worked on a website for myself, and when I say “a long, long time” I mean “actually had a roadmap to follow”, and when I say “for myself” I mean “not for my day job”. Most of the projects I’ve tried working on in my recent past have been based on self-imagined high-level concepts that lacked concrete steps or fleshed out ideas. These shortcomings have ultimately led to half-assed attempts and a tapering-off of interest. Add to that the fact that these projects were literally just to have busywork to do when I was bored. All of these issues mean that the last site I actually created fully formed and published was a site for our small corporation in EVE Online, circa sometime in the early 2000’s.

Recently I’ve been working on a new project with actual purpose. Some members of Star Citizen organization I belong to, Armored Expeditions or ArmorEx, had been chatting about the kind of activities we’d be tackling in the game eventually, and how to manage the processes and outcomes to maximize efficiency and profit. For example, cargo hauling promises to be a pretty involved affair, with tracking down the lowest priced, highest availability commodities to buy and knowing where to sell them, getting org mates (or hiring NPCs) to load and unload ships, and of course rounding up escorts and assembling soldiers to repel potential boarding parties. Because of the “Quantum System” simulation, having up-to-date information is going to be difficult without a way to track it outside of the game.

The thing is, I don’t normally take the initiative, especially in groups of people I don’t really know. My gaming social history is littered with failed attempts to join someone else’s group, and I’m lucky if I manage to stick around long enough to actually get recognized never mind participate. This time, though, I’ve toughed it out because Star Citizen practically demands that players join forces, as it ultimately promises be fairly solo-unfriendly (The “Dicks in Space” Conundrum), and because overall this is a really great bunch of people. Since I’ve been spending a lot of time shifting my development perspective from one front-end platform to another, have been learning a lot about Node, Docker, and yes, even some required smatterings of Linux, I volunteered to take the lead on creating an online tool for the organization’s needs.

My first step was to write out — long-form, as is how I’ve taken notes since college — what the site needs to do. This is usually where I skimp in my projects; I rely mainly on vague ideas of an end-goal and fill in the gaps as I go. Sometimes this works as expected, but it also fails to keep me focused enough to feel that any “micro-goals” have been achieved. As someone who needs to see progress in order to feel that my efforts are making enough of a difference to warrant sticking with a project, I’ve learned that checking boxes on a regular basis is essential for keeping the momentum. Having a document to compare against has so far been incredibly useful in that regard. It was also necessary as I’m technically working with a small group of other members who have different tasks in an overall “org tools” strategy. The document is something that everyone can look at, add things too, and cross things off…something else that I’ve lacked in my usual lone-developer M.O.

Next comes the data store, which has been the trickiest part of any development project I’ve undertaken in the past 20 years. Back when I worked for a web development company, I was allowed to take as much server space as I wanted, which included using the SQL Server databases that our official websites used. As a result, my strength lies in SQL Server development, which is good for my current day job, but not so much for my personal projects since MSSQL is not a free product. Hosting is another problematic aspect since finding a host that offers database access and web space is not as easy as you might think. Looking ahead, I’ve kind of avoided commitments to data storage knowing that if or when it came time to deploy, I might have to completely change my data storage strategy based on what I could find for hosting.

Since I started working with Docker, however, a lot of those concerns have evaporated to the point where I feel I have a lot more breathing room. Services like Heroku or Digital Ocean offer the ability to deploy a Docker container, meaning that with a carefully constructed docker compose file I could run a MySQL or Postgress database alongside a Node-based web server and not have to worry about the amenities that the host offers. Even so, I am prototyping with MSSQL (in a Docker container, no less) in order to get the ball rolling.

Speaking of Node, my third step was to create the API that would allow the front end to access the database. This uses ExpressJS and MSSQL interface library built on Tedious to serve API endpoints. The first order of business was to deal with user storage. I had floated the options of using Discord to authenticate and authorize users, since that’s where the org’s community presence is currently based, but one possible mandate of the site’s tools was to open them (with limited access) to anyone in the Star Citizen community. That might require a stand-alone user management system, so that’s what I did first. Then I stubbed out a roles-based permission system and have moved on to a way for org admins to post news to the site, using a familiar blog-style paradigm. None of this has a front-end yet, though, so I’m testing the endpoints using Postman which is a fantastic tool for kicking the tires of RESTful services. I’ve also created a mobile “data layer” that would allow me to re-write the MSSQL interface for another data store and not have any meaningful effect on the operation of the API server itself. It’s only taken a few decades for me to get out of my own way…

I do still have periods of “aww fuck this” which cause me to close out the IDEs and go do something else entirely. I am still not as proficient with Node as I am with C#, and with my “seat of the pants” coding style I often find myself testing implementations that were obviously not ready to be tested (the developer’s version of “we’ll fix it in post”) and although it’s entirely my fault for not taking more time to think about what I’m trying to do and how I’m trying to do it, it’s still disheartening enough that I opt to step away for a while lest I get into my trademark “burn it all to the ground” modes.

It’s nice to have an actual reason for out-of-work development again. Having people depending on the outcome who aren’t just me is a massive help, and wanting to complete a project that has some cool ideas on paper is a great work-driver as well. So far, the first pass implementations have been going well, though I expect serious revisions once I do get around to slapping a face on the project. I have been kicking around some UI ideas, although other folks on the team have been coming up with the actual systems that the site would offer, including a really cool “org missions” component that would allow members to offer missions to other members and/or coordinate larger-scale efforts like mining or caravans for cargo running. Although the game itself isn’t fully formed enough to make some of these systems completely usable, not having a deadline is actually a good thing right now, as it’s allowing me to take the time to do things right.