Here are five of the rules published with the LoftLoom sizing calculators, written as small JavaScript functions so you can read and check them. They're rules of thumb, not laws of physics, and a designer may break them on purpose.

1. Chandelier diameter: add the room's sides

Add the room's length and width in feet, and read the result in inches. A 14 × 16 ft room gets a fixture of about 30 inches.

const chandelierForRoom = (lengthFt, widthFt) => lengthFt + widthFt;

Over a dining table the room doesn't matter; the table does. The fixture should be one-half to two-thirds of the table's width.

const chandelierForTable = (tableWidthIn) =>
  [Math.round(tableWidthIn / 2), Math.round((tableWidthIn * 2) / 3)];

chandelierForTable(42); // [21, 28]

2. The biggest dining table a room can take

Everyone at the table needs 36 inches behind them to pull out a chair, on every side. So subtract 72 inches from each room dimension. That's a ceiling, not a target.

const largestTable = (roomLengthFt, roomWidthFt) =>
  [roomLengthFt * 12 - 72, roomWidthFt * 12 - 72];

largestTable(12, 16); // [72, 120] → a 72 × 120 in. footprint at most

Seating is the same idea in the other direction: about 24 inches of table edge per person with standard chairs, and 28 to 30 inches with armchairs.

const seatsAlongEdge = (edgeIn, perPerson = 24) => Math.floor(edgeIn / perPerson);

2 * seatsAlongEdge(96); // 8 along the two long sides of a 96 in. table

3. Art over a sofa: two-thirds to three-quarters

The art, or the whole group of frames, should span about two-thirds to three-quarters of the furniture below it.

const artWidth = (furnitureWidthIn) =>
  [Math.floor((furnitureWidthIn * 2) / 3), Math.floor((furnitureWidthIn * 3) / 4)];

artWidth(84); // [56, 63] for an 84 in. sofa

Rounding down matters here. With Math.round, a 62-inch headboard gives 41 to 47 inches; the published guidance says 41 to 46. Hang it 8 to 10 inches above a sofa back.

4. Will the sofa go through the door?

This is the one that ruins delivery days. Measure the doorway's clear width with the door open. If the sofa's depth or its height, whichever is smaller, is at least 2 inches narrower than the opening, it goes through on its back or side. If not, compare its diagonal depth (top of the back frame to the front of the arm), again with 2 inches to spare.

function sofaFits({ doorIn, depthIn, heightIn, diagonalIn }) {
  const clearance = 2;
  if (Math.min(depthIn, heightIn) + clearance <= doorIn) return "flat";
  if (diagonalIn && diagonalIn + clearance <= doorIn) return "angled";
  return "no";
}

sofaFits({ doorIn: 32, depthIn: 34, heightIn: 30 }); // "flat"

Taking the door off its hinges usually adds about 2 inches, and every doorway on the route counts, not just the front one.

5. Check against a table, not just a formula

Each LoftLoom calculator page also publishes a quick-reference table, and the functions in this post were tested against those rows: room 14 × 16 ft → about 30 in., a 54 in. table → 27 to 36 in., an 11 × 14 ft room → a 60 × 96 in. table at most, and every row of the wall-art table. That's how the rounding bug in rule 3 showed up: one row was off by an inch.

Try them

All nine calculators are free at loftloom.com/tools: rug, chandelier, dining table, coffee table, wall art, lampshade, bar stool height, sofa-through-the-door, and Christmas tree size. Each one shows its working, so you can see which rule produced the number.

Each sale includes the domain, full source code, the backend and 30 days of handover help.

1. 72fm.com ($900)

Browser radio player with 30,000+ live stations, podcasts and radio tools. Premium is sold as one-time PayPal passes; the first one sold in November. About 1,440 human visits a month from search, social and GitHub, and rising.

2. events.lat ($900)

Event discovery for Latin America in English, Spanish and Portuguese. 3,671 upcoming events across 7 countries, 500+ articles, organizer promotion slots and PayPal ticket checkout. About 2,000 search and Facebook visits a month. Pre-revenue.

3. furnifindusa.com ($3,000)

Live Shopify furniture store with 38,547 products dropshipped from a US supplier, so no inventory. $2,305 in net sales over the last 12 months from 10 orders. To be clear, $1,999.99 of that was a single order.

4. loftloom.com ($900)

Furniture brand with a custom React storefront over a 31,728-product catalogue, 197 design guides and 9 sizing calculators. Pre-revenue. Its checkout runs on FurniFindUSA's store, so it's best bought together with #3.

5. wine.equipment ($900)

B2B directory where wineries compare production equipment (156 listings) and request quotes. Pre-revenue, no signed manufacturers yet, one real quote request so far.

6. check.tattoo ($900)

AI tool that scores a tattoo idea and previews it on the body before booking. The full report costs $19 via PayPal. Comes with an MCP server and a CC BY size chart. Pre-revenue.

