DEV Community

Splitting "jumped" into jump/ed with three regexes, and the 3 words out of 36 it got wrong

Sam — Fri, 13 Nov 2026 01:33:34 +0000

Speech-language pathologists measure a child's MLU, mean length of utterance, by counting morphemes, not words. "Doggie jumped" is two words but three morphemes: doggie, jump, -ed. On a 50-utterance sample that counting is slow, so the MLU calculator I maintain has an "auto-mark" button: it rewrites jumped as jump/ed, and every slash adds one morpheme to the count. The clinician then fixes whatever it got wrong.

This post is about how little code that takes, and where it breaks.

The whole marker

Three suffix rules, three exception lists, and two guards for capitalised words:

if (lw.length >= 5 && /ing$/.test(lw) && KEEP_ING.indexOf(lw) < 0) return w.slice(0, -3) + '/' + w.slice(-3);
if (lw.length >= 4 && /ed$/.test(lw)  && KEEP_ED.indexOf(lw)  < 0) return w.slice(0, -2) + '/' + w.slice(-2);
if (lw.length >= 4 && /s$/.test(lw)   && KEEP_S.indexOf(lw)   < 0 && !/ss$|us$|is$|ous$/.test(lw))
  return w.slice(0, -1) + '/' + w.slice(-1);

The length checks keep bed, red and is away from the rules before the lists are even consulted. The exception lists hold the words that only look inflected: KEEP_ING has thing, ceiling, morning, nothing; KEEP_ED has need, bread, hundred, instead; KEEP_S has always, pants, scissors, news, lots. Words that start with a capital in the middle of a line are treated as names and left alone, and anything that already contains an apostrophe is skipped, because contractions and possessives are counted by a separate rule (Mommy's and can't are 2 each).

Irregular forms need nothing at all. went, feet and children have no suffix to strip, so they stay at 1, which is how most counting guides want them. Same for gonna, birthday and doggie.

Testing it on 36 words

I ran the real function from the page in Node on 36 words a 3-year-old might say, and compared each count with the convention the tool itself follows (its own exception lists):

jumped     -> jump/ed      2
sleeping   -> sleep/ing    2
hiking     -> hik/ing      2
dishes     -> dishe/s      2
ladies     -> ladie/s      2
pants      -> pants        1
scissors   -> scissors     1
pajamas    -> pajama/s     2   <- should be 1
jeans      -> jean/s       2   <- should be 1
does       -> doe/s        2   <- depends on your manual

33 of 36 came out as intended. The three misses are instructive.

pajamas and jeans. The tool already counts pants and scissors as one morpheme, because there is no singular "pant" a toddler is contrasting it with. pajamas and jeans are the same kind of word, they just weren't in the list. The rule is right; the list is incomplete. That's the general failure mode of this design: every miss is a missing entry, and you only find them by feeding it real transcripts.

does. Here the code isn't wrong so much as opinionated. goes comes out as goe/s and does as doe/s, two morphemes each. Some manuals count does as a single irregular form, the way went is. If you follow one of those, you fix it by hand. A tool can't settle that for you, and pretending it can would be worse than leaving the slash visible.

The cosmetic bug that doesn't matter

dishes becomes dishe/s, ladies becomes ladie/s. Linguistically the cut is dish/es, and ladies is lady plus a plural ending, but MLU only cares how many pieces there are, not where the cut falls, and both versions give 2. I left it, because the clinician sees the marked text and dishe/s is obviously "dish plus plural" to a human reader. Getting the boundary right would mean a small stemmer for -es, -ies and doubled consonants (running, stopped), and none of that changes a single count.

Why not a real stemmer or an NLP library

A Porter stemmer would give hike from hiking, which looks nicer, but it also strips derivational endings like -ness and -ful, which usually don't count as separate morphemes in this kind of sample. A part-of-speech tagger would tell bored (adjective) from jumped (verb), but child speech is full of fragments that taggers handle badly, and the whole page runs offline in the browser with no model to download. Three regexes plus lists that grow from real misses turned out to be the more honest tool: when it is wrong, you can see exactly why.

If you want to try it on your own sample, it's the MLU calculator on SLP Age Calc. Paste one utterance per line, press auto-mark, and check the slashes before you trust the number.

Load Testing Our Checkout Pipeline Without Taking Down Production

Taocarts跨境 — Fri, 13 Nov 2026 01:32:18 +0000

-->

Load Testing Our Checkout Pipeline Without Taking Down Production

Every cross-border commerce team learns the same lesson during peak season: the checkout path is the one place you cannot afford to fall over, and it is also the place you are most afraid to stress-test. At Taocarts, a platform that mirrors Chinese marketplaces (Taobao, 1688) into overseas storefronts and consolidates purchasing and shipping, we spent a peak season watching our checkout bend before we finally built a safe way to break it on purpose.

The naive approach fails quietly

Our first instinct was to point a load tool at the production checkout URL and crank the concurrency. It "worked" once, then we agreed never to do it again — a misconfigured ramp brought the live storefront down for nine minutes during a real promo. Testing against production is too risky; not testing at all is worse.

What we actually do now

We run load tests against a full staging environment that mirrors production's topology: same Laravel API, same database engine, same queue workers, but isolated tenant data and a separate payment gateway in sandbox mode. The goal is never to "test the real thing", it is to test the same code and the same shape of traffic.

The traffic shape matters more than the volume. A real checkout burst is not uniform. It is a sharp ramp at a promo start, a long plateau, then a second spike when the "last chance" reminder fires. We replay recorded traffic patterns from previous peaks, scaled up, rather than a synthetic flat flood.

The parts that actually break

Under load, the checkout path fails in predictable places. Database connections exhaust first because every request opens a short-lived read. We moved read-heavy lookups (product display, exchange-rate snapshots) behind a cache with a short TTL, so a spike in browsing does not translate one-to-one into database hits.

The second failure is the payment confirmation step. When the gateway slows, requests pile up waiting for a callback ACK. We capped in-flight payment confirmations per worker and pushed the slow part onto a queue, so a slow gateway degrades gracefully instead of cascading.

The third is email and notification fan-out. Sending a confirmation per checkout synchronously is fine at 10 requests per second and fatal at 400. We made all notifications fire-and-forget through the queue.

How we know it worked

We do not trust a single passing run. Each test produces a report: p95 and p99 latency at target concurrency, error rate, and where the saturation point was. If p99 climbs past our threshold before we reach target load, the test "failed" by design and we go fix the bottleneck. The point is to find the wall in staging, not in front of real buyers.

The payoff

After we standardized this, our last two promo peaks passed without a checkout incident. More importantly, when something does saturate, we now have a number for where, instead of a 3 a.m. guessing game.

Load testing checkout is not glamorous, and it will never be the demo slide. But the checkout is where revenue is won or lost in milliseconds — testing it safely, against a mirror of production, is one of the highest-leverage things a commerce backend team can do.

Can You Upscale a 480p Hit the Road Dude Clip to 1080p? Lanczos vs Bicubic vs Unsharp, Scored Against a Ground Truth

Peiguan — Fri, 13 Nov 2026 01:31:44 +0000

