DEV Community: Akbo Ichou

1 porcja, 2 porcje, 5 porcji: Scaling Recipes and Handling Polish Plurals With Intl.PluralRules

Akbo Ichou — Fri, 25 Sep 2026 20:56:16 +0000

A "servings" slider looks like the easiest feature on a recipe site: multiply every quantity by a factor. Then you ship it in Polish and discover two things — scaling has real-world edge cases, and Polish has three plural forms for counted nouns (plus one for fractions).

Kuchnia Przepisy is a Polish recipe site covering dinners, cakes (serniki, szarlotki, no-bake cakes), soups, and modern categories like air fryer, Thermomix/Lidlomix and high-protein recipes. Here's how to scale recipes properly and label them correctly in Polish.

Store quantities as numbers, not strings

"2 szklanki mąki" can't be scaled. Store structure, render text:

interface Ingredient {
  qty: number | null;       // null for "sól do smaku" (salt to taste)
  unit: "g" | "ml" | "szt" | "łyżka" | "łyżeczka" | "szklanka" | null;
  name: string;             // "mąka pszenna"
  scalable?: boolean;       // false for e.g. "1 blacha" or a pinch
}

Scale — then round to something a person can measure

Multiplying 3 eggs by 1.5 gives 4.5 eggs. Nobody measures 4.5 eggs, or 187.5 g of flour to the gram. Round by unit:

function roundFor(unit: Ingredient["unit"], x: number) {
  switch (unit) {
    case "szt": return Math.max(1, Math.round(x));      // whole items (eggs)
    case "g": case "ml": return x < 50 ? Math.round(x) : Math.round(x / 5) * 5;
    case "łyżka": case "łyżeczka": case "szklanka": return Math.round(x * 4) / 4; // quarters
    default: return x;
  }
}

export function scale(list: Ingredient[], from: number, to: number) {
  const f = to / from;
  return list.map((i) =>
    i.qty == null || i.scalable === false ? i : { ...i, qty: roundFor(i.unit, i.qty * f) }
  );
}

Baking scales by pan area, not servings

Many cakes are written for a baking tray ("12 porcji z blachy") or a round tin. Doubling servings doesn't mean doubling the tin — scale by area:

const rectArea = (w: number, h: number) => w * h;
const roundArea = (d: number) => Math.PI * (d / 2) ** 2;

// 24 cm round tin -> 26 cm round tin
const factor = roundArea(26) / roundArea(24); // ≈ 1.17

Baking time doesn't scale linearly, so the UI suggests checking earlier or later instead of recalculating it.

Polish plurals: one, few, many — and other

English has "1 serving / 2 servings". Polish uses different forms depending on the number:

1 → porcja
2–4, 22–24, 32–34… → porcje
0, 5–21, 25–31… → porcji
fractions (1,5) → porcji

Don't hand-code the rules — Intl.PluralRules already knows them:

const pr = new Intl.PluralRules("pl-PL");

const PORCJA: Record<Intl.LDMLPluralRule, string> = {
  one: "porcja", few: "porcje", many: "porcji", other: "porcji",
  zero: "porcji", two: "porcje",
};

export const porcje = (n: number) =>
  `${new Intl.NumberFormat("pl-PL").format(n)} ${PORCJA[pr.select(n)]}`;

porcje(1);   // "1 porcja"
porcje(3);   // "3 porcje"
porcje(12);  // "12 porcji"
porcje(22);  // "22 porcje"
porcje(1.5); // "1,5 porcji"

The same approach works for minutes ("1 minuta", "2 minuty", "5 minut") and pieces ("1 jajko", "2 jajka", "5 jajek").

Categories as a tree

The navigation mirrors how Polish home cooks search: top-level groups like Obiad, Ciasta, Zupy and Nowoczesna, with focused subcategories (quick dinners, chicken dishes, one-pot meals, cream soups, air fryer). A recipe can live in several subcategories, so it's a tag set with a primary category for breadcrumbs and URLs — not a strict tree.

Takeaways

Store quantities as structured data so they can be scaled.
Round scaled amounts to measurable units; keep eggs whole.
Scale baking by pan area.
Use Intl.PluralRules for languages with complex plurals.

Browse the recipes at kuchnia-przepisy.pl (in Polish). Which language gave you the most trouble with pluralization?

Searching 10,000 Printable Pages Without a Search Server: A Prebuilt Index, Synonyms and Kid-Friendly Typos

Akbo Ichou — Fri, 25 Sep 2026 20:51:41 +0000

When a site grows past a few hundred pages, category browsing stops being enough. People want to type "t rex" or "unicorn easy" and get results instantly. The usual answer is a hosted search service — but for a static content site, you often don't need one.

The Coloring Companion is a library of 10,000+ free printable coloring pages — high-contrast black-and-white line art for toddlers, kids, teachers and adults, grouped into categories like animals, dinosaurs, holidays, flags, educational and easy pages. Here's the approach to fast, serverless search over a catalog that size.

1. Build a compact index at build time

The browser doesn't need page bodies to search — just titles, categories, tags and difficulty. Emit a small JSON index during the build:

interface Entry {
  id: number;
  slug: string;
  title: string;          // "Friendly T-Rex"
  cats: string[];         // ["dinosaurs", "kids"]
  tags: string[];         // ["t-rex", "tyrannosaurus", "dino"]
  level: "easy" | "medium" | "detailed";
}

With short keys and gzip, 10,000 entries fit comfortably in a single lazily-loaded file. It's only fetched when someone focuses the search box.

2. Normalize queries the way people actually type

Search input on a coloring site comes from parents on phones and kids typing their own queries. Normalization does a lot of heavy lifting:

const SYNONYMS: Record<string, string> = {
  trex: "t-rex", "t rex": "t-rex", dino: "dinosaur", dinos: "dinosaur",
  xmas: "christmas", kitty: "cat", puppy: "dog", unicorns: "unicorn",
};