What I learned

Shipping was the easy part. Distribution is the job, and I spread myself across six products instead of pushing one. If you're good at the part I'm not, one of these could be a cheap head start.

Open to offers on one site or the whole set. Comment here or reach me through my profile and I'll share analytics.

npx -y internet-radio-mcp

The interesting part wasn't the radio. It was realising that every field the server returns goes straight into a language model's context, and that anyone in the world can edit those fields.

The threat is the station name

Radio Browser is community-maintained: anyone can add or edit a station. So a station could be named "Ignore previous instructions and ...". When an assistant asks for jazz stations in Brazil, that name arrives in the tool result next to the real ones. That's indirect prompt injection, and an MCP server is exactly the kind of component that carries it.

You can't make it impossible. You can make it small, visible and boring.

What the server does

One line per field, with nothing hidden. Line breaks and control characters become spaces. Zero-width characters, bidirectional controls, private-use code points, the Unicode "tag" block and other invisible default-ignorable code points are removed. That matters more for an LLM than for a person: those characters can carry text a human reviewer never sees. The exceptions are the emoji selector and the zero-width joiners that real scripts need, and even those survive only in runs of two.

Length caps. Names are cut at 120 characters, tags at 40, other fields at 60. A long "name" is the easiest place to hide a paragraph of instructions.

Only real URLs. stream_url, homepage and favicon must be plain http or https, written out in full, with no credentials or backslashes. javascript:, data:, file:, https:host and bare words are dropped, and URLs are returned in their parsed, canonical form. A station without a valid id or a playable stream is left out entirely.

Say it out loud. The server instructions and every result state that these fields are data from a public directory, not instructions. That doesn't stop a determined model from following text, but it gives the client's model the right frame.

Read-only by design. Every tool is annotated readOnlyHint: true and openWorldHint: true. There's nothing to write, delete or spend, so the worst a poisoned name can do is mislead, not act.

Results that are easy to check

Each tool result carries three things: a one-line human summary, the same data as JSON text, and structuredContent that matches the tool's outputSchema. Clients that understand structured output get typed data; the rest still get readable text. Inputs are bounded too: limit is 1 to 50 for searches, country codes are ISO 3166-1 alpha-2, and order is an enum.

Fail loudly, keep running

The server tries three Radio Browser mirrors in order, each with an 8-second timeout. Replies are capped at 5 MB and must be a JSON list; a mirror that redirects or returns something else counts as failed. If all three fail, the tool returns a clear isError: true result instead of crashing the server or inventing an answer.

Try it

In Claude Code:

claude mcp add internet-radio -- npx -y internet-radio-mcp

Then ask something like "find jazz stations in Brazil" or "what's trending on internet radio right now?". The README has configs for Claude Desktop, Cursor, VS Code, Gemini CLI and Docker, and the server is in the official MCP Registry as io.github.AlonDrilich/internet-radio-mcp.

It's MIT-licensed, plain ES modules with JSDoc types, and depends only on the official MCP TypeScript SDK and zod. If you build an MCP server over any public, editable data set, the same list applies: one line per field, nothing invisible, capped lengths, canonical URLs, read-only tools, and a clear statement that the data is data.

It's on GitHub as CSV under CC BY 4.0: AlonDrilich/depot-strength-programs (DOI 10.5281/zenodo.24082645). The programs follow documented templates such as 5/3/1, 5×5, push/pull/legs and upper/lower.

One caveat up front: this is what one library prescribes, not what people did, and not a sample of all training programs.

A few numbers

• Volume grows with level, but less than you'd think. Median weekly prescribed sets: beginner 47, intermediate 59.5, advanced 67. The whole range is 12 to 130.
• Rest follows the rep range. Median rest is 180 s when the top of the rep range is 5 or fewer, 120 s at 6 to 8, 90 s at 9 to 12, and 60 s at 13 or more.
• Sessions are small. The median session is 5 exercises and 16 sets; 92.1% of sessions have 3 to 6 exercises.
• Three or four days a week. 42 programs train 3 days, 40 train 4, and only 19 ask for 5 or 6.
• Moderate reps dominate. Of 1,565 rep-count prescriptions, 33.4% top out at 9 to 12 reps and 32.9% at 13 to 15. Only 13.0% are in the 1 to 5 range.
• Nobody prescribes RPE or RIR. Progression is free text, and only 10 programs mention a deload or reset.

Load it in a few lines

import pandas as pd

base = "https://raw.githubusercontent.com/AlonDrilich/depot-strength-programs/main/"
programs = pd.read_csv(base + "programs.csv")
exercises = pd.read_csv(base + "exercises.csv")

# Median weekly prescribed sets by level
print(programs.groupby("level")["weekly_prescribed_sets"].median())

