In short: when a fetch request body is a string, the server will receive UTF-8 bytes.I was recently calling fetch with a string body, like this:await fetch("/foo", { method: "POST", body: "🍉",});I wondered: what exact bytes would the server receive? Most stuff uses UTF-8 nowadays, but JavaScript uses UTF-16 for its strings. So what would fetch send?Spec is inconclusive?Best I could tell, the Fetch specification doesn’t directly specify what should happen here. However, it links to another document that says the following:To get a byte sequence out of a string, using UTF-8 encode from Encoding is encouraged. In rare circumstances isomorphic encode might be needed.Sounds like UTF-8 is “encouraged”, but what actually happens in practice?A simple testI wrote a short Crystal web server that logged the bytes of an incoming request:require "http/server"def hex_dump(io : IO) : String io.getb_to_end.map(&.to_s(16).rjust(2, '0')).join(" ")endHTTP::Server.new do |context| body = context.request....

Things I published and things I saw this August.See also: my notes from last month, which has links to all the previous months so far.Things I published this monthMost of my work this month was on private stuff, like some contracting and a demo app for a small social group. But I published a few little things:Over on Zelda Dungeon, I wrote a big guide showing how to play every Zelda in 2025 and a deranged post about my favorite Ocarina of Time item.Got invited to speak at Longhorn PHP in October, giving a version of a Unicode talk I’ve given before. Spent some time prepping that.Speaking of Unicode, I added a new script, u+, to my dotfiles. Now I can run u+ 2025 to see ñ, LATIN SMALL LETTER N WITH TILDE. Thanks to Python’s unicodedata library for making it easy!I also wrote a quick script, csv2md, to convert CSV files to Markdown tables.Hopefully I’ll have more blog posts in September!Links and bookmarks and goodiesI started seeding some torrents of censored US government data. Cool pr

Here are some of my notes from July 2025. See also: my notes from last month, and the month before, and so on…What I published this July“How I build software quickly” was my marquee post this month. I haven’t mastered the tension between speed and quality, but I’ve learned a few things that have been useful. It sparked a lot of discussion on Lobsters and Hacker News. I worked on this post for months, and I’m glad it did well (for me, at least).I informally compared the download sizes of local LLMs with offline Wikipedia. Seems like Wikipedia offers more value per gigabyte. The Hacker News girlies were all over this one too, probably because it mentioned AI even a little.I wrote a simple macOS-only script to extract text from images. I can now run ocr image.png to grab text out of screenshots and photos, at least on macOS.I read Where Wizards Stay Up Late: The Origins of the Internet, a book about the invention of the internet, and took a few notes. I also took notes on The Weather Mach

In The Weather Machine: A Journey Inside the Forecast, author Andrew Blum gives a high-level overview of global weather forecasting. What complexity hides behind the simple interfaces of our daily weather apps?Three main points stuck out to me:“The weather machine has to be a global system, and it won’t work any other way.” International collaboration is critical. Weather models need lots of global data to be effective.Weather technology, like the internet, is closely tied to military interests. Some quotes:“In a very practical sense, there were few clear distinctions between weather satellites and reconnaissance satellites, or cargo-carrying rockets and intercontinental ballistic missiles. It worked both ways. The military uses justified the meteorological efforts. The military efforts benefited the meteorological uses.”The NASA Jet Propulsion Laboratory “was haunted by the space program’s fundamental duality: They would create the machines that would open up a new era in human explor

Last month, I read Empire of AI, a scathing tale of the invention of ChatGPT. This month, I read Where Wizards Stay Up Late: The Origins of the Internet, a much rosier story of the invention of a more important technology: the internet.Authors Katie Hafner and Matthew Lyon cover the history starting in the 1960s all the way up to 1994, just two years before the book was published.1 Here are my notes.Chapter 1: The Fastest Million DollarsThis book argues that the space race was a precursor to the invention of the Internet, because it led to the creation of ARPA.This early sentence introduced one of the book’s main themes:The relationship between the military and computer establishments began with the modern computer industry itself.This tech-and-military romance has not gone away in 2025.Chapter 2: A Block Here, Some Stones ThereThis is still a problem today, only partly solved by containers:In [the 1960s], software programs were one-of-a-kind, like original works of art, and not easily

Two days ago, MIT Technology review published “How to run an LLM on your laptop”. It opens with an anecdote about using offline LLMs in an apocalypse scenario. “‘It’s like having a weird, condensed, faulty version of Wikipedia, so I can help reboot society with the help of my little USB stick,’ [Simon Willison] says.”This made me wonder: how do the sizes of local LLMs compare to the size of offline Wikipedia downloads?I compared some models from the Ollama library to various downloads on Kiwix. I chose models that could be run on some consumer-grade hardware, and Wikipedia bundles that didn’t have images for a better comparison. Here’s what I found, ordered by size:Name Download size Best of Wikipedia (best 50K articles, no details) 356.9MB Simple English Wikipedia (no details) 417.5MB Qwen 3 0.6B 523MB Simple English Wikipedia 915.1MB Deepseek-R1 1.5B 1.1GB Llama 3.2 1B 1.3GB Qwen 3 1.7B 1.4GB Best of Wikipedia (best 50K articles) 1.93GB Llama 3.2 3B 2.0GB Qwen 3 4B 2.6GB Deepseek-R1

I wrote a script that lets me run ocr image.png to extract text from images. This is useful for pulling text from screenshots, photos, and more.It only works on macOS because it uses Apple’s proprietary text recognition API. (I’ve used Frog for OCR on Linux, which I believe uses Tesseract under the hood.)Let’s say I want to extract text from this picture:I run this command…ocr /path/to/photo.jpg…to get this output:The author's reflections on his situation- Isdeceived by a promise of being delivered - Hisdespair at sailing for the West Indies-Arrives atMontserrat, where he is sold to Mr. King-Variousinteresting instances of oppression, cruelty, andextortion, which the author saw practised uponthe slaves in the West Indies during his captivityfrom the year 1763 to 1766- Address on it to theplanters.As you can see, it isn’t perfect. For example, it messes up em dashes here. But this is usually good enough for me!Here’s the script’s source code, which uses Swift and Apple’s Vision framewor

Software is built under time and quality constraints. We want to write good code and have it done quickly.If you go too fast, your work is buggy and hard to maintain. If you go too slowly, nothing gets shipped. I have not mastered this tension, but I’ll share a few lessons I’ve learned.This post focuses on being a developer on a small team, maintaining software over multiple years. It doesn’t focus on creating quick prototypes. And this is only based on my own experience!“How good should this be?”Early in my career, I wanted all my code to be perfect: every function well-tested, every identifier elegantly named, every abstraction easily understood. And absolutely no bugs!But I learned a lesson that now seems obvious in hindsight: there isn’t one “right way” to build software.For example, if you’re making a game for a 24-hour game jam, you probably don’t want to prioritize clean code. That would be a waste of time! Who really cares if your code is elegant and bug-free?On the other hand,