DEV Community: Joe Lin

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.

How Browser Speech Scoring Turns a Tongue Twister Into an Accuracy Problem

Joe Lin — Fri, 11 Sep 2026 13:00:06 +0000

Timing someone reading a tongue twister is easy; deciding whether they said the words correctly is not. I built this challenge to use browser speech recognition when it exists, while keeping a timer-only mode when it does not. That fallback is important because a missing API should be visible, not disguised as a zero score. The article is for a frontend developer who wants useful pronunciation feedback without making the entire game depend on one browser feature.

Speech recognition is optional at runtime

The component checks both browser constructor names and also avoids touching window during server rendering:

function getRecognitionConstructor() {
  if (typeof window === "undefined") return null;
  return window.SpeechRecognition ||
    window.webkitSpeechRecognition || null;
}

When available, recognition uses the selected twister's language, continuous = false, interim results, and one alternative. Each result is concatenated into a transcript. The timer starts independently, so a user can still finish if recognition emits an error. If the constructor is missing or start() fails, the challenge remains usable as a timing-only round and explains why true scoring is unavailable.

The data contains 18 language choices, each with a language-specific recognition code and local phrases. That is more than a translation label: recognition engines use the code to choose an acoustic and language model, while a phrase such as “Peter Piper” should be compared to the exact English target rather than to a translated sentence. The English set includes “Peter Piper,” “Betty Botter,” “Woodchuck Challenge,” “Fuzzy Wuzzy,” and “Seashells on Seashore.”

Accuracy is normalized edit distance

Raw transcripts are messy. The scorer normalizes Unicode with NFKC, lowercases, removes whitespace and punctuation, and converts Chinese number characters before calculating Levenshtein distance:

