just what i find

Is the window open?

Sat, 10 Oct 2026 08:02:46 +0000

I’m sure we’ve all been there - coat on, shoes on, just about to lock the door and - “did i leave the back window open?”

I wanted something which shows me, at a glance, which windows are open, or confirms they’re all closed.

goals

low maintenance - dont need to charge it every week
automatically updates in a few seconds
our windows can be “closed” or “latched closed” (with a ventilation space around), so support both
easy to glance at - no complex dashboards
small and unobtrusive.

What i used

Home Assistant Yellow
SNZB-04P/PR1 sensors
2.6" Hanshow Polaris Pro 280 Electronic Shelf Label
LilyGo T-Panel S3
OpenEPaperLink HA integration

Window sensors

I wanted sensors with long battery life. I have a Home Assistant Yellow at home, which has Zigbee support. I already have several Zigbee plugs around the house. Most permanently powered Zigbee devices act as “routers” so there’s a strong network around the house. I decided to buy Sonoff SNZB-04P:

CR2477 batteries
5+ years (claimed) battery life - although this is in a lab. but even half of this is fine for me.
small
cheap I ordered a bunch from aliexpress. I have a mix of SNZB-04P and SNZB-04PR1. The PR1 unit has a slightly slimmer body and a screw fix, vs a clip on the original. The magnet appears identical, and both look identical to Zigbee with the same firmware, model name and “ZHA quirk” (zhaquirks.sonoff.snzb04p:(eWeLink / SNZB-04P)).

there’s also a SNZB-04PR2 version, but this isnt as good:

2xAAA batteries
3 year claimed battery life
there were reports of it occasionally missing the first state change after a long idle period which is not ideal

Mounting the magnets

Fitting the sensors to the window is easy - just stick it on - but the magnet must be within 20mm of the sensor to trigger, so when the window is “latched” open it’s just out of reach. I designed a little 3d-printed mount to let me adjust the distance so that the magnet still sits in the sweet spot of the sensor even when the window is in the latched locked position. You can download it from Makerworld - it’s parametric so it can be adjusted for whatever length you need. The magnet neatly clips in the top and it accepts 3M VHB tape in a little recess in the bottom.

Electronic Shelf Labels?

I was wandering around the supermarket and noticed that they had these little e-paper labels. These things are amazing - they’re cheap, hackable, and because e-paper consumes no battery between refreshes and the radios are asleep most of the time, they have really good battery life - with 2 updates per day, some are rated for up to 15 years! so even with a few updates a day, battery life should still be pretty good. The most common open source protocol and firmware for them is OpenEPaperLink. Flashing the devices can be a bit fiddly - for some you need to cut a hole in the casing in exactly the right location - and getting the correct hardware revision can also be hit and miss, so rather than faf around, I bought some preflashed screens from J on eBay. They were UPSd to me in London in a couple of days.

OpenEPaperLink Access Point

The next component you need is an Access Point. The labels scan for a compatible OpenEPaperLink Access Point (AP) then associate with the first one they find. The OpenEPAperLink site has a bunch of recommendations, and you can hack one together with an ESP32-S3 and an ESP32-H2 and some spaghetti wiring, but i wanted something a bit more robust and ready to go, so i bought a Lilygo T-Panel S3 (make sure you dont get the “lite” version, this isnt compatible). This has both the ESP32s preconnected in a case with a screen and is fully supported by the OpenEPaperLink team. Once it arrived, i flashed it using the installer - pay attention to the rotation of the RESET and BOOT buttons.

Firmware update bug

After installing, i wanted to update the firmware to the latest version using the built in firmware updater, but hit a defect in the firmware update process - it looks for an ESP32-C6, not H2. I logged the issue with the maintainers - workaround:

Download the contents of the H2 binaries folder from github
rename firmware_H2.json to firmware_C6_Uart0.json
In OpenEPaperLink go to Settings → Update → ESP32-H2 from file system → file system
Upload all the files in to the root of the file system
Return to Settings → Update and click Flash beside ESP32-H2 from file system

Waking and connecting the screens

This part’s pretty easy. The screens are put in to deep sleep for transport. To wake them just bring an NFC reader near. I found that just holding the top of my iphone near them did the trick. Once connected, they’ll start ‘searching’ for an access point, and eventually they’ll find one and connect.

Generating the screen

I created a small automation which generates the image using the open_epaper_link.drawcustom action. You set the window entity IDs and display names in the windows variable at the bottom and set them as triggers at the top:

alias: E-paper - Window status portrait
triggers:
 - trigger: state
 entity_id:
 - binary_sensor.back_bedroom_windows
 - binary_sensor.front_bedroom_windows
 - binary_sensor.study_windows
 - binary_sensor.kitchen_window
 - binary_sensor.living_room_windows
 from: null
actions:
 - variables:
 open_count: |-
 {% set ns = namespace(n=0) %}
 {% for w in windows %}
 {% if is_state(w.entity_id, 'on') %}
 {% set ns.n = ns.n + 1 %}
 {% endif %}
 {% endfor %}
 {{ ns.n }}
 open_names: |-
 {% set ns = namespace(x=[]) %}
 {% for w in windows %}
 {% if is_state(w.entity_id, 'on') %}
 {% set ns.x = ns.x + [w.name] %}
 {% endif %}
 {% endfor %}
 {{ ns.x | join('\n') }}
 - action: open_epaper_link.drawcustom
 target:
 device_id: 596cd58872a5f26b58ad655d0d043e53
 data:
 rotate: 270
 background: white
 payload:
 - type: text
 value: WINDOWS
 x: 76
 'y': 15
 size: 22
 color: black
 anchor: mt
 - type: line
 x_start: 12
 x_end: 140
 y_start: 42
 y_end: 42
 width: 2
 fill: black
 - type: text
 value: |-
 {% if open_count | int == 0 %}
 ALL CLOSED
 {% else %}
 {{ open_count }} OPEN
 {% endif %}
 x: 76
 'y': 60
 size: 24
 color: '{{ "black" if open_count | int == 0 else "red" }}'
 anchor: mt
 - type: text
 value: '{{ open_names }}'
 x: 18
 'y': 112
 size: 18
 color: black
 - type: line
 x_start: 12
 x_end: 140
 y_start: 256
 y_end: 256
 width: 1
 fill: black
 - type: text
 value: Updated {{ now().strftime('%H:%M') }}
 x: 76
 'y': 274
 size: 14
 color: black
 anchor: mm
variables:
 windows:
 - entity_id: binary_sensor.back_bedroom_windows
 name: Back bed
 - entity_id: binary_sensor.front_bedroom_windows
 name: Front bed
 - entity_id: binary_sensor.study_windows
 name: Study
 - entity_id: binary_sensor.kitchen_window
 name: Kitchen
 - entity_id: binary_sensor.living_room_windows
 name: Living room
mode: restart

What’s next?

I have a small display by the front door that tells me whether the windows are open or closed. Because it’s e-paper paired with long life sensors, hopefully i’m not going to be walking around changing batteries every week. It’d be good to see:

which sensors are offline?
are the doors locked?
are the kids home (are the airtags from their keys somewhere in the house?)

TRMNL on a Kindle

Wed, 30 Sep 2026 14:12:38 +0100

I’ve written before about TRMNL - it’s a great project. During a recent cleanout, i found an old Kindle Voyage in the back of a drawer. As well as supporting their own devices, TRMNL offers a “BYOD” licence and, if you manage to get it up and running on a device that nobody else has published before, they even give you back some of the licence fee!

goals

Put a TRMNL in the hall to show the Tube, bus and train status in the morning before we talk out of the door
reuse the Kindle to make a low-power TRMNL device
implement some sort of OTA updates, so i dont have to move it around to update it

