Posts tagged "software" - nolan caudill's internet house

Putting Macbook into DFU mode

Thu, 26 Mar 2026 22:28:39 -0700

During the most recent upgrade, my MacBook seemed to freeze on the update so I restarted. Big mistake.

After it came back up, I got the scary exclamation mark and text that linked to an Apple support page. The page gave me two options: ‘revive’ my Mac, or restore it.

Reviving it meant connecting a USB-C cord between the dead laptop and a working one and then hitting a magic combination of keys on the dead one with the right timing to get it to boot into DFU mode so the firmware could be restored.

I tried and tired but could not get it working correctly.

Googling, I came across a YouTube video that mentioned https://github.com/AsahiLinux/macvdmtool.

I downloaded the software and ran make.

Then, with sudo, I ran the serial subcommand and then the dfu subcommand and instantly the other laptop went into DFU mode. At that point, the ‘reviving’ continued as it should and I shortly had a working a laptop again. Thank you, open source author!

Using Things for GTD

Thu, 05 Mar 2026 08:45:07 -0800

I’ve been using Things as my to-do app and GTD (aka the Getting Things Done productivity system) for over 10 years. It’s helped me stay organized through multiple years of startups, house moves, vacations, two kids, complicated financial situations, and other life complexities, and I wanted to write about how I use them together.

Inbox

First, the Inbox. The purpose of the Inbox is simply to get something out of my head and onto my computer. Whenever I think of something that I want or need to do, I type the fewest necessary words to get an item in the Inbox. These words are short and leave just enough info that I can look at it a few hours later and still be able to know what it means.

I have configured Things to have the badge number represent the number of tasks in Today and in the Inbox. I want to burn this number down to zero by the end of the day, which means nothing dangling in the Inbox and no tasks I’ve picked left incomplete.

I try and go through the Inbox a few times per day. I follow the guideline that if a task takes less than 2 minutes, just do it, and for everything else, prioritize it.

Most things that comes into the inbox will be a ‘someday’ task, which conveniently shares the same meaning across Things and in GTD.

If something is important, and I need to do it today and I can’t get to it immediately, I’ll give the task a more descriptive name, and move it to Today.

In summary, quick notes come in, and then throughout the day, process the list: either do it quickly if I can, or prioritize it.

Projects

In GTD, every task that has more than one step is a project. For me, that is too detailed most of the time. I’ve adopted a different angle: every project should have a next step that immediately gets me back into the flow of the project.

I don’t bother creating a full project in Things for a “someday” task. That’s wasted effort as planning something I may never do, or at least for a while, is not a great use of time.

I do have some recurring projects like planning birthdays or holidays, or completing taxes. I give them a deadline of when they should complete. Then, to keep the projects out of the sidebar until it’s time to think about them, I set an appropriate ‘When’. This maps to GTD’s “tickler file” concept.

With this setup, I typically only have 2-5 projects visible in the left sidebar which keeps noise and clutter down. I can also click into ‘Anytime’ and that view only shows me the next action for my active projects. So, if my Today is clear and I’m looking for something to do, I can click in there and see what I can get done.

Today

The Today view only holds the things that I must do today, or have committed to doing today.

Every night, or over my morning coffee, I’ll skim through my active projects and pick out a small handful of things to do today from my ‘Anytime’ list. If that Anytime list is empty, I’ll browse through the ‘Someday’ list and see if there are any projects I want to start on.

It’s easy to be ambitious and say I’m going to do more than is reasonable in a day, but I really try to keep this list short. If things roll over to the next day, I’ve found I trust my list less to tell me what is important. And, there is some benefit in looking at what I didn’t get done and figuring out why that is.

I really try not to shame or guilt myself into doing tasks by putting them in the Today view. I tend to punt on those things and they roll over to the next day (and the next day, and the next day…), which changes the list from being practical to aspirational.

Weekly review

This is the part that’s easy to skip, but I believe is the key to the whole system.

In GTD, the weekly review helps me get my plans in good shape. I have time set aside on my calendar every Friday afternoon, where I do the following:

Empty the Things Inbox list
Use the ‘deadlines’ view in Things to see if anything that is coming up soon
Go through all projects and make sure each has a clear next step
Look through the Someday list and see if there is anything important I want to schedule soon
Look through my calendar and see if there is anything I should prepare for
Then, a full braindump where I think of anything that’s been floating in my head

At the end of this, I have a solid grasp of what’s happening, what’s coming up, and get anything nagging me out of my head.

Things is a very natural fit for the GTD system, and I haven’t found there’s any places in the GTD system that I’ve had to hack or hammer into the software. As always, picking what’s important to do is the hard part, but Things + GTD makes it easy to make progress on those things, with little falling through the cracks.

