DEV Community: FF

Your internet isn't slow — it's bufferbloat. Diagnose it in 25 seconds.

FF — Sat, 31 Oct 2026 07:26:03 +0000

You pay for 500 Mbps. At 2 a.m. everything is instant. At 7 p.m., when someone starts a game update, your video call turns into a slideshow — and the speed test you run right after still cheerfully reports 500 Mbps.

Nothing is broken. Your speed test just doesn't measure the thing that's actually hurting you.

The number that speed tests don't show you

Raw bandwidth answers "how much data can move per second". It says nothing about how long each tiny packet waits when the line is busy — and that latency-under-load number is what real-time apps live and die by.

That problem has a name: bufferbloat.

Modern routers and modems buffer packets instead of dropping them. That's polite under light load, but when a download saturates your link, outgoing packets — your video call frames, your game inputs — get stuck at the back of a huge queue. Your ping goes from 8 ms to 300+ ms while the download runs. The call stutters. The game desyncs. When the download finishes, everything is magically fine again, which is why it feels haunted.

Jitter is the sibling problem: the variation in your ping between packets. Real-time codecs can hide high latency better than they can hide inconsistent latency.

The 25-second diagnosis

You need a test that measures latency while the line is saturated, not just at idle. Waveform's bufferbloat test is the well-known option.

SpeedPulse is the one I built — free, no signup, no app, no cookies, everything runs client-side. One ~25-second run measures:

Download / upload / idle ping — the usual suspects
Jitter (RFC 3550-style mean difference between consecutive pings)
Bufferbloat — a ping train keeps running during the download and upload phases; the tool reports loaded latency − idle latency per direction and grades the worse one from A+ to F
Plain-English verdicts for 4K streaming, gaming, video calls and browsing, so you don't have to interpret raw numbers
An 8-CDN cross-check — after each test it pings 8 independent CDN edges (Cloudflare, jsDelivr, Fastly, GitHub, Google, AWS...). If the speed-test server is dramatically faster than the pack, your ISP may be prioritizing speed-test traffic — the classic reason "the test says I'm fine but everything feels slow"
CSV export and a local history chart, all client-side

Reading the grade

Grade	Extra latency under load
A+	< 5 ms
A	< 30 ms
B	< 60 ms
C	< 200 ms
D	< 400 ms
F	≥ 400 ms

If you score C or worse, you've found your problem.

Full disclosure: I built SpeedPulse. The grade scale is the same A+–F scheme Waveform and the bufferbloat.org community use, so results are comparable across tools — I'd rather share a standard than invent a flattering one.

The fixes that actually work

In order of effectiveness:

Enable SQM with fq_codel/CAKE on your router (trivial on OpenWrt; many stock firmwares ship a basic "QoS"). Smart queue management keeps buffers short so latency stays flat even at full load. This is the fix — A+ grades come from this.
Cap your speeds ~5–10% below your ISP rate in the SQM settings. Counter-intuitive but correct: queues then form inside your router, where SQM controls them, instead of inside the ISP's modem, where they don't.
Fix the upload direction first. Skinny upstreams bloat first — video calls die on upload saturation (cloud backup + call = slideshow). If you can only cap one side, cap upload.
Go wired for the machine that matters. Wi-Fi retransmissions and airtime contention add jitter no router setting can undo.
Check for speed-test favoritism. If only the test's server is fast while every other CDN is slow, the 8-CDN panel makes the mismatch visible — worth raising with your ISP.

For the nerds: how you measure this in a browser

No ICMP, no raw sockets. A browser test times HTTPS round trips with fetch(url, { mode: 'no-cors' }) and performance.now(). no-cors returns an opaque response — no body, no status — but the full network round trip (DNS, TCP, TLS, HTTP) completes, which is all timing needs. Jitter is the mean absolute difference between consecutive samples; bufferbloat is the median loaded latency minus the idle median, measured per direction, graded on the worse of the two.

Full methodology write-up, including the limitations we're honest about: How SpeedPulse measures jitter, bufferbloat and 8 CDN latencies.

Run the test on your line and drop your grade in the comments — happy to help interpret results: speedpulse.tech. Want the long-form bufferbloat explainer (router queue theory, CAKE vs fq_codel)? What is bufferbloat?

How to Create Custom Emojis for Discord and Slack for Free (No Design Skills)

FF — Fri, 30 Oct 2026 17:44:31 +0000

