Paulus Esterhazy pesterhazy

Google doesn't make it easy for users to download a stable build of Chromium. If you just download the latest version, fine, but you might be getting an unstable version in between releases. I want a stable Chromium!

After years of trying, this is the process I've settled on - on macOS ARM:

Find the build number you want to get. For me, that was 1056772. I found it by browsing Puppetteer. Yes you read that right. I found it in the release notes
Go to https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Mac_Arm/1056772/ - but set the last segment of the path to the build number you picked.
Download the app and put it in /Applications/Chromium.app
If you get an error saying that the file is damaged, run xattr -cr /Applications/Chromium.app to remove the quarantaine attribute
open /Applications/Chromium.app

John McPhee famously considered a dictionary his secret weapon. What's your secret weapon?

If like me you're not a native speaker of English, you've probably used bilingual dictionaries to learn about English words. But at a certain level of proficiency, you almost certainly want to use a monolingual dictionary instead. You want to look up words the way a native speaker would.

Here are some of my favorites:

This is the best material I know out there on Automated Testing with Microtests (aka Unit Tests aka TDD style tests).

Monographs

Test Driven Development By Example (Kent Beck)

Unit Testing: Principles, Practices, and Patterns (Vladimir Khorikov)

The Art of Unit Testing 2nd ed (Roy Osherove)

This gist is for anyone who's trying to use emacs + eglot + monorepo (with Clojure or any other language).

When you open a file in a buffer, eglot needs to determine the scope or folder to run the language server in. By default, the folder eglot will pick as the assumed project root is the repo root (the ancestory directory containing .git).

But in a monorepo, that's rarely what you want. In a large repo, analyzing all the *.clj files with clojure-lsp could take a minute or longer. As a limiting case, imagine Google with its gargantuan monorepo. Analyzing all the source files would take an indefinite period of time.

So you want to write a sync system for a web app with offline and realtime support? Good luck. You might find the following resources useful.

Overview articles

Database in a browser, a spec (Stepan Parunashvili)

What problem are we trying to solve with a sync system?
The web of tomorrow (Nikita Prokopov)

It's often desirable to print articles or blog posts to PDF for easier reading. In fact you're almost always better off reading a cleaned-up printout than a noisy HTML page on a backlit screen.

Printing the web without all the noise

Why?

Offline reading has fewer distractions; you can mark up the article with your own notes; and it's easier on the eyes. Active reading, underlinding and annotating improves comprehension and retention. If you read on the reMarkable tablet, as I do, then you don't to print to actual paper and save trees.

If an article is worth reading, it's worth printing and reading with a pen in your hand.

I often want to read Markdown documentation on Github — or proof-read my own documents — without staring at a backlit screen. Here's an easy way to print the files in a readable format.

Create a bookmarklet with the following code and give it the name "github print"

javascript:void function(){b=document.body,c=document.querySelector("article"),b.innerHTML="",b.appendChild(c)}();

Go to the markdown view on Github of the file you want to print, e.g. Ripgrep's user guide
Click on the bookmarklet. Alternatively (in Chrome) type "github print" in the search bar, select the bookmarklet code with cursor keys if necessary and press enter.
Use the browser print feature to print the document, to a physical printer or (to save paper) to PDF on a reMarkable eInk tablet.

This gist collects publications by GeePaw Hill around the topic of Incrementalism in Software Development - the advice to "take many more, much smaller steps."

Where to start

The good entry point into the discussion is a pair of 2020 muses: The RAT: Rework Avoidance Theory and Understanding Incremental Switchover

Muses

Later muses are also published as podcast episodes.

	#!/usr/bin/env bash
	#
	# When using "git push", I frequently find myself overlooking git's
	# dreaded 'Updates were rejected because the remote contains work that
	# you do not have locally' error message.
	#
	# After I push, I don't typically wait around for the command to
	# complete. So while I _think_ that my changes have been pushed to
	# remote branch, in fact the push wasn't successful. Because the
	# branch has changed in the meantime, I need to `git pull --merge` to

	import * as assert from "node:assert/strict";

	function splitLinesWithEols(str) {
	let r=/((?!(\n\|\r\n)).)*(\n\|\r\n)/y;
	let m;
	let last = 0;
	let result = [];

	while ( (m=r.exec(str)) ) {
	result.push(m[0]);