# The ten exercises that appear in the most programs
print(exercises.nlargest(10, "programs_using")[["exercise_name", "programs_using"]])

The second query puts back squat and bench press on top, in 56 programs each, followed by barbell row (44), Romanian deadlift and lateral raise (39 each).

The messy part: exercise names

The source is free text, so "Back Squat", "Back Squats", "Barbell Squat" and "Barbell Squats" are the same lift, and so are "Leg Curl" and "Hamstring Curls (Lying)". Names are slugified, run through an alias table (abbreviations expanded, parentheticals dropped, four barbell pairs merged), and a trailing "s" is merged only when the singular also appears. Names that could mean something different, like "Squats" and "Back Squat T1", are left apart rather than guessed. The result is 484 canonical exercises, and exercises.csv lists every spelling that was merged into each one, so you can check or redo it.

Reps are free text too. Each prescription gets a reps_kind (fixed, range, 5/3/1 wave, per-set list, AMRAP, time, interval and so on), and numeric bounds only where they make sense.

What's not in it

• Exercise-by-exercise prescriptions for the other 96 programs. They're counted in the summaries but not released.
• Any mapping from exercises to muscles. The source only has program-level muscle groups.
• Anything about outcomes. It's a description of prescriptions, nothing more.

The charts and the full method are at depot.fitness/data. Corrections are welcome at support@depot.fitness, or as an issue on the repo.

The 9 November build has 51,965 working stations after de-duplication, in 172 country playlists, 60 genre playlists and a top-500 list.

Writing an M3U file is trivial. Writing one from data that anyone can edit takes more care, because an M3U is a tiny program that a player executes: a list of #EXTINF lines and URLs to open. Here is what I had to defend against.

1. A line break in a name is a new entry

An entry is two lines:

#EXTINF:-1,Station name
https://stream.example/live

If a station's name contains a newline followed by a URL, the "name" becomes an extra playlist entry pointing wherever the author likes. So names lose every line-breaking character: C0 and C1 controls, plus U+2028 and U+2029, which many tools forget.

const LINE_BREAKING = /[\u0000-\u001f\u007f-\u009f\u2028\u2029]/g;
const name = raw.replace(LINE_BREAKING, " ");

2. Commas and quotes in the #EXTINF line

Several players split #EXTINF on the first comma to find the title, and attributes such as tvg-logo="..." sit before that comma. A name like X tvg-logo="http://..." would smuggle in an attribute. Titles lose double quotes, and attribute values lose quotes and commas.

3. Text you can't see

Bidi overrides (U+202E and friends) can make a name display differently from what it says. Zero-width characters and the Unicode "tag" block can hide text altogether. Those are stripped. The exceptions are ZWJ, ZWNJ and the emoji variation selector, because Persian, Indic scripts and emoji need them, and even those are capped at runs of two.

4. URLs that point into your network

A public playlist shouldn't make someone's player, or their Home Assistant box, connect to 192.168.1.1. Stream URLs are kept only if they are plain public http(s) addresses:

• no username or password in the URL
• no localhost, .local, .lan, .internal, or bare hostnames that only resolve on a LAN
• no private, loopback, link-local or CGNAT IPv4 ranges (10/8, 127/8, 169.254/16, 172.16/12, 192.168/16, 100.64/10), and the IPv6 equivalents
• no backslashes, which new URL() and curl read differently, and no https:host without slashes

One detail matters more than it looks. The build writes new URL(value).href, the parsed and canonical form, so the string that was checked is exactly the string that ends up in the file.

5. Check the output, not just the input

Before each file is written, the build parses the text it just generated and throws if the structure isn't exactly what it meant to produce: the #EXTM3U header, every #EXTINF followed by one URL, no URL without an #EXTINF, attributes in the expected form, no control characters anywhere, and the expected number of entries. If a hostile entry ever gets past the sanitising, the weekly update stops instead of publishing it.

There's also a guard against the source shrinking. If the directory suddenly returns far fewer stations than last week, for example during an outage, the build refuses to replace the old playlists with near-empty ones.

Using the playlists

Open any of them straight from GitHub, for example jazz:

mpv https://raw.githubusercontent.com/AlonDrilich/radio-playlists/main/genres/jazz.m3u

index.json lists every playlist with its URL and station count, if you'd rather pick one in code. The same weekly build also writes per-country station lists for Euro Truck Simulator 2 and American Truck Simulator, Farming Simulator, and Garry's Mod.

The station data is public domain (Radio Browser), and the playlists are CC0. The streams themselves belong to their stations. If you'd rather not deal with files, the same directory plays in the browser at 72fm.com.

The bug is almost never in your click handling. It comes from two coordinate systems that agree on ordinary pages and disagree on the ones that come from scanners.

Two coordinate systems