Every server admin and community manager hits the same wall eventually: you need a reaction emoji that simply doesn't exist. The inside joke lands, everyone types "we NEED that as an emoji," and then... nothing, because making custom emoji images sounds like a design job.

It isn't. Here are two free ways to make original emojis in under a minute, plus how to upload them to Discord and Slack.

Option 1: Fuse two emojis into a new one

The fastest route is an emoji "mixer" — it blends any two existing emojis into a brand-new one, no drawing required. EmojiMagic.io's Emoji Mixer does this instantly in the browser:

Pick emoji A (say 🐱)
Pick emoji B (say ☕)
Get the fused result — cat + coffee usually lands somewhere adorable

Every pair works, and you can regenerate until something clicks. No signup, no watermark, works on your phone too.

Option 2: Generate from a text prompt

When you need something no two emojis can produce ("a capybara wearing a hard hat"), use an AI emoji generator instead. On emojimagic.io you type the idea and get four styles back: Apple style, sticker, cute 3D, and flat. Free daily credits, no account needed.

Export a transparent PNG

Both routes give you a transparent PNG download — this matters, because a white box behind your emoji looks terrible on dark mode. The site handles transparency automatically; just hit download.

Upload to Discord

Open your server → Server Settings → Emoji
Click Upload Emoji
Pick your PNG, give it a name in lowercase (e.g. :catcoffee:)
Everyone in the server can now use it — including Nitro users, who can carry it to other servers

Discord resizes anything you throw at it, but square images around 128px look crispest.

Upload to Slack

Workspace name → Customize workspace → Emoji
Add custom emoji, name it, upload the PNG
It's instantly available to the whole workspace

Two quick tips

Test at small size. Your emoji renders at 22px in most chat clients. If the detail disappears, simplify.
Name for discoverability. :catcoffee: beats :image3: — people type names to find reactions.

That's the whole workflow: mix or generate, download the transparent PNG, upload. The emoji your community asked for doesn't need a designer — just a free browser tab.

How Emoji Semantic Search Works: Embeddings, Cosine Similarity, and 310k Vectors in Milliseconds

FF — Thu, 29 Oct 2026 16:56:52 +0000

Type "cozy morning coffee" into our emoji search and it returns breakfast, warm-light and calm-mood emoji combinations — none of which share a single keyword with the query. No synonym table, no hand-tagging. That swap from keyword lookup to meaning-based matching is powered by the most boring-sounding stack in modern ML: text embeddings plus cosine similarity, scanned over ~310,000 precomputed vectors. This is the engineering tour of how it works and what we learned building it.

Keyword tables don't generalize

Classic emoji search is a lookup table: "happy" maps to 😊, and if you type "joyful" you get nothing. Every synonym must be hand-tagged and every phrasing anticipated.

Embedding-based search flips the problem. Instead of matching strings, you match points in a high-dimensional space:

Every query is converted into a vector of numbers.
Every item in the catalog (for us, 310k+ emoji combinations) is also a vector, precomputed ahead of time.
"Similar" simply means "geometrically close" — and geometry generalizes to words the system has never seen.

The embedding pipeline, step by step

We use an open-source multilingual model (BGE-M3, 1024 dimensions). Every text — queries at runtime, the whole catalog offline — goes through the same four stages:

Tokenization — the model sees subword tokens, not words: "cozy morning coffee" → ["co", "##zy", "morning", "coffee"]. Rare words split into known pieces, so the model can embed text it has never seen.
Transformer encoding — each token flows through self-attention layers, exchanging information with every other token. "coffee" absorbs the fact that "morning" is next to it.
Mean pooling — one per-token vector each is averaged into a single 1024-dimension sentence vector.
L2 normalization — the vector is scaled to unit length, landing on the surface of a unit sphere.

That last step is load-bearing. Once every vector has length 1, comparing directions is all that's left.

The math that ranks everything

Cosine similarity measures the angle between two vectors, ignoring length — from −1 (opposite) through 0 (unrelated) to +1 (same direction):

cos(θ) = (q · c) / (|q| × |c|)

Because we normalized everything to unit length, the denominator is always 1 and the whole formula collapses to a plain dot product — one multiply-and-add per dimension. There's also a neat identity that falls out:

|q − c|² = 2 − 2 × cos(θ)

Smaller Euclidean distance and larger cosine similarity are the same statement for unit vectors. Whether your nearest-neighbor code sorts by dot product, cosine, or Euclidean distance, the ranking is identical.

Here's the entire mechanism in three dimensions, small enough to check by hand:

import numpy as np

