DEV Community: javascript

O perigo silencioso de formatar JSON de produção em sites aleatórios da web

geekecia — Tue, 10 Nov 2026 01:04:22 +0000

Quem nunca recebeu um payload gigante de API desformatado em uma linha só e, na pressa para debugar um chamado urgente, jogou no primeiro "JSON formatter" que apareceu na busca do Google?

Esse é um dos hábitos mais comuns e, ao mesmo tempo, um dos maiores vetores acidentais de vazamento de dados em times de engenharia.

Onde está o perigo?

Muitos sites gratuitos de formatação de JSON realizam o processamento enviando os dados para os seus próprios servidores via requisições HTTP POST. Nesses servidores:

Os payloads podem ficar salvos em logs de acesso e de erros;
Dados sensíveis como e-mails de clientes, CPFs, tokens de autenticação (JWT / Bearer), chaves de API e regras de negócio ficam expostos em infraestruturas terceiras desconhecidas;
Há um risco direto de não conformidade com legislações de privacidade (LGPD e GDPR).

A alternativa segura: Processamento 100% Client-Side

No TipTools, construímos o Formatador & Validador JSON com um princípio inegociável: nenhum dado que você cola ou digita é enviado para qualquer servidor.

Tudo é processado localmente na memória RAM do seu navegador.

Recursos do utilitário:

Formatação & Embelezamento: Indentação limpa e ajustável (2 ou 4 espaços) com destaque sintático.
Validação Instantânea com Diagnóstico: Detecção precisa de erros de sintaxe com indicação visual da linha e coluna com erro (vírgula a mais, aspas ausentes, chaves não fechadas).
Minificação (Minify): Remova espaços e quebras de linha em um clique para economizar bytes em requisições de rede.
Zero Fricção: Sem necessidade de login, sem limites de tamanho artificial e sem anúncios intrusivos.

Se você precisa formatar ou validar JSONs com frequência e deseja manter seus dados protegidos na sua máquina:

👉 Acessar o Formatador & Validador JSON no TipTools

Conheça também a suíte com mais de 100 ferramentas seguras para desenvolvedores em: tiptools.com.br

Splitting a wallet key 2-of-3 in Node.js, and what Keplr's social login incident shows about it

NefiSwap — Tue, 10 Nov 2026 00:56:34 +0000

On November 6, 2026, Web3Auth paused its wallet service after a flaw in its systems exposed the private keys of some Keplr Wallet users who had signed up with Google or Apple. Keplr co-founder Josh Lee estimated about 20% of those social login accounts were affected and said Keplr's own code wasn't the problem. Over the weekend Web3Auth moved about $5.6 million out of exposed wallets into 12 recovery addresses, which on-chain trackers first read as the attacker's haul (The Block).

Keplr's preliminary review said accounts created with a recovery phrase or a hardware wallet were not affected. Its help center says Google login accounts get a hex private key generated by Web3Auth instead of a 12 or 24 word phrase, and coverage of the incident describes Web3Auth's method as distributed key generation: the key lives as shares in different places and comes together at login.

Web3Auth hasn't published the root cause, so this post doesn't guess at it. What I wanted to understand is the primitive underneath: how a key can be split so that no single share means anything, and where that guarantee stops.

The idea in one line

Shamir's secret sharing hides the secret as the value of a polynomial at x = 0. For a 2-of-3 split you pick a random line f(x) = secret + a1 * x, hand out the points f(1), f(2), f(3), and throw away a1. Two points define a line, so any two shares give back f(0). One point fits infinitely many lines, so a single share tells you nothing.

The arithmetic has to happen in a finite field, otherwise the share values leak size information. For a secp256k1 wallet key the natural choice is the curve's group order N, since valid private keys are already integers mod N.

The code

Plain Node.js 18+, no dependencies. Save it as split-key.mjs.

import { randomBytes } from 'node:crypto';

// secp256k1 group order: valid private keys are integers in [1, N-1]
const N = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141n;
const mod = (a) => ((a % N) + N) % N;
const rand = () => mod(BigInt('0x' + randomBytes(32).toString('hex')));
const inv = (a) => { // Fermat: a^(N-2) mod N, N is prime
  let r = 1n, b = mod(a), e = N - 2n;
  while (e > 0n) { if (e & 1n) r = (r * b) % N; b = (b * b) % N; e >>= 1n; }
  return r;
};
const hex = (x) => x.toString(16).padStart(64, '0');

// Split: f(x) = secret + a1*x, share i is (i, f(i)). Any 2 points fix the line.
function split(secret, n = 3) {
  const a1 = rand();
  return Array.from({ length: n }, (_, k) => { const x = BigInt(k + 1); return { x, y: mod(secret + a1 * x) }; });
}
// Combine: Lagrange interpolation at x = 0
function combine(shares) {
  let s = 0n;
  for (const { x: xi, y: yi } of shares) {
    let num = 1n, den = 1n;
    for (const { x: xj } of shares) if (xj !== xi) { num = mod(num * -xj); den = mod(den * (xi - xj)); }
    s = mod(s + yi * num * inv(den));
  }
  return s;
}

const key = rand();
const shares = split(key);
console.log('private key   ', hex(key));
shares.forEach((s) => console.log(`share ${s.x}       `, hex(s.y)));

for (const pair of [[0, 1], [0, 2], [1, 2]]) {
  const got = combine(pair.map((i) => shares[i]));
  console.log(`shares ${pair[0] + 1}+${pair[1] + 1} ->  `, got === key ? 'same key' : 'MISMATCH');
}

