Quis tracket ipsos trackores

If the formatting of this post seems odd or incomplete, try viewing the original on my site.

In service of fulfilling one or two of the subcomponents of my new year’s resolution to (largely metaphorically) “drink more tea”, I’ve been working on my suite of media trackers, which now broadly record everything I want them to, i.e. books, films, manga, games, and Pokémon. Apart from the last, all of them are based on my main set of journal files, which I’ve been keeping in the same format for about five years now. I think a lot of Emacs users have some kind of journal system based on using a single file for a month or a year, or logging items of the same type in the same file, but mine have always been based on a filetree that distinguishes years, then months, and lastly contains a different file for each day with anything related to that day contained within it. It seems that when I installed org-journal in 2022 I was already using this system and merely configured the package to work around it. Of course users of inferior text editors don’t tend to have the option to do this and just have to deal with whatever structure is imposed on them by the software, which is quite cringe actually.

With the help of org-capture I use these files to log pretty much everything, including my engagement with various forms of media but also brief private journal entries of the sort I might previously have overshared on social networks, archived posts from a variety of deleted and just-about-clinging-on microblogging services, places I visit (also tracked on this site), the complete record of all concerts and services I’ve sung/played in going back to 2009, and even typed-up entries from the physical planners I used between 2008 and early 2018 – the digitisation of these being a work in (very slow) progress. This list has ballooned over the years, as has the amount of time it takes Deft to initialise. When I started tracking all these things in a filetree I naturally had no idea that I might one day be using a. a big old Python script to put them on my website, and b. various org-capture templates to make recording everything easier too. It goes without saying that my Python and elisp skills weren’t at an adequate level to set this system up at the time, but several years of making increasingly bizarre static site generators have since honed them.

When I built the games tracker I based it on the (then brand new) Backloggery design; when I first made the book tracker I wondered about basing it on Goodreads, although enough of the Goodreads features were irrelevant or unnecessary for me to decide it wasn’t worth trying. Similarly, I briefly thought I could base the manga tracker on MyAnimeList before realising the way MAL displays statistics doesn’t really appeal to me. Everything except games (and Pokémon, on which more later) therefore shares a common design and looks the same as the rest of the site, which is probably a good thing. There are a few features I’m thinking about trying to implement in the future: perhaps some kind of area for brief reviews of books or films that might once have been monthly roundup material. Then again, I don’t know if I really want to share my opinions on media outside this household – apart from “I really really like final fantasy ten, oh god I like final fantasy ten so much,” you can have that one for free.

There’s also an argument for keeping all this light on features so as not to slow down the build process. Thanks to the life-changing firestarter package I have the build script set to run every time I save a journal file, but this conversely means I can’t really save more than one such file in the time it takes to run the script. Fortunately it only takes about five seconds to build everything and sync the pages to the server via rclone, but I don’t want it to get much slower than that. Possibly there is some refactoring that could be done à la swapping out lists of dictionaries for dictionaries of dictionaries, a nuance that was lost on me when I first started putting this together but has undoubtedly made the latest addition (the manga tracker) more efficient. I definitely and perhaps more urgently need to do something similar in my TCG site build script, which takes several minutes to run in its current state, plus several more microseconds every time I add another card to my heaving collection, no doubt.

Having synced the org-capture templates to my phone recently and made the various changes to my config that allow me to run Emacs on Android without errors, I can now track all this directly from my phone as well. I previously thought there was an issue with tab completion in the Android version, but thanks to our good friends at StackOverflow I learnt it was actually a problem with the keyboard I was using. Now that I’ve installed Unexpected Keyboard in its place, everything works as well as can be expected for a tiny touchscreen. The Python script that generates the HTML files also compiles lists of books, manga, and games in progress, which are then passed as completion lists to the org-capture templates. This minimises the chance of recording the same piece of media twice with slight variations in the name. For manga, I also have another file that lists each series along with the number of extant chapters and volumes. This requires manual updating when new chapters are released, which is a bit of a departure from the spirit of the whole endeavour (and certainly from the “drink more tea” ethos; you will have to take my word for this), but the alternative was to try finagling something involving making API calls to MyAnimeList, which definitely would have slowed things down and also would have relied on that website holding up-to-date versions of the relevant information, which seems not to be guaranteed based on my investigations.

“Ah, but you could have created an account on that website and updated the information yourself.”

Look, don’t make me tap the sign. (The sign reads “I will not make an Account on a Website”.)

I wrote quite a lot of the Pokémon tracker on Christmas Day on my phone, including most of the CSS, which was a predictably excruciating experience. This one is based on a single table that contains all my Pokémon across the different Switch games I own. If I move a Pokémon from one game to another or it levels up, I simply update the relevant cell in the table, and via firestarter the page is rebuilt when I save the file. I based the appearance of the page loosely on the Home mobile app and downloaded the images from Bulbagarden (”Bulgaria”, my phone helpfully suggests). The filters for restricting which Pokémon are displayed by level are very helpful for checking which of them I should be including in my party; they’re big fat dirty CSS, in the sense of “a big fat dirty beat”, and probably nobody should look at it unless they want to be horrified. The process of adding everything to the table also taught me that while I think I’m very witty with my incredibly obscure references that I use as sources of Pokémon nicknames, there are in fact a few nicknames that I’ve used more than once: Squeako (two Pikachu), Tavros (two Tauros), Hex, Spike, Xanthe, Bridget, Vilia, and three Brians.