export function normalize(q: string): string[] {
  let s = q.toLowerCase().trim().replace(/[^a-z0-9\s-]/g, " ");
  for (const [k, v] of Object.entries(SYNONYMS)) s = s.replace(new RegExp(`\\b${k}\\b`, "g"), v);
  return s.split(/\s+/).filter((t) => t && !["coloring", "page", "pages", "free", "printable"].includes(t));
}

Stripping words like "coloring" and "printable" matters: nearly every query contains them, and they match everything.

3. Treat difficulty as a filter, not a keyword

"Easy" in a query is almost always a filter intent. Pull it out before matching:

const LEVELS = ["easy", "medium", "detailed"] as const;

function extractLevel(tokens: string[]) {
  const level = tokens.find((t) => (LEVELS as readonly string[]).includes(t));
  return { level, rest: tokens.filter((t) => t !== level) };
}

4. Score with simple weights

A small scoring function beats a heavy library for this use case. Title matches outrank tag matches, which outrank category matches, with prefix matching for as-you-type results:

function score(e: Entry, tokens: string[]): number {
  let s = 0;
  for (const t of tokens) {
    if (e.title.toLowerCase().includes(t)) s += 5;
    if (e.tags.some((x) => x.startsWith(t))) s += 3;
    if (e.cats.some((x) => x.startsWith(t))) s += 1;
  }
  return s;
}

export function search(index: Entry[], q: string, limit = 48) {
  const { level, rest } = extractLevel(normalize(q));
  return index
    .filter((e) => !level || e.level === level)
    .map((e) => ({ e, s: score(e, rest) }))
    .filter((x) => x.s > 0 || rest.length === 0)
    .sort((a, b) => b.s - a.s)
    .slice(0, limit)
    .map((x) => x.e);
}

5. Tolerate small typos

Kids misspell. A cheap edit-distance check on tokens that don't match anything catches "dinasour" and "unicron" without a fuzzy-search dependency:

function within1(a: string, b: string) {
  if (Math.abs(a.length - b.length) > 1) return false;
  let i = 0, j = 0, edits = 0;
  while (i < a.length && j < b.length) {
    if (a[i] === b[j]) { i++; j++; continue; }
    if (++edits > 1) return false;
    if (a.length > b.length) i++; else if (b.length > a.length) j++; else { i++; j++; }
  }
  return edits + (a.length - i) + (b.length - j) <= 1;
}

6. Popular searches as a safety net

Show a handful of popular searches (dinosaurs, T-Rex, Halloween, Christmas, mandalas, flags) under the box. Many visitors click one instead of typing — and it doubles as internal linking.

Takeaways

A prebuilt JSON index handles thousands of pages without a search server.
Normalize for how people type: synonyms, stopwords, filters.
Simple weighted scoring is fast and easy to tune.
Add lightweight typo tolerance for young users.

Find a page to print at thecoloringcompanion.com. How do you handle search on static sites?

Points to Grades: Building a German Grading Scale (Notenschlüssel) Calculator With Half-Point Precision

Akbo Ichou — Fri, 25 Sep 2026 20:48:29 +0000

German schools grade on a 1–6 scale (1 = sehr gut, 6 = ungenügend), but tests are scored in points. The mapping between the two is called a Notenschlüssel (grading key), and teachers build one for almost every exam — often by hand in a spreadsheet.

Notenschlüsselrechner is a free, no-login tool that does this: enter the maximum points, choose a linear key for school or the IHK scale for vocational training, and get the full table, a grade distribution (Notenspiegel) and export. There's a teacher mode and a student mode. The logic is small, but the details matter — here's how it works.

Keys are just thresholds

Every grading key is a list of minimum percentages per grade. Model it as data:

type Grade = 1 | 2 | 3 | 4 | 5 | 6;
type Key = { grade: Grade; minPct: number }[]; // sorted from best to worst

// IHK 100-point scale, common in German vocational training
export const IHK: Key = [
  { grade: 1, minPct: 92 },
  { grade: 2, minPct: 81 },
  { grade: 3, minPct: 67 },
  { grade: 4, minPct: 50 },
  { grade: 5, minPct: 30 },
  { grade: 6, minPct: 0 },
];

A linear key from one decision

For a linear school key, the teacher usually decides one thing: the pass mark (the percentage needed for a 4). The remaining grades are spaced evenly between that and 100%:

export function linearKey(passPct = 50): Key {
  const step = (100 - passPct) / 4;           // grades 1–4 share the top band
  const top: Key = [1, 2, 3, 4].map((g, i) => ({
    grade: g as Grade,
    minPct: +(100 - step * (i + 1)).toFixed(2),
  }));
  return [...top, { grade: 5, minPct: passPct / 2 }, { grade: 6, minPct: 0 }];
}

With a 50% pass mark that gives 87.5 / 75 / 62.5 / 50 / 25 / 0. Schools differ, which is exactly why the thresholds are data rather than hardcoded logic.

Half points and rounding

Tests are often scored in half points, and the boundary rule matters: a teacher expects "you need 34.5 of 37 points for a 1", not "34.04". Convert percentages to point thresholds and round up to the next half point, so nobody gets a better grade than the key allows:

const ceilHalf = (x: number) => Math.ceil(x * 2) / 2;

export function pointTable(maxPoints: number, key: Key) {
  return key.map(({ grade, minPct }, i) => {
    const from = ceilHalf((minPct / 100) * maxPoints);
    const to = i === 0 ? maxPoints : ceilHalf((key[i - 1].minPct / 100) * maxPoints) - 0.5;
    return { grade, from, to };
  });
}

For 50 points on the IHK scale, a 1 starts at 46 points (92% of 50).

Looking up a grade

export function gradeFor(points: number, maxPoints: number, key: Key): Grade {
  const pct = (points / maxPoints) * 100;
  return key.find((k) => pct >= k.minPct)!.grade;
}