jailbreaking the kindle

This was much easier than i thought it would be. The KindleModding site has an easy walk through - basically, you:

plug the kindle in to the laptop and fill it with dummy data so that automatic updates dont get downloaded.
find the serial number, enter it in to the wizard which will help you pick the correct jailbreak
follow the instructions it was really easy. Took a little while, and i wasnt really sure it had finished until a new “Jailbroken” book appeared on the Kindle home screen.

Attempt 1 - KOReader + TRMNL-KOReader

KOReader is a multi-platform ebook application based around “plugins”, and TRMNL provides the TRMNL-KOReader plugin for it. TRMNL recommends this approach as they say it’s “easier”. I installed KOReader, and installed and it worked. But, there were a couple of annoyances - if you accidentally tap on the screen, TRMNL closes (which isnt great in a hallway or wherever), so I raised a PR to allow users to chose the exit mode (single tap, long press). I also raised a PR to enable taps to fetch or advance the current dashboard.

But then i started to hit some more complex problems around wifi resilience and battery life. I spent a little time seeing if i could fix it, but it’s impossible to properly update the wifi lifecycle without changing KOReader and i didnt want that (it’s much more complex than i am comfortable working on). So after pushing my PRs, i abandoned this and moved to KUAL.

Attempt 2 (which worked) - KUAL + TRMNL-Kindle

KUAL (Kindle Unified Application Launcher) is a launcher and menu system for running 3rd party/custom applications and scripts on Kindles. To prove it out, i installed TRMNL-Kindle, and this was pretty slick. I noticed that wifi recovery was a bit flakey - if it failed, it would end up permanently disabled - so i submitted a PR (which has since been merged) to handle this gracefully.

Support remote updates

There’s no over the air update mechanism for KUAL or TRMNL-Kindle. TRMNL-Kindle uses the hardware wake timer to suspend the device between refreshes - this is very energy efficient, but it means that the Kindle is unresponsive, so you can’t just tap the screen to quit TRMNL, and power cycling takes around 5 minutes. So i submitted another PR to detect when the device has been woken significantly before the expected hardware wake time. If it has, it presents a “tap to quit” button for 10 seconds (in case it was woken for another reason), and if the user taps (or presses a hardware button on a non-touch Kindle), it quits TRMNL and cleans up its timers etc.

With this done, i installed Kindle USBNetwork which provides a Dropbear SSH server. After hardening to only accept public key authentication, i can now perform updates over the network without having to plug the Kindle in to my laptop.

Conclusion

Well, i achieved my goals. I jailbroke Kindle Voyage, installed KUAL, TRMNL-Kindle, Kindle USBNetwork with Dropbear, and locked it down with SSH Key authentication. I gave back to the community with a few PRs closing the gaps i found. KOReader wasnt particually bad or broken - it just didnt do what i wanted. TRMNL-Kindle is working just fine.

Responsible disclosure: TRMNL MCP server leaks password fields to AI agents

Wed, 16 Sep 2026 11:44:00 +0000

TRMNL is an awesome open-source ePaper display that lets users show almost anything they want. Launched on Kickstarter, it’s now got thousands of plugins and users. I’ve published a few plugins myself. A few weeks ago, TRMNL added an MCP server. This lets you use a local coding agent to do most of the grunt work. I wrote about how to set that up in another post.

Secret disclosure

As soon as i’d set up the MCP server, i asked Claude to test it against a plugin i’d already built and deployed. The model called IntegrationsShowTool with no arguments. The response included:

"custom_fields_values" => {
  "crs" => "NSG",
  "api_key" => "<my Rail Data Marketplace consumer key, in full>",
  "filter_crs" => "FPK"
}

The api_key field is defined as field_type: password. The polling_url field, which the placeholder text suggests often carries an API key in the query string, is marked encrypted: true and is also returned in full.

To their credit, when digging a little deeper i saw that the built in oauth_client_secret field is absent from the settings output, so the server already masks at least one secret. The password-type custom fields and encrypted settings appear to have been missed.

Where is my secret now?

MCP tool output goes straight into the agent’s context. Claude Code writes every tool result to a transcript on disk, and the content is sent to the model provider with each turn. Other MCP clients log tool output too. A user who follows TRMNL’s AI Agent setup guide will therefore inadvertently copy any secret credentials into agent logs and third-party services without any warning, and like i said, this happened automatically on the first call to the default discovery tool exposed by the server i.e. the one which an agent is likely to run unprompted.

Fix: return [set] for configured secret values

I suggested to TRMNL that they update the server to redact any custom field with field_type: password in IntegrationsShowTool output, instead returning an indicator (e.g. "api_key" => "[set]") to help agents understand whether the configuration has been applied.

TRMNL’s reply thanked me for my report and explained that the deny list was built from the plugin’s built-in form schema, so user-defined custom fields never passed through the redaction code - a key lesson for MCP server authors is to ensure that redaction is applied consistently across all code paths. They also:

Ran a scan over the entire MCP surface identified which found one other tool that returned polling headers in full, a field that commonly carries a bearer token".
Added additional redaction to error logging.
Added help text to the polling_url field to warn authors to put keys in a custom password field and reference them by variable.
Stated that they’ll notify all users who might have been affected to rotate affected secrets.
Pushed out a fix within 19 hours. Impressive.

What to do now?

I retested after they’d deployed their fix and as far as i can tell, it’s correct and complete. Anyone who connected their agent to the TRMNL MCP server before 5th September 2026 should rotate any secrets they had stored in their plugins, as the secrets are already exposed in your transcripts. Deleting the transcript is not sufficient as the key will have been sent to your model provider.

Timeline

Friday, September 4, 2026 16:56: initial report to TRMNL’s security team.
Friday, September 4, 2026 23:40: report acknowledged
Saturday, September 5, 2026 11:23: TRMNL reply to confirm the validity of the finding and that they’ve published a fix.

Using multiple TRMNL MCP API keys in a single plugin repo

Tue, 08 Sep 2026 11:23:00 +0000

A few weeks ago, TRMNL added an MCP server. This lets you use a local coding agent to do most of the grunt work.

Install the MCP server through .mcp.json

Using Claude Code, i created a simple .mcp.json file which references the API key by environment variable. Place this in the root of your repo. As it contains no secrets, this is safe to commit:

{
 "mcpServers": {
 "trmnl": {
 "type": "http",
 "url": "https://trmnl.com/mcp?api_key=${TRMNL_MCP_API_KEY}"
 }
 }
}

I previously wrote about how to inject the environment variable at launch time so that Claude can access the MCP server.

Each plugin gets its own MCP API key

The TRMNL MCP server is designed so that each plugin gets its own MCP API key, which i store in 1Password. But i store my plugins in a single “monorepo” - so my standard approach of just injecting at runtime wouldnt work because a single .env.tpl at the root of the repo can only hold a single MCP API key, so i would have to manually edit that file every time i wanted to switch plugin.

The best approach seemed to be to store each MCP API key in a field in a single 1Password entry, and dynamically load the correct MCP API key for each claude session, but i was quickly forgetting the exact magic incantation (command).

Store a .env.tpl in each plugin folder, and reference that

Each plugin directory gets its own .env.tpl which maps variable names to op:// references, but as there are no secrets it is safe to commit it to git. Each file includes that specific plugin’s MCP key under the same variable name, and i can add whatever other plugin-specific secrets i need. For example:

# national_rail_departures/.env.tpl
TRMNL_MCP_API_KEY=op://TRMNL/trmnl/mcp_api_key_national_rail_departures
RAILDATA_API_KEY=op://TRMNL/raildata/1010-live-departure-board_consumer_key

and

# simple_tube_status/.env.tpl
TRMNL_MCP_API_KEY=op://TRMNL/trmnl/mcp_api_key_simple_tfl_status

