Rasmus Schultz mindplay-dk

Unit tests are fast to run - but they are usually expensive to write and maintain. They are also typically full of mocks and stubs, which means the tests are tightly coupled to implementation details - which makes them high maintenance. Basically, any time something changes around a unit, the unit test needs to be updated with the mocks and stubs they interact with.

After 40 years of coding, my own testing strategy is much simpler: I use unit tests only as a stepping stone to prove the smallest units work before I build whatever is at the next layer above that unit. As soon as the next layer is in place, I write a test that covers the inner workings of the units below it - usually, that test is much simpler, and then I simply delete the complex unit tests with all of their mocks and scaffolding, and check my code coverage.

If you can get the same coverage with fewer lines of code from a higher layer, testing the same outcomes, as opposed to testing meaningless implementation details ("does it call this func

This issue has been bothering me since I started using Figma a few years ago:

The rendered px units in Figma are about 8% smaller than they are in Chromium-based browsers.

In other words, when developers copy px values from Figma and implement them on the web, the rendered results are around 10% larger than the design.

This is a really serious issue, especially when selecting very small font sizes - for example, there is a considerable difference when a font is rendered at 10px, 11px and 12px, and designers are very careful when selecting small font sizes.

And just in general, you design for a specific experience, especially when creating fluid web page designs - a 10% difference is a huge perceived difference on a large page, and it just gives the design a different feel and experience versus what you actually designed.

Tak Rules

1. Starting Play

1.1. Board Setup

The board must be square: standard sizes are 3×3, 4×4, 5×5, 6×6, 7x7, or 8×8.
The board starts empty.
Players each have a supply of stones and capstones based on board size:

These are my GNOME extension settings to make the Ubuntu desktop work mostly like Windows 8/10 used to work:

Bottom taskbar - Shows running applications with window previews (Dash to Panel)
Start menu - Traditional hierarchical application launcher accessed via menu button (ArcMenu)
Window snapping - Snap windows to predefined layouts by holding CTRL (Tiling Shell)
Emoji picker - Quick emoji insertion panel similar to Windows: WIN + . (Emoji Copy)
Desktop icons - I've turned them off because my Desktop is always a mess - save things in Documents instead.
Taskbar window previews - I've turned them off because they're annoying.
Application indicators - I've removed them because they're distracting.

between the most popular frontend frameworks (React, Svelte and Solid in particular) what are the features a modern frontend framework must have to be considered a serious option? focus on frontend frameworks with fine grained reactivity. ignore features like server side rendering and server components and focus on frontend features. identify features and requirements that are handled differently in each framework and focus on the problems they solve.

To be considered a serious modern frontend framework with fine-grained reactivity, the following features and capabilities are essential. These features address core challenges like efficient DOM updates, state synchronization, and developer ergonomics. Below is a breakdown of these requirements and how React, Svelte, and Solid handle them differently:

1. Fine-Grained Reactivity System

A framework must track dependencies at the most granular level (e.g., individual variables or DOM nodes) to update only what changes, avoiding

Claude.ai just helped me make a whole lot more sense of the absolute mess that is BNF-family syntaxes. 🤔

I just discovered ABNF is actually a standard, RFC 4234.

Why isn't this more widely used?

BNF in the wild drives me nuts - no two grammars are ever written in the same flavor of BNF, and often grammars are published as merely "BFN" neglecting to even specify which BNF variant was used.

Are there any other BNF variants that are properly standardized?

	# Block everything in search results except actual results & videos:
	www.google.com###search div>div[data-rpos]:not(:has([data-snf])):not(:has([data-vurl])):not(:has(h3>a.l)):not(:has([jscontroller]):has([data-maindata*="currency"]))

	# AI overview:
	www.google.com##[data-mcpr]

	# Junk below search results:
	www.google.com###bres

	# Junk in right-hand column:

	#!/bin/bash
	set -euo pipefail

	$REPO_DIR=~/devel
	repos="1password bitwarden dashlane lastpass opvault passwordbox roboform stickypassword truekey zoho-vault"

	# pull all repos
	(
	for repo in $repos; do
	echo $repo

	const DANISH = {
	"Hello {{name}}!": "Hej {{name}}",
	"Welcome to the world": "Velkommen til Verden",
	"You have {{amount}} {{cookies}}": "Du har {{amount}} {{cookies}}",
	"cookie": "kage",
	"cookies": "kager",
	"Missing translation": "Manglende oversættelse",
	}

	type TranslationKey = keyof typeof DANISH

	const fs = require('fs');
	const path = require('path');
	const TurndownService = require('turndown');

	// Directories
	const inputDir = path.join(__dirname, 'html');
	const outputDir = path.join(__dirname, 'markdown');

	// Initialize Turndown
	const turndownService = new TurndownService({