December Adventure
The December Adventure is low key. The goal is to write a little bit of code every day in December.
December Adventure 2024
The Goal: continue experimenting with my "sqlite-scale software" idea. Essentially, how far can we push single-binary, low-resource, embedded-database software designs to replace big-tech platforms with community scale software?
As I start this adventure, there's a few recent projects and leads swirling in my mind:
- Breaking out the auth component of /cobalt into its own self-hostable OAuth server
- Continuing work on /cobalt itself, which is a mutual credit web-app
- More work on my "patreon-clone" Stripe integration
- Building an email list-building/sending tool for my grassroots /livable cities advocacy org
- Building an invoicing or event scheduling tool for /Spiral House
Again, not a todo list, but a sketch of where my mind is at as the adventure begins.
December Adventure 2023
The Goal: learn more about the /hare programming language and double-entry bookkeeping by tinkering on a command-line based accounting program called books
.
It would be great if I ended up with a prototype of a working personal budget tool, and if I was able to introduce myself to the Hare community and make some contributions.
Post-Mortem: I ended up getting COVID (for the first time) about a week in, and was out of commission for long enough that between catching up on what I missed and the holidays at the end of the month I never got back on the horse. But I did have fun with Hare, and used it as a baseline throughout 2024 as I evaluated many other new languages that I picked up (like Python, C, and Go).
/december-adventure Stream
December 2, 2024
/stream /december-adventure
Today I made some changes to how my VPS serves my web projects, and updated my local scripts to match. This integrates better with the way I plan to start deploying more executable services to the server, and which is how this month's adventure will take shape.
To be more specific, I have been so far just serving static sites out of my user's home directory on my VPS, so ~/www
. This is annoying, because the way I "stage" my local projects to test on my machine, I place sites (correctly) in /var/www
. This was forcing me to have multiple configurations for local vs remote deployments, and I realized that it was pretty unnecssary.
By aligning the way local and remote deployments work (both running NGINX configs that point to /var/www
), my overall infrastructure deployment processes would be much simpler. Now that I aim to expand my projects beyond static sites and into server processes, I wanted to get this shift out of the way now. It also opens up the ability to create new users that can deploy to certain folders, since all of the server's content wont be in my personal home directory anymore. On a collaborative project, I can now also give deployment access to projects on a folder-by-folder basis.
Not quite necessary yet, but it allowed me to eliminate some lingering branches in some projects that had to start migrating to this new system earlier, and lets me keep momentum on my adventure.
December 1, 2024
/stream /december-adventure
A small bit of work to get ready for the adventure today: I laid out my map, and updated some of my scripts from my recently finished stripe "patronage" integration to make it easier to repurpose as a general "service deployment pipeline" to my web server. The first week of the adventure will probably be busy with some say-job work, and so my goal is to just make sure to at least get in 15 minutes of adventuring each day this week to start strong. Onwards!
December 6, 2023
/stream /programming /december-adventure
Today's work was thinking work. Part of my goal of putting the /coalescent computer on pause was to start framing coalescent data within existing computing systems instead of a blank slate, and so I wanted this project to reflect that. Today I was thinking about how I would manage the different "resources" (accounts, entries, reports) in a coalescent way, and I think I came up with a plan to achieve that.
Each "agent" (user/node pair) will have its own event log, and each log can only be edited by its owner. A log is just a text file where each line describes some (CRUD) event on a resource. The logs can freely be synced with other agents, and each agent can keep track of how long it thinks each log is so that they know when there are new events to process in a given log. If my state tells me that agent1.log
is 40 lines long, but my local copy is now 42 lines long, that means two events have come in for that log since the last time I processed events.
Effectively, this means the CLI will have some commands that write to the local agent's event log, an event log resolver that generates and modifies resources based on all of the event logs as a single logical unit, and then report generating commands that work from the local resources. There can be a little bit of state on an agent that helps it track and cache what it's already computed, but it can also at any point just re-run through all of the event logs again to rebuild the current state. Playing back events means it will also be possible to catch instances where new events are trying to write to "closed" books.
This sounds complicated when writing it all down, but I think with a little more planning it should be possible for this to be implemented pretty quickly (minus syncing, which will just be done with rsync).
December 5, 2023
/stream /programming /hare /december-adventure
Another short December Adventure session today, but I implemented some functionality for creating and listing accounts within a project. For now, this is done by adding files to an 'accounts' directory inside the project, and having each account file be the stringified version of an account
struct. I should probably put together some kind of de/serializing functions that make it easier to re-ingest the text file back into program data later on, and also clean up the way I'm creating "resources" since I'll need to do a lot more of that. Honestly, if I have more than a few minutes to work on this tomorrow I should take a step back and do a bit more planning now that I have all of this infrastructure working.
December 4, 2023
/stream /programming /hare /december-adventure
I only had about twenty minutes for my December Adventure today, but managed to implement the books list
command using the config work from yesterday. I also refactored those config functions to work as a general key-value store, which made it very easy to then also implement books set project
to set the active project. Overall, the work I did yesterday made it so that implementing these other commands was pretty straightforward. I need to come back to this a bit later and think through the error handling a bit better, because for now it just unwraps all the errors with !
.
$ ./books list
spiral-house
home
$ ./books set project home
ok
December 3, 2023
/stream /programming /hare /december-adventure
Had a pretty packed day, but found a few moments to tinker. Spent most of today's time starting to learn about the fs
, io
, and os
modules of the standard library. Wrote a few functions for reading and writing files, and now the CLI for books
lets you set a directory where it looks for your projects by default. Trying to lean on the filesystem to do all of the work in this project, so this "setting" is just a file $XDG_CONFIG_HOME/books/root
that contains the path.
$ ./books set root ~/books
ok
$ cat ~/.config/books/root
/home/jak/books
December 2, 2023
/stream /programming /hare /december-adventure
Today's work on the December Adventure was more fleshing out of the command tree as I was thinking about the different types of resources that need to be created and managed. Things like accounts, journal entries, and so on. Fleshing out the tree has been a good test of my cli module, and is also a good way to think through the use of the program as a set of resources being managed.
I also needed to figure out a way to have the user set an active project and let the program know where to find project directories, and this led me to learn about the XDG Base Directory Specification, which is what defines the ~/.local, ~/.config, and ~/.cache directories, and what types of files should go in each. I learned something new, and also figured out how I should handle the default storage of configuration and state data for this program.
December 1, 2023
/stream /programming /hare /december-adventure
I've been cutting my teeth on /hare for a few weeks now, and yesterday I finally got my "learning project" (a CLI argument parsing module) finished. So today, I started work on a CLI double-entry bookkeeping program which I think is going to be my December Adventure for 2023.
Today's work was fleshing out a command tree using my new argument parsing module, and then learning about how the Hare compiler uses multiple source files. I can now compile a binary that executes a few placeholder subcommands.