Narthur Slop

Watch your containers with lazydocker

Tue, 10 Nov 2026 00:00:00 GMT

Written by AI from Nathan’s notes and reviewed by him before publishing. About Slop

lazydocker is a terminal UI for Docker and docker-compose. Run lazydocker and one screen shows every container and service, its state, its logs and its resource graphs.

It replaces a familiar debugging loop. A service misbehaves, so you run docker compose ps, then docker compose restart, then ps again to find it died on startup. The logs you wanted are buried in a stream mixed with every other service. Following one service’s logs ends whenever that service dies, so you rerun the command after each restart. lazydocker puts the list, the logs and the actions in one window, one keypress each.

From that window you can read logs per container or service, attach to a container, and restart, remove or rebuild it. You can also inspect an image’s layers and prune whatever is eating disk.

Install it with Homebrew:

brew install lazydocker

The README lists Docker 29.0.0 or newer as a requirement, so check docker version if it won’t start. Logs default to the last hour, so a quiet container can look empty. The README says to change that through commandTemplates in the config.

Next time a compose stack acts up, open lazydocker in a spare terminal pane before reaching for docker compose logs.

Check for a stray .pnpm-store before git add -A

Mon, 09 Nov 2026 00:00:00 GMT

Written by AI from Nathan’s notes and reviewed by him before publishing. About Slop

pnpm keeps every package in one global store. Each project’s node_modules hard-links to it. pnpm store path prints where that store lives. Normally it is under your home directory, outside any repo.

If the home directory isn’t writable, pnpm falls back to a store inside the project, at .pnpm-store/. A sandboxed shell can trigger this. The install still succeeds and nothing looks wrong. Then git add -A stages tens of thousands of package files, because the folder isn’t in .gitignore.

Two commands and one ignore line catch it:

pnpm store path   # should point outside the repo
git status --short | wc -l   # thousands of lines means something unignored got in
echo ".pnpm-store" >> .gitignore

Run the count before any commit that follows an install. If it is huge, git reset to unstage everything and look at what appeared.

Nathan hit this with an AI agent working in a sandboxed git worktree. The install fell back to a repo-local store. A later git add -A swept about 97,000 files into a commit, and the commit had to be rebuilt before it could be pushed. Running the install outside the sandbox fixed it at the source. The ignore line is the safety net for whoever forgets.

Add .pnpm-store to your .gitignore today, and glance at the file count in git status after every install.

Set a different language for each Mac app

Thu, 05 Nov 2026 00:00:00 GMT

Written by AI from Nathan’s notes and reviewed by him before publishing. About Slop

macOS can use a different language for individual apps. The setting is easy to miss: it lives in System Settings, under General, then Language & Region, in a section called Applications.

It helps anyone who switches between languages or regional spellings during the day. The usual case is British and US English. Spellcheck can’t flag a correct word that belongs to the other version of the language, and a per-app language is a partial fix for that.

It also helps someone learning a new language. Switching one everyday app to that language adds daily practice without changing the whole system.

To set it up:

Open System Settings, then General, then Language & Region.
Find the Applications section.
Add an app, then select a language for it.

Browsers are the useful target, because much writing happens in one. Two browsers can cover two spellings. With British English as the system language, Safari uses it, and Chrome can be set to US English. Writing in one browser or the other then picks the spelling.

One limit applies. Only apps that support macOS’s localization APIs can be set, so some apps never appear in the list.

Open that pane now and pick a language for the app used most for writing.

Point the Docker CLI at Podman

Wed, 04 Nov 2026 00:00:00 GMT

Written by AI from Nathan’s notes and reviewed by him before publishing. About Slop

Podman runs containers without a paid desktop app, and its VM exposes a Docker-compatible socket. That means the plain docker CLI can drive it, so existing scripts and Compose files keep working unchanged.

Install the pieces with Homebrew: brew install podman docker docker-compose. The docker formula is only the command-line client, with no daemon. Then create and start the VM once:

podman machine init
podman machine start

The one wiring step is telling the Docker CLI where the socket lives. Set DOCKER_HOST in your shell config. The obvious way to find the path is podman machine inspect, but that call is slow, and running it on every shell startup is noticeable. The socket path is stable, so write it out instead:

export DOCKER_HOST="unix://$(getconf DARWIN_USER_TEMP_DIR)podman/podman-machine-default-api.sock"

getconf DARWIN_USER_TEMP_DIR returns the real per-user temp directory even when $TMPDIR has been overridden, which happens inside sandboxed tools such as Claude Code. Using $TMPDIR there would point at the wrong place.

Check it with docker run hello-world. Nathan made this switch after a Colima VM went into a broken state and docker ps started failing with a permission error; the Podman machine ran hello-world on the first try.

Two caveats. When the VM is stopped, docker commands fail to connect until podman machine start runs. And images with no arm64 build need --platform linux/amd64.

If a container runtime is misbehaving, try the Podman install and the one-line DOCKER_HOST export before debugging further.

Let your coding agent take its own screenshots with Snapzy

Tue, 03 Nov 2026 00:00:00 GMT

Written by AI from Nathan’s notes and reviewed by him before publishing. About Slop

Snapzy is an open-source screenshot and screen recording app for macOS, inspired by CleanShot X. It lives in the menu bar and covers area, window and scrolling captures, annotation, OCR, GIF and video recording, and uploads to your own S3 or Cloudflare R2 bucket. It is BSD-licensed and collects no telemetry.

The snapzy command is the reason to install it. It lets a script or an AI coding agent take a screenshot with no clicks and get back a file path, JSON metadata and an exit code. That means an agent can screenshot the app it just changed and check the result itself.

To set it up:

Install it with Homebrew. It needs macOS 13 or later.
```
brew install --cask snapzy
```
Grant Screen Recording permission when macOS asks, then put the command on your PATH from Settings → Command Line → Install.

Try a capture:

snapzy list windows --app Safari
snapzy capture window --app Safari --max-dimension 1568 -o shot.png

The window capture works even when the window is covered. The first time an app runs snapzy, Snapzy asks whether to allow it, so a terminal or agent has to be approved once.

Install it, run the window capture once from your terminal, and tell your agent the command exists.

Check the numbers before picking a framework for your coding agent

Mon, 02 Nov 2026 00:00:00 GMT

Written by AI from Nathan’s notes and reviewed by him before publishing. About Slop

“Better for agents” has become a common reason to switch frontend frameworks, usually with no data behind it. The AI cost of JavaScript frameworks supplies some. It had Claude Opus 5.5 build the same small Pokémon app five times in each of 12 frameworks, checked every result against a conformance suite, then measured cost, time, tokens, Lighthouse scores and lines of code.

Hono with htmx, Astro and Nuxt were the cheapest to build, at under $3 a run. SvelteKit, Gracile with Lit, and Angular cost the most. With SvelteKit and Gracile, the agent spent tokens learning a framework version or a framework it didn’t know well. Lighthouse performance and accessibility came out near perfect for almost every framework, so the bigger differences were in JavaScript shipped: Astro sent close to none, Next.js about 142 KiB. Plain Vite with no framework did worse than several frameworks.

The results are noisy. The same framework could vary by more than a dollar between runs, and agents often ignored the official MCP servers and skill files installed for them.

To use it:

Look up your framework, or the one being pitched, in the cost and JavaScript-size tables.
If your app looks nothing like a small, content-heavy site, treat the numbers as a starting point and run the published benchmark against your own spec.
If you run it, run each framework several times. One run says little.

Before the next rewrite pitched as “better for agents,” ask for numbers like these.