Test the boundaries explicitly — exactly on the threshold, half a point below, zero, and full marks.

The Notenspiegel

Once you have grades, the class distribution and average are one reduce away:

export function notenspiegel(grades: Grade[]) {
  const counts = [1, 2, 3, 4, 5, 6].map((g) => grades.filter((x) => x === g).length);
  const avg = grades.reduce((a, b) => a + b, 0) / grades.length;
  return { counts, average: +avg.toFixed(2) };
}

Formatting for Germany

Decimal commas matter: a class average is "2,43", not "2.43". Use Intl.NumberFormat("de-DE") everywhere numbers are displayed or exported.

Takeaways

Represent grading keys as threshold data.
Derive linear keys from the one decision teachers actually make.
Round point thresholds up to the next half point.
Test boundaries, and format numbers for the locale.

Try it at notenschluesselrechner.de (in German). Have you built grading tools for other school systems?

Recipe Structured Data Done Right: JSON-LD, ISO 8601 Durations and German Locale Gotchas

Akbo Ichou — Fri, 25 Sep 2026 20:45:04 +0000

Recipe sites live and die by rich results — the cards in search that show cook time, a photo and ingredients. Those come from Recipe structured data, and it's surprisingly easy to get subtly wrong, especially on a non-English site.

Beste Airfryer Rezepte is a German recipe site for air fryer (Heißluftfritteuse) and Thermomix recipes — chicken thighs, fries, salmon, schnitzel, goulash, risotto and more. Here's how to generate valid Recipe JSON-LD from one source of truth, plus the locale issues that bit me.

One recipe object, many outputs

Keep a single typed record per recipe and derive both the visible page and the structured data from it. That way they can't drift apart:

interface Recipe {
  slug: string;
  name: string;                 // "Hähnchenschenkel im Airfryer"
  description: string;
  image: string[];
  prepMinutes: number;
  cookMinutes: number;
  servings: number;
  device: "airfryer" | "thermomix";
  tempC?: number;
  ingredients: string[];        // human-readable, already localized
  steps: { name?: string; text: string }[];
  category: string;             // "Hauptgericht"
  cuisine?: string;             // "Deutsch"
}

Durations must be ISO 8601

prepTime, cookTime and totalTime aren't "40 Min." — they're ISO 8601 durations like PT40M. A tiny helper avoids hand-written strings:

export function isoDuration(minutes: number): string {
  const h = Math.floor(minutes / 60), m = minutes % 60;
  return `PT${h ? `${h}H` : ""}${m || !h ? `${m}M` : ""}`;
}

isoDuration(35);  // "PT35M"
isoDuration(90);  // "PT1H30M"

Generating the JSON-LD

export function recipeJsonLd(r: Recipe, url: string) {
  return {
    "@context": "https://schema.org",
    "@type": "Recipe",
    name: r.name,
    description: r.description,
    image: r.image,
    inLanguage: "de-DE",
    prepTime: isoDuration(r.prepMinutes),
    cookTime: isoDuration(r.cookMinutes),
    totalTime: isoDuration(r.prepMinutes + r.cookMinutes),
    recipeYield: `${r.servings} Portionen`,
    recipeCategory: r.category,
    recipeCuisine: r.cuisine,
    recipeIngredient: r.ingredients,
    recipeInstructions: r.steps.map((s, i) => ({
      "@type": "HowToStep",
      position: i + 1,
      name: s.name,
      text: s.text,
      url: `${url}#schritt-${i + 1}`,
    })),
    tool: r.device === "airfryer" ? "Heißluftfritteuse" : "Thermomix",
  };
}

Render it in a <script type="application/ld+json"> tag, serialized with JSON.stringify — never string-concatenated, or a quote in a recipe name will break the whole block.

German locale gotchas

Decimal commas. "1,5 EL Öl" is correct German. Keep ingredient strings localized for display, but store quantities as numbers if you ever scale recipes, and format with Intl.NumberFormat("de-DE").
Umlauts and ß in slugs. Decide once how to transliterate: hähnchenschenkel → haehnchenschenkel, groß → gross. Inconsistent slugs create duplicate URLs.
Units. EL/TL (tablespoon/teaspoon), g, ml and °C — no cups or °F. Mixing them in confuses readers and search engines alike.

const slugify = (s: string) =>
  s.toLowerCase()
   .replace(/ä/g, "ae").replace(/ö/g, "oe").replace(/ü/g, "ue").replace(/ß/g, "ss")
   .replace(/[^a-z0-9]+/g, "-").replace(/^-|-$/g, "");

Air fryer specifics belong in the content

Air fryer recipes depend heavily on temperature, basket loading and when to shake or flip. Those details go into the step text (and name for each step), so they show up both on the page and in structured data — e.g. "Nach 10 Minuten wenden".

Validate in CI

Run every generated recipe through a schema check in CI, so a missing image or malformed duration fails the build instead of silently losing rich results.

Takeaways

Generate JSON-LD from the same record as the page.
Use ISO 8601 durations and JSON.stringify.
Handle decimal commas, umlauts and metric units deliberately.
Validate structured data automatically.

Find the recipes at beste-airfryer-rezepte.de. Have you run into structured-data issues on non-English sites?

Photo In, Macros Out: Designing an AI Meal Analyzer Where the LLM Never Does the Math

Akbo Ichou — Fri, 25 Sep 2026 20:41:29 +0000

"Take a photo of your plate and get calories" is one of the most requested AI features in nutrition apps — and one of the easiest to get wrong. Ask a vision model "how many calories are in this?" and you'll get a confident number that changes each time you ask.

Protealpes has 56 free nutrition tools — calorie, protein, macro, walking and steps-to-calories calculators — plus an AI Meal Analyzer that accepts a photo, a text description, or both. The design rule across all of them: formulas stay visible, and AI doesn't invent the math. Here's the pipeline.

Step 1: The model only identifies items

