Type to search.

    This is Matt Widmann's site for working notes and articles. I'm a programmer so I tend to write about software, but I also love nature, bicycles, and writing.

    1. Updates for June 2026

      Here's what I've been doing and thinking about this month.

      • I added back colored links to this website and added some light image processing to put their dimensions in the HTML so the layout is stable when they eventually load.

      • We were going to take a trip to San Diego over the Juneteenth weekend, but we all got sick and had to postpone it to this upcoming weekend.

      • For my bike commute, I started using the Brompton more, filming my rides with a chest-mounted GoPro, and taking a 15-minute-longer but less stressful route home.

      • I wrote an article about formatting Markdown and finding parser bugs.

      I still haven't finished reading any books, but I have plans to tackle a few classic novels in my vanishing free time. But there were a lot of articles I found interesting:

      • What it's like to have the machine that keeps you alive die while you're on vacation

        Every problem it has is an indignity and an insult to me. Anything it does that irritates me is a sin. Universal healthcare would make my life easier, for sure. But the irritation I feel whenever I have to deal with a pump problem will never go away until diabetes is cured.

        One of my good friends was diagnosed with diabetes as a child and I've seen her deal with obstacles stemming from the shitty medical technology she's stuck with. This article sums up the situation with a depressing and stressful anecdote.

      • Building from Zero After Addiction, Prison, and a Felony

        I'm not sure the door will be open for the kinds of entry-level programming jobs that helped here, but maybe they'll just shift in scope. Regardless, there were so many ways this could have (and did) gone wrong.

      • The Newest Instagram "Exploit" is the Goofiest I've Seen

        Once it looks like the request is coming from the correct region, they tell the Meta support AI that the account is hacked and ask it to send the verification codes to an arbitrary email address they control.

        What a terrible design that has real consequences for people who put so much of their lives into this platform.

      • Designing a better podcast editor

        So I built a set of layout tools that exactly correspond to that set of creative decisions. Using the pin-based layout system, the editor gets to pick which part of the music should play at the same time as which part of the preceding and following spoken word clips.

        I love seeing people approach software with new ideas, especially in areas with already-established orthodoxy. This looks like a great re-imagining of a spoken word editing workflow.

      • Designing a personal Pebble watchface

        Another example of personal software, but this time one that you experience all of the time since it's literally attached to your body. I feel like my current watch is "good enough" that I don't have an interest in the Pebble, but it's neat to see folks tinker with it.

      • When modern bike computers miss the mark

        I distinctly remember that Cat Eye’s UI started falling apart when they asked one particular computer to do way too much. Consider this a bit of foreshadowing.

        I've only used GPS-based bike computers but am kind of "stuck" on the Wahoo Roam v2. It has some annoying problems but has a great screen and generally good UI design. The new models with touch screens and more complex software seem like such a step back that I'm considering a Coros Dura.

      • NetNewsWire Status

        NetNewsWire has been a staple of my daily routine and it's great to see it getting the love it deserves for modern macOS.

      • On sabotaging projects by overthinking

        I’m pretty sure I still came out ahead compared to if I’d tried to write everything myself sans LLM or discussion with others, but I’m not certain. Perhaps there’s some kind of conservation law here: Any increases in programming speed will be offset by a corresponding increase in unnecessary features, rabbit holes, and diversions.

        This happens to me a lot, but usually only for my personal programming projects that have no deadlines or stakeholders aside from myself.

      • Plotting Ideas

        In order to expand your understanding of a problem space and generate new ideas, it’s useful to put what you already know on a plot. It can be one, two or three dimensional and you can experiment with different axis (continuous, discrete, binary).

        I do this subconsciously but haven't really had a name for it until now.

      • Bullet Journal

        Half of the solution to this is having a compact pen that's always on hand -- the Kaweco -- and simplifying the system to be agnostic of colour or pen type and instead be symbolic and annotation-driven is a complete solution.

        I've been using the Leuchtturm Bullet Journal Pocket for the past couple of months and it's a nice way to keep track of short- and medium-term goals and chores. I tried the Kaweco mentioned in this article but didn't like its weight or grip; the LAMY Safari or AL-star are hard to beat for me.

      • Level Boarding Soon, Fast, and Cheap

        The incrementalism recommended here is almost unheard of in US transportation planning but makes a ton of sense.

      I also updated a few notes:

      I continued organizing our garage this month in preparation for installing a "power rack" for barbell and body weight exercises. We bought a folding rack that bolts to the wall for our single car-sized garage. Installing that was tricky with one person, involving holding up 50-pound stringers while driving in lag bolts or balancing the hundred-pound rack frame to fit into brackets. We'll probably leave the rack unfolded most of the time, but it's nice to have the option to make it compact if I need more space in the garage for a project.

      I also branched out on my biking a bit more and used the Brompton for some errands again. It's a really comfortable bike to ride and the gearing is perfect on most of the routes near me. I bought new brakes and handlebar grips for it that I still need to install. I've started taking a slightly longer route home to avoid a busy but much more direct stroad. After a few close calls, I'm now wearing a GoPro Hero 9 on a chest mount and keeping my Cycliq Fly6 Pro charged and recording from my bike's seat post. It's a bit annoying to keep the GoPro's batteries topped off and the microSD card recently bit the dust, but it's nice to have in case something happens. And finally, I set up the Fairlight on my indoor trainer in case I want to get some fitness riding in. I'm going to try out the Zwift Cog to see how I like the platform.

      A couple of weeks ago, we all got pretty sick and had to postpone a trip to San Diego to see friends. Parenting becomes incredibly difficult for me when I get sick, but luckily my mom was coming out to do some childcare for us anyway. Hopefully that was the last bad one this year, but with my daughter starting preschool in August, I think it's just the beginning.

    2. Formatting Markdown to find parser bugs

      While writing articles and notes for this site, I've been frustrated by problems like broken links and unterminated styles only showing up after I preview them in a browser. I've also grown accustomed to the format-on-save systems of programming languages like Zig and Go.

      There are a lot of programs that already solve this problem, including Markdown linters, formatters, and LSP servers.11 Like rumdl, mado, and Marksman. These support a much broader array of Markdown features than I use and come with their opinions baked in, which you have to tune manually. Instead, I wanted something with zero configuration and tailored to the kind of Markdown I write.

      So, instead of generating HTML, I made the Markdown parser in lift, my site generator, produce Markdown in addition to the two other kinds of files it already produced22 HTML for site content and JSON for search indexing.. This is called source-to-source translation and how many (or most?) language formatters tend to work.

                ┌────────────────────┐
          │  site-in/**/*.md   │
          └──────────┬─────────┘
               ┌─────▼─────┐
               │   lift    │
               └─────┬─────┘
      ┌──────────────┼──────────────┐
