Hello code, my old friend

It's been a while since I've been writing code more than a few lines at the time. Since the pandemic situation eased out and I've been able and allowed to organize in-person events again, the last month has been quite busy with events almost every night.

Every now and then I was thinking about spending a Saturday to code but then when Saturday came, I had trouble getting started and week after week, no code was being written. Given that I only code as a hobby these days, it wasn't really a problem but since I do like developing and building things, I really wanted to get back to it.

Last week I finally then had an evening with no events, no hockey games on TV and nothing else to do. I've been developing a decklist validator for an unofficial community format for Pokémon TCG called Gym Leader Challenge. As the community announced their first ban list additions, I knew I had to do a bit of work to update the app.

Starting point

When I originally built the validator in August and shared it with the community, it was built in the most prototype way ever: just make something that works and validate the use cases and needs with it. I had to test out a few things since I wasn't quite sure how implement them and ended up with two half-broken repositories of code. When a new set came out, I had to run some Node scripts on one project, then copy-paste the output into files on the other project and test and deploy from there.

It worked but only barely and every time a new set came out, I had to read through the code to remind myself how to run the updates. I had completely failed to document the whole process, since I was always in the mindset of "I'll fix this one day."

Improvements and fixes

Good thing was that I had something that worked. I was able to make the banlist function with the old code and deployed that which gave me plenty of time to tinker with the rewrite.

Since everything was a mess, I decided to do a full rewrite now that I had confirmed the need and usefulness of the application. And I also had learned from updating the content a few times what were the pain points on that end as well.

Unifying two projects

First and foremost priority for me was to bring all of my experiments and pieces of code into one place. So I started a new project by creating three different sub-projects inside: one for admin tooling containing all the necessary scripts and documentation for how to do content updates; another one for the API that I use through Netlify's Functions as a serverless function; and finally one for the web frontend that the users interact with.

Documentation, documentation

For someone as passionate about documentation as I am, this project has been the most horrifying of my projects in terms of lack of documentation. This time I started with the documentation. I already knew how the application works and how I want it to be developed and operated so I started by writing a README file to both the root folder as well as the admin tooling folder.

In addition to writing things in readmes, I think one good way to document workflows is to add scripts into package.json. If everything you need to run is covered by those, it's easy to find out what's happening.

The documentation and naming is not yet perfect but it's a huge improvement over the older situation.

Interactive CLI menus

I'm a huge fan of command-line interfaces. They are not best for everything but for smaller scripts they are a nice balance between the power of command line and documentation through menus rather than having to remember flags and arguments.

To add new sets or to adjust the ban list (the two main data points for this app), I can run npm run start (probably will rename to npm run cli at some point) and get interactive menu that tells me my options and allows me to manage the data.

Data separated from build

Another "fail-safe" I built into the system is that downloading new sets or adjusting the ban list don't actually change the data API uses but generates a local flat database (as JSON files) that can be then moved into the API with npm run build.

By building a separate build step, I can feel bit more confident that when developing or experimenting, I don't accidentally destroy the data for the API.

Improving the situation for future me

All of one evening's work and nothing to show for.

All this rewrite work didn't change anything (other than fixing some validation bugs) for the user. But it enabled a lot of possible improvements in the long run and that's why I really enjoy doing this kind of work. I've always been really excited about building tooling for the people behind the scenes.

Since I can now feel confident that when the next set of cards hit the market, I can update the data for the validator without a worry with just a few well-documented steps, I can focus all the attention to the improvements of the app.

I kinda want to start learnin Svelte and am considering building the frontend with that and then start envisioning new features and functionality.

Gym Leader Challenge format

A side note about the format itself. I think it's the best way to play Pokemon TCG these days. I wrote about it in August a bit more in depth in my gaming blog and now that I've been playing both GLC format and the current standard format quite a lot since, I'm really happy I found this format. It balances out so many annoying things about the fast-paced hard-hitting meta of standard.

So if you're a Pokémon TCG player who's growing a bit tired of the current format or want to explore something new for funzies, check out gymleaderchallenge.com and join our Discord community (find current link from the glc website) to find discussion, decklists and people to play with since it's not official format supported by PTCGO.