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.

Neat snippet for y’all today. I’m calling this snippet “channel smuggling”; I googled this and all that came up was weird stuff. Anyway, the idea here is that suppose you want to pass a piece of data into a channel and have something do some work on it. However, what if you want to block until after all the work on that data is completed? Here’s an example on Go Playground, and here it is replicated below:

Happy 2024!!! I decided I’d use this space to hold some of the bits of info I come across before/during/after our New Year’s trip to Portugal, as well as an overall cataloging of what we did.

Welp, I finally took the Kubernetes (K8s) dive. This post is basically going to be my “lab notes” from the experience, so don’t expect too much expository prose.