Misc

Today I spent some time learning about SQL common table expressions (aka “CTEs”). I already use subqueries, so they were easy to understand. The syntax is very simple: WITH my_cte AS ( SELECT col1, col2, col3 FROM table1 ) SELECT col1, col3 FROM my_cte WHERE ... Here’s a more complex example with two CTEs: WITH my_cte1 AS ( SELECT col1, col2, col3 FROM table1 ), my_cte2 AS ( SELECT col4, col5, col6 FROM table1 ) SELECT my_table.*, my_cte1.col1, my_cte2.col4 FROM my_table JOIN my_cte1 ON my_table.fkey_id1 = my_cte1.col1 JOIN my_cte2 ON my_table.fkey_id4 = my_cte1.col4 WHERE ... In general, I should prefer CTEs over subqueries because: ...

I’ve been using Sublime Text as my main text editor since August of 2014. I know it pretty well, but occassionally I still learn something new and useful. Today I learned about the Arithmetic command from a video by OdatNurd. Summary of what I learned Variables The following variables are supported: Variable What it does s The literal selected text i The selected text interpreted as a number (0, if interpretation fails) i The index of each selection (0-indexed) Converstions hex(x) // to hex int(x) // to decimal bin(x) // to binary format() is supported format(x, ',') // add comma separators to number, 1234 -> 1,234 format(x, '^80') // center selected text in 80-character column math package is supported math.ceil(x) math.floor(x) TIP: update numbers of an ordered list This is particularly useful; I do this all the time! ...

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. Now I plan to date them, as it suggests. Using the email sub-alias (+) is clever and I’m stealing that. ...

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.) Splitting and closing panes. (Whereas iTerm2’s keybindings to do this are burned into my brain forever.) For all iTerm2’s faults, I miss it sometimes. (The biggest reason I ditched it is because you can’t commit its config to version control easily. Its config is huuuuuuge. And I won’t daily drive anything whose config I can’t version.) ...

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. HTTP/1.1 Still a text-based protocol. Added connection re-use. On by default. Controlled via the Connection: keep-alive header and tuned via Keep-Alive. Added the Host header, which allows multiple websites to be hosted at a single IP address. Better cache control mechanisms. Added HTTP pipelining (allowing multiple requests to be sent in succession before responses were received). Apparently never got widespread support, though. Still suffers from Head of Line blocking. Even though TCP connections get re-used, a given request/response cycle must complete before the connection is eligible for re-use. Many browsers improved throughput by allowing up to 6 TCP connections per domain. Websites took this even further with domain sharding. Example: Sharding resources over www1.foo.bar, www2.foo.bar, www3.foo.bar gives you 18 connections to play with. No compression of headers. Lots of redundant data sent for each request/response in the headers, which is inefficient. HTTP/2 Based on pioneering work done by Google with their SPDY (pronounced: “speedy”) protocol in the 2010s. No longer a text-based protocol; now a binary-based protocol. Allows request multiplexing over a single TCP connection. Solved the application-layer Head of Line Blocking problem, but did not solve it for the transport layer (e.g., a dropped TCP packet would still delay all requests/responses behind it). Adds header compression. HTTP/3 Still a binary-based protocol. Moved from TCP to UDP+QUIC for the transport layer. Many improvements come from this. Faster connection setup Old: Setting up a TLS connection with older protocols required around three round trips (3-RTT): the TCP handshake (around 1-RTT) and TLS handshake (2-RTT). New: Setting up a TLS connection with QUIC requires a single round trip (1-RTT) because the transport connection setup and TLS handshakes are merged. Note that 0-RTT resumption is possible with QUIC as well. Avoids the transport-layer head of line blocking problem by using multiple streams. Head of line blocking now fixed at both HTTP and transport layer. Faster connection migration via Connection IDs. (Allows a client to switch networks seamlessly while browsing.) Closing It was interesting going down this rabbit hole on HTTP. ...

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). In this case, I typically create a database table for the pending operation with columns for each param plus a scheduled_at column. I then use a daily job to check for these items with scheduled_at <= today, and either delete them or mark them as complete once the job has finished. ...

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. They are: ...

I get the impression that a lot of people are overwhelmed by their personal email inbox nowadays and get so much email that they’ve more or less given up on it. I don’t have that problem and that’s by design, not by accident. This post explains the rules I use to keep my personal email useful and very manageable. Unsubscribe aggressively Any time you give your email address out nowadays, you will get put on a mailing list. ...

I’ve been doing a weekly planning session for the last five or so years. It is one of the most helpful things I do to organize my life, keep myself physically healthy, and moving forward. This process has become even more valuable to me since having a child, as I am now responsible for a lot more and time is more scarce. In this post, I’ll describe what I do, why it’s useful, and how I do it. ...