DEV Community: Akbo Ichou

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?

Turning a Government Fee Table Into a Rules Engine: Lessons From a US Passport Cost Calculator

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

Official fee schedules list every possible charge, but they rarely tell you which lines apply to you. That's the gap Passport Calculator fills: answer five or six questions and get an itemized estimate of what a US passport will actually cost.

Under the hood it's a small rules engine — a pattern that works for any "which fees apply to me?" problem (visas, permits, licenses, shipping). Here's how it's put together.

Fees as data, not if-statements

The first version of a calculator like this is usually a pile of nested ifs. That falls apart the moment fees change. Instead, each fee line is data with a condition:

type Answers = {
  type: "first_time" | "renewal" | "child" | "lost_stolen";
  product: "book" | "card" | "both";
  expedite: boolean;
  needsPhoto: boolean;
};

interface FeeLine {
  id: string;
  label: string;
  amount: number;               // in cents
  official: boolean;            // government fee vs estimate
  applies: (a: Answers) => boolean;
}

Amounts are stored in cents to avoid floating-point surprises when adding lines together.

The fee table (as of the site's last update)

const inPerson = (a: Answers) => a.type !== "renewal"; // DS-11 applicants pay execution

export const FEES: FeeLine[] = [
  { id: "app_book_adult", label: "Application fee (adult book)", amount: 13000, official: true,
    applies: (a) => a.type !== "child" && a.product !== "card" },
  { id: "app_book_child", label: "Application fee (child book)", amount: 10000, official: true,
    applies: (a) => a.type === "child" && a.product !== "card" },
  { id: "app_card_adult", label: "Application fee (adult card)", amount: 3000, official: true,
    applies: (a) => a.type !== "child" && a.product !== "book" },
  { id: "execution", label: "Execution fee", amount: 3500, official: true, applies: inPerson },
  { id: "expedite", label: "Expedited service", amount: 6000, official: true, applies: (a) => a.expedite },
  { id: "photo", label: "Passport photo (estimate)", amount: 1500, official: false, applies: (a) => a.needsPhoto },
];

Note that the execution fee is charged once per appointment, which is why a book and card together come to $195 rather than double-counting.

The engine is a filter and a sum

export function estimate(a: Answers) {
  const lines = FEES.filter((f) => f.applies(a));
  const total = lines.reduce((sum, f) => sum + f.amount, 0);
  return { lines, total };
}

const usd = (cents: number) =>
  new Intl.NumberFormat("en-US", { style: "currency", currency: "USD" }).format(cents / 100);

That's it. A first-time adult book comes out to $165.00 ($130 + $35), a mail renewal to $130.00, and adding expedite brings a first-time book to $225.00.

Test every published scenario

Every scenario shown on the site becomes a test, so a fee change that breaks a page is caught immediately:

test.each([
  [{ type: "first_time", product: "book", expedite: false, needsPhoto: false }, 16500],
  [{ type: "renewal",    product: "book", expedite: false, needsPhoto: false }, 13000],
  [{ type: "child",      product: "book", expedite: false, needsPhoto: false }, 13500],
  [{ type: "first_time", product: "card", expedite: false, needsPhoto: false }, 6500],
  [{ type: "first_time", product: "both", expedite: false, needsPhoto: false }, 19500],
  [{ type: "first_time", product: "book", expedite: true,  needsPhoto: false }, 22500],
])("%o costs %i cents", (answers, cents) => {
  expect(estimate(answers as Answers).total).toBe(cents);
});

Separate official fees from estimates

A photo isn't a government fee, so it's labeled as an estimate. Mixing the two quietly would make the total look more authoritative than it is. The official flag drives that label in the UI.

Scenario pages share the same engine

Pages like "first-time adult", "passport card" or "lost or stolen" all read from the same fee table and link back to the calculator with answers prefilled via query string. Update one number and every page, table and test stays consistent.

Be explicit about what you're not

For anything touching government services, clarity matters: the site states it isn't affiliated with the State Department, that results are unofficial estimates with an "as of" date, and that users should confirm current fees on travel.state.gov before paying. Nothing users enter is submitted anywhere.

Takeaways

Model fees as data with conditions; keep the engine tiny.
Store money in integer cents.
Turn every published example into a test.
Label estimates separately from official amounts, and date your data.

Try it at passportcalculator.com. Have you built rules engines for pricing or eligibility? I'd like to hear how you structured them.

How an ATS Resume Checker Scores Your CV (and Why Developers Get Filtered Out)

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

Plenty of strong developers send dozens of applications and hear nothing back. Often the problem isn't skill — it's that the resume doesn't survive the applicant tracking system (ATS) or the recruiter's 10-second skim.

I built HireFlow, a free ATS resume checker with no signup, to make that invisible filtering visible. This post walks through how the scoring works, which is useful whether or not you ever use the tool.

An ATS score is really two questions

Can the software read your resume? (parsing)
Does what it reads match the job? (relevance)

A beautifully designed resume that fails question 1 never gets to question 2. So the checker scores them separately rather than blending everything into one opaque number.

The seven check groups

The checker groups its checks into categories, each producing specific, fixable findings:

ATS essentials — parseable text (not an image), standard fonts, no content trapped in headers/footers or tables, contact info present.
Resume sections — recognizable headings like Experience, Education, Skills.
Content quality — action verbs, quantified results, reasonable length.
Job tailoring — keyword overlap with a pasted job description.
Recruiter red flags — things that make a human skim past you.
Bias & gaps — employment gaps and details that invite bias.
Seniority & impact — whether the resume reads at the level you're applying for.

Keyword matching: exact phrases matter

A classic failure: the job says "Salesforce" and the resume says "CRM software". To a human that's close; to keyword matching it's a miss. The fix is to mirror the exact phrases from the posting where they're truthful.

A simplified version of the matching logic:

const normalize = (s: string) =>
  s.toLowerCase().replace(/[^a-z0-9+#.\s-]/g, " ").replace(/\s+/g, " ").trim();

export function keywordCoverage(resume: string, keywords: string[]) {
  const text = ` ${normalize(resume)} `;
  const hits = keywords.filter((k) => text.includes(` ${normalize(k)} `));
  return {
    score: keywords.length ? hits.length / keywords.length : 0,
    missing: keywords.filter((k) => !hits.includes(k)),
  };
}

Note the character class keeps +, # and . — otherwise C++, C# and Node.js get mangled, which is a surprisingly common bug in resume tooling.

Parsing checks for developers specifically

Developer resumes break ATS parsing in predictable ways:

Two-column templates — text can be read across columns in the wrong order.
Skill bars and icons — "React ●●●●○" is meaningless to a parser.
Tech stacks as logos — images contain no text.
Contact details in the header — some parsers skip headers entirely.

Strong vs weak bullet points

Content quality checks look for impact over activity:

❌ "Worked on the backend API."
✅ "Cut p95 API latency from 800 ms to 180 ms by adding Redis caching to the pricing service."

The second one has an action verb, a metric and a technology keyword — everything both the ATS and the recruiter are looking for.

What a "good" score means

A score isn't a pass/fail gate, and different ATS products behave differently. It's most useful as a checklist: fix parsing problems first, then tailor keywords to each job, then sharpen impact statements.

Takeaways for your own resume

Use a single-column, text-based layout.
Mirror exact keywords from the job posting when they're true.
Quantify results.
Keep contact info in the body, not the header.

You can check your resume for free at hireflow.net — no signup. What's the most surprising resume feedback you've received?

"Uncertain" Is a Valid Answer: Building an Ingredient Checker That Doesn't Guess

Akbo Ichou — Fri, 25 Sep 2026 19:58:55 +0000

Most "is it X?" checkers return a yes or a no. That's clean UI — and often wrong. When I built Is This Vegan?, a free checker for products, ingredients and E-numbers, the most important design decision was adding a third answer: uncertain.

Here's why, and how the classification logic works.

Why binary answers fail for food

Some ingredients are clearly animal-derived: gelatin, whey, casein, honey, carmine (E120). Others are clearly plant-based. But a meaningful set depend on the source, and labels usually don't say which:

E471 (mono- and diglycerides) — can come from plant oils or animal fats.
E322 (lecithin) — usually soy in mass-market foods, but egg lecithin exists.
E631 — may be fermented from plants or derived from animal tissue.
"Natural flavors", glycerin, stearic acid — same problem.

A checker that labels these "vegan" is guessing. One that labels them "not vegan" is also guessing. So the model has three states.

The data model

type Status = "vegan" | "not_vegan" | "uncertain";

interface Ingredient {
  id: string;
  names: string[];          // aliases: "e471", "mono- and diglycerides of fatty acids"
  status: Status;
  typicalSource?: string;   // "Animal collagen (bones, skin)"
  note?: string;            // why it's uncertain
}

Aliases matter a lot: EU/UK labels tend to use E-numbers, US labels chemical names, and dairy hides under names like whey, casein, lactose, milk powder and butterfat.

Normalizing an ingredient list

Ingredient lists are messy: parentheses, percentages, "contains 2% or less of", mixed case, and sub-ingredients. A small normalizer turns them into tokens you can match:

export function tokenize(list: string): string[] {
  return list
    .toLowerCase()
    .replace(/\d+(\.\d+)?\s*%/g, "")          // drop percentages
    .replace(/contains \d+% or less of:?/g, ",")
    .split(/[,;()\[\]]+/)                      // flatten sub-ingredient lists
    .map((s) => s.replace(/\s+/g, " ").trim())
    .filter(Boolean);
}

E-numbers get normalized too (E 471, e-471 and E471 should all match).

Aggregating to a product verdict

The product result is the "worst" status found, with an important ordering: a single definite animal ingredient makes the product not vegan; otherwise, any uncertain ingredient makes it uncertain.

export function verdict(tokens: string[], lookup: (t: string) => Ingredient | undefined) {
  const found = tokens.map(lookup).filter(Boolean) as Ingredient[];
  if (found.some((i) => i.status === "not_vegan")) return { status: "not_vegan", reasons: found.filter((i) => i.status === "not_vegan") };
  const unsure = found.filter((i) => i.status === "uncertain");
  if (unsure.length) return { status: "uncertain", reasons: unsure };
  return { status: "vegan", reasons: [] };
}

Always return the reasons, not just the status. "Uncertain because of E471 — source not stated" is actionable; "Uncertain" alone isn't.

Edge cases worth modeling explicitly

"May contain" warnings describe cross-contamination risk, not ingredients. They're shown separately, not counted in the verdict.
Regional formulations — the same brand can use different recipes in the US, UK and EU, so product records need a market field.
Reformulations — manufacturers change recipes quietly, so product records carry a "last verified" date.
Certification (e.g. Vegan Society, V-Label) can resolve uncertain additives, since the certifier has checked the supply chain.
Allergies are a different question. Vegan status isn't allergen safety, and the UI says so.

UX: make uncertainty useful

An uncertain result should tell people what to do next: check the package they're actually holding, look for certification, or contact the manufacturer with the product name, batch code and country of purchase.

Takeaways

If the real world has three answers, your data model should too.
Store aliases aggressively; labels use many names for the same thing.
Return reasons alongside verdicts.
Keep "may contain" and allergens out of the core classification.

Try it at isthisvegan.net. Have you built classifiers where "unknown" turned out to be the most important state?