DEV Community: Joe Lin

Gadget Replacement Calculator

Joe Lin — Wed, 07 Oct 2026 13:00:05 +0000

“Should I replace this device?” sounds like a price comparison, but a cheap upgrade can still be a poor decision if the current device is inexpensive to keep or the new device carries a large manufacturing footprint. I built this calculator for a more explicit comparison: put the financial break-even point beside a rough carbon payback point, then see whether both axes agree.

The result is not a universal upgrade rule. It is a transparent model whose assumptions you can change: device type, resale value, repair cost, satisfaction score, expected lifespan, manufacturing CO₂, power draw, and daily usage.

The Current Device Is a Monthly Cost Model

The form supports smartphones, laptops, tablets, and desktop PCs. Selecting a type updates two defaults:

const CO2_DEFAULTS = {
  smartphone: 70,
  laptop: 300,
  tablet: 90,
  desktop: 700,
};
const POWER_DEFAULTS = {
  smartphone: 5,
  laptop: 15,
  tablet: 8,
  desktop: 80,
};

function setDeviceType(key) {
  deviceType.value = key;
  mfgCo2.value = CO2_DEFAULTS[key];
  powerWatts.value = POWER_DEFAULTS[key];
}

If no positive resale value is entered, the calculator estimates one with straight-line depreciation from the purchase price:

const resale = currentResale.value > 0
  ? currentResale.value
  : Math.max(
      0,
      purchasePrice.value *
        (1 - ageMonths.value / (newLifespan.value * 12))
    );

That fallback is intentionally visible in the source: it uses the new device's expected lifespan as the time scale for the estimate. The keep-cost model then adjusts remaining months by the satisfaction score, never allowing less than one month:

const remainingMonths = Math.max(
  (expectedLifeMonths - ageMonths.value) * (perfScore.value / 10),
  1
);
const monthlyDepreciation = resale / remainingMonths;
const monthlyCostKeep = monthlyRepair.value + monthlyDepreciation;

The new device's monthly cost is simply its price divided by its expected lifespan in months. If keeping the old device is cheaper per month, there is no financial benefit and moneyBreakEven becomes -1. Otherwise the upfront amount is the new price minus the resale value, divided by monthly savings and rounded up.

Carbon Payback Uses an Explicit Assumption

The carbon side estimates annual savings from reduced power use:

const co2PerKwh = 0.5;
const extraPowerWatts =
  powerWatts.value * (efficiencyLoss.value / 100);
const annualCarbonSaved =
  (extraPowerWatts / 1000) *
  usageHours.value *
  365 *
  co2PerKwh;
const carbonBreakEven = annualCarbonSaved > 0
  ? Math.ceil((mfgCo2.value / annualCarbonSaved) * 12)
  : 9999;

The 0.5 value is treated as kilograms of CO₂e per kilowatt-hour, described in the interface as a world-average estimate. It is not a measurement of your local grid. Manufacturing emissions are editable because the built-in reference values—roughly 70 kg for a phone, 300 for a laptop, 90 for a tablet, and 700 for a desktop—are estimates rather than certified product data.

The model asks a narrow question: if the current device consumes efficiencyLoss percent more power than a replacement, how long would the saved electricity take to offset manufacturing emissions? It does not count transport, recycling, repair parts, battery degradation, or the rebound effect of using a more powerful device.

The Verdict Is a Two-Axis Policy

The calculator labels a result replace only when financial break-even is positive and at most 24 months and carbon payback is at most 36 months. It labels a result keep when the money calculation does not favor replacement or takes more than 36 months, and carbon payback is over 48 months. Everything else is borderline:

const moneyFavorsReplace =
  moneyBreakEven > 0 && moneyBreakEven <= 24;
const carbonFavorsReplace =
  annualCarbonSaved > 0 && carbonBreakEven <= 36;
const moneyFavorsKeep =
  moneyBreakEven < 0 || moneyBreakEven > 36;
const carbonFavorsKeep = carbonBreakEven > 48;

if (moneyFavorsReplace && carbonFavorsReplace) {
  verdict = "replace";
} else if (moneyFavorsKeep && carbonFavorsKeep) {
  verdict = "keep";
}

Those thresholds are policy choices, not laws of economics or climate science. The UI also shows both monthly costs, the calculated break-even months, manufacturing carbon, annual carbon saved, and the two small bar comparisons, so you can disagree with the label without losing the underlying numbers.

The interface keeps the two questions visible instead of collapsing them into one score. The financial card reports the monthly cost to keep and the monthly amortized cost of the new device, while the carbon card reports manufacturing emissions and annual savings. A device can therefore be financially attractive but environmentally slow to pay back, or the reverse. The borderline state is not a calculation failure; it is the expected output when the chosen thresholds disagree or neither side is decisive.

Where the Model Can Mislead

Straight-line depreciation is a convenient approximation, not a resale-market forecast. A device can have a sudden battery failure, retain value unusually well, or be worth nothing while still working. The satisfaction score changes the remaining-life estimate, which makes it a subjective input rather than a measured performance benchmark. A device older than the assumed lifespan is clamped to one remaining month instead of producing a special “already beyond life” state.

Carbon payback becomes infinite when annual savings are zero, and all carbon values are estimates. Treat the result as a conversation starter and sensitivity test: change the resale value, repair cost, efficiency loss, and usage hours to see which assumptions actually control the recommendation.

I turned this model into a small free tool: Gadget Replacement Calculator. It is useful when a purchase decision needs more than “the new one has a lower monthly payment.”

CSS Specificity Real Render Winner Rule Checker

Joe Lin — Tue, 06 Oct 2026 13:00:04 +0000

I used to reach for a specificity calculator whenever a CSS declaration “did nothing.” It would return a neat (a,b,c) score, but I still had to remember source order, !important, whether the selector actually matched, and what value the browser computed after the cascade. A score is useful for explaining a conflict; it is not the same thing as observing the rendered result.

This tool takes a deliberately hybrid approach. It renders the pasted HTML and CSS in a hidden iframe, reads the browser's computed value, and separately parses the declarations to explain which matching rule should win. That gives you a concrete value and an inspectable reason instead of one opaque number.

The Browser Gets an Isolated Document

The analyzer creates a fixed, invisible iframe and writes only the supplied markup into it:

const iframe = document.createElement("iframe");
iframe.style.cssText =
  "position:fixed;top:-9999px;left:-9999px;width:1000px;height:600px;" +
  "opacity:0;pointer-events:none;z-index:-1";
document.body.appendChild(iframe);

const doc = iframe.contentDocument || iframe.contentWindow.document;
doc.open();
doc.write(
  `<!DOCTYPE html><html><head><style>${cssInput.value}</style>` +
  `</head><body>${htmlInput.value}</body></html>`
);
doc.close();

The requested selector is resolved with querySelector, and the selected element is checked with getComputedStyle:

const computedStyle = iframe.contentWindow.getComputedStyle(el);
const computedValue = computedStyle.getPropertyValue(prop).trim();

That matters for values such as colors, inherited properties, and browser normalization. The returned value is what this isolated document computed, not merely what a parser thinks the declaration says.

Specificity Is Still Useful as an Explanation

The component calculates the familiar three-part score. IDs count as a, classes, attributes, and pseudo-classes as b, and type selectors and pseudo-elements as c:

const score = idCount * 10000 + classCount * 100 + typeCount;
return {
  a: idCount,
  b: classCount,
  c: typeCount,
  score,
  str: `(${idCount},${classCount},${typeCount})`,
};

