DEV Community: Vera Yang

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, but wrote 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
Таблиця калорійності популярних продуктів — Українська

Why three "characters" in my HTML symbol table aren't actually there

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

I built a click-to-copy table of HTML special characters — the kind of reference page you land on from a Google search when you need — or © and don't want to remember the numeric code. I figured the hard part would be assembling a few hundred symbols. It wasn't. The hard part was three rows where the "symbol" you're supposed to click on is invisible, plus a search box that only works if you already know what you're looking for.

The table is a flat array, not a category system

The marketing copy on the page talks about symbols being "neatly organized by category" — arrows, currency, math, Greek letters. In the actual data file, there's no category field anywhere. It's one flat array of ~360 plain objects:

let table = [
  { symbol: "Α", name: "&Alpha;", code: "&#913;" },
  { symbol: "←", name: "&larr;", code: "&#8592;" },
  { symbol: "¢", name: "&cent;", code: "&#162;" },
  { symbol: "©", name: "&copy;", code: "&#169;" },
  // ...roughly 360 of these
];

The "categories" you notice while scrolling are just an artifact of the order the list was assembled in — Greek letters cluster because whoever built the table pasted them in as a block, not because there's a category: "greek" key anywhere. Filtering is a plain substring match across all three fields:

let showTable = computed(() => {
  return htmlsymbols.value.filter((item) => {
    return (
      item.symbol.indexOf(keyword.value) > -1 ||
      item.name.indexOf(keyword.value) > -1 ||
      item.code.indexOf(keyword.value) > -1
    );
  });
});

Which means typing "arr" finds ←, →, ↑ — because those entity names literally contain "arr" — but typing "arrow" finds nothing, because the string "arrow" doesn't appear anywhere in the data. There's no synonym layer, no description field, no fuzzy matching. The search only works if you already half-know HTML entity naming conventions, which is a little backwards for a tool aimed at people who don't.

Making invisible characters clickable

Three rows in the table are spaces — &ensp;, &emsp;,   — and a plain space rendered in a table cell gives you nothing to click on. No visual weight, no hover target you'd notice, nothing. So those three rows carry an extra field the rest of the table doesn't have:

{ symbol: " ", name: "&ensp;", code: "&#8194;", rmk: "en space" },
{ symbol: "　", name: "&emsp;", code: "&#8195;", rmk: "em space" },
{ symbol: " ", name: "&nbsp;", code: "&#160;", rmk: "non-breaking" },

And the template checks for it before deciding what to display:

<div class="tableGroup__item__symbol" :class="{ canCopy: item.symbol }" @click="copy(item.symbol)">
  {{ item.rmk ? `(${item.rmk})` : item.symbol || " " }}
</div>

The label you see is (non-breaking), but the click handler is still wired to item.symbol — the actual invisible space character, not the label text. So the displayed text and the copied text are deliberately different things. It's a small trick, but it's the only reason those three rows are usable at all instead of being dead, empty-looking cells nobody would think to click.

Not every cell is copyable, and one code is just wrong

Each of the three columns — symbol, entity name, decimal code — copies independently, and the canCopy styling (and the click handler itself) is gated on the value actually being truthy:

function copy(content) {
  if (!content) return;
  navigator.clipboard.writeText(content ? content : res.value);
  message.info({ content: t("message.copySuccess", { copySuccess: content }) });
}

That res.value fallback in the ternary is dead code — res isn't defined anywhere in this component, and it's unreachable anyway because the if (!content) return; guard already exits before you'd get there. Looks like a leftover from a copy-pasted pattern used in one of the other tools on the site that never got cleaned up here; harmless, but a good reminder that "it works" isn't the same as "every line does something."

The guard matters for real data, though — the apostrophe row has no named entity at all:

{ symbol: "'", name: "", code: "&#39;" },

name is an empty string, so that cell never gets the canCopy class and clicking it does nothing — correctly, since HTML never defined a named entity for a plain apostrophe.

There's also a plain typo sitting in the data: the micro sign's decimal code is written &#181 instead of µ — missing the closing semicolon that every other row in the table has. Copy that one into an HTML document and depending on what follows it in your markup, it may not render as µ at all, because the semicolon terminator got dropped.

