Hello!

Today I needed to create a new SSH public/private keypair for work. I wanted to make sure I was following modern best practices for this, so I did some reading online. I found these two articles to be very helpful: SSH Key Best Practices for 2025 – Using ed25519, key rotation, and other best practices SSH Agent Explained Things I learned I didn’t ever think to change the comment at the end of the keyfile....

Today I encountered an API which sometimes sends back numbers as strings. Example response: { "age": "30" } That’s annoying, because I wanted my struct in Go to be like this: type Person struct { Age int `json:"age"` } I learned that json struct tags have a string option meant for dealing with exactly this sort of problem: The “string” option signals that a field is stored as JSON inside a JSON-encoded string....

Rebasing your feature branch on main regularly is a good idea. I used to do it like this: # update local copy of main git fetch origin main:main # rebase on local main git rebase main This always felt a litle off because I was worried I’d typo main:main and mess it up. This works just as well and feels much better to me: # update local copy of `origin/main` git fetch # rebase on origin/main git rebase origin/main

Here’s how to add key/value pairs to an http.Reqest’s query string in Go: package main import ( "fmt" "net/http" ) func main() { // create a request req, _ := http.NewRequest(http.MethodGet, "http://www.example.com/", nil) // get the current query string from the http.Request values := req.URL.Query() // add or set values values.Set("myKey1", "myVal1") // overwrite! values.Add("myKey1", "myVal2") // append! // add values back to the request req.URL.RawQuery = values.Encode() // query string: mykey1=myVal1&myKey1=myVal2 // print the url fmt....

Path Note /usr/local/bin/ System-wide binaries go here! ~/bin/ My user’s binaries go here!

I’ve been using Alacritty exclusively for over a year. It’s fantastic! But I listened to an interview with Mitchell Hashimoto and he talked about trying to make terminal multiplexers obsolete. It struck a cord with me. I’ve been using Zellij ever since I switched from Iterm2 to Alacritty and it’s great, but also it can be cumbersome. I find it cumbersome to: Search through this history (I don’t do it frequently enough for the keybindings to stick in my head....

This interview with Simon Willison is great. It pushed1 me into using GitHub Issues for my private repositories. They’re wonderful. (In the past, I’ve been just tracking everything in Markdown documents. That worked, but was just OK.) As an example, I have a private GitHub repo with notes and documents for a private network I maintain (as a volunteer). It’s very ad-hoc and I sometimes go months between without working on it....

There have been four1 major versions of HTTP in-use in the last 30-ish years: Version RFC Year HTTP/1.0 RFC 1945 1996 HTTP/1.1 RFC 2068 1997 HTTP/2 RFC 7540 2015 HTTP/3 RFC 9114 2022 It’s surprising to me how quickly HTTP/1.1 was released after HTTP/1.0. Less than one year! HTTP/1.0 A simple, text-based protocol. Runs over TCP. Only officially supports a single HTTP request and response over each TCP connection, then the connection was torn down....

This blog post by Sean Goedecke was a great read on high-level system design patterns. Most of them were familiar to me, but I got several good ideas from it. Using a database as queue: Sometimes you want to roll your own queue system. For instance, if you want to enqueue a job to run in a month, you probably shouldn’t put an item on the Redis queue. Redis persistence is typically not guaranteed over that period of time (and even if it is, you likely want to be able to query for those far-future enqueued jobs in a way that would be tricky with the Redis job queue)....

Much productivity advice on the internet is too complicated and not actually that helpful. Complicated systems are less likely to be used due to the friction of using them and are more brittle in the face of changing needs. You are better off use basic, flexible systems; you are more likely to use simple systems and simple systems can adapt to change more easily. There are only a few tools you need to completely run your personal life....