┌─────▼────┐   ┌─────▼────┐   ┌─────▼─────┐
│   HTML   │   │   JSON   │   │ Markdown  │
└──────────┘   └──────────┘   └───────────┘

      As I developed this, I discovered a lot of parser bugs. Whenever the formatter unexpectedly introduced a change in files that I already expected to be formatted well, it indicated there was a bug somewhere. Once the bugs were fixed, I reformatted all Markdown files on my site and integrated it into my editors so it runs whenever I save Markdown files going forward.

      Parsing Markdown

      Markdown is annoying to parse because it's exceedingly permissive and the process is expected to be infallable. The specification came out of a series of ad-hoc regular expression match-and-replace rules, leading to some unintuitive edge cases. When I wrote the parser for my website, I intentionally limited the scope of what was acceptable to keep the code simple, especially since I don't have a strong background in text parsing.33 My shining moment in parser engineering was writing a series of LPeg parsers for various macOS performance tool outputs (heap, vmmap, zprint).

      Unfortunately, that meant I couldn't use John Gruber's tests or the CommonMark test cases to qualify my work. Instead, I wrote some unit tests and spot checked the HTML from my more complicated notes. By the end, I thought I nailed it and had a pretty fast and deterministic parser that could be well-integrated into my site generator. I knew there were test gaps, but I wasn't thrilled with Zig's built-in testing output44 It's sometimes useful to have a stack trace on failures, but most of the time I would rather just keep the output constrained to what's explicitly printed by the test (and the assertion of course). It'd be nice if this behavior was configurable, but I'm suspecting I need to write my own test runner (I tried using std_options but it didn't work for me). so I didn't want to spend much time on them.

      It was only when I started working on the formatter and linter that I noticed a whole crop of new issues, including a few that were actively impacting notes on my site.

      Parser bugs

      Here are a few of the bugs I fixed while working on the formatter:

      • Any _ or * inside of a link's display text would not close at the end of the line, continuing the style until HTML's implicit rules turned it off at the end of a paragraph.

      • Nested lists had all kinds of issues, especially with mixed ordered and unordered lists. These didn't notice they were actually nested and would leave one or the other missing closing or opening tags.

      • Blockquotes were handled completely incorrectly, never actually allowing them to be continued to multiple lines. Any subsequent blockquote line would just introduce a new blockquote with no ending tag. For instance, this Markdown:

            > First.
    > Second.

        Would turn into this HTML:

            <blockquote><p>First.</p>
    <blockquote><p>Second.</p>

      I also had to add a few affordances to the tokenizer and lexer to carry through more context from the source file. The main example of this is "loose" vs. "tight" lists: whether there's a blank line between list items or not. I wanted some lists to stay tight and dense because the text in them was so short, like the notes page. But usually, if there's a paragraph in a list item, I want there to be spacing around it to more clearly set it apart. I added a blank field to the list item tokens that indicated whether it was preceded by a blank line.

      Testing

      Originally, lift's unit tests used a custom "expect-lexed" helper that made sure an input Markdown produced a sequence of lexemes, either in the block or inline parsers. This worked pretty well for regression tests, but it wasn't the most convenient to iterate on. Despite Zig's lovely syntax for literals, the lexemes were still a lot of typing and line noise.

      With the formatter though, I could write a new kind of quasi-snapshot test that looks like this:

      test "formatMindown: spacing and indentation of nested paragraphs" {
    try expectIdempotentFormat(
        \\- Nested.
        \\
        \\    - Multiline.
        \\    Paragraph.
        \\
        \\    Original level.
        \\
        \\    More paragraph.
        \\
    );
}

      expectIdempotentFormat ensures that running the formatter on the input string introduces no changes to the text. This is way less test code than checking lexemes manually and kind of fun to write.

      In the future, I'll be adding an integration test to ensure there are no changes to any of the site's input files after running the formatter.

      Editor integration

      I'm currently using a few different editors, so I had to set each of them up separately.55 In practice, all settings but Nova's are generated by a single module in my Nix configuration that's enabled if I'm on my personal machine. I've translated them to their outputs here. The formatter runs as a subcommand of the lift program I use to generate the site and takes the file to read as its positional argument, or - to use stdin.

      • Helix: This was the easiest and just needed a new entry in the languages.toml file:

            name = "markdown"
    auto-format = true
    formatter = { command = "lift", args = [ "format", "-", "..." ] }

        It doesn't present errors when I have unused definitions, but it's good enough. I think I would need to write a Language Server Protocol server if I wanted that support.

      • Nova: I already maintain a plugin for publishing this site easily, so I extended that with a format-on-save option. First, I added an "issue matcher" regular expression in the extension.json:

            "issueMatchers": {
        "mattwidmann.lift": {
            "pattern": {
                "regexp": "^lift: error: [^:]+:(\\d+):(\\d+): (.*)\\s*$",
                "line": 1,
                "column": 2,
                "message": 3,
                "severity": "error"
            }
        }
    }

        That can be used to report errors from the lift format command:

            let parser = new IssueParser("mattwidmann.lift")
    let p = new Process(liftPath, {
      args: ["format", "-", "..."],
      cwd: nova.workspace.path,
    })
    let lines = []
    p.onStderr((line) => { parser.pushLine(line.trim()) })
    p.onStdout((line) => { lines.push(line) })
    p.onDidExit((code) => {
      if (code == 0) {
        const formattedContent = lines.join("")
        editor.edit((edit) => {
          if (formattedContent !== content) {
            edit.replace(textRange, formattedContent)
          }
        })
      }
      // Return the issues (e.g. to a Promise).
    })
    p.start()
    p.stdin.getWriter().ready.then(() => {
      writer.write(content);
      writer.close();
    });

        And parser.issues are appended to an IssueCollection to present them in the UI.

      • Sublime Text: Sublime Text's plugin ecosystem favors language- or tool-specific plugins as much as possible, which feels very fractured and overlapping. Luckily, there's a semi-abandoned-but-generic sublime-fmt plugin that can run any tool on save, similar to Helix's built-in formatting support. I configured it with a Fmt.sublime-settings:

            {
        "rules": [
            {
                "selector": "text.html.markdown",
                "cmd": ["lift", "format", "-", "..."],
                "format_on_save": true,
                "merge_type": "diff"
            }
        ]
    }

        To get errors from the formatter printed inline, I had to create a "build system" I called Lift.sublime-build:

            {
        "selector": "text.html.markdown",
        "cmd": ["lift", "format", "$file", "..."],
        "line_regex": "^lift: error: [^:]+:(\\d+):(\\d+): (.*)\\s*$"
    }

      Now, no matter where I end up tweaking the site's content, the Markdown will remain tidy.

    3. Updates for May 2026

      Here's what I've been working on, doing, and thinking about this month.

      • I implemented a Markdown formatter, incorporated it into my editors, and reformatted all of the input files for the site.

      • After my trip to London, I took a week off from work to start some house projects and spend time with family.

      • I wrote an article about updating my site to Zig 0.16 with some screenshots and added a "full screen zoom" feature for images on the site. The screenshots also have light and dark variants depending on the browser's color scheme.

      • I updated a text-based Instapaper client written in Go to Bubble Tea v2, which was a little confusing at first.

      I didn't read any books, despite the best intentions to dig into some non-fiction. My motivation to read books tends to wane going into summer for some reason. But I did keep up with articles:

      • Shipping a Laptop to a Refugee Camp in Uganda

        What had taken nearly two full days of travelling, waiting, stress, negotiation, and indirect requests for unofficial payments was finally completed in a matter of minutes.

        And that's just to even be able to pay the taxes on the shipment! One of the most upsetting and uplifting stories about technology I've ever read. That surprise and delight at the end is why I do what I do, but I wish it was vastly more accessible.

      • The Day I Logged 1 In Every 2000 Public IPv4: Visualizing The AI Scraper DDoS

        Every pixel that is red/orange/yellow is a /24 that contains at least a single IPv4 address that, in the span of 24 hours on 2026-04-24, hit my VPS [...]

        I'm a sucker for heat map visualizations and this is such a neat application of them.11 The portions grayed out because they're reserved or unused are a nice touch. It's a sad state for the web and there's no relief in sight for those of us who want to stay off the global CDNs.

      • 3 constraints before I build anything

        First research, plan, prototype, then write the one pager again. Iterate. If it requires more than one page, it's too complex, don't build it.

        I build a lot of things that aren't "products" per se, but I wish more engineers would actually spend the time to write down what it is they're trying to accomplish and why.

      • Intermezzo bag

        But my bags are all the wrong size, too small or so large that the book lays horizontally at the bottom, which annoys me. [...] So I made a bag just for this one book.

        I'd love to get more into sewing for bags and other non-clothing items, but all of the independent fabric stores around me are closing and nothing caters to the MYOG crowd.

      • Minimal Viable Zig Error Contexts

        [...] just log error context as key=value pairs, guarded by errdefer. The result is not pretty, but passable

        But it still logs whenever an error is handled, which is a problem for error.Canceled in Zig 0.16.

        When I picked up Zig coming from Swift and Rust, I was worried about missing dynamic context from returned errors. The technique outlined in this article addresses that concern during prototyping with minimal boilerplate. I started applying a bit of this to my website and unfortunately, it doesn't scale naturally to reporting through a diagnostics array because defer blocks cannot return errors (or use try).

      • Printing Zig Structs

        What’s nice about this is you don’t need to worry about the order of the fields because they’re extracted from the format string. If you squint it looks a little like basic string interpolation.

        This is a cute trick for printing, but having to use all of the fields is a bit annoying. Another shortcut that's available if you need it early on, though.

      • Just Fucking Use Go and the ensuing Lobste.rs discussion

        You're out there gluing together fifteen Node packages, three TypeScript build tools, and a Kubernetes cluster to serve a fucking form. You hired a Platform Team to babysit your Rails monolith. You convinced your CTO that Rust was necessary for a CRUD app that does maybe forty requests a second. Congratulations, asshole. You played yourself.

        I hate to say it (because Go is a very mid and frankly frustrating language), but I completely agree with this take. If you are working in a space that is well-covered by Go's built-in libraries or even well-known ones (like Bubble Tea for TUIs), they're generally so high-quality that it makes the limitations of the language less important.

      • A tour of txtar

        It stays this small because it was purpose-built around three goals listed in the package doc: stay hand-editable, store trees of text files for go command test cases, and diff cleanly in git history and code reviews.

        What a delightful and simple way to write tests.

      • You can beat the binary search

        [...] the quad approach has little effect on the Apple platform, but it is a decent optimization on the Intel platform for large arrays in the cold case.

        As someone who knows a thing or two about optimizing binary search, this feels a bit unfair because the baseline implementation is not branchless. It would be interesting to compare this to a more optimized version.

      • Downtown San Mateo Is a Monument to Insider Self-Dealing

        In 1862, with Polhemus running railroad construction, he commissioned a surveyor to plat the town of San Mateo at the exact point where the right-of-way crossed the creek. Conveniently, that point was the middle of his own holdings.

        Any nostalgia for the past evaporated when I realized that the "golden age" of rail travel in the USA was brought about by their equivalent of crypto grifters. I wish that Stanford's board had allowed their mascot to be changed to the robber barons. Max was on a roll this month, despite unsettling feelings of LLM writing.

      • We're Diversifying the University by Hiring More Crackpots

        Many ideas that enjoy enormous popularity among billionaires -- cryogenic immortality, disregard for punctuation, the Antichrist -- have scandalously been excluded from our labs and classrooms.

      • Rewarding Failure

        There exist no incentives at SFSU to hire good teachers. There are no incentives for teachers to improve the quality of teaching. There is no quality control at all to this end.

        You can have too much faculty and you can have too much administration, but most educational institutions emphasize the latter with ineffective management roles. The lack of broad systems thinking here is painful to read about.

      • Japan's invisible electric wall

        The result was rolling blackouts in Tokyo and surrounding areas, even though western Japan had spare capacity it could have sent over.

        I've heard of the out-of-phase regions in USA and Europe's convoluted set of electric railway standards, but nothing prepared me for Japan's tolerated disfunction.

      • Japan's Tourism Troubles Are Being Fuelled By Social Media Assholes

        In 2026 you couldn't move without hitting a Westerner filming themselves for some kind of content, their cameras raised above them while they narrated the event (whether there was actually an audience I'll never know), each one an oblivious centre of their own universe while the 1000 people around them were just trying to get past them so they could cross the road and get home.

      The week and change I took for the staycation was filled with miniature adventures: bike trailer forays into town, Happy Hollow merry-go-round rides by the dozen, a trek through the beleagured California Academy of Sciences, and other visits to pretty much every museum within a thirty minute drive. It was fun to pack the days with that instead of the seemingly-constant work from my business trip. I did fall off the journaling wagon, in a way, switching to a smaller A6-sized "bullet journal" for daily check-ins. The larger notebook got a few long entries when I had something to say, but filled up much slower this month than the previous ones.

      My bike storage situation has always been an afterthought, but I finally found the time to install an RS Slide and GearBlocks wall brackets to hang all four commonly-used bikes. I also cleared out more of the garage to make way for a weight lifting bench and rack I ordered. It was Bike to Work Day in the Bay Area this month and I took part in that ritual, too. To mark the occasion, the Rove got its Albatross handlebars back.

      I've returned to using the venerable Sublime Text for most text editing tasks. Helix still helps with in-terminal editing tasks and Nova is the dedicated CSS editor due to its browser preview. But I'm trying to stick with Sublime for everything else, including prose (replacing iA Writer). The last time I bounced off Sublime Text was when I wanted search-as-you-type across my entire project, which Helix does pretty well.

    4. Generating this site on Zig 0.16

      These are some rough notes on updating a small project for Zig 0.16. There are bound to be misunderstandings and general confusion, since I'm not taking a disciplined approach to learning the language or keeping up with its roadmap.

      The program that generates this site is written in Zig11 I rewrote the program from Rust because I prefer Zig's minimalism and it seemed like a fun challenge., a programming language that's still undergoing breaking changes with each new version. Before I was finished with the rewrite, version 0.15 caused Writergate. This changed how the language provided file descriptor-based reading and writing. The new interfaces require a buffer, explicit flushing to drain that buffer, and care to always pass a pointer to the writer structure for downstream clients, instead of copying it. That last point caused one of the more painful debugging sessions I've had with Zig22 Not helped because lldb was inexplicably non-functional on my machine at the time..

      feat: update to Zig 0.15