Where this actually falls short

Search is pure substring matching on exactly what's stored — no semantic search, no "symbols that look like an X."
The "clean categories" description in the page copy doesn't match the underlying data structure — there's no category field to filter by, just scroll order.
It only covers the classic HTML4/Latin-1/general-punctuation/Greek/math/arrows range — no emoji, no CJK punctuation, no anything from more recent Unicode blocks.
The invisible-character trick (rmk) only exists for three rows; any other zero-width or hard-to-see character added later would need the same manual override or it'd be effectively unclickable.

I cleaned up the version I use into a small free tool if you need to grab an entity code without digging through W3Schools tables: HTML Symbol Entity Reference. No sign-up, click any cell to copy it.

Available in other languages

HTML特殊符號對照表 — 繁體中文
HTML特殊符号对照表 — 简体中文
HTML Symbol Entity Reference — English
HTML特殊記号対照表 — 日本語
HTML 특수문자 코드 대조표 — 한국어
Tableau de référence des entités HTML — Français
Справочник спецсимволов HTML — Русский
HTML-Sonderzeichenreferenz — Deutsch
Tabel Referensi Simbol HTML — Bahasa Indonesia
Tabla de símbolos HTML — Español
Bảng ký tự đặc biệt HTML — Tiếng Việt
ตารางอ้างอิงสัญลักษณ์ HTML — ไทย
Tabela znaków specjalnych HTML — Polski
HTML Özel Karakterler Referansı — Türkçe
Tabella di riferimento simboli HTML — Italiano
Tabela de Símbolos HTML — Português
Tabel met HTML Speciale Tekens — Nederlands
Довідник символів HTML — Українська

Why "business days between two dates" isn't a division problem (I only saw it clearly building a workday calculator)

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

A while back I needed to know how many working days I had left before a deadline. My first instinct was: total days divided by 7, times 5, done. That works fine as long as your date range happens to be a whole number of weeks. The moment you have leftover days at either end — which is basically always — that formula falls apart, because whether a leftover day "counts" depends entirely on which day of the week it lands on. I ended up building a small workday calculator just to get this right, and the actual logic turned out to be less "math" and more "walk the calendar and check."

Full weeks are cheap, partial weeks aren't

The calculator lets you define your own work week (a set of weekday numbers, 0=Sunday through 6=Saturday, defaulting to Mon–Fri) instead of assuming a fixed 5-day week. That's the part that breaks the naive division trick — you can't just multiply by 5 if the user's work week has 4 days or includes Saturday.

Here's the "count workdays between two dates" function, close to what's actually running:

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

let res_week = Math.floor(Math.abs(source_Day) / 7);

let firstDate = source_Day > -1 ? twoDate.date1 : twoDate.date2;
let lastDate  = source_Day > -1 ? twoDate.date2 : twoDate.date1;
let firstDate_weekday = new Date(firstDate).getDay();
let lastDate_weekday  = new Date(lastDate).getDay();

let resDays = res_week * myWorkday.value.length;

let tempEnd =
  lastDate_weekday >= firstDate_weekday
    ? lastDate_weekday
    : lastDate_weekday + 7;

for (let i = firstDate_weekday; i <= tempEnd; i++) {
  if (myWorkday.value.includes((i % 7).toString())) {
    resDays++;
  }
}

The trick is splitting the range into two very different problems:

Complete 7-day blocks. res_week = floor(totalDays / 7). Any full 7-day span always contains exactly one occurrence of every weekday, so it always contains exactly myWorkday.length workdays — no matter which day it starts on. That's why this part can be pure multiplication.
The leftover partial week. This can't be reduced to a day count, because whether those leftover days count depends on which weekdays they actually are. So instead of computing "how many leftover days," the code computes the leftover's start and end weekdays, and walks weekday-by-weekday from one to the other (tempEnd bumps by 7 if the end weekday number is smaller than the start, to handle wrapping across a week boundary, e.g. Friday → Monday), checking each one against the custom workday set.

Both the start date and end date are included in the count — that's an explicit design choice in the tool, not an accident of the math.

