Good Morning from my Robotics Lab! This is Shadow_8472, and today I am working on a dice bot for a role play on Discord for a few friends. Let’s get started!
Seeking a Container
Many projects are like a tree in terms of having a general sense of progression up from the root and the fine details take most of the work to perfect. This week, my project was a rose bush. I have an end-goal in mind, but I want to run it from a container, a technology I still haven’t fully introduced myself to.
My plan started out simple: find a Discord dice bot already in a container and get it on the server. DockerHub, a sizable repository of OCI (Open Container Initiative) container images. (Most places call them Docker Containers due to its popularity over the past ten+ years. Searches for help should be worded accordingly.) I located about the only one that met all my simple criteria and made myself a bot account for it.
Discord bot accounts are more similar to human accounts than I gave them credit for. The only big differences are that bot accounts log in with a token instead of a username/password and the interface is different to accommodate a program instead of a human. Just as you only interface with your account to make posts, so too does a bot interface with its account to make posts. Give the login to someone or something else, and Discord shouldn’t care.
Long story short, the bot was set up to use an environment variable when using the image to make a container. Once I got it logged in, it ran into other problems I wasn’t prepared to diagnose.
Learning to Build Containers
With my only obvious option a bust, I set my sights on a Discord dice roller I’ve used in the past made by SkyJedi for the Star Wars tabletop RPG’s and a generic spinoff called Genesys. The game I’ll be running is GURPS, which focuses on using 6-sided dice. Plus it has an interesting turn counter system for combat I’d like to try using. The rest is fluff to me this time around, so long as I get it working.
A quick tell of an intense week is when I spend a whole day watching tutorials on the same subject over and over again until I find one at my level. This was one of those weeks. I remember there being one breakthrough video right at my beginner level that let me go back and follow the logic of more advanced tutorials that previously dazed me. During this intense study session, I puzzled together how to use Buildah at a beginner level, what a Dockerfile does, and went from muck to murk in my understanding of Javascript.
Buildah is a for making OCI containers Podman can later run and another tool I haven’t yet explored can edit. Like Podman, Buildah’s corner of their ecosystem aims to replace Docker commands one for one. It’s a win for people switching from Docker, and a win for newcomers like me who can look back at pertinent Docker documentation.
Docker –at least– takes a layered approach to making containers. Using a Dockerfile (one word, also its file name with no extension) lets you build start with a base image and build it up layer by layer, one command at a time. Parts can then be swapped out and the image rebuilt as needed.
The Star Wars dice bot is written in Javascript. If there’s one thing I learned about Javascript this week, it’s that there are several “frameworks” for both front-end development (used to make things look nice for users) and back-end development (used for internal logic). More specifically: I needed to look into NodeJS, a back-end framework. Node has a few different base images on DockerHub, so I worked with the full one with the intent to swap it out for smaller ones for a much smaller image.
Assembling My Own Containers
It took a very special set of circumstances during my self-study for containers to really click. First, I’ve been working through the Podman plugin for Cockpit. Individual images and containers are presented in an intuitive way. Each container has tabs for info, logs, and console access. The life cycle of a container is tied to executing a single command, but if that command is to start a shell, I can interact directly with the container like I would at any other command line. I could test commands from there, and if I got something right, I could add it to the Dockerfile for my next iteration.
I was actually able to find SkyJedi’s Discord server and contact him directly. He wasn’t familiar with containers enough to help me, but he did direct me to a much simpler bot of his I was rapidly able to package into a Node container – and later a Node:Alpine container.
The difference was login token. No matter what I tried, the full dice bot would not accept its login token. I was not able to figure this out, though I came quite close.
Side Project
I’m considering a new weekly segment where I work with my 3D printer a little bit each week. This week, I printed up a calibration cube using everything I’ve learned so far. It’s still far from perfect. I still need to tune in my Z-braces, as I can tell from some faint ringing I can more easily feel by running my thumbnail across it. I still need to calibrate my E-steps, a process I may need to repeat a few times as I come up with interesting, new ways to improve my printer.
Takeaway
After all that, I looked ahead at a the database I’d need to deal with once I get the bot logging in, and I’m almost certain now that my time will be better served making my own bot in Python. Of minor interest, I was able to learn the curl command better. Rocky Linux apparently doesn’t come with wget, the terminal program I usually use to download files. Curl –on the other hand– copies the contents of links to the stream. When directed to a file, it does the same job as Wget. A cool trick I pulled off involved manually following a redirect link.
Final Question
I feel like a rose bush gardener with nothing to show for his work but the tools he’s learned to use along the way. What projects have you farmed up a bunch of dead ends on?