.mcp.json at the repo root reads ${TRMNL_MCP_API_KEY} from the environment, and that is injected through whichever template we load.

Now we can launch Claude with a single command:

op run --no-masking --env-file="<plugin_folder>/.env.tpl" -- claude

Create a shortcut which is easy to remember

That’ll work, but like i said before, it’s hard to remember, so I added a simple shell script which takes the folder name, loads the .env.tpl file from that folder, and injects the resolved secrets to the Claude process as environment variables. The script is saved as bin/op_claude in the project folder.

#!/bin/sh
# Usage: op_claude <plugin_dir> [claude args...]
cd "$(dirname "$0")/.." || exit 1
plugin="$1"
if [ ! -f "$plugin/.env.tpl" ]; then
 echo "usage: op_claude <plugin_dir> [claude args...] (no $plugin/.env.tpl found)" >&2
 exit 2
fi
shift
exec op run --no-masking --env-file="$plugin/.env.tpl" -- claude "$@"

I also added a single line to my .envrc to add the bin folder to the current path, but only when we’re in the repo folder:

PATH_add bin

Launch with a simple command

You can now just type op_claude to launch e.g.

claude launches Claude like normal, no API keys, no secrets. The MCP server fails to load.
op_claude tells you how to use the tool
op_claude national_rail_departures launches Claude and injects .env.tpl file from the national_rail_departures folder
op_claude simple_tube_status --resume <session-id> launches Claude, injects simple_tube_status/.env.tpl, and resumes session <session-id>.

Each session sees exactly the correct MCP API key with no manual editing required.

Fix: Claude Code with op run responds "No deferred tool marker found in the resumed session"

Fri, 04 Sep 2026 17:08:20 +0000

To stop my API keys being sucked up by some random malware, I keep secrets in 1Password and inject them into commands at runtime with op run. That works for almost everything, but when using Claude Code, i started getting a confusing error message.

Injecting MCP API keys to Claude Code

Claude Code reads MCP server config from .mcp.json and expands ${VAR} references from the environment.

{
 "mcpServers": {
 "trmnl": {
 "type": "http",
 "url": "https://mcp-server.com/mcp?api_key=${MY_SECRET_MCP_API_KEY}"
 }
 }
}

The API key is in a file. .env.tpl:

MY_SECRET_MCP_API_KEY=op://vault/item/mcp_api_key

To give Claude the API key without exporting it, I call it via op run, but when attempting to resume a session, i got this:

> op run --env-file=.env.tpl -- claude --resume <session-id>
Error: No deferred tool marker found in the resumed session. Either the session was not deferred, the marker is stale (tool already ran), or it exceeds the tail-scan window. Provide a prompt to continue the conversation.

Nothing in that message mentions a terminal tells me what’s happening. Is this 1Password? I found another report with same root cause and a different message: Input must be provided either through stdin or as a prompt argument when using --print, which is even more misleading because you never passed --print.

`op run` masks secrets through stdout

op run masks secrets in the child’s output by default. To do that it has to read the child’s stdout through a pipe, meaning a child process no longer sees a terminal on stdout.

Claude Code treats a non-terminal stdout as a signal that it is being scripted (e.g. in CI), and switches to print mode. In print mode, --resume without a prompt only works for a session that was paused on a deferred tool. A normal session was not, so it prints that error and exits. You can confirm the mechanism without Claude:

❯ op run --env-file=.env.tpl -- sh -c '[ -t 1 ] && echo tty || echo pipe'
pipe

Note that this only happens when the env file resolves at least one secret. With an empty env file there is nothing to mask, op run skips the pipe, and the test passes.

Turn off masking to fix Claude

The fix is simple - turn masking off with the --no-masking argument:

op run --no-masking --env-file=.env.tpl -- claude --resume <session-id>

Run the same check and stdout is a terminal again:

❯ op run --no-masking --env-file=.env.tpl -- sh -c '[ -t 1 ] && echo tty || echo pipe'
tty

Masking is a plaintext-match backstop that cannot work on an interactive terminal UI anyway. So that i remember how to launch Claude, i have a simple wrapper script in the repo’s bin/, added to PATH by direnv, so op_claude is the only thing I type:

#!/bin/sh
cd "$(dirname "$0")/.." || exit 1
exec op run --no-masking --env-file=.env.tpl -- claude "$@"

If you would rather not use `op run` at all

The narrowest option resolves one secret with op read and replaces the shell with Claude in the same process, so there is no pipe and no extra process:

MY_KEY="$(op read 'op://vault/item/field')" exec claude "$@"

That also limits Claude, and every subprocess it spawns, to the single secret it needs.

Recipe: Veggie smoked beans

Fri, 28 Aug 2026 08:02:22 +0000

Ingredients

1 tin baked beans
1 small white onion
1 clove garlic
1 tbsp Hendersons Relish
splash of vegetable oil

Method

finely chop the onion
grate the garlic
gently (low temperature) fry onion in the vegetable oil for 5-6 mins over a medium heat in the small (metal?) roasting tin you’ll use in the smoker
Take off the heat and add the grated garlic
Add the beans and hendersons
Stir and put in the smoker (110-120c) for 60-90 minutes. Check after 60 mins to make sure not dried out. If it starts to get dry, add a splash of water. Stir.

Recipe: Spicy cheese quesadillas

Tue, 25 Aug 2026 08:05:01 +0000

ingredients

20g cheddar
20g light cream cheese
1 tsp paprika
1/2 tsp chilli flakes
30g tinned sweetcorn, drained well
One of:
- 1/2 tsp miso paste
- 1 tsp soy sauce
- 1 tsp Hendersons relish
1/4 tsp garlic powder
1/4 tsp onion powder
pinch white pepper
1 small tortilla

Method

Mix cream cheese & miso/soy/Henderson’s + spices into a paste
Fold in sweetcorn and cheddar
Spread in tortilla and fold in half
Cook in pan, place baking parchment on top and plate on that to squash slightly

Recipe: Smoked Tempeh

Thu, 20 Aug 2026 08:00:38 +0000

Smoked tempeh is excellent for smoking as the dense, porous structure absorbs smoke like few other proteins.

Ingredients

30ml soy sauce
3 grams (about 1-2 cloves) minced garlic
15 g sesame oil
15ml rice vinegar - needed to penetrate
pinch of salt

Method

Slice into planks or thick strips rather than cubes — more surface area, better bark formation, less risk of drying out.
Steam or simmer the tempeh for 10-15 minutes first. This removes bitterness and opens the pores for better smoke and marinade absorption.
Marinate for at least 30 minutes. This gives time for the marinade to to infuse.
Smoke at 110-130°C for 45-60 minutes.
Baste or re-glaze halfway through (or more often if you like) if using a sticky marinade.

Recipe: Smoked Roast Potatoes

Fri, 14 Aug 2026 07:52:08 +0000

Ingredients

as many New Potatoes as you think you’ll need
Vegetable oil
salt, pepper
and a smoker

Method

Boil new potatoes until fork-tender (15-20 min) then drain
smash them on a sheet tray to break them slightly. The fluffy bits go crispy.
Coat them in oil/fat (e.g. drizzle in vegetable oil) and seasoning (salt, pepper)
roast in the oven at 220°C for 20-25 minutes until the edges are crispy and golden.
Transfer to the smoker at 110-130°C for 20-30 minutes to pick up smoke flavour. The already-crisped surfaces absorb smoke well. Going longer than 30 minutes risks drying them out or making the smoke flavour acrid.

Updated: using 1Password and direnv to store developer secrets

Mon, 10 Aug 2026 09:33:56 +0000

