I came across this post by Xuanwo about starting a link blog in the spirit of Simon Willison’s post here. This is pretty close to what I’m striving for here, and it spurred me to write up some snippets about how I’ve gotten started with Simon’s amazing tools: llm, datasette, and sqlite-utils (and a few helpers I’ll mention below).

Ok, everyone’s doing posts on the uv shebang trick so I have to, too. But no actually I really do want to cover this killer feature of uv because it finally gives us the python “scripts” that we were promised.

Mastering Multi-Label Classification in Python with Scikit-Learn

Welcome back! Today, we’re diving into multi-label classification.

Hello friends! Today’s post is going to be about window functions (specifically with Postgres).

Here’s the docs and tutorial. Give them a read. Like most Postgres docs, they’re quite good.

Back so soon? Today’s post is about a pretty neat Temporal feature. Imagine you have some business logic you want to run on a CRON-esque schedule. You might be tempted to just set up a script that gets called by a CRON job. Not so fast though, what if it’s some Very Important Task? You need retries, you need resiliancy, you need visibility, you need…a bunch of stuff. And you probably don’t have just one of these Very Important Tasks, you might have dozens or even hundreds that need to run at any given time. Fortunately, Temporal provides this sort of thing out of the box with Schedules. The Go SDK overview of the Schedule API is here.

TimescaleDB. Is. Dope.

Back in the bad ol’ days when I worked on transient astronomy, all my timeseries data fit in memory. I’d store it in a CSV and not give it a second thought. But if you want to build a web application that leverages timeseries data, that won’t fly. You might think “I can’t store my timeseries data in a relational database, I need to stand up a whole new database for my timeseries stuff and I need to learn a whole new tsdb system and blah blah blah…”

I was reading HackerNews a few months ago and came across this post. It demystified something I’d long wondered about but hadn’t investigated myself: PubSub with PostgreSQL. Most PubSub implementations I’ve seen rely on some sort of message broker like Redis. To be fair, the Redis PubSub interface is pretty easy to work with (I think I have a post or two showing just how easy), and if you were purely working in memory, it would be totally fine. However, most applications rely on some sort of SQL database. In that case, in order to “publish”, you have to write to the database and then notify listeners over your message broker. You end up having to maintain two systems and it’s kind of annoying.

Hot damn, I think I have the PERFECT workflow to building an application!!! Ok, probably not, BUT I have settled on what I think is a pretty straightforward process that lets you build things real fast. In the end, you be able to build:

Continuing on this hot streak of posts, I figured I’d write up something I’ve wanted to do a post on for quite a while. The idea here is to have a sort of “arterial channel” where we merge some arbitrary number of channels into one singular channel. There’s actually a couple “Just for Func” episodes on this topic that were extremely helpful: justforfunc #26: why are there nil channels in Go? and justforfunc #27: two ways of merging N channels.

Howdy folks. I was refactoring some of my Go code from another project this past weekend and I realized this would be a great opportunity for a post about working with WebSockets in Go, so here we are.