query = np.array([0.80, 0.60, 0.00])   # "coffee"
combos = np.array([
    [0.70, 0.70, 0.14],                # "hot drink"
    [0.20, 0.30, 0.93],                # "birthday party"
])

cosine = combos @ query / (
    np.linalg.norm(combos, axis=1) * np.linalg.norm(query)
)
print(cosine)   # [0.98 0.34]  -> hot drink wins by a mile

Scale that from 3 dimensions to 1024, and from 2 candidates to 310,000, and you have semantic emoji search.

The lifecycle of one search

Offline, once: embed every catalog item and store its vector alongside its text. Vectors never change until the catalog does, so this cost is paid once — not per search.

Online, every search: embed the query with the same model, compute the dot product against the catalog, sort, return the top 100. Mixing models between index time and query time is the classic bug that quietly destroys result quality — two models produce two incompatible geometries.

Exact scan vs. ANN index

1024 dimensions × 310k vectors is ~318 million multiply-adds per query. That sounds scary and isn't: a tight vectorized loop finishes in well under a second, and an exact scan returns the provably best matches. Most systems switch to approximate nearest-neighbor (ANN) indexes — graph or cluster structures that trade a sliver of recall for an order-of-magnitude speedup — only past a few million vectors. Know your threshold before you reach for the fancy index.

Lessons we learned the hard way

Normalize your vectors at write time — cosine becomes a dot product and rankings stay consistent.
Use one model everywhere. Index and query vectors must share a geometry.
Precompute aggressively. Only the live query should pay the embedding cost.
Watch p99, not the average. Inference has cold starts; warm instances matter more than average speed.
Evaluate with real queries. Cosine scores don't feel like relevance — the only test that counts is whether humans like what comes back.

If you want to see it ranking live, every query on emojimagic.io/text-to-emoji runs exactly this pipeline — this post on our blog has the full worked example, and the site itself is free with no signup if you'd rather throw queries at it than read about them.

Why SVG Files from Figma Are 50–80% Dead Weight (and What to Strip Out)

FF — Tue, 27 Oct 2026 23:52:48 +0000

Every project has at least one multi-kilobyte SVG icon that could have been a few hundred bytes. Design tools write SVG for their convenience, not for the web — and the result is routinely 3–5× larger than it needs to be.

Here are the 7 things making your SVGs bigger than they should be.

1. Editor metadata

<metadata> blocks, rdf:RDF payloads, generator comments — Figma, Illustrator and Inkscape all pad files with data only they read. Browsers never render it.

2. Coordinate precision

74.98399992065430 renders identically to 74.984. Dropping to 2–3 decimals is the single biggest win on path-heavy artwork — often half the file.

3. Empty and nested groups

<g> wrappers that mirror the editor's layer panel but apply no transform or style.

4. Unused defs

Gradients, filters, masks and symbols defined but never referenced by any shape.

5. Editor IDs and attributes

id="Layer_1", data-name, xmlns:serif, style attributes with no visual effect.

6. Whitespace

Pretty-printed indentation and newlines — great for humans, dead weight for machines.

7. Embedded raster images (the trap)

A base64 PNG hiding inside <image> can be 95% of the file size, and no SVG optimizer can shrink it. If your "SVG" is mostly an embedded bitmap, the honest fix is either re-exporting the artwork as true vectors or shipping an optimized WebP/JPEG instead.

How much can you actually save?

Illustrator exports: 50–80%
Sketch: 40–70%
Figma: 30–60%
Hand-written SVGs: 5–15%

And an optimized SVG is plain text, so gzip/Brotli squeezes another 50–70% on the wire. The two stack — do both.

Automate it

If the same SVGs ship in an app, make optimization a compile step, exactly like minifying JavaScript:

Vite: vite-plugin-svgo
Webpack: svgo-loader
Any CI: npx svgo -f src/icons -o dist/icons

Keep editable originals in the design repo, let the pipeline emit optimized files, and nobody has to remember anything again.

The full guide — with a browser-based optimizer (SVGO running client-side, no upload) and a batch processor for whole icon sets — is at svgeditor.dev.

Favicon not showing? Here's how to fix it (10 causes)

FF — Tue, 27 Oct 2026 03:37:08 +0000

A missing or broken favicon is one of the most common questions on Stack Overflow — and the answer is almost always one of ten things. Work through this checklist top to bottom and you'll find it.