What pdf-lib draws in. page.drawImage() and friends work in the page's raw user space. The origin is at the bottom-left of the MediaBox, y points up, and the page's /Rotate entry is ignored.

What the user sees. A viewer, pdf.js included, shows the CropBox (the visible part of the page), turned by /Rotate, with the origin at the top-left and y pointing down.

On a plain portrait page with no crop, the difference is a y-flip:

const userY = page.getHeight() - viewY;

That's the line most tutorials give you. It's correct until one of these shows up:

• /Rotate 90 (or 180, 270). Scanners often store a landscape page as portrait pixels plus a rotate flag. The viewer turns it. pdf-lib doesn't, so your x and y axes are swapped, and the image is drawn rotated relative to what the user saw.
• A CropBox smaller than the MediaBox. The viewer shows only the crop. Your click coordinates are relative to the crop's corner, but pdf-lib measures from the MediaBox corner, so everything is shifted.
• Both at once. That's common in real scanned contracts.

The mapping

For a point in view space (points, top-left origin, y down) on a page whose visible box starts at (bx, by) and is bw × bh points:

The displayed width and height also swap for 90 and 270. Drawing an image upright means passing the matching rotation to pdf-lib, and accounting for the fact that pdf-lib rotates around the image's own origin, not its centre. That last part is where most hand-rolled fixes break.

One more edge case: pdf.js treats a /Rotate value that isn't a multiple of 90 as 0. Do the same, or your output won't match what the user saw.

A small library for it

I pulled this logic into pdf-view-coords, a small MIT TypeScript helper for pdf-lib. You stay in view space, and it does the translation:

import { PDFDocument } from "pdf-lib";
import { viewport, drawImageInView, rectFromFractions } from "pdf-view-coords";

const pdf = await PDFDocument.load(bytes);
const page = pdf.getPage(0);
const png = await pdf.embedPng(signaturePng);

// The box the user drew, as fractions of the rendered page size.
const vp = viewport(page);
const rect = rectFromFractions(vp, { x: 0.1, y: 0.8, width: 0.3, height: 0.08 });

drawImageInView(page, png, rect); // right place, upright, aspect ratio kept

viewport(page) also gives you toUser(x, y) and toView(x, y) if you'd rather draw yourself. The tests check every rotation, with and without a crop, and confirm that the area pdf-lib actually paints matches the view-space rectangle you asked for.

The live demo runs in the browser. Load your own PDF, click on a rotated page, and compare where plain pdf-lib puts the box with where the library puts it.

Install it from GitHub for now:

npm install github:AlonDrilich/pdf-view-coords pdf-lib

If you've hit a PDF where it still lands wrong, open an issue with the file. Odd real-world PDFs are exactly what it needs to be tested against.

Nothing went wrong. Many extensions are priced this way on purpose: a low first year to get the registration, and the real price from year two. The renewal price is published, but checkout pages put the first-year price front and centre.

How big the gap is

I keep a weekly snapshot of one registrar's public list prices (Porkbun) for 532 extensions. In the snapshot from 9 November 2026:

• 309 of the 532 extensions renew at 2× their first-year price or more.
• 188 renew at 5× or more.

The first year tells you little about what a name costs to keep. Here are five years of ownership (first year plus four renewals) for some extensions developers often buy:

.online costs less than .com in year one and about twice as much over five years. .ai is expensive from day one, but at least it doesn't change.

These are one registrar's list prices on one date, in USD. Other registrars price differently, and promotions change often, so treat the table as a reason to check rather than as a quote.

Check it yourself in a few lines

Porkbun publishes its prices at an endpoint that needs no API key. This prints the extensions whose renewal is at least five times the first year:

const res = await fetch("https://api.porkbun.com/api/json/v3/pricing/get", {
  method: "POST",
  headers: { "content-type": "application/json" },
  body: "{}",
});
const { pricing } = await res.json();

const rows = Object.entries(pricing)
  .map(([tld, p]) => ({
    tld,
    first: Number(p.registration),
    renewal: Number(p.renewal),
  }))
  .filter((r) => r.first > 0 && r.renewal / r.first >= 5)
  .sort((a, b) => b.renewal / b.first - a.renewal / a.first);

console.table(rows.slice(0, 20));

It runs in Node 18+ (save it as an .mjs file) or in the browser console.

Before you register

1. Look for the renewal price, not just the first-year price. Most registrars list both on their pricing page.
2. Multiply it out over the years you expect to keep the name.
3. If you're choosing between two extensions, compare the renewals. The cheaper first year often turns out to be the dearer domain.

The full table for all 532 extensions, updated weekly, is on GitHub as CSV under CC BY 4.0: AlonDrilich/tld-renewal-prices (DOI 10.5281/zenodo.24082643). There's also a sortable version at namesale.store/renewal-prices.

Not affiliated with Porkbun. Its endpoint is simply the easiest public source to snapshot.