Tris Sherliker

undefined

2025-11-02T00:00:00Z

Ignorance more frequently begets confidence than does knowledge.

Charles Darwin

I had a negotiation a while ago which very nearly derailed itself. I keep thinking back to what happened and what it tells me as a lawyer and a person. As lawyers, we’re usually advocating other people’s views. Our business is representing other people’s business, but sometimes it can be hard to keep track.

This was the settlement stage of a long-running dispute. The contract had gone back and forth several times, resulting in layered redline.⊕However a case begins, almost all of them end with drafting tweaks on an A4-shaped MSWord document trying to untangle the redline.

Redline-swapping is a nightmare if you don’t keep good track of your versioning, because it all blends together unless you take time to check the metadata for each revision. Worse, most law firms automatically strip out the metadata of all sent attachments out of caution, so it becomes verbal soup.⊕Version control was solved in software decades ago but it’s harder in law because (a) most lawyers are allergic to plain text and (b) it’s much, much easier to version collaboratively than it is when you’re adversarial.

In this case, we thought we were at the end. We’d decided to accept some of the less reasonable requests from the other side just to get the deal done, so we expected to be getting a signature back quickly. Couldn’t work out why it took so long to hear back. After chasing, we got another tangled version of the agreement, with comments this time:

The guy on the other side had clearly taken against some of the wording and committed several paragraphs in the margin to explain why it was blocking the deal, how unreasonable it was, and what awful people we were for having it in the draft in the first place.

A quick phonecall was enough to remind him that the wording came from his client, and we agreed with him. The deal was done within the day.

undefined

2026-03-22T00:00:00Z

Whenever I find myself doing a task for a third time, it’s probably going to come up again and probably worth writing a script to get it done faster when it does. This is a pretty common habit far from unique, but mine were beginning to get out of hand so I was interested to see Evan Hahn’s post about handling the cutter.

Ditching aliases

Instead of using aliases in bashrc (or in my case usually config.fish) for execution, Evan recommends adding basic scripts to a directory. You can then put that directory in your PATH The $PATH is the list of places where your system looks to find commands it’s being executed. This is different to the common (lowercase) “file path” showing where a file is found. and have the script execute right from your shell, while the directory is version controlled.

The effect is like a personal multitool that’s ready whenever you need it. Maybe obvious in hindsight but quite powerful in practice. Julia Evans also explains how to do this in a very clear way, covering lots of different cases.

I found the idea compelling and started using it straight away.

Doing the thing

I use fish shell (because it just works), so I can use the handy “do what you mean” built-inAlthough Julia Evans warns against this for a couple of reasons, including that it’s hard to undo. to do this:

~> fish_add_path (realpath ./script-path)

The (realpath …) function in the snippet above will be replaced by the full directory path. That will then be added to the PATH.

“Symlinks” is always the answer

One tweak to the setup I use is to have two folders:

/.../scripts for the scripts themselves, which is version controlled and
a subdirectory /.../scripts/script-path, which goes into the PATH.

⊕

scripts/
├── myscript.sh
├── .gitignore
└── script-path/
    └── myscript

script-path/ is gitignored and goes on $PATH; the scripts themselves stay under version control in the parent directory.

I can then use git to track the version control in the scripts directory, without needing to have a git history in my PATH (which feels like it could go wrong). So:

/.../scripts ~> mkdir script-path
/.../scripts ~> git init
/.../scripts ~> echo "script-path/" >> .gitignore

All that remains is to add the scripts themselves to the subdirectory. Rather than making copies of the various scripts, symlinks do the job cleanly. This way even when I update the main files, the symlinks still point where I want them to, and the files themselves remain under version control. Add scripts one at a timeThe first time, I did it in bulk. All my existing scripts were named with a .sh extension so in fish: ~> for sh_file in *.sh; set filename_without_extension (string split -r -m1 . $sh_file); ln -s (realpath $sh_file) ./script-path/$filename_without_extension; end with:

ln -s (realpath ./scripts/myscript.sh) ./script-path/myscript

And don’t forget to give all the script files executable permission with chmod +x filename.sh.

undefined

2026-05-02T00:00:00Z

Working out the date of a web page can be useful (especially for prior art in patent cases, and for evidence in litigation), but it can also be difficult. Most of the time a useful page has a date on it of some kind which may be reliable. For others the Wayback Machine helps perhaps about half the time but it hasn’t got perfect coverage. There’s another tool that can sometimesThis is mainly directed to static web content, i.e. content stored as files on a server. A lot of web content is generated dynamically and isn’t stored as files in the same way. help fill the gap.

The Last-Modified header

When you save or edit a file on your computer, the system logs a “last modified” timestamp recording the change. This is also true for a lot of web content.

When your browser requests a page online, it sends an HTTP request and the server’s response includes a set of HTTP headers, with extra information alongside the web content itself. This often includes a Last-Modified header, a time and date stamp recording when the content was last changed on the server. The Last-Modified header is used by web systems to detect whether something has changed since it was last fetched (e.g. for caching and archiving), but it is useful evidence of modification or publication date.

A response containing one looks like this:

Last-Modified: Tue, 15 Oct 2024 09:32:00 GMT

It isn’t always reliable and there are lots of reasons that a webpage’s date might show as more recent than it in fact is. Some servers set it accurately, others might be generating content dynamically at the server and set it to the current date and time; or it might record the last time the server’s cache was refreshed. But it’s a useful point of information, and usually broadly reliable in the same way as other computer timestamp information.

Checking for Last-Modified Timestamps

To view in Chrome:

Go the web page you’re interested in.
Press F12, opening the developer tools console. This allows viewing the normally-hidden metadata.
Choose the “Network” tab in the console.
Refresh the page (pressing F5), so the console can record the request and response traffic.
There will often be several files loaded (the web page itself; images; scripts etc): click on the one you’re interested in.
Look for the Last-Modified header.

Here’s an example for http://landley.net/history/mirror/collate/aa080499b.htm, which shows that the page was last-modified Tue, 28 May 2002 18:51:09 GMT

![lastmod-0.png]

The Wayback Machine

When the Internet Archive’s Wayback Machine snapshots pages it also preserves the HTTP headers that it saw at the time (i.e. those which accompanied the original response to the Archive, at the time when it retrieved the page in question). This is labelled with X-Archive-Orig- or X-Orig- prefix for example:

X-Archive-Orig-Last-Modified: Tue, 15 Oct 2024 09:32:00 GMT

To find these, load the archived version of the page on web.archive.org, then open DevTools and inspect the response headers as above. Look for any header beginning X-Archive-Orig-. This can help to establish a sequence of edits (or that there were no edits) between snapshot date and the present.

undefined

2026-05-09T00:00:00Z

My side project has been entirely handcoded in the backend, until today. I’ve used Claude Code a great deal for frontend work — I am no web designer — but I’ve tended my backend carefully with my own hands.In fact using my hands is part of the point, being effective rehab while recovering from an injury. Today I decided to break that habit and try adding a feature using Claude to generate all the code edits.

BunTool (git) is for making PDF bundles for use in court and legal settings, and one feature requested by a colleague (who absolutely knows what she is talking about and should be listened to) was the ability to add a custom coversheet. That’s a great test case, because the feature is easy to conceptualise and express, it touches multiple points in the bundle-making pipeline from frontend to output, and because I can hold the logic in my head from beginning to end for checking purposes.

Framework

Also a good chance to test a new (to me) claude.md variant. I heard from a friend today that Forrest Chang’s Karpathy-Inspired Claude Code Guidelines was usefulDescribed as “A single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathy’s observations on LLM coding pitfalls.” I’ve used Claude enough in the past that I think I’ll be able to spot differences, though this is a slightly different exercise., so installed it as a plugin before I got started. This was pretty easy using claude’s inline plugin management commands.

Specifying

I decided to work from a markdown checklist and iterate through the steps one by one, so started by planning out my spec for the feature:

# Adding coversheet checklist

## Backend

- [ ] buntoolconfig.js - add bool option
- [ ] validate cover page function: check file = 1 page or extract first page, return first page
- [ ] Add validation call in buntoolMain.js
- [ ] at 3/11 in buntoolMain.js Creation of TOC entries, page numbers +1 if coversheet
- [ ] at 5/11 buntoolMain.js (generating TOC pages) page number needs to respect toc entries setting if coversheet present (just check carries through)
- [ ] After current step 7/11 buntoolMain.js (add new step before current step 8, after toc is merged), the result of the step7 merge should then be merged again with coversheet
- [ ] the abbreviated justtheeindex flow in buntoolMain.js should merge with coversheet


## frontend

- [ ] Button to add optional coversheet
- [ ] call validate function at point of upload (belt and braces)
- [ ] show selected filename
- [ ] clear/remove button
- [ ] error handling for invalid file
- [ ] submit logic to accommodate coversheet as parameter coversheetFile
- [ ] add mention in tutorial

This is spec’d by reference to the logic flow in my buntoolMain.js main logic flow, but those steps in turn call out to various submodules.

Step by step

Setting Claude to ask-before-edits gave me peace of mind, and then I prompted it to follow stepwise ("ok let’s do the coversheet adding plan step by step. start with step 1: show me your proposed edits"). Baby steps from the interface within VSCode:

Claude politely making edits without fluff

And so it proceeded.

Overall it went very well. There were a few nits and irritations though:

Claude often used variable names which were fine in isolation but which were confusing in their overall context. For example coversheetFile and coversheetPDF were two different but closely connected things, one derived from the other, both the same type. I much preferred names that conveyed the functions - coversheetFile and validatedCoversheet. It would have been annoying to come back to maintain the confusing variables in future.
Without Forrest Chang’s plugin Claude just loved haphazardly deleting my comments. I’m sure that some people would do the same, but I put them there for a reason! I found the plugin helped with this, suppressing unwanted edits.
Although it had no respect for my comments, it seemed to find the logging prints unassailable. They count up stepwise in the main pipeline ("step 4/11" etc), so a sed call or two was needed to update them globally as new pipeline steps were added.Using sed is quite boring. Luckily Claude could also save me all the typing.
In some cases it got the logical flow of steps out of order. That’s fine, this is why I monitor and could correct it. Somewhat sassily it reacted to that by amending my spec to hyperclarify… even after the edit was finished!

So I ended up being quite hands-on and I couldn’t surrender control entirely. Having said that, if I were using Claude for maintaining a lot of this wouldn’t matter a jot.

I let the LLM have the satisfaction of checking things off its list, and it took the opportunity for some sassy backchat.

At one point while testing I found quite a subtle bug with hyperlinking, which took a while to solve because it seemed to be only intermittently reproduciblea sort of Heisenbug, since trying to debug it with my preferred PDF viewers (which give richer control than a browser viewer) led to a different experience.. This was very annoying but I eventually worked out that it was due to relying on undefined behaviour being handled in a certain way. This wasn’t Claude’s fault, but Claude confidently proposed a fix that broke things much more acutely. I fixed it by hand in the end.

Overall?

But I didn’t get the most out of it because I’m apparently very stuffy about edits to my own handcoded work. It wasn’t quite as smooth as I hoped, but that was partly because I was so opinionated about how things should look that I tended to want to micromanage the result anyway. In the frontend I’m perfectly happy to deploy UI features via Claude.