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.

Just a few thoughts on programming languages that have been rattling around in my head this week, but which don’t each merit a full blog post. The main theme is that the culture behind each programming language leads to some interesting choices, as is the case with spoken languages.

This week I started learning how to program in Rust. Even though I’m using the project-based Command-Line Rust to learn, the author still went with the traditional “Hello, world!” project for the first intro to the language. I was also working on a Go project last week and so it immediately stood out to me that (at least as taught by this author) Rust has the print! macro that allows you to succinctly print to the command line. By contrast, Go requires importing fmt before you can print. This was the first topic that was swirling around in my head this week. What makes language designers choose whether printing output (one of the most basic things a program can do) is built-in or requires an import. I even remember back when I was learning Java in undergrad (I think it was Java 1.8, but I don’t remember) we had to use the savitch library just to get program input (another very basic computer program concept). As I thought about it, I wondered if it has to do with thoughts around compilation and whether the language designers think you’re mostly making user-interactive programs or libraries? It makes sense to me that scripting languages like Python, Ruby, and Perl would have print built-in since you always have to have the interpreter along with you, so all the basics should be there. (The original Batteries Included Python promise, for example) But perhaps the Go developers thought you wouldn’t always be printing to the command line so a more efficient binary could be compiled by forcing you to import the functionality? I’m not entirely sure.

In 2023 I just didn’t have the urge to do as much programming as in years past. I felt more of a tug towards video games, reading, and baking/cooking. So this recap will be quite a bit shorter than usual. A couple upfront themes and ideas: The programming was essentially Go and Python. I started reading a book about Julia, but didn’t do any new programming in Julia. I mostly worked on new code vs maintaining older code.

In March I continued to work on my programming projects as well as a little more Advent of Code.

Things started off with me finishing up my dreamhostapi and Dreamhost_DNS_Go projects in Golang. I got the API working under all the conditions that I need and I worked on both the output of the program and the logging. It now functions quite well for me to keep my dynamic DNS URLs up to date. My next step is something I’m going to do in a few of my cron scripts - have a separate JSON log that could be interpreted so that I could either have a daily email to let me know that the scripts all ran correctly or so that I can load them into Prometheus/Grafana to see on a dashboard how all my scripts are doing.

I recently used Mastodon to ask for recommendations for Go podcasts and one of the suggestions was Go Time. One of the recent episodes in the feed was a rerun of an older episode about " How Go helped saved HealthCare.Gov". This was extra interesting to me since I wrote my Master’s Special Project on Healthcare.gov. (I haven’t read it in nearly a decade, so I don’t know if it’s cringe-worthy at this point). The episode had on one of the programmers who helped get things back on track for the site. It was incredibly informative about the problems that led to the site not being responsive enough and how they were able to help fix it without scrapping the entire site. No matter what side of the political spectrum you’re on or if you’re even an American, the episode is fascinating for understanding how things can go wrong even when everyone has the best intentions and how to fix a large, complex code base.

January

January was a relatively light programming month for me. I was focused on finishing up end of year blog posts and other tasks. Since Lastfmeoystats is used to generate the stats I need for my end of year music post, I worked on it a little to make some fixes.  The biggest fix was to change the chart titles not to be hardcoded. I didn’t realize it until I was reviewing my blog post, but I had hard-coded the year when I first wrote the code a couple years ago. I also changed the limits on some of the data I was collecting so that I could do more expansive trending for my overall stats.