function normalizeForScore(text) {
  return chineseNumeralsToArabic(
    String(text || "")
      .normalize("NFKC")
      .toLowerCase()
  )
    .replace(/[\u3000\s]+/g, "")
    .replace(/[.,!?;:'"()[\]{}，。！？；：「」『』（）、¿¡«»„“”‘’—–-]/g, "");
}

function calculateAccuracy(target, spoken) {
  const a = normalizeForScore(target);
  const b = normalizeForScore(spoken);
  if (!a || !b) return 0;
  return Math.max(0, Math.min(100,
    (1 - levenshtein(a, b) /
      Math.max(a.length, b.length)) * 100));
}

NFKC handles compatibility forms, while removing spaces means a recognition engine that inserts a different word boundary is not punished for formatting alone. Punctuation is also not the point of a tongue-twister drill. Levenshtein distance still catches insertions, deletions, and substitutions: if the target has ten normalized characters and two edits are needed, accuracy is 80%.

The final speech score weights accuracy at 78% and speed at 22%. Expected speaking time is Math.max(3, normalizedLength / 5). Speed is capped at zero when a reader takes longer than the expected pace by enough, but it cannot overwhelm a bad transcript. In other words, racing through the phrase does not compensate for saying a different phrase.

There is a subtle consequence of character-based expected time: a long phrase in a language with compact characters does not necessarily correspond to the same number of syllables as an English phrase. The estimate is intentionally a simple baseline, not a language model. The 78/22 weights are product choices that make correctness dominant and keep speed useful as a secondary practice signal.

Timing-only mode needs a separate meaning

A timing-only run records seconds and lets the reader choose a self-rating, but it does not invent transcript accuracy. That distinction is visible in the result mode: “no speech support” is not the same as “speech recognized with 0% accuracy.” It also keeps the game useful on browsers where microphone permission, implementation support, or network-backed recognition is unavailable.

Timing uses a monotonic performance clock when available and falls back to Date.now() only when necessary:

function nowMs() {
  if (typeof performance !== "undefined" &&
      performance.now) return performance.now();
  return Date.now();
}

This measures elapsed reading time without making a missing speech API fatal. A user can practice the phrase and compare times even when the browser cannot provide a transcript. The trade-off is that self-rating is subjective, so it should not be plotted beside machine accuracy as if both were equivalent measurements.

Best records stay scoped and local

The key for saved records combines the selected language and twister. On completion, the store updates only the best accuracy and best time for that pair:

const old = storeData[recordKey.value] || {};
const next = { ...old };
if (typeof accuracy === "number" &&
    (typeof old.bestAccuracy !== "number" ||
      accuracy > old.bestAccuracy)) {
  next.bestAccuracy = accuracy;
}
if (typeof old.bestTime !== "number" ||
    seconds < old.bestTime) {
  next.bestTime = seconds;
}
window.localStorage.setItem(STORAGE_KEY,
  JSON.stringify({ ...storeData, [recordKey.value]: next }));

That means an excellent English reading does not overwrite a French best, and a faster attempt does not erase a better accuracy. The storage is per browser profile and can disappear when site data is cleared. Speech recognition is also not deterministic: microphones, accents, permissions, browser support, network behavior, and selected language all affect transcripts. Even a correct human reading can receive a lower score, so this is practice feedback rather than a pronunciation test. I turned the challenge into a small free tool: Tongue Twister Challenge.

How to Generate a Single-Elimination Bracket When the Player Count Is Not a Power of Two

Joe Lin — Thu, 10 Sep 2026 13:00:03 +0000

Tournament brackets look like a list of matchups until the participant count is 6, 10, or 14. Then the missing slots need BYEs, seeds need a consistent distribution, and later rounds must wait for actual winners. I built this generator to make those rules visible instead of asking an organizer to fill gaps by hand. The interesting implementation problem is not drawing boxes; it is keeping identity, seeding, and progression correct when the tree is incomplete.

Normalize names before creating matches

The input accepts newlines, commas, and their full-width variants. Trimming and a Set remove duplicate tokens:

const namesList = computed(() => {
  const tokens = rawNames.value
    .split(/[\n,，;；]+/g)
    .map((s) => s.trim())
    .filter(Boolean);
  return [...new Set(tokens)];
});

The delimiter regex means a pasted list such as Ada, Ben；Cara becomes three names. Empty lines and accidental spaces disappear before bracket math starts. Set preserves the first occurrence while removing exact duplicate strings. That is a product decision as much as a parsing detail: two real players with the same name must add a team name or number themselves, or the generator cannot distinguish them.

Generation refuses fewer than two distinct names. That is better than drawing a one-person “final” and pretending it is a tournament. The original participant list remains text until generation, so editing the textarea does not unexpectedly mutate a bracket that people may already be using.

Build the next power-of-two bracket and place BYEs

Single-elimination trees are easiest to represent when the first round has a power-of-two number of slots. The helper finds that size:

function nextPowerOfTwo(n) {
  let size = 1;
  while (size < n) size *= 2;
  return size;
}

function seedOrder(size) {
  let order = [1, 2];
  while (order.length < size) {
    const nextSize = order.length * 2;
    order = order.flatMap((seed) =>
      [seed, nextSize + 1 - seed]);
  }
  return order.slice(0, size);
}

With six entrants, nextPowerOfTwo(6) returns eight, so two slots become BYEs. seedOrder(8) produces a mirrored sequence that places high seeds apart instead of putting seeds 1 and 2 into the same half. The generator maps a seed to an entrant when seed <= entrants.length; otherwise it creates { bye: true }.

The first-round matches are then paired. A match with one real player and one BYE auto-advances. A match with two real players waits for the organizer to click a winner. This distinction is important: a BYE is not a player and should never be selectable as champion. When a winner exists, the component writes it into Math.floor(m / 2) in the next round at m % 2, so match positions—not display text—carry the progression.

There are two seed modes. Shuffle uses a Fisher–Yates-style swap with Math.random(), then the same bracket logic handles the shuffled order. Ordered mode retains the input order before seeding. Neither mode claims official sport-specific seeding; this is a transparent small-event bracket, not a governing-body rules engine.

Winners update a tree, not a flat list

The bracket model keeps a global match index and round-local IDs. That lets the template render labels while selectedWinnerKeys records which participant was chosen for each match. Recomputing the bracket walks rounds from left to right, applies any automatic winner, reads the stored selection, and forwards the winner. If an earlier winner changes, later slots are recalculated instead of leaving stale names in the final.

For an eight-slot example, four first-round results populate two semifinal matches, and those populate one final. A match cannot be selected until it has two real players, which prevents an organizer from choosing a winner before the preceding round exists. This is a small state-machine rule that avoids many “why did the final contain a player who never won?” bugs.

The advancement state is recomputed from the first round forward rather than patched one slot at a time. That matters when an organizer changes an earlier winner: downstream matches are cleared and rebuilt from the new selection, so a participant from an abandoned path cannot remain stuck in a semifinal. It is a modest amount of recalculation for a small bracket, but it is much easier to reason about than trying to undo every dependent update.

Export is a second rendering path

The interactive bracket is regular Vue markup, but PNG export draws a separate canvas. The export computes card and round positions, creates a canvas at twice the logical width and height, then calls ctx.scale(2, 2) before drawing:

const width = padding * 2 + rounds.value.length * cardW
  + (rounds.value.length - 1) * roundGap;
const height = padding * 2
  + rounds.value[0].length * baseGap + 40;
const canvas = document.createElement("canvas");
canvas.width = width * 2;
canvas.height = height * 2;
const ctx = canvas.getContext("2d");
ctx.scale(2, 2);

The logical coordinates stay readable while the resulting PNG has more pixels on high-density screens. Printing uses a print area and hides inputs and controls through noPrint classes. This separate path means a CSS change to the interactive view does not automatically change the downloaded image, so both paths deserve a quick visual check.

The limitations are clear: this is single elimination only, no official seeding validation is performed, and shuffle uses browser pseudo-randomness. Participant text is local, but an exported PNG or printed sheet can be shared outside the browser. I turned this implementation into a small free tool: Tournament Bracket Generator.

How a hidden timer measures your sense of time with millisecond precision

Joe Lin — Wed, 09 Sep 2026 13:00:06 +0000

A visible countdown turns a ten-second challenge into a reaction test. I wanted the other version: start the clock, hide the elapsed value, and stop when your internal clock says the target has arrived. The implementation is tiny, but using the right browser clock and keeping the target hidden are what make the game meaningful. I wrote this as a small example for someone building a perception game where the measurement should describe the button press, not the user's ability to read a timer.

`performance.now()` measures the round

On start, the component chooses the target, clears the old result, records a monotonic start time, and marks the round as running:

function startChallenge() {
  if (!hasBrowser()) return;
  pickTarget();
  lastResult.value = null;
  startAt.value = performance.now();
  isRunning.value = true;
}

function stopChallenge() {
  if (!hasBrowser() || !isRunning.value) return;
  const elapsedMs = performance.now() - startAt.value;
  const targetMs = activeTargetSec.value * 1000;
  const errorMs = elapsedMs - targetMs;
  const errorPct = (errorMs / targetMs) * 100;
  // store elapsedMs, errorMs, and errorPct in the result
}

performance.now() is the important choice. It is intended for elapsed measurements and is not based on the calendar clock that can jump when the operating system synchronizes time. The result keeps milliseconds, then derives signed error and error percentage from the target duration. If a player stops at 9.842 seconds for a 10-second target, the error is -158 milliseconds and -1.58 percent; stopping at 10.3 seconds makes both values positive.

There is no interval ticking in the round itself. The page does not need to display “9, 8, 7” and accidentally teach the answer. The browser records a start reading and an end reading around the user's two clicks. The click event still has normal input latency, so this is a game measurement, not laboratory equipment.

Random targets are selected at start time

The fixed modes are 5, 10, and 30 seconds. Random mode samples from [5, 7, 10, 12, 15, 20, 30] inside pickTarget(), after Start is pressed:

const RANDOM_TARGETS = [5, 7, 10, 12, 15, 20, 30];

function pickTarget() {
  if (targetMode.value === "random") {
    activeTargetSec.value =
      RANDOM_TARGETS[Math.floor(Math.random() *
        RANDOM_TARGETS.length)];
    return;
  }
  activeTargetSec.value = Number(targetMode.value) || 10;
}

Selecting random at start prevents the player from memorizing a value while setting up. The active target can be shown in the pre-round UI for fixed modes, but the elapsed value disappears once the round is running. A 5-second attempt feels very different from a 30-second attempt: short rounds magnify click timing, while long rounds invite internal counting and drift. That is why comparisons are most useful within one mode.

The target is stored in each result along with the elapsed milliseconds, so a history row can honestly say whether an attempt was for 7 or 20 seconds. It would be a mistake to compare raw errors across targets without considering their scale: 200 milliseconds is 4% of five seconds but only about 0.67% of 30 seconds. The source keeps both errorMs and errorPct, allowing the interface to show the absolute miss while the rating logic uses the relative one.

The error bar is only a visualization:

const pct = Math.min(100,
  Math.abs(lastResult.value.errorPct) * 4);
return `${pct}%`;

It scales absolute error for a readable bar, caps at 100%, and does not alter the stored error or score. A large miss can therefore saturate the graphic without pretending that a 40% miss is equivalent to a 5% miss.

The rating thresholds are also separate from the bar. getRatingKey() uses absolute error in milliseconds: up to 50 ms is the top label, followed by 150, 400, and 1,000 ms boundaries. That makes the feedback easy to explain, while the percentage remains useful for comparing targets of different lengths. A 200 ms miss is 4% of five seconds but only about 0.67% of 30 seconds.

History is local and deliberately bounded

After a round, the component prepends the result to an array saved under begoodtool_tenSecondChallenge_v1. saveRecord keeps only the first 50 records. The screen derives recentRecords by taking the ten most recent, while bestRecord sorts all retained records by absolute error:

function saveRecord(record) {
  const records = [record, ...loadRecords()]
    .slice(0, HISTORY_LIMIT);
  saveRecords(records);
  historyVersion.value++;
}

const recentRecords = computed(() =>
  allRecords.value.slice(0, RECENT_LIMIT));

This keeps the page useful for practice without creating an account or sending timing data anywhere. Clearing history removes the local records and the current result. A private browsing session, cleared site data, or a different browser profile can remove the history, which is a privacy property and an inconvenience at the same time.

For a repeatable personal drill, I would keep the mode fixed, do ten attempts, and compare the distribution rather than celebrating one lucky click. Random mode is better for a party because nobody can settle into a memorized rhythm. Neither mode changes the underlying measurement: only the interval between the two button events is recorded.

The limitation is the point: focus, fatigue, music, counting strategy, display refresh, and the precision of a button press all affect the result. Randomness is not seeded, so repeated random-mode rounds are not reproducible experiments. I turned the experiment into a small free tool: 10-Second Intuition Timer Challenge.

How to split one monthly savings budget across competing goals

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

Saving for an emergency fund, a trip, and a home deposit at the same time creates a deceptively simple UI problem: percentages must be understandable, but each goal also needs a useful date. I built this allocator around explicit sliders so the reader can see exactly what happens when one goal gets more of the monthly budget. It is a cash-flow example for developers and planners who want priorities to remain visible instead of hidden inside an automatic “optimal” allocation.

Percentages are the source of truth

Each goal stores a target, current savings, optional target date, and an allocation percentage. The page derives the total percentage and monthly amount from those values:

const totalPercent = computed(() =>
  goals.value.reduce((sum, goal) =>
    sum + normalizedPercent(goal.percent), 0)
);
const totalAllocatedMonthly = computed(() =>
  ((Number(monthlySavings.value) || 0) *
    totalPercent.value) / 100
);

normalizedPercent rounds a value and clamps it between 0 and 100. The total can therefore be less than, equal to, or greater than 100. The status deliberately distinguishes under-allocation, exactly 100%, and over-allocation. Nothing silently normalizes the sliders, because silently changing a user's chosen priorities would make the result hard to trust. If monthly savings is 30,000 and two goals are 40% and 30%, the visible allocated total is 21,000 and the remaining 9,000 is not secretly assigned anywhere.

That choice also makes edge cases teachable. An over-allocated plan is not mathematically impossible—the UI is simply saying the percentages demand more than the stated monthly budget. A user can fix it by moving sliders, while a developer can test the warning without reverse-engineering a hidden redistribution algorithm.

Completion time comes from the remaining gap

For each goal, the remaining amount is target minus saved, clamped at zero. Monthly allocation is the budget multiplied by the goal percentage; the estimated month count is the ceiling of the gap divided by that allocation:

function remainingFor(goal) {
  return Math.max(0,
    (Number(goal.target) || 0) -
    (Number(goal.saved) || 0));
}

function monthsNeeded(goal) {
  const remaining = remainingFor(goal);
  if (remaining <= 0) return 0;
  const monthly = monthlyFor(goal);
  if (monthly <= 0) return Infinity;
  return Math.ceil(remaining / monthly);
}

If a goal targets 120,000, already has 30,000, and receives 12,000 per month, the gap is 90,000 and the estimate is eight months because Math.ceil(7.5) gives a whole deposit month. An already-reached goal reports zero months. A goal with no allocation reports that it cannot be estimated instead of producing a misleading infinite date. The optional target date is displayed as a comparison, not used to invent extra deposits.

The arithmetic assumes a regular deposit at the same frequency as the percentage. It does not prorate the first month or account for a deposit made on payday versus month-end. That simplicity is useful for explaining the result, but it is exactly why the number should be read as a schedule estimate.

The date field is intentionally not used to reverse-engineer a required percentage. A goal can display a personal target date while the calculator still reports the completion month implied by the current allocation. That avoids a surprising side effect where editing a date silently changes the user's priorities. If the target date is unrealistic, the mismatch is information to discuss: raise the monthly budget, change the percentage, extend the date, or accept that another goal must wait.

Presets change priorities, not the budget

“Split evenly” assigns the same percentage to every goal. The implementation uses integer division and hands the leftover percentage points to the earliest goals, so three goals become 34%, 33%, and 33% rather than 33.333 repeating values. The result is always a clean 100% when there is at least one goal.

“Split by target size” uses each goal's remaining gap as a weight, falling back from a zero remaining gap to the original target:

const weights = goals.value.map((goal) =>
  Math.max(0, remainingFor(goal) ||
    Number(goal.target) || 0));
const total = weights.reduce((sum, value) => sum + value, 0);
if (total <= 0) {
  distributeEvenly();
  return;
}
let used = 0;
goals.value.forEach((goal, index) => {
  goal.percent = index === goals.value.length - 1
    ? Math.max(0, 100 - used)
    : Math.round((weights[index] / total) * 100);
  used += goal.percent;
});

The fallback matters when a goal is complete. Using only the remaining gap would give it zero weight, while a zero-target or fully saved sample could leave every weight at zero. Falling back to the original target preserves a meaningful preference; if even that is unavailable, the preset falls back to an even split. Rounding each early goal can drift from 100, so the last goal receives the exact remainder.

Storage and limitations

Goals and monthly savings are serialized to begoodtool_multiGoalSavingsAllocator_v1 in browser localStorage. Reloading the page preserves the list, but clearing site data, private browsing, or changing devices does not. The sample goals are loaded only when no saved state exists, which prevents a refresh from overwriting personal priorities.

This is allocation arithmetic, not an investment projection. It ignores interest, inflation, taxes, irregular deposits, and whether a target date is compatible with the chosen percentage. A visible under-allocation may be a deliberate cash reserve rather than a mistake. I turned this into a small free tool: Multi-Goal Savings Allocation Calculator.

Why comparing insurance deductibles needs shared random medical-spend paths

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

The hard part of comparing a high-deductible, low-premium plan with a low-deductible plan is not adding two premiums. Medical spending varies, and a fair comparison should expose both ordinary and expensive years. I built this simulator so both plans see the same generated spending path; otherwise random noise can make one plan look better simply because it received easier years. The useful audience is someone who can read a spreadsheet or a little JavaScript and wants to reason about uncertainty without mistaking a simulation for an insurer's forecast.

Generate one annual spend, then apply both plan rules

Annual spending uses a log-normal-style transformation. First, randomStandardNormal() makes a normal deviate with the Box-Muller transform. Then volatility becomes sigma, and the result is exponentiated and clamped:

function randomStandardNormal() {
  let u1 = Math.random();
  const u2 = Math.random();
  if (u1 <= 1e-12) u1 = 1e-12;
  return Math.sqrt(-2 * Math.log(u1)) *
    Math.cos(2 * Math.PI * u2);
}

function annualMedicalSpend(avg, volatilityPct) {
  const sigma = Math.max(0, volatilityPct || 0) / 100;
  if (sigma === 0) return Math.max(0, avg || 0);
  const z = randomStandardNormal();
  return Math.max(0, (avg || 0) *
    Math.exp(-0.5 * sigma * sigma + sigma * z));
}

The tiny u1 floor prevents Math.log(0). With volatility set to zero, the function returns the average instead of needlessly consuming random samples. With volatility enabled, spending is non-negative and usually clustered around ordinary values with a longer expensive tail. “Log-normal-style” is deliberate wording: it is a convenient shape for a toy model, not a claim that health expenses follow this exact distribution.

The Monte Carlo loop generates one spend per plan-year and sends that same number to both plans:

for (let r = 0; r < runs; r++) {
  let totalA = 0;
  let totalB = 0;
  for (let y = 0; y < years; y++) {
    const spend = annualMedicalSpend(state.avgSpend,
      state.spendVolatility);
    totalA += planOutOfPocket(state.planA, spend);
    totalB += planOutOfPocket(state.planB, spend);
  }
  planA[r] = totalA;
  planB[r] = totalB;
}

That shared path is the key comparison control. If Plan A and Plan B each generated their own random spending, the difference would mix policy design with unrelated luck. In one run, both see the same ordinary year, bad year, and expensive year; only premium, deductible, coinsurance, and cap rules differ.

Deductible, coinsurance, and cap have an order

planOutOfPocket starts with annual premium. Medical spending up to the deductible is paid fully by the member. Above it, the deductible is combined with the configured coinsurance share of the remainder. Finally, a positive out-of-pocket maximum caps that member portion:

function planOutOfPocket(plan, medicalSpend) {
  const premium = Math.max(0, plan.annualPremium || 0);
  const deductible = Math.max(0, plan.deductible || 0);
  const oopMax = Math.max(0, plan.oopMax || 0);
  const coinsurance =
    Math.min(100, Math.max(0, plan.coinsurance || 0)) / 100;
  let oop = medicalSpend <= deductible
    ? medicalSpend
    : deductible + (medicalSpend - deductible) * coinsurance;
  if (oopMax > 0) oop = Math.min(oop, oopMax);
  return premium + Math.max(0, oop);
}

For example, with a 3,000 deductible, 20% coinsurance, and 7,000 cap, a 1,500 spend produces 1,500 member cost before premium. A 13,000 spend produces 3,000 plus 20% of 10,000, or 5,000, still below the cap. The annual premium is added regardless of whether a claim happens. This is a simplified annual rule: it does not model service categories, network pricing, copays, or a deductible that resets on a different schedule.

Read distributions instead of chasing one winner

For each run, the component totals every simulated year's cost. The results are sorted to report mean, median, 10th percentile, 90th percentile, and the share of runs where Plan A is cheaper. The chart reuses those arrays, so it shows a distribution rather than a single break-even claim. A high-deductible plan may have the lower mean but a much wider high-cost tail; a richer plan may cost more in most routine paths while limiting unpleasant surprises.

Try 10 years and 5,000 runs, then rerun with volatility at zero. The zero-volatility version isolates policy math; the volatile version shows how premiums trade against exposure. Repeated clicks will not reproduce identical values because the source uses Math.random() and does not seed it. That is useful for seeing variability, but inconvenient for a reproducible audit.

There are also practical bounds behind the controls. The simulation enforces at least one year and at least 100 runs even if a malformed value reaches the calculation, while the normal selector offers 500 through 10,000 runs. More runs generally make the displayed distribution less noisy, but they do not repair a bad average-spend assumption. In other words, increasing computational effort cannot turn an invented input into reliable insurance underwriting data.

Honest inputs are part of the algorithm

The form asks for years, runs, average annual spending, volatility, and each plan's four parameters. It does not contain a disease-rate or insurer database. Outputs are conditional on those assumptions, and currency is not inherently tied to one country's policy vocabulary. Real policies can have exclusions, eligible-service rules, family deductibles, and claim limits this model cannot represent. It should support questions for an insurer, not replace policy wording or professional advice. I turned this experiment into a small free tool: Insurance Deductible Scenario Simulator.

How to calculate a no-income runway without pretending expenses are constant

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

When someone asks “how many months can I live without a salary?”, dividing savings by monthly expenses gives a useful first guess, but it hides two decisions: which expenses are essential and what happens to income during the transition. I built this calculator around explicit scenarios so a cautious budget and a current-lifestyle budget can be compared instead of blended into one optimistic number. This is aimed at anyone planning a resignation, layoff buffer, or career break and wanting to understand the model rather than trust one impressive number.

Net burn is the quantity that matters

Each scenario has savings, transition income, an annual savings rate, and four expense buckets: rent or mortgage, living costs, insurance, and other essentials. The calculation sums expenses, subtracts income, then clamps negative burn to zero:

const monthlyExpense = cleanNumber(clean.rent)
  + cleanNumber(clean.living)
  + cleanNumber(clean.insurance)
  + cleanNumber(clean.other);
const rawNetBurn = monthlyExpense - income;
const netBurn = Math.max(0, rawNetBurn);

Suppose the four buckets total 50,000 and temporary income is 12,000. The model calls the burn 38,000 per month. If income is 55,000, rawNetBurn is negative, but netBurn becomes zero. The result is labeled theoretically indefinite rather than claiming that savings become infinite. That distinction matters: a zero modeled burn means this particular set of assumptions does not consume the starting savings; it does not mean the person's life has no expenses.

Every numeric field passes through cleanNumber, which turns non-finite or non-positive values into zero. Annual rate is also capped at 100 percent. Those choices make pasted blanks and malformed input safe, but they also mean a typo can silently become zero. I would still review the displayed monthly expense before using the result for a real decision.

Daily simulation and the 30.4375-day compromise

For a finite runway, the component divides monthly net burn by DAYS_PER_MONTH, which is exactly 30.4375. It then simulates one day at a time. Interest is converted from the annual rate to a daily compound rate:

const dailyNetBurn = netBurn / DAYS_PER_MONTH;
const dailyRate = annualRate > 0
  ? Math.pow(1 + annualRate / 100, 1 / 365) - 1
  : 0;

let balance = savings;
let totalDays = 0;
while (balance > 0 && totalDays < 36500) {
  balance = balance * (1 + dailyRate) - dailyNetBurn;
  totalDays += 1;
}

Applying growth before that day's burn gives the balance a small amount of interest before expenses leave it. The loop stops once the balance is no longer positive or after 36,500 days, a defensive ten-year ceiling. The displayed runway converts the resulting days back into months and days using the same 30.4375 average. This is more honest than pretending every month has 30 days, but it is still an average: rent due dates, quarterly bills, and leap years are not modeled individually.

The zero date is calculated by adding the rounded simulated days to Date.now(). Treat it as a planning marker, not a promised payday. A real account may earn interest monthly, pay bills on different dates, or receive a severance payment that belongs in transition income.

The monthly preview is a second, bounded view

The result also builds balanceRows for a monthly preview. It uses a monthly rate and applies interest before subtracting the same monthly burn:

const monthlyRate = cleanNumber(scenario.annualRate) / 100 / 12;
let balance = savings;
const maxMonths = Math.min(36,
  Math.max(1, Math.ceil((totalDays || 0) / DAYS_PER_MONTH)));
for (let month = 1; month <= maxMonths; month++) {
  balance = Math.max(0, balance * (1 + monthlyRate) - netBurn);
  balanceRows.push({ month, balance });
  if (balance <= 0) break;
}

This can differ slightly from the daily answer because it is a monthly summary with a monthly rate, not a replay of every daily balance. The 36-month cap keeps the page readable and avoids pretending a long-horizon projection is precise. If the daily calculation says 14 months, the preview stops around that point; if a balance lasts longer, the preview intentionally shows only the first three years.

The two views answer slightly different questions. The daily loop is the source for the runway duration and zero date, while the rows are a communication layer for scanning how the balance changes month by month. That separation is useful when building a financial UI: a chart should not quietly become a second, conflicting calculator. If I changed the month preview to drive the headline number, I would also have to decide how to reconcile daily interest, bill timing, and the fractional average month.

Scenarios are saved locally so assumptions can evolve

The page supports adding, duplicating, deleting, clearing, and switching scenarios. A watcher serializes the scenario array to begoodtool_noIncomeRunwayCalculator_v1 in localStorage, and the comparison table runs the same calculation for every scenario. That makes “what if I cut rent?” a side-by-side change rather than a memory exercise. A useful walkthrough is to duplicate a baseline, set income to zero in one copy, then reduce living costs in another; the table exposes which assumption actually moves the zero date.

Important edges remain: positive cash flow is reported as indefinite, a zero-savings positive-burn case is zero days, annual taxes must be translated into a monthly bucket, and changing devices loses local scenarios. I turned this scenario model into a small free tool: No-Income Runway Calculator.

Why a Pomodoro timer needs a phase clock, not just a countdown

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

I built this Pomodoro timer for the moment when a simple countdown stops being enough. A useful session timer has to know whether it is work, a short break, or a long break, remember which task was completed, and survive the user switching tabs. The interesting part is keeping those concerns separate. The reader I had in mind was someone implementing a browser timer who has already discovered that setInterval is not a clock.

One state machine drives every phase

The component stores the current phase and the number of completed work sessions. Duration is derived from the phase, while the display only deals with remaining seconds:

const phase = ref("work"); // work | shortBreak | longBreak
const remainingSeconds = ref(25 * 60);
const completedWorkCount = ref(0);

const durationForPhase = (p) => {
  if (p === "work") return (Number(settings.workMin) || 1) * 60;
  if (p === "shortBreak") return (Number(settings.shortBreakMin) || 1) * 60;
  return (Number(settings.longBreakMin) || 1) * 60;
};

That small function is doing more than formatting. It gives every phase one source of truth, including the reset path and the settings watcher. Invalid or empty durations fall back to one minute, so a half-edited input cannot create a zero-length loop. The UI can still let people choose work, short-break, long-break, and rounds independently without duplicating conversion logic in several click handlers.

When a phase ends, the code increments the work count only for a completed work phase, then chooses a long break when the configured round count is reached. Breaks do not increment the count. That avoids the common bug where counting every transition makes the long break arrive early. After the long break, the count resets so the next work block starts at round one. Pausing clears the deadline but keeps the phase and remaining seconds, which makes Resume behave differently from Reset in a predictable way.

Measuring the deadline instead of trusting interval ticks

The timer keeps a phaseEndAt timestamp and calculates the remaining value from Date.now() on each tick. The interval is for refreshing the screen, not for measuring time:

const tick = () => {
  if (!isRunning.value || phaseEndAt === null) return;
  const rem = Math.max(0, Math.round((phaseEndAt - Date.now()) / 1000));
  remainingSeconds.value = rem;
  if (rem <= 0) completePhase();
};

const start = () => {
  if (isRunning.value) return;
  ensureAudioContext();
  isRunning.value = true;
  phaseEndAt = Date.now() + Math.max(0, remainingSeconds.value) * 1000;
  stopInterval();
  timerHandle = setInterval(tick, 250);
};

The interval runs every 250 milliseconds only to make the display feel responsive. If the browser throttles a background tab, callbacks may arrive late, but the next callback subtracts the current wall-clock time from the saved end time. A tick is not allowed to “owe” exactly one second simply because one callback happened. There is still a wall-clock caveat: a large system clock adjustment can affect Date.now(). For this productivity timer that trade-off is acceptable, and the deadline is much more robust than accumulating interval deltas.

The progress bar is derived from the same phase duration rather than from a second counter maintained by the template:

const progressPercent = computed(() => {
  const total = durationForPhase(phase.value);
  if (!total) return 0;
  const pct = (1 - remainingSeconds.value / total) * 100;
  return Math.min(100, Math.max(0, Math.round(pct)));
});

At a transition the component pauses, records a work phase if appropriate, plays a short Web Audio beep, sends a browser Notification when permission is available, applies the next phase, and starts again. The beep and notification are side effects; a permission denial must never prevent the state machine from moving on.

The log is a local product feature, not a server database

A completed work phase stores the trimmed task name, an ISO timestamp, and a date key in localStorage. The UI derives today's count, a seven-day trend, and recent records from that array. Settings and the last task are stored separately, so clearing history does not unexpectedly reset a user's preferred durations. A task name is captured when the phase finishes, not when the user merely presses Start, which keeps abandoned sessions out of the log.

Try a concrete setup: set work to 25 minutes, short break to 5, long break to 15, and four rounds. After the fourth work phase, the counter reaches four and the next phase is long break. If you change the durations while paused, the watcher recalculates the visible remaining seconds for the current phase; while running, it does not rewrite the active deadline underneath you.

That separation also makes the behavior testable: phase transitions can be checked with a fake clock, while local history and notification permissions can be tested as independent browser concerns. The timer does not need a server or a login to be useful.

The honest limitation is that local storage is per browser profile. Clearing site data, using private browsing, or changing devices removes the history. Notifications and audio also require browser permission and can be unavailable in some environments. I turned this implementation into a small free tool: Pomodoro Timer.