More Fun With Local AI Models
A few days ago I mentioned playing around with local AI models, despite having low strength hardware for the task. Yesterday I was trying our some new models - tinyllama and smollm2 - and I asked each model the same question to compare the answers. After doing this for a few questions, I had the same feeling I always have when I’m doing a repetitious task: computers would excel at this!
My Year in Programming: 2025
Since I started making my end of the year posts this is the year in which I did the least amount of programming. This was actually slightly done on purpose. When 2024 was ending and 2025 was starting I looked around and realized that I only have a few years until Scarlett is an adult and a handful after that before the twins are adults. I don’t want to get all Cat’s in the Cradle about it, but looking at my own life, I know that even if we maintain the best relationship, the kids will never have as much time to hang as they do now. So I prioritized playing with them - mostly TTRPGs, but also video games and whatever else they wanted to play. Programming is often a solitary pursuit and most of my utilities do what I need them to do anyway. I also spent of a lot of my weekends cooking and baking - again providing for the family.
2024 Programming EOY
This year was a bit light on programming. I was focused a lot on gaming, cooking, and Tabletop Gaming. (No surprise if you’ve been reading my December blog posts) I constantly found myself desiring to code and I definitely had a few ideas - like a utility to extract EXIF data out of my images for use in Hugo. But when I would sit down at my computer I often found myself preferring to play Cities: Skylines II or Against the Storm. (More on that when I post my EOY video game post) As per usual, let’s go month-by-month (after the first quarter that is)
Advent 2024 Day 03
Time once again to review my Advent of Code solutions! Also the latest die or dice from the Dice Envy Advent Calendar; scroll below the AoC code to see today’s die.
Advent of Code
As the years have piled on, Eric Wasl has thrown in references to past years’ problems. However, as of day 3 we now have 2 references (perhaps that’s what the historian story line is about). Day 02 had you visit the location of 2015 Day 19 and today visited the location of 2020 Day 2 (my first year doing Advent of Code!) The only thing I’m slightly worried about is if this signals that this year will be a grand finale for the annual event.
Advent 2024 Day 02
Time once again to review my Advent of Code solutions! Also the latest die or dice from the Dice Envy Advent Calendar; scroll below the AoC code to see today’s die.
Talk Python Bits
Michael Kennedy from the podcasts Python Bytes and Talk Python has recently written a couple blog posts that I wanted to highlight here. First up is his post about rewriting the Talk Python site in Quart (aka async Flask). Three and a half years ago I wrote about realizing that it’s not about Django vs Flask vs FastAPI, but actually about finding the right framework for your workload. I didn’t completely state my current thought process in that blog post, but I was pretty close to the advice I currently give. If you want a Python-based site that needs CMS features and you don’t want to have to reinvent the world, Django is your framework. If you are making websites where you want to be in control of every puzzle piece, then you want flask. You only bring in what you need. And if you’re writing REST API based site (controversy about whether REST truly is REST aside), you want FastAPI. Well, I respect Michael Kennedy’s opinion on this matter for a few reasons:
Advent 2024 Day 01
December has finally arrived and with it my favorite activity of the month - Advent of Code! I also wanted to give myself a fun little present this year, so I bought the Dice Envy Advent Calendar. Every day I’ll get a fun new die (or dice!). Scroll below the AoC code to see today’s die.
Advent of Code
Let’s start off with Advent of Code. This year I haven’t done any of the Advent of Code problems ahead of December so I was a bit rusty. One is not often using the same algorithms or libraries for Advent of Code as one does for everyday programming. I started off with Python since that’s my most comfortable language. First you can head over to today’s page to see the prompt. If you’re not solving the problems yourself, you won’t be able to see the prompt for part 2, so in summary:
Wordpress to Hugo Migration Process
As there are many people who are currently looking for alternatives to Wordpress in light of a little…. instability… I decided I would document my migration process. I figure my case is one of the more extreme cases, as I ran a self-hosted Wordpress instance for the past 19 years (since Feb 2005) and have ~4000 posts that needed to be migrated. I also have lots of photos, videos, and other media. Finally, I have made heavy use of many Wordpress features.
Programming Jan-April 2024
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.
A few thoughts on Programming languages
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.