// One share alone says nothing: for ANY candidate key there is a line through it and share 1.
const guess = rand();
const slope = mod((shares[0].y - guess) * inv(shares[0].x));
console.log('share 1 alone fits a random key too:', mod(guess + slope * 1n) === shares[0].y);

// The catch: whoever ends up holding two shares holds the key.
console.log('attacker with shares 1+3 rebuilds it:', combine([shares[0], shares[2]]) === key);

Output

Your hex values will differ on every run; the checks won't.

private key    8f5d2b92921cf8791535495c163aa1025ca3ec575d4b7f5ecd6a7134bb41a8b2
share 1        8cac3d676aeb94d4150b78c133b078c096c5d7c0704f7a77b5e1c92c138e7c83
share 2        89fb4f3c43ba312f14e1a8265126507ed0e7c329835375909e5921236bdb5054
share 3        874a61111c88cd8a14b7d78b6e9c283d0b09ae92965770a986d0791ac4282425
shares 1+2 ->   same key
shares 1+3 ->   same key
shares 2+3 ->   same key
share 1 alone fits a random key too: true
attacker with shares 1+3 rebuilds it: true

What the split protects, and what it doesn't

The math does its job. Steal one share and you have a uniformly random number. That is why a social login design can keep one share with a sign-in network, one on the user's device and one as a backup, and still say no single party holds the key.

The last line of the output is the part that matters for incidents like this one. The scheme is only as strong as the separation between share holders. If one system can reach two shares, or if the full key is ever rebuilt in a place an attacker can read, the threshold stops mattering. Real deployments use threshold signatures or DKG so the full key is never assembled at all, which shrinks that window but doesn't remove the dependency on the provider's infrastructure.

A recovery phrase sits on the other end of the trade. One copy, no math, and only the person holding the paper can rebuild it. Keplr's phrase and hardware accounts were outside this incident because nothing about them touched Web3Auth.

If you're building on embedded wallets

Read your provider's docs for where each share lives and which component rebuilds or uses the key. Find out whether users can export the key and leave, and check that they can do it during an outage, not only when your app is healthy. Keep a status page or a kill switch for deposits ready, because Keplr's first instruction to users was to stop sending funds to affected accounts.

This demo is for learning. Don't hand-roll secret sharing for production keys; use an audited library and a threshold signature scheme.

Sources: The Block (Nov 8, 2026); Keplr Help Center, "Privacy & Security"; CryptoTicker (Nov 7, 2026).

The jslab CLI: open files and pipe code into a tab

JSLab — Tue, 10 Nov 2026 00:45:57 +0000

JSLab feature notes: one docs page, explained. Today: The jslab CLI.

JSLab is a JavaScript & TypeScript scratchpad for macOS, which makes it a GUI app. But a lot of the code you want to try starts in a terminal: a file in a repo, the output of another command, a one-liner. jslab is a small command-line tool that gets it into a tab.

Install it

Choose Help → Install jslab Command…. JSLab links its own binary into ~/.local/bin/jslab. If that folder isn't on your PATH, the message gives you the line to add to your shell profile:

export PATH="$HOME/.local/bin:$PATH"

Once it's installed, the same menu item reads Uninstall jslab Command….

Open files

jslab notes.ts

Each file opens in a new tab. The tab's language comes from the extension, or from your settings.

Pipe code in, and run it

- reads code from stdin. --run runs it as soon as it opens:

echo 'console.log(new Date())' | jslab --run -

Without --run, the code only opens. For -, the tab's working directory defaults to your terminal's current folder, so relative paths in the piped code resolve where you are.

The options

jslab [file ...]                 Open files in new tabs
jslab -                          Read code from stdin into a new tab
jslab --run [file|-]             Open and run immediately
      --runtime bun|browser|browser-node
      --lang ts|js|tsx|jsx
      --cwd <dir>
      --title <title>
jslab --version | --help

browser-node is the Browser & Node APIs runtime. So opening a component in a browser tab, in the current folder, is:

jslab --runtime browser --cwd . app.tsx

Two I use

# Last week's version of a file, in its own tab
git show HEAD~5:src/format.ts | jslab --lang ts -

# Try a snippet you just copied from a README
pbpaste | jslab --run -

Code from stdin has no file extension, so pass --lang when it's TypeScript. pbpaste prints the macOS clipboard, so the second line runs whatever you copied. Read it before you pipe it.

How it works

If JSLab isn't running, jslab starts it and waits up to 10 seconds for it to be ready. Each call then sends one request over a local socket, jslab.sock, in JSLab's data folder.

JSLab launches Nov 15. The full page: https://js-lab.app/docs/reference/cli

