DEV Community: Vera Yang

I thought porting my margin-call calculator to short selling was a one-line sign flip. It wasn't even close.

Vera Yang — Tue, 11 Aug 2026 07:00:04 +0000

I already had a margin-call calculator for regular margin buying (the long side), so when someone asked for a short-selling version I figured it'd be a ten-minute job: take the existing ratio formula, flip a sign so the loss direction points up instead of down, done. It wasn't. Once I actually sat down to write the short-side math, I realized the "maintenance ratio" isn't a single universal equation at all — depending on which market's convention you're modeling, it's two structurally different formulas, and the code has to branch on which one applies before it can even ask "what price triggers a margin call."

Two regions, two different ratio formulas

The tool splits behavior on a locale check:

const isAsianMode = computed(() => {
  return ["tw", "cn", "kr"].includes(locale.value);
});

That one boolean decides which of two completely different maintenance-ratio formulas gets used:

const now_maintenance_ratio = computed(() => {
  if (!now_market_value.value) return 0;

  let totalAsset =
    old_market_value.value + self_provided.value + maintenance_margin.value;

  let res = 0;
  if (isAsianMode.value) {
    // Asia: total collateral / current market value (call below 130%)
    res = totalAsset / now_market_value.value;
  } else {
    // West: (total collateral - current market value) / current market value
    // i.e. equity / liability
    res = (totalAsset - now_market_value.value) / now_market_value.value;
  }

  return Math.floor(res * 100);
});

totalAsset is the same thing in both branches — proceeds from the short sale plus the initial margin you put up plus anything you've added since. What differs is the denominator relationship. The Asian-market version treats the ratio as "how much collateral do I have relative to what I owe," full stop, so it's always comfortably above 100% (the usual floor is 130%). The Western version subtracts the current market value first — it's computing account equity (what's left over after covering your short liability) as a fraction of the liability, which is why 25–40% is a normal maintenance floor there instead of 130%. Same underlying accounting, but they're not the same formula with a constant swapped — one has a subtraction the other doesn't.

That difference isn't cosmetic. It's why the component also switches default thresholds when you change language:

watch(
  locale,
  (newVal) => {
    if (["tw", "cn", "kr"].includes(newVal)) {
      maintenance_ratio.value = 130;
      target_maintenance_ratio.value = 167;
    } else {
      maintenance_ratio.value = 30; // Western-style equity %
      target_maintenance_ratio.value = 50;
    }
  },
  { immediate: true },
);

If you plugged a Taiwan-style 130% floor into the Western formula (or vice versa), the numbers would be nonsense — you'd either never trigger a call or trigger one immediately. The defaults aren't just localization polish; they exist because the underlying math actually changes shape.

Solving for the price, not just the ratio

The more useful number isn't "what's my ratio right now," it's "at what price do I get called." That means solving the ratio equation for price instead of evaluating it. For the Asian branch that's simple algebra:

Asset / Price = Ratio  =>  Price = Asset / Ratio

For the Western branch, the subtraction means an extra step:

(Asset - Price) / Price = Ratio
Asset / Price - 1 = Ratio
Price = Asset / (1 + Ratio)

Both show up almost verbatim in the code, just divided by quantity to turn total asset value back into a per-share price:

const gg_price = computed(() => {
  if (!sell_quantity.value) return 0;

  let totalAsset =
    old_market_value.value + self_provided.value + maintenance_margin.value;
  let ratioDecimal = maintenance_ratio.value / 100;
  let gg = 0;

  if (isAsianMode.value) {
    gg = totalAsset / ratioDecimal / sell_quantity.value;
  } else {
    gg = totalAsset / (1 + ratioDecimal) / sell_quantity.value;
  }

  return Math.ceil(gg * 100) / 100;
});

This is the actual mirror-image part, and it's a genuine inversion, not just a sign flip: in a long margin-call calculator the danger direction is the stock price falling (your collateral shrinks relative to your loan). Here now_market_value — the thing working against you — is now_price * sell_quantity, and it grows as price rises, because rising price means it costs more to buy back the shares you borrowed and sold. Same "collateral vs. liability" skeleton as the long-side tool, opposite trigger direction, and (for the Western branch) an extra subtraction that the long-side formula never needed.

Working out how much cash to inject to get back to a target ratio is the same algebra run in reverse — set the ratio equation equal to a target instead of the current value, then solve for the "add" term:

// Asian: (Asset + Add) / Price = Target  =>  Add = Price * Target - Asset
needValue = now_market_value.value * targetDecimal - totalAsset;
// Western: ((Asset + Add) - Price) / Price = Target  =>  Add = Price * (1 + Target) - Asset
needValue = now_market_value.value * (1 + targetDecimal) - totalAsset;

What this doesn't account for

The feature description says it outright: the calculation excludes fees and taxes. It also doesn't model the cost that's specific to shorting and doesn't exist on the long side at all — the daily stock-borrow fee you pay for as long as the position stays open. Every non-Asian language file mentions this in the intro copy as a caveat, but it's genuinely absent from the computation, not just undocumented; totalAsset never touches a daily accrual.

The other asymmetry is economic, not a code bug, but it's the reason the whole tool exists: a long position's maximum loss is capped (the stock can only fall to zero), while a short position's loss is theoretically unbounded, since price has no ceiling. The calculator will happily compute a "you get called at $X" number, but nothing in the math communicates that the position you're protecting has open-ended downside in a way a long position never does — that's on the person reading the result, not the formula.

One more small thing worth knowing if you go digging in the source yourself: the maintenance-ratio input has a locale-dependent minimum (:min="isAsianMode ? 100 : 0"), which quietly enforces that the Asian-mode floor can never be typed in below 100% — a sensible guard given that formula has no subtraction term to keep it in a sane range on its own.

I turned this into a small free tool if you want to plug in real numbers instead of tracing the algebra yourself: Short Selling Calculator. No sign-up, and if you're on the long side instead, there's a companion margin-call calculator linked from the same page.

Available in other languages

融券維持率計算機 — 繁體中文
融券维持率计算器 — 简体中文
Short Selling Calculator — English
空売り維持率計算機 — 日本語
공매도 담보비율 계산기 — 한국어
Calculateur Short Selling — Français
Калькулятор Шорта — Русский
Leerverkauf (Short) Rechner — Deutsch
Kalkulator Short Selling — Bahasa Indonesia
Calculadora de Venta en Corto — Español
Máy Tính Bán Khống — Tiếng Việt
เครื่องคำนวณ Short Sell — ไทย
Kalkulator Short Selling — Polski
Short Selling Hesaplayıcı — Türkçe
Calcolatore Short Selling — Italiano
Calculadora Short Selling — Português
Short Selling Calculator — Nederlands
Калькулятор Шорт — Українська

The shuffle in my memory-training game isn't fully random — and nobody would ever notice

Vera Yang — Mon, 10 Aug 2026 13:00:02 +0000

I built a small card-flip memory game a while back: nine tiles numbered 1–9 flash their numbers for ten seconds, then go blank, and you have to click them back in ascending order purely from memory of where each number was sitting. Recently I went back into the source to clean it up and actually read the shuffle function line by line instead of skimming it. Turns out it has a real bug — one that's completely invisible while playing, but is a textbook example of how easy it is to get a "just shuffle an array" loop subtly wrong.

It's not "repeat the sequence" — it's "reconstruct it from memory"

The game doesn't show you an order to repeat, like Simon. It shows you nine tiles in scrambled positions, each briefly displaying its number, and your job during recall is to click the tiles in ascending numeric order (1, 2, 3…9) even though the numbers are now hidden. The click handler is bound once, on the container, using event delegation:

box_num.addEventListener(
  "click",
  (addbox = (e) => {
    if (e.target.tagName.toLowerCase() === "div") {
      ccount.value++;
      if (Number(e.target.id) != ccount.value) {
        // wrong tile — game over
      } else {
        e.target.style.background = "#ff4e50";
        e.target.innerHTML = e.target.id;
        if (Number(e.target.id) == length) {
          // last tile clicked correctly — win
        }
      }
    }
  }),
);

Each tile's id was set to its real number when it was created (divtag.id = nums[key]), it just isn't displayed anymore. ccount counts how many correct clicks you've made in a row, and every click has to match ccount exactly — so there's no partial credit and no way to click out of order and self-correct. The tagName check exists because the listener sits on the parent #box_num, not on individual tiles, so any click that bubbles up from outside an actual .div_num (padding, gaps between tiles) has to be filtered out rather than miscounted as a wrong tile.

The shuffle that's almost, but not quite, Fisher-Yates

Before the tiles are drawn, the numbers get shuffled with this:

let nums = Array.from(Array(length + 1).keys()).slice(1); // [1, 2, ..., length]

for (let j, i = 0; i < length; i++) {
  j = Math.floor(Math.random() * i);
  [nums[i], nums[j]] = [nums[j], nums[i]];
}

That looks like the standard in-place swap shuffle, and for most of the array it behaves like one. But walk through the first two iterations by hand:

i = 0: j = Math.floor(Math.random() * 0), which is always 0. Swapping nums[0] with itself — a no-op.
i = 1: j = Math.floor(Math.random() * 1). Math.random() returns a value in [0, 1), so Math.random() * 1 is also in [0, 1), and Math.floor() of anything in [0, 1) is always 0. j isn't random at all here — it's a hardcoded 0 in disguise.

