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.

If Hemingway Wrote JavaScript by Angus Croll

My rating: 3 of 5 stars

The intro mentions the natural language nature of Javascript. I wonder if the book had been concieved a few years later if it would rather have been Python or Ruby - both of which are way more like human language than Javascript.

The book is fun and I mostly get it, but to truly get what the author is doing here, I think you would need to be a Javascript dev. The whole point is that the author is nerding out not only on the writing style of the authors they have chosen, but also converting that into Javascript coding styles. As someone who programmed in many languages, but hasn’t touched Javasscript in the the mid-90s, a lot of the elegance of this book is lost on me.

I didn’t really use any new programs this year. I just continued expanding on programs I’ve used in the past.

Python

For Python I continued to mostly use Pycharm. I’ve spoken about it for the past few years, but JetBrains continues to add features that make it easier to work with Python. For example, this year they added a model explorer to have better visibility into your models in Django. They also make running development servers for Django, Flask, and FastAPI a breeze. (Including restarting the server after every save).

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.

I started off the year mostly working on Python projects. For January and February I finally started making some great progress with understanding modern web frameworks and use of CSS frameworks rather than rolling my own. This not only helped with the Prophecy Practicum project, but would form the backbone to a lot of coding this year. I also wrote a utility to tally up my videos for my end of year video game roundup, saving me literal hours of time. As you can read from following the link above, I also worked on my long-running Extra Life Donation Tracker code.

December was wholly dedicated to solving the Advent of Code 2022 problem set. Our job was to help the elves trek through the jungle to get magical starfruit. It was a lot of fun to do it live once again! This year I also had experience from the previous years (both live and on my own pace) that gave me the skills to solve some of the puzzles, including some puzzles that were variations on themes I’d seen before. In the end, I collected 36 stars, near my average for number of stars collected during AoC. Between work, family commitments, my programming and problem solving skill levels, that’s about the most I can usually do during the live period in December.