My current agentic coding approach

Sun, 22 Feb 2026 16:41:52 -0800

I’ve been full swing on using agents (primarily Codex with a mix of Claude) the past few weeks working on a few personal software projects, and I’ve started to get into a rhythm of an approach that is working for me, and results in relatively steady progress without many false starts, wild expansive scope, or complete do-overs.

Work small

I like to keep the feedback loops relatively small, which means asking for small iterations and then checking often.

The guideline I’ve found that keeps the process moving along is to only ask it to build something that I could reasonably test in a few minutes.

“Test” in this case is more like an acceptance test — did the software do the thing I hoped it would do? I’ve actually found the automated tests that the agents have been generating and automatically running after every change to be fairly complete so this has been the “Is this what I wanted? Does this feel right?” phase.

When I first started using these tools, I’d ask for fairly large, open-ended changes and then give incredibly specific instructions for one aspect of it. This never worked. I’d get something that was akin to what I asked for but usually with lots of things I didn’t want, and few things that I did. I’d also have no idea how it fit together, tradeoffs it made, or even how to test it fully.

Another benefit of working small is that I’m spending most of my time verifying and tweaking which is way less frustrating than trying to rephrase and describe a full worldview to the model so that it might guess better next time.

Use plan mode liberally

All the major players have some version of plan mode, where the agents are explicitly forbidden from writing code and instead come up with an output that is a readable doc.

My first couple of attempts at these would be to write a full requirements doc, similar to the ones a product manager would write. But, I found that I could be much more concise and get just-as-good levels of plans.

For any feature of some complexity or ambiguity, or where I wasn’t quite sure I what I wanted, I’d do this:

Enter plan mode
Write a quick, one sentence version of what I wanted
Add in some extra context of the motivation if I thought it was useful
If I knew of some edge cases or error conditions that I knew were important, I would add them here
If it was similar to another feature, I’d mention that to give it a head-start of what “good” would look like
Then, at the end, I literally say, “Ask me lots of questions.”

And it would! It’d go off and read through code and docs, and quickly come back with some implementation questions, scope questions (“do you want the kit-and-kaboodle, or the quick-and-easy?”), and if at any point I wasn’t sure, I’d stop and go back and forth on a minor point until I was able to figure out and describe what should happen.

Plan mode is a really nice mix of being high-level and then being presented with some tradeoffs where it matters.

Side benefit: Sometimes a feature is one where I’m not sure what I wanted, but I would know it when I saw it. Just being quizzed by the agent on tradeoffs sometimes has resulted in me seeing the kernel of the feature better, while also realizing that it was way more complexity than I wanted to add and I’d scrap the whole feature.

Fast, automated tests

My current software project is a CLI tool, written in go. My original prompt included mentioning it needed to be robust and that tests should be maintained and ran before returning success. The magic is watching it make changes, run the tests, see breakage, figure out what needs to change, and then changing the code to get to green again.

For the current project, I had used agents to write 100% of the code. Not a single line or character change was manual. I had a minor text change I wanted to make so I manually updated the text and sure enough broke the tests. It turned out that the minor text, in my eyes, was covered in tests coverage 3 different ways, which gave me a lot of confidence in the rest of the tests.

One thread at a time

This one is probably controversial and may be as much of a reflection of my relative newbieness to this way of working but I really like the one thread at a time approach.

I know people spend time on writing orchestration systems so they can spin up multiple changes at one time but for me, the bottleneck is what can I reason through and verify. Having multiple things in flight means reasoning about how they interact, and that turns play into work.

The architecture matters

Easy to read that “architecture matters” as a no-duh, of-course-it-does statement, but I think it is more interesting than a quick read suggests.

Many of the reasons that people favor certain tools or patterns are things that are, in some way, less relevant now. “This tool doesn’t have good documentation” doesn’t matter when agents can just vacuum the whole code into context. And any missing shim or API or wrapper can be quick work for a well-prompted LLM.

But, there is a compounding benefit in choosing certain tools or patterns. For my current project, I picked go + bash as the weapons of choice. Go is fast to compile and has a good testing story and that makes for fast feedback loops. There is also a tremendous amount of go and bash code in the world and LLMs are pretty dang good at producing idiomatic go code.

And, having seen lots of systems over the years, and knowing why some are “good” and others “less good” given certain constraints, absolutely helps when making tradeoffs or figuring out which paths to go down and which to avoid. This is probably the “taste” that people say doesn’t scale. (I am not sure what I believe here yet.)

