This year started off pretty light when it came to programming because I’ve been addicted to the video game Against the Storm since last winter. But I eventually started working again on various projects – some old and some new. I didn’t do any programming in January, so we’ll start in February.
February and March
Over these two months I worked on my replacement for web access to my Taskwarrior TODO list because Inthe.am had shut down. In February I got the podman containers set up – one to run the taskd server and one to run the website I’d coded up in Flask. In March I had to write some rudimentary Javascript to get the website to highlight the selected tab (Overdue, Today, This Month, etc). The rest of the interactivity on the site works using HTMX, letting me focus on Python instead of Javascript, but I just wasn’t able to get that part of the site to work without a tiny bit of Javascript. I also added some fixes because the date/time widget assumes UTC. Of course, now that I have it all working correctly and get lots of use for it (especially when I’m at work and I want to quickly get something out of my brain’s short-term buffer), Taskwarrior went to 3.0 which completely changes the way the program works, the API, and the way syncing works. I think in the end it’ll be for the best, but it’s annoying that I need to figure this out. That may involve finally learning how to use PyO3 to interact with Rust or re-writing part of my backend in Rust. We’ll have to see where that goes.
April
Things really picked up in April, programming-wise. First off, I had to upgrade the dependencies in my Amortization program. This will segue into the next topic in a second, but essentially every time I upgrade Fedora, I get a new version of Python. This means I have to redo my virtual environment. So when I tried to run this program again, I had to pip install my requirements and since some of the packages were no longer available on PyPi as wheels, it tried to compile. When that failed, I upgraded the dependencies.
As I’ve mentioned before, because of the virtual environment annoyances, I’ve decided to rewrite all my cron utilities in a compiled language. If it’s a utility I have running via cron, it’s something I want to work all the time. I don’t want to have to run around recreating virtual environments (something I don’t mind for a program I’m going to run occasionally – see previous paragraph). So I rewrote my NASA background downloading program in Go. This was a real breeze. It truly is a pretty easy language to work with – a hybrid of C and Python in my humble opinion. I also used the opportunity to learn how to use Go’s new(ish) SLOG package.
I also took a few days to update the one project I know for a fact is used by other people besides myself, Extra Life Donation Tracker, to use PyQt6. It was an annoying couple days figuring out what has changed since PyQt5. Or rather, to be more specific, the Qt devs did a great job documenting what had changed, but seeing how that translated to what I needed to fix for pyinstaller to make an exe for my Windows users took a few days.
As I mentioned a couple days ago, I’ve started learning Rust. Just as I did with Python when I first learned it, I started with a project-based book: Command-Line Rust. However, while I was getting a good feel for the language, the author wasn’t quite explaining some concepts early enough (to my mind) like when to use a double colon vs a dot to access a function/method. So I started also reading The Rust Programming Language (2018 version) (link is to the newer 2021 edition). There I learned that (using Python terms) double colon is a static method (would belong to the class as a whole) while dot is a method on an instance of the “class”. While I probably could say the same thing about modern C++ or C, I think Rust is actually a good stepping-stone on the path that goes Python->Go->Hard Systems language. As a newer language with less baggage, it seems to be a child of Haskell and C, with functional programming being a first class way of programming in Rust. (I may be speaking out of my butt since I’m only a week or so into learning the language, but that’s my first impression).
Going back to what I said about rewriting my cron utilities in compiled languages, I may end up rewriting Snap-In-Time, my btrfs snapshot project in Rust. Based on what I did in the first project of Command-Line Rust, it seems like it would be pretty trivial (compared to Go) to retrieve and use the output of system commands (like btrfs sub snap, btrfs sub del, etc). If this happens, it’s probably a few months away.
Speaking of future projects, over at my personal Mastodon account (started before WordPress joined the Fediverse or I might have only used this account as my Fediverse presence) @djotaku I post my top scrobbled artists every week. (Here’s an example) This is another cron utility that I would prefer not to have to be mindful of when I upgrade Python (although, in comparison to the other utilities, it’s also the most trivial). I’m thinking of redoing this one in Go as (as of this point) interacting with a JSON API seems easier than in Rust. I’m basing that from looking on crates.io at the last.fm crates on there. Most of them are older (makes sense since a lot fewer of us still scrobble to last.fm than in its heyday) and none of them covered the endpoints I needed so I’d have to write my own. One last thing – even though many folks aren’t scrobbling anymore, they must be getting information from somewhere (I thought CBS either sold last.fm to Spotify or did a partnership) because this article mentions the researchers using it to analyze song lyrics.