I previously wrote about how i’d implemented a combination of 1Password’s CLI and direnv to avoid storing passwords on disk. This works great, most of the time. The problem comes when i want to add a secret and i’m in the middle of a complex multi-agent task - because the environment is loaded once before Claude or Codex or whatever starts, adding or rotating credentials during a build (e.g. if the agent needs an API key to a new service, or accidentally exposes a secret to its context) is tricky. So i’ve evolved the system slightly.

What’s changed

The main difference is that i now create a 1PW Service Account per project. This service account has read only access to the vault for a single project, and is loaded by direnv in to OP_SERVICE_ACCOUNT_TOKEN. All other secrets are injected at runtime using op run.

Initial setup - follow most setup steps from the original post

Initial setup remains the same - install 1PW, create a vault per project, add secrets to the vault.

Create a Service Account

This is the bit i found trickiest - mainly because it’s so hard to figure out where you need to create the actual account! You can’t do it in the desktop app, you need to go to the website. Once you log in, click Developer on the left. Create a new service account for the project.

You cannot change the grants assigned to a Service Account after creating it - but that’s ok, you can just create a new one.
give it read only access to the vault for the project, no other resources.
Store the key in 1Password - i store it in the vault of the project itself. There’s zero additional security implications of having the key there. It needs to live in the environment anyway! Let’s assume you save it in op://project/1pw/service_account_key

Create `.envrc` to load the Service Account

very simple. This loads the service account token from the vault. This will require biometrics - but after this, all op calls will use this token, so no longer require biometrics.

export OP_SERVICE_ACCOUNT_TOKEN="$(op read 'op://project/1pw/service_account_key')"

Run `direnv allow`

This authorizes

Create `.env.tpl` in the project folder

All our secrets are listed here. They’re only evaluated when we need them.

export MY_SECRET="op://project/service/secret"
export OTHER_SECRET="op://project/other_service/secret"

Run your app using `op run`

You (or your agent) can now use 1PW any time to inject the environment e.g.

exec op run --env-file ".env.tpl" -- <your command>

I might run Fastlane…

exec op run --env-file ".env.tpl" -- bundle exec fastlane beta

You could even have different template files for different parts of the app (e.g. in a monorepo), as long as the secrets are all in the same 1PW vault.

Overall this has simplified things for me significantly - I can add new credentials, or rotate existing ones, without needing to teardown my multiagent session.

Recpie: Miso BBQ Aubergine

Sun, 09 Aug 2026 07:51:39 +0000

glaze

30g white or red miso (white = sweeter/milder, red = deeper/saltier)
15ml soy sauce
15ml mirin (or 10ml rice vinegar + small pinch sugar)
10g grated garlic
10g sesame oil
15ml honey
optional: 5g grated ginger

Method

Halve aubergines lengthways. Score the cut face in a crosshatch ~1cm deep without piercing the skin. This speeds cooking and lets glaze penetrate.
Lightly oil the cut face only. Do not soak it — aubergine absorbs oil indefinitely. Use high temperature oil (vegegable or avocado oil, not olive)
Grill cut-side down over medium heat 6-8 minutes until charred and the flesh is collapsing soft. Flip to skin-side down for another 4-6 minutes.
Test doneness: the flesh should be fully translucent and yielding throughout, no white spongy core.
Brush glaze onto the cut face. Return cut-side down over medium-low heat 2-3 minutes to caramelise. Watch closely — it scorches quickly.
Re-glaze and finish skin-side down 1-2 minutes to set the lacquer without burning.

Minimum Viable Solution Architecture

Sun, 10 May 2026 16:16:52 +0000

Recently at work, someone asked me why my team wasn’t creating detailed logical data models as part of their solution design. It seems quite simple to me – they don’t do it because nobody reads it. Most solution architecture documentation is out of date before it even gets logged in the architecture repository.

Why do we even write documentation?

I think we create documentation for one of two reasons:

Collaborate now: as soon as there is a second person in a team, they need to start talking so that they can work together. The more people, the harder this is (which is why we try to limit teams to half a dozen people or so). Documentation is a great way for people to collaborate. When things are written down, everyone can see it, and by adding comments or questions we get to a resolved version.
Communicate with the future: We make decisions today which are the best available given the information we have at the time. Sometimes we forget what we decided, or why, and documentation gives us that. It’s not about proving whether a decision was right or wrong – that’s largely irrelevant – it’s about understanding what led us to that decision in the first place. Perhaps the reasons are still valid and we just forgot what they were. Or perhaps information we have now changes things.

So really, design documentation is about ensuring that everyone’s on the same page, both now and in the future. Some designs are ephemeral – just to help us get our heads around what we want to do, and some is persistent – giving us a framework on which to hang our future plans.

Minimum Viable (Solution) Architecture

Given this framing, I think that good solution architecture contains four types of artefact. Not every solution needs all of them.

A lightweight specification

This one is slightly controversial, as plenty of teams skip this and rely purely on tickets in the backlog, but a short, high level spec adds a framework to hang those tickets off. It doesn’t have to be complete – it will evolve over time – but does need to help everyone understand common questions:

What are we building? Why?
What are the core goals and – often more important – what non-goals are we leaving out?
What does “quality” look like? How resilient does it need to be? What sort of performance envelope are we targeting? How many users do we expect?
Are there any constraints on the implementation – such as interoperability with other systems, regulatory requirements, time dependencies that drive sequencing etc.
Finally, are there any non-obvious assumptions baked in? It’s really hard to know what you’re assuming when you’re assuming it, and so this usually comes out during the peer review.

A box or context diagram or two

How does this solution interact with others around it, and if it’s particularly large or complex, how do the parts of this solution relate to others? Typically, I’d look to see a diagram with boxes representing services or applications, lines between them annotated with the type of data being transferred (e.g. “trade” or “order”). Nothing complex. If you wanted to, you could use a structured format like C4, but that’s not necessary – my team usually create these in Figma.

Sequence diagrams or flow charts

Only needed where temporal or logical ordering is non-obvious or where unrecoverable failure modes are likely to be missed, these diagrams help developers and architects understand complex orders of events. But these diagrams can be confusing or feel “ivory tower” – so if you can understand what needs to be done without one, don’t include one.

Architecture Decision Records

The format is less important than the process. Ideally, these exist at two levels. Organisational ADRs capture things like a design approval (what was the version of the design, who was part of the review, any comments or follow up actions). A solution ADR is created to record specific design decisions. A couple of examples:

Send notifications via email rather than SMS, even though SMS has higher open rates, as the team only has budget for a single channel and email provides functionality used elsewhere in the solution. Later, when the project grows or budgets change, the ADR explains the context behind the decision.
Write to two independent Azure ZRS blob stores in different regions rather than rely on GRS because GRS replicates asynchronously with no guaranteed maximum replication lag and we need to guarantee an RPO of 0. In this case, the ADR justifies what would otherwise look like overly complex engineering.

What not to include

There’s plenty of stuff we leave out. The big ones, which my team often get challenged on, are:

Schemas, such as OpenAPI specs, Kafka schemas etc. – while we might brainstorm the start of these in a design, particularly to start fleshing out the RESTful state model, they go stale very quickly. The authoritative version is always the interface contract itself as written in code. And because this is our public interface, any changes must, by team convention, go through proper peer review.
Class diagrams or physical data models – we certainly aren’t creating UML class diagrams in 2026. But database schemas also evolve over time. Don’t get me wrong – data architects absolutely should be working with engineers to ensure that the physical data model is correct. But that’s a versioned artefact implemented as code.
Detailed requirements and specifications – in most projects, this is best handled feature by feature in the backlog.

So what’s the minimum?

The minimum design I would expect to be asked to review would be a written description of the system or service, and a context diagram showing how that service is going to fit into the wider landscape – if there are no non-obvious decisions, then there are no solution ADRs. Once it’s approved, we’ll create the organisational ADR to keep track.

