The eMudhra problem is quite bad. Any system that depends on TLS/SSL and makes network requests is potentially vulnerable. eMudhra was added in spring 2019, so most versions of until 2026-10-20 have problems.
Examples of things in need of attention:
any Linux machines with old cron jobs/services making network requests
old Docker images deployed somewhere
CI package caches
Python venvs with the certifi dependency or with the pip dependency (which vendors its own certificates)
For Python specifically, you’ll need to update pip and uv, since they vendor their own certs and those are exposed.
1# Update uv 2brew update && brew upgrade uv
3# or 4sudo pacman -Sy uv
5# or 6uv self update
7# Upgrade all Python installations which now ship a patched pip 8uv python upgrade
910# Updating pip11python -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"
1# Upgrade certifi and pip2uv pip install -U certifi pip
3# If a uv.lock is present, it needs an explicit version bump4uv lock --upgrade-package certifi
This script will find and print all Python venvs on your machine (under your user) and print the certifi version in that venv
Now, review runs continuously, more like spellcheck while you write. Most changes have been reviewed and fixed by Claude at least once before a human is asked to look. This catches most routine mistakes, and saves team attention for higher-level questions and scrutiny.
As we move through big shifts in software dev practices, it’s grounding to get historical context and realize that much of what we do is more recent than we thought. In the 90s/00s, it wasn’t that uncommon for small teams to just push to trunk directly (as long as the build/test times were fast):
Some teams will choose to commit/push straight to the trunk. Most likely it is because they are a small team with each team member knowing what the others are up to. Their build is probably fast and relatively exhaustive, and they may well seldom experience a build breakage. If the build does break (post integration into trunk/main) then they most likely ‘revert’ the commit straight away, possibly locking the trunk for a short period of time while that is performed. If the team is really small (say three or four), in which case the team might allow someone to fix the build quickly and commit that in order to get the build green again.
Steve Yegge’s experiments with running an MMO come to mind - it’s not only a question of whether human review can keep up, but can your CI/CD keep up? Github is certainly feeling the strain of having to run CI/CD on every change. If the pace of change keeps increasing, I can see CI/CD running in a git bisect-like mode, only in response to a suspected problem, rather than on every commit.
Surprisingly many things can go wrong with streaming a game from your computer to your TV. Most of these issues came up around this time last year when I played through Silksong, so I figured I’d write them up before I totally forget them (at this point I’m using Sunshine/Moonlight anyway).
I made a Rust port of MistQL, a query language for JSON-like data structures. I learned a lot about what goes into a program that runs a language: lexers, parsers, grammars, runtimes, and general language design. This was also my first serious project with Rust. I made a follow-up improvement that focused on memory management, which taught me a lot about Rust lifetimes, and, in particular, it taught me that JSON-like structures are very tough to represent in Rust. I’m not sure if I will get the motivation to write an in-depth post.
A large portion of my work at Delphi has involved producing R packages for epidemiological data processing and forecasting. This includes:
epidatr - a package for downloading and processing epidemiological data.
epiprocess - a package for processing epidemiological data.
epipredict - a package for building forecasting models on epidata.
I used these to build data pipelines (in Python and in R) that flowed into forecasting models. I worked with a research team to design and implement our forecasting models. We read through Forecasting: Principles and Practice and Advanced R recently, as a reading group.
I have also built web apps with Django and FastAPI to Epidata API - Swagger UI. I have peered into the depths of data engineering to serve a 2TB versioned dataset in Postgres (and scoped potential migration to a datalake using DuckDB). Might do some technical writeups on this soon.
I made an album of improvised acoustic guitar songs this February.
It’s here on Bandcamp.
I am quite proud of it.
Not so much of the guitar playing or the composition, but of the fact that I actually put something out.
I’ve been playing guitar for almost 20 years and finishing and publishing projects has been my biggest challenge1.
So here’s to overcoming long-held hurdles.
My two main projects were a cover of Sikth “Bland Street Bloom” in 2011 and a metal radio show called HEAVY from 2015-2016, which I co-hosted with my friend George Mossessian. ↩︎
I recently got to work on making fast Python code. I put together an IPython notebook highlighting some things I learned. Topics include NumPy, Cython, and Numba.
I’ve been working on the cryptopals challenges and avoiding stock libraries, to learn more about string encodings and the bytes type in Python 3.
So here, we’ll learn way more than we need to know about Unicode.