Adding N workdays to a date has the same problem, mirrored

The other half of the tool answers a different question: "what date is 10 workdays from now?" Same underlying issue — you can't just add 10 * 7/5 calendar days, because it matters which weekday you start counting from:

let infer_Week = Math.floor(inferNumber.value / myWorkday.value.length);
let infer_remainder = inferNumber.value % myWorkday.value.length;
if (infer_Week > 0) {
  infer_Week = infer_Week - 1;
  infer_remainder = infer_remainder + myWorkday.value.length;
}

let start_weekday = new Date(singleDate.date).getDay();
let nowWeekday = dateDirection.value == 0
  ? (start_weekday + 1) % 7
  : (start_weekday + 6) % 7;

let inferDays = infer_Week * 7;
let i = infer_remainder;
while (i > 0) {
  if (myWorkday.value.includes(nowWeekday.toString())) {
    i--;
  }
  inferDays++;
  nowWeekday = dateDirection.value == 0 ? (nowWeekday + 1) % 7 : (nowWeekday + 6) % 7;
}

Same split as before: infer_Week full weeks get resolved by multiplication, and the leftover (infer_remainder) gets resolved by actually walking day-by-day and checking membership in the workday set, incrementing inferDays every calendar day but only decrementing the counter i on days that are actual workdays.

The one non-obvious line is the if (infer_Week > 0) block, which "borrows back" one full week into the remainder. Without it, a small remainder (say, needing 2 more workdays) combined with an unlucky starting weekday could theoretically need to walk further than the remainder value allows before hitting enough workdays. Padding the remainder with one extra full week's worth of days guarantees the while loop always has enough calendar days to walk through to satisfy the count, regardless of which weekday you started on.

Note also that the start date itself is not counted here — the loop deliberately starts from start_weekday + 1 (or - 1 going backwards), so "5 workdays from Monday" lands on the following Monday, not the Friday four days later.

Where this actually breaks

A few real gotchas I ran into:

The weekday lookup uses new Date(dateString).getDay(), not the same date library used everywhere else. The rest of the tool parses dates with Luxon's DateTime.fromISO, but the weekday check falls back to plain new Date("2024-01-01").getDay(). A bare YYYY-MM-DD string is parsed by JS as UTC midnight, while .getDay() reads it back in the browser's local time zone. For anyone west of UTC, that mismatch can roll the date back to the previous day right at midnight-ish boundaries and return the wrong weekday — which then throws off which days count as workdays for that edge of the range.
No public holidays. This only excludes the weekdays you tell it to exclude. If a national holiday falls inside your range, you have to manually adjust the result yourself — the tool doesn't know your country's calendar and doesn't try to.
Deselecting every workday checkbox isn't guarded against. Nothing stops you from unchecking all seven days. In the "between two dates" mode that just quietly returns 0. In the "add/subtract workdays" mode it's worse: myWorkday.value.length becomes the divisor in infer_Week = Math.floor(N / 0), which produces Infinity/NaN, and the result is a broken date instead of a warning.
The two modes disagree on whether the start date counts, and that's intentional rather than a bug — "days between" includes both endpoints, "add N workdays" excludes the starting point — but it's easy to get bitten by the asymmetry if you assume they behave the same way.

I turned the cleaned-up version of this into a small free tool if you want to poke at it: Business Day Calculator. No sign-up, and you can set your own work week instead of assuming Mon–Fri.

Available in other languages

工作天計算機 — 繁體中文
工作日计算器 — 简体中文
Business Day Calculator — English
営業日計算機 — 日本語
근무일 계산기 — 한국어
Calculateur de Jours Ouvrables — Français
Калькулятор рабочих дней — Русский
Arbeitstage-Rechner — Deutsch
Kalkulator Hari Kerja — Bahasa Indonesia
Calculadora de días laborables — Español
Máy tính ngày làm việc — Tiếng Việt
เครื่องคิดวันทำงาน — ไทย
Kalkulator dni roboczych — Polski
İş Günü Hesaplayıcı — Türkçe
Calcolatore Giorni Lavorativi — Italiano
Calculadora de dias úteis — Português
Werkdagen Calculator — Nederlands
Калькулятор робочих днів — Українська