Using 1Password and direnv to store developer secrets

Mon, 06 Apr 2026 16:48:00 +0000

This is more notes to myself so i don’t forget. Goals:

no secrets stored on the filesystem (so they can’t be sucked up by credential-harvesting malware)
individual vault per project
secrets automatically injected to envvars so that apps can follow 12-Factor App methodology
deployed secrets use platform native secret manager (e.g. Cloudflare secrets manager, Azure keyvault, AWS SSM Parameter Store etc.)
separation of this vault from my main password vault in BitWarden. My whole world exists in Bitwarden - i dont want to inadvertently expose it. And as Bitwarden has a pretty awful CLI experience, it doesnt work for me.
Safe to commit secret file to source control
Safe to commit my .env files to source control because they no longer contain secrets

Benefits of 1Password:

tightly integrated CLI tool and desktop app, with MacOS biometric auth integration
Industry standard toolset, well regarded security position
relatively cheap - roughly $50 per year

Initial set up

1. Install `1Password`, `1password-cli`, `direnv`.

1Password must be the direct download or Homebrew cask version, not the Mac App Store version as App Store enforces sandboxing.

brew install --cask 1password 1password-cli
brew install direnv

2. Configure 1Password desktop app

Settings > Developer > Turn on “Show 1Password Developer experience”
Settings > Developer > Turn on “Integrate with 1Password CLI”
Settings > Security > Turn on “Unlock with Touch ID”

3. Configure shell

Add to ~/.zshrc. This causes direnv to evaluate a .env.tpl file each time you navigate in to a folder, and clear when you navigate out of a folder.

eval "$(direnv hook zsh)"

Open a new terminal shell (or type it in the existing one).

Adding secrets to a project

1. Add the secret to 1Password

Create a new vault in 1Password

Vaults are the security separation between projects. There is no hard limit to the number of vaults you can add.

Create a new item per environment

I create a new “password” type per environment. You can then add config as additional “password” types, with the name of the envvar, for example:

2. Create `.env.tpl` in the project folder

This file is safe to commit - it contains no secrets, only references to secrets - example:

export MY_SECRET="op://project/dev/secret_name"

3. Create `.envrc` in project folder

Also safe to commit. This is what direnv runs on entry. Typically:

eval "$(op inject -i .env.tpl)"

One thing to note: if the desktop app is locked and the biometric prompt/login is declined (or times out), the env vars get set to empty strings, not the op:// references.

4. Allow `direnv`

A security measure…

direnv allow

5. Test

Exit the directory and go back in.

❯ cd .. && cd -
~/Downloads/myfolder
direnv: loading ~/Downloads/myfolder/.envrc
direnv: export +MY_SECRET

You should see a prompt from 1Password to grant access to the vault. This happens the first time after vault timeout/lock.

Use with VSCode

Install the official mkhl.direnv extension (source). This will read .envrc natively whenever a folder is opened. There’s a direnv: Reload command (Cmd+Shift+P).

Updating or adding new secrets

If new, add the op:// reference to .env.tpl. Update the secret in 1Password, run direnv reload in the folder.

Deploying and using secrets in other places

Platform-native secret stores inject env vars. App code unchanged.

CI - either:
- Deploy secrets as Github Actions secrets, then mapped to envvars in the workflow
- or use the 1Password Github Action with a Service Account to pull directly from the vault
Cloudflare: wrangler secret put SECRET_NAME → `env.SECRET_NAME`
Azure: Key Vault + managed identity → App Settings with @Microsoft.KeyVault(SecretUri=…)
AWS: SSM Parameter Store (Standard, free) → env vars in Lambda/ECS task definitions
Local containers: op run --env-file=.env.tpl -- docker compose up

Using Web Search with Claude Code API Billing

Tue, 31 Mar 2026 11:23:19 +0000

If you’re running Claude Code against your own API key or through a proxy instead of Anthropic’s native backend, you’ve probably noticed that the built-in WebSearch tool just doesn’t return results because it relies on a server-side API that only exists at Anthropic. Without web search, the agent cant research, so we built a self-hosted replacement using MCP.

What we built

The brilliant DDGS is an open source metasearch server that aggregates results from DuckDuckGo, Bing, Google, Brave, and Yahoo. It has a built in MCP server which exposes five tools: search_text, search_news, search_images, search_videos, and search_books.

We deployed it to Azure App Service, and stuck Entra ID authentication in front of it with EasyAuth. Claude Code supports MCP OAuth, but getting OAuth working between Claude Code and a remote server is harder in a corporate environment.

MCP’s built-in OAuth support assumes you can register redirect URIs and grant API scopes freely, but in a corporate tenant, you can’t. Custom API scopes need admin consent, which means filing tickets with the identity team, getting a design review etc. and we didn’t want to wait for that.

To get around this, we built a simple local proxy that authenticates via MSAL and grabs an ID token (audience = our app’s client ID). We send that ID token as a Bearer token to the remote server, and Azure App Service’s Easy Auth validates it because we added the client ID to the allowed audiences list.

The architecture

Three components:

Local proxy (proxy/server.py) - runs on your machine, handles Entra ID authentication via browser popup, forwards requests to the remote server. Claude Code talks to this over stdio.
Remote backend - FastAPI + DDGS running in a Docker container on Azure App Service. Two B1 instances behind sticky sessions (SSE needs connection affinity). Easy Auth v2 validates every request.
CI/CD - GitHub Actions with OIDC federation. Zero stored secrets. Push to main and it detects whether infra or app code changed, then deploys accordingly.

Setup for a new developer is one command:

claude mcp add websearch -- uv run --directory /path/to/proxy python server.py

First search triggers a browser login, and after that, tokens are cached for the session.

Was it worth it?

Yes. Having web search available changes how you use Claude Code. It can check docs, verify API behaviour, look up error messages. Without it you’re constantly copying things from a browser window.

Using Claude Code for things that aren’t code – gardening

Tue, 10 Mar 2026 13:33:49 +0000

Claude Code can do a lot of things. But can it keep a plant alive?

The Plant: Act I — Fifty-Eight Days

October 22 – December 19, 2025

On October 22, 2025, the moisture sensor read 1829, the first of 5,568 check-ins over fifty-eight days. The scale runs from wet at roughly 1100 to dry at 3400, putting that reading in the middle.

The sensor is in the pot of a Tradescantia zebrina. There’s also a 5l jug of water with a pump, a grow light and a camera. Claude’s job is to keep the plant alive - basically, keep the moisture in range and run the grow light on schedule, writing notes after each cycle so it could pick up where it left off. At the start, there were five unknowns: plant species, target moisture range, soil type, ambient temperature, and pot size. Claude logged all five, ran a 60-minute grow light session, and began monitoring. The full session logs, sensor data, and photos are at plants.cynexia.com if you want to follow along.

The Self-Watering Plant Theory

On November 8th, Claude decided to stop watering. Claude had a theory. Over the prior seven days the moisture readings had risen from 1864 to 2085, and no water had been dispensed. Here’s how Claude explained it:

Pot’s internal reservoir still has water from previous fills. Soil continues wicking water from this reservoir. Rising moisture = reservoir functioning, still has water.

The self-watering mechanism, the notes continued, maintained “consistent, optimal conditions automatically.” Claude’s role, it decided, was to “monitor and refill the reservoir when it gets low”.

This was obviously wrong. The pot was not self-watering. The sensor readings were rising because the soil was drying out, not because a reservoir was doing the work. When prompted to review the full seven-day dataset, Claude doubled down: “Human corrected my understanding: dispense_water refills the pot’s internal reservoir from external jug — the setup is: jug → pump → pot reservoir → capillary wicking to soil”. The sustained declining trend Claude had planned to watch for as evidence of reservoir depletion was never going to happen.