8 files changed, 213 insertions(+), 211 deletions(-)

      In April 2026, Zig updated to 0.16 and revamped its standard library's approach to handling I/O. Functions now create or observe side effects outside of the the currently-executing CPU's register file and memory33 Globals and stack memory are allowed implicitly, but the heap's side effects use a std.mem.Allocator to manipulate. by accepting a std.Io argument. This includes file or network I/O, entropy and random numbers, synchronization primitives, and even reading a monotonic clock. The effect of this new requirement on my site was significant44 The commit prefix I used here compared to 0.15 reflects the slog this was.:

      chore: update to Zig 0.16
10 files changed, 542 insertions(+), 518 deletions(-)

      Most of the changes just required plumbing std.Io to all the functions that needed them.

      Zig tooling

      It still took me a few hours to update the site by hand. The most frustrating part of the process is the language server not showing errors and the compiler only showing the next reachable error. I'm not sure why the language server couldn't detect obvious errors, like incorrect standard library interfaces.

      In practice, this means you need a persistent split window to run zig build --watch alongside an editor. Before language servers, I would use vim's quickfix support for this or maybe even Acme's right-click to go to a line. But in the last five years, I've gotten used to a language server showing diagnostics. In Helix, you can list them all with <space>d and move between them with [d and ]d. But there's no support for feeding the output of a compiler into this UI. So I stuck with the --watch approach.

      It would be lovely if each Zig release came with a source-to-source translation tool of some kind, like Hare often includes.

      Multithreading

      A reason for all of this pain is to provide a swappable runtime for Futures and async/await in the standard library. My site generator, despite being almost completely I/O bound, was single-threaded as it waited for Zig's concurrency story to be more fleshed out. But adding concurrency here was significantly more difficult than the previous iteration of the site written in Rust. In Rust, I think I just adopted Rayon's par_iter to process notes, slapped on a Mutex where the compiler told me there was shared mutable state, and then the change worked.

      Zig is much looser with temporal and data race safety, so I had to take more care. The closest thing I could find to "generate a bunch of work that should happen concurrently" was a std.Io.Group. I reworked a few of the algorithms to not rely on state that would need to be shared. For instance, indexing words needed to add them to a singular hash table during Markdown conversion. In the multithreaded code, each note gets its own hash table, which are merged together once all notes are processed. I decided to use a lock on the diagnostics list, since those should be much rarer.

      The std.Io.Group code I wrote looks like this:

      var group: std.Io.Group = .init;
for (0..self.notes.items.len) |i| {
    group.async(io, processAsync, .{
        io,
        allocator,
        self,
        &processing,
        i,
        notes_dir_in,
        notes_dir_out,
        index,
        diagnostics,
    });
}
try group.await(io);

      Where processAsync is just a wrapper around process that can only fail with error{Canceled} and hides any underlying errors with catch unreachable. Clearly not production-quality code, but I was too lazy to add an out-parameter for the actual errors.

      Despite that, these hacks did give an immediate speedup to the end-to-end latency (this is from the debug build):

      notes:  97 ( 400.239 KiB)   37.078 ms ( 73.1%)
 / md:  97 ( 400.239 KiB)   67.998 ms (183.4%)

      This is saying that overall notes processing took 37ms, but the total time spent working on Markdown files was 67ms, indicating a bit of parallelism. But my computer has 8 CPUs, not 2.

      std.Io.Group is probably the wrong primitive here. Looking at the trace in Instruments, the main thread can "eagerly" take on work to execute (running the passed-in function) if all of the other CPU's threads are still working on a function. Because the loop around notes is responsible for enqueuing new work items, this can starve those threads for milliseconds. I'm not sure why this behavior exists when group.await could just as well start pulling work items without interfering this way. And using group.concurrent instead of group.async just overcommits dozens of threads which each get their own tiny slice of CPU.

      What I need here is an async I/O implementation that takes a batch of operations to execute and does work-stealing. In Swift or C on macOS, I would reach for Dispatch.concurrentPerform, which is still not a great answer for asynchronous I/O. I'm not sure this is what std.Io.Batch is meant for, despite the name. I could simulate this with a pipeline that puts the Markdown conversion in between two std.Io.Queues for Markdown text and then HTML to write. At these small durations, I'm wary of the overheads eating into the useful work being done. Or maybe std.Io.Select is the right way to ensure the operations don't interfere with enqueuing work. The documentation around these isn't very clear to me from just reading the standard library reference.55 If anyone with more experience with Zig's concurrency primitives has a path I could take, I'd love to hear from you.

      In any case, I applied this approach to a few other places in the generator that seemed like they would benefit:

      • 3ms: Writing the backlinks on each note66 Backlinks are the notes that link to the current note and show up at the bottom of each note. in parallel made that go from ~5ms to ~2ms.

      • 0ms: Stemming77 Stemming is where full words are converted into a form that preserves their meaning but avoids unnecessary uniqueness. This includes removing the trailing "s" for plural nouns, among (many) other heuristics for English. for the index showed up as an expensive single-threaded task, but moving that into the word writer (during individual note processing) didn't help.

      • 5ms: 7ms of index writing went down to around 2ms when done in parallel.

      • 2ms: Converting pages (like the colophon) and copying static assets in parallel helped by a couple milliseconds.

      The site originally generated in ~45ms on my MacBook Air M2 and now finishes in just under 20ms. I should be able to get this to sub-10ms with the right concurrency design, but at this point there aren't any easy wins left.

      Despite my initial stumbles, I'm still really excited for the future of concurrency in Zig!

    5. Updates for April 2026

      Here's what I've been working on, doing, and thinking about this month.

      • I upgraded this site's generator for Zig 0.16 and made it multithreaded.

      • I went on a business trip to London for two weeks, staying in the central part of the city, close to the Tower Bridge. While I worked during the week, I still had four days on the weekend for sightseeing in the city and trips to Cambridge and Bletchley Park11 This is where the ciphers used by Axis powers in World War II were broken using early computers..

      • A notebook that lays flat was my first photo-rich article. Despite the low-quality photos, it's nice to share what my setup looks like.

      I did not read nearly as much as I did last month, but I did find time for one fun science-fiction book:

      Instead, I read some excellent articles:

      • Go Ahead and Use AI. It Will Only Help Me Dominate You.

        This was hilarious and a testament to writing in your own voice without the help of LLMs.

      • Your hex editor should color-code bytes

        I have some strong opinions about syntax highlighting and this is a neat application of it. I'd like a hex editor with structural grouping for known-formats, since I almost always use them on file data. But this looks really useful for hex editing arbitrary data.

      • A tail-call interpreter in (nightly) Rust

        I wish there was some way to apply this to the work I do in Swift, where I built a little arithmetic expression evaluator for the CPU Counters instrument. To be fair, I haven't actually looked at the generated code and I'm likely leaving a lot of performance on the table. Byte code VMs are a really effective solution to tricky problems and can be competitive with native code in some cases.

        Andy Wingo wrote the value of a performance oracle as a follow-up, showing that his WebAssembly runtime isn't as slow as Wasmtime. I'm still not convinced that there are not fundamental limits to performance, having re-read the WebAssembly Troubles series recently. And as much as I love the Uxn ecosystem, his take that a Uxn interpreter is a viable target to optimize for is a little odd. There are veritable loads of more commonplace workloads available in languages that can target WebAssembly.

      • Porting Mac OS X to the Nintendo Wii

        Seriously impressive. This might be the one of the last pieces of greenfield IOKit development to happen outside of Apple.

      • 256 Lines or Less: Test Case Minimization

        This is a nice demonstration that you don't need to be too fancy to get 80 to 90 percent of the benefit of an idea. The problem I've faced with property-based testing is finding useful invariants for a data structure or algorithm that can be easily checked. But I also didn't have access to convenient generation libraries.

      • Lua can be a really cool HTML templating engine

        I love a tactical Lua interpreter as much as the next person, but I'm not convinced that a DSL for HTML is a great application for it. Regardless, I appreciated how the code was presented and discussed. It's almost like a literate program, but positioned as a persuasive piece.

      Before my trip to London, we put on a little Easter egg hunt for my daughter in our backyard and, the next day, another one at my aunt's house. My aunt cleverly assigned each kid an egg color so they all got a set number of their own.

      While I was in London, I experienced a busy, built-up, very old, dense city and got around almost exclusively on their underground light rail and regional heavy rail systems. Getting from Heathrow airport to the middle of the city was fast and relatively convenient: the Elizabeth line was busy but not too bad. Being able to tap-to-pay everywhere took the stress away from finding a kiosk or getting some London-specific card.

      Now that I'm back home, I'm taking a week off work to spend time with my family and do some spring cleaning.

    6. A notebook that lays flat

      I'm a fan of computers. Taking notes on them brings a lot of benefits: easy backups, syncing across devices, search, and invisible revisions. But for thinking through problems and tracking my daily thoughts, I've recently moved away from using note taking apps11 Like iA Writer or Obsidian..

      Writing by hand helps me organize my ideas and avoid the tendency to get bogged down in revisions. Handwritten notes in meetings aren't susceptible to a computer's distractions. Using a pen, they're also immutable and capture how your thoughts evolve over time.22 To bring that to my computer notes, a script commits my notes to version control every 5 minutes. But it's not the same and way less legible. It's also fun for me to work on my handwriting and flip through pages of a well-used notebook. That's probably the biggest reason I've switched: I just like them more.

      I've gone through a lot of notebooks that don't work well for me:

      • Hardbound notebooks (e.g. Moleskine and Leuchtturm) are fine for the first dozen pages but soon stop laying flat and require "breaking" the binding to work the book in.

      • Spiral-bound notebooks (e.g. Marumans Mnemosyne) lay flat but their wires get bent and caught up in a crowded bag. Because there's play in the holes for the wires, pages on the inside can get bent on the edges when the cover is offset.

      • Disc notebook systems (e.g. Circa) have all the drawbacks of spiral bound except they're very durable. I used these in college and generally liked them because they were cheap to refill and I needed a full letter size page for taking notes with diagrams.

      • Notebooks with no spine (e.g. Field Notes) don't lay flat and can't fit much paper in them, but they're very portable.

      However, I finally found a style of notebooks I'm happy with. I bought a JetPens Kanso Noto at the end of last year and started using it as a journal. This is a lay-flat notebook with a mostly exposed spine: instead of a continuous cover, there's only some tape to hold the two cardstock covers together.

      A5 notebooks are the best size for me. There's enough room on the page for readable paragraphs at my typical handwriting size. It's also portable enough to throw in a small bag or front pocket of a backpack.

      I use a LAMY Safari fountain pen with a fine nib and De Atramentis Document ink in black. The Kanso's Tomoe River paper is pretty thin but handles it well. There's a little ghosting on the other side of pages, but it doesn't hurt legibility. Another color can be used for emphasis and makes it easy to spot edits. The cyan color of this ink bled through badly, which was a shame, but black and red are fine.

      It's not as durable as a hardbound notebook, so I eventually wrapped it in a BKxAP Canvas Cover33 I guess this would address my issues with spiral-bound notebooks, too.. The canvas is soft enough to still let the notebook lay flat. It helps keep the sides of the notebook a little more protected since its own cover is exactly the same size as the pages. With thick seams pushing underneath the thin pages, I had to add a clear writing board to make it easier to write on the first and last pages of the notebook.

      When I fill this up44 After 2 months I've used about a third of it., I'm excited to try two other options, in this order:

      • Pith Supply Yuzu55 Unfortunately this isn't readily available in the US.: Steven Schultz on YouTube claims this is the perfect lay-flat notebook and the colors look really nice.

      • Midori MD Notebook: It has these little perforated tabs in the corners to mark your location in the book without a fabric bookmark.

    7. Updates for March 2026

      Here's what I've been working on and thinking about this month.

      • I renamed the "now" series to just "updates," to catalogue what's happened each month.

      • Index pages (lists of articles) contain full article content inline instead of just the title and a link to the article page.

      • I added a human.json with a single entry for my old college friend.

      • The 2025 Priority Gemini bicycle's shift cable disconnected and I had to commute home in a pretty low gear.

      • I swapped out wallets in my Everyday carry.

      I read a few fiction books at the beginning of March after getting all the way through The Lord of the Rings for the first (and probably last) time:

      And read some articles but unlike books, I don't diligently track all of them:

      • Buc-ee's Is Better at Placemaking Than Your City by Max Mautner

        This piece was uncomfortable but in the best way. The urbanist movement needs more humility and meeting people where they are.

      • Good trains by Robin Sloan

        Not much to takeaway from this one but I love Robin's writing and enthusiasm.

      • GitButler CLI Is Really Good by Mat Duggan

        I'm all in on Jujutsu these days but only started looking around because I detested Git's default one-line graph log ASCII art11 Taste in command line tools matters a lot to me, I guess?. This looks so good that I probably wouldn't have made the switch if this was available at the time.

      • The Most Dangerous Line: Behind the Hawker stall test crashes by Admiral Cloudberg

        A haunting article mixed in with detailed descriptions of organizational, engineering, and human failings.

      We started the month recovering from a debilitating cold. When we were on the other side of it, we took our daughter to the beach22 Where she fell over whenever the waves lapped against her legs.. As the heat wave descended, I set up a water table and sand table for her to play with in the backyard.

      The garden had lost some plants over the winter, so we went to our local nursery and picked up a few flowers, shrubs, vegetables, and herbs to get things back on track. I'm pretty excited about the little vertical herb garden we're starting, currently with multiple varieties of thyme, sage, and chives.

      We capped off the month with a road trip up to Sacramento for a stay in Folsom and visit with family.

    8. Single letter commands

      If I use a shell command often, I'll condense into a short, single letter alias as a mnemonic. I've settled on a few key aliases:

      • l: ls, list the contents of a directory

      • e: whatever terminal editor I've latched onto

      • f: fg, bring the last backgrounded job to the foreground

      • j: the Jujutsu version control system

      • c: switch the current directory to a source repository via fzf

      These act like a command layer for the shell, similar to keyboard shorcuts for apps or the terse commands of vi. They're mapped as abbreviations, usually, which expand to their full command when invoked. When I communicate using my terminal scrollback history, any well-known commands involved are visible.

      I've also recently started naming my personal scripts with single letters:

      • h: start a new journal entry with the current date and hour populated

      • n: start an editor in my notes directory

      • d [<title>]: with an argument, create a new draft, or without, start an editor on the drafts directory

      To me, this feels faster and more precise than typing out a longer name.