Turns out a "random" spin wheel doesn't pick a winner and rotate to it — it spins first, then checks who's standing there

Vera Yang — Fri, 31 Jul 2026 07:00:01 +0000

A while back I needed a wheel for picking a raffle winner from a list of names. My mental model going in was basically a slot machine: roll a weighted random number, figure out which name that number lands on, then animate the wheel spinning around until it visually lines up with that pre-chosen name. Reasonable assumption — that's how I'd have built it.

That's not what happens. Building the random-wheel tool, I found the actual sequence is backwards: the wheel spins to a random angle first, and only after it physically stops does the code check which segment happens to be sitting under the pointer. The winner isn't decided — it's discovered.

The wheel doesn't know who won until after it stops

The tool hands its segment list to Winwheel.js, a canvas wheel library, configured like this:

this.theWheel = new Winwheel({
  outerRadius: this.canvasWdith / 2,
  textFontSize: 24,
  textOrientation: "vertical",
  textAlignment: "outer",
  numSegments: this.segments.length,
  segments: this.segments,
  animation: {
    type: "spinToStop",
    duration: 10,
    spins: 3,
    callbackFinished: this.alertPrize,
  },
});

Nowhere does this app set animation.stopAngle. That matters, because inside the library, when stopAngle is left unset, it fills it in itself with a plain random number:

this.animation._stopAngle = (this.animation.stopAngle == null)
  ? Math.floor(359 * Math.random())
  : 360 - this.animation.stopAngle + this.pointerAngle;

The final rotation the wheel animates to is just spins * 360 + _stopAngle — some number of full turns, plus that random leftover angle. TweenMax eases the rotationAngle property from its current value to that target over the 10-second duration, using a decelerating curve so it looks like it's slowing down naturally. Only once the tween finishes does callbackFinished fire, and only then does the library work out which segment is physically under the fixed pointer by taking the final rotation modulo 360 and comparing it against each segment's angular range. That result — whatever segment happens to be there — is what gets handed to the app's alertPrize function. There's no "chosen winner" object anywhere before that point. The randomness lives entirely in one Math.random() call buried in a third-party script tag (/Winwheel.min.js), loaded outside the normal build pipeline — which is an easy thing to miss if you only read the Vue component and assume the picking logic is in there.

"Wheel speed" doesn't change the odds — it changes how long you have to wait

The UI lets you pick slow/medium/fast before spinning:

if (this.wheelPower == 1) {
  this.theWheel.animation.spins = 3;
} else if (this.wheelPower == 2) {
  this.theWheel.animation.spins = 9;
} else if (this.wheelPower == 3) {
  this.theWheel.animation.spins = 30;
}

More "power" just means more full 360° turns before the wheel settles, all crammed into the same fixed 10-second duration — so higher power genuinely does spin faster on screen, since the wheel has to cover more distance in the same time. But since every extra full turn is a multiple of 360, it has zero effect on which segment ends up at the top; spins * 360 disappears entirely once you take the final angle modulo 360. The random offset from getRandomForSegment-style logic is the only thing that decides the outcome. "Fast" mode is pure theater for suspense, not a different fairness setting — which took me a minute to convince myself of, because visually it really does look like a different kind of spin.

Segments are colored like a line, but the wheel is a circle

Each item becomes a wedge, colored by cycling through three colors based on index:

segments() {
  let colorList = ["#7ecefc", "#fff6e6", "#ff8066"];
  let newArray = this.wheelItems.map((item, index) => {
    return {
      fillStyle:
        colorList[
          index + 1 == this.wheelItems.length &&
          this.wheelItems.length % 3 == 1
            ? 1
            : index % 3
        ],
      text: item.value,
      textFontSize:
        item.value.length > 5
          ? this.canvasWdith / 3 / item.value.length
          : 24,
    };
  });
  return newArray;
},