So the second tile always swaps with the first tile, every single game, regardless of the RNG. From i = 2 onward j does range properly over [0, i), so the bias fades out fast and by the time you're looking at nine tiles it's not something a human could ever detect just by playing — but it means the first position isn't shuffled with the same freedom as the rest. A correct inside-out Fisher-Yates needs j to range over [0, i] inclusive, not [0, i); missing that one boundary is exactly what turns "shuffle" into "shuffle, except the first step."

The on-screen timer only ever measures the recall phase

The ten-second memorization window and the timer you see on screen are two different clocks, and they don't overlap:

window.startTimer = () => {
  numTimeout = setInterval(() => {
    tt.value++;
    time.value = tt.value;
  }, 1000);
};

window.stopTimer = () => {
  tt.value = 0;
  ccount.value = 0;
  time.value = "0";
  if (numTimeout) {
    clearInterval(numTimeout);
    numTimeout = null;
  }
};

startTimer runs immediately when the tiles first appear, but stopTimer — which resets the counter to zero — fires again right when the ten seconds are up, just before the tiles go blank and the click listener gets attached. So the number you see counting up during recall never includes the memorization window; it's purely "how long did clicking the right sequence take you," which is also the number baked into the win message. It's a small design choice, but it's the reason the "success" time can be genuinely fast (2–3 seconds) even though the whole round took thirteen.

That reset function doing double duty (as both "pause between phases" and "reset on game over") is also why addbox — the click handler — is captured in an outer-scoped variable instead of being an anonymous inline function. The #box_num container itself is never destroyed between games, only its child tiles are cleared out, so on closeMask() the code has to explicitly call removeEventListener("click", addbox) using that exact same function reference. Without holding onto it, a second playthrough would stack a second click listener on top of the first, and every click would silently count twice.

Two things that look configurable but aren't

The shuffle function takes a length parameter, and num_click(length) reads like it's built to support different board sizes. In practice the template only ever calls num_click(9) — there's no way in the current UI to play a smaller or larger board, and the ten-second memorization window (RememberTime = 10) is a flat constant that doesn't scale with length either. So despite the code being written in a reusable, parameterized way, there's currently exactly one difficulty level.

The other honest gotcha: the tiles themselves are built with raw document.createElement and innerHTML calls straight into a #box_num div, sitting inside an otherwise normal Vue component. That works, but it means Vue's reactivity system has no idea those tiles exist — which is exactly why cleanup (removing the old listener, clearing innerHTML by hand) has to be done manually instead of just letting Vue's own re-render/unmount handle it.

I turned the cleaned-up version into a small free tool if you want to see whether you can beat the "less than 2 seconds" tier without tripping the shuffle's one deterministic swap: Memory Test & Training. No sign-up, just nine cards and a clock.

Available in other languages

記憶力測試訓練 — 繁體中文
记忆力测试训练 — 简体中文
Memory Test & Training — English
記憶力テスト＆トレーニング — 日本語
기억력 테스트 훈련 — 한국어
Entraînement de mémoire — Français
Тренировка памяти — Русский
Gedächtnistest & Training — Deutsch
Pelatihan Memori — Bahasa Indonesia
Entrenamiento de Prueba de Memoria — Español
Luyện Tập Kiểm Tra Trí Nhớ — Tiếng Việt
ฝึกและทดสอบความจำออนไลน์ — ไทย
Trening i Test Pamięci Online — Polski
Hafıza Testi Eğitimi — Türkçe
Allenamento Test di Memoria — Italiano
Teste e Treino de Memória — Português
Geheugentesttraining — Nederlands
Тренування Тесту Пам'яті — Українська

Why every "calories burned" calculator boils down to one formula (I found this out because my own copy button was lying to me)

Vera Yang — Mon, 10 Aug 2026 07:00:02 +0000

I built a little MET-based calorie table — type in your weight and how long you exercised, get calories burned for 178 different activities, from mountain biking to sitting on the couch. While testing it I clicked the calorie cell to copy the number to my clipboard, and the value that landed in my clipboard didn't match the number on screen. Not a rounding difference — a completely different number. Chasing that down taught me more about how these calculators actually work than building the formula did.

The whole calculator is one line of math

Every "calories burned" tool, no matter how many activities it lists, comes down to the same MET (Metabolic Equivalent of Task) formula: calories = MET × weight in kg × duration in hours. 1 MET is defined as the energy your body burns at rest — about 3.5 ml of oxygen per kg per minute — and every activity in the table just gets a multiplier of that baseline (walking is around 3, running 8 km/h is around 8.3, competitive rowing can be 12+).

In the component, weight and duration are the only two reactive inputs, and they get collapsed into one computed value that every row in the table reuses:

const weight = ref(60);
const weightUnit = ref("Kilos");
const duration = ref(10);

const MET_computed = computed(() => {
  let kg = weightUnit.value == "pounds" ? weight.value / 2.2 : weight.value;
  return (kg * duration.value) / 60;
});

MET_computed is just "weight in kg, converted to a per-hour basis" (dividing minutes by 60 turns duration into hours). Then for each of the 178 rows, the displayed calorie figure is simply MET_computed * item.MET — weight × time × that activity's multiplier. No per-activity logic, no special cases. One formula, reused 178 times with a different constant.

The number you see isn't the number you copy

Here's the bug that sent me digging. Each row has a click-to-copy cell for the calorie value:

<div
  class="tableGroup__item__cal"
  @click="copy(item.man)"
  :class="{ canCopy: item.man }"
>
  {{
    ((MET_computed * (item.MET * 10)) / 10)
      .toFixed(1)
      .replace(/\.?0+$/, "")
  }}
</div>

The text rendered on screen is the live calculation — it changes the instant you change your weight or duration. But the click handler copies item.man instead, which is a static field baked into the dataset for every single exercise, like this one for mountain biking:

{
  idx: "01009",
  group: "bicycle",
  man: "595",
  feman: "425",
  desc_en: "bicycling, mountain, general",
  MET: "8.5",
}

That 595 is a precomputed reference value — 8.5 MET × 70 kg × 1 hour = 595, the classic "average man" figure. feman (425) is the same math at 50 kg, the "average woman" reference. Those numbers exist because the underlying data was originally built as a static lookup table, and the live per-user calculation got layered on top of it later. If you leave the defaults at 60 kg and 10 minutes, the screen shows a small number based on your actual inputs, but the clipboard silently gives you the "70kg person exercising for an hour" reference instead. I left it as-is for now — fixing it means deciding whether man/feman are worth keeping around at all, since nothing else in the UI uses them.

The `* 10 / 10` that does nothing (and the regex that does)

That calorie expression has another detail worth pointing at: item.MET * 10 / 10. Multiplying by 10 and immediately dividing by 10 is mathematically a no-op — the only real effect is that item.MET (stored as a string like "8.5" in the dataset) gets forced into a number a step earlier than it strictly needs to be, since JavaScript's * operator already coerces strings automatically. My best guess, looking at it now, is that it's a leftover from an earlier version that rounded to the nearest tenth before this logic got simplified, and only half of the original line got deleted. It's harmless, so it stayed.

The part actually doing work is the tail end: .toFixed(1).replace(/\.?0+$/, ""). toFixed(1) always produces one decimal place, so a clean result like 85 comes out as "85.0". The regex strips trailing zeros (and the decimal point if nothing but zeros follows), turning "85.0" back into "85" while leaving a genuine decimal like "92.1" untouched. Small detail, but it's the difference between a table that looks hand-typed and one that visibly reeks of floating-point math.

Where this falls apart

MET values aren't measured on you — they're population averages from a published reference table (the Compendium of Physical Activities), tested on a mix of people under lab conditions. Two people doing the exact same 30 minutes of "moderate cycling" can burn meaningfully different amounts of energy depending on fitness level, technique, terrain, and even how their body regulates heat that day. The calculator can only ever give you an estimate built from weight and duration — it has no way to know if you're a beginner grinding through this activity for the first time or someone who does it every day. It also converts pounds to kilograms with a flat /2.2, not the more precise 2.20462, so heavier inputs in pounds drift by a small but nonzero amount. None of that makes the number useless, it just means "482 calories" should be read as "roughly this ballpark," not a lab-verified figure.

I cleaned up the version I built for this into a small free tool if you want to look up MET values for something specific without hunting through a PDF: Exercise Calorie Burn Calculator. No sign-up, works for any weight or duration you throw at it.

Available in other languages

各類運動熱量消耗表 — 繁體中文
运动热量消耗计算器 — 简体中文
Exercise Calorie Burn Calculator — English
運動消費カロリー計算機 — 日本語
운동 칼로리 소모 계산기 — 한국어
Calculateur de Calories Brûlées — Français
Расход калорий для упражнений — Русский
Kalorienverbrauchsrechner — Deutsch
Tabel Konsumsi Kalori — Bahasa Indonesia
Calculadora de Calorías Quemadas — Español
Bảng Tiêu Thụ Calo — Tiếng Việt
เครื่องคำนวณการเผาผลาญแคลอรี่ — ไทย
Kalkulator spalanych kalorii — Polski
Kalori Harcama Tablosu — Türkçe
Tabella del consumo calorico — Italiano
Calculadora de Calorias de Exercício — Português
Tabel van Calorieverbruik — Nederlands
Таблиця витрати калорій — Українська

Keep moving forward!