Wrapping up, my biggest suggestion is to resist the urge to go big. Work in mind-sized chunks, use your taste and judgement each step of the way, and you’ll find the momentum builds from there. I have no doubt my approach will be wildly different as people figure out what these systems are capable of, and their limitations, but right now, this rhythm is working for me and I’m having fun.

Writing a Simulator

Tue, 17 Feb 2026 13:46:32 -0800

To give myself a slightly-bigger project, I came up with the idea of writing an simulator game where you’re the CTO of a small startup with a goal of helping your company get to an IPO.

I just started it around dinnertime last night, writing up a few paragraphs with how things like projects, budgets, hiring, incidents, and so on work. I let Claude and Codex rip on a planning (“here’s some words. now ask me questions.”) and implementation loop. After every loop, I’d play around with it, think of a thing that’d make it better, and repeat.

This post isn’t about writing software with agents (though I am amazed and am learning a lot about what they are good at and not so capable of) but a more general thing I’m learning when you’re writing a simulator.

Writing this simulator is as much encoding how I think the job of engineering manager works than anything else. If someone said, “How would you do the mechanics of the job?,” this would be an interactive answer to that question which is neat in a meta way.

When thinking through the elements of the game and how they work and interact, I started to use (my many) years of seeing these things up close to model how I think they should behave.

The first part of writing the simulator was mostly coming up with the nouns, the physical objects: projects, engineers, budgets, incidents and then, what sort of attributes they’d have. Projects have a timeline, whether or not they are started or not, which team they are assigned to and other things that seemed relevant to the flow of the game.

But, thinking harder, I started to think of things that “real” projects have. They have a distribution curve of when they’ll actually finish. The individuals that start on a project might not be the same set throughout. And, when you assign a project to an already busy team, each of project takes a little longer (though you as the CTO/manager might not know that until too late).

I realized that writing a simulator about something you know well, you quickly see where the simulator isn’t correct and you add that in. And, before long, I realized I haven’t written a generic “you’re the CTO” game but instead an interactive way to explore how I specifically see the job. I believe someone else given this prompt would pick different things to emphasize, objects interacting differently, and likely even different success criteria.

(Also, I don’t think the game is “fun” yet but I’m not sure a simulation of a fairly bureaucratic job would be fun? If it does up being fun, or at least interesting in my eyes, I’ll likely open source it but I’m not there yet.)

The other part of this exercise that is interesting is that the game does have some emergent properties. For example, new engineers have some amount of ramp before they are fully productive. New engineers on a project might take longer or make more mistakes (which is natural!). Newer engineers add some risk to projects and missed projects hurt the CTO’s standing and lowers the morale of the team. Each of these consequences follow naturally based on some simple rules, but when interacting together, every game is slightly different and somewhat surprising.

Blink: A more secure OpenClaw

Fri, 13 Feb 2026 09:56:59 -0800

I have been intrigued by OpenClaw – a system that uses LLM agents to act locally on your behalf, doing things like sorting email, filling out webforms, cleaning up files, etc – but the security seemed like a complete afterthought. I was happy for folks using that, but it was something I would not run for myself.

This, though, looks interesting and well thought-out. I’m still not at the point where I’d set this up but this is moving things in the right direction.

Why I Ditched OpenClaw and Built a More Secure AI Agent on Blink + Mac Mini:

The community responded with workarounds: layering on firewalls, VPN tunnels, and reverse proxies. These were patches on a system that wasn’t built with security at its core. OpenClaw was designed as a single-user local tool that organically grew into something much bigger. Security was bolted on after the fact instead of baked in from the start.

I wanted everything OpenClaw offered: a personal AI agent on my own hardware, connected to my real tools, available around the clock. But I also wanted a system where the secure setup is the default, without requiring constant hardening and maintenance.

Fun with LLMs

Thu, 12 Feb 2026 21:41:26 -0800

I had a lot of fun playing Claude and OpenRouter today, trying out new techniques, prompts and different models. I realize I’m about 6 months to 2 years behind a lot of people but this is truly the most fun I’ve had writing software in a long long time.

Just today I’ve:

Diagnosed a bug with how I was added SSL to the miniflux installation
Completely revamped my vimrc
Completely revamped my zshrc
“Wrote” a basic test harness and test suite for this blog (in bash, naturally)
Played with 3-4 different models
And most fun of all, I sat with our 9 year old this afternoon (who is home because of the strike) and wrote a complete browser-based store simulator, where you are a shopkeeper and have to do pricing and inventory management

And now I’m spending the evening reading about how best to use these tools beyond barking commands at them.

Hosting an RSS reader

Wed, 11 Feb 2026 21:29:14 -0800