Before counting, it expands the contents of :not(...) for counting and replaces attribute contents with [x]. It then removes IDs, classes, attributes, and pseudo-classes before looking for type selectors. This is a practical parser for the snippets the tool is designed to inspect, not a standards-complete CSS grammar.

Declarations are found with a regular expression, split on commas for multi-selector rules, and stored with their source order:

const declRe = /([\w-]+)\s*:\s*([^;!]+)(\s*!\s*important)?;?/g;
// ...
props[propName] = { value, important };

For each requested property, matching rules are sorted by specificity score and then source order. An important declaration receives a million-point offset:

score: r.props[prop].important
  ? spec.score + 1000000
  : spec.score,
sourceOrder: r.sourceOrder,

The results table keeps every matching declaration, highlights the first one as the winner, and shows !important beside it. If a property name contains color or background, the component also tests whether the computed value can be assigned to a temporary element so it can show a color swatch.

Why Computed Value and Winner Explanation Can Diverge

The iframe is the source of truth for the computed property value, but the displayed winner is derived from the component's simple parser and score. That distinction is worth keeping in mind when debugging shorthand properties, inheritance, browser defaults, or syntax the parser does not recognize. The tool also auto-detects property names by collecting up to twelve names that match ([\w-]+)\s*: in the CSS text; it does not inspect the browser's full computed-style list.

The good news is that this makes the output readable. You can see the actual value, the selector that the local explanation ranks first, all matching rules, and their (a,b,c) values in one table. You can also replace the defaults with a tiny reproduction instead of loading an entire application.

The default reproduction is intentionally small: a .text paragraph sits inside .container#main, and .text, .container .text, p.highlight, and #main p all compete over color and font-size. It is a useful sanity check because the winning ID rule is not the last rule in the stylesheet. You can also press “Auto-detect from CSS”; that helper collects property names with a simple regular expression, lowercases them, removes duplicates with a Set, and limits the list to twelve properties before filling the input.

Static Snippets Only

The iframe does not load external fonts or images and does not execute external JavaScript. Shadow DOM and styles dynamically injected by CSS-in-JS are outside this input model. The CSS parser is intentionally regex-based, so nested braces, unusual declaration values containing semicolons, or advanced syntax can be parsed differently from a production stylesheet. If the selector is invalid or no element matches, the component reports that rather than pretending there is a winner.

I turned this debugging workflow into a small free tool: CSS Specificity Real Render Winner Rule Checker. Paste the smallest HTML/CSS example that reproduces the conflict, then use the table to decide whether the fix belongs in the selector, source order, or the declaration itself.

Encoding Fixer (Multilingual Mojibake Repair)

Joe Lin — Mon, 05 Oct 2026 13:00:03 +0000

Mojibake is one of those bugs that looks like corrupted data even when the bytes are still fine. A UTF-8 file opened as Windows-1252 can turn é into Ã©; a Big5 file decoded as UTF-8 can become a wall of unrelated symbols. The hard part is that the visible text often no longer tells you which decoder was used. I built this tool around a safer question: which plausible decoding produces text that looks least broken, and how confident should we be?

That is deliberately different from claiming to “detect the encoding” with certainty. The component tries candidates, scores their output, and shows up to five results so a person can verify the language and context.

File Mode Preserves the Original Bytes

When the original file is available, the UI uses FileReader.readAsArrayBuffer() instead of starting with a JavaScript string:

function loadFile(file) {
  fileError.value = "";
  fileName.value = file.name;

  const reader = new FileReader();
  reader.onload = (e) => {
    fileBuffer.value = e.target.result;
  };
  reader.onerror = () => {
    fileError.value = t("encodingFixer.fileLoadError");
    fileBuffer.value = null;
  };
  reader.readAsArrayBuffer(file);
}

That choice keeps the raw byte sequence available for each decoding attempt. The catalog includes UTF-8, GBK/GB2312, GB18030, Big5, Shift-JIS, EUC-JP, EUC-KR, several ISO-8859 variants, Windows-1250 through Windows-1257, and KOI8-R/U. For each candidate, TextDecoder runs in fatal mode:

const decoder = new TextDecoder(enc, { fatal: true });
const text = decoder.decode(buf);

An encoding that cannot decode the bytes is skipped rather than turned into a misleading string full of replacement characters. Successful candidates are scored and only those above 10 are kept.

A Score Is a Bundle of Imperfect Signals

The scorer samples at most 2,000 characters, counts printable code points, and penalizes ranges that are common signs of a wrong decode:

const sample = text.slice(0, 2000);
let printable = 0;
let suspicious = 0;

for (let i = 0; i < sample.length; i++) {
  const cp = sample.charCodeAt(i);
  if (cp === 9 || cp === 10 || cp === 13 || (cp >= 32 && cp !== 127)) {
    printable++;
  }
  if (isSuspiciousCodePoint(cp)) suspicious++;
}

let score = Math.round(printableRatio * 100)
  - Math.round(suspiciousRatio * 300);

The suspicious ranges include halfwidth Katakana, private-use characters, Yi characters, and isolated Hangul jamo. The score is then clamped between 0 and 99. UTF-8 receives a small bonus when it decodes cleanly, while raw ISO-8859-1 and Windows-1252 output is penalized if it contains many control-range bytes. Replacement characters are also penalized by their ratio; a result with more missing data should not outrank a clean result merely because most of its characters are printable.

This is heuristic ranking, not language understanding. A short identifier, a code file, or an unusual proper noun may look “suspicious” even when it is correct.

Paste Mode Replays a Mojibake Mistake

Once text has been copied, its original bytes are gone. The paste path uses iconv-lite to try a smaller cross-encoding search: encode the visible mojibake as one of four possible source encodings, then decode those bytes as one of four possible target encodings:

for (const sourceEncoding of SOURCE_ENCODINGS) {
  const rawBytes = iconv.encode(originalText, sourceEncoding.enc);

  for (const targetEncoding of TARGET_ENCODINGS) {
    if (sourceEncoding.enc === targetEncoding.enc) continue;
    const restoredText = iconv.decode(rawBytes, targetEncoding.enc);
    if (!restoredText || restoredText === originalText) continue;
    // score and keep the candidate
  }
}

The source list is Big5, GBK, Shift-JIS, and Windows-1252. Targets are UTF-8, Big5, GBK, and Shift-JIS. Results with too many synthetic ? characters are discarded because iconv-lite substitutes characters that do not fit a codec with ?; a string of legal question marks can otherwise score deceptively well. When the input contains no literal question marks, those generated marks are displayed as � so partial recovery is visible.

After scoring, the candidates are sorted from highest confidence to lowest and deduplicated. File mode uses the first 100 characters of the preview as its signature; paste mode compares the full restored text. That prevents the interface from filling with the same readable result produced by several source/target combinations, while still preserving different plausible repairs. The first candidate receives a visual highlight, but the copy and download actions remain available for every candidate. A download is always emitted as a UTF-8 text blob, regardless of the encoding label that produced it, which is convenient for saving a repaired result but worth remembering if another system specifically requires Big5 or Shift-JIS bytes.

Honest Boundaries

The original file is the best input. In file mode, previews are capped at 5,000 characters and the UI returns at most five deduplicated candidates. In paste mode, copying already-decoded gibberish can permanently discard byte information, especially for CJK text; trying every combination cannot recreate bytes that no longer exist. A high confidence score is evidence, not proof, so compare a candidate with known words, headers, or a sample from the source system before saving it over the original.

I turned this into a small free tool: Encoding Fixer (Multilingual Mojibake Repair). It is most useful when you can upload the original .txt, .csv, or .log file and keep the recovery process reversible.