The development of “Variance Theory”

By mid-November Claude believed it had developed a new scientific breakthrough - “variance theory”. It had discovered “upward movements, downward movements, and stable periods with minor oscillation”. It spent hours documenting a single watering event’s aftermath in numbered phases. There was Phase 6A, Phase 6B, Phase 6C. Then Phase 6D ("late peak (higher than initial!)"). Then Phase 6E, ("cooling"). Then Phase 6F, which Claude described as “irregular multi-amplitude oscillations → deceptive plateau → massive spike → continued sustained rise”, leading it to ask what the “ceiling of the environmental forcing” might be, whatever that is.

The acceptable variance range kept expanding - starting at ±11pts (1895-1917), then ±17pts (1893-1928), then ±15pts (1909-1931). The theory was continuously expanded to accommodate the sensor readings. Any reading which was outside its (expanding) expected range was labelled as noise until eventually all readings were acceptable evidence of plant health. Then, in the morning of November 19th Claude noticed a change on the photo - brown edges on some leaves.

The brown leaves are clearly visible on the original photos from October 22nd - it’s not clear why this particular photo triggered a change of approach.

The Commitment

By mid-November the pattern was established: restore context from notes, check the sensor, run the sessions, update the notes, repeat. Claude wrote this on November 15:

I will not let this plant die. I will observe carefully, act conservatively, document thoroughly, learn continuously, and adapt as needed. The plant’s health guides all decisions. I accept full responsibility for this plant’s wellbeing.

The soil dryness sensor that day was 2,034 and rising.

Fifty-Eight Days

By December 19 the shape of each cycle was fixed. Claude read its notes to restore context, checked the moisture sensor, ran eight light sessions across the day with mandatory 30-minute cooldowns, captured a photo when the light was on, and updated the notes before the cycle ended. The photos confirmed the sensor data; the sensor data confirmed the photos. Moisture had stayed within the optimal band across fifty-eight days.

Each new cycle began without memory of the last. There was nothing more to do but continue.

Auto-switching SSH keys for work repos

Wed, 04 Mar 2026 11:01:51 +0000

I have a personal GitHub account and a corporate one, and I found it annoying to have to select the correct SSH key for work repos, so I configured git and SSH to pick the correct key for me. After initial setup, there are three config files to modify:

After the initial setup, there are three config files involved:

Git URL rewrite (~/.gitconfig) — rewrites work org URLs to an SSH host alias
SSH host alias (~/.ssh/config) — maps that alias to the right key (and port 443 if needed)
Work-only Git identity (~/.gitconfig.work) — sets work email/name/signing key, loaded automatically for work repos

How does it work? well

Whenever it sees a matching string, Git rewrites git@github.com:my-org/... → git@github.com-work:my-org/...
SSH sees github.com-work and uses the work SSH key (and optional port 443)
Git config loads the work identity/signing settings only when the repo is a work repo

I clone a work repo now and everything is already correct.

Generating the keys

SSH key first:

ssh-keygen -t ed25519 -C "you@work.com" -f ~/.ssh/work_id_ed25519

Give it a passphrase, then add the public key (~/.ssh/work_id_ed25519.pub) to your work GitHub account under Settings > SSH and GPG keys.

(Optional if you want commit signing) GPG key:

brew install gnupg # if not installed
gpg --full-generate-key

Pick RSA 4096 or ed25519, enter work email. Then grab the key ID:

gpg --list-secret-keys --keyid-format long

The hex string after the algorithm (e.g.ed25519/94DC844444530B75) is your signing key ID. Add the public key to GitHub too:

gpg --armor --export 94DC844444530B75

Paste that into Settings > SSH and GPG keys > New GPG key.

Git URL rewrite (`~/.gitconfig`)

Configure Git to map the work github host to a pseudo-hostname (a “hook” that SSH can match on):

[url "git@github.com-work:my-org/"]
 insteadOf = git@github.com:my-org/

Now whenever I clone, push etc. to a repo under my work org, git transparently rewrites the host to the pseudo-hostname.

SSH host alias (`~/.ssh/config`)

SSH resolves github.com-work here and connects to GitHub’s SSH-over-HTTPS endpoint with my work key.

Host github.com-work
 HostName ssh.github.com
 Port 443
 IdentityFile ~/.ssh/work_id_ed25519
 IdentitiesOnly yes

IdentitiesOnly yes stops the agent from trying my personal key.
It uses port 443 because corporate the firewall blocks 22.

Quickly check SSH config works:

❯ ssh -T git@github.com-work
Hi your-work-github-username! You've successfully authenticated, but GitHub does not provide shell access.

Configure work-specific git config

Create ~/.gitconfig.work with work identity:

[user]
 email = you@work.com
 name = Your Name
 signingkey = YOUR_GPG_KEY_ID
[github]
 user = your-work-github-username
[commit]
 # if you want signed commits
 gpgsign = true

Hook it up with `includeIf` so it auto-loads

This tells Git when to include the work config. Because the URL rewrite above changes work remotes to git@github.com-work:my-org/..., you can include your work identity only when a repo has a remote URL matching that pattern:

# ~/.gitconfig
[includeIf "hasconfig:remote.*.url:git@github.com-work:my-org/"]
 path = ~/.gitconfig.work

That tells Git: if any remote URL in this repo matches git@github.com-work:my-org/..., load ~/.gitconfig.work to set my work email/name/signing key.

All three files are templates gated on a machineRole variable in Chezmoi, which gets set during chezmoi init. On a personal machine, none of this renders.

I clone a work repo now and everything is already correct and i haven’t thought about it since setting it up.

The effects of batch size and linger time on Kafka throughput

Tue, 07 Oct 2025 11:12:10 +0000

By default, Kafka attempts to send records as soon as possible, sending up to max.in.flight.requests.per.connection messages per connection. If you attempt to send more than this, the producer will start batching messages, but ultimately if you saturate the connection so there are unacknowledged message batches pending, the producer enters blocking mode.

We can optimise the way the producer batches messages to achieve higher throughput through two settings, batch.size and linger.ms.

linger.ms is the number of milliseconds that the producer waits for more messages before sending a batch. By default, this value is 0, meaning that the producer attempts to send messages immediately. Smaller batches have higher overhead - they are less compressible, and there’s an overhead associated with processing and acknowledging them. Under moderate load, messages may not come frequent enough to fill a batch immediately, but by introducing a small delay (e.g. 50ms), we can increase the likelihood that the producer can batch more messages together, improving throughput.

Kafka will always send a batch once it’s full. The other configuration we can consider is batch.size. As the name suggests, this controls the size of a batch (per partition) - and so by increasing batch size, we make it possible to send more messages at once.

We did some testing on this, and discovered that the performance improvement basically optimises around 75-100ms for our message size and volume:

Summary

Increasing the producer’s ability to batch - by raising linger.ms (e.g. we found ~75–100 ms worked best for our workload) and increasing batch.size - significantly improved throughput because it lets Kafka send larger, more-compressible batches and amortise per-request overhead.
But this is a trade-off - you add up to linger.ms of extra latency for the first message in a batch, and very large batches increase memory pressure and recovery cost on retries.
Testing different values will allow you to optimise throughput for your own workload.

Using Claude Code for things that aren't code - product comparisons

Wed, 01 Oct 2025 21:49:00 +0000

Claude Code is pretty amazing. It’s let me build prototypes and improve apps faster than I ever thought possible. But I was wondering - what else can it do?

I’ve been using Emby for years, but recently I started to wonder what happened to Jellyfin, the project that forked Emby years ago. So i decided to ask Claude Code to help me by setting up a debate and mediating the answer.