index % 3 alone is a fine way to alternate three colors down a flat list. But a wheel wraps around — segment 0 sits right next to the last segment, not just the next one. Cycling colors mod 3 on a list whose length is a multiple-of-3-plus-one (4, 7, 10, 13...) means the last segment's natural color ((length-1) % 3, which works out to 0) collides with the first segment's color, and since they're physically adjacent on the circle, you'd get two same-colored wedges sitting side by side. The length % 3 == 1 check catches exactly that case and forces the last segment to color index 1 instead, breaking up the collision. It's a small, easy-to-miss piece of circular-list logic that a flat-list mental model won't catch until you actually render a 4- or 7-item wheel and stare at the seam.

The font-size line next to it is solving an unrelated problem: text is drawn radiating outward (textOrientation: "vertical", textAlignment: "outer"), and a long label at the default 24px font will run off the edge of a narrow wedge, so anything over 5 characters gets shrunk proportionally to canvasWidth / 3 / length instead.

Limitations and things that bit me

Duplicate item text isn't handled specially, and it has a real consequence. The wheel has a "remove previous winner" button, and it filters the item list by matching text: wheelItems.filter(item => item.value != itemText). If you type "Alice" into two different slots, spin, and win "Alice," clicking remove deletes both segments named Alice at once — because the filter has no way to know you meant one specific wedge. Duplicate labels also quietly double that label's odds without any warning in the UI.
No dedupe, no cap. The only validation before building the wheel is AwardSetting.Items.length < 2 (must have at least two non-empty items). You can paste in a few hundred lines and it will happily render a few hundred slivers — readable-text-per-wedge just isn't something the tool checks for.
It's a uniform pick, not a weighted one. There's dead code in the source (rateWin, fully commented out) that computes cumulative weighted ranges from a rate field — clearly an earlier attempt at weighted odds that never shipped. As it stands today, every segment has exactly equal probability regardless of how many times a name repeats structurally (aside from the duplicate-label trick above).
The random-number call isn't in the app's own code at all. It's inside a vendored library loaded via a plain <script src="/Winwheel.min.js"> tag, separate from the npm-managed dependencies. If you're auditing "is this actually random," reading the Vue component alone won't show you — you have to go find the library file.

I turned the working version of this into a small free tool if you want an actual raffle wheel without wiring up the animation library yourself: Online Random Wheel Generator. No sign-up, add as many items as you want.

Available in other languages

隨機抽獎輪盤產生器 — 繁體中文
在线随机抽奖轮盘生成器 — 简体中文
Online Random Wheel Generator — English
オンラインランダムルーレットジェネレーター — 日本語
온라인 랜덤 휠 생성기 — 한국어
Générateur de roulettes aléatoires en ligne — Français
Онлайн-генератор случайных колес — Русский
Online Zufallsrad-Generator — Deutsch
Pembuat Roda Acak Online — Bahasa Indonesia
Generador de Ruleta Aleatoria en Línea — Español
Công Cụ Tạo Máy Quay Ngẫu Nhiên Trực Tuyến — Tiếng Việt
สร้างรถหมุนสุ่มออนไลน์ — ไทย
Generator Losujący Ruletkę Online — Polski
Çevrimiçi Rastgele Rulet Oluşturucu — Türkçe
Generatore di Roulette Casuale Online — Italiano
Gerador de Roleta Aleatória Online — Português
Online Willekeurig Roulette Generator — Nederlands
Онлайн Генератор Випадкової Рулетки — Українська

DEV Community: Vera Yang

Keep moving forward!

How I built a highly profitable web platform, but wrote 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

Why three "characters" in my HTML symbol table aren't actually there

The table is a flat array, not a category system

Making invisible characters clickable

Not every cell is copyable, and one code is just wrong

Where this actually falls short

Available in other languages

Why "business days between two dates" isn't a division problem (I only saw it clearly building a workday calculator)

Full weeks are cheap, partial weeks aren't

Adding N workdays to a date has the same problem, mirrored

Where this actually breaks

Available in other languages

Turns out a "random" spin wheel doesn't pick a winner and rotate to it — it spins first, then checks who's standing there

The wheel doesn't know who won until after it stops

"Wheel speed" doesn't change the odds — it changes how long you have to wait

Segments are colored like a line, but the wheel is a circle

Limitations and things that bit me

Available in other languages

The `.`split() trap I started with

Counting days between two dates without native `Date` math

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