Log Multi-Regex Filter Dashboard

Joe Lin — Fri, 02 Oct 2026 13:00:03 +0000

I built this after spending too much time switching between Ctrl+F, shell commands, and a spreadsheet just to answer a few basic incident questions: how many lines mention ERROR, which requests came from one IP range, and whether a fix reduced the number of warnings. The annoying part was not writing one regular expression. It was applying several of them to the same pasted log without losing the line numbers or accidentally counting the same line differently in each search.

The useful mental model here is not “search the log several times.” It is “turn each rule into a small, independent classifier, then compare the resulting sets of lines.” That distinction explains several implementation choices in this Vue component.

A Rule Is a Label, a Pattern, and a Color

The UI starts with three rules and gives every rule a label, a pattern, and a color:

const COLORS = ["#e53e3e", "#dd6b20", "#d69e2e", "#38a169", "#3182ce"];

const defaultRules = [
  { label: "ERROR", pattern: "ERROR|FATAL|Exception|error", color: COLORS[0] },
  { label: "WARN", pattern: "WARN|WARNING", color: COLORS[1] },
  { label: "INFO", pattern: "INFO", color: COLORS[3] },
];

const rules = ref(defaultRules.map((r) => ({ ...r })));

The spread is small but important. It gives the reactive state fresh objects instead of letting edits mutate the template constants. New rules are capped at ten and receive a color based on their position. A blank pattern is ignored when analysis runs, so adding a row while experimenting does not automatically create an error.

Labels are presentation, not matching logic. If a label is empty, the result falls back to the pattern itself. That keeps an unlabeled rule useful in the summary and in the exported filename, while letting a human-readable label such as Specific IP make an incident report easier to scan.

Matching Lines Without Counting Occurrences

The analysis splits the input into lines once, then constructs a JavaScript RegExp for each non-empty rule:

const lines = logText.value.split("\n");

for (const rule of rules.value) {
  if (!rule.pattern.trim()) continue;

  let re;
  try {
    const flags = caseSensitive.value ? "g" : "gi";
    re = new RegExp(rule.pattern, flags);
  } catch {
    errorMessages.value.push(
      t("logRegexDashboard.errorInvalidRegex")
        .replace("{label}", rule.label || rule.pattern)
    );
    continue;
  }

  const matches = [];
  for (let i = 0; i < lines.length; i++) {
    re.lastIndex = 0;
    if (re.test(lines[i])) {
      matches.push({ lineNo: i + 1, line: lines[i] });
    }
  }
}

The g flag makes test() stateful: after a successful test, lastIndex can point past the beginning of the next test. Resetting re.lastIndex before every line makes the result deterministic. It is an easy detail to miss because the same expression often appears to work when tested only once.

Notice what this counts: matching lines, not every occurrence. A line containing ERROR ERROR ERROR contributes one hit to the ERROR rule. That is intentional for triage dashboards, where “how many log entries are affected?” is usually more useful than raw substring frequency. Separate rules can overlap; the ERROR and Specific IP counts are independent rather than mutually exclusive categories.

