The grill

I recently purchased an ASMOKE Essential ‘Smart’ pellet grill. Before purchasing it, I did what any average consumer does and watched several YouTube review videos. As it turns out, those were all astroturfed, paid content from ASMOKE.

My experience convinced me to write this post as counter-programming to ASMOKE’s prolific astroturfing. This post is what I wish I had found before purchasing the ASMOKE Essential very dumb, very bad, non-essential grill. My hope is that at least one person searching the internet for information on ASMOKE grills ends up here.

Fly.io Postgres failover fix (flyctl pg failover)

This is a note to myself, meant to be succinct and helpful. I’m sharing it publicly to save others time.

Most of the time Fly.io works as I expect it to, but occasionally there are edge cases that lack documentation, public announcements, or both.

It’s possible that at some point Fly.io announced a breaking change and I missed it, but the behavior I observed deserves more than an announcement or silently released documentation.

Hetzner raises prices

This morning I received an email from Hetzner stating that they are raising prices in the US while significantly reducing bandwidth.

The largest price percentage increase is 27.52% for CPX21 servers, and the smallest is 4.17% for CX3+ servers.

Bandwidth allotments are decreasing on average, across all products, 88.19% from previous allotments.

I’ve been a big fan of Hetzner. Unfortunately they’ve made a feeble attempt to dress this change up in the name of “fairness”.

ChatGPT is slipping

Three months ago I put code in production that utilizes gpt-4o and/or gpt-4o-mini models to analyze feedback about businesses and categorize it. The prompts instruct the models to identify categories of feedback, and in a second phase, extract some examples of what people said. This is a simplification, but it took very little effort to craft some prompts that enabled even the meager gpt-4o-mini model to do exactly that. It didn’t feel like a stretch to imagine that this use case was well within ChatGPT’s limits based on the minimal effort put into a working solution. The results were genuinely useful, and the effort was low. It seemed like an obvious win.

Problem synopsis

I’m a huge fan of sqlc’s approach to code generation. I’ve seen sqlc called a reverse ORM, and I really like that moniker.

However, as a sqlc newbie, I’m still discovering its edge cases. Today’s edge case is using postgres UPSERT queries with sqlc.

The crux is that when upserting, it’s necessary for unique key conflicts to occur so that the UPDATE portion of the query executes. But non-null uuid Go types tend to have a zero-value of 00000000-0000-0000-0000-000000000000. This results in new records inserting with the uuid Go type’s zero value, and every following new record upserts the existing zero ID record.

Mastodon

While I’m in no way a Mastodon power user, I’ve really been enjoying the content that I get from my very limited Mastodon feed. I recently stopped consuming news from – hold on let’s not call it news. I recently stopped consuming useless information from a site that I won’t name. Everyone has those junk, just-for-fun sites they visit to blow off stream. You don’t have to be proud of them, and it’s fine that you visit them; every part of every day need not be productive. Anyway, I recently stopped consuming a lot of useless information that I plan to replace with an equally fun, but probably less useless Mastodon feed.

Introduction

Postgres queue tech is a thing of beauty, but far from mainstream. Its relative obscurity is partially attributable to the cargo cult of “scale”. The scalability cult has decreed that there are several queue technologies with greater “scalability” than Postgres, and for that reason alone, Postgres isn’t suitably scalable for anyone’s queuing needs. The cult of scalability would rather we build applications that scale beyond our wildest dreams than applications that meet concrete customer and business needs. Postgres’ operational simplicity be damned; scale first, operate later.

TL;DR ess automates syncing .env with env.sample

It’s available here on Github.

The problem

If you have a look through any software or infrastructure project you’ve worked on in the past, it won’t take long before you come across some “secrets”. Secrets are how we generally refer to things like passwords, API keys, and certificates that act as “identity”. If you have the secret to an identity, you or your systems are assumed to have that identity. Identities are authorized to do stuff like fetch data, and access APIs. Secrets are important. Most moderately complex projects contain secrets.

Update :: live demo now available

A demo of this concept is now available at https://garbagespeak.com and the demo source code is available at https://github.com/acaloiaro/garbagespeak.com/.

Intro

I’ve encountered a lot of skepticism around the idea of adding dynamic behavior to Hugo sites with hugo-htmx-go-template. That skepticism is well founded, because Hugo bills itself as a static site generator.

So why would anyone want to add dynamic functionality to Hugo sites when Hugo aspires to be a simple static site generator?

Overview

I’m always looking for the easy way. Certbot already makes retrieving TLS certificates from Let’s Encrypt easy. But it’s getting those certificates “into production” that tends to be less easy. This is the easy way to get Let’s Encrypt TLS certificates into production with Hashicorp’s Nomad.

This is an overview of what we’ll be doing:

• Using Nomad’s docker driver to run docker container jobs.
• Using a cerbot docker image that performs a DNS-01 Challenge using Hetzner’s DNS API.
• Using Nomad host volumes to share certificates between nomad tasks.
• Using Nomad lifecycle block to initialize certificates before Nginx startup.
• Using Nginx as a reverse proxy/SSL termination

Here is what we won’t be doing: