What programming/technical projects have you been working on?

I've been writing my own note-taking tool for the past few days.

There's a ton of existing options in that space, from Obsidian to org-mode, but I never managed to stick with one. So I thought "I'm a programmer, why don't I make one myself?".

So now I have a Rust tool called notelog (imaginative name, I know!), which I can simply call from the commandline and it'll either take the note directly from the commandline args, read STDIN if provided, or open $EDITOR to let me write a longer note.
The hardest part was getting all the error handling implemented -- there's so much that can go wrong even in such a simple program, and there's still a ton to do, though I'm now at a point where you'd have to actively try to break things for them to go south (like, by setting the $EDITOR env variable to rm -rf / or something).

Each note is written to a Markdown file and stored in an automatically-created folder hierarchy based on the current year and month. The files all have YAML frontmatter, so the entire thing is extensible.
As a proof of concept, the current version can store a list of tags for each note, but I plan on adding other things like "status: todo/done/delegated/canceled/etc" later on. Right now it also just stores the note; if I want to find it again, I have to use grep.

I ended up using Generative AI to auto-generate almost all 1500 lines of it (using the AugmentCode extension for VSCode), though the process required some handholding on my part -- the AI won't refactor code on its own, and it doesn't have good 'taste' yet on when to factor out or inline functionality, or refactor in general. Or maybe that's just a skill issue with my prompting technique.

Still, it's quite amazing that technology has progressed to the point where you can write a 50 line spec in English and get a 450 line Rust file out that does everything you outlined in the spec -- mere minutes after handoff. I had to tell it to break the generated code up into smaller modules, but I basically had the initial prototype working using that single (though thorough) prompt. The AI does a lot of legwork once it is running -- writing the code, writing tests, running tests, debugging errors, looking up documentation, cleaning up things the linter didn't like, even 'speaking' JSON-RPC to notelog in order to debug an issue with the MCP server I asked it to build for the tool.

The MCP server allows me to use NoteLog from inside my IDE or using any other MCP client. Whenever I feel like it, I can just '/log some note with tags +foo and +bar' or have the LLM do it for me ("summarize the points we just discussed into a notelog note").

Some people say that AGI is right around the corner, and I'm starting to believe they're right. You can just hand off tasks to the AI agent, do something else for 5 or 10 minutes, and expect it to have implemented the entire feature you've requested when you get back. (I do run the IDE in a virtual machine though, just in case it does decide to rm -rf everything). Heck, you can even ask it to come up with a draft spec for new functionality based on vague ideas, and then review the result, and eventually just tell it to "make it so".

It won't be too long until something like it can do a whole day's work with a single guiding prompt.