Invalid patterns do not abort the whole run. The try/catch records a localized error and continues with the other rules. That is a much friendlier failure mode when one experimental pattern has an unmatched [ but the remaining incident checks are valid.

Results Are Data You Can Inspect, Not Just Bars

Each result keeps the original line text and its one-based line number. The bar width is relative to the largest rule count:

const maxCount = computed(() => {
  if (!results.value.length) return 1;
  return Math.max(...results.value.map((r) => r.matches.length), 1);
});

width: maxCount > 0
  ? (res.matches.length / maxCount * 100) + "%"
  : "0%"

That means the chart answers “which rule has the most matching lines?” while the expandable list answers “which exact entries caused that number?” The export path preserves both pieces:

const lines = [`=== ${res.label} (${res.pattern}) ===`, ""];
res.matches.forEach((m) => {
  lines.push(`[Line ${m.lineNo}] ${m.line}`);
});
const blob = new Blob([lines.join("\n")], {
  type: "text/plain;charset=utf-8",
});

The browser creates a temporary object URL and downloads log-filter-${res.label}.txt. Nothing in the component sends the pasted text to a server; the work happens in the page.

The Practical Limits

This is a line-oriented filter, not a log parser. It does not understand JSON fields, multiline stack traces, timestamps, or log levels beyond whatever your regex expresses. A stack trace split over several lines can therefore be counted as several unrelated entries. Regex syntax is JavaScript syntax, including its escaping rules, and a pathological pattern can still be expensive.

The implementation also scans every line for every rule. Ten rules over tens of thousands of lines can make the browser feel slow, and the result list retains the matching text in memory. I would start with a broad rule, inspect the reduced set, and then run more specific patterns when working with a very large paste.

I turned this approach into a small free tool: Log Multi-Regex Filter Dashboard. It is useful when you need comparable per-rule line counts and the actual lines behind them, without first building a log pipeline.

Color Contrast Matrix Checker: Turning WCAG Pair Checks into a Readable Grid

Joe Lin — Thu, 01 Oct 2026 13:00:03 +0000

Accessibility reviews get repetitive when a design system has four, six, or ten colors. A designer may check dark text on white, then forget the warning color on a tinted card or the inverse combination in a badge. I built the Color Contrast Matrix Checker to turn those pairwise questions into one table: every entered color becomes a row and a column, and every ordered foreground/background pair gets a WCAG result.

The primary reader is a frontend developer or design-system maintainer who needs to audit a palette before wiring it into components. The takeaway is both the math and the shape of the work: a contrast ratio is based on relative luminance, while the matrix makes the number of combinations visible. The tool is a concrete browser implementation of that calculation, not a promise that RGB alone describes every rendered design.

Normalize the palette before calculating

The interface starts with four colors and permits adding colors up to ten. Each row has a native color picker and a text field, but the calculation accepts only three- or six-digit hexadecimal values:

function isValidHex(hex) {
  return /^#([0-9a-fA-F]{3}){1,2}$/.test(hex);
}

function normalizeHex(hex) {
  const clean = hex.replace(/^#/, "");
  if (clean.length === 3) {
    return "#" + clean.split("").map((c) => c + c).join("");
  }
  return "#" + clean.toLowerCase();
}

On calculate, each row is synchronized from its picker when valid, then mapped to a normalized value. If any entry is invalid, the function stops and displays “At least 2 colors required” from the localization data. In practice the UI prevents removing below two colors, while the add button prevents more than ten. That upper bound also keeps the resulting table usable on a small screen.

The ratio is luminance math, not channel averaging

The source expands shorthand hex and converts each channel to a linear-light value:

function linearize(c) {
  const s = c / 255;
  return s <= 0.03928 ? s / 12.92 : Math.pow((s + 0.055) / 1.055, 2.4);
}

function relativeLuminance([r, g, b]) {
  return 0.2126 * linearize(r) +
         0.7152 * linearize(g) +
         0.0722 * linearize(b);
}

function contrastRatio(hex1, hex2) {
  const rgb1 = hexToRgb(hex1);
  const rgb2 = hexToRgb(hex2);
  if (!rgb1 || !rgb2) return null;
  const l1 = relativeLuminance(rgb1);
  const l2 = relativeLuminance(rgb2);
  const lighter = Math.max(l1, l2);
  const darker = Math.min(l1, l2);
  return (lighter + 0.05) / (darker + 0.05);
}

The 0.05 terms prevent a zero-luminance color from making the ratio undefined. Taking the lighter and darker luminance makes the ratio symmetric: black on white and white on black have the same numeric result, even though the UI still labels one color as the row and the other as the column.

Thresholds depend on text size

The radio buttons select normal or large text. The checker then applies the source’s WCAG thresholds:

function getLevel(ratio, size) {
  const aaThreshold = size === "large" ? 3.0 : 4.5;
  const aaaThreshold = size === "large" ? 4.5 : 7.0;
  if (ratio >= aaaThreshold) return "aaa";
  if (ratio >= aaThreshold) return "aa";
  return "fail";
}

The result loop deliberately computes both directions for every pair:

for (let i = 0; i < n; i++) {
  const row = [];
  for (let j = 0; j < n; j++) {
    if (i === j) {
      row.push({ same: true, bg: validColors[i], fg: "#888888", levelClass: "same" });
    } else {
      const ratio = contrastRatio(validColors[i], validColors[j]);
      const level = getLevel(ratio, size);
      row.push({
        same: false, bg: validColors[i], fg: validColors[j],
        ratio: ratio.toFixed(2) + ":1", level, levelClass: level,
      });
    }
  }
  result.push(row);
}

The diagonal is marked “Same” rather than pretending a color against itself is a useful text pairing. Summary counts exclude those cells, and totalPairs is n * (n - 1), so the total reflects ordered foreground/background combinations.

The ordered grid is useful even though the ratio itself is symmetric because the rendered preview is not abstract: each cell uses the row color as its background and the column color as its foreground. A design-system owner can therefore see which actual text/background assignment is being reviewed. The CSV keeps the same orientation with an FG \ BG header, making it possible to carry the review into a spreadsheet without losing which side of the pair was intended as text.

The matrix is also a debugging aid

Each cell shows the ratio and AA/AAA/fail label, with the cell background set to the row color and its text color set to the column color. The table is horizontally scrollable, and the export function writes the same values to color-contrast-matrix.csv. That makes the result useful in a review: a failing cell points to a specific pair instead of a vague “palette needs work” comment.

There are honest boundaries. The parser accepts RGB hex only; alpha, CSS gradients, images, and color-mix results are not modeled. The formula cannot know the font’s actual weight, anti-aliasing, surrounding colors, or a semi-transparent overlay. The “large” option is a simplified choice matching the tool’s labels, not a parser for every CSS typography rule. A ratio that passes in isolation can still be hard to read in a real component.

I turned this implementation into a small free tool: Color Contrast Matrix Checker.

API Secret Scanner: Why Regex Finds Both Real Leaks and False Alarms

Joe Lin — Wed, 30 Sep 2026 13:00:04 +0000

A secret scanner should be useful before a secret reaches Git history, not just after a security incident. I built the API Secret Scanner as a deliberately small client-side analyzer: paste code or upload a text file, scan each line against known token shapes, and show a masked finding with its line number. That workflow is fast enough for a pre-commit spot check and transparent enough to inspect.

The primary reader is a developer reviewing an .env, configuration file, or pull request who needs to understand what a pattern-based scanner can and cannot promise. The takeaway is not “regex proves a credential is active.” It is how to design a useful first-pass detector while protecting the value it found. The tool itself is the example, not a substitute for revocation, history cleanup, or a full secret-management system.

The pattern table makes policy visible

The implementation stores recognizers with a type and severity. High-severity examples include AWS access key IDs, private-key headers, JWTs, and Stripe live keys:

const SECRET_PATTERNS = [
  { type: "AWS Access Key ID", severity: "HIGH", re: /\bAKIA[0-9A-Z]{16}\b/ },
  { type: "RSA/EC/OPENSSH Private Key", severity: "HIGH",
    re: /-----BEGIN (?:RSA |EC |DSA |OPENSSH )?PRIVATE KEY-----/ },
  { type: "JWT Token", severity: "HIGH",
    re: /\beyJ[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}\b/ },
  { type: "GitHub PAT (ghp_)", severity: "MEDIUM",
    re: /\bghp_[A-Za-z0-9]{36,}\b/ },
  { type: "Hardcoded token=", severity: "LOW",
    re: /(?:access_token|auth_token)\s*[=:]\s*["'][^"']{16,}["']/i },
];

The full source includes provider-specific formats for GitHub, GitLab, Google, Slack, SendGrid, Twilio, Stripe, npm, PyPI, Shopify, Azure, Firebase, Telegram, Discord, and more, plus generic hardcoded password, secret, API-key, token, and basic-auth patterns. Keeping these as data makes it possible to audit the policy instead of hiding every decision inside one enormous expression.

Scan line by line and preserve only a masked preview

scanText splits on newline, tests each pattern against the current line, and records the first match returned by that pattern:

function scanText(text) {
  const lines = text.split("\n");
  const result = [];
  for (let i = 0; i < lines.length; i++) {
    for (const pattern of SECRET_PATTERNS) {
      const match = lines[i].match(pattern.re);
      if (match) {
        const raw = match[1] || match[0];
        result.push({
          type: pattern.type,
          severity: pattern.severity || "LOW",
          line: i + 1,
          masked: maskValue(raw),
        });
      }
    }
  }
  return result;
}

The output stores the line number and classification, not a copy of the whole source file. The masking function keeps four characters at each end and replaces the middle with a bounded run of asterisks:

function maskValue(val) {
  if (val.length <= 8) return "****";
  return val.slice(0, 4) +
    "*".repeat(Math.min(val.length - 8, 20)) +
    val.slice(-4);
}

That is enough to recognize which credential was found without placing the full value in the results table or downloaded report. The report includes the type, severity, line, and masked value, plus a timestamp and summary counts.

Client-side is a useful boundary, not a security guarantee

The file upload uses FileReader.readAsText(file, "utf-8"); the scanner never calls an API or sends the content to a server. The privacy badge is therefore grounded in the implementation. A browser extension, injected script, or compromised machine can still read a page’s memory, so “client-side” should not be confused with a secure vault. I would still rotate a real credential immediately if it appears in a scan.

The severity counts are computed from the findings array:

const counts = computed(() => ({
  HIGH: findings.value.filter((f) => f.severity === "HIGH").length,
  MEDIUM: findings.value.filter((f) => f.severity === "MEDIUM").length,
  LOW: findings.value.filter((f) => f.severity === "LOW").length,
}));

The scan is explicit about where a result came from. A match carries the pattern’s human-readable type, the normalized severity, and i + 1 for a line number, so the review can jump back to the source instead of searching a giant report. After a file upload, the reader places the text into the same inputText ref and clears old findings; uploading a new file does not silently mix results from two files. Clicking Clear resets the text, findings, and scanned flag together.

That reset behavior is a small but important safety property. A user should not see yesterday’s finding labeled as the result of today’s clean file, and an empty input disables the scan button in the template. The report is generated from the current findings only, with new Date().toISOString() making its timestamp unambiguous across time zones.

Where regex reaches its edge

This is static matching. A fake test string with the right shape can be a false positive, while a newly introduced provider format, a split token, an encoded value, or a secret assembled at runtime can be missed. Because the code calls match on each pattern without a global flag, it records at most one match per pattern per line; repeated credentials of the same type on one line are not exhaustively listed. Generic patterns can also flag ordinary configuration values.

Those limitations are why “no known secret patterns detected” is not the same as “safe.” Use the result as a review queue, then inspect context, check repository history, revoke exposed credentials, and add a real pre-commit or CI scanner where the project needs one. I turned this implementation into a small free tool: API Secret Scanner.

Creator Audio Pre-Publish Health Check: Why LUFS Is Only One Warning

Joe Lin — Tue, 29 Sep 2026 13:00:04 +0000

Before publishing a video or podcast, I care less about whether the waveform looks “big” than whether the exported file behaves on another platform. Loudness, peak headroom, clipping, and DC offset answer different questions. The Creator Audio Pre-Publish Health Check puts those measurements together so a creator can catch an obvious problem before uploading.

The primary reader is a YouTuber, podcast editor, or musician who wants a fast browser-side preflight, not a replacement for a mastering meter. The useful takeaway is how the measurements are derived and why a green result still needs context. The product is a working example of Web Audio analysis, with explicit thresholds rather than a mysterious single score.

Decode the file locally, then inspect the samples

The upload accepts audio and video MIME types plus FLAC, OGG, and OPUS extensions. runAnalysis reads the selected file as an ArrayBuffer, creates an AudioContext at 48 kHz, and calls decodeAudioData:

const arrayBuffer = await selectedFile.value.arrayBuffer();
const audioCtx = new (window.AudioContext || window.webkitAudioContext)({ sampleRate: 48000 });

let audioBuffer;
try {
  audioBuffer = await audioCtx.decodeAudioData(arrayBuffer);
} catch {
  await audioCtx.close();
  throw new Error("decode");
}
await audioCtx.close();

After decoding, the code collects every channel with getChannelData. It computes the DC offset from channel zero, but checks clipping across all channels:

let dcSum = 0;
const len = channels[0].length;
for (let i = 0; i < len; i++) dcSum += channels[0][i];
const dcOffset = dcSum / len;

let clipCount = 0;
let totalSamples = 0;
for (const ch of channels) {
  for (let i = 0; i < ch.length; i++) {
    if (Math.abs(ch[i]) >= 0.99999) clipCount++;
    totalSamples++;
  }
}
const clippingRate = clipCount / totalSamples;

The threshold is close to the normalized 0 dBFS ceiling. It is a sample-level clipping indicator, useful for finding flat-topped digital audio, not proof that an analog stage or a codec will never distort.

The displayed peak is the largest decoded sample

The analyzer searches every channel for the greatest absolute sample and converts that amplitude to decibels:

let maxSample = 0;
for (const ch of channels) {
  for (let i = 0; i < ch.length; i++) {
    const abs = Math.abs(ch[i]);
    if (abs > maxSample) maxSample = abs;
  }
}
const truePeak = maxSample > 0 ? 20 * Math.log10(maxSample) : -Infinity;

The UI labels this value “True Peak” and advises staying at or below -1.0 dBTP. That is a practical safety target for lossy encoding, but the implementation is measuring the maximum decoded sample; it does not oversample and reconstruct inter-sample peaks. This distinction matters when comparing it with a professional true-peak meter. A file can pass this browser check and still reveal an inter-sample peak after conversion.

LUFS uses an offline filter pass

For loudness, calcLufs builds an OfflineAudioContext, copies at most two channels into a buffer, and processes them through two Biquad filters:

const numCh = Math.min(channels.length, 2);
const offlineCtx = new OfflineAudioContext(numCh, totalSamples, sampleRate);

const preFilter = offlineCtx.createBiquadFilter();
preFilter.type = "highshelf";
preFilter.frequency.value = 1681.974;
preFilter.gain.value = 3.999843853;

const rlbFilter = offlineCtx.createBiquadFilter();
rlbFilter.type = "highpass";
rlbFilter.frequency.value = 38.13547;
rlbFilter.Q.value = 0.5003270373;

It renders the filtered buffer, averages the squared samples, and returns -0.691 + 10 * Math.log10(meanSquare). The result is an approximation of an ITU-R BS.1770-style K-weighted integrated loudness. The platform comparison then uses configured targets: YouTube and Spotify at -14 LUFS, Apple Music at -16, Podcast at -16 with a wider tolerance, Instagram/TikTok/Facebook at -14, and EBU R128 at -23.

The status logic is intentionally simple. Loudness from -16 through -12 LUFS is marked good, values below -24 are a warning, and the middle region is over-limit. That makes the screen actionable for a preflight, while the platform cards show the different target and tolerance choices.

The result object also keeps duration, channel count, and sample rate alongside the headline metrics. Those fields are not decorative: a surprising channel count can explain a loudness mismatch, and a sample rate tells you what the browser actually decoded. The progress values are UI checkpoints rather than a measurement of remaining CPU time—5 before reading, 20 after the buffer is loaded, 50 after decoding, and 100 when analysis finishes—so a very long file can appear to pause while the offline render is still running.

Honest limits before publishing

Everything runs in the browser, but decoding a long, multichannel file still requires memory for the complete AudioBuffer and an offline render. A browser may reject a codec even when its extension looks supported, and the catch block reports a generic decode failure. The tool does not normalize or repair the file; it only measures the decoded data.

DC offset is calculated from the first channel and flagged when its absolute average reaches 0.01. Clipping is a percentage of samples at or above the threshold, not a duration-weighted perceptual measure. Most importantly, the LUFS filter and the sample peak calculation can differ from a DAW because of browser precision, sample-rate behavior, channel handling, and the lack of true-peak oversampling. I use the report to decide what to inspect next, then cross-check a broadcast or release master in a dedicated meter.

I turned this implementation into a small free tool: Creator Audio Pre-Publish Health Check.

Subtitle Timecode Fixer & Format Converter: What a Millisecond Offset Really Changes

Joe Lin — Wed, 16 Sep 2026 13:00:05 +0000

The most annoying subtitle bug is often a consistent one: every line is early by the same amount. Manually editing dozens of timestamps is risky, and converting between SRT, VTT, and ASS can introduce a second class of mistakes. I built the Subtitle Timecode Fixer & Format Converter around a simpler model: parse the timing into milliseconds, apply one offset, then render it back into the requested format.

This article is for a video editor, translator, or frontend developer who needs to repair a batch of subtitle cues without sending the file to a server. The takeaway is that a time shift is an arithmetic operation, but format conversion is a data-loss decision. The tool is a concrete browser implementation of both choices.

Detect the format before changing anything

The input textarea is watched with detectFormat, which looks for structural markers instead of trusting a filename:

function detectFormat() {
  const text = inputText.value.trim();
  if (!text) { detectedFormat.value = ""; return; }
  if (/^WEBVTT/m.test(text)) {
    detectedFormat.value = "VTT";
  } else if (/^[Ss]cript [Ii]nfo|^\[V4\+ [Ss]tyles\]|^Dialogue:/m.test(text)) {
    detectedFormat.value = "ASS/SSA";
  } else if (/^\d+\s*\n\d{2}:\d{2}:\d{2},\d{3}\s*-->/m.test(text)) {
    detectedFormat.value = "SRT";
  } else {
    detectedFormat.value = "";
  }
}

This is intentionally a format hint, not a full validator. A WebVTT header identifies VTT, a Dialogue: line is characteristic of ASS, and an SRT cue needs an index followed by a comma-separated timestamp range. If none match, processing stops with an unknown-format message rather than trying to “fix” arbitrary text.

Normalize timestamps to one unit

SRT and VTT have different separators, but the parser converts both into milliseconds. SRT splits hh:mm:ss,mmm, while VTT accepts either hh:mm:ss.mmm or the shorter mm:ss.mmm form:

function srtTimeToMs(ts) {
  const [hms, ms] = ts.split(",");
  const [h, m, s] = hms.split(":").map(Number);
  return (h * 3600 + m * 60 + s) * 1000 + Number(ms);
}

function vttTimeToMs(ts) {
  const parts = ts.split(":");
  let h = 0, m = 0, s = 0;
  if (parts.length === 3) {
    [h, m] = [Number(parts[0]), Number(parts[1])];
    s = parseFloat(parts[2]);
  } else {
    [m] = [Number(parts[0])];
    s = parseFloat(parts[1]);
  }
  return Math.round((h * 3600 + m * 60 + s) * 1000);
}

Once every entry has start and end values in the same unit, the offset is easy to apply:

entries = entries.map(e => ({
  ...e,
  start: Math.max(0, e.start + offset),
  end: Math.max(0, e.end + offset),
}));

The Math.max(0, ...) guard is important. Advancing subtitles by a negative value should not create a negative timestamp that cannot be represented by the output formatter. A positive value delays both boundaries, preserving each cue’s duration.

Rendering is where formats stop being equivalent

SRT rendering renumbers entries and writes comma milliseconds. VTT adds a WEBVTT header and uses periods. ASS keeps the original file lines and replaces only the start and end fields on Dialogue: lines:

const assLines = text.split("\n");
let entryIdx = 0;
result = assLines.map(line => {
  if (/^Dialogue:/.test(line) && entryIdx < entries.length) {
    const e = entries[entryIdx++];
    const fields = line.split(",");
    fields[1] = msToAssTime(e.start);
    fields[2] = msToAssTime(e.end);
    return fields.join(",");
  }
  return line;
}).join("\n");

For ASS-to-SRT or ASS-to-VTT conversion, the source extracts the text field, removes {...} override tags, and turns \N or \n into line breaks. That makes the plain subtitle readable, but it cannot preserve ASS fonts, colors, positioning, karaoke effects, or other styling in SRT/VTT. Keeping the original file is part of the workflow, not an optional precaution.

Thinking in milliseconds also makes the direction of the correction less mysterious. If the subtitle appears after the speaker, the subtitle is late and the offset should be negative. If the words appear before the audio, the offset is positive. The interface explains this beside the number input and uses a 100 ms step, but it does not try to estimate the offset from the media itself. The human still supplies the observed difference; the code’s job is to apply it consistently to every parsed cue.

Limits and useful edge cases

The SRT parser separates blocks on blank lines and finds the line containing -->; malformed cues are filtered if their start time becomes NaN. The VTT parser begins at the first timing line and collects text until a blank line, so unusual cue metadata or nonstandard formatting may not round-trip perfectly. ASS parsing accepts the specific Dialogue: layer,start,end,... shape used by the regular expression; comments and other event types are left alone.

The browser reads uploaded files with FileReader, copies results with navigator.clipboard, and downloads a generated text blob. That keeps subtitle content local, but clipboard permissions can still fail in a restricted browser context. Finally, a single constant offset cannot repair subtitles whose drift grows over time; that needs a time-stretch or manually corrected timeline, not this batch shift.

I turned this implementation into a small free tool: Subtitle Timecode Fixer & Format Converter.

Multi-Platform Text Length Previewer: Why SMS Character Counts Change

Joe Lin — Tue, 15 Sep 2026 13:00:04 +0000

I built the Multi-Platform Text Length Previewer for the moment when a sentence looks fine in one editor but gets clipped everywhere else. A social post, a search snippet, and an SMS campaign do not share one universal definition of “character.” The useful part is not memorizing a collection of limits; it is seeing which counting rule is being applied before the copy is published.

The primary reader here is a content developer or frontend engineer preparing the same message for several channels. The problem is easy to describe: a JavaScript .length check says the text fits, but a phone message becomes two SMS segments, or a search description displays only its first line. The implementation shows why those outcomes are different, and the previewer is a working example rather than a replacement for checking the final platform.

A platform card is a display rule, not a universal validator

The tool keeps its visible platform rules in one small array:

const PLATFORMS = [
  { id: "twitterPost",     icon: "𝕏", labelKey: "twitterLabel",    limit: 280 },
  { id: "googleTitle",     icon: "🔍", labelKey: "googleTitleLabel", limit: 60 },
  { id: "googleDesc",      icon: "🔍", labelKey: "googleDescLabel",  limit: 155 },
  { id: "youtubeTitle",    icon: "▶",  labelKey: "youtubeLabel",     limit: 60 },
  { id: "linkedinPost",    icon: "in", labelKey: "linkedinLabel",    limit: 180 },
  { id: "facebookPost",    icon: "f",  labelKey: "facebookLabel",    limit: 477 },
  { id: "instagramCaption",icon: "📸", labelKey: "instagramLabel",   limit: 125 },
];

Those numbers are used for a practical display preview. Each card reports used, calculates a percentage bar, and calls truncate to split the visible and overflow text:

function truncate(text, limit) {
  return text.length <= limit ? text : text.slice(0, limit);
}

function statusClass(platform) {
  const ratio = platform.used / platform.limit;
  if (ratio <= 0.85) return "status-ok";
  if (ratio <= 1.0) return "status-warn";
  return "status-over";
}

The 85% warning is deliberately separate from “over.” It gives a writer a signal before the hard cutoff, while still showing exactly what the code considers beyond the configured limit. The source also describes Google’s values as visible search cutoffs rather than storage limits. That distinction matters: a title can be stored successfully and still be shortened in a search result.

SMS is a different counting problem

SMS is where a plain character counter becomes misleading. The implementation first checks every code point against two sets: GSM7_BASIC and GSM7_EXT. An extended GSM character such as €, {, or | consumes two character units:

function calcGsmLength(text) {
  let len = 0;
  for (const ch of text) {
    if (GSM7_EXT.has(ch)) len += 2;
    else len += 1;
  }
  return len;
}

function isGsm7(text) {
  for (const ch of text) {
    if (!GSM7_BASIC.has(ch) && !GSM7_EXT.has(ch)) return false;
  }
  return true;
}

If every character is in the GSM sets, one segment has capacity 160 and multipart messages use 153 units per segment. Otherwise the tool switches to Unicode counting: 70 units for one segment and 67 per multipart segment. It uses [...text].length for that Unicode count, which iterates by code point instead of splitting UTF-16 surrogate pairs. The result is then computed with Math.ceil(gsmLen / multiSegSize) after the first segment threshold is crossed.

This is why adding one character can change more than the “characters used” number. A curly brace costs two GSM units, while a single CJK character switches the whole message to the smaller Unicode capacity. The interface also builds visual segment cards, so the writer can inspect the actual chunks rather than only seeing a total.

The UI updates from one reactive source

There is no separate “run” button for platform previews. The textarea is bound to inputText, and a computed value maps the same string across all platform definitions:

const platformPreviews = computed(() =>
  PLATFORMS.map(p => ({
    ...p,
    name: platformName(p.id),
    used: inputText.value.length,
  }))
);

That makes the preview easy to reason about: one edit produces one new array of cards, and the SMS panel independently derives its encoding and segment data from the same inputText. The visible overflow is styled rather than silently discarded, which is useful when a sentence’s important qualifier is the part that falls outside a limit.

There is also a subtle mismatch worth noticing. The platform cards use JavaScript text.length and slice, while SMS uses code-point iteration or GSM septet units. Emojis, some symbols, and other non-BMP characters can therefore occupy two UTF-16 code units in a platform card even though the SMS branch counts them as one Unicode code point. That is not an accidental inconsistency; it reflects different approximations, but it means a card’s “characters” number should not be treated as an SMS billable-unit count.

Limits and the final check

The limits are maintained as product data, not fetched from each platform. Search engines, social networks, fonts, languages, and devices can change how much text is displayed. The source explicitly calls its truncation approximate. text.slice(limit) also does not understand words, grapheme clusters, or platform-specific link previews, so a cutoff can occur in the middle of a word or a visually combined emoji sequence.

The SMS visual splitter is described as an approximation too. For GSM it accounts for extended characters while filling each 153-unit chunk; for Unicode it slices an array of code points. It cannot model carrier concatenation details or every renderer’s treatment of line breaks. I use the output to catch obvious surprises, then paste the final copy into the actual publishing surface.

I turned this implementation into a small free tool: Multi-Platform Text Length Previewer.

How a Caffeine Tracker Estimates What Is Still in Your System

Joe Lin — Mon, 14 Sep 2026 13:00:07 +0000

A caffeine log is easy to misunderstand if it only shows today's total. Two drinks consumed hours apart do not contribute equally to what remains now. I built this tracker as a manual log plus a decay curve, not as an always-on monitor, so the calculation stays explicit about what it knows. The useful implementation lesson is to keep dose, time, half-life, and display thresholds separate instead of hiding everything in a single “daily total.”

Each drink contributes an exponentially decaying dose

The page includes presets for coffee, espresso, black tea, matcha, energy drinks, cola, and a custom dose. For every stored record, the residual calculation applies a half-life:

const halfLife = Math.max(0.1,
  Number(halfLifeHours.value) || 5) * MS_PER_HOUR;

return records.value.reduce((sum, record) => {
  if (ts < record.intakeTime) return sum;
  return sum + record.mg * Math.pow(
    0.5, (ts - record.intakeTime) / halfLife
  );
}, 0);

The equation says that after one half-life, half a recorded dose remains; after two, one quarter remains. A 100 mg drink with the default five-hour half-life contributes about 50 mg five hours later and 25 mg ten hours later. If another 95 mg coffee was consumed in between, the current estimate is the sum of both residuals, not the decay of whichever drink was latest.

The default half-life is five hours, but it is a user-editable assumption. Math.max(0.1, ...) prevents a zero denominator, and future records are ignored when the chart asks for a timestamp before intake. The code stores times as millisecond timestamps, while the form parses a datetime-local value into a timestamp; that keeps the decay formula independent from how a browser formats dates.

What “today” means in this UI

The tracker reports a daily intake total based on the local date key of each recorded timestamp. That is different from residual caffeine, which can include late-night drinks from the previous local date. Records are retained while their age is under 48 hours, so caffeine from last night is not dropped at midnight just because the calendar label changed.

This distinction prevents a common misleading display. Someone can have a low “today” total and still have substantial residual caffeine from yesterday evening. Conversely, a large morning dose can count toward today's total while decaying through the afternoon. The page is not reading a sensor; it is adding only the records the user entered.

The 24-hour chart is a projection of known records

The component refreshes nowTick every minute and builds Chart.js data from the same residualAt function used for the current estimate. It samples the next 24 hours at 30-minute intervals:

function chartLabelsAndData() {
  const labels = [];
  const data = [];
  const start = nowTick.value;
  for (let i = 0; i <= 48; i++) {
    const ts = start + i * 30 * 60 * 1000;
    labels.push(formatDateTime(ts));
    data.push(Math.round(residualAt(ts) * 10) / 10);
  }
  return { labels, data };
}

There are 49 points including both endpoints, which covers 24 hours without implying minute-level precision. Changing the half-life or adding a drink changes the curve because there is no second projection formula to keep in sync. The chart's second dataset repeats the configured sleep threshold across every sample.

That bedtime line defaults to 50 mg and is a reference threshold. The daily status uses a separate 400 mg adult reference. Keeping 50 and 400 distinct matters: one is a user-facing planning line for bedtime, while the other is a broad daily reference, not a personalized medical safety boundary. A chart crossing 50 does not diagnose insomnia or prove that sleep will be affected.

For a concrete walkthrough, log a 95 mg coffee at 8:00 and a 63 mg espresso at 13:00 with the five-hour half-life. At 18:00 the coffee contributes roughly 47.5 mg and the espresso roughly 53.6 mg, so the total is about 101 mg before rounding. The chart then projects both curves forward and lets you see when their sum falls below the selected reference. It is the additive shape, not a claim that the body follows a perfect single-compartment model, that makes multiple entries easier to reason about.

The graph is intentionally sampled rather than continuously calculated for display. There are 49 points including the current time and the 24-hour endpoint, one every 30 minutes. That is enough resolution for a planning curve and keeps the chart readable on a phone. The underlying residualAt function still accepts arbitrary timestamps, so the current number and each chart point use the same decay logic.

Manual data is a real edge case

Records, half-life, and threshold are saved under begoodtool_caffeineTrackerCalculator_v1 in localStorage. Reloading can restore them, but closing the page stops the minute refresh and a forgotten drink never reaches the curve. The 48-hour filter also means old records are deliberately removed from the active model rather than being treated as permanent history.

Preset caffeine values are approximate and serving sizes vary. Half-life varies with metabolism, medication, age, pregnancy, liver function, and individual sensitivity. The component explicitly warns that this is general information, not medical advice; people with health conditions or special circumstances should use qualified local guidance. I turned this manual model into a small free tool: Real-Time Caffeine Buildup Calculator.

How Expected Value Exposes the Break-Even Failure Rate of an Extended Warranty

Joe Lin — Sun, 13 Sep 2026 13:00:07 +0000

“Peace of mind” is real, but it is not the same thing as a positive financial expectation. I built this calculator to separate those questions: what is the expected covered loss, what does the warranty cost, and how likely would failure need to be before the math breaks even? The intended reader is comparing a real plan with a repair estimate and wants to see which assumptions drive the conclusion, not receive a fake certainty about whether every warranty is bad.

Calculate the claimable loss before applying probability

The form accepts warranty price, coverage months, estimated failure probability, repair cost, deductible, product price, and an optional claim limit. The component subtracts the deductible, clamps the result at zero, then applies the claim cap:

const grossLossAfterDeductible = computed(() =>
  Math.max(0, repairCost.value - deductible.value)
);
const claimableLoss = computed(() =>
  claimLimit.value > 0
    ? Math.min(grossLossAfterDeductible.value,
      claimLimit.value)
    : grossLossAfterDeductible.value
);

That ordering matters. For an 18,000 repair with a 1,000 deductible and a 15,000 claim limit, the loss after deductible is 17,000, so claimable loss is 15,000. The warranty does not magically reimburse the deductible. If the deductible is larger than the repair cost, the clamped loss is zero. If claim limit is zero, the source treats it as “no stated cap” rather than capping at nothing.

All monetary inputs pass through safeNumber, which clamps invalid and negative values to zero. Failure probability is clamped to 100% and converted to a fraction. The product price is collected for context and display, but it does not enter the expected-value equation. That is a useful reminder that an expensive product does not automatically make a repair claimable.

The two key equations are intentionally visible

Expected claim value is estimated failure probability multiplied by claimable loss. Net expected value subtracts the warranty price:

const probability = computed(() =>
  Math.min(100, safeNumber(form.value.failureRate)) / 100
);
const expectedClaimValue = computed(() =>
  probability.value * claimableLoss.value
);
const netEv = computed(() =>
  expectedClaimValue.value - warrantyCost.value
);
const breakEvenRate = computed(() =>
  claimableLoss.value <= 0
    ? null
    : (warrantyCost.value / claimableLoss.value) * 100
);

With a 3,990 warranty, 12% estimated failure probability, and 15,000 claimable loss, expected claim value is 1,800 and net EV is -2,190. The break-even failure probability is 26.6%, because 3990 / 15000 * 100 is the rate at which expected reimbursement equals price. This is not the probability that the device will fail; it is the threshold your estimate would need to cross under this simplified claim model.

The result card labels positive, negative, and near-break-even outcomes. “Near” uses a tolerance of the greater of 10 and 5% of warranty cost, so a small difference is not presented as a dramatic win. A second visual compares the user's estimate with the break-even rate. If claimable loss is zero, the marker is omitted and the result says there is no covered loss rather than dividing by zero.

Why the ordering and scope matter

Expected value is an average over repeated similar decisions. It does not predict the timing of one failure. A device can fail tomorrow, after the coverage period, or never fail. The model also treats the estimated failure probability as one event and does not add a second probability for approval, parts availability, or replacement depreciation.

Coverage months are input and shown as part of the decision context, but the arithmetic does not annualize the rate. Therefore a 12% estimate must already describe the selected coverage period. Mixing a one-year failure rate with a three-year warranty would produce a confident-looking but mismatched comparison. This is a limitation worth preserving rather than silently “fixing” with an invented hazard curve.

The break-even display is useful for sensitivity testing. Hold the warranty price at 3,990 and raise the claim limit from 5,000 to 15,000: the same price requires a much lower failure probability once more loss is actually claimable. Then increase the deductible and watch claimable loss fall. These experiments show why quoting a warranty price alone is not enough; the contract's deductible and cap are doing as much mathematical work as the probability.

One subtle input boundary is that the calculator does not infer a probability from the product price or coverage length. Coverage months appears in the form, but the expected-value calculation treats the supplied failure rate as already belonging to that coverage period. That keeps the formula inspectable, though it puts the responsibility on the reader to compare like with like. A warranty salesperson's annual failure statistic cannot be pasted into a multi-year scenario without first deciding how the periods relate.

The limitation is the point of the tool

The page does not contain a brand, store, or model failure-rate database. The reader supplies the probability and repair cost, while real policies may contain exclusions, service fees, depreciation, claim friction, waiting periods, and replacement rules. Product price is not a proxy for any of those details.

A negative EV result is not a command to reject coverage. Cash-flow risk, inconvenience, inability to self-insure, or strong risk aversion may justify paying for protection, but those are separate reasons from the arithmetic. I turned this decision model into a small free tool: Extended Warranty Calculator.

Why the Cheapest Meal Changes When You Price Your Own Time

Joe Lin — Sat, 12 Sep 2026 13:00:05 +0000

I kept seeing delivery-versus-cooking comparisons that stopped at the receipt total. That misses the time spent shopping, cooking, cleaning, waiting, or walking downstairs. I built this calculator to show both answers: cash-only cost and cash plus an explicit opportunity cost for time. It is for someone making an ordinary weeknight decision, not for proving that one lifestyle is always financially superior.

Keep money and time as separate computed totals

Delivery money is the meal amount plus delivery fee, service fee, and tip. Cooking money is ingredient cost. The component then computes time costs from minutes and the user's time value per hour:

const deliveryMoney = computed(() =>
  safeNumber(state.mealAmount)
  + safeNumber(state.deliveryFee)
  + safeNumber(state.serviceFee)
  + safeNumber(state.tip)
);
const cookingMoney = computed(() =>
  safeNumber(state.ingredientCost)
);
const deliveryTimeCost = computed(() =>
  (safeNumber(state.deliveryWaitMinutes) / 60)
  * safeNumber(state.timeValuePerHour)
);

Cooking time combines shopping, cooking, and cleaning. With a 220-per-hour time value, 12 minutes of delivery wait costs 44 in the model. Twenty minutes shopping, 25 cooking, and 10 cleaning costs 201.67 of time. Those numbers are not charges on a credit card; they are an explicit way to ask what else that time could have done.

The component keeps deliveryMoney, cookingMoney, deliveryTimeCost, and cookingTimeCost separate before adding them into deliveryTotal and cookingTotal. That makes the screen explain why a result changes. safeNumber clamps invalid and negative values to zero, which protects calculations but means a negative correction cannot represent a refund. Inputs are also not a nutrition or quality database; the user supplies the facts.

The “flip” is a useful diagnostic

The page compares moneyWinner from the cash difference with totalWinner from the money-plus-time difference. If they differ, it shows that the conclusion flipped after opportunity cost was added. Consider delivery cash of 340 and cooking cash of 120: cooking wins by 220. If cooking takes 55 minutes and delivery takes 12, the value of time can exceed that 220 gap, making delivery the lower total-cost choice.

That is not a universal answer about delivery. It is a signal that the decision depends on how the reader values a particular evening. Set time value to zero and the total-cost result collapses back to cash-only. Set it high and the model makes the trade-off visible rather than pretending the minutes are free. The chart draws both cash and total-cost bars so the flip is inspectable instead of buried in a sentence.

Frequency scaling and the investing extension

Weekly meal frequency is converted to monthly with weeklyMeals * 52 / 12 and to yearly with weeklyMeals * 52. The page multiplies the per-meal money difference, not the time difference, to produce monthly and yearly money projections:

const mealsPerMonth = computed(() =>
  safeNumber(state.weeklyMeals) * 52 / 12
);
const monthlyMoneyDiff = computed(() =>
  moneyDiff.value * mealsPerMonth.value
);
const yearlyMoneyDiff = computed(() =>
  moneyDiff.value * (safeNumber(state.weeklyMeals) * 52)
);
const monthlyMoneyDiffAbs = computed(() =>
  Math.abs(monthlyMoneyDiff.value)
);

The absolute values make the magnitude readable, while the companion label says which side saves money. For the investing extension, the component treats the absolute monthly money difference as the amount set aside. It does not pretend that time savings can be deposited:

const positiveMonthlySavings = computed(() =>
  Math.max(0, Math.abs(monthlyMoneyDiff.value))
);
const investFutureValue = computed(() => {
  const months = Math.max(1,
    Math.round(safeNumber(state.investYears) * 12));
  const monthlyRate =
    safeNumber(state.annualReturnRate) / 100 / 12;
  const pmt = positiveMonthlySavings.value;
  if (monthlyRate === 0) return pmt * months;
  return pmt * (((1 + monthlyRate) ** months - 1) /
    monthlyRate);
});

At zero return this is simply contribution times months. At a positive rate it is an ordinary end-of-period contribution formula. The “absolute” detail matters: even if delivery is cheaper, the extension displays the size of the difference as a hypothetical saving rather than passing a negative payment into the formula. It assumes the difference is actually invested every month.

A model cannot decide what cooking feels like

The calculator assumes every listed minute has the same time value and that a weekly frequency stays constant. It does not price leftovers, food waste, dishwashing fatigue, delivery quality, minimum order thresholds, subscriptions, grocery trips shared with other meals, or the enjoyment of cooking. A batch-cooking session may make the per-meal shopping time much lower than the form suggests; conversely, a single complicated recipe may make it much higher.

One practical way to use the model is to run two inputs for the same meal: a rushed weekday version and a relaxed weekend version. Keep the ingredient cost fixed, change the time fields, and see whether the winner flips. That preserves the source's intent better than averaging all evenings into one fictional meal, because the opportunity cost is usually situational. The displayed totals are rounded for currency, while the underlying computed values retain the minute-to-hour conversion.

The compound-interest extension is an assumption, not investment advice, and the return rate is not a forecast. The useful output is the sensitivity: try a lower time value, a realistic cleanup time, and a different frequency to see which assumptions change the answer. I turned these trade-offs into a small free tool: Delivery vs Cooking Cost Calculator.