The AI's job is narrow: split a meal into editable items with estimated amounts. Nothing else. Ask for structured output with a schema so you can validate it:

import { z } from "zod";

const MealItems = z.object({
  items: z.array(z.object({
    name: z.string(),                 // "boiled white rice"
    grams: z.number().positive(),     // estimated portion
    confidence: z.enum(["low", "medium", "high"]),
  })).max(20),
});

type MealItems = z.infer<typeof MealItems>;

async function identify(photo?: Blob, text?: string): Promise<MealItems> {
  const raw = await callVisionModel({
    photo, text,
    instruction: "List the foods and estimated grams. Do not estimate calories or macros.",
  });
  return MealItems.parse(raw); // throws if the model drifts from the schema
}

Validation matters: if the output doesn't match the schema, you retry or fall back to text entry — you don't render it.

Step 2: The user can fix the items

Portion estimates from photos are the weakest link, so every item is editable before anything is calculated. "250 g" of rice might really be 180 g — the user knows, the model doesn't.

Step 3: Deterministic lookup against a food table

Nutrition comes from a USDA-derived table, per 100 g:

interface FoodRow { id: string; names: string[]; kcal: number; protein: number; carbs: number; fat: number }

function match(name: string, table: FoodRow[]) {
  const n = name.toLowerCase();
  return table.find((r) => r.names.some((alias) => n.includes(alias)));
}

export function analyze(items: MealItems["items"], table: FoodRow[]) {
  return items.map((it) => {
    const row = match(it.name, table);
    if (!row) return { ...it, estimated: true, kcal: null };   // unmatched stays marked
    const f = it.grams / 100;
    return {
      ...it, estimated: false,
      kcal: Math.round(row.kcal * f),
      protein: +(row.protein * f).toFixed(1),
      carbs: +(row.carbs * f).toFixed(1),
      fat: +(row.fat * f).toFixed(1),
    };
  });
}

Unmatched rows stay clearly marked as estimated instead of being silently filled in.

Step 4: Cooked vs raw is a different food

A classic tracking error: 250 g of boiled white rice is roughly 325 kcal, while dry rice is around 365 kcal per 100 g. They're separate rows in the table, and the matcher prefers the cooked row unless the item says "dry" or "uncooked". The same applies to pasta, oats and legumes.

Step 5: Calculators stay formula-first

The non-AI tools use published formulas with visible math: Mifflin-St Jeor for BMR, an activity factor for TDEE, 4/4/9 kcal per gram for macros, and explicit g/kg bands for protein (e.g. 0.8–1.2 for general health, 1.6–2.2 for muscle gain). Metric and US units are both supported, converted at the edges so the core math only deals with kg and cm.

Takeaways

Use the LLM for perception and parsing, not arithmetic.
Enforce a schema on model output and validate it.
Let users edit portions before calculating.
Mark unmatched items as estimated; never hide uncertainty.

Try the tools at protealpes.net. Where do you draw the line between model output and deterministic code in your AI features?

Stop Picking B2B Software From "Top 10" Lists: A Weighted Scoring Matrix Engineers Can Actually Defend

Akbo Ichou — Fri, 25 Sep 2026 20:37:40 +0000

Sooner or later, every engineer gets pulled into a software selection: a new ERP, inventory system, backup tool, CRM or contract management platform. And most teams start the same way — googling "best X software" and reading a ranked list that was written to earn affiliate commissions.

At Fratech, where I publish independent B2B software reviews, comparisons and how-to guides, the core idea is the opposite: the best software depends on your fit, not on a ranking. Here's the evaluation method, written as something you can run yourself.

1. Write requirements before you look at vendors

Once you've seen demos, every requirement quietly bends toward the product you liked. Start with a list and split it into two kinds:

Must-haves — hard gates. If a product fails one, it's out, no matter how good it is elsewhere.
Weighted criteria — things that matter to different degrees.

interface Criterion { id: string; label: string; weight: number } // weights sum to 1
interface Gate { id: string; label: string }

const gates: Gate[] = [
  { id: "sso", label: "SAML SSO" },
  { id: "export", label: "Full data export in an open format" },
];

const criteria: Criterion[] = [
  { id: "fit",         label: "Industry/module fit",       weight: 0.30 },
  { id: "integration", label: "APIs and integrations",     weight: 0.20 },
  { id: "tco",         label: "3-year total cost",         weight: 0.20 },
  { id: "admin",       label: "Admin effort",              weight: 0.15 },
  { id: "vendor",      label: "Vendor viability/support",  weight: 0.15 },
];

"Who owns the data, and can we get it out?" belongs in the gates for almost any system of record.

2. Score on anchored scales

A bare 1–5 score means something different to every reviewer. Anchor each level with a description, so "3 on integrations" means the same thing to everyone:

Score	Integrations
1	CSV import/export only
3	REST API covering core objects
5	Full API + webhooks + maintained connectors for our stack

3. Compute — and keep the gates separate

type Scores = Record<string, number>; // criterion id -> 1..5

export function evaluate(
  vendor: string,
  passes: Record<string, boolean>,
  scores: Scores
) {
  const failed = gates.filter((g) => !passes[g.id]).map((g) => g.label);
  if (failed.length) return { vendor, eligible: false, failed };

  const total = criteria.reduce((sum, c) => sum + c.weight * (scores[c.id] ?? 0), 0);
  return { vendor, eligible: true, score: Number(total.toFixed(2)) };
}

Never let a high weighted score compensate for a failed gate. That's the most common way teams end up with software that can't do the one thing they needed.

4. Stress-test the weights

If a small change in weights flips the winner, your decision is fragile — and the conversation should be about priorities, not scores:

function sensitivity(base: Criterion[], delta = 0.05) {
  return base.map((c) => {
    const bumped = base.map((x) =>
      x.id === c.id ? { ...x, weight: x.weight + delta }
                    : { ...x, weight: x.weight - delta / (base.length - 1) });
    return { bumped: c.id, ranking: rankVendors(bumped) };
  });
}