It's not all rainbows and sunshine though. I'm a bit ambivalent about how capable the darn thing is -- you just start to trust it, start glossing over the text it outputs (there's sooo much of it, though each task completed ends with a summary of what it has done), and I find myself getting less vigilant over time.

In two later instances, the agent silently did (minor) things that were against the prompt/spec I formulated. In retrospect, the spec was wrong on these points, but ideally it shouldn't have deviated from it. At one point it got into a doom loop of trying to read the source code of a dependency because of an inscrutable compiler error; that turned out to have been caused by it doing a web search and finding outdated documentation. It also likes to do LLM things ("I left that legacy function in there because it might be useful later on") once in a while.

Still, I'll probably continue to use GenAI for programming. Programming is fun, but after doing that for 20+ years, I'm starting to feel that getting results fast is even more fun than just coding. Using the agent is an enormous speed-up over doing everything myself, especially writing tests or debugging compiler errors -- but at least for now, I still abhor the idea of vibe coding and truly leaving everything up to the AI agent.

The final downside of the whole GenAI programming shtick I noticed, is that sometimes you become so preoccupied with whether you can write some program quickly, that you don't stop to think whether you should write that program at all...

(Edit: Removed a stray sentence that I forgot to cut out)

So I use fancontrol to (surprise!) control the fans in my computer (some of which happen to be zip-tied to my GPU at the moment... long story).

fancontrol is easy-ish to set up. You just run sudo pwmconfig in a terminal, and that guides you through the whole process. At the end, you get a lovely config file that looks like this:

INTERVAL=1
DEVPATH=hwmon2=devices/pci0000:00/0000:00:03.1/0000:27:00.0/0000:28:00.0/0000:29:00.0 hwmon3=devices/pci0000:00/0000:00:18.3 hwmon6=devices/platform/nct6775.2592
DEVNAME=hwmon2=amdgpu hwmon3=k10temp hwmon6=nct6795
FCTEMPS=hwmon6/pwm6=hwmon2/temp2_input hwmon6/pwm5=hwmon2/temp2_input hwmon6/pwm4=hwmon2/temp2_input hwmon6/pwm3=hwmon2/temp2_input
FCFANS=hwmon6/pwm6=hwmon6/fan6_input hwmon6/pwm5=hwmon6/fan5_input hwmon6/pwm4=hwmon6/fan4_input hwmon6/pwm3=hwmon6/fan3_input
MINTEMP=hwmon6/pwm6=60 hwmon6/pwm5=60 hwmon6/pwm4=60 hwmon6/pwm3=20
MAXTEMP=hwmon6/pwm6=80 hwmon6/pwm5=80 hwmon6/pwm4=80 hwmon6/pwm3=80
MINSTART=hwmon6/pwm6=50 hwmon6/pwm5=50 hwmon6/pwm4=50 hwmon6/pwm3=30
MINSTOP=hwmon6/pwm6=50 hwmon6/pwm5=50 hwmon6/pwm4=50 hwmon6/pwm3=30
MINPWM=hwmon6/pwm6=50 hwmon6/pwm5=50 hwmon6/pwm4=50 hwmon6/pwm3=30

I'll spare you from having to understand what every part of the config file is, and just say that the important parts are:

• DEVNAME declares the names of the devices that fancontrol is interacting with. So amdgpu is my graphics card, k10temp is my processor, and nct6795 is my motherboard. Notice that each device name is given a hwmon number. amdgpu is assigned to hwmon2 for example.
• DEVPATH declares the absolute paths of the devices mentioned above. So amdgpu can be found at the path /sys/devices/pci0000:00/0000:00:03.1/0000:27:00.0/0000:28:00.0/0000:29:00.0.
• Each device's hwmon number is actually a symlink to its absolute path. So if I run ls -al /sys/class/hwmon I will see that hwmon2 is a symlink to amdgpu's absolute path: ../../devices/pci0000:00/0000:00:03.1/0000:27:00.0/0000:28:00.0/0000:29:00.0/hwmon/hwmon2/

Cool, so when we run sudo pwmconfig, that command figures out what devices respond to a PWM signal. It then determines the name, absolute path, and hwmon number of each of those devices, and writes that information to the lovely fancontrol config file above.

fancontrol then uses that config file to figure out what temperature sensors, on what devices, it needs to monitor, and where to find the files that report those temperatures. It also knows what fans to bind to what temperature sensors, what speeds to run those fans at, and where to find the files that determine fan inputs.

(Oh right, if you didn't know, basically all of your hardware on Linux writes and reads data from text files. So if I want to know how hot my GPU's hotspot is, I can run cat /sys/class/hwmon/hwmon2/temp2_input in a terminal and it will print out the temperature. Similarly, I can control my GPU's fan speed by writing a value into a file, such as with the command echo 1000 > /sys/class/hwmon/hwmon2/fan1_input. Remember: "everything is a file".)

Unfortunately, fancontrol has one glaring issue:

The hwmon numbers change all the time.

So when I set up fancontrol for the first time, amdgpu is assigned to hwmon2. When I reboot my computer though, it might be assigned to hwmon3.

fancontrol itself has no way of dealing with this, so it just dies at boot. The "solution" is to re-run sudo pwmconfig and go through the entire setup again. Or, I can manually edit fancontrol's config file to replace every incorrect instance of hwmonX with hwmonY.

Both of those solutions suck, so I wrote my own. Behold this beauty:

#!/usr/bin/env bash
set -eo pipefail

# This script backtracks the hwmon# assignments for the devices in my computer detected by
# pwmconfig, controlled by fancontrol, etc

# Sync to /etc/fancontrol with ,set_fancontrol_config function

# The order of device names and paths in their respective arrays matters
device_names=("amdgpu"
              "k10temp"
              "nct6795")

device_paths=("devices/pci0000:00/0000:00:03.1/0000:27:00.0/0000:28:00.0/0000:29:00.0"
              "devices/pci0000:00/0000:00:18.3"
              "devices/platform/nct6775.2592")

hwmon_numbers=()

# Loop through absolute device paths and determine their hwmon number
for path in "${device_paths[@]}"; do
    # Check if /sys/device_path/hwmon exists
    if [ ! -d /sys/$path/hwmon ]; then
        echo "/sys/$path/hwmon does not exist"
        exit 1
    else
        # Count the number of directories in each path's hwmon directory (should be 1)
        count=$(find /sys/"$path"/hwmon/ -maxdepth 1 -type d | wc -l)
        # But find also returns the directory it is called on, inflating the result by +1
        # So check if the result equals 2
        if [ "$count" -eq 2 ]; then
            hwmon_number=$(ls /sys/$path/hwmon)
            # Append path's hwmon number to hwmon_numbers array
            hwmon_numbers=("${hwmon_numbers[@]}" "$hwmon_number")
        else
            echo "/sys/$path/hwmon/ contains $count directories, unsure what to do"
            exit 1
        fi
    fi
done

# Write new fancontrol config file
cat > $HOME/.config/fancontrol/fancontrol <<EOL
INTERVAL=1
DEVPATH=${hwmon_numbers[0]}=${device_paths[0]} ${hwmon_numbers[1]}=${device_paths[1]} ${hwmon_numbers[2]}=${device_paths[2]}
DEVNAME=${hwmon_numbers[0]}=${device_names[0]} ${hwmon_numbers[1]}=${device_names[1]} ${hwmon_numbers[2]}=${device_names[2]}
FCTEMPS=${hwmon_numbers[2]}/pwm6=${hwmon_numbers[0]}/temp2_input ${hwmon_numbers[2]}/pwm5=${hwmon_numbers[0]}/temp2_input ${hwmon_numbers[2]}/pwm4=${hwmon_numbers[0]}/temp2_input ${hwmon_numbers[2]}/pwm3=${hwmon_numbers[0]}/temp2_input
FCFANS=${hwmon_numbers[2]}/pwm6=${hwmon_numbers[2]}/fan6_input ${hwmon_numbers[2]}/pwm5=${hwmon_numbers[2]}/fan5_input ${hwmon_numbers[2]}/pwm4=${hwmon_numbers[2]}/fan4_input ${hwmon_numbers[2]}/pwm3=${hwmon_numbers[2]}/fan3_input
MINTEMP=${hwmon_numbers[2]}/pwm6=60 ${hwmon_numbers[2]}/pwm5=60 ${hwmon_numbers[2]}/pwm4=60 ${hwmon_numbers[2]}/pwm3=20
MAXTEMP=${hwmon_numbers[2]}/pwm6=80 ${hwmon_numbers[2]}/pwm5=80 ${hwmon_numbers[2]}/pwm4=80 ${hwmon_numbers[2]}/pwm3=80
MINSTART=${hwmon_numbers[2]}/pwm6=50 ${hwmon_numbers[2]}/pwm5=50 ${hwmon_numbers[2]}/pwm4=50 ${hwmon_numbers[2]}/pwm3=30
MINSTOP=${hwmon_numbers[2]}/pwm6=50 ${hwmon_numbers[2]}/pwm5=50 ${hwmon_numbers[2]}/pwm4=50 ${hwmon_numbers[2]}/pwm3=30
MINPWM=${hwmon_numbers[2]}/pwm6=50 ${hwmon_numbers[2]}/pwm5=50 ${hwmon_numbers[2]}/pwm4=50 ${hwmon_numbers[2]}/pwm3=30
EOL

In this script, I declare the names and absolute paths of the devices I want fancontrol to control. The script then automatically determines their hwmon numbers and writes a new fancontrol config file to $HOME/.config/fancontrol/fancontrol.

Of course, fancontrol's config file actually lives in /etc/fancontrol, so I have to symlink it from my home directory to the correct path before restarting fancontrol's systemd service. All of that is handled with the ,set_fan_control_config function in my .zshrc:

# Function to sync fancontrol config
,set_fan_control_config () {
    # TODO: Automatically call the script from a systemd unit file?

    # Symlink the script to a directory in PATH
    ln -fs $HOME/.config/fancontrol/build_fancontrol_config.sh $HOME/.local/executables/build_fancontrol_config.sh
    # Calling this after the symlink should work even if the script was not previously in the
    # user's PATH
    build_fancontrol_config.sh
    sudo ln -fs $HOME/.config/fancontrol/fancontrol /etc/fancontrol
    sudo systemctl stop fancontrol.service
    sudo systemctl enable --now fancontrol.service
    sleep 0.5s
    sudo systemctl status fancontrol.service
}

I still haven't automated this. So if I boot my computer and the hwmon numbers are wrecked, I still have to run ,set_fan_control_config manually. I'm pretty sure I could automate calling that function by writing my own systemd unit file, checking if fancontrol failed on boot, run unit file if it did, etc. I've never done that before though, and this is cursed good enough for now.

It's probably more accurately a learning thing than a real project, but I've been getting deep into the weeds of mesh shaders and voxel rendering. Mesh shaders are pretty cool and the hardware seems to support them fine, but not all parts of the toolchain do. For Vulkan they're also pretty light on the documentation front and so take quite a bit of piecing together. Maybe the most "fun" gap I've found is that reading per-primitive data (something that seems super cool) is impossible in Slang (the shader language I'm using) and not really supported by HLSL either (possible, but exceptionally hacky). In my opinion this is because the spec for them took the wrong approach. Every other case has the input strides of data automatically bound to the outputs at those locations in the prior step, but this case wants the strides baked in unlike anything else (ex. vertex shaders don't have a distinction between per-vertex and per-instance data because that gets bound during pipeline creation). This also makes it harder to reuse fragment shaders than it should be.

I've also ended up way deeper down the rabbit hole of investigating various approaches to voxel rendering than is sane, especially with the fact it's not like I have anything that actually needs optimizing. I've also rewritten that part a bunch of times now, including doing and then abandoning greedy meshing entirely because I didn't like how inelegant the solutions to t-junctions were.

I am quite liking mesh shaders though. I've not used task shaders yet, but that's next up. If anyone has experience with these things, mesh and task specifically, I'd be interested in learning more from someone with a clue. Stumbling through very fragmented and incomplete documentation is not exactly the ideal approach, especially because some of the bits of reference code that I've found aren't even spec compliant (and as a result don't work on my hardware).

So a year ago I posted a comment to a similar thread, indicating that I had started working on a custom App for Bonnaroo using React Native and what I could learn on Chatgpt.

Well, I was able to create a working version. And it worked extremely well. So this year I decided to go nearly all-in in continuing development on it, including adding features I thought of last year but didn't have time to implement, and overhauling the repository on GitHub, getting acquainted with releases and working with Apple's App Store Connect and their TestFlight system.

The result? Archlight, an app for streamlining your Bonnaroo experience. The 2025 version is extremely close to being finished, with only needing tweaks to the app and notification icons ahead of Bonnaroo releasing updated map and vendor information.

Next year I'm brainstorming UX decisions around involving other festivals besides Bonnaroo, and including smartwatch support as well. It's crazy to see how this passion project has evolved compared to some of the first development screenshots I have from the first month of creating it

Just a mini thing from me. I'm attending (just as visitor, not speaker) my first Maker Faire in Prague this weekend.

Since I'm going on train, I wanted to take my Steam Deck with me and play on the way.

But I also wanted to showcase my 3D printing/modelling skills so I'm taking my LTT Tech Sack with over-the-shoulder strap I made for it. The Tech Sack is my daily wear for a bunch of things - LTT stubby screwdriver, bunch of USB cables, powerbank, ID card, credit card, money, earbuds... You get the idea.

So I went and made a strap adapter to clip my Steam Deck to my already existing 40mm wide strap for the LTT Tech Sack. This adapter can clip the Steam Deck to anything up to 40mm wide and around 3-3.5mm thick.

A few years ago I wrote a python script to select the secret santas that my family does. I've been making it a little better each year, but it's always been something I run locally. I've been starting the process of creating a web app around it as a bit of a learning exercise for me and a way for people to update wishlists for their secret santa to get ideas.

I'm not a developer and end up having to research and figure things out every step of the way. I'm using FastAPI with SQLite for a small database. I can get it to run locally in dev mode so it has auto-reloading. I can build a docker container that runs the app with SQLite as a Volume, but then it doesn't have auto-reload for while I'm making code changes.

I'm looking for some guidance on how to setup my local development environment while still having the right pieces in place to eventually deploy to a Digital Ocean droplet. I've looked in to VSCode dev containers, docker compose with watch, docker compose with -f for merging files, scripts and environment variables. None of them quite seem the right fit for what I think I want. Anyone have any suggestions or how to rethink my approach to this? Thanks.