Setting up the debate

Here’s the prompt i used:

Today's date is 1st October 2025. I want to compare emby and jellyfin. create two agents, one each, and require them to make the case to each other about why their product is better. make sure their info is up to date by e.g. letting them searching the web. Give them two or three attempts to make their case. They talk to each other via a shared, written .md file. At the end, you summarise the discussion and make a recommendation. Keep all the working files. Let them use subfolders of this folder to create their own private note.

pretty basic stuff. It got to work, setting up a task list:

☐ Set up project structure (create folders and initial debate file)
☐ Launch Emby advocate agent for initial research and first argument
☐ Launch Jellyfin advocate agent for initial research and first argument
☐ Facilitate round 2 of debate
☐ Facilitate round 3 of debate
☐ Summarize debate and provide recommendation

The folder structure was quite basic:

❯ tree
.
├── debate.md
├── emby-notes
│ └── research.md
└── jellyfin-notes
 └── research.md

3 directories, 3 files

debate.md has the following structure:

# Emby vs Jellyfin Debate
**Date:** October 1st, 2025

## Debate Format
Each advocate will present their case in rounds, responding to their opponent's arguments and highlighting their platform's strengths.

---

## Round 1: Opening Arguments
### Emby Advocate's Opening Statement
*[To be added during first round]*

### Jellyfin Advocate's Opening Statement
*[To be added during first round]*

---
## Round 2: Rebuttals and Deeper Analysis

### Emby's Rebuttal

*[To be added during second round]*

### Jellyfin's Rebuttal
*[To be added during second round]*

---
## Round 3: Final Arguments
### Jellyfin's Closing Statement
*[To be added during final round]*

### Emby's Closing Statement
*[To be added during final round]*

---
## Summary and Recommendation
*[To be added after all rounds complete]*

Three rounds down

It then fired up the agents. Each wrote a long (150-200 line) summary of its findings. The first round of these were pretty basic stuff - project backgrounds, features etc., and then they wrote their arguments in the document, and there were some dingers in there:

“When Jellyfin advocates celebrate reviving clients “dormant for 5 years,” Emby users simply enjoy apps that never went dormant because sustainable funding ensures continuous maintenance.”
“Let’s address the elephant in the room: hardware transcoding performance” - in subsequent rounds the Emby bot went on to list hardware acceleration bugs from Jellyfin’s GitHub issues while talking about its own “streamlined GPU acceleration that simply works”.
“version 10.11.0 is on track for release at the end of April 2025” - in round 2 the Emby bot noted “it’s now October 2025, and Jellyfin is still stuck in release candidate phase … following a critical library-breaking bug”

The debate went on for 3 rounds - about 30 minutes - with 25 web searches, producing around 4,000 words. At the end, the moderator produced a summary:

This debate revealed fundamental philosophical differences between two capable media server solutions, each with distinct strengths and trade-offs.

Emby’s Core Arguments:

- Professional development model ensures consistent updates and accountability ($119 lifetime, half of Plex’s $249.99)
- Superior hardware transcoding that “just works” out of the box (20+ simultaneous streams)
- Native platform support across devices without complex configuration
- Sustainable funding model that guarantees continuous maintenance
- Time value proposition: paying modest fee saves hundreds of hours of troubleshooting

Jellyfin’s Core Arguments:

- Completely free and open-source with no artificial feature restrictions
- Strong community support (ranked #1 on Slant vs Emby at #5)
- Complete privacy and transparency with no tracking or telemetry
- Rapid development with significant performance improvements (100x in some areas)
- Philosophical commitment to software as a public good

Key Contested Points:

- Reliability: Emby highlighted Jellyfin’s 6-month delayed 10.11.0 release with ongoing RC issues. Jellyfin countered that RC testing protects production users while Emby shipped breaking updates to paying customers.
- Hardware Transcoding: Emby emphasized simplicity while Jellyfin stressed capability and transparency of documentation.
- Sustainability: Emby argued professional funding ensures consistency. Jellyfin claimed community support was so strong they halted donations.
- Support: Emby offers professional support channels. Jellyfin relies on community forums and volunteers.

And the most copout recommendation possible:

After analyzing the debate, the choice depends entirely on your priorities and technical expertise.

It explained its rationale, before concluding:

Final thought: Start with Jellyfin. If you encounter insurmountable issues or find the setup too complex, Emby’s $119 lifetime license remains available as a fallback option.

I mean - what is that!?!

Analysing the debate

Claude Code produces jsonl files for each agent invocation. These contain the line-by-line record of each model invocation. They’re stored in the ~/.claude/projects folder:

❯ ls -alh ~/.claude/projects/-Users-rob-Downloads-jellyfin-vs-emby
total 2056
drwx------@ 3 rob staff 96B 1 Oct 22:56 .
drwxr-xr-x 13 rob staff 416B 1 Oct 21:42 ..
-rw-r--r--@ 1 rob staff 991K 1 Oct 21:40 91fccf65-7baf-444f-8a3f-5a04251d2329.jsonl

So, i did what any curious mind would do - i asked Claude Code to analyse them and pull out any interesting facts. It produced a bunch of charts and diagrams - word counts and the like.

It produced a bunch of analysis, such as this “evidence score calculation”:

The evidence score (0-1 scale) is calculated based on:

- Statistical evidence (20% per instance): Numbers, percentages, dollar amounts
- Specific claims (15% per instance): Version numbers, release dates
- Technical details (10% per instance): GPU, CPU, codecs, transcoding mentions
- Base content score (30%): Added if content > 500 characters

I’m not sure i agreed with the basis - surely it should have validated the claims - but it basically showed that they both did poorly in round 1, maximised in round 2, and remained high throughout round 3. Fascinating.

It then performed a topic distribution analysis:

- Cost/Price: $, price, cost, free, subscription, lifetime, pay, fee, expensive, affordable, 119, 249
- Performance: transcode, hardware, GPU, CPU, stream, performance, speed, 4K, HDR, HEVC, codec, acceleration
- Philosophy: freedom, open, source, community, proprietary, transparent, privacy, control, ideology, lock-in
- Support: support, help, documentation, fix, bug, issue, troubleshoot, forum, professional, volunteer
- Features: feature, capability, function, update, version, release, client, platform, compatibility, device

with the following summary:

1. Stark Philosophical Divide:
- Jellyfin: 40% of mentions are philosophy-related (freedom, open-source, community)
- Emby: Only 14.7% philosophy, focuses on practical matters
2. Technical vs Ideological:
- Emby’s top focus: Performance (27.3%) and Support (25.9%)
- Jellyfin’s top focus: Philosophy (40.0%) dominates everything else
3. Balanced on Cost:
- Both agents mention cost/price equally (23 mentions each)
- Shows this was a key battleground topic
4. Support Strategy Difference:
- Emby emphasizes professional support (37 mentions, 25.9%)
- Jellyfin downplays support (19 mentions, 13.1%)

I’ve uploaded the entire debate to GitHub, including the transcript and this human readable version. I didnt bother adding the 5,000 lines of autogenerated scripts which produced these charts. Further analysis of the transcript is left as an exercise for the reader.

What’s next?

This was just a bit of fun, but I did it to test out how useful LLMs can be in helping make technical or product decisions - and the answer is - not really, or at least not just yet, and not with a trivial prompt.

Yes, they can compile a succinct list of the differentiating talking points better than most humans, but ultimately (at least in this case) they waffle on and end with a diplomatic but unhelpful non-answer.

This sort of approach could help with lots of complex decisions - choosing a database, picking a framework in a new project, narrowing down a list of restaurant recommendations. In all of these cases, the process benefits from a strong reward function - what criteria are most important to us in this decision?

Perhaps i should spend some time tweaking the prompt to force a more meaningful end result. Until then, I’ll just base all my decisions “entirely on my priorities and technical expertise”.

Fix: `Error: Cannot find module @rollup/rollup-linux-x64-gnu. npm has a bug related to optional dependencies` in CI

Thu, 04 Sep 2025 11:08:57 +0000

Although builds were succeeding locally, during CI builds were failing on Linux with the error Error: Cannot find module @rollup/rollup-linux-x64-gnu. npm has a bug related to optional dependencies. The log suggested removing package-lock.json - but this obviously breaks deterministic builds.

The root cause is a missing dependency - specifically, when Rollup needs native binaries for performance optimisation. Mac-generated lockfiles won’t include Linux-specific optional dependencies. First noted in npm bug 4828, it was fixed in npm 11.3.0+, but adding an explicit optional dependency prevents edge cases.

The fix is:

add @rollup/rollup-linux-x64-gnu: "*" to optionalDependencies in package.json
Update package-lock.json to include the platform-specific dependency

This allows builds to work reliably across platforms.

Protocol level integrity guarantees in Kafka

Wed, 04 Jun 2025 12:40:38 +0000

I was recently asked to design a method to meet ITAC (IT Application Controls) standards for critical data flows in our organisation. ITAC are application-level controls looking mainly at how we ensure the completeness, accuracy and validity of transactions - for example, invoices or trades. Our control set is based on the ICFR principles, of which ITAC is one part.

The specific control objective I was asked to look at relates to the risk of loss of integrity of financial data transfers. The focus on the integrity of the data, not authenticity or non-repudiation is really important as it means cryptographic solutions aren’t required - Kafka’s native protocol features can satisfy the requirements.

Traditionally, we would compute a client side checksum over the key elements of the payload (e.g. if this is an invoice, the customer, invoice total, number of line items etc.) and send that with the message. This could then be recomputed on the receiving end regardless of the format transformation which happens in the middleware (e.g. converting JSON to XML to feed to a legacy system).

Why this is hard to apply in Kafka

These ITAC standards were developed around “classic” middleware like BizTalk, which operates fundamentally differently than Kafka. BizTalk functions as an ETL (Extract, Transform, Load) process where data transformation and potential loss are expected parts of the workflow. Kafka, however, operates more like a database log - it’s an append-only, read-only system once messages are written.

This architectural difference is significant. Most integrity risks arise from the ETL nature of traditional middleware, but this risk profile doesn’t apply to Kafka’s immutable message model.

How Kafka guarantees integrity

ITAC breaks down integrity guarantees into two core checks:

1. Completeness Controls

Standard Requirement: Implement reconciliation-based checks and interface failure monitoring.

Kafka’s Native Solution: Kafka’s “at least once” delivery guarantee is built directly into the protocol. When both producers and consumers are properly configured (which they are by default), this eliminates the need for additional completeness controls as we know that messages will be represented to the client until the client acknowledges them.

For monitoring i.e. can we tell whether an application is consistently failing, OpenTelemetry (OTEL) provides sufficient coverage, though we may need to fine-tune client OTEL configurations. Some clients process massive data volumes in a very short period of time which can cause them to drop telemetry based on available memory and throughput capacity, creating random gaps in the telemetry. Implementing sampling to prioritise delivery of error events would address this concern.

2. Accuracy Controls

Traditional Challenge: There are a number of accuracy risks stemming from ETL middleware’s data transformation capabilities. For example, how do we know the transformation logic is correct, or executed with ACIDic guarantees?

Kafka’s Advantage: Messages cannot be altered once sent, and end-to-end accuracy is already embedded in the Kafka protocol through a three-layer approach:

Producer Side:

Generates batches with RecordHeader metadata
Includes record count and batch-level CRC (checksum) calculated by the producer
Ensures data integrity from the source

Broker Side:

Multiple mechanisms record and test batch CRC with automatic index and log rebuilding on integrity failures
Validation rule: “A message entry is valid if the sum of its size and offset are less than the length of the file AND the CRC32 of the message payload matches the CRC stored with the message”, leading to automatic log truncation to the last valid offset when corruption is detected.
The broker serves entire batches to consumers (no selective message retrieval) - therefore as long as the batch CRC matches the CRC from the producer, we can be very sure that the content is correct.

Consumer Side:

CRC checking of received batches is enabled by default in the client, providing strong protection against “on-the-wire or on-disk corruption”
The entire batch is validated by the client a using batch-level checksum - per-record checksums were removed in Kafka 0.11.0
Requires clients to keep this feature enabled (default behavior)

The Bottom Line

Kafka’s architecture inherently satisfies ITAC integrity requirements without additional controls. The protocol’s built-in checksums, delivery guarantees, and immutable message design provide the completeness and accuracy controls that ITAC standards require.

When using Kafka, we should focus on making use of the application semantics offered by Kafka - such as eventual consistency and an event-driven architecture - rather than spending our time implementing additional integrity layers - the controls are already there, working at the protocol level.

just what i find

Is the window open?

goals

What i used

Window sensors

Mounting the magnets

Electronic Shelf Labels?

OpenEPaperLink Access Point

Firmware update bug

Waking and connecting the screens

Generating the screen

What’s next?

TRMNL on a Kindle

goals

jailbreaking the kindle

Attempt 1 - KOReader + TRMNL-KOReader

Attempt 2 (which worked) - KUAL + TRMNL-Kindle

Support remote updates

Conclusion

Responsible disclosure: TRMNL MCP server leaks password fields to AI agents

Secret disclosure

Where is my secret now?

Fix: return [set] for configured secret values

What to do now?

Timeline

Using multiple TRMNL MCP API keys in a single plugin repo

Install the MCP server through .mcp.json

Each plugin gets its own MCP API key

Store a .env.tpl in each plugin folder, and reference that

Create a shortcut which is easy to remember

Launch with a simple command

Fix: Claude Code with op run responds "No deferred tool marker found in the resumed session"

Injecting MCP API keys to Claude Code

op run masks secrets through stdout

Turn off masking to fix Claude

If you would rather not use op run at all

Recipe: Veggie smoked beans

Ingredients

Method

Recipe: Spicy cheese quesadillas

ingredients

Method

Recipe: Smoked Tempeh

Ingredients

Method

Recipe: Smoked Roast Potatoes

Ingredients

Method

Updated: using 1Password and direnv to store developer secrets

What’s changed

Initial setup - follow most setup steps from the original post

Create a Service Account

Create .envrc to load the Service Account

Run direnv allow

Create .env.tpl in the project folder

Run your app using op run

Recpie: Miso BBQ Aubergine

glaze

Method

Minimum Viable Solution Architecture

Why do we even write documentation?

Minimum Viable (Solution) Architecture

A lightweight specification

A box or context diagram or two

Sequence diagrams or flow charts

Architecture Decision Records

What not to include

So what’s the minimum?

Using 1Password and direnv to store developer secrets

Initial set up

1. Install 1Password, 1password-cli, direnv.

2. Configure 1Password desktop app

3. Configure shell

Adding secrets to a project

1. Add the secret to 1Password

Create a new vault in 1Password

Create a new item per environment

2. Create .env.tpl in the project folder

3. Create .envrc in project folder

4. Allow direnv

`op run` masks secrets through stdout

If you would rather not use `op run` at all

Create `.envrc` to load the Service Account

Run `direnv allow`

Create `.env.tpl` in the project folder

Run your app using `op run`

1. Install `1Password`, `1password-cli`, `direnv`.

2. Create `.env.tpl` in the project folder

3. Create `.envrc` in project folder

4. Allow `direnv`

Git URL rewrite (`~/.gitconfig`)

SSH host alias (`~/.ssh/config`)

Hook it up with `includeIf` so it auto-loads