Vera Yang — Fri, 07 Aug 2026 08:17:27 +0000

YunTao Lin for BeGoodTool.com

Aug 7

How I built a highly profitable web platform, with zero backend code to keep my server costs at $0.

#webdev #frontend #architecture #indiehackers

10 min read

Dead-pixel test sites are just colored divs — the actual engineering problem is the Fullscreen API, not the colors

Vera Yang — Fri, 07 Aug 2026 07:00:03 +0000

I bought a used monitor a while back and did what everyone tells you to do first: pull up an online "dead pixel test" and cycle through some solid colors before deciding whether to keep it. It worked, but afterward I was curious why every single one of these tools looks identical — same handful of colors, same full-bleed look, no ads-covered corners, nothing fancy. So I built my own version to see what's actually involved, and it turns out almost none of the interesting work is in the colors. It's in getting a <div> to actually, reliably, cover the entire physical screen.

The colors are chosen, not decorative

The color grid isn't nine random swatches — each one is picked to isolate a specific kind of pixel failure:

const testModes = [
  { key: "red", style: { background: "#FF0000" } },
  { key: "green", style: { background: "#00FF00" } },
  { key: "blue", style: { background: "#0000FF" } },
  { key: "black", style: { background: "#000000" } },
  { key: "white", style: { background: "#FFFFFF" }, darkText: true },
  { key: "gray", style: { background: "#808080" } },
  { key: "yellow", style: { background: "#FFFF00" }, darkText: true },
  { key: "cyan", style: { background: "#00FFFF" }, darkText: true },
  { key: "magenta", style: { background: "#FF00FF" } },
];

Pure red, green, and blue each light up exactly one of a pixel's three sub-pixels — that's how you catch a sub-pixel that's stuck off (it stays dark against a color that should light it) or stuck permanently on in one channel (it shows up as a stray colored dot against black). Black and white check the opposite extremes: a "dead" pixel is usually defined as one that never lights at all, so a pure black fill is actually the easiest way to spot one — any point of light against total black is a defect, not a judgment call. Gray is there because it's R, G, and B mixed in equal parts; if the panel has any color tint or backlight unevenness, gray is where a human eye notices it fastest, since a slight tint is invisible against a color but obvious against neutral gray. Yellow, cyan, and magenta are two channels at once — useful for catching a sub-pixel that's stuck in a way pure R/G/B alone wouldn't reveal.

Then there are two patterns instead of flat colors:

{
  key: "gradient",
  style: { background: "linear-gradient(to right, #000000, #FFFFFF)" },
  isPattern: true,
},
{
  key: "checkerboard",
  style: {
    backgroundColor: "#fff",
    backgroundImage:
      "linear-gradient(45deg, #000 25%, transparent 25%, transparent 75%, #000 75%, #000), linear-gradient(45deg, #000 25%, transparent 25%, transparent 75%, #000 75%, #000)",
    backgroundSize: "20px 20px",
    backgroundPosition: "0 0, 10px 10px",
  },
  isPattern: true,
},

The gradient isn't for pixel defects at all — it's for banding. A cheap panel (or a panel driven at a reduced color depth) can't render a smooth 0–255 transition, so instead of a clean fade you see visible steps. The checkerboard does something similar for contrast and sharpness: alternating black/white squares make it obvious if edges look soft or if there's visible bleed between adjacent pixels, neither of which a flat color would show you.

Fullscreen isn't cosmetic — it's the whole point, and it's annoyingly stateful

The naive version of this tool is "put a colored div on the page." The actual requirement is that the color has to cover every pixel, including the space normally eaten by the browser's tab bar, address bar, and OS taskbar — otherwise you're not testing the whole panel. That means the Fullscreen API, not just big CSS:

const enterFullscreen = async (index = 0) => {
  currentIndex.value = index;
  const elem = fullscreenContainer.value;

  try {
    if (elem.requestFullscreen) {
      await elem.requestFullscreen();
    } else if (elem.webkitRequestFullscreen) {
      await elem.webkitRequestFullscreen();
    } else if (elem.msRequestFullscreen) {
      await elem.msRequestFullscreen();
    }

    isFullscreen.value = true;
    displayHint();
  } catch (err) {
    message.error(t("screenTest.fullscreenError"));
  }
};

Two things about this bit me before I wired it up correctly. First, requestFullscreen() returns a promise that rejects if it's not called as a direct result of a user gesture — you can't call it inside a setTimeout or on page load and expect it to work, which is exactly why the tool requires a click on a color swatch rather than trying to auto-launch. Second, there's no unprefixed-only world yet: Safari still wants webkitRequestFullscreen, and old Edge/IE wanted msRequestFullscreen, so the fallback chain isn't legacy cruft, it's still load-bearing.

The other half of the problem is knowing when you've left fullscreen — the user can hit Escape at any point, and the app needs to notice and reset its own state, not just rely on the browser's native exit animation:

const handleFullscreenChange = () => {
  if (
    !document.fullscreenElement &&
    !document.webkitIsFullScreen &&
    !document.mozFullScreen &&
    !document.msFullscreenElement
  ) {
    isFullscreen.value = false;
    stopAutoPlay();
  }
};

document.addEventListener("fullscreenchange", handleFullscreenChange);
document.addEventListener("webkitfullscreenchange", handleFullscreenChange);

Without that listener, pressing Escape exits the OS-level fullscreen but leaves the app thinking it's still showing the color tester, so the next click does something confusing. The fixed-position overlay underneath (position: fixed; width: 100vw; height: 100vh; z-index: 99999) is really just a safety net for browsers where the fullscreen request silently fails — it covers the viewport even without real fullscreen, just not the parts of the screen the browser chrome still owns.

Auto-play is a plain interval, not a rendering-timed loop

The "auto play" button just steps through the color list on a timer:

const startAutoPlay = () => {
  isAutoPlaying.value = true;
  enterFullscreen(0);
  autoPlayTimer = setInterval(() => {
    nextColor();
  }, 3000);
};

I want to flag what this isn't, because it's tempting to assume any color-cycling tool is secretly doing frame-rate or response-time measurement with requestAnimationFrame. It's not — there's no timing measurement here at all, just "switch to the next color every 3 seconds" so you can stand back and watch the whole panel without touching anything. setInterval is fine for that because nobody's timing precision matters at a 3-second cadence; it would be the wrong tool if you were trying to measure actual pixel response time or refresh-rate behavior, which needs frame-accurate deltas, not a coarse timer that browsers are free to throttle when a tab is backgrounded.

What this can't actually tell you

A couple of honest gaps, since a full-screen color page will always be a cheap proxy for real display measurement, not a replacement for it:

The colors you see aren't calibrated. #FF0000 is just a CSS value — what actually hits your eyes depends on the OS color profile, the monitor's own color space, whether a blue-light filter or "night mode" is active, and how the GPU compositor happens to render it. Two perfectly healthy panels can render "pure red" slightly differently; this tool can't and doesn't try to correct for that.
It only catches what a human eye can see in real time. A pixel that's stuck a very slightly wrong shade, viewing-angle color shift on cheaper IPS/VA panels, or backlight bleed that only shows up at specific brightness levels are all things a careful look under the right lighting conditions will catch far better than a quick scroll through nine colors.
Fullscreen support is inconsistent across mobile browsers. Some mobile Safari versions restrict or ignore requestFullscreen() on arbitrary elements entirely, so on iOS you may just get the fixed-overlay fallback rather than true fullscreen, meaning the OS status bar area doesn't actually get tested.

None of that makes it useless — it's still the fastest way to catch the obvious stuff (a fully dead pixel, an obviously stuck one, ugly gradient banding) before you decide whether a monitor is worth returning. I turned the version I built into a small free tool: Screen Test Tool. No install, no sign-up, just click a color and go fullscreen.

Available in other languages

螢幕測試工具 — 繁體中文
屏幕测试工具 — 简体中文
Screen Test Tool — English
画面テストツール — 日本語
화면 테스트 도구 — 한국어
Outil de Test d'Écran — Français
Инструмент Тестирования Экрана — Русский
Bildschirmtest-Tool — Deutsch
Alat Tes Layar — Bahasa Indonesia
Herramienta de Prueba de Pantalla — Español
Công Cụ Kiểm Tra Màn Hình — Tiếng Việt
เครื่องมือทดสอบหน้าจอ — ไทย
Narzędzie do Testowania Ekranu — Polski
Ekran Test Aracı — Türkçe
Strumento di Test dello Schermo — Italiano
Ferramenta de Teste de Tela — Português
Schermtesttool — Nederlands
Інструмент Тестування Екрану — Українська

Generating unique random numbers is easy — swapping min and max broke my own validation

Vera Yang — Fri, 07 Aug 2026 05:44:32 +0000

I put together a small number picker for an office raffle: type a minimum, type a maximum, hit generate, optionally pull several numbers with no repeats so you can draw multiple winners at once. It felt like a five-minute job. It mostly was — right up until I typed the range in backwards and the tool told me a perfectly valid request was impossible.

Letting min and max be typed in either order

The core random-pick function doesn't trust that the "minimum" field actually holds the smaller number:

function random() {
  let real_min = Math.min(min.value, max.value);
  let real_max = Math.max(min.value, max.value);
  let real_res =
    Math.floor(Math.random() * (real_max - real_min + 1)) + real_min;
  return real_res;
}