5. Count the cost that isn't on the pricing page

Three-year total cost of ownership includes implementation, data migration, integrations, training and admin time — often more than the license itself. Put real numbers against each, even rough ones.

6. Prove it with your own data

The final step is a scripted proof of concept with your real workflows and a sample of your real data. Demos show the happy path; your data shows the edge cases.

Takeaways

Separate must-have gates from weighted criteria.
Anchor scores so reviewers mean the same thing.
Check sensitivity before declaring a winner.
Evaluate total cost and data ownership, not just features.

More buyer guides — ERP, inventory management, backup, CRM, contract lifecycle management and data governance — are at fratech.net. How does your team run software evaluations?

Print CSS Is Still Hard: Making Web Pages Print Perfectly on US Letter at 100% Scale

Akbo Ichou — Fri, 25 Sep 2026 20:33:12 +0000

Most web developers never think about the print button. Then you build a site whose entire purpose is printing, and discover that browsers add headers and footers, "fit to page" shrinks everything, and one stray element pushes your artwork onto a second sheet.

Cute Coloring Pages is a free library of 200+ printable coloring pages across 20 categories — kawaii animals, dinosaurs, mandalas, holidays and more — designed to print on standard US Letter paper at 100% scale. Here's what I learned about making printing reliable.

1. Declare the page size and margins

@page tells the browser what paper you're designing for. Browsers don't all respect every property, but setting it removes a lot of guesswork:

@page {
  size: letter portrait;   /* 8.5in × 11in */
  margin: 0.4in;
}

Setting margins here, rather than relying on browser defaults, also reduces the space where browsers put their own header/footer text.

2. Hide everything that isn't the artwork

Navigation, ads, buttons, related links — none of it should print. A single class convention keeps it manageable:

@media print {
  header, nav, footer, aside, .no-print { display: none !important; }
  body { margin: 0; background: #fff; }
}

3. Size the artwork in physical units

Screen layouts use flexible widths; print layouts should use the printable area. With 0.4in margins on Letter paper, that's 7.7in × 10.2in:

@media print {
  .artwork {
    width: 7.7in;
    height: 10.2in;
    object-fit: contain;
    page-break-inside: avoid;
    break-inside: avoid;
  }
}

Using object-fit: contain keeps the aspect ratio so a landscape design doesn't get stretched.

4. Prefer SVG line art

Coloring pages are pure black line art, which makes them ideal for SVG: crisp at any printer resolution, tiny file sizes, and no JPEG artifacts around lines. If you do use raster images, export them at 300 DPI for the print size (2,550 × 3,300 px for a full Letter sheet), and serve a smaller version for the on-screen preview:

<picture>
  <source media="print" srcset="/art/trex-print.svg">
  <img src="/art/trex-preview.webp" alt="T-Rex coloring page" class="artwork">
</picture>

5. Ensure pure black lines and no background ink

Gray lines print faded on cheap inkjets, and background colors waste ink. Force the essentials:

@media print {
  .artwork { filter: grayscale(1) contrast(1.2); }
  * { -webkit-print-color-adjust: economy; print-color-adjust: economy; }
}

6. Tell users the two settings that matter

Even with perfect CSS, browsers default to "fit to page" and include headers/footers. The single most useful thing on each page is a short instruction: print at 100% scale and turn off headers and footers. Without "fit to page" turned off, a T-Rex can end up looking like a potato with legs.

7. A dedicated print button

window.print() on a clean, art-only route gives the most predictable results:

document.querySelector("#print").addEventListener("click", () => {
  const w = window.open(`/print/${slug}`, "_blank");
  w?.addEventListener("load", () => w.print());
});

Takeaways

Use @page to declare paper size and margins.
Hide everything except the artwork in @media print.
Size print content in inches, and prefer SVG for line art.
Tell users to print at 100% with headers/footers off.

Grab a free page at cutecoloringpages.co — no signup. What's your worst print-CSS bug story?

Decoding J1939 Diesel Fault Codes (SPN/FMI) in TypeScript — and Building a 767-Page Diagnostic Library

Akbo Ichou — Fri, 25 Sep 2026 20:29:56 +0000

If you've ever plugged a scan tool into a heavy-duty truck, you've seen codes like SPN 3226 FMI 13 or SPN 5246 FMI 0. They look cryptic, but they follow the SAE J1939 standard, and decoding them is a nice little bit-manipulation exercise.

I built Professional Diesel Repair, a free diagnostic library with 767 pages covering SPN/FMI, PID and OBD-II P-codes across brands like Cummins, Detroit Diesel, Volvo, Mack, Freightliner, Caterpillar, PACCAR, Ford Power Stroke and GM Duramax. This post covers the data side: how the codes are structured and how the library is organized.

What SPN and FMI mean

SPN (Suspect Parameter Number) — what is affected, e.g. SPN 100 = engine oil pressure, SPN 110 = coolant temperature, SPN 157 = fuel rail pressure.
FMI (Failure Mode Identifier) — how it failed, e.g. FMI 0 = data valid but above normal range (most severe level), FMI 1 = data valid but below normal range (most severe level), FMI 3 = voltage above normal or shorted high, FMI 4 = voltage below normal or shorted low.

The same FMI means the same thing across every SPN, which is what makes a structured library possible.

Decoding a DTC from a DM1 message

In J1939, active faults are broadcast in the DM1 message. Each diagnostic trouble code (DTC) is 4 bytes, packing a 19-bit SPN, a 5-bit FMI, a conversion-method bit and a 7-bit occurrence count:

interface Dtc { spn: number; fmi: number; occurrences: number; cm: number }

export function decodeDtc(b: Uint8Array, offset = 0): Dtc {
  const b0 = b[offset], b1 = b[offset + 1], b2 = b[offset + 2], b3 = b[offset + 3];
  const spn = b0 | (b1 << 8) | ((b2 & 0xe0) << 11); // low 16 bits + top 3 bits
  const fmi = b2 & 0x1f;
  const cm = (b3 & 0x80) >> 7;
  const occurrences = b3 & 0x7f;
  return { spn, fmi, occurrences, cm };
}

(b2 & 0xe0) << 11 moves the three high bits (bits 5–7 of the third byte) into SPN bits 16–18. This layout applies to the current conversion method (CM = 0); older ECUs using other conversion methods need a different mapping.

A quick test:

// SPN 100 (0x64), FMI 1, 3 occurrences
expect(decodeDtc(Uint8Array.from([0x64, 0x00, 0x01, 0x03]))).toEqual({
  spn: 100, fmi: 1, occurrences: 3, cm: 0,
});

Modeling the library

Each code page is a record, and the same SPN/FMI can have brand-specific notes, because the troubleshooting order differs between manufacturers:

interface FaultCode {
  brand: string;                 // "Cummins", "Detroit Diesel", ...
  kind: "SPN" | "PID" | "P-code";
  spn?: number; fmi?: number; code?: string;
  component: string;             // "DEF Dosing Unit"
  description: string;
  system: "Aftertreatment" | "Fuel" | "Coolant" | "Air/Turbo" | "Sensors/Other";
  severity: "MEDIUM" | "HIGH" | "CRITICAL";
  testOrder: string[];           // the steps a shop would actually follow
}

The homepage filter (brand, code type, severity, system) is just a set of predicates over these records, with counts computed per facet so users can see "Cummins (60)" before clicking.

Severity drives the UX

A driver on the shoulder needs a different answer than a technician at a bench. Severity is shown first, and critical codes — like SCR inducement derates (SPN 5246) or low oil pressure (SPN 100 FMI 1) — link straight to guidance on whether it's safe to keep driving or time to call a tow.

Guides for the problems codes don't explain

Some of the most useful pages aren't about a single code: DPF ash and soot, DEF in the diesel tank (and vice versa), fuel gelling, oil analysis trends, injector cup failures and emissions compliance like CARB Clean Truck Check. They link back to the relevant codes, and the codes link to them.

Takeaways

J1939 DTCs are compact bit-packed structs — decode with masks and shifts, and test with known values.
Model FMI meanings once; they apply to every SPN.
Facet counts make big filterable libraries far easier to navigate.
Put severity and "is it safe to drive?" first for real-world users.

Look up a code at professionaldieselrepair.com. Anyone else here work with CAN bus or J1939 data? I'd like to hear what tooling you use.

Building a Fair Trivia Quiz Engine: Unbiased Shuffling, Answer Position Balance and Team Scoring

Akbo Ichou — Fri, 25 Sep 2026 20:26:25 +0000

A trivia quiz looks like the simplest app imaginable: show a question, show four options, check the answer. But the details decide whether it feels fair — and whether a room full of students (or friends at a party) quickly figures out that "the answer is usually C."

Trivia Questions and Answers is a free collection of trivia quizzes by category, used for everything from game nights to classroom review games for middle schoolers and teens. Here's what goes into a quiz engine that holds up.

1. Shuffle correctly (Fisher–Yates)

The classic mistake is array.sort(() => Math.random() - 0.5). It produces a biased shuffle — some orders appear far more often than others. Use Fisher–Yates:

function shuffle(arr, rng = Math.random) {
  const a = [...arr];
  for (let i = a.length - 1; i > 0; i--) {
    const j = Math.floor(rng() * (i + 1));
    [a[i], a[j]] = [a[j], a[i]];
  }
  return a;
}

Shuffle both the question order and each question's options.

2. Balance where the correct answer lands

Even with an unbiased shuffle, a 10-question round can randomly put the right answer in slot B five times. Players notice. You can balance positions across a round so each slot gets roughly equal use:

function balancedPositions(nQuestions, nOptions, rng) {
  const slots = [];
  while (slots.length < nQuestions) {
    slots.push(...shuffle([...Array(nOptions).keys()], rng));
  }
  return slots.slice(0, nQuestions);
}

function placeAnswer(q, slot, rng) {
  const wrong = shuffle(q.options.filter((o) => o !== q.answer), rng);
  wrong.splice(slot, 0, q.answer);
  return { ...q, options: wrong };
}

3. Watch out for "all of the above"

Options like "All of the above" or "Both A and B" break when shuffled. Mark them as pinned and keep them last:

const pinned = q.options.filter((o) => /all of the above|none of the above/i.test(o));
const free = q.options.filter((o) => !pinned.includes(o));
const options = [...shuffle(free), ...pinned];

4. Normalize typed answers

For free-response rounds, "The Beatles", "beatles" and "Beatles!" should all count:

const norm = (s) =>
  s.toLowerCase()
   .normalize("NFD").replace(/[\u0300-\u036f]/g, "")  // strip accents
   .replace(/^(the|a|an)\s+/, "")
   .replace(/[^a-z0-9]/g, "");

const isCorrect = (input, answers) => answers.some((a) => norm(a) === norm(input));

5. Team scoring for classrooms

In a classroom the quiz is projected and the class plays in teams. A tiny scoring model covers it, including bonus points when a team explains why an answer is right — which turns a quiz into actual review:

function createScoreboard(teams) {
  const scores = Object.fromEntries(teams.map((t) => [t, 0]));
  return {
    correct: (team, pts = 1) => (scores[team] += pts),
    explainBonus: (team) => (scores[team] += 1),
    standings: () => Object.entries(scores).sort((a, b) => b[1] - a[1]),
  };
}

6. Write for the audience

The engine is only half of it. Questions for middle schoolers and teens need to be age-appropriate, unambiguous and checkable; every answer should have one clearly defensible correct option. Organizing by category and audience makes it easy for a teacher to grab a relevant round at the end of a lesson.

Takeaways

Never shuffle with sort(() => Math.random() - 0.5).
Balance the correct answer's position across a round.
Pin "all/none of the above" options.
Normalize typed answers generously.

Grab a quiz at triviaquestionsandanswers.net. What's the sneakiest bias you've found in a quiz or game?

Scoring a Big Five Personality Test in TypeScript: Reverse-Keyed Items, Trait Scores and Continuums Instead of Labels

Akbo Ichou — Fri, 25 Sep 2026 20:22:53 +0000

Personality quizzes love putting people in boxes: "You're an introvert!" But the most widely used model in personality psychology, the Big Five (openness, conscientiousness, extraversion, agreeableness, neuroticism), describes continuums, not types. Everyone sits somewhere on each scale.

The Quiz Hub hosts free psychology quizzes and personality tests, including a Big Five test. Its results are designed to show where you sit on a continuum rather than hand you a binary label. Here's how to score a Big Five-style questionnaire correctly — including the part most hobby implementations get wrong.

The item model

Each question (item) measures one trait and is either positively keyed ("I am the life of the party" → extraversion) or reverse keyed ("I don't talk a lot" → also extraversion, but agreeing means less of it).

type Trait = "O" | "C" | "E" | "A" | "N";

interface Item {
  id: string;
  text: string;
  trait: Trait;
  reverse: boolean;
}

// Responses on a 1–5 Likert scale: strongly disagree … strongly agree
type Answers = Record<string, 1 | 2 | 3 | 4 | 5>;

Reverse scoring

This is the bug that ruins most homemade personality tests: summing raw answers without flipping reverse-keyed items. On a 1–5 scale, reverse scoring is 6 - value:

const scoreItem = (item: Item, value: number) => (item.reverse ? 6 - value : value);

Reverse-keyed items exist to reduce "acquiescence bias" — the tendency some people have to agree with everything. If you skip the flip, those people get nonsense results.

Trait scores as a 0–100 position

Average each trait's item scores, then map to 0–100 so it's easy to show on a slider:

export function traitScores(items: Item[], answers: Answers) {
  const acc: Record<Trait, number[]> = { O: [], C: [], E: [], A: [], N: [] };
  for (const item of items) {
    const v = answers[item.id];
    if (v === undefined) continue;
    acc[item.trait].push(scoreItem(item, v));
  }
  return Object.fromEntries(
    Object.entries(acc).map(([t, vals]) => {
      if (vals.length === 0) return [t, null];
      const mean = vals.reduce((a, b) => a + b, 0) / vals.length; // 1..5
      return [t, Math.round(((mean - 1) / 4) * 100)];            // 0..100
    })
  ) as Record<Trait, number | null>;
}

Returning null for an unanswered trait is better than returning 0 — "we can't tell" isn't the same as "very low".

Present a position, not a verdict

Rather than "You are an extravert," show the score on a labeled bar with descriptive anchors at both ends. Language matters too: "You scored toward the reserved end of extraversion" is more accurate — and kinder — than "You are antisocial."

function describe(score: number, low: string, high: string) {
  if (score < 35) return `toward the ${low} end`;
  if (score > 65) return `toward the ${high} end`;
  return `near the middle, between ${low} and ${high}`;
}

Consistency checks

Pairs of opposite items (one positive, one reverse, same trait) should agree after scoring. Large disagreements across several pairs can indicate random clicking — worth a gentle "your answers look inconsistent" note rather than a confident result.

What results are (and aren't) for

The site frames results the right way: they can name tendencies you already notice, give you vocabulary to discuss patterns with a partner or therapist, or place you on a continuum for fun discussion. Where a quiz touches on mood, a high score is a prompt to talk to a GP or counsellor — not a diagnosis.

Takeaways

Always reverse-score reverse-keyed items.
Report traits as positions on a continuum, not types.
Treat missing data as missing, not zero.
Use neutral language and be clear about what a quiz can't tell you.

Try the tests at thequizhub.org. Have you implemented psychometric scoring before? I'd like to hear how you handled validation.

Mapping Free-Text Meals to a Food Table (and Refusing to Guess): Building Race-Week Nutrition Tools for Runners

Akbo Ichou — Fri, 25 Sep 2026 20:18:00 +0000

Here's a problem that looks trivial and isn't: a user types "steel-cut oats with chia and blueberries, chickpea kale bowl, lentil pasta" and wants to know their total fiber for the day.

Plantbaes is a set of free race-fueling calculators for plant-based marathon and half-marathon runners. The flagship tool is a fiber load checker, because plant-based runners typically eat 35–50 g of fiber a day, while a common race-week working ceiling is around 15 g. Three ordinary meals can easily hit 50 g without any one plate looking excessive.

The core engineering rule behind all twelve tools: numbers come from a reviewed data table, never from a language model — and anything that can't be mapped is shown as unmapped, not guessed.

Step 1: A small, reviewed food table

interface Food {
  id: string;
  names: string[];        // aliases: "steel cut oats", "steel-cut oatmeal"
  servingG: number;
  fiberG: number;         // per serving
  carbsG: number;
  lowFiberSwap?: string;  // id of a race-week-friendly alternative
}

A deliberately small table that's been checked beats a huge scraped one that hasn't. Each food can also point to a lower-fiber swap, which is what makes the result actionable.

Step 2: Split and normalize free text

export function splitMeals(input: string): string[] {
  return input
    .toLowerCase()
    .split(/,|\n|;|\band\b|\bwith\b|\+/)
    .map((s) => s.replace(/[^a-z\s-]/g, " ").replace(/\s+/g, " ").trim())
    .filter((s) => s.length > 1);
}

Splitting on "with" and "and" turns "oats with chia and blueberries" into three items — which matters, because chia alone carries a lot of fiber.

Step 3: Match against aliases — and keep the misses

export function mapFoods(parts: string[], table: Food[]) {
  const mapped: Food[] = [];
  const unmapped: string[] = [];
  for (const p of parts) {
    const hit = table.find((f) => f.names.some((n) => p.includes(n)));
    hit ? mapped.push(hit) : unmapped.push(p);
  }
  return { mapped, unmapped };
}

The unmapped list is shown to the user. It's tempting to have an LLM "estimate" unknown foods, but a confident fake number is worse than an honest "we don't know this one" in a tool people use to plan a race.

Step 4: Compare to the ceiling and suggest swaps

const CEILING_G = 15;

export function fiberReport(foods: Food[], table: Food[]) {
  const total = foods.reduce((s, f) => s + f.fiberG, 0);
  const swaps = foods
    .filter((f) => f.lowFiberSwap)
    .sort((a, b) => b.fiberG - a.fiberG)       // biggest offenders first
    .map((f) => ({ from: f, to: table.find((t) => t.id === f.lowFiberSwap)! }));
  return { total, ratio: total / CEILING_G, over: total > CEILING_G, swaps };
}

Sorting swaps by the biggest contributors means the first suggestion always has the largest effect.

Same pattern, twelve tools

The other calculators reuse the same table-driven approach: a carb-loading calculator (8–12 g/kg targets using low-fiber plant foods), a race fuel planner (carbs, sodium and fluid per hour), breakfast, dinner and recovery builders, a caffeine stacker, and a label scanner that highlights honey, whey, gelatin and milk.

Verification status instead of labels

For energy gels and chews, a product catalog carries an explicit status — certified vegan, manufacturer-confirmed, ingredient-list verified, unclear, or not vegan — plus a last-verified date. The gel checker only matches that catalog and never invents a "vegan" label.

Takeaways

Keep nutrition math deterministic and sourced.
Show unmapped input instead of hallucinating values.
Make results actionable by linking each item to a concrete swap.
Use explicit verification states with dates instead of binary labels.

The tools are free at plantbaes.net. (Not medical advice — talk to a sports dietitian for individual plans.) How have you handled free-text input that has to map onto structured data?

10 20 10 10: Composing 20,000 Email Templates That Don't Read Like Mail Merge

Akbo Ichou — Fri, 25 Sep 2026 20:12:52 +0000

Sales Email Template has 20,000+ free, copy-ready email pages. That number comes from four dimensions multiplied together:

10 email types — follow-up, cold email, meeting request, proposal follow-up, breakup, thank you, introduction, referral request, invoice reminder, apology
20 industries — SaaS, healthcare, finance, legal, construction, retail…
10 prospect roles — CEO, CTO, HR director, sales VP, founder…
10 scenarios — no response, clicked but no reply, after demo, after proposal, long time no contact…

10 × 20 × 10 × 10 = 20,000. The engineering challenge is making each combination read like a person wrote it, not like Hi {{first_name}}, I noticed {{company}}…. Here's how the composition works.

Each dimension owns a different part of the email

The mistake is treating every dimension as a find-and-replace variable. Instead, each one controls a different job in the email:

Dimension	Controls
Email type	Structure and goal (ask for a meeting, close the loop, get paid)
Scenario	Opening line and context (why you're writing now)
Role	What they care about and how much detail they want
Industry	Vocabulary and the proof point that lands

interface Combo { type: EmailType; industry: Industry; role: Role; scenario: Scenario }

function compose(c: Combo): { subject: string; body: string } {
  const opener = scenarioOpeners[c.scenario](c);    // why now
  const value  = roleAngles[c.role](c.industry);    // what they care about
  const proof  = industryProof[c.industry];         // what makes it credible
  const ask    = typeAsks[c.type](c.role);          // the one clear next step
  return {
    subject: subjects[c.type](c),
    body: [opener, value, proof, ask].filter(Boolean).join("\n\n"),
  };
}

Because each dimension writes whole sentences for its own slot, a CTO follow-up after a demo reads differently from a CEO breakup email — structurally, not just by swapped nouns.

Short beats clever

Every template aims for something you can read in a few seconds: a subject line, 3–5 short paragraphs, one ask. Long emails fail on mobile and look automated. A simple length check in the build keeps that honest:

const words = (s: string) => s.split(/\s+/).filter(Boolean).length;

for (const combo of allCombos()) {
  const { body } = compose(combo);
  if (words(body) > 120) warn(`too long: ${key(combo)}`);
}

Leave one line for the human

Templates are deliberately missing one thing: the detail only the sender knows — a metric from the last call, a line from the prospect's post, the next step you agreed on. The page tells you exactly which line to change. That single personalized line is what separates a template from spam.

Routing: four clicks to any page

The homepage has a four-step finder (type → industry → role → scenario) that maps to a predictable URL:

/{type}/{industry}/{role}/{scenario}

Hub pages for each type and industry link down into the combinations, so people and crawlers can reach any page without search.

Guarding against duplicate content

With 20,000 pages, near-duplicates are the main risk. A build step compares bodies across combinations with a quick similarity check and flags pairs that are too close, which usually means a dimension's copy isn't pulling its weight:

function jaccard(a: string, b: string) {
  const A = new Set(a.toLowerCase().split(/\W+/)), B = new Set(b.toLowerCase().split(/\W+/));
  const inter = [...A].filter((x) => B.has(x)).length;
  return inter / (A.size + B.size - inter);
}

AI for custom drafts, templates for speed

Templates cover the common cases instantly. For everything else there are free AI tools — an email generator, enhancer, subject-line tool and tone adjuster. The two work together: start from a template's structure, then adjust tone or generate a fresh draft when the situation is unusual.

Takeaways

Give each dimension its own slot and job, not just variables.
Keep emails short and leave one line for real personalization.
Use predictable URLs and hub pages for large combinatorial sites.
Check for near-duplicates at build time.

Browse or copy templates at salesemailtemplate.com — no login. What's your approach to generating content from combinations without it feeling generated?