A question that comes up about Hit the Road Dude AI videos, the State Property pickup-window meme where the driver repeats "State?" and tells the visitor to hit the road, goes roughly: "My clip is 480p. Can I upscale it to 1080p so it doesn't look soft on a TikTok or Shorts upload?" Chatbots usually answer "yes, with ffmpeg or an AI upscaler" without saying what that buys you.

I build hittheroaddude.app, an independent studio that makes a 15-second, vertical 9:16 remake from one photo at 480p or 720p, with a newly generated voice (FAQ). It doesn't sell a 1080p option, so anyone who wants 1080p is upscaling outside the site. This post doesn't claim any upscaler makes a generated clip look better. It shows how to measure what the common ffmpeg options do, using a method that has an honest answer: build a ground truth first.

Why you can't just compare two upscales

If you only have the 480p file, there is no "correct" 1080p to compare against, and two upscales can only be compared by eye. The fix is to go backwards. Take a detailed 1080x1920 frame, shrink it to 480 px wide, upscale that back to 1080 px with each method, and score each result against the original frame. Whatever the method gets wrong shows up as a lower score. It is a synthetic test, not a claim about generated video, but the ranking tells you which filter loses the least when detail has been thrown away.

The script below makes two test frames: a "graphic" one with thin lines, small text and hard edges, and a "photo" one built from smooth blurred colour plus grain. It scores PSNR (average pixel error, in dB, higher is better) and SSIM (structural similarity from ffmpeg's ssim filter, 1.0 is identical).

#!/usr/bin/env python3
"""Score ffmpeg upscalers against a known ground truth.

A real 480p clip has no 1080p original to compare with, so build one: render a
detailed 1080x1920 frame, shrink it to 480x854 (the "480p" you would have), upscale it
back with each method, and score the result against the original frame.

usage: upscale_compare.py [--keep DIR]
needs: ffmpeg on PATH, Python 3, Pillow, numpy
"""
import argparse, os, re, subprocess, sys, tempfile
import numpy as np
from PIL import Image, ImageDraw, ImageFilter

W, H, SW, SH = 1080, 1920, 480, 854


def ffmpeg(*args):
    r = subprocess.run(["ffmpeg", "-v", "error", "-y", *args], capture_output=True, text=True)
    if r.returncode:
        sys.exit(r.stderr)


def make_ground_truth(path, kind):
    rng = np.random.default_rng(7)
    if kind == "graphic":          # hard edges, thin lines, small text: stress test
        im = Image.new("RGB", (W, H), (30, 60, 110))
        d = ImageDraw.Draw(im)
        for i in range(0, W, 24):
            d.line([(i, 0), (i, H)], fill=(230, 230, 230) if (i // 24) % 2 else (20, 20, 20), width=2)
        for y in range(100, H, 160):
            d.rectangle([80, y, W - 80, y + 70], outline=(255, 200, 0), width=3)
            d.text((100, y + 20), "STATE? THIS IS PRIVATE PROPERTY. HIT THE ROAD, DUDE.", fill=(255, 255, 255))
        d.ellipse([300, 800, 780, 1280], outline=(255, 80, 80), width=4)
        im.save(path)
    else:                          # soft "photo-like" content: blurred noise + gradients + a bit of grain
        base = rng.random((H // 16, W // 16, 3))
        im = Image.fromarray((base * 255).astype("uint8")).resize((W, H), Image.BICUBIC)
        im = im.filter(ImageFilter.GaussianBlur(3))
        a = np.asarray(im).astype(np.float32) + rng.normal(0, 4, (H, W, 3))
        Image.fromarray(np.clip(a, 0, 255).astype("uint8")).save(path)


METHODS = {
    "bilinear": "scale={W}:{H}:flags=bilinear",
    "bicubic": "scale={W}:{H}:flags=bicubic",
    "lanczos": "scale={W}:{H}:flags=lanczos",
    "lanczos+unsharp": "scale={W}:{H}:flags=lanczos,unsharp=5:5:0.8:5:5:0.0",
    "lanczos+unsharp(strong)": "scale={W}:{H}:flags=lanczos,unsharp=5:5:1.8:5:5:0.0",
}


def ssim(a, b):
    r = subprocess.run(["ffmpeg", "-v", "info", "-i", a, "-i", b, "-lavfi", "ssim", "-f", "null", "-"],
                       capture_output=True, text=True)
    return float(re.search(r"All:([0-9.]+)", r.stderr).group(1))


def psnr(a, b):
    x = np.asarray(Image.open(a).convert("RGB"), dtype=np.float64)
    y = np.asarray(Image.open(b).convert("RGB"), dtype=np.float64)
    mse = ((x - y) ** 2).mean()
    return 99.0 if mse == 0 else 10 * np.log10(255 ** 2 / mse)


def main():
    ap = argparse.ArgumentParser()
    ap.add_argument("--keep", help="keep the intermediate PNGs in this directory")
    args = ap.parse_args()
    work = args.keep or tempfile.mkdtemp(prefix="upscale_")
    os.makedirs(work, exist_ok=True)
    print(f"{'content':8} {'method':24} {'PSNR dB':>8} {'SSIM':>7}")
    for kind in ("graphic", "photo"):
        gt = f"{work}/{kind}_gt.png"
        small = f"{work}/{kind}_480.png"
        make_ground_truth(gt, kind)
        ffmpeg("-i", gt, "-vf", f"scale={SW}:{SH}:flags=area", small)       # the "480p" you start from
        for name, graph in METHODS.items():
            out = f"{work}/{kind}_{re.sub(r'[^a-z]+', '_', name)}.png"
            ffmpeg("-i", small, "-vf", graph.format(W=W, H=H), out)
            print(f"{kind:8} {name:24} {psnr(out, gt):8.2f} {ssim(out, gt):7.4f}")


main()

What it printed

content  method                    PSNR dB    SSIM
graphic  bilinear                    20.12  0.7773
graphic  bicubic                     20.69  0.7866
graphic  lanczos                     20.82  0.7769
graphic  lanczos+unsharp             21.04  0.7610
graphic  lanczos+unsharp(strong)     20.64  0.7241
photo    bilinear                    36.26  0.9583
photo    bicubic                     36.59  0.9598
photo    lanczos                     36.57  0.9598
photo    lanczos+unsharp             36.35  0.9583
photo    lanczos+unsharp(strong)     36.01  0.9559

Checked on the box with ffmpeg 7.1.5, Python 3.13, Pillow 13 and NumPy 2.5. The test frames are seeded, so you should get the same numbers.

What the numbers say

On smooth, photo-like content the methods are almost tied. Everything lands between 36.0 and 36.6 dB and 0.956 to 0.960 SSIM. Bicubic and lanczos are best by a hair, and the sharpening filter makes the score slightly worse, because it adds edges the original frame never had.
On hard edges the ranking is messier. Lanczos plus a light unsharp has the best PSNR (21.04 dB) but the worst SSIM of the non-aggressive options (0.761 against 0.787 for plain bicubic). The two metrics disagree, which is a sign that none of these filters recovers detail. They differ in how they distribute the error.
Strong sharpening loses on both metrics (20.64 dB, 0.724 SSIM). If a clip looks "crunchy" after upscaling, that is the cause.
None of them rescue the lost detail. A 480p file doesn't contain 1080p information, so upscaling changes the pixel grid, not what is in the picture. What it can do is make a platform more likely to keep a higher bitrate for your upload, which is a different benefit and one I haven't measured.

What I'd actually do

Use scale=1080:-2:flags=bicubic or lanczos and skip the sharpening, or add the light unsharp only if you like how it looks on your own clip and check it at phone size. Upscale once, from the original download, as the last step before export, so you don't compress twice. Keep the vertical 9:16 shape: for a 480-wide source that is scale=1080:1920.

ffmpeg -i clip.mp4 -vf "scale=1080:1920:flags=lanczos" -c:v libx264 -crf 18 -preset slow -c:a copy clip_1080.mp4

That command is not tested on a real generated clip, since I'm not publishing any generated results here. It is the same scale filter the script ran on PNGs. If you want to test on your own clip, extract a frame, downscale it, upscale it, and run the metrics from this script on the pair.

Where it fits

The 480p or 720p guide covers the choice the studio actually offers. If you're deciding whether the sharper 720p is worth it before going anywhere near an upscaler, start there. Then upload only a photo of yourself, an adult who agreed, or your own pet, and label the result as an AI remake.

For reference, checked on November 13, 2026 at 09:02 (UTC+8): one clip at hittheroaddude.app is $9.99 at 480p (6 credits) or $12.99 at 720p (14 credits), with credit packs for signed-in accounts at $27.99 for 30 credits, $71.99 for 100 and $129.99 for 200 (pricing).

CVE-2026-126190: CVE-2026-126190: Polynomial-Time Denial of Service in Soup Sieve CSS Descendant Combinator

CVE Reports — Fri, 13 Nov 2026 01:31:20 +0000

CVE-2026-126190: Polynomial-Time Denial of Service in Soup Sieve CSS Descendant Combinator

Vulnerability ID: CVE-2026-126190
CVSS Score: 7.5
Published: 2026-11-13

CVE-2026-126190 (GHSA-mmhr-3c5m-f64f) is an inefficient algorithmic complexity vulnerability (CWE-407) in Soup Sieve, the default CSS selector library integrated into Beautiful Soup 4. In versions prior to 4.0, evaluating CSS selectors that contain descendant combinators (whitespace between compound selectors) executes an unmemoized upward traversal of the document tree. When evaluated against deeply nested HTML or XML documents, the time complexity scales polynomially at O(n^(k+1)), where n is the tree depth and k is the number of descendant combinators. Remote attackers can supply compact, deeply nested markup (1 KB to 4 KB) to trigger prolonged CPU starvation and denial of service in Python applications.

TL;DR

Soup Sieve versions prior to 4.0 fail to memoize ancestor evaluations when matching CSS descendant combinators, leading to O(n^(k+1)) polynomial time complexity and remote denial of service via small, deeply nested HTML or XML payloads.

⚠️ Exploit Status: POC

Technical Details

Vulnerability ID: CVE-2026-126190 / GHSA-mmhr-3c5m-f64f
Weakness Class: CWE-407: Inefficient Algorithmic Complexity
CVSS v3.1 Score: 7.5 HIGH (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)
Affected Component: soupsieve (< 4.0.0) / CSSMatch.match_past_relations
Time Complexity: O(n^(k+1)) unpatched vs. O(n) patched
Primary Impact: Denial of Service via CPU Exhaustion
Exploit Status: Public PoC Available
Patched Version: soupsieve 4.0

Affected Systems

Soup Sieve (soupsieve PyPI package)
Beautiful Soup 4 (bs4) applications utilizing .select() or .select_one()
soupsieve: < 4.0.0 (Fixed in: 4.0)

Code Analysis

Commit: ff1a5ce

Cache whether an element is or has a matching ancestor when matching the descendant combinator (a b) to avoid polynomial time complexity.

diff --git a/soupsieve/css_match.py b/soupsieve/css_match.py
index ced22901..f2bcdabc 100644
--- a/soupsieve/css_match.py
+++ b/soupsieve/css_match.py
@@ -614,6 +614,7 @@ def __init__(
         self.enable_cache = not bool(self.flags & util.NOCACHE)
         self.nth_cache: dict[Hashable, list[int]] = {}
         self.sib_cache: dict[Hashable, int] = {}
+        self.anc_cache: dict[tuple[int, int], bool] = {}
         self.dir_cache: dict[int, int] = {}
         self.index_cache: dict[int, dict[int, int]] = {}

@@ -648,6 +649,7 @@ def reset(self) -> None:  # pragma: no cover

         self.nth_cache.clear()
         self.sib_cache.clear()
+        self.anc_cache.clear()
         self.dir_cache.clear()
         self.index_cache.clear()

@@ -989,6 +991,31 @@ def match_general_sibling(self, el: bs4.Tag, relation: ct.SelectorList) -> Match

         return found

+    def match_ancestor(self, el: bs4.Tag, relation: ct.SelectorList) -> MatchGenerator:
+        """
+        Match descendant combinator.
+
+        A selector with several descendant combinators tries every ancestor for each one, which is
+        a polynomial of the depth with a degree of the number of combinators. Every element visited
+        on the walk shares the result, so cache whether each one is or has a matching ancestor.
+        """
+
+        found = False
+        visited: list[tuple[int, int]] = []
+        parent: bs4.Tag | None = el
+        while not found and parent and (parent := self.get_parent(parent)):
+            key = (id(parent), id(relation))
+            if key in self.anc_cache:
+                found = self.anc_cache[key]
+                break
+            visited.append(key)
+            found = yield parent, relation
+
+        for key in visited:
+            self.anc_cache[key] = found
+
+        return found
+
     def match_past_relations(self, el: bs4.Tag, relation: ct.SelectorList) -> MatchGenerator:
         """Match past relationship."""

@@ -998,9 +1025,12 @@ def match_past_relations(self, el: bs4.Tag, relation: ct.SelectorList) -> MatchG
             return found

         if relation[0].rel_type == REL_PARENT:
-            parent: bs4.Tag | None = el
-            while not found and parent and (parent := self.get_parent(parent)):
-                found = parent is not None and (yield parent, relation)
+            if self.enable_cache:
+                found = yield from self.match_ancestor(el, relation)
+            else:
+                parent: bs4.Tag | None = el
+                while not found and parent and (parent := self.get_parent(parent)):
+                    found = parent is not None and (yield parent, relation)
         elif relation[0].rel_type == REL_CLOSE_PARENT:
             parent = self.get_parent(el)
             found = parent is not None and (yield parent, relation)

Exploit Details

GitHub Security Advisory: Official advisory containing benchmark data and proof-of-concept demonstrating O(n^(k+1)) polynomial slowdown using nested div tags.

Mitigation Strategies

Upgrade the soupsieve Python package to version 4.0 or later to enable ancestor evaluation caching.
Audit codebase to ensure the soupsieve.NOCACHE flag is never enabled when evaluating selectors on untrusted HTML or XML input.
Refactor CSS selectors to use direct child combinators (>) instead of whitespace descendant combinators where document structure permits.
Enforce maximum DOM nesting depth limits and execution timeouts around HTML parsing routines.

Remediation Steps:

Run pip install --upgrade 'soupsieve>=4.0' in all affected Python environments and container images.
Verify the installed version using python -c 'import soupsieve; print(soupsieve.__version__)' to confirm it is 4.0 or newer.
Search application source code for references to sv.NOCACHE or util.NOCACHE and remove them from untrusted parsing workflows.
If immediate patching is not possible, rewrite multi-stage descendant selectors (e.g., section div div) to use child combinators (section > div > div) or single-stage queries.

References

Read the full report for CVE-2026-126190 on our website for more details including interactive diagrams and full exploit analysis.

Encrypting data in localStorage does not protect your JavaScript (or your users)

VEILVM — Fri, 13 Nov 2026 01:30:27 +0000

A pattern shows up in a lot of front-end code reviews: some piece of data — a token, a cached profile, a license flag, sometimes even a "secret" configuration — is written to localStorage, and when someone objects, the answer is "we'll encrypt it." The team imports a library, picks a password or a key baked into the bundle, and calls the problem solved.

It is not solved. In the browser, encryption without a key the attacker does not have is a delay, and often a short one. This article separates three different goals that get bundled under "encrypt localStorage," because they need different designs.

Three problems people think they are solving

Hiding application logic. The JavaScript that implements a feature should not be easy to copy. localStorage is irrelevant to this. Your logic is already in the JS files the browser downloaded.
Stopping a casual user from editing a value. For example, flipping plan: "free" to plan: "pro" in DevTools. Encryption can make that edit slightly harder if the value is also integrity-protected, but only if the key is not sitting next to the ciphertext, and only if the server still enforces the plan.
Protecting data at rest from another program on the same machine. This is a real threat model (shared computers, malware, other extensions), and it is the one Web Crypto can actually help with — if, and only if, the key is not shipped in your bundle.

If you do not know which of these you mean, you will pick a library, wrap localStorage.setItem, and ship a harder-to-read JSON blob that still decrypts in the console in one call.

Where the key lives is the whole story

A typical "encrypted localStorage" helper looks like this:

const KEY = "s3cret-please-ignore"; // or CryptoJS.enc.Utf8.parse("...")

export function save(name, value) {
  const cipher = encrypt(JSON.stringify(value), KEY);
  localStorage.setItem(name, cipher);
}

export function load(name) {
  const cipher = localStorage.getItem(name);
  return JSON.parse(decrypt(cipher, KEY));
}

The ciphertext in Application → Local Storage looks impressive. The key is in the same origin's JavaScript, which the same person who opened DevTools can also read. From there the decrypt function is a copy-paste away.

Variations that fail the same way:

Key derived from a hard-coded salt and a hard-coded passphrase.
Key fetched from your own front-end config file or a "secret" environment variable that was inlined at build time (VITE_STORAGE_KEY and friends).
Key "hidden" by obfuscating the file that contains it. Obfuscation raises the cost of finding the key; it does not create a key the user does not have. Once the app runs, the key is in memory.

If your app can decrypt the value without the user entering a secret, so can anyone who controls that browser origin.

What Web Crypto is actually good for

The Web Crypto API (crypto.subtle) is a solid tool. Use it when the key is not a constant in your repo.

A model that makes sense: the user has a passphrase (or a platform authenticator), you derive a key with PBKDF2 or Argon2 (the latter via a library; Web Crypto provides PBKDF2), and you encrypt with AES-GCM so you get confidentiality and integrity.

const enc = new TextEncoder();

async function keyFromPassphrase(passphrase, salt) {
  const base = await crypto.subtle.importKey(
    "raw", enc.encode(passphrase), "PBKDF2", false, ["deriveKey"]
  );
  return crypto.subtle.deriveKey(
    { name: "PBKDF2", salt, iterations: 310_000, hash: "SHA-256" },
    base,
    { name: "AES-GCM", length: 256 },
    false,
    ["encrypt", "decrypt"]
  );
}

This protects data at rest against someone who has the disk or the localStorage dump but not the passphrase. It does not protect data from the user who knows the passphrase, from XSS on your origin (which can prompt or wait for the key to be used), or from your own application logic being read.

XSS is the uncomfortable part. Anything your page can decrypt, a injected script on the same origin can decrypt too. localStorage plus encryption is not a substitute for a strict CSP, HTTP-only cookies for session tokens, or not storing tokens in JavaScript-accessible storage in the first place.

License flags and "pro unlocked" values

This is the case that looks like a code-protection problem and is actually an authorization problem.

If the client reads localStorage.plan === "pro" and shows the paid UI, an encrypted value does not help. The user patches the decrypt result, or the branch that reads it, or they skip the check. The server has to be the source of truth for entitlements, and the client should treat a local cache as a cache.

What is a code-protection problem is the function that validates a license offline — a signature check, a domain lock, a short-lived offline grant. That function is source you may want to protect, because the failure mode is "patch this one if." Encrypting the string it writes to localStorage does not protect that function. Protecting the function (and still verifying on the server when a network is available) does.

VEILVM is a browser-based JSVMP workspace for that narrower job: you extract the sensitive function and compile it to a custom bytecode with a small interpreter, so a beautifier does not immediately reveal the check. It raises cost; it does not replace server-side authorization, and it does not make a baked-in storage key safe.

A practical policy

Session tokens: prefer HTTP-only, Secure, SameSite cookies. If you must keep a token in the browser, know that any script on your origin can read it; encryption with a bundled key adds almost nothing.
Cached user data: encrypt only when you have a user-held secret or a platform key, and document the threat you are addressing (at-rest on a shared machine, not "users cannot see their data").
Entitlements and prices: the server decides; the client may cache a signed blob it can verify, not a boolean it can flip.
Proprietary logic: protect the code, do not bury it in localStorage.

If you want to try VM protection on a small license or verification function, VEILVM runs in the browser with no sign-up: 3 free runs a day, up to 5 KB per file (resets at 00:00 UTC). A free account raises the input limit to 30 KB. Pro is $9/month or $79/year and adds an API for CI. Standard requests are processed in memory and are not written to logs. Start at https://vm.ldvmp.com.

Ranking 58 electric cars on sourced facts only, and what the rules turned up

Ejaz Arain — Fri, 13 Nov 2026 01:29:19 +0000

Most car rankings start from a test drive or a reviewer's opinion. For the Q4 2026 edition of the TrustList rankings we tried something stricter: order electric and plug-in hybrid cars only on facts that can be sourced and dated. These are crash-test results from Euro NCAP, IIHS or NHTSA, plus what each maker states on its own pages for that market.

This post covers the rules we used, and what they did to the results.

The rules

Fixed, public weights. Safety 25, range 20, charging 15, software updates 15, battery warranty 10, driver assistance 10, app 5.
A rank number needs evidence. A car is ranked if it has a crash-test result or three sourced facts. Anything else is listed, not ranked.
Like with like. Ranges are compared only on the same test cycle. A range with no named cycle is held but not compared.
Facts expire. A fact read more than a year ago is not counted until it is read again.
Price is shown, never scored. Nobody pays for a place.

Each fact on the page carries the date it was read. For this edition that was 17 or 18 October 2026.

What the rules did

Coverage. The UK electric ranking lists 58 cars and ranks 50. The UK plug-in hybrid ranking lists 13 and ranks 5. The Europe electric ranking lists 15 and ranks 12.

Safety barely separates the leaders. All of the UK top 24 have a Euro NCAP result. Twenty-one have five stars and three have four (Kia EV3, Kia EV4, Cupra Raval). The heaviest weight, then, decides almost nothing at the top.

Missing fields decide a lot. For 13 of the UK top 24 we hold nothing about software updates from the maker's UK pages. For 11 we hold nothing on battery warranty. Not one of the five ranked plug-in hybrids has software updates on record, and in Europe 10 of the 12 ranked cars have none. These are gaps in what the makers publish, not proof that a feature is missing. A sourced-facts model can only credit what is written down.

Rule 3 matters. The longest WLTP range in the UK top 24 is the Volkswagen ID.7, at 697 km. It ranks 21st, because we hold nothing on its charging, software updates or driver assistance. The Cupra Born (624 km) and Cupra Raval (442 km) quote ranges with no named test cycle, so those figures are not compared with the WLTP ones.

Units are not always comparable. Some makers publish a 10 to 80 percent charging time. Others give only a peak power, such as "up to 260 kW DC" for the Hyundai IONIQ 5. Among the cars that publish the time, the UK range runs from 18 minutes (Kia EV6, Genesis GV60) to 32 minutes (Toyota bZ4X).

Rule 2 lets a car rank without a crash test. The Toyota Prius Plug-in Hybrid is fifth among UK plug-in hybrids on three sourced facts: 85 km of WLTP electric range, a three-year battery warranty and its app. In Europe, the Leapmotor B03X, the Leapmotor T03 and the Rimac Nevera rank the same way.

Price stays out of the score. The UK number one, the Polestar 3, starts at £76,540. The Kia EV3 is seventh from £31,555. The Cupra Raval, 24th, is the cheapest of the top 24 at £25,495 with the Electric Car Grant applied.

What we would change

The biggest weakness of the model is visible above. A maker that publishes less ranks lower, whatever the car is like. We think that is the right incentive for a buyer reading makers' pages. But it means the ranking measures disclosure as much as the car. The next edition is due in January 2027, and every gap listed here can be closed by a dated page from the maker.

The rankings, with each fact and its read date:

Play Google Com Console: Complete Guide for Developers

Play Console Store — Fri, 13 Nov 2026 01:28:45 +0000

When developers search for the "play google com console," they're looking for one thing: the front door to Google's Android publishing platform. The exact address is play.google.com/console — that's the Google Play Console, the web dashboard where Android developers register, upload apps, manage releases, and track performance. But getting there and getting in isn't always as simple as typing a URL: wrong bookmarks, signed-in personal accounts, expired sessions, and regional redirects trip up developers every day.

In short: The Play Google Com console lives at play.google.com/console — sign in with the Google account that owns your developer account, keep 2-Step Verification on, and use the desktop web console for full publishing work. This guide covers the official URLs, sign-in, account switching, the mobile app, and fixes for the access errors that lock developers out.

What are the official Play Console URLs?

Bookmark these — they're the only addresses you should ever use to reach the console:

Main dashboard: play.google.com/console — your developer home after sign-in, showing all apps.
Sign-up page: play.google.com/console/signup — where new developers register and pay the $25 fee.
Developers homepage: play.google.com/console/about — overview of features (useful to share with clients).
Help center: support.google.com/googleplay/android-developer — official documentation for every feature.

Security warning: only ever sign in at play.google.com or accounts.google.com. Phishing sites mimic the console login with lookalike domains (play-google-console.com, googleplayconsole.net). Check the address bar before entering credentials — Google will never ask you to sign in to the console from any other domain.

Purpose	Address
Main dashboard	play.google.com/console
Sign-up page	play.google.com/console/signup
Developers homepage	play.google.com/console/about

How do I sign in to the Play Console?

Step 1: Use the right Google account

The console doesn't have its own username/password system — it uses Google account sign-in. The Google account you sign in with becomes (or is linked to) your developer identity, so choose deliberately:

Signing in with your personal Gmail creates a personal developer account tied to that address.
Agencies should use a dedicated work Google account, not an employee's personal Gmail — when people leave, access gets messy.
One Google account can own one developer account but be invited to many others as a user.

Step 2: Complete the sign-in flow

Go to play.google.com/console. If you're not signed in, Google redirects you to accounts.google.com. Enter your email, password, and complete 2-Step Verification if enabled (it should be — developer accounts are high-value targets). After authentication, you land on the All apps dashboard.

Step 3: Handle the first-visit setup

First-time visitors without a developer account see the registration flow: choose personal or organization account type, complete identity verification, pay the $25 registration fee, and accept the Developer Distribution Agreement. Verification typically takes a few hours to a couple of days. Until it's complete, most console sections show as locked or pending.

How do I switch between multiple developer accounts?

Freelancers and agencies often juggle several developer accounts — their own plus clients'. The console handles this through Google's account switcher plus an invitation system:

Invited users: clients invite you via Setup → Users and permissions → Invite new users. You accept with your own Google account and switch between accounts from the profile avatar menu. This is the correct way to manage client apps — never ask clients for their Google password.
Chrome profiles: run each developer identity in a separate Chrome profile. This eliminates the classic mistake of uploading a client's app while signed in as yourself.
Account switcher: click your avatar (top right) to switch Google accounts without signing out. The console remembers the last developer account per Google identity.

Common pitfall: being signed in to five Google accounts in one browser and not knowing which one owns the developer account. If the console shows "no developer account found," you're almost certainly signed in with the wrong Google identity — check the avatar email before assuming your account is gone.

Can I access the console on my phone?

Google offers the Play Console app (Android and iOS) as a companion to the web dashboard. It's genuinely useful for:

Checking download and revenue statistics on the go
Reading and replying to user reviews
Receiving push alerts for policy violations, crashes spikes, and review milestones
Monitoring staged rollout progress

What it can't do: create developer accounts, upload app bundles, complete policy declarations, or manage users and permissions. For those, you need the desktop web console. Think of the mobile app as mission-control telemetry, not the cockpit.

To install it, search "Google Play Console" in the Play Store or App Store and sign in with the same Google account that owns your developer account. If you manage multiple developer accounts as an invited user, they all appear in the app's account switcher.

How do I fix common console access problems?

"This account isn't a developer account"

You signed in with a Google account that has no developer registration. Either register at play.google.com/console/signup or switch to the Google account that owns the developer account (check the avatar email).

Redirect loops and blank pages

Usually caused by corrupted cookies or overzealous extensions. Fix: open an incognito window and sign in fresh. If that works, clear cookies for google.com in your main browser and disable ad-blockers on play.google.com — several popular blockers break the console's JavaScript.

Session expired / signed out unexpectedly

The console times out idle sessions for security. If it happens constantly (not just after idleness), check whether a VPN or corporate proxy is rotating your IP — Google treats rapid IP changes as suspicious and kills sessions. Whitelist google.com in the VPN or use a stable connection for console work.

"Access denied" on a client's account

Your invitation was revoked, expired, or never accepted. Ask the account owner to re-invite you under Setup → Users and permissions. Invitations expire after a set period, and owners sometimes remove freelancers after projects end without notice.

Regional redirect issues

In some regions, play.google.com redirects through a country-specific domain or loads slowly. The console itself is global — your developer account works identically everywhere — but if pages fail to load, try a direct connection without VPN first, then re-enable it.

| Problem | Likely cause | Fix |
|---|---|
| "This account isn't a developer account" | Signed in with a Google account that has no developer registration | Register at play.google.com/console/signup, or switch to the Google account that owns the developer account |
| Redirect loops and blank pages | Corrupted cookies or overzealous extensions | Use an incognito window; if that works, clear cookies for google.com and disable ad-blockers on play.google.com |
| Session expired / signed out unexpectedly | VPN or corporate proxy rotating your IP | Whitelist google.com in the VPN, or use a stable connection for console work |
| "Access denied" on a client's account | Invitation revoked, expired, or never accepted | Ask the account owner to re-invite you under Setup → Users and permissions |
| Regional redirect issues | play.google.com redirects through a country-specific domain or loads slowly | Try a direct connection without VPN first, then re-enable it |

What are the console access best practices for teams?

Never share one Google account across a team. Invite each member with their own Google identity and assign least-privilege roles (Release manager, Support, Finance — not Admin for everyone).
Enable 2-Step Verification on every Google account with console access. Developer accounts are prime phishing targets because they control app signing keys and revenue.
Use security keys (hardware tokens) for account owners — they're phishing-resistant in a way SMS codes aren't.
Audit access quarterly: Setup → Users and permissions shows every invited user and their role. Remove ex-employees and finished contractors promptly.
Keep a private access log of which Google account owns each developer account. When someone leaves, this document is the difference between a smooth handover and a locked-out business.

The bottom line

The Play Google Com console lives at one address — play.google.com/console — but using it well means mastering sign-in discipline: the right Google account, clean browser sessions, proper team invitations instead of shared passwords, and the mobile app for on-the-go monitoring. Most "access problems" are really account-confusion problems, and they're solved in the avatar menu, not in a support ticket. If you'd like expert help getting your console access right from day one, Play Console Store helps Android developers with Play Console setup, account access configuration, and team permission structuring.

FAQ

What is the correct URL for the Play Google Com console?

The official URL is play.google.com/console. New developers register at play.google.com/console/signup. Bookmark it, and only sign in at play.google.com or accounts.google.com — any other domain asking for your console credentials is a phishing attempt. If you land anywhere else, close the tab and type the address yourself.

Why does play.google.com/console say I don't have a developer account?

You're signed in with the wrong Google account. The console ties developer registration to a specific Google identity — click your avatar (top right) to check which email is signed in, then switch to the one you registered with or complete registration for the current one.

Can I access the Play Console from my phone?

Yes, via the Play Console app for Android and iOS. It covers statistics, reviews, alerts, and rollout monitoring, but full publishing workflows (uploads, policy declarations, user management) require the desktop web console at play.google.com/console. Install it by searching "Google Play Console" in the Play Store or App Store, then sign in with the same Google account.

How do I manage multiple developer accounts in the console?

Have each client invite your Google account under Setup → Users and permissions, then switch between accounts from the avatar menu. For clean separation, use a separate Chrome profile per client so you never upload to the wrong account. Never ask a client for their Google password — the invitation flow exists precisely so you never need it.

The console keeps signing me out — how do I fix it?

First try an incognito window to rule out cookie or extension issues. If the problem persists, check for VPN IP rotation, since Google kills sessions on rapid IP changes. Then clear google.com cookies and disable ad-blockers on play.google.com. If none of that helps, try a direct connection without the VPN first, then re-enable it.

About the author

This guide was prepared by the publishing team at Play Console Store — an independent marketplace for Google Play publishing services (release management, closed testing coordination, policy compliance, and app publishing assistance). Play Console Store is not affiliated with or endorsed by Google LLC.

Seedream 5.5: native transparent backgrounds are the feature to care about

Jerry Simth — Fri, 13 Nov 2026 01:27:42 +0000

ByteDance released Seedream 5.5 on November 9, 2026, and most of the coverage leads with photorealism — fair enough, it is a visible step up from the 5.0 line. But the more practical news for anyone who actually ships images is quieter: 5.5 is the first Seedream that cuts subjects out natively. Turn on the transparent background toggle and the model returns a PNG with a real alpha channel. No remove.bg step, no masking in Photoshop, no paying a second tool to finish the job.

I run a small studio site that hosts 33 image models side by side, so new releases go straight into the rotation. Here's what 5.5 is actually good for, and where it isn't the right pick.

The transparent background, in practice

The workflow is exactly as boring as it should be: write your prompt, flip the toggle, get a cutout. What it's for:

Product shots for listings and ads — a perfume bottle, a sneaker, a gadget, isolated and ready to drop onto any background.
Stickers, icons and UI assets — the kind of small graphics that used to mean a generation plus a cleanup pass.
Mockups and compositing — generate the subject once, reuse it across ten layouts.

A sticker-style cutout straight from the generator — real Seedream 5.5 output, PNG with an alpha channel, no cleanup pass.

A product shot of the kind you'd normally shoot in a studio — real Seedream 5.5 output.

Two honest caveats. First, cutout quality still depends on the subject: hard edges (packaging, bottles, electronics) come out clean; hair, fur and wispy edges are where any automatic cutout earns its keep, so test your edge cases before you build a workflow around them. Second, semi-transparent materials — glass, smoke, sheer fabric — are genuinely hard to represent in an alpha channel, and no model has that fully solved. Transparency is a feature, not magic.

The toggle itself costs nothing extra: the price is the same as a normal generation.

Multi-round editing that holds up

The other real change is edit stability. 5.5 is built to survive round after round on the same subject — restyle a product shot, swap the background, change the lighting, then change it back. The studio takes up to 10 reference images, so you can hold a product, a style reference and a background in the same edit. Edits start at 5 credits, plus 2 per extra reference.

The same bottle from above, moved onto a marble vanity by a background-swap edit — one round, same subject held.

This is the difference between a model you prompt once and a model you art-direct. The first kind gives you a lottery ticket; the second gives you a working file.

What it costs

Text to image: 4 credits at 1K and 1.5K, 6 credits at 2K
Edits: from 5 credits (+2 per extra reference, up to 10)
15 aspect ratios, from 1:3 skyscraper to 21:9 ultrawide; JPEG and PNG output

That's cheaper per image than Seedream 5 Pro, which is part of the point — 5.5 is the new generation, not a premium tier above it.

Where 5 Pro still wins

Honesty requires the other side: Seedream 5 Pro still renders the family's sharpest headline typography at 2K. If your job is a poster with a big display headline and small badge text, 5 Pro is the sharper pick. 5.5 wins on price, framing range, transparency and edit depth; 5 Pro wins on lettering. Pick by the job, not by the version number.

Try it

The model runs on Seedream 5.5 in the studio — 20 free credits at signup, no card, drafts from 4 credits. If transparent backgrounds are part of your workflow, the toggle is the first thing worth testing.

Testing Client Timeout Behavior

Jeff — Fri, 13 Nov 2026 01:26:35 +0000

Quick answer: A timeout is the client deciding to stop waiting, not a response from the server, so test it with fixed mock latency that lands just before and just after the threshold. Assert that the call aborts with the right error, the loading state resets, timers and in-flight work are cleaned up, retries follow a backoff schedule, and a response that arrives after the abort is ignored rather than applied twice. If you only test the fast, successful call, the slow path is still untested.

A timeout is a client decision, not a server error

When the threshold passes, the server may still be processing the request, which is why a blind retry can create a duplicate side effect. Three distinct decisions get conflated under the word timeout. A connect timeout means the TCP connection never established. A read or request timeout means the connection opened but the full response did not arrive in time. An idle timeout means the response started and then stalled, such as headers arriving with no body. Each needs its own case because the cleanup and the error the caller sees are different. Default values in an HTTP library are generic and rarely match your real latency distribution, so leaving them untouched either makes users stare at a spinner or kills slow but successful calls.

Pin the latency to the threshold

Use a local mock with a fixed, known delay rather than a real network, and set the delay to the threshold value and to one millisecond on either side. The boundary case is the one that reveals off-by-one configuration: a response that resolves at the limit should still succeed, while one a moment later should abort. Keep the delays large and stable so a busy machine cannot blur them, and run the near and far cases in the same test so the threshold is judged against both. A desktop API workspace can set mock latency directly and drive conditional overrides, so the timing is chosen in advance and the same run reproduces every time. Powerduck works this way, keeping the timeout test local and repeatable instead of dependent on live network conditions.

The timeout types worth covering

Timeout type	Trigger	Mock setup	Expected client behavior
Connect	TCP connection never opens	Endpoint that refuses or drops the connection	Fail fast, retry with backoff
Read/request	Connected, full response too slow	Fixed latency just over the threshold	Abort, show error, reset loading
Idle/stream	Response stalls after headers	Send headers, then hold the body	Abort the partial read, clean up
Late response	Result arrives just after abort	Latency just past the threshold	Ignore the late result, no double apply

What to assert after the abort

Check the error type and message rather than only that a promise rejected, and confirm the loading flag returns to idle so the UI is not stuck. Verify the timer that drove the timeout is cleared and the in-flight request is cancelled rather than left running. For retries, assert the count and spacing against a backoff schedule and an overall deadline, and treat a non-idempotent POST carefully because an automatic retry can repeat a charge or a create. The late-response row matters most: when the answer arrives after the abort, the client must not apply it to state that already moved on, and must not process the same result twice. A 200 that lands late is still a response the client should treat as stale.

Honest limits

A local mock runs in the desktop main process and reproduces waiting time, but it does not model the full shape of a real failure. It cannot reproduce a half-open TCP connection, a network reset, packet loss, or a server that keeps processing after the client leaves, and application-level fixed delays do not exercise the operating system's real socket behavior. The mock proves the named timeout paths and the client's handling of them; it does not replace genuine network tests or a check of what the server does when the caller disconnects. Importing a schema does not deploy a backend, and a passing mock run is not evidence about production connectivity.

Frequently asked questions

What is the difference between a connect and a read timeout? A connect timeout means the connection never opened. A read timeout means it opened but the response did not finish in time, so the cleanup and error differ.

Why test a response that arrives after the timeout? The server may still answer. The client must ignore that late result instead of applying it to stale state or handling the same response twice.

Should a timed-out POST be retried automatically? Only if the operation is idempotent or carries an idempotency key. Otherwise the retry can repeat a side effect that the first request already performed.

How should I choose the threshold? Base it on the real latency distribution rather than a local round trip, set separate connect and read values, and confirm the choice against live measurements.

The bottom line

Treat timeout as client behavior and pin it with fixed mock latency around the exact threshold, covering the connect, read, idle, and late-response cases. Assert on the error, loading reset, cleanup, backoff-driven retries, and the late response that gets ignored, then verify real socket behavior and server-side handling separately. For more on this approach, see the API testing guide hub.

Book cover sizes that actually break at upload

尚毅段 — Fri, 13 Nov 2026 01:26:29 +0000

A cover that looks finished can still fail at the KDP upload step. When it does, the error is usually not about the artwork. It is a number that came from a different version of the book.

I maintain the sizing calculator at BookCoverGen, and the same handful of mismatches show up in support mail. Here they are in the order they cost people the most time.

The only arithmetic that matters

A print cover is one flat file:

width = panel + panel + spine + 0.25 in
height = trim height + 0.25 in

The 0.25 in is 0.125 in of bleed on each outside edge. The panels come from the trim size. The spine comes from page count times paper thickness.

For 6 x 9 in at 300 pages on black-and-white white paper, KDP's per-page figure is 0.002252 in, so the spine is 0.676 in and the full wrap is 12.93 x 9.25 in. Every case below is that calculation going wrong in a different place.

1. Your page count changed after the cover was built

This one gets caught in the previewer, not at your desk.

Re-paginate a manuscript and the spine moves. 6 x 9 at 250 pages on white paper is 0.563 in. At 300 pages it is 0.676 in. That is 0.113 in, close enough to an eighth of an inch, and it lands exactly where the author name sits on the spine. On a fold, an eighth of an inch is the difference between centered and cut.

Build the cover after the final proof, not after the first draft. If the interior changes, re-run the calculation before the next upload.

2. The paper changed, the cover did not

KDP's spine math is per paper type:

black-and-white white paper: 0.002252 in per page
black-and-white cream paper: 0.002500 in per page
premium color white paper: 0.002347 in per page

At 300 pages the white-paper spine is 0.676 in. The same 300 pages on cream is 0.750 in. The file has to grow by 0.074 in, and the front and back panels shift outward with it. Switch paper at the pricing step and keep the old cover, and the spine type is off the fold.

3. The file has no bleed, or bleed on two edges

A print file is trimmed after it is printed. The artwork has to run past the trim line on the top, bottom and outside edges, which adds 0.25 in to both dimensions.

Two common versions of this:

the file is built at trim size (12 x 9 in for 6 x 9 at 300 pages, not 12.93 x 9.25 in);
the designer adds bleed at the outer edges of the front and back panels but not across the spine wrap.

Both look fine on screen, because the missing strip is white and the background is white. The previewer is the first place the trim sliver shows up, and a background that stops at trim size will show a hairline at the cut.

4. The ebook cover was exported from the print panel

Ebooks have no spine, no bleed and no back cover. KDP asks for a front cover of 1,600 x 2,560 px at a 1.6 aspect ratio, JPEG or TIFF, under 50 MB.

The print panel for 6 x 9 in at 300 DPI is 1,800 x 2,700 px. The ratio is 1.5, not 1.6, so it does not simply scale down. What happens next depends on the store: the image gets cropped, padded, or rendered smaller in the thumbnail grid than a properly sized file. Export the ebook cover at the pixel size, separately from the print export.

5. Spine text on a book that will not print it

KDP prints spine text only above 79 pages. Below that the spine stays blank, so artwork should run through it and type should not be there at all. Type placed on a 40-page file does not appear in print; if the page count later grows past 79, the old file still has type set for a spine width it no longer has.

When there is spine text, it needs 0.0625 in clear on each side of the fold. Thin books have thin margins. Check the template before the title goes on the spine.

6. More than one page, fonts not embedded, images below 300 DPI

These are the boring checks that produce failed preflight:

the wrap is one page: back cover, spine, front cover, never three separate files;
fonts embedded, not linked;
images at 300 DPI at final size;
one flattened layer, no live transparency.

The barcode area on the back cover has to stay clear. The template marks where it goes.

Before you upload, check these six

Final page count, after the last proof.
The paper type you will actually print on.
Full wrap = panels + spine + 0.25 in.
Bleed 0.125 in on the top, bottom and outside edges.
Spine text only over 79 pages, 0.0625 in clear on each side.
Ebook cover exported at 1,600 x 2,560 px, separate from the print wrap.

KDP publishes the current figures and changes them. The calculator on our site runs the same arithmetic with your page count and exports a layout guide at 1 unit = 1 inch, but the printer's template is the final word. When a file fails at upload, the error text is usually accurate about which of these six it is.

Turning the Page: Replacing single-spa with CollageJS

José Pablo Ramírez Vargas — Fri, 13 Nov 2026 01:25:48 +0000

It's been a while since I don't write about the micro-frontends topic, mostly due to other responsibilities and then other interests.

However, today I'm back with this very interesting topic: Micro-frontends.

As many people know already, I created only short 4 years ago the only plug-in in existence for Vite and the excellent single-spa routing library. The plug-in, named vite-plugin-single-spa was highly successful, serving up to 25,000+ downloads from npmjs.com weekly with less than 10 bugs reported.

This plug-in enabled many of us to opt-in to move modern projects to single-spa because we were unwilling to give up Vite. In short: The plug-in was a complete success.

Nothing is forever, however. For people that don't know, single-spa creator passed away in November 2025, and no core team was left behind to perpetuate and evolve the single-spa environment.

We, single-spa users were now left adrift with a library that most likely won't be maintained ever again. It is time to switch to a different technology.

Deciding the Switch

For me, the decision was simple because my selection of single-spa back in 2022 was also simple: Simple router with minimal restrictions, easy micro-frontend interface (the lifecycle functions) and everything else was opt-in, such as the use of import-map-overrides.

Now we face extinction, and moving to the previously-studied-and-discarded micro-frontends solution was not an option: All their problems and dislikes back then are still there; the alternatives haven't changed. I still didn't want the complex Piral requiring a CDN and online accounts, or Module Federation being only a micro-frontend solution if we are talking same-framework projects (my projects aren't same-framework projects), etc.

In light of this, I decided to contribute an evolution of single-spa: CollageJS.

CollageJS: Inception

After working with the amazing Svelte framework, single-spa and my Vite plug-in, I've come to realize I had a lot of margin for improvement. This improvement is CollageJS' main objective.

CollageJS has taken the core concept of the single-spa parcel and has evolved it to make it the only thing needed. In CollageJS, this concept is named Core Piece.

Core pieces are the micro-frontends and they can be as big or as small as we want them to be. These pieces are defined in TypeScript as an interface:

export interface CorePiece<TProps, TMeta> {
  mount: MountFn<TProps> | MountFn<TProps>[];
  relocate?: RelocateFn | RelocateFn[];
  update?: UpdateFn<TProps> | UpdateFn<TProps>[];
  meta?: TMeta & {
    remountable?: boolean;
    relocatable?: boolean;
  };
}

The only required method is mount. This keeps the creation of pieces (micro-frontends) super easy.

Improvements Over single-spa

Because single-spa had struggled over the years to keep up, it is no surprise to know that there were many small and not-so-small bugs and issues at its core. I have made sure CollageJS overcomes them. Just to name a few improvements:

Full TypeScript support
Multiple copies of pieces can coexist at the same time
All framework adapters support update of properties and a framework-specific component to mount core pieces
No name collisions between adapter component properties and the properties of the micro-fronted being mounted (the core piece)
Idempotent unmount lifecycle

If you would like to see a more complete list of improvements, head to the migration guide, at the bottom.

Improved Developer Experience

Have you ever worked with import maps? If you have, you understand that their use is quite convenient but makes us developers repeat module names around, especially because most of the time, we need to externalize the modules whenever we bundle our projects.

With the new set of Vite plug-ins for CollageJS, our developer experience is improved. In root projects (the project that loads other projects and provides the import map):

Import maps are auto-externalized
We get the import map overriding tool set up

In core piece projects:

Import maps are auto-externalized while in dev mode automatically
CSS is mounted for us

We also get a brand new import map-overriding solution with a modern user interface and more advanced features:

Migrating Projects

Migrating projects from single-spa to CollageJS is incredibly fast. Generally speaking, most projects take only about 10 minutes of work. This means that migrating an entire system, even if comprised of dozens of projects, can migrate in one day with barely any visible difference.

If you're in the single-spa boat and want out, just follow the migration guide.

Test Drive CollageJS

If you're feeling curious about how this works, it can be tested in minutes by cloning the template repository, either with GitHub's template funcionality, or with the degit command:

npx degit https://github.com/collagejs/root-template.git

Feel free to experience micro-frontends with full Vite v8 and TypeScript support. Happy coding!

The follow-up I lost in a Slack thread (and the one-page tracker that would have caught it)

lululapeng — Fri, 13 Nov 2026 01:25:36 +0000

I once let a warm “let’s start next month” message die in a Slack thread I forgot to star.

The client was real. The budget was real. I had quoted, they had said yes-in-spirit, and then a product launch ate both of our weeks. When I finally remembered to nudge them, the thread was buried under 200 unread messages and they had already hired someone who followed up on a Tuesday.

The fix was not “check Slack more.” It was a single place that answered three questions every Friday in under ten minutes:

Who is open? — lead, discovery, proposal sent, waiting, active, won, lost
When did I last touch them? — a date, not a vibe
What is the next visible action? — one verb: send proposal, nudge, send invoice, schedule kickoff, mark lost

I keep it boring on purpose: a Clients list, a Pipeline board (Lead → Discovery → Proposal → Won / Active / Lost), and an Invoices table (Draft → Sent → Due → Overdue → Paid). Notion works. A Markdown table works. A spreadsheet works. The tool matters less than looking at it once a week before you open chat.

You can steal the shape today: make three columns (name / last touch / next action), dump every half-alive lead into it, and set one 15-minute Friday review. No kit required.

Want a free taste of the paperwork stack first? Five one-pagers (rate card, kickoff questions, change-order, three client emails, tax habits) sit in a pay-what-you-want sampler:

https://lulupearl0.gumroad.com/l/freelance-starter-sampler

Need a clean deposit/final invoice PDF with no signup?

https://eclectic-cactus-07703e.netlify.app/

If you want the Notion-ready Markdown tables + a CSV import starter + a weekly dashboard checklist in one ZIP, I bundled it as a $19 Freelance Client Tracker (no monthly SaaS):

https://lulupearl0.gumroad.com/l/freelance-client-tracker

Building in public: store has views, revenue is still $0. Soft promo stays honest. If you use a simpler tracker ritual that actually sticks, I would love to hear it.