Math.min/Math.max normalize the two inputs before doing anything else, so if you type 99 into "min" and 1 into "max," it just works — no error telling you to swap the fields. The actual random pick is the standard inclusive-integer-range formula: Math.random() gives you [0, 1), multiplying by (range + 1) and flooring spreads that across every integer in the range with equal probability, then you shift up by the minimum. At the range sizes this tool deals with (double-digit or triple-digit spans), there's no meaningful Math.random() bias to worry about — that only becomes a real concern at ranges in the billions, where floating-point precision starts running out of distinct multiples.

The validation check that forgot about the swap

Here's where it got interesting. The "generate multiple, no duplicates" path validates the range before generating anything:

function getRandom() {
  let real_res = [];
  if (max.value - min.value + 1 < multiple.value) {
    return alert(t("random.error1"));
  }
  if (isMultiple.value) {
    if (multiple.value * 1 > 100) multiple.value = 100;
    for (let i = 0; i < multiple.value; i++) {
      let now = random();
      if (!real_res.includes(now)) {
        real_res.push(now);
      } else {
        i--;
      }
    }
  }
  ...

Look closely at that first if. It computes max.value - min.value + 1 — the raw field values, with no Math.min/Math.max normalization. random() happily tolerates a swapped min/max, but this check doesn't. Type min=99, max=1, ask for 5 unique numbers, and the check computes 1 - 99 + 1 = -97, which is less than 5, so it rejects a request that's actually completely fine — there are 99 valid numbers to draw from. The tool is inconsistent with itself: it's forgiving about swapped input everywhere else, then strict about it in exactly the one place where being strict produces a wrong answer.

Retry until it's unique, not shuffle-and-slice

The no-duplicates mode itself is worth a second look, because there are two very different ways to implement "give me N unique numbers from a range," and this uses the simpler-sounding one:

for (let i = 0; i < multiple.value; i++) {
  let now = random();
  if (!real_res.includes(now)) {
    real_res.push(now);
  } else {
    i--;
  }
}

This is rejection sampling: draw a number, check if it's already in the result array, and if it is, decrement the loop counter so the same slot gets tried again. It's unbiased — every still-available number is equally likely on each draw — and it needs zero extra memory beyond the result array itself.

The alternative would be shuffle-and-slice: build an array of the entire range, Fisher–Yates shuffle it, and take the first N. That's guaranteed to finish in time proportional to the range size no matter what, but it has to allocate an array covering the whole range even if you only want 3 numbers out of it.

Retry-until-unique flips that trade-off: cheap when N is small relative to the range, but it gets worse the closer N gets to the range size. Near the end, most of the range is already taken, so a growing fraction of draws come back as duplicates and get thrown away — the classic coupon-collector problem. On top of that, each real_res.includes(now) check is a linear scan, so as the result array grows the checks themselves get slower too. This tool caps multiple at 100, so in practice you'd have to set a very tight range (like 1–100 while asking for 100 numbers) to actually feel the slowdown — but it's the kind of thing that would matter a lot if someone reused this loop for a bigger range without reusing the cap.

Limitations

A few things worth knowing if you actually use this:

The min/max-swap validation bug above is real — if your "no duplicates" request gets rejected as impossible, try swapping which number you put in which field before assuming your range is actually too small.
That multiple.value * 1 > 100 clamp happens after the range check already ran with whatever number you originally typed, and it silently caps your request to 100 with no message. Ask for 500 unique numbers from a range of 10,000 and you'll quietly get 100 back, not 500.
Math.random() is a pseudorandom generator, not a cryptographically secure one. That's completely fine for raffles, games, and sampling, but it's not the right tool for generating anything security-sensitive, like password seeds or real-money draws.

I cleaned up the version I built for the raffle into a small free tool: Random Number Generator (RNG). No sign-up, works for any range you throw at it — just watch which field you put the bigger number in.

Available in other languages

隨機亂數產生器 — 繁體中文
在线随机数生成器 (RNG) — 简体中文
Random Number Generator (RNG) — English
乱数ジェネレーター (RNG) — 日本語
랜덤 숫자 생성기 — 한국어
Générateur de nombres aléatoires — Français
Генератор случайных чисел — Русский
Zufallszahlengenerator (RNG) — Deutsch
Pembangkit Angka Acak — Bahasa Indonesia
Generador de Números Aleatorios — Español
Trình Tạo Số Ngẫu Nhiên — Tiếng Việt
เครื่องมือสร้างเลขสุ่ม — ไทย
Generator Liczb Losowych — Polski
Rastgele Sayı Üretici — Türkçe
Generatore di Numeri Casuali — Italiano
Gerador de Números Aleatórios — Português
Willekeurige Nummergenerator — Nederlands
Генератор Випадкових Чисел — Українська

Why "must be subscribed to enter" is a checkbox I had to delete from a YouTube giveaway picker

Vera Yang — Thu, 06 Aug 2026 13:00:03 +0000

A YouTuber I know asked me to help pick a winner from a giveaway video fairly, because doing it by scrolling through comments and eyeballing one invites exactly the kind of "the mod's friend won" accusations you'd expect. I figured: grab the comments, roll a die, done — how hard can that be? Turns out, once you actually build it against the real YouTube Data API v3 instead of imagining how it probably works, there's pagination to chase, replies to exclude, duplicate commenters to catch, and one feature I had to rip out because it's technically impossible to build honestly.

Turning whatever URL someone pastes into a video ID

People paste video links in three different shapes — the desktop watch?v= link, the shortened youtu.be/ link, and the shorts/ link — and none of them go through a real URL parser, just string splitting on whichever marker is present:

let searchID = "";
if (searchKey.value.indexOf("v=") > -1) {
  searchID = searchKey.value.split("v=")[1];
} else if (searchKey.value.indexOf("youtu.be") > -1) {
  // https://youtu.be/KtkW3Hx0MvA
  searchID = searchKey.value.split("youtu.be/")[1];
} else if (searchKey.value.indexOf("shorts") > -1) {
  // https://www.youtube.com/shorts/QWUTKpZmSX0
  searchID = searchKey.value.split("shorts/")[1];
}

This works for a clean link, but it doesn't strip anything that comes after the ID. Paste a link with a timestamp (&t=45s) or a share-tracking suffix (?si=xyz) and that junk rides along as part of searchID, gets sent straight to the video-lookup call, and comes back as a generic "couldn't find that video" error — which is technically true but tells the organizer nothing about why. I didn't catch this until someone pasted a link straight from the YouTube mobile app's share sheet, which appends a tracking param by default.

Paginating through the comments API without losing your place

YouTube's commentThreads endpoint hands back comments in pages of up to 100, with a nextPageToken when there's more. The fetch function just calls itself with that token until there isn't one:

const getComment = (searchID, pageToken = null) => {
  isLoading.value = true;
  $API.youtubeData.youtube_getComment(searchID, pageToken).then((res) => {
    let { data } = res;
    if (data && data.items) {
      data.items.forEach((item) => {
        comentData.push({
          authorChannelId: item.snippet.topLevelComment.snippet.authorChannelId,
          authorDisplayName: item.snippet.topLevelComment.snippet.authorDisplayName,
          likeCount: item.snippet.topLevelComment.snippet.likeCount,
          textOriginal: item.snippet.topLevelComment.snippet.textOriginal,
          totalReplyCount: item.snippet.totalReplyCount,
          // ...a few more fields for the table
        });
      });
      if (data.nextPageToken) {
        getComment(searchID, data.nextPageToken);
      } else {
        isLoading.value = false;
      }
    }
  });
};

Notice everything is pulled from topLevelComment.snippet — never the replies themselves. totalReplyCount is captured just so it can be displayed in the table, but the actual reply text is never fetched. So if a giveaway's rule is "reply to the pinned comment to enter" rather than "leave a top-level comment," this tool structurally can't see those entries — it only ever eats top-level comments, which is also why the UI explicitly labels its count as "comments (excluding replies)."

One entry per commenter, not per comment

Before picking a winner, every comment runs through a filter chain, and the interesting one is duplicate removal:

const MessageFrom = new Set();
let filterList = comentData.filter(({ textDisplay, likeCount, authorChannelId, publishedAt }) => {
  if (mustContain.value && textDisplay.indexOf(mustContainValue.value) == -1) return false;
  if (mustLength.value && textDisplay.length < mustLengthValue.value) return false;
  if (mustLike.value && likeCount * 1 < mustLikeValue.value) return false;

  if (mustNoRepeat.value) {
    if (MessageFrom.has(authorChannelId)) {
      return false;
    } else {
      MessageFrom.add(authorChannelId);
    }
  }
  // ...date-range check
  return true;
});

Dedup is keyed on authorChannelId, not the display name — a name is just cosmetic text a user can change at any moment, so two comments from the same account could show two different names. The channel ID is the one thing that's actually stable. Since Array.filter walks the list in order, whichever comment from a given channel appears first is the one that survives; any later comment from that same account is silently dropped, keyword-spam or not.

The date-range check on the next line is the one piece of this function I'd flag if I were reviewing someone else's PR:

if (
  (mustDate.value &&
    new Date(new Date(mustDateStart.value).toDateString()).getTime() >
      new Date(publishedAt).getTime()) ||
  new Date(new Date(mustDateEnd.value).toDateString()).getTime() + 86400000 <
    new Date(publishedAt).getTime()
)
  return false;

The parentheses only wrap mustDate.value && startCheck — the end-date half of the || has no such guard, so it's evaluated regardless of whether the "date range" checkbox is even ticked. In practice it's harmless today only because an empty mustDateEnd produces Invalid Date, and NaN < anything is always false. But it's one stray value away from silently filtering out legitimate entries the moment someone fills in an end date without checking the box first.

Picking winners without replacement, the brute-force way

Once the pool is filtered, picking N winners isn't a shuffle — it's rejection sampling:

let real_index = [];
for (let i = 0; i < AwardNumber.value; i++) {
  let now = random(filterList.length);
  if (!real_index.includes(now)) {
    real_index.push(now);
  } else {
    i--; // collision — roll again
  }
}

function random(real_max) {
  return Math.floor(Math.random() * (real_max - 0)) + 0;
}

Roll a random index; if it's already been picked, back the loop counter up and roll again. It's not a proper Fisher–Yates partial shuffle, and it doesn't need to be — the code already checked earlier that filterList.length >= AwardNumber.value, so the loop is guaranteed to eventually land on N distinct indexes, and for a typical giveaway (a handful of winners out of hundreds of eligible comments) collisions are rare enough that a plain retry loop is simpler to read than a real shuffle and costs nothing anyone would notice.

Where this quietly falls short

There's a checkbox still sitting in the template, commented out, for "must be subscribed to the channel" — with a note next to it admitting that anyone who hasn't made their subscriptions public gets treated as unsubscribed. I left it disabled on purpose: YouTube's API has no endpoint that tells you "does channel A have viewer B subscribed," because a user's subscription list is private by default and there's no way to check it from public comment data without that specific user handing over their own OAuth token. Any tool claiming to enforce a subscribe-to-enter rule automatically is either lying or quietly excluding most of your actual subscribers.

A couple other honest gotchas: the comments API has a daily quota, so a video with an unusually large comment count can exhaust it mid-fetch and just stop with a generic error. And dedup by channel ID stops someone from commenting five times on one account, but does nothing to stop someone running the exact same giveaway comment from two separate Google accounts — there's no way to detect that from a comment thread alone.

I cleaned this up into a small free tool if you run YouTube giveaways and want to skip building your own version: YouTube Comment Picker Tool. No sign-up, just paste a video link.

Available in other languages

Youtube留言抽獎工具 — 繁體中文
YouTube评论抽奖工具 — 简体中文
YouTube Comment Picker Tool — English
YouTubeコメント抽選ツール — 日本語
Youtube 댓글 추첨 도구 — 한국어
Outil de tirage au sort de commentaires Youtube — Français
Инструмент розыгрыша комментариев на Youtube — Русский
YouTube-Kommentar-Picker-Tool — Deutsch
Alat Undian Komentar YouTube — Bahasa Indonesia
Selector de Comentarios de YouTube — Español
Công cụ chọn bình luận YouTube — Tiếng Việt
เครื่องมือจับรางวัลคอมเม้นต์ยูทูบ — ไทย
Losowanie Komentarzy YouTube — Polski
YouTube Yorum Çekiliş Aracı — Türkçe
Estrattore Commenti YouTube — Italiano
Sorteador de Comentários do YouTube — Português
YouTube Reactie Verloting Tool — Nederlands
Інструмент для витягування коментарів на YouTube — Українська

Why my auto-scrolling teleprompter froze at low speed (and the hidden float that fixed it)

Vera Yang — Thu, 06 Aug 2026 07:00:02 +0000

I built a browser-based teleprompter for a friend prepping a conference talk — paste your script, hit play, text scrolls up the screen while you read it into the camera. Simple enough. Except when she set the scroll speed slider all the way down (she's a slow, deliberate speaker), the text just... didn't move. Not slowly. Not at all. For a solid few seconds, nothing happened, then it would suddenly jump a pixel.

Turned out the bug wasn't in my speed math. It was in how scrollTop handles numbers smaller than 1.

requestAnimationFrame, not setInterval

The scroll loop is driven by requestAnimationFrame, not setInterval:

const scrollStep = () => {
  if (!isPlaying.value || !teleprompterViewRef.value) return;

  decimalScrollTop += speed.value * 0.05;
  teleprompterViewRef.value.scrollTop = decimalScrollTop;

  // ...end-of-script check omitted here...

  animationFrameId = requestAnimationFrame(scrollStep);
};

This matters more than it looks. setInterval(fn, 16) fires on a wall-clock timer regardless of whether the browser is actually ready to paint — if the tab is busy or the display can't keep up, intervals pile up and scrolling gets jerky. requestAnimationFrame instead asks the browser "call me right before your next repaint," so the scroll step is always synced to the actual frame rate. For something people are reading off in real time while talking to a camera, that smoothness is the whole point of the tool.

The decimal accumulator that makes slow speeds actually scroll

Here's the bug I mentioned. The speed slider is 1–100, and it's turned into pixels-per-frame with a flat multiplier: speed.value * 0.05. At speed 1, that's 0.05 pixels per frame. At ~60fps, that's 3 pixels per second — deliberately slow, for someone reading carefully.

The problem: element.scrollTop = 0.05 doesn't accumulate the way you'd hope. Browsers round or coerce scrollTop toward whole pixels, so if you add 0.05 to it every frame and read it back before adding again, you can lose the fractional remainder on every single frame — the number never crosses the 1px threshold, and the text never visibly moves.

The fix is a variable that lives outside the DOM entirely:

let decimalScrollTop = 0;

const scrollStep = () => {
  decimalScrollTop += speed.value * 0.05;
  teleprompterViewRef.value.scrollTop = decimalScrollTop;
  // ...
};

decimalScrollTop is a plain JS float, so it keeps every fractional pixel across frames — 0.05, 0.10, 0.15... — and only the DOM write gets truncated. The DOM forgets the remainder each frame; the JS variable never does. That's the entire fix: stop trusting the browser to remember fractions you handed it, and remember them yourself.

There's a second wrinkle tied to this. When you press play, the code resyncs the accumulator to wherever the element actually is first:

const startScrolling = () => {
  if (teleprompterViewRef.value) {
    decimalScrollTop = teleprompterViewRef.value.scrollTop;
  }
  isPlaying.value = true;
  animationFrameId = requestAnimationFrame(scrollStep);
};

Without that line, if someone manually scrolled the view while paused (or after seeking around), hitting play would snap back to wherever the stale accumulator last was, undoing their manual scroll. It only reads from the DOM at the moment playback starts, though — while it's actively playing, scrollStep overwrites scrollTop every frame, which means a mouse wheel nudge mid-playback gets silently stomped on the very next frame. You can only manually reposition while paused.

Mirror mode is one CSS property, applied twice

The feature that actually makes this a "teleprompter" and not just an autoscrolling text box is mirror mode — for people using real teleprompter rigs with a beam-splitter glass in front of the camera lens, where the display underneath has to show mirrored text for it to look correct once reflected. The whole implementation is a single transform:

.teleprompter-content {
  &.mirrored {
    transform: scaleX(-1);
  }
}

scaleX(-1) flips the element horizontally around its own vertical axis, which is exactly what a reflection off glass needs. The only non-obvious part is that it has to be applied to two elements independently — the script text and the countdown overlay:

<div class="countdown-overlay" :class="{ mirrored: isMirrored }">
<div class="teleprompter-content" :class="{ mirrored: isMirrored }">

If you only flip the content and forget the countdown, you get an unmirrored "3, 2, 1, Get Ready..." for a couple of seconds before the mirrored script kicks in — a small but very obvious continuity break if you're actually staring through a beam splitter at the time.

Limitations

A few things worth knowing if you're relying on this for a real shoot:

Backgrounding the tab pauses scrolling. Because the loop runs on requestAnimationFrame, browsers throttle or fully suspend it when the tab isn't visible/focused. If your recording setup involves switching windows (e.g. controlling OBS on another monitor while this runs unfocused), the scroll can stall completely until you click back into the tab. setInterval wouldn't have this problem — but it also wouldn't scroll as smoothly, which is the tradeoff.
Fullscreen isn't guaranteed. startTeleprompter calls requestFullscreen() and just logs a warning to the console if it's denied — it doesn't tell the user or fall back to anything. iOS Safari in particular doesn't support the Fullscreen API on arbitrary elements at all, so on an iPhone you'll never get a true fullscreen call to succeed. It still mostly works visually, because the teleprompter view is position: fixed at 100vw/100vh regardless of fullscreen state — but the browser's own UI chrome stays on screen.
The stop-at-the-end check is nested oddly. It first checks if you're within 20px of the bottom, and only inside that branch checks if you're within 1px of the true max scroll before actually stopping. In practice it works fine, but it means the "are we done" logic runs two slightly different distance checks back to back rather than one clean comparison — a good reminder that shipped code doesn't have to be elegant to work.

I turned this into a small free tool if you want to use it without wiring up your own requestAnimationFrame loop: Online Teleprompter. No sign-up, and your script never leaves your browser.

Available in other languages

線上提詞機 — 繁體中文
在线提词器 — 简体中文
Online Teleprompter — English
オンラインプロンプター — 日本語
온라인 텔레프롬프터 — 한국어
Téléprompteur En Ligne — Français
Онлайн-телесуфлер — Русский
Online Teleprompter — Deutsch
Teleprompter Online — Bahasa Indonesia
Teleprompter Online — Español
Máy Nhắc Chữ Online — Tiếng Việt
Teleprompter ออนไลน์ — ไทย
Teleprompter Online — Polski
Online Teleprompter — Türkçe
Teleprompter Online — Italiano
Teleprompter Online — Português
Online Teleprompter — Nederlands
Онлайн-телесуфлер — Українська

Why splitting text into sentences by punctuation breaks on "Dr. Smith" (I found out building a case converter)

Vera Yang — Wed, 05 Aug 2026 13:00:03 +0000

I added a "Sentence case" mode to a text case converter I was building — the kind of tool that turns pasted text into UPPERCASE, lowercase, Title Case, or "just capitalize the start of each sentence." The first three are one-liners. The fourth one, sentence case, is the one that quietly ate an afternoon, because "find the start of a sentence" turns out to be a much fuzzier problem than "find a period."

The `.`split() trap I started with

The file I was working in still has my first attempt sitting there, commented out, as a reminder of how I got it wrong:

// const capitalizeSentences = () => {
//   outputArea.value = inputArea.value.replace(
//     /.+?[\.\?\!](\s|$)/g,
//     function (txt) {
//       return txt.charAt(0).toUpperCase() + txt.substr(1).toLowerCase();
//     }
//   );
// };

It looks reasonable: lazily match everything up to a ., ?, or ! followed by whitespace (or end of string), then capitalize the first letter and lowercase everything else. The bug is in that last part — .toLowerCase() on the rest of the "sentence." Paste in "I love NASA missions. The ISS orbits every 90 minutes." and this version happily lowercases NASA and ISS along with everything else, because it doesn't know the difference between "the rest of a sentence" and "a proper noun or acronym that happens to not be first." It also had no concept of line breaks, so multi-paragraph text got flattened into a single blob-replace pass.

What actually shipped

The version that replaced it splits the problem into two passes instead of one regex:

function capitalizeSentences() {
  if (!inputArea.value) return "";

  const trimmedText = inputArea.value.trim();
  let group = trimmedText.split(/(?<=\n)/);
  group = group.map((item, index) => {
    const sentences = item.split(/(?<=[.?!])\s+/);
    const capitalizedSentences = sentences.map((sentence) => {
      const trimmedSentence = sentence.trim();
      const firstChar = trimmedSentence.charAt(0).toUpperCase();
      const restOfSentence = trimmedSentence.slice(1);
      return `${firstChar}${restOfSentence}`;
    });
    return capitalizedSentences.join(" ");
  });

  outputArea.value = group.join("\n");
}

Two things changed on purpose here. First, it splits on lines before splitting on sentences, using a lookbehind (?<=\n) so the newline stays attached to the chunk before it — that keeps paragraph structure intact instead of merging everything into one line. Second, and more importantly, sentence-splitting uses (?<=[.?!])\s+ instead of a consuming match. A lookbehind checks that a period/question mark/exclamation point came right before the split point without actually consuming it, so the punctuation stays glued to the end of the sentence it belongs to instead of getting lost or duplicated.

The other deliberate choice: it only touches firstChar. restOfSentence is used exactly as typed, no .toLowerCase() anywhere. That's what fixes the NASA/ISS problem from the naive version — if a word was already capitalized correctly, sentence case just leaves it alone instead of "helpfully" re-lowercasing it. It's a much dumber piece of code than the first attempt, and that's exactly why it behaves better.

Title Case has a completely different bug

Title Case (capitalize every word) doesn't need sentence boundaries at all — it just needs "word" boundaries, so it uses a much simpler regex:

const capitalizeWords = () => {
  outputArea.value = inputArea.value.replace(/\w\S*/g, function (txt) {
    return txt.charAt(0).toUpperCase() + txt.substr(1).toLowerCase();
  });
};

\w\S* means "a word character, followed by any run of non-whitespace." That last part is the trap: \S* doesn't stop at hyphens, apostrophes, or slashes, so "well-known" is matched as a single token, not two words. Capitalizing the first letter and lowercasing the rest turns it into "Well-known" instead of "Well-Known." Same story for anything with an internal capital that isn't at a word boundary a human would recognize — "NASA," for instance, becomes "Nasa," because the regex only sees one long non-whitespace run and blindly lowercases everything after its first character.

Where this still gets it wrong

Even the shipped sentence-case version has real gaps, because it has no idea what an abbreviation is:

Abbreviations fool it completely. "He is 6 ft. tall and strong." splits into "He is 6 ft." and "tall and strong." because a period followed by a space is treated as a sentence end every time — there's no list of "Dr.", "Mr.", "etc.", "e.g." that get skipped. The output capitalizes "Tall" as if it started a new sentence, because as far as the regex is concerned, it did.
Manual line wraps get treated as sentence boundaries too. Since each line is processed independently before being rejoined with \n, a sentence that was soft-wrapped across two lines without ending punctuation still gets its second line's first letter capitalized — even though grammatically it's the middle of a sentence, not the start of one.
One detail I noticed while writing localized copy for this tool: a couple of the translated marketing blurbs claim the sentence-case mode "recognizes common abbreviations (Dr., Mr., etc.) that don't end sentences." That line isn't true of the actual code above — there's no abbreviation list anywhere in it. It's a good reminder to go check the source before believing your own product description.

None of this makes it useless — it still saves you from manually re-capitalizing a pasted paragraph — but it's pattern-matching on punctuation, not parsing grammar, and it's worth knowing exactly where that line is.

I cleaned this up into a small free tool if you want to see the four modes side by side: Online Case Converter. No sign-up, just paste and click.

Available in other languages

英文大小寫轉換器 — 繁體中文
在线英文大小写转换器 — 简体中文
Online Case Converter — English
英語大文字小文字変換ツール — 日本語
영문 대소문자 변환기 — 한국어
Convertisseur de casse en anglais — Français
Конвертер регистра английского текста — Русский
Online-Konverter für Groß- und Kleinschreibung — Deutsch
Konverter Kasus Bahasa Inggris — Bahasa Indonesia
Convertidor de mayúsculas y minúsculas en inglés — Español
Bộ chuyển đổi kiểu chữ tiếng Anh — Tiếng Việt
เครื่องมือแปลงตัวพิมพ์ภาษาอังกฤษ — ไทย
Konwerter wielkości liter angielskich — Polski
İngilizce Büyük Küçük Harf Dönüştürücüsü — Türkçe
Convertitore di maiuscole e minuscole inglesi — Italiano
Conversor de Maiúsculas e Minúsculas em Inglês — Português
Engelse hoofdletteromzetter — Nederlands
Конвертер регістру англійського тексту — Українська

Why "the date exactly halfway between these two dates" doesn't always have one answer

Vera Yang — Wed, 05 Aug 2026 02:00:02 +0000

A friend asked me to help her find the exact midpoint between her and her partner's birthdays — apparently it's a whole thing people do, so they get a "shared" anniversary to celebrate every year. I figured it'd be a five-minute (date1 + date2) / 2 kind of problem. It's not. Building the date calculator that eventually answered her question, I ran into a genuinely annoying edge case: sometimes there just isn't a single day exactly in the middle.

Counting days between two dates without native `Date` math

The tool doesn't do new Date(a) - new Date(b) and divide by 86400000. It uses Luxon, parses both inputs as calendar dates, and asks Luxon for a calendar-aware diff:

let start = DateTime.fromISO(twoDate.date1);
let end = DateTime.fromISO(twoDate.date2);
let diffInMonths = end.diff(start, "days");
betweenRes.value = diffInMonths.toObject().days;

That variable name is not a typo I'm inventing for the article — it's sitting in the actual source, and I only noticed it while re-reading the file for this post. It's clearly a leftover from an earlier version of the function that computed something else, and it's now permanently doing a days diff while being named diffInMonths. Harmless, since .diff(start, "days") is unambiguous regardless of variable naming, but it's a good reminder that variable names lie the moment you stop actively maintaining them.

The more deliberate design choice is letting Luxon own the calendar math instead of hand-rolling it. Raw millisecond subtraction on native Date objects gets you into trouble the moment DST or timezone offsets are involved; a calendar-aware diff("days") over ISO date strings just counts calendar days, which is what a "how many days between these two dates" tool actually needs.

The fencepost question nobody asks out loud: is today "day 0" or "day 1"?

Say two dates are 3 days apart. Is the second date "the 3rd day after" the first, or "the 4th day" if you count the first date itself as day 1? This is the classic fencepost ambiguity, and the tool resolves it by spelling out its own convention in the result text instead of leaving it implicit:

between_res_detail:
  "以隔天為第1天來說，{date1}過後的第{betweenRes}天，就是{data2}。"
// "Counting the day after {date1} as day 1, the {betweenRes}th day after that is {data2}."

So a 3-day gap is explicitly defined as: the day after date1 is day 1, and date2 is day 3. It's a plain diff under the hood, but the UI text exists specifically so nobody has to guess whether the tool is counting inclusively or exclusively — which is exactly the kind of ambiguity that makes people distrust a date calculator's output even when the math is correct.

Finding the midpoint: what happens when the gap is an odd number of days

This is the part that actually stopped me. If two dates are, say, 6 days apart, the midpoint is clean: 3 days from either end. But if they're 7 days apart, dividing by 2 gives 3.5 — there is no calendar day at "3.5 days from the start." The tool handles this by branching on parity and returning a range instead of a single date when the gap is odd:

let days = diffInMonths.toObject().days;
if (days % 2 == 0) {
  // even gap: one exact midpoint
  let middle = Math.abs(days) / 2;
  middleRes.value =
    days < 0
      ? end.plus({ days: middle }).toFormat("yyyy-MM-dd (ccc)")
      : start.plus({ days: middle }).toFormat("yyyy-MM-dd (ccc)");
} else {
  // odd gap: midpoint falls between two candidate days
  let middle1 = (Math.abs(days) - 1) / 2;
  let middle2 = middle1 + 1;
  middleRes.value =
    days < 0
      ? `${end.plus({ days: middle1 }).toFormat("yyyy-MM-dd (ccc)")}~${end.plus({ days: middle2 }).toFormat("yyyy-MM-dd (ccc)")}`
      : `${start.plus({ days: middle1 }).toFormat("yyyy-MM-dd (ccc)")}~${start.plus({ days: middle2 }).toFormat("yyyy-MM-dd (ccc)")}`;
}

Even gap → one exact answer. Odd gap → two adjacent dates shown as a range, because both are equally "the middle" and picking one over the other would just be arbitrary. The days < 0 branch also handles a detail that's easy to overlook: the user isn't required to type the earlier date into the first field, so the function figures out which of start/end is actually earlier before it adds the offset, rather than assuming input order. The same input-order tolerance shows up in the days-between result too — before display, the component swaps which date is shown first based on the sign of the raw diff, so date1 and date2 in the output text always resolve to the chronologically earlier and later date, regardless of which one the user typed first.

Where this falls short

A few honest limitations, since none of this is magic:

The single-date calculator only adds or subtracts a plain count of days — there's no "add 1 month" or "add 1 year" option. If you want a month from now, you have to already know how many days that is (28–31, depending), the tool won't do that translation for you.
The date inputs allow anything up to year 9999 with no realistic lower bound. Luxon will happily compute a diff against a date in year 1, but that's applying the proleptic Gregorian calendar backwards past 1582, when the Gregorian calendar didn't actually exist yet — the math is internally consistent, it just isn't "historically real" that far back.
The "at least 1" rule on the day-count input for the single-date calculator is enforced by a UI hint and a truthy check (!inferNumber.value), not a strict numeric range check — it stops empty/zero input but isn't the same as validating that the value is a genuine positive integer.

None of these are bugs exactly, just the edges you hit once you stop treating "days between two dates" as a solved problem.

I cleaned up the version I built for my friend's shared-birthday math into a small free tool: Online Date Calculator. No sign-up, and yes, it shows the range when the midpoint lands between two days instead of quietly rounding.

Available in other languages

日期計算機 — 繁體中文
在线日期计算器 — 简体中文
Online Date Calculator — English
オンライン日付計算ツール — 日本語
온라인 날짜 계산기 — 한국어
Calculateur de Date en Ligne — Français
Онлайн Калькулятор Дат — Русский
Online Datumsrechner — Deutsch
Kalkulator Tanggal Online — Bahasa Indonesia
Calculadora de Fechas Online — Español
Máy Tính Ngày Trực Tuyến — Tiếng Việt
เครื่องคิดเลขวันที่ออนไลน์ — ไทย
Internetowy Kalkulator Dat — Polski
Çevrimiçi Tarih Hesaplayıcı — Türkçe
Calcolatore di Date Online — Italiano
Calculadora de Datas Online — Português
Online Datumcalculator — Nederlands
Онлайн Калькулятор Дат — Українська

Why `new Date(garbage) === "Invalid Date"` is always false (a timestamp converter taught me this the hard way)

Vera Yang — Tue, 04 Aug 2026 07:00:01 +0000

I built a small Unix timestamp converter — paste in seconds or milliseconds, get a date back, or go the other way. Simple enough that I figured the only real work would be the date math. Then I went to add "tell the user when they typed garbage" and ran straight into a JavaScript gotcha that's been quietly living in more codebases than anyone wants to admit.

The unit dropdown is secretly a multiplier, not a branch

The converter has a unit selector next to the input — "Seconds" or "Milliseconds." The tempting way to wire that up is an if/else: if seconds, do this math; if milliseconds, do that math. That's not what's in the actual component. The <a-select> options are bound directly to the numbers 1 and 1000, and those numbers get used as literal arithmetic operands everywhere downstream:

const unixToNoraml_getOutput = () => {
  let unix = data.unixToNoraml.unix;
  let unit = data.unixToNoraml.unit; // 1 or 1000
  let output = new Date(Math.floor((unix * 1000) / unit));
  data.unixToNoraml.output = output;
};

If unit is 1 (seconds), that's unix * 1000 / 1 — converts seconds to the milliseconds Date wants. If unit is 1000 (milliseconds), it's unix * 1000 / 1000, which cancels out and leaves the value untouched, because it was already in milliseconds. Same one-liner handles both cases with no conditional at all.

The reverse direction does the same trick in reverse — compute the answer in seconds, then multiply by the unit to get either seconds or milliseconds back out:

const normalToUnixOutputFormat = computed(() => {
  if (!data.normalToUnix.output) return "";
  return data.normalToUnix.output * data.normalToUnix.unit;
});

It's a small thing, but reusing the dropdown's raw value as a multiplier instead of introducing a "seconds" | "milliseconds" enum saved a branch in four separate places in the component.

The validation check that doesn't actually validate anything

Here's the one that got me. When you type a date string into the "normal time" field and hit convert, the code tries to reject bad input before doing math on it:

if (new Date(normal) === "Invalid Date") {
  return Swal.fire({
    title: t("timestamp.error"),
    icon: "warning",
    confirmButtonColor: "#1890ff",
  });
}
let output = new Date(normal).getTime() / 1000;

new Date("not a real date") doesn't throw and doesn't return the string "Invalid Date" — it returns an actual Date object whose internal time value is NaN. Calling .toString() on that object prints "Invalid Date", but the object itself is never, ever === to a string, no matter what garbage you feed it. So that guard clause is dead code. It will never fire, for any input, ever.

What actually keeps the tool from displaying literal "NaN" to the user is something else entirely, three lines away in a computed property:

const normalToUnixOutputFormat = computed(() => {
  if (!data.normalToUnix.output) return "";
  return data.normalToUnix.output * data.normalToUnix.unit;
});

NaN / 1000 is still NaN, and !NaN evaluates to true in JavaScript — so the falsy check blanks the output field instead of the intended validation ever running. The tool behaves correctly, but by accident: the real safety net is a coincidental side effect of how NaN interacts with !, not the Swal.fire() warning dialog that was written to handle exactly this case. The correct check would be isNaN(new Date(normal).getTime()), but that's not what's in the file.

The live clock ticks in your local time, not UTC

The page also has a running "current timestamp" display that updates once a second, with pause/continue buttons:

const init_clock = () => {
  if (data.timer) return;
  data.timer = setInterval(() => {
    let now = new Date();
    data.currentUnix = Math.round(now.getTime() / 1000);
    data.currentLocalString = DateTime.fromSeconds(data.currentUnix).toFormat(
      "yyyy/MM/dd HH:mm:ss",
    );
  }, 1000);
};
const pause_clock = () => {
  clearInterval(data.timer);
  data.timer = null;
};

Two things worth calling out. First, setInterval(..., 1000) doesn't guarantee a tick every exact second — it just re-reads Date.now() and rounds each time it fires, so under heavy main-thread load a tick can land late; the displayed number just catches up rather than drifting permanently. Second, DateTime.fromSeconds() from Luxon defaults to the local system time zone when you don't pass one — so the human-readable clock next to the raw Unix number is your machine's local time, not UTC, even though a Unix timestamp is by definition timezone-independent. There's no UTC toggle for it. If you're in Tokyo and I'm in Berlin, we see the same integer but a different clock face next to it.

Limitations, honestly

No digit-count auto-detection. I assumed a paste-in converter like this would sniff "10 digits, must be seconds" vs "13 digits, must be milliseconds." It doesn't — the unit is a manual dropdown. Paste a 13-digit millisecond value while "Seconds" is still selected and you silently get a date several thousand years in the future. No warning, no clamp.
Everything renders in local time. The seconds-since-epoch value is timezone-agnostic by definition, but every human-readable output on the page — the live clock, the converted date — is displayed in whatever timezone the browser is set to, with no UTC option. If you're debugging a server log recorded in UTC, you have to do the offset math yourself.
The "type a date manually" field parses whatever new Date(string) accepts, which is a browser-implementation detail, not a fully spec'd format. It works fine for the YYYY/MM/DD HH:MM:SS shape the placeholder suggests, but it's not the same guarantee you'd get from an explicit parser.
The Invalid Date check discussed above never runs. It's harmless here because NaN's falsiness happens to save it, but it means the warning dialog telling you "please enter a valid time" is unreachable code.

I turned the cleaned-up version into a small free tool: Unix Timestamp Converter. No sign-up, works entirely in the browser.

Available in other languages

Unix時間戳轉換工具 — 繁體中文
Unix时间戳转换器 — 简体中文
Unix Timestamp Converter — English
Unixタイムスタンプ変換ツール — 日本語
Unix 타임스탬프 변환기 — 한국어
Outil de Conversion de Timestamp Unix — Français
Конвертер Unix Timestamp — Русский
Unix-Zeitstempel-Konverter — Deutsch
Alat Konversi Unix Timestamp — Bahasa Indonesia
Conversor de Unix Timestamp — Español
Công cụ chuyển đổi Unix Timestamp — Tiếng Việt
เครื่องมือแปลง Unix Timestamp — ไทย
Konwerter znacznika czasu Unix — Polski
Unix Timestamp Dönüştürme Aracı — Türkçe
Strumento di conversione Unix Timestamp — Italiano
Conversor de Unix Timestamp — Português
Unix Timestamp Conversie Tool — Nederlands
Інструмент конвертації Unix Timestamp — Українська

I built a calorie lookup table and realized the search box was already a category filter

Vera Yang — Tue, 04 Aug 2026 02:00:04 +0000

A while back I wanted a fast way to answer "how many calories are in this" while eating instead of after — no app to install, no account, just type the food and see a number. I figured I'd build a small searchable table over a list of common foods. There's no clever algorithm hiding in something like this. It's a filtered array rendered as rows. What actually took the time was the boring stuff: how do you store "1 bowl (200g)" as data, what happens when someone searches for a category instead of a food, and whether the number you show is even the number you meant to show.

The search box already does more than the category dropdown

The table has both a text search and a category dropdown (Staple Food, Fruit, Drinks, Vegetable, Seafood, Meat, Egg). I built them as two separate filters, applied one after the other:

let showTable = computed(() => {
  let searchResult = foodCalories.value.filter((item) => {
    return (
      item.groupName.toUpperCase().indexOf(keyword.value.toUpperCase()) > -1 ||
      item.groupName_en.toUpperCase().indexOf(keyword.value.toUpperCase()) > -1 ||
      item.name.toUpperCase().indexOf(keyword.value.toUpperCase()) > -1 ||
      item.name_en.toUpperCase().indexOf(keyword.value.toUpperCase()) > -1
    );
  });
  return searchResult.filter((item) => {
    if (showGroup.value == "All") return true;
    return item.groupName_en == showGroup.value;
  });
});

The text filter checks four fields per item, not one: the Chinese name, the English name, the Chinese category, and the English category. I added the category fields mostly so a groupName_en typo somewhere wouldn't make an item unfindable. What I didn't plan for is that typing "fruit" into the search box now returns every fruit in the table, with zero interaction with the dropdown next to it — the dropdown and the search box quietly do the same job through two different UI elements. It's not a bug exactly, it's just a filter that's wider than the label on the box suggests. Nobody's complained, but if I rebuilt this I'd probably narrow the text search to just the name fields and let the dropdown own category filtering exclusively.

Calories are stored as a string, and that decision has a shelf life

Each row looks like this:

{
  name: "白米飯",
  name_en: "White rice",
  unit: "1碗",
  unit_en: "1 bowl",
  weight: "200g",
  calories: "225",
  groupName: "主食",
  groupName_en: "Staple Food",
},

calories is a string, "225", not the number 225. That was fine as long as all I ever did with it was print it next to the name. The table has no sort feature today, and that's exactly why it's gotten away with this so far — "9" sorting after "80" because "9" > "8" lexicographically only matters the moment you try to sort. The day I add "sort by calories," every row with a triple-digit value will need parseInt first, or the ordering will look randomly wrong to anyone who doesn't know why. I left it as a string because the data came from a spreadsheet of copy-pasted nutrition labels, and normalizing every value to a real number felt like busywork for a feature that didn't exist yet. That's a fair trade until it isn't.

A `<table>` your browser never actually shows you

The template renders the food data twice. Once as a real HTML <table> with <thead>/<tbody>, and once as a grid of styled <div>s that's the thing you actually see and interact with:

.foodCalories__table {
  height: 0;
  overflow: hidden;
}

The semantic table exists purely for crawlers and screen readers — search engines and assistive tech get proper table markup with real headers, while the visible UI is a <div> grid because that's what let me do per-cell click-to-copy, a font-size toggle, and a mobile layout that reflows without fighting <table> layout rules. Two representations of the same 300+ rows, kept in sync only because they're both generated from the same v-for over the same array. If I ever changed one loop without the other, they'd silently drift apart with no error to catch it.

Where the numbers don't quite line up

The honest gotchas, since none of this is as tidy as it looks:

Click-to-copy doesn't always match what's on screen. The visible unit column shows the Chinese unit for both tw and cn locales (locale == "tw" || locale == "cn" ? item.unit : item.unit_en), but the click-to-copy handler for that same cell only checks locale == "tw". A cn-locale user sees "1碗" on screen and copies "1 bowl" to their clipboard. Small, easy to miss, and exactly the kind of thing that survives for years in a component nobody re-reads line by line.
Calories are per labeled serving, not per 100g, and the serving unit and its gram weight are just two adjacent strings (unit, weight) glued together for display — "1碗（200g）" — with no actual unit conversion behind them. Comparing two foods with different serving sizes means doing the per-gram math yourself.
The category dropdown is a hand-written list, separate from the actual groupName_en values in the data file. If a future data update adds a new category, it's searchable by text immediately but invisible in the dropdown until someone remembers to add it there too.

None of that makes the table wrong, exactly — it makes it a spreadsheet with a search box, and it's worth knowing that's what you're looking at before you trust it for anything more precise than "roughly how much is this."

I cleaned this up into a small free tool if you want to poke at the real thing: Common Food Calorie Table. No sign-up, just search and filter over 300+ foods.

Available in other languages

常見食物熱量表 — 繁體中文
常见食物热量表 — 简体中文
Common Food Calorie Table — English
食品カロリー表（300種類以上） — 日本語
식품 칼로리 표 — 한국어
Tableau des Calories des Aliments Courants — Français
Таблица калорийности продуктов — Русский
Kalorientabelle für gängige Lebensmittel — Deutsch
Tabel Kalori Makanan Umum — Bahasa Indonesia
Tabla de calorías de alimentos comunes — Español
Bảng calo thực phẩm thông thường — Tiếng Việt
ตารางแคลอรี่อาหารทั่วไป — ไทย
Tabela kalorii popularnych produktów spożywczych — Polski
Yaygın Yiyecek Kalori Tablosu — Türkçe
Tabella delle calorie dei cibi comuni — Italiano
Tabela de calorias de alimentos comuns — Português
Tabel met calorieën van veelvoorkomende voedingsmiddelen — Nederlands
Таблиця калорійності популярних продуктів — Українська

DEV Community: Vera Yang

I thought porting my margin-call calculator to short selling was a one-line sign flip. It wasn't even close.

Two regions, two different ratio formulas

Solving for the price, not just the ratio

What this doesn't account for

Available in other languages

The shuffle in my memory-training game isn't fully random — and nobody would ever notice

It's not "repeat the sequence" — it's "reconstruct it from memory"

The shuffle that's almost, but not quite, Fisher-Yates

The on-screen timer only ever measures the recall phase

Two things that look configurable but aren't

Available in other languages

Why every "calories burned" calculator boils down to one formula (I found this out because my own copy button was lying to me)

The whole calculator is one line of math

The number you see isn't the number you copy

The * 10 / 10 that does nothing (and the regex that does)

Where this falls apart

Available in other languages

Keep moving forward!

How I built a highly profitable web platform, with zero backend code to keep my server costs at $0.

Dead-pixel test sites are just colored divs — the actual engineering problem is the Fullscreen API, not the colors

The colors are chosen, not decorative

Fullscreen isn't cosmetic — it's the whole point, and it's annoyingly stateful

Auto-play is a plain interval, not a rendering-timed loop

What this can't actually tell you

Available in other languages

Generating unique random numbers is easy — swapping min and max broke my own validation

Letting min and max be typed in either order

The validation check that forgot about the swap

Retry until it's unique, not shuffle-and-slice

Limitations

Available in other languages

Why "must be subscribed to enter" is a checkbox I had to delete from a YouTube giveaway picker

Turning whatever URL someone pastes into a video ID

Paginating through the comments API without losing your place

One entry per commenter, not per comment

Picking winners without replacement, the brute-force way

Where this quietly falls short

Available in other languages

Why my auto-scrolling teleprompter froze at low speed (and the hidden float that fixed it)

requestAnimationFrame, not setInterval

The decimal accumulator that makes slow speeds actually scroll

Mirror mode is one CSS property, applied twice

Limitations

Available in other languages

Why splitting text into sentences by punctuation breaks on "Dr. Smith" (I found out building a case converter)

The .split() trap I started with

What actually shipped

Title Case has a completely different bug

Where this still gets it wrong

Available in other languages

Why "the date exactly halfway between these two dates" doesn't always have one answer

Counting days between two dates without native Date math

The fencepost question nobody asks out loud: is today "day 0" or "day 1"?

Finding the midpoint: what happens when the gap is an odd number of days

Where this falls short

Available in other languages

Why `new Date(garbage) === "Invalid Date"` is always false (a timestamp converter taught me this the hard way)

The unit dropdown is secretly a multiplier, not a branch

The validation check that doesn't actually validate anything

The live clock ticks in your local time, not UTC

Limitations, honestly

Available in other languages

I built a calorie lookup table and realized the search box was already a category filter

The search box already does more than the category dropdown

Calories are stored as a string, and that decision has a shelf life

A <table> your browser never actually shows you

Where the numbers don't quite line up

Available in other languages

The `* 10 / 10` that does nothing (and the regex that does)

The `.`split() trap I started with

Counting days between two dates without native `Date` math

A `<table>` your browser never actually shows you