1. Browser caching (the #1 cause)

Browsers cache favicons extremely aggressively — far more than regular pages. Even after you've fixed the issue, the old (broken) icon can persist for days. Test in this order:

Hard refresh: Ctrl/Cmd + Shift + R
Incognito / private window — if it shows there, it's just your cache
Visit the file directly: open https://yourdomain.com/favicon.ico. If you see the image, the file is fine and it's a cache/link issue.

2. Wrong file path

The href in your <link> must point to where the file actually is. A leading slash (/favicon.ico) means site root.

<!-- ❌ wrong if file is in /assets/ -->
<link rel="icon" href="favicon.ico">

<!-- ✅ absolute path from site root -->
<link rel="icon" href="/favicon.ico">

<!-- ✅ or the real location -->
<link rel="icon" href="/assets/favicon.ico">

3. Missing `<link>` tag

Some browsers fall back to /favicon.ico automatically, but you should never rely on that. Always declare icons explicitly in <head>:

<link rel="icon" type="image/x-icon" href="/favicon.ico" />
<link rel="icon" type="image/png" sizes="32x32" href="/favicon-32x32.png" />
<link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png" />

4. Wrong MIME type

If your server serves .ico as image/png (or vice versa) some browsers will refuse to render it. .ico should be image/x-icon or image/vnd.microsoft.icon; PNG should be image/png.

5. File not deployed

Check that the file actually made it to production. Open the file URL in a new tab. A 404 means it's not there — rebuild and redeploy, and confirm your build pipeline copies favicons into the output directory.

6. Non-square source image

Favicons must be square. If your source image isn't 1:1, browsers may show a stretched or blank icon. Crop first.

7. Framework-specific gotchas

Next.js App Router: icon files go in app/ (not public/) for auto-detection.
Next.js Pages Router: files go in public/, tags go in pages/_document.tsx.
Webpack / Vite: make sure favicon.ico is in your public/ or static/ directory and referenced in your HTML template.

8. HTTPS / mixed content

If your site is HTTPS but the favicon is referenced over HTTP, browsers will block it as mixed content. Always use HTTPS URLs or relative paths.

9. Service worker caching an old version

If you have a PWA with a service worker, it may be serving a cached HTML that references an old favicon. Update and re-register the service worker.

10. The SVG favicon isn't supported

SVG favicons aren't supported in every browser (notably older Chrome on Android). Always provide a PNG/ICO fallback alongside an SVG.

Still stuck? Automate the diagnosis

Paste your URL into the Favicon Checker and it will tell you exactly which icons and tags are missing or broken — no guessing.

Need a clean favicon package to replace a broken one? Generate one free at Favicon.one — text, emoji, SVG or image, every size and format, all processed locally in your browser.

Making legacy regexes readable — without changing what they match

FF — Mon, 26 Oct 2026 19:08:05 +0000

A pattern like this ships in real projects every day:

^(?\[(?:[A-Za-z0-9_.-]+)\])|^(?[A-Za-z_][A-Za-z0-9_]*)\s*=\s*(?"(?:[^"\\]|\\.)*"|'(?:[^'\\]|\\.)*'|[^#\n]*)\s*(?:#.*)?$

An INI-line parser: a section header or a key–value pair, three quoting modes for the value, trailing comments. Perfectly readable — to the person who wrote it, today. Come back in three months, or hand it to a teammate, and the review comment is always the same: what does this actually match?

Formatting solves this the way it's solved for every other language. The same pattern, laid out by structure:

^
(? \[(?:[A-Za-z0-9_.-]+)\])
|
^ (? [A-Za-z_][A-Za-z0-9_]*)
\s* = \s*
(? "
   (?: [^"\\] | \\ . )*
"
| ' (?: [^'\\] | \\ . )* '
| [^#\n]*
)
\s* (?:\#.*)?
$

Two branches instead of one buried |; three quote styles you can point at; a comment-stripping tail that's obviously a tail. Same language — the difference is purely typographic, which is exactly the point.

That's the Format panel in RegexTester.dev: open the toolbar's Format button or the deep link regextester.dev/format.

Three modes

Pretty — free-spacing layout with indented groups and stacked alternation branches.

Annotated — the pretty layout plus AST-derived inline comments naming each construct as it appears (alternation, negative lookahead, named capture, …).

Minify — the reverse direction: comments and free-spacing whitespace stripped back down to a single dense line for shipping.

Why the layout can't change behavior

Whitespace only becomes syntax when the x / extended flag is on, so the formatter emits its output with the x flag enabled for your dialect — PCRE2, Python, Java and .NET all spell it slightly differently, and the panel handles that. What it must never do is insert whitespace inside a character class (where it would be literal), inside a quantifier, or escape sequences that carry meaning. The layout rule is simple: only touch whitespace and comments outside classes and escapes.

Verified, not assumed

"Trust me, the layout is safe" is not a review argument, so the panel shows its work at the bottom of every run:

Round-trip proof — the formatter re-minifies its own output and compares it, byte for byte, with the escaped input. If the only difference is whitespace and comments outside classes — exactly what x mode ignores — you get a green Round-trip exact line.

Live behavior check — both forms (original, and formatted with x enabled) are executed against your current test string on the real engine for your flavor, and every match is compared: text, position, and each capture group's content. Only identical match lists earn the green Behavior verified line.

If either check fails, the line turns red and points you at the parse errors above. Formatting a regex you can't test is guesswork; here it's a proof.

Try it: open regextester.dev/format, paste your gnarliest pattern, and read it in one click — then let the round-trip proof tell you the formatter didn't change a thing.

Full write-up: regextester.dev/blog/regex-formatter. Free, no signup, everything runs locally in your browser.

One regex, seven engines: catch portability bugs before you ship

FF — Mon, 26 Oct 2026 18:46:32 +0000

"Regular expressions" is not one language. It's a family of dialects that look almost identical and disagree in exactly the places you don't look until production breaks:

\w is Unicode-aware by default in Python 3, PCRE2 and .NET — but ASCII-only in JavaScript.
Lookbehind must be fixed-width in PCRE2; .NET accepts variable width; RE2-based engines reject it entirely.
Possessive quantifiers, atomic groups, \K, named-group syntax (?<name>…) vs (?P<name>…) — every one of these is a line in some engine's grammar and an error (or a silent behavior change) in another's.

The standard workflow makes this invisible. You test the pattern in one tester with one flavor selected, it works, you paste it into another language — and the failure shows up far away from the regex: a log line that never matches, a validation that rejects valid input, an import script that silently skips rows.

A flavor selector doesn't solve this either — you'd still have to try every flavor by hand and compare results from memory. What you need is every engine answering at once, side by side, on the same input. That's what the Compat button in RegexTester.dev does.

Seven engine paths, one click

Type your pattern and a representative test string, then hit the Compat button in the toolbar — or open the deep link regextester.dev/compat directly.

One pattern runs through seven execution paths in parallel:

PCRE2 — real engine, compiled to WebAssembly
Go (regexp) — real engine, WebAssembly
Rust (regex) — real engine, WebAssembly
JavaScript — the browser's native RegExp
.NET — a real interpreter for System.Text.RegularExpressions syntax
Python — parser plus normalize-and-run path
Java — parser plus normalize-and-run path

Not simulated: the WASM paths are the actual engine builds, so a rejection or a match here is what the real engine does.

The three ways a port fails

Every engine reports one of three outcomes, and the panel clusters engines by their exact match sets:

Rejection — the pattern doesn't even compile. RE2's rejection of lookbehind, or a possessive quantifier a dialect has never heard of, is a build error you want to know about before the port.

Silent divergence — the worst one. The pattern compiles everywhere and simply disagrees. Classic example: \w+ against Unicode input gives JS and Java four matches where the other five engines give two, because \w is ASCII-only there. No error, no warning — different data.

Full agreement — all seven engines return identical match sets (text, position, groups), and the panel says so explicitly.

Exporting the verdict

The verdict copy is written to be pasted: one click copies a Markdown report listing every engine, its outcome, and the divergent match sets — drop it into a PR when you're porting a pattern between services written in different languages.

Try it: open regextester.dev/compat, paste the pattern you're about to port, and see all seven verdicts in a couple of seconds.

Full write-up: regextester.dev/blog/regex-compatibility-checker. Free, no signup, everything runs locally in your browser.

Buying the dip without catching the knife: a 2-line crypto pullback rule, walk-forward validated across 40 coins

FF — Sun, 25 Oct 2026 14:38:27 +0000

"Buy the dip" is the most repeated advice in crypto — and following it blindly is one of the most reliable ways to lose money. A 6% pullback inside a bull market and a 6% bleed on the way to zero print the same red candle. One is an opportunity; the other is a knife.

We built Trend Dip, a pullback strategy that only buys reclaims inside an uptrend, validated it walk-forward across 40 coins on 4-hour bars, and shipped it as a free preset in our in-browser backtester — no signup, the whole engine is WASM running locally in your browser, so you can re-run every number in this post on any coin in about a second.

The rule (two lines)

ENTRY:CROSS(C,LOWER) && C>TRENDMA    // buy the reclaim of the lower Bollinger band, in an uptrend
EXIT:CROSS(C,MID)                    // sell at the mid band

…where LOWER = MA(C,20) − 2·STD(C,20), MID = MA(C,20), and TRENDMA = MA(C,100). Each piece earns its place:

C > MA100 — the trend filter. This is what separates a dip from a knife. Below the 100-bar average, the same band reclaim is ignored entirely.
CROSS(C, LOWER) — buy the reclaim, not the touch. The entry fires on the bar whose close comes back above the band. The market has already rejected the low once before you spend a cent. This single change moved the OOS win rate by roughly ten points versus buying the first touch.
Exit at the mid band. The thesis is snap-back to the 20-bar mean, so that's where the trade ends. We tried smarter exits — trailing lows, trend-break exits — every one performed worse out of sample.
No stop in the formula. Deliberate: 4h crypto charts routinely flush 5% below the band and revert by the next close, and a stop converts those wicks into realized losses. Adding a 10–20% protective stop changed the results almost imperceptibly (stops almost never fired). The backtester still gives you an optional stop field if you want a hard tail cap.

How we validated it

Four rules, all of which matter:

Not one chart — forty. BTC, ETH, SOL, BNB, XRP, DOGE, AVAX, DOT and 32 more majors with long histories. A rule that only works on a cherry-picked chart is a screenshot, not an edge.
Walk-forward, not full-history. Each coin's ~500 days of 4h bars split 70/30: the first 70% is where parameters would effectively have been chosen; the final 30% is scored blind as one continuous out-of-sample segment. All headline numbers below are OOS only.
Realistic fills. Signals confirm at bar close, fill at the next bar's open — no lookahead — with 0.10% taker fee + 0.05% slippage per side (~0.3% round trip). The same engine and simulator that power the public backtest page ran every test.
Benchmarks. The identical harness scored the nine other strategies on the site on the same data.

The numbers

Out-of-sample metric (40 coins, 4h, 70/30)	Result
Win rate, all held-out trades	73.6% (174 trades)
Win rate, in-sample (for contrast)	62.9% (267 trades)
Coins profitable OOS	26 / 40
Coins beating buy & hold OOS	24 / 40
Coins winning ≥50% of held-out trades	33 / 35 with ≥3 trades
Median per-coin max drawdown	−6.1%
Worst / median / best held-out trade	−16.7% / +1.2% / +34.8%
Average holding time	12 bars ≈ 2 days
Win rate at 2× fees	69.5%
BTC / ETH / SOL win rate	83% / 75% / 100%

Two details deserve a second look. First, the OOS win rate is higher than the in-sample one — overfit strategies show the opposite signature: brilliant in the tuning window, collapsing the moment data is unfamiliar. Second, the edge survives fees at two to three times what a normal spot account pays.

Trying hard to break it

Six consecutive time slices scored separately: win rates 71%, 56%, 62%, 55%, 69%, 75% — every window above 50%. A regime-dependent fluke does not do that.
Parameter plateau. Defaults (20 bars, 2σ, MA100) sit in the middle of a plateau: 1.8σ–2.5σ all won 70–77%, neighbouring trend filters (50–200) all stayed positive. If performance collapses when you nudge a parameter 10%, you found noise.
Split-date sensitivity. Moving the walk-forward cut across 50/30 → 90/10 changed the aggregate win rate only between 55% and 66%.
Exit shoot-outs. Adding a 10-bar-low emergency exit or a trend-break exit lowered the OOS win rate (61.5% and 51.0%). The boring mid-band exit won — stops were selling into the very wicks the strategy profits from reverting.
Benchmarks: the best of the nine existing strategies managed a 51% OOS win rate on the same data.

Where it loses — read this part

73.6% win rate is not a money printer. The median winner is small (+1.2%) because the target — the mid band — is close. The profile is many small wins, occasional runners, occasional give-backs. The worst held-out trade lost 16.7%.
No formula stop means tail exposure exists. Historically the MA100 filter and mid-band exit capped the damage, but a coin that breaks down mid-trade holds until it recovers to the mid band. If that worries you, set the optional stop in the backtester and accept slightly worse expected numbers for a hard floor.
The held-out window is one market regime (~5 months per coin, dips inside an uptrend). In a full bear market the MA100 filter will simply keep the strategy flat for long stretches — designed behavior, not a bonus.
Survivorship bias is real — today's top-40 list excludes the coins that died.

Run it across the whole market

One coin's backtest is an anecdote. The scanner page runs the identical formula across a whole universe in one pass — each coin split walk-forward, ranked by out-of-sample Sharpe:

Under the hood (the dev part)

The whole thing — formula parser, indicator engine, backtest simulator, walk-forward scanner — is a Rust→WASM module evaluated entirely in your browser on real exchange candles. The strategy DSL is a tiny TDX-style language (ENTRY:CROSS(C,LOWER) && C>TRENDMA;), so every rule on the site is user-editable text, and the simulator fills at the next bar's open with configurable fees and slippage. Nothing you type is uploaded anywhere.

Re-run this exact strategy on any pair: backtest page
Scan the whole universe: scanner page
Full write-up with more stress tests: original article (canonical URL of this post — it's the same article, cross-posted)

Disclaimer: everything above is a historical backtest, not a promise. Backtested win rates decay in live trading. Not financial advice — crypto is volatile and you can lose your entire investment.

Testing automata-theory exercises in the browser: a regex flavor for CS coursework

FF — Sun, 04 Oct 2026 12:19:22 +0000

If you've ever taught or taken a formal languages course, you know the workflow: the exercise says write a regular expression for all strings over {a,b} containing an even number of a's, you write (b|ab)* on paper... and then you have no way to check it.

Programming regex flavors can't validate it for you — they're full of conveniences the formal dialect doesn't have: character classes, quantifier shorthands, anchors. What you want is a checker that speaks the textbook dialect: union ∪ or |, concatenation, Kleene star *, plus +, parentheses. Nothing more.

RegexTester.dev now ships a Formal Automata Theory flavor exactly for this.

What it accepts

Symbols from your chosen alphabet (typically a, b, or 0, 1)
Union: ∪ or |
Concatenation: juxtaposition or .
Kleene star: *, and one-or-more: +
Grouping with parentheses

Everything else — \d, [a-z], lookahead, backreferences — is rejected with an explanation, because the point is to exercise exactly the constructs the course covers.

Instant feedback

Type the expression and test strings in, and you immediately see which strings match and which don't — so you can iterate on the exercise instead of waiting for a grader.

The flavor runs on the same engine infrastructure as the other eight dialects (PCRE2, RE2, .NET, Python, Java, Go, Rust, JavaScript), so the matching behavior is well-defined and consistent.

Why a browser tool for coursework?

Because the feedback loop is everything when learning. The gap between writing (b|ab)* on paper and knowing whether it's right is where most of the confusion in a formal languages course lives. Close that gap to seconds and students experiment their way to understanding: they can see that (b|ab)* matches babb but not abab, and fix their mental model immediately.

It also works the other direction: instructors can build exercise sets with permalinks — every regex and test string combination in the tester has a shareable URL, so "check your answer against this" becomes a link.

Try it: open regextester.dev, pick the Formal Automata flavor from the selector, and test that even-number-of-a's exercise.

Full write-up: regextester.dev/blog/Formal-automata-theory-flavor. Free, no signup — built for students and educators.

Benchmarking regex patterns properly: P95/P99, equivalence checks, real engines

FF — Sun, 04 Oct 2026 12:08:30 +0000

Every developer has been here: two regex patterns that both work. One is a dense one-liner, the other reads like prose. Which do you ship?

"Use the simpler one" is a fine heuristic until the pattern runs over a 50 MB log file or every request in a hot path. Then you want data. The problem is that regex benchmarks done casually lie to you three ways:

The engine problem — your JS benchmark measures JavaScript's RegExp, but the pattern ships to a PCRE2-based backend. Different engine, different behavior, different speed.
The clock problem — a fast regex finishes in microseconds, far below performance.now() resolution. You're measuring timer noise.
The equivalence problem — the faster pattern is faster because it matches less. You optimized a bug.

RegexTester.dev's built-in Benchmark Suite was designed against those three traps. Here's how it works.

Real engines, identical conditions

Up to 5 alternative patterns run sequentially under identical input, flags and engine — the same engines the tester itself uses: PCRE2 and RE2 as WebAssembly in a dedicated worker, .NET's System.Text.RegularExpressions as a real interpreter, and native JS RegExp (including the normalize-to-JS path used for Python, Java and other flavors).

Sub-clock-precision timing

Each sample times K consecutive executions and records time ÷ K, with K auto-calibrated so every sample spans between 0.35 ms and 12 ms. This batch amplification resolves sub-microsecond patterns with sub-nanosecond effective resolution — far below browser clock precision.

You get median, mean, P95, P99, ops/sec and the relative speedup of the fastest pattern, with a ±RSE column that tells you when a number is too noisy to trust.

Equivalence checking

Speed means nothing if the output changed. The suite records each pattern's match count on the benchmark input and raises an "Output differs" warning when counts diverge — a pattern that's faster because it matches less gets flagged before you ship it.

Reading the charts

Latency histograms and timelines make the distribution shape visible: a tight spike means stable performance; a long tail means some inputs hit pathological backtracking even when the median looks fine.

Export

Results export as Markdown (for PRs and docs) or JSON (for your own tooling), with the environment (UA, cores, timestamp) baked in so numbers stay comparable.

Try it: open regextester.dev/bench, paste two alternatives, press Run. Sixty seconds later you'll know which one to ship — and whether they really do the same thing.

Full write-up: regextester.dev/blog/regex-benchmark-suite. Free, no signup, everything runs locally.

I built a regex debugger that shows every backtrack (flame graph included)

FF — Sun, 04 Oct 2026 12:08:29 +0000

Testers tell you what a regex matches. A debugger tells you why — and where it burns time.

Every regex tester shows the same three things: matches, groups, and an explanation of the pattern. That covers the happy path. It stops helping the moment a regex is almost right — matching one tag too many, missing a case you can't reproduce, or taking 400 ms on an input that looks identical to the one that took 4.

The failure modes of a backtracking engine are invisible from the outside. A pattern doesn't slowly get slower — it tries a prefix, gives characters back, retries the inner quantifier at a different split, fails, and repeats that a few thousand times. The match result looks the same as the fast version's. Only the trace of what the engine actually did tells them apart.

So I built a full debugger into RegexTester.dev. Here's what it does.

One click from the tester

The entry point is the Debug button on the tester toolbar. Hit it, and the debugger opens with the trace already recorded. The demo pattern <([a-z]+)([^<]+)*(?:>(.*)<\/\1>|\s+/>) against <div>Content</div> generates 7,530 execution steps for 18 characters of input. That gap between "looks simple" and "7,530 steps" is exactly what the debugger makes visible.

The execution graph

The graph is a flame-chart of the engine's work. Each bar is one node attempt — a TRY that ended in OK (green), FAIL (red), or was undone by backtracking (thin blue give-back marks). Rows are stack depth; vertical bands separate match attempts.

It behaves like a proper profiler view: scroll-wheel zoom, drag to pan, double-click to zoom to a block, click any block to jump there — the amber marker follows, and every other panel updates in lockstep. A healthy trace reads as a calm staircase. A sick one shows the signature immediately: one region of the graph orders of magnitude wider than everything else, striped with red and blue.

Hot spots: where the steps go

The Hot spots table is the profiler summary: every node of your pattern, ranked, with its operation count, give-backs, failures, and share of total steps.

This is the same workflow you'd use on slow code: profile, find the hot function, fix, re-profile. It just didn't exist for regular expressions in a browser before.

From diagnosis to fix in two clicks

Diagnosis without a fix is only half a tool. The Suggestions panel combines static analysis with trace statistics to propose concrete rewrites — dialect-aware, so a PCRE2 pattern gets atomic groups and possessive quantifiers while a JavaScript pattern gets the constructs ES2025 actually supports.

The classic case: (a+)+b on aaaaaaaaaaX — the textbook catastrophic backtracking example. The debugger names the disease and prescribes the cure:

Two things make this safe to trust:

Equivalence checking — both patterns run against the real engine for your dialect on your input; only identical match lists earn the "same matches on this input" badge. A faster regex that matches less is a bug, not an optimization.
Apply writes the rewrite into the tester and re-traces immediately: same input, Healthy verdict, 404 steps instead of 50,000+.

A tracer kept honest

The trace comes from an instrumented backtracking engine — a continuation-passing matcher written for this purpose, speaking the semantics of nine flavor dialects. Every trace is cross-checked against the real thing: the match outcome is compared with the actual engine for the selected flavor (native RegExp, or PCRE2/.NET compiled to WebAssembly), and a "trace verified" badge only appears when they agree.

Try it: regextester.dev/debug — or read the full write-up at regextester.dev/blog/regex-debugger. Free, no signup, everything runs locally.