What a 5 MB super-resolution model can (and can't) do inside a browser tab

Enlh NG — Tue, 10 Nov 2026 00:45:43 +0000

I enlarged a 563×449 photo to 1576×1257 without uploading it anywhere. The file was 147 KB before and 515.6 KB after, and it took 14.2 seconds. The interesting part isn't the result, it's the three questions it raises:

Why did the file get 3.5× bigger if no new information exists?
Why is the work split into "part 10 of 20"?
Why do these tools cap the input at about 2 megapixels?

Let's answer them with a bit of arithmetic and some small snippets.

Resizing vs. super-resolution

A normal resize (bilinear, bicubic, Lanczos) computes every new pixel as a weighted average of its neighbours. It can only blend what is already there, so edges get softer as you enlarge.

// The baseline every "AI upscaler" should be compared against
function resizeBaseline(img, scale) {
  const c = document.createElement('canvas');
  c.width  = Math.round(img.naturalWidth  * scale);
  c.height = Math.round(img.naturalHeight * scale);
  const ctx = c.getContext('2d');
  ctx.imageSmoothingQuality = 'high';
  ctx.drawImage(img, 0, 0, c.width, c.height);
  return c;
}

A super-resolution network such as Real-ESRGAN (Wang et al., 2021, open source, BSD-licensed) does something different. It was trained on pairs of degraded and clean images, so it has learned what a plausible edge, a hair or a brick texture looks like, and it paints those in. The result looks sharper, but the extra detail is a statistically likely guess, not recovered truth. That's why a face can get crisp skin texture it never had, and why the same model is the wrong tool for a screenshot of text, where a "plausible" letter shape can be a wrong letter.

Rule of thumb I use: photos, artwork, product shots → try the network. Screenshots, charts, scans of text → plain resizing.

Why the file got bigger

Compression ratio depends on how much high-frequency detail an image has. The network adds texture, texture is expensive for JPEG, and the pixel count grew too:

563 × 449   =   252,787 px
1576 × 1257 = 1,981,032 px   (≈ 7.8× more pixels, scale ≈ 2.8× per side)
147 KB → 515.6 KB            (≈ 3.5× more bytes)

Bytes grew less than pixels because JPEG handles smooth areas cheaply. The takeaway: a bigger file is not a better file, and you should expect to run a compressor afterwards.

Why "part 10 of 20"

The model itself is small. The tool I tested says its model is about 5 MB. The tensors are the problem. Back-of-the-envelope, for a worst-case 2 MP input enlarged 4× (that's 32 MP of output):

output RGBA bytes:        32e6 * 4            ≈ 128 MB
float32 RGB activations:  32e6 * 3 * 4        ≈ 384 MB  (for the final layer alone)

and intermediate feature maps are many channels wide, so the real peak is far higher. A browser tab on a laptop or a phone will not survive that, so the image is processed in chunks. The generic recipe looks like this (a sketch of the idea, not any particular tool's code):

const T = 128, PAD = 8, SCALE = 4;           // tile size, overlap, model factor

for (let y = 0; y < h; y += T) {
  for (let x = 0; x < w; x += T) {
    // read a little more than the tile so the seams have context
    const sx = Math.max(0, x - PAD), sy = Math.max(0, y - PAD);
    const ex = Math.min(w, x + T + PAD), ey = Math.min(h, y + T + PAD);

    const up = await runModel(cropRGB(src, sx, sy, ex, ey)); // SCALE× bigger

    // keep only the inner part, drop the padded border
    blit(dst, up,
         (x - sx) * SCALE, (y - sy) * SCALE,
         Math.min(T, w - x) * SCALE, Math.min(T, h - y) * SCALE,
         x * SCALE, y * SCALE);
    onProgress(++done / total);              // "part 10 of 20" comes from here
  }
}

The overlap matters. Without it, every tile boundary becomes a faint grid line because the network has no context beyond the edge of its input.

That also explains the caps you see in these tools: the one I tried accepts JPG/PNG/WebP up to 16 MB and about 2 MP, and limits the output's longest side to 4096 px. Those are not arbitrary; they keep the memory estimate above inside what a normal device can take.

WebGPU or not

The same model can run on the GPU through WebGPU or fall back to the CPU. Detecting it is cheap:

async function pickBackend() {
  if ('gpu' in navigator) {
    try {
      const adapter = await navigator.gpu.requestAdapter();
      if (adapter) return 'webgpu';
    } catch { /* fall through */ }
  }
  return 'cpu';
}

The difference is large. In my test the status line read Enhancing (WebGPU) — part 10 of 20 · about 8 s left. The page itself warns that without WebGPU a 1 MP photo "can take a minute or two". If you build something like this, show the backend and a time estimate in the UI; people forgive a slow job far more easily than a silent one.

What I'd do in a real project

Compare against the baseline. Always render resizeBaseline next to the network output. If you can't see a difference at 100% zoom, skip the network and save the battery.
Don't promise recovery. "Adds detail" is honest, "restores your photo" is not. Very blurry or heavily compressed sources improve only a little.
Cap the input, cap the output. Do the memory arithmetic first, then pick the limits.
Cache the model. A one-time 5 MB download is fine; downloading it on every visit is not.
Ship the tiling progress. It is the cheapest way to make a 15-second job feel acceptable.

If you want to try the browser-only setup yourself without writing it, the tool I used for the numbers above is here. Whatever you use, test it with one photo and one screenshot. The contrast between the two tells you more than any benchmark.

What's the largest image you've pushed through a model in the browser before the tab gave up? I'd like to know where your limit was.

How to get Google Trends data with an API (Python, Node or no code)

Big Man — Tue, 10 Nov 2026 00:41:54 +0000

Google Trends has no official public API, and the website hands you one chart at a time. If you want trend data in a spreadsheet, a dashboard or an AI agent's context (tracking demand for a product category every week, or spotting rising queries before they peak), you need another way to get it.

This tutorial uses Google Trends Scraper, an Apify actor I built. It returns three Google Trends widgets for up to 20 keywords per run: interest over time, interest by region and related queries. The output is flat rows that drop straight into Sheets or a BI tool. It works for any country or worldwide, over 7 days to 5 years, with no browser and no API key. The full examples are on GitHub: auto-actor/google-trends-scraper-all-widgets.

What people use it for

Weekly demand tracking for your product category or brand in one spreadsheet.
Finding rising related queries before they peak, for content and ads.
Comparing interest across countries for market entry decisions.

Input

{"keywords": ["bitcoin"], "geo": "", "timeRange": "past_12_months"}

Field	What it does
`keywords`	Up to 20 search terms to analyse.
`geo`	Two-letter country code such as `US`, `AU` or `GB`, or empty for worldwide.
`timeRange`	One of `past_7_days`, `past_30_days`, `past_90_days`, `past_12_months`, `past_5_years`.

Python

"""Run Google Trends Scraper on Apify and print the results.

    pip install apify-client
    export APIFY_TOKEN=...   # Apify Console -> Settings -> Integrations
    python example.py
"""
import os

from apify_client import ApifyClient

client = ApifyClient(os.environ["APIFY_TOKEN"])

run = client.actor("daedal_quintuplet/google-trends-scraper-all-widgets").call(
    run_input={
        "keywords": [
            "bitcoin"
        ],
        "geo": "",
        "timeRange": "past_12_months"
    }
)

rows = client.dataset(run["defaultDatasetId"]).iterate_items()
for row in rows:
    print(row["kind"], "|", row["label"], "|", row["value"])

Node.js

// Run Google Trends Scraper on Apify and print the results.
//
//   npm install apify-client
//   APIFY_TOKEN=... node example.js     (token: Apify Console -> Settings -> Integrations)

const { ApifyClient } = require('apify-client');

async function main() {
    const client = new ApifyClient({ token: process.env.APIFY_TOKEN });

    const run = await client.actor('daedal_quintuplet/google-trends-scraper-all-widgets').call({
        "keywords": [
            "bitcoin"
        ],
        "geo": "",
        "timeRange": "past_12_months"
    });

    const { items } = await client.dataset(run.defaultDatasetId).listItems();
    for (const row of items) {
        console.log(row.kind, '|', row.label, '|', row.value);
    }
}

main().catch((err) => {
    console.error(err);
    process.exit(1);
});

No code: one HTTP request

Works from n8n, Make, Zapier or curl:

curl -X POST "https://api.apify.com/v2/acts/daedal_quintuplet~google-trends-scraper-all-widgets/run-sync-get-dataset-items?token=$APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"keywords": ["bitcoin"], "geo": "", "timeRange": "past_12_months"}'

What you get

Every row has a kind, so you can filter it into one table per widget:

Field	Meaning
`keyword`	The search term the row belongs to
`kind`	`interest_over_time`, `interest_by_region` or `related_query`
`label`	Week range, region name or related query text, depending on `kind`
`time`	Unix seconds for `interest_over_time` rows; null otherwise
`value`	Google's relative score, 0 to 100
`geo`	Country code or `worldwide`
`trend`	`related_query` rows only: whether the query is from the top or rising list
`link`	`related_query` rows only: link to that query on Google Trends

Google Trends values are relative: 100 is the highest point for that keyword in the period you picked, not a count of searches.

Price

$0.0025 per row ($2.50 per 1,000 rows), paid per result, with no monthly fee. One keyword over 12 months produced about 170 rows in our tests, so about $0.43. Apify's free plan includes $5 of usage a month, which is enough to try it.

Links: Store page · GitHub examples

My AI Tests Passed While Half the Mutants Went Undetected

Meursyphus — Tue, 10 Nov 2026 00:34:17 +0000

If someone asked me how I verified code written by AI, I used to have a simple answer: I ran the tests.

My project had 451 tests across 84 files. Claude Code had written them, and I had reviewed and merged them. A green test run felt reassuring.

Then a friend mentioned mutation testing. I tried it on ten files in src/lib that already had tests. The tool generated 550 small changes to the production code and checked whether the tests noticed.

Scope	Mutants	Killed	Survived	No coverage
Ten tested files in `src/lib`	550	273	161	116

The tests caught 49.6% of those mutants. Another 161 survived despite running tests, and 116 had no test coverage.

That does not mean half of my 451 tests were worthless. It means roughly half of the generated mutations in this sample went undetected. That was enough to make me inspect what the tests actually asserted.

Some tests only checked the source text

Here is an excerpt from my project, with the test description translated:

function source(relativePath: string): string {
  return readFileSync(
    fileURLToPath(new URL(`../${relativePath}`, import.meta.url)),
    'utf8',
  )
}

it('separates new time credits from the legacy user baseline', () => {
  const codingTimeRepository = source(
    'src/server/repository/coding-time-credit/index.ts',
  )

  expect(codingTimeRepository).toContain('userCodingTimeCreditLedger')
  expect(codingTimeRepository).not.toContain('projectId')
})

This reads a file as a string and checks for words. It does not execute the credit calculation or verify its result.

I found 62 tests like this across seven files. They can enforce a convention, but they cannot establish that the program behaves correctly. The implementation could return the wrong value while those checks stay green.

Other patterns deserved a closer look too:

Copying the implementation's current output directly into the expected value, without checking whether that output matches the requirement.
Reimplementing the production algorithm inside the test to calculate the expected result.
Checking only that a mock was called. My project had 139 toHaveBeenCalled() assertions; the useful question was what each one established about behavior.
Treating test-file count or coverage as proof that important decisions have assertions.

None of this is unique to AI. But when the same agent writes the implementation and its tests in one session, both can inherit the same misunderstanding.

A 2026 study, All Smoke, No Alarm, examined 86,156 test-file patches from 33,596 agent-authored pull requests. Its syntactic classification found weak or absent explicit oracle signals in 80.2% of patches. That is a result about observable assertion patterns in that dataset, not proof that 80.2% of all AI tests are useless. It does reinforce why counting tests is a poor substitute for inspecting their checks. Study

Mutation testing checks whether a change makes a test fail

A mutation tool changes the production code in small ways: replacing < with <=, changing + to -, forcing a condition to false, or replacing a return value.

Each modified version is a mutant. The tool runs the relevant tests against it.

Result	Meaning
Killed	At least one test failed with the mutation active
Survived	The tests still passed
No coverage	No test covered the mutated code

These are the three results I focused on. Tools also report timeouts, invalid mutations, and other states. Stryker's overall score counts detected mutants against valid mutants; its covered-code score uses a different denominator. Stryker states and metrics

Consider this function:

function isUserOldEnough(user: { age: number }) {
  return user.age >= 18
}

If a mutant changes >= 18 to > 18, tests using ages 17 and 19 still pass. A test for exactly 18 can distinguish the two implementations.

Coverage can tell me that a test executed the comparison. Mutation testing helps me find whether the assertion notices a meaningful change to it.

Eleven tests missed six boundary changes

My first run used StrykerJS with Vitest in a Next.js project. The configuration was small:

{
  "testRunner": "vitest",
  "plugins": ["@stryker-mutator/vitest-runner"],
  "mutate": ["src/lib/**/*.ts"],
  "disableTypeChecks": false,
  "incremental": true,
  "reporters": ["clear-text", "html"]
}

With Stryker and its Vitest runner installed and the test configuration available, I ran:

npx stryker run

That initial run took 1 minute and 5 seconds in my project.

The disableTypeChecks: false setting kept Stryker from inserting its usual @ts-nocheck directives. It did not make Vitest perform TypeScript checking; type validation still needs its own checker or command. Stryker configuration

The most memorable result came from kstRelativeTime, a utility that produces labels such as “just now,” “three hours ago,” and “yesterday.” Eleven tests exercised it. All six mutants that changed < to <= survived.

I had tests around the date boundaries, but not at the boundaries. None asked what should happen at exactly 48 hours. A branch that produced a number of weeks had no coverage at all.

Other results were harder to ignore:

Changing + 1 to - 1 in a sequence number used for concurrent editing still passed.
Replacing if (local === remote) with if (false) in text-merging logic still passed.
The Markdown image parser killed only six out of 109 mutants.

Every one of those files already had tests. The CI result was green.

The source-text tests caused a different problem. Instrumentation changes the source file, so tests that inspect its literal text can fail because the tool inserted scaffolding. I excluded those tests from the mutation run. I wanted failures caused by changed behavior, not by the instrumentation's spelling.

Why this matters when agents write tests

Tests give a coding agent feedback. Weak assertions can tell the agent that it has finished even when an important behavior remains unchecked.

Mutation testing provides a more specific follow-up than “write more tests.” I can point to a surviving change and ask what input would distinguish the original behavior from the mutated behavior. Then I can review whether that expected result actually follows from the requirement.

Meta's Automated Compliance Hardener uses a related approach at a different scale. It generates concern-specific mutants with an LLM, then generates tests to catch faults that the existing suite misses. The reported deployment produced 9,095 mutants and 571 tests; engineers accepted 73% of tests in its Messenger and WhatsApp test-a-thons. The useful idea is that a new test can improve fault detection even when it exercises lines that existing tests already cover. Meta paper

The agent can help improve the tests, but I still need to decide what the program should do. Otherwise it can simply encode the same wrong assumption more thoroughly.

Keep the feedback close to the change

The obvious concern is runtime. A naive process that runs a five-minute suite for each of 1,000 mutants would take about 83 hours.

Modern tools avoid much of that repetition. Stryker can select tests using per-test coverage, and incremental mode reuses previous results where appropriate. That makes a small run on relevant logic a different proposition from mutating an entire repository every time. Stryker configuration, incremental mode

For Comwit and its project template, I adopted a few practical rules:

Start with application logic: utilities, server logic, APIs, and state. I excluded pages, routing, UI components, and database schemas from this particular setup.
Run mutation tests on changed files during normal work. Use a broader run occasionally to establish a baseline.
When an agent changes tests, have it run the changed-file mutation command and inspect survivors.
Review survivors by cause. A boundary change suggests an exact-value test; a skipped branch suggests a missing input path. Equivalent behavior or irrelevant logging changes need a different decision.

The command in my repository is pnpm test:mutation:changed. It is a project-specific script, not a built-in Stryker command.

I also ran a larger baseline: 902 logic files, 41,343 mutants, and about 49 minutes in my environment.

Area	Total mutants	Covered mutants	Survived	Score on covered mutants
All targeted logic	41,343	10,230	3,799	62.9%
`src/server/repository`	12,516	5,121	2,021	60.5%
`src/server/domain-jobs`	2,490	1,084	459	57.7%

The denominator matters. The 62.9% figure describes the covered mutants, not all 41,343 generated mutants. Only about a quarter of the generated mutants had coverage, and more than a third of those covered mutants survived.

Those numbers gave me places to investigate. They did not give me a reliable estimate of how many production bugs the application had.

The score is a prompt to investigate

A surviving mutant is not automatically a missing requirement. Some mutations leave observable behavior unchanged. Those equivalent mutants cannot be killed by a test that correctly checks the same behavior.

Mutation testing also cannot prove that the implementation matches the intended specification. It checks sensitivity to the generated changes. A test suite and implementation can agree with each other and still agree on the wrong behavior.

That is why I do not want the mutation score to become a team KPI. It would be easy to optimize the number and miss the reason for running the tool.

I still ask AI to write tests. What changed is the next question I ask: if this code were slightly wrong, which test would notice?

In my first run, one minute of mutation testing gave me a much more useful review queue than another reassuring green check.

I build Comwit, where this workflow is part of the project template. Adapted from my original Korean article on Velog, published October 7, 2026.

Contact: X @meursyphus.

Merging PDFs With Different Page Sizes: Why the PDF Organiser Counts A5 and Legal as Other

OnePassApps — Tue, 10 Nov 2026 00:14:33 +0000

I work on OnePassApps, the team behind app.onepassapps.com. This is our own PDF Organiser.

When you merge PDF files whose pages are different sizes, something has to give: one sheet size for all of them, or one size per page. Our PDF Organiser does the second one. Each page keeps the size it arrived with, and the exported file proves it.

The Paper row names two sizes and stops there

I loaded five one-page PDFs into the PDF Organiser in one browser session: A4 (595.92 x 841.92 pts), US Letter (612 x 792 pts), US Legal (612 x 1008 pts), A5 (420 x 595.92 pts) and a custom 7 x 9 inch sheet (504 x 648 pts). The Source step read "5 of 20 PDFs" and "5 of 300 pages".

The Export step has a Paper row. With those five sheets loaded it reads:

Paper
1 A4 - 1 Letter - 3 other

Two sizes are named, and the count is right: there is one A4 page and one Letter page. Everything else is folded into "other". The Legal, the A5 and the custom sheet are three pages, and the panel calls them "3 other". So the row is a summary of how many pages sit on each size, not a list of every size in the file. If you are checking a merge by paper size, that is the line to read - and if you expected it to name your Legal or A5 sheet, or to print their dimensions, it will not.

An earlier post of mine measured this same row on 7 November 2026, when it read in millimetres for each distinct size instead. I have linked it at the end rather than repeat it: this is the same app and the same question, answered from today's build.

Nothing is resized

I pressed "Download PDF" and read the exported file back page by page with pdfinfo:

Page 1: 595.92 x 841.92 pts (A4)
Page 2: 612 x 792 pts (letter)
Page 3: 612 x 1008 pts
Page 4: 420 x 595.92 pts (A5)
Page 5: 504 x 648 pts

Every page came out at the size it went in at. The A4 page was not stretched to Letter, the A5 page was not scaled up, and the custom sheet was not snapped to anything. On a four-page run (A4, Letter, A5 and the custom sheet) pdftotext pulled the four headings back out of the export in order, so the content came through with the sizes.

Rotation travels with the page

With four sheets loaded I pressed "Rotate right" on the first page tile. The panel moved to "Rotated 1 of 4 pages", and the exported file carried it as page 1 rot 270 - the other three pages stayed at rot 0. The turn is written as a page rotation flag, not by swapping the width and height of the page box, so the page box itself is unchanged.

What the export offers, and what I could not reach

The Export step lists two things: "Combined PDF", with the line "organised.pdf - up to 64 MiB", and "Split ZIP", with the line "up to 50 pages - 50 MiB".

I could not run the Split ZIP export. The export area holds no radio inputs at all, and the only export button on the page is "Download PDF". Clicking the "Split ZIP" label itself changed nothing - the export buttons and the Paper row were identical afterwards. So the ZIP is described in the panel, and I am not claiming I produced one. The guide repeats it as part of the app's scope: "Merge, split, reorder, and rotate existing PDF pages locally."

The panel also carries one warning worth reading before you rely on a merge: "Page content is preserved. Bookmarks, forms and digital signatures may not carry over to a new export."

The limits it states

The Source step reads "Up to 20 PDFs, 25 MiB each, 50 MiB combined and 300 pages. Encrypted PDFs are not supported." The app's own guide puts the same numbers in a different order: "Imports allow up to 20 files, 25 MiB per file, 50 MiB combined and 300 pages."

The page says "Nothing leaves this tab." I traced the network while the export ran: 137 requests, and every one of them was a GET. No PDF byte was posted anywhere.

Try it

Open the PDF Organiser

Read the PDF Organiser guide

Earlier measurement of the same row

Merge PDFs With Different Page Sizes in the Browser: What the Export Actually Does - published on Substack on 7 November 2026.

Supabase "email rate limit exceeded"? Turn on custom SMTP, then raise the limit

Ahmed Hassan Yaseen — Tue, 10 Nov 2026 00:14:24 +0000

Sign-ups worked yesterday. Today new users never get the confirmation email, and the sign-up or reset call comes back with one of these:

email rate limit exceeded
over_email_send_rate_limit
429 Too Many Requests
Email address not authorized
email_address_not_authorized

Supabase's built-in email provider sends at most 2 emails an hour for the whole project, and only to members of your team. Connect your own SMTP provider and Supabase sends to every address, starting at 30 emails an hour, which you can raise.

I see this a lot in Lovable and Bolt apps on Supabase right when the first real users arrive.

Why it happens

The default email service is still on. It refuses addresses outside the project team (email_address_not_authorized) and sends 2 emails an hour for the whole project, across every sign-up, reset, magic link and invite. Supabase describes it as best effort and not meant for production.
Too many emails to one address. Repeated sign-up or reset attempts trip over_email_send_rate_limit (HTTP 429) for that address. By default the same user waits 60 seconds before another confirmation or reset email.
The custom SMTP limit is still the starting value. After you add custom SMTP, Supabase starts at 30 emails an hour to protect your new sender's reputation, until you change it.

Find the cause

Read the error code returned by the sign-up or reset call. over_email_send_rate_limit and email_address_not_authorized need different fixes.
In the Supabase dashboard, open Authentication > SMTP settings and check whether custom SMTP is enabled.
Open Authentication > Rate Limits and read the limit for emails sent.

Fix 1: connect a real email provider

Create an SMTP account with a transactional email provider and verify your sending domain there.
In Authentication > SMTP settings, enter the host, port, username, password, a From address such as no-reply@yourdomain.com, and a sender name.
Save. From then on, Supabase sends auth emails to every address, not only your team.

Fix 2: raise the limit to fit real traffic

Set the limit for emails sent in Authentication > Rate Limits to cover your busiest hour of sign-ups and resets. Or do it from a script with the Management API:

# Access token from https://supabase.com/dashboard/account/tokens
export SUPABASE_ACCESS_TOKEN="your-access-token"
export PROJECT_REF="your-project-ref"

# Read the current limit
curl -X GET "https://api.supabase.com/v1/projects/$PROJECT_REF/config/auth" \
  -H "Authorization: Bearer $SUPABASE_ACCESS_TOKEN" | jq '.rate_limit_email_sent'

# Set it to your busiest hour of auth emails (replace <emails-per-hour>)
curl -X PATCH "https://api.supabase.com/v1/projects/$PROJECT_REF/config/auth" \
  -H "Authorization: Bearer $SUPABASE_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "rate_limit_email_sent": <emails-per-hour> }'

Keep the per-user wait between emails, so one person can't flood their own inbox.

Check the fix worked

Sign up with an address outside your team: the confirmation arrives from your domain.
Request three password resets in an hour from different addresses: all of them arrive.

Stop it coming back

Switch to custom SMTP before you invite any real users.
Add the sending domain's SPF, DKIM and DMARC records at your provider so the emails reach inboxes.

Quick answers

Is the built-in service fine for launch? No. Supabase describes it as best effort, for testing and non-critical projects, with no delivery guarantee.

Does this affect magic links and invites too? Yes. Every auth email, including one-time codes, magic links and invites, goes through the same sender.

Sources: Supabase rate limits, Send emails with custom SMTP, Auth error codes.

Full write-up with the same steps: Supabase "email rate limit exceeded": the fix. Before launch, the free Launch Check looks over your live app for exposed keys, missing security headers and broken basics.

I wrote this with AI assistance and reviewed it myself.

Designing fair romaji acceptance for a browser Japanese typing game

Typing Sushi Lab — Tue, 10 Nov 2026 00:14:04 +0000

Building a browser typing game for Japanese learners sounds simple until you hit romaji variants.

Learners type the same mora many ways: shi vs si, chi vs ti, fu vs hu, long vowels with or without u, and ん before consonants. If the game only accepts one spelling, practice becomes frustration instead of muscle memory.

What we wanted

For 寿司打 (Sushida), a free browser sushi typing practice site, the goals were:

Accept common Hepburn / kunrei-style variants learners actually use
Keep scoring fair (no free points for wrong kana)
Stay entirely client-side (no iframe embeds of third-party games)
Work on a phone keyboard and a physical JIS/US layout

Acceptance table, not string equality

Instead of comparing raw input to a single canonical string, we normalize keystrokes through a small acceptance table:

Map each target mora to a set of allowed romaji spellings
Consume the longest matching spelling from the left (greedy but bounded)
Reject mid-mora garbage early so the falling sushi does not “stick”

This is closer to how IME romaji engines think than to input === answer.

Edge cases that surprised us

ん before な行: nna vs n'na — we accept both when the next mora starts with n
長音: ou / oo / ASCII approximations for some learners
促音: doubling the consonant (kitte) must not steal the next mora’s first letter incorrectly
Mixed scripts: if someone pastes kana mid-word, fail soft and show the expected romaji hint

Why not just use an IME?

IME composition is great for writing, terrible for a falling-object timing game. Composition windows steal focus and break frame timing. We keep the game on raw keydown and teach romaji explicitly — that is the skill people practice on 寿司打.

Takeaway

If you ship a Japanese typing practice game in the browser, invest in the acceptance table before the particle effects. Fair input parsing is the product.

Free to try: https://sushida.org/

Stopwatch: How I Built a Sub-Second Transit Schedule Lookup for 123 Systems from Open GTFS Data

Shivrajsinh Zala — Tue, 10 Nov 2026 00:13:44 +0000

When you're rushing to catch a bus or train, you don't need a heavy 50MB map application that stalls on 3G connections. What you need is an instant, readable, stop-by-stop schedule: when is the next bus arriving, when is the last bus tonight, and what does the full day's service look like?

That challenge led me to create Stopwatch — a lightweight, instant public transit timetable lookup tool covering 123 transit networks across the United Kingdom, United States, Canada, Australia, Ireland, and New Zealand.

The entire codebase is open source on GitHub: shivrajsinhzala/transit-timetables.

Why Transit Schedules Need a Lightweight Alternative

Most transit agencies provide two options:

Raw PDFs or Slow HTML Tables: Often buried three layers deep in municipal portals, poorly formatted for mobile viewports.
Heavy Mapping Apps: Heavy routing calculators that consume battery, require background location tracking, and take 5–10 seconds to render when cellular reception is weak at an underground station or remote bus stop.

Stopwatch was architected specifically to bridge this gap: deliver clean, readable, full-day timetables with sub-second page loads on any device, fully accessible and offline-capable as a progressive web app (PWA).

Technical Highlights & Architecture

1. Ingestion of 123 GTFS Feeds

General Transit Feed Specification (GTFS) data is the global standard for public transit schedules. Stopwatch ingests static GTFS feeds across 123 agencies (from London buses and Sydney trains to Phoenix Valley Metro, Dublin Bus, Toronto TTC, and Auckland Transport).

Normalizes disparate agency stops, routes, service calendars, and trip stop times into a compressed schema.
Pre-calculates calendar exceptions (calendar_dates.txt) for accurate weekend, weekday, and public holiday departure tables.

2. Static Pre-Rendering & Edge CDN

Timetables are statically generated and cached at the edge, guaranteeing sub-100ms first contentful paint (FCP).
Zero tracking scripts, zero third-party telemetry, and zero bloat.
Built-in Service Worker caching allows commuters to check recently viewed lines even with zero cellular signal.

3. Phone-First Typography

Reading timetable matrices on small screens outdoors in harsh sunlight requires clear contrast, high typography standards, and clean hourly breakdowns rather than cramped desktop-oriented tables.

Explore Stopwatch & Source Code

Live Timetable Viewer: https://transit.shivrajsinh.in/
GitHub Repository: https://github.com/shivrajsinhzala/transit-timetables

Whether you commute daily or build open-source transit tools, feel free to explore the app, report issues, or contribute new agency feeds!

Why sRGB Euclidean Distance Fails on Paint Swatches (And How CIEDE2000 Fixes It)

Someesim — Tue, 10 Nov 2026 00:10:38 +0000

If you sample a wall color from a room photograph—say #DCE3E6—and search a database of 15,000 commercial paint swatches using standard RGB Euclidean distance, the top result frequently looks visibly purple or green once rolled onto drywall.

1. Non-Linearity of sRGB Gamma Encoding

Standard hex codes live in gamma-compressed sRGB space rather than linear light intensity. Before comparing two colors, each channel C_srgb in [0, 1] must be linearized:

const linearize = (c) => (c <= 0.04045 ? c / 12.92 : Math.pow((c + 0.055) / 1.055, 2.4));

Once linearized, the relative luminance Y = 0.2126 * R + 0.7152 * G + 0.0722 * B maps directly to the paint industry's Light Reflectance Value (LRV, 0–100) printed on the back of fan decks from Sherwin-Williams, Benjamin Moore, and Behr.

2. Perceptual Uniformity and the Blue-Hue Twist

Even after converting linear RGB to CIE XYZ (D65 illuminant) and CIE L*a*b*, simple Euclidean distance (CIE76) over-penalizes saturated yellows and under-penalizes subtle hue shifts in low-chroma grays—the exact region where 70% of architectural interior paints sit.

The CIEDE2000 (ΔE00) formula introduces three perceptual corrections essential for cross-brand swatch matching:

Lightness, Chroma, and Hue Weighting Functions (S_L, S_C, S_H) that compress tolerance ellipses near neutral grays so warm greige never collides with cool slate.
G-Factor Expansion on the a* Axis to sharpen red-green sensitivity on subtle off-whites.
Rotation Term (R_T) in the 275° Blue Region correcting the well-known CIE Lab curvature where navy blues drift toward violet.

3. Practical Thresholds for Cross-Brand Paint Equivalents

When matching across proprietary fan decks—for example, finding the closest Benjamin Moore or Behr swatch to a Sherwin-Williams specification—ΔE00 values map reliably to human perception under D65 daylight:

ΔE00 < 1.0: Imperceptible difference on adjacent walls.
1.0 ≤ ΔE00 ≤ 2.0: Close cross-brand match suitable for trim/wall pairings when sheen is matched.
ΔE00 > 2.5: Noticeable undertone shift under 2700K warm LED lighting.

You can inspect live ΔE00 distances, LRV values, and cross-brand equivalents directly with the HEX to paint swatch converter at PaintColorMatcher, or query its stateless JSON-RPC endpoint (https://paintcolormatcher.com/api/mcp) from terminal workflows.

I made a free browser version of the "word impostor" party game — pass-and-play or online rooms

Jeson — Tue, 10 Nov 2026 00:09:59 +0000

At game nights my friends kept playing "Who's the Impostor?" with slips of paper. Someone always peeked, and someone always lost the slips. So I built Word Impostor, a free browser version you can play on one phone or across everyone's phones.

How it plays

3 to 10 players. Most players get the same secret word; one player — the Impostor — gets a related but different word. Everyone takes turns describing their word without saying it, then you vote on who seems off. The Impostor wins by blending in.

For bigger groups (6+) there's an optional Mr. White role who gets no word at all and has to bluff from context.

Two ways to play

Pass-and-play: one device goes around the table; each player taps to see their word privately.
Online rooms: the host creates a room and shares a short code; friends join from their own phones. No app and no sign-up.

Word packs cover themes like food, travel and internet culture.

Why browser-only

Party games die the moment someone has to install an app or make an account. Keeping it as a plain web page means anyone at the table can join in seconds.

Try it

Grab some friends and open imposterwords.com. Suggestions for new word packs are very welcome in the comments.