In the year 2026, I decided I wanted to self-host an RSS reader. After setup, I am running miniflux in Docker on a Synology NAS configured to expose a Google Reader API so I can use NetNewsWire as the client on iOS and macOS. Here’s how I got that working.

Motivation

My news reading method was incredibly haphazard. I flitted betweeen big news sites, apps like Apple News, various subreddits and blogs. I forgot which sites I visited. I lost track of interesting articles I came across. I was disorganized.

Also, like every tech-savvy person of a particular age, I really missed Google Reader. I had dozens of RSS feeds I read daily and I missed that. I’ve tried various RSS readers over the years and none of them stuck.

But, on its 23rd birthday, I downloaded NetNewsWire and instantly loved the macOS-familiar UI.

But, when exploring what RSS syncing service to use, none of the options fit what I wanted. I wouldn’t have enough feeds to justify using one of the paid services, and the iCloud option, while being the right price (read: free), is slow. So, I dug into self-hosting, which NetNewsWire supports as long as the service exposes a Google Reader-compatible API.

The option that floated to the top was miniflux. Miniflux is, in its own words, “a minimalist and opinionated feed reader.” Perfect. It does have a very usable web UI but I planned to use it primarily via the NetNewsWire apps.

I uncovered a couple of gotchas so wanted to write them here in case anyone else wants to glue these pieces together and host their own RSS reader.

Install miniflux

First, I created a new directory on the NAS itself.

mkdir -p /[your volume here]/docker/miniflux

Inside that directory, I created 1 file and 2 more directories.

The 2 directories were: data/postgres and var/lib/postgresql/data.

The docker-compose file, titled docker-compose.yml follows. Note: there are placeholder passwords and URLs in there which may be worth changing.

version: '3.8'

services:
  miniflux-db:
    image: postgres:15-alpine
    container_name: miniflux-db
    environment:
      - POSTGRES_USER=miniflux
      - POSTGRES_PASSWORD=changeme_strong_password
      - POSTGRES_DB=miniflux
    volumes:
      - ./data/postgres:/var/lib/postgresql/data
    restart: unless-stopped

  miniflux:
    image: miniflux/miniflux:latest
    container_name: miniflux
    ports:
      - "8080:8080"
    depends_on:
      - miniflux-db
    environment:
      - DATABASE_URL=postgres://miniflux:changeme_strong_password@miniflux-db/miniflux?sslmode=disable
      - RUN_MIGRATIONS=1
      - CREATE_ADMIN=1
      - ADMIN_USERNAME=admin
      - ADMIN_PASSWORD=changeme_admin_password
      - BASE_URL=http://your-nas-ip:8080
    restart: unless-stopped

Now that you have the docker-compose file and the required directories created, run: sudo docker-compose up -d to build the containers and start them.

When this is complete, you should have a running miniflux reader listening on port 8080. You will now need to login to configure the service.

Configure miniflux

Once logged in, you will need to configure miniflux to turn on its Google Reader API, which is not on by default. Under Settings -> Integrations, you will see ‘Google Reader’. Under this section, you will need to create a new username and password (I just used the same one as the service login). Hit update and you’re done.

Configure NetNewsWire

In NetNewsWire, you will want to add a new account. In the settings, under accounts, you will see ‘self-hosting’ with FreshRSS. (NetNewsWire should probably just call this option “Google Reader API-compatible service” or something, because that’s what it is.)

Select FreshRSS and then enter in the Google Reader integration username/password you just created and enter in the URL that miniflux gave you. It should just be the base URL of the miniflux service with no trailing slash.

If all went well, you should be in business.

Some new install gotchas

I am not sure why but I needed to go to the ‘Feeds’ section in miniflux and hit ‘refresh all feeds in the background’ to get them to start polling automatically. I think this was related to the OPML import. I bet that adding a feed automatically queues up the first polling job, but an OPML import doesn’t. This fixes whatever problem that is.

Also, I was moving my OPML from an existing RSS reader to this one. I wasn’t able to do it from the NetNewsWire interface but importing via the miniflux import feature worked fine.

Conclusion

After following the steps above, I now have a hosted RSS reader running on my NAS and some slick native clients that stay in sync. Success.

MeteoPace

Wed, 11 Feb 2026 13:38:45 -0800

I came across MeteoPace (via) which is something I’ve wanted for a while.

When you are running, wind, heat, humidity, and elevation all can affect your ability to hold a pace. This is especially critical when you’re racing, as a few seconds difference in pace can be the difference in finishing or not. There are various rules-of-thumb and calculators people use, but those can be unwieldy and error-prone. This app looks to make this much easier.

I’ve synced my Strava runs to this, and spot-checking some recent hilly runs seemed to match the effort I was putting in. This is going to be very useful for that summer running.