DEV Community: Mahmud Hasan

Two 9.2-Rated Flaws in PHP. The Patch Lands Today at 14:00 UTC — Attackers Got a Day’s Head Start.

Mahmud Hasan — Wed, 21 Oct 2026 08:32:25 +0000

Yesterday afternoon, an anonymous Hacker News post claimed — with no evidence at all, the poster admitted — that PHP had two CVSS-10 remote code execution flaws affecting everything from PHP 5 onward. Within hours, security firm watchTowr confirmed the flaws were real. By evening, PHP had pulled its release forward a full day. The patch ships today, October 21, at 14:00 UTC. This is the playbook for the hours before it lands — and the days after.

What PHP actually announced (and what it didn't)

The official notice on php.net, dated October 20, is nine sentences long. The PHP security team gave "advance notice of an upcoming security release" scheduled for Wednesday, October 21, 2026 at 14:00 UTC. It addresses two critical vulnerabilities, both rated CVSS v4.0 9.2. "All PHP users are encouraged to prepare now so they can upgrade as soon as the release is available."

Then the sentence that matters most: "We reserve the right to release earlier should details of either vulnerability become public, or should evidence of active exploitation appear in the wild."

What the notice does not contain: CVE numbers, affected versions, or fixed version numbers. "Full details, affected versions, and the fixed versions will be published with the release." That is normal for an embargoed disclosure. What is not normal is the next part.

How the embargo broke before the release

At ~15:20 UTC on October 20, a now-deleted Hacker News post (user "petecooper") cited a "reliable source" claiming two CVSS-10 PHP RCE flaws affecting PHP 5 onward, with disclosure planned for October 22. The poster's own evidence: "source: trust me, bro."

Then the story changed. watchTowr confirmed on X: "We were all supposed to wait until Thursday at 11am ET. Information has leaked wrt zero-day embargoed RCE vulns in PHP. We can confirm that they're real." Their post had a typo in the CVE IDs — "CVE-2926-109618/619" — which tells you how fast this moved. The corrected IDs: CVE-2026-109618 and CVE-2026-109619.

watchTowr CEO Benjamin Harris told BleepingComputer the flaws were leaked "in the last hour," had been embargoed for a Thursday 11 AM Eastern release, and were remote code execution flaws. The company believes it reproduced CVE-2026-109618 in its own lab — but is withholding technical findings until the patches ship. Crucially: watchTowr reported no exploitation in the wild at the time.

What we know about the flaws — and the evidence boundary

PHP has confirmed the severity and the schedule. It has confirmed nothing else. Everything below is third-party attribution, held at that distance:

The CVE IDs are watchTowr-attributed, not official. PHP's notice names no CVEs. Both entries were still "reserved" on NVD with no description as of this morning.
9.2 vs 10.0. PHP rates the flaws CVSS v4.0 9.2. The leak and watchTowr say "CVSS 10.0" without naming which scoring version. Treat 9.2 as the number and the 10 as the rumor.
"PHP 5 onward" is unconfirmed. That scope came from the anonymous HN post, repeated by watchTowr's CEO — but watchTowr's own FAQ says the affected range "has not been confirmed by an official vendor advisory." Researcher Florian Roth notes the flaw is in PHP core and that only the PHP 8 branches can receive patches.
The mechanism is third-party speculation. External research describes an unauthenticated RCE path in PHP's multipart upload processing; other coverage points at session upload-progress handling, with one suggested interim mitigation: session.upload_progress.enabled=Off. But as DeXpose flags: "PHP has confirmed the severity and release schedule, not the full technical mechanism."
An exploit tool is already being named. Sansec reported a screenshot of a tool called "PHP2Shell," credited to Calif.IO, circulating with the leak; its banner claims coverage from PHP 5.4.0 onward. Sansec predicts mass attacks could begin within roughly 15 minutes of the release. The "PHP2Shell" nickname is community shorthand, not PHP's.

On scale: only 8.2, 8.3, 8.4, and 8.5 can receive an upstream fix (8.1 went EOL December 2025; 8.2's own security support ends this December). Mallory counted roughly 884,000 internet-facing hosts whose banners reported PHP 8.1 or older to Shodan on October 20 — 59% of versioned hosts — plus ~740,000 more that reported PHP with no version. Those are banner reports, not confirmed vulnerable systems, but they show how much of the web runs PHP it can't patch.

What to do before 14:00 UTC, in the order that matters

The patch lands today at 14:00 UTC — 10 AM Eastern, 4 PM Central European, 8 PM in Dhaka. The window between now and then is for preparation, not panic:

1. Find every PHP on your network. Not just the app servers: cPanel/Plesk builds, containers, appliances, CI runners, dev stacks, the old WordPress site on the shared host you forgot about. php -v everywhere. Most teams discover at least one PHP they didn't know was running.

2. Know how your fix arrives. Distro packages (check whether your distro backports security fixes), panel builds (cPanel/Plesk ship their own PHP — their timeline is the one that matters), source builds (have your exact configure line ready), or managed hosting (ask your host now; several have already posted status pages saying they'll handle it).

3. Snapshot and back up first. PHP patch releases are usually safe, but extensions and pinned builds can break in odd ways. A snapshot is cheaper than a rollback at midnight.

4. Patch internet-facing systems first, in order of exposure. Public web servers, then internal apps, then everything else. Wordfence's threat team says it will assess firewall coverage as soon as the advisory drops.

5. If you're on 5.x, 7.x, or 8.1: no patch is coming for you. CERT-EU's guidance is blunt: isolate internet-facing apps on EOL PHP from public networks. If upgrading today is impossible, a WAF and network isolation are your only defenses.

6. Watch for the weaponization. Look for php-fpm, php-cgi, or Apache worker processes spawning shells, download tools, or interpreters. The precedent: when PHP shipped an out-of-cycle fix for CVE-2024-4577 (the Windows CGI RCE) in June 2024, Akamai's honeypots caught exploit attempts within 24 hours of disclosure. Sansec predicts ~15 minutes this time, because attackers already know the patch is coming today.

Why the next 48 hours matter

Is this fear-mongering? PHP says 9.2, watchTowr reports no exploitation in the wild, and the "CVSS 10 / PHP 5 onward" claims come from a leak whose poster admitted having no evidence.

No — because the leak inverted the normal disclosure timeline. Usually defenders get the patch and the details at the same moment attackers do. Here, attackers got a day's head start of awareness: everyone now knows a PHP core RCE patch drops at 14:00 UTC today, and tooling is already being named in screenshots. The June 2024 precedent says the gap between "patch available" and "exploit circulating" closes within a day. Preparation today costs almost nothing. A web shell tomorrow costs everything.

One honest caveat: this post publishes before the release, so the fixed versions, affected-versions matrix, and technical details all arrive at 14:00 UTC. Check the official advisory against everything above — the advisory wins, always.

The takeaway: 14:00 UTC today. Know where PHP runs in your stack, know how your fix arrives, snapshot, and patch the internet-facing systems first. The embargo already broke once — don't let your own patching be the second thing that runs late.

References

How to Implement Rate Limiting for an API: In the Order That Actually Matters

Mahmud Hasan — Wed, 21 Oct 2026 02:31:32 +0000

The request that takes your API down rarely comes from a hacker. It comes from a legitimate customer with a retry loop, or a scraper that found your endpoint. Rate limiting is how you stay up — but most tutorials teach the happy path and skip the ways production limiters fail. This is the order that works: pick the algorithm for your bottleneck, identify clients honestly, tier by endpoint cost, return useful 429s, and plan for the limiter's own failure.

First, pick the algorithm for your bottleneck

Four serious algorithms for four different bottlenecks — pick the one that matches yours.

Fixed window is the simplest: one counter per client per window, reset at the window's end. Cheap and fine for internal APIs — with a known leak at the window edge: 100 requests at 12:00:59 plus 100 at 12:01:00 is 200 requests in two seconds, fully "compliant."

Sliding window log records every request timestamp and counts what falls inside the trailing window. Perfect accuracy, no edge leak — at the price of one stored entry per request per client. Reserve it for logins, MFA codes, password resets.

Token bucket holds up to N tokens, refilled at a fixed rate; each request costs a token, expensive endpoints cost ten. It absorbs bursts up to the bucket's capacity while enforcing the average rate — the most deployed algorithm in production. AWS API Gateway throttles with token buckets (10,000 requests/second steady-state plus a 5,000-request burst); Stripe's engineering writeup describes a per-user token bucket with burst allowance above the cap for flash sales.

Leaky bucket is the mirror image: requests queue and drain at a constant rate, so output is perfectly smooth. Choose it when your downstream can't absorb a burst — payment rails, legacy mainframes, anything where "eventually, in order" beats "fast."

Choose by what sits behind your API: if it can't absorb a burst, use a leaky bucket; if you're rate-limiting logins, use a sliding window log; otherwise use a token bucket. Fixed windows are for internal tools, not the public internet.

Key the limiter on the right identity

The algorithm is the part everyone writes about. The identity is the part that breaks.

Key by user ID when authenticated, IP when not. In Laravel's named limiters:

use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\RateLimiter;

RateLimiter::for('api', function (Request $request) {
    return Limit::perMinute(60)->by($request->user()?->id ?: $request->ip());
});

Two traps in that last line. First, behind a load balancer or CDN, $request->ip() may resolve to the proxy's address — one shared budget for everyone. If a CDN terminates the connection, key on its signed header (Cloudflare's CF-Connecting-IP). Second, the naive fix is trusting X-Forwarded-For, and that header is client-controlled: one curl flag hands an attacker a fresh budget per request. Only trust forwarded headers from proxies you control — in Laravel, configure trusted proxies and ignore the header on direct connections.

And the mistake that silently starves paying users: one global bucket for everything. Without ->by(), one noisy scraper throttles your whole user base. Segment per user, and give anonymous traffic a smaller bucket than authenticated traffic. (On IPv6, group by subnet rather than keying on the full /128 — one user can rotate through an enormous address space; Traefik documents an ipv6Subnet option for exactly this.)

Tier by endpoint cost, not just by user

Sixty requests per minute is reasonable for fetching a profile; catastrophic for an endpoint that sends an SMS. Price rate limits in the currency of your infrastructure: expensive endpoints get stricter budgets, or cost more tokens in the same bucket.

Stripe documents it explicitly: a global 100 requests/second in live mode, 25 per individual endpoint, plus resource-specific caps. When you hit one, Stripe's 429 tells you which tier fired via the Stripe-Rate-Limited-Reason header. Copy that: the error names the rule that fired.

Five hundred reads a minute, three exports a minute.

The cheapest version is multiple limits per route — Laravel supports it out of the box:

RateLimiter::for('reports', function (Request $request) {
    return [
        Limit::perMinute(500)->by('minute:'.$request->user()->id),
        Limit::perMinute(3)->by('exports:'.$request->user()->id),
    ];
});

Five hundred reads a minute, three exports a minute — price the limit in the cost of the endpoint.

Return a 429 that helps instead of hurting

A rate limiter that returns a bare 429 with no context is a locked door with no sign — the client retries immediately, in a loop, making your load problem worse. Four headers and a paragraph of documentation fix it.

Status code is 429 Too Many Requests (RFC 6585). Pair it with Retry-After, in seconds: Retry-After: 12. Subtlety from Cloudflare's feedback to the IETF: under token or leaky bucket schemes, the next request may be permitted before the window fully resets — so don't blindly echo the window reset.

For limit metadata, pick one of two conventions. The de-facto standard is X-RateLimit-Limit / X-RateLimit-Remaining / X-RateLimit-Reset, used by GitHub and Laravel's throttle middleware. The newer convention is the IETF's RateLimit-Policy / RateLimit fields — but as of October 2026 it's still a draft, not an RFC. What breaks developers is mixing conventions or shipping none. Document yours with an example 429 response.

The four ways production limiters actually die

Run your implementation through this list before you ship it.

1. Retry storms. The clients you rate-limited retry immediately, all at once, synchronized — the thundering herd — and one 429 wave becomes a self-inflicted DDoS. Publish Retry-After, but more importantly make your clients behave: exponential backoff with jitter, which Stripe's docs recommend for exactly this reason.

2. Redis is down and nobody decided what happens next. Your limiter lives in Redis, and Redis will eventually be unreachable. Fail open for checkout: blocking all purchases over a cache hiccup is a business disaster. Fail closed for login and OTP endpoints: an attacker would love a password-guessing window with no limiter. Decide per route and test it by killing Redis in staging.

3. You forgot concurrency exists. Rate limits count requests per window, not simultaneous requests. Stripe maintains a separate global concurrency limit — 50 in-progress requests by default in live mode — and its 429s distinguish global-concurrency from global-rate. If your endpoints are slow, cap concurrency too.

4. Your check-and-record isn't atomic. A fixed-window check that INCRs, reads the count, then decides in application code races when two gateway nodes hit the last slot at the same instant. Run the whole thing as a Lua script — Redis executes Lua atomically — or document that your limit is approximate.

What to do on Monday

Wire up a limiter you don't have to babysit. Laravel named limiter + throttle: middleware, express-rate-limit, or Flask-Limiter — backed by Redis in production.
Key honestly. User ID when authenticated, IP when not, from a proxy chain you control. IPv6 goes in subnet buckets.
Tier by cost. Generous for reads, strict for login, signup, exports, webhooks. Let the 429 name the tier that fired.
Ship useful 429s. 429 + Retry-After in seconds + one consistent header set, documented.
Test the failure modes. Kill Redis in staging; confirm checkout stays up while login stays guarded. Hammer staging and watch whether clients back off or stampede.

References

Laravel 12.x docs — rate limiting (named limiters, Redis throttle, response-based limits): https://laravel.com/index.php/framework/docs/12.x/routing
Stripe docs — rate limits (100 rps live, 25 rps per endpoint, backoff guidance): https://docs.stripe.com/rate-limits
Stripe blog — Scaling your API with rate limiters: https://stripe.com/en-fi/blog/rate-limiters
GitHub docs — rate limits for the REST API: https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api
AWS docs — API Gateway request throttling (token bucket): https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html
Cloudflare docs — WAF rate limiting rules: https://developers.cloudflare.com/waf/account/rate-limiting-rulesets/create-api/
IETF draft — RateLimit header fields for HTTP (draft-ietf-httpapi-ratelimit-headers): https://datatracker.ietf.org/doc/draft-ietf-httpapi-ratelimit-headers/
SharpByte — designing a rate limiter: https://www.sharpbyte.dev/system-design/design-rate-limiter
CodingPancake — distributed rate limiting at scale: https://www.codingpancake.com/2026/09/distributed-rate-limiting-at-scale.html
Traefik docs — rate limit middleware (IPv6 subnet grouping): https://doc.traefik.io/traefik-hub/api-gateway/reference/routing/http/middlewares/ref-rate-limit

How to Do a Good Code Review: Small Diffs, Fast Reviews

Mahmud Hasan — Tue, 20 Oct 2026 22:57:11 +0000

Most code reviews are theater. A thousand-line pull request lands on Friday, sits untouched for four days, and merges on Monday with two approvals from people who skimmed it. Nobody found a bug, nobody learned anything — the diff was too big to understand, so the approval was a ritual, not a review. Google's engineering docs and the peer-review research agree on the uncomfortable point: reviews only work when the diff is small and the feedback is fast. Everything else is technique.

I've spent the week reading Google's published review docs, SmartBear's peer-review benchmarks, and the best practitioner write-ups I could find. The advice below is what survived.

1. Know what the review is actually for

A good review does three things: it catches the mistakes the author missed, it builds a shared understanding of what changed and why, and it keeps the codebase's abstractions consistent — pointing out that a helper already exists elsewhere so the author doesn't reinvent it. That's it. One practitioner puts it even more bluntly: the goal should be creating understanding, never forcing your colleague to justify themselves.

Notice what's not on the list: perfection. Google's standard — approve once a change definitely improves code health, even if it isn't perfect. Perfect code doesn't exist; "better" is enough. If more feedback would make significant improvements, ask. Otherwise, approve and move on.

2. Keep the diff small — the only rule with numbers

This is the most quantified piece of the whole discipline, and almost nobody follows it. SmartBear's peer-review guidance recommends reviewing fewer than 400 lines of code at a time, inspecting under 500 lines per hour, and limiting concentrated review sessions to 60 minutes. Their reported benchmark: a 200–400 line review conducted over 60–90 minutes can yield 70–90% defect discovery. That's not a guarantee for every codebase — it's a directional benchmark — but the shape of it is the point: small reviews find things; huge ones don't.

The reviewer can't fix a 1,000-line diff — the author owns reviewability. Google splits work into small change lists: ten 100-line CLs beat one 1,000-line CL, every time. If a change is too big to understand in one pass, split it by independently testable behavior before asking for review.

3. Review fast — slow reviews rot everything

Google's maximum for a review is one business day. Why the urgency? Three compounding costs. First, the review becomes a blocker: the author moves on, new work piles up, and days become weeks. Second, developers get frustrated — and frustrated developers submit worse code and do less of the unglamorous cleanup work ("if my reviewer won't reply for four days, what's the point?"). Third, code quality degrades precisely where you thought reviews were protecting it.

The real performance metric isn't comment count — it's time-to-first-response. If your team measures one review metric, make it that one. And if you spot an architectural problem early, say so immediately, before finishing the rest: Google tells reviewers to send severe findings the moment they land. The author may already be building on top of what you're about to reject.

4. Ask questions, don't deliver verdicts

Write questions, not pronouncements. "Is there a reason this migration isn't reversible?" lands differently than "make this reversible" — and the question often wins, because suboptimal solutions are usually carefully chosen compromises the reviewer can't see. Don't understand a section? Ask what it does. Disagree? Ask why, instead of criticizing. See a likely mistake? Ask whether section X might lead to problem Y.

The one test that tells you whether you're doing this honestly: if the question you're about to write has only one possible answer, it's not a question — it's a demand in disguise. Say what you mean instead. Reserve the direct version for the rare case where you're certain a solution must not be merged as written.

This is also the answer to the question every junior dev asks: am I even allowed to review senior engineers' code? Yes — because asking comprehension questions is reviewing. A less experienced reviewer finds fewer subtle defects but more than makes up for it by forcing the author to explain and re-examine their own decisions. If you're new and lost, ask the author to walk you through the change — that's not a weak review, it's the review working as designed.

5. Label your comments so the author knows what's blocking

The biggest cause of review friction isn't disagreement — it's ambiguity. Fix it with labels. Four is enough: Blocking (concrete defect, security issue, broken requirement — nothing merges until fixed), Suggestion (a better approach exists; the author picks the fix), Question (you need context before judging), and Nit (optional polish that must not delay the merge).

Google's version is simpler — prefix non-essential polish with "Nit:" — and the rule behind it is absolute: never block a PR on personal style preference, and never mix style changes into a real change. Formatters exist; your taste is not a standard. Critique the code and its consequences, not the person: "this condition permits duplicate writes" is reviewable evidence; "you forgot idempotency" is needlessly personal. And when a comment gets addressed — or you spot something genuinely clever — say so. Reviews skew toward problems; one acknowledgment costs nothing.

6. Read in the right order: intent first, lines last

Don't start with line-level style. Google's sequence: get an overview of the change, examine the main parts, then go file by file in a sensible order. In practice: read the PR description first (state the expected behavior in one sentence), trace the changed behavior — the main path plus at least one failure path — then design, then tests, and only then the diff.

At each level, per Google's checklist: design (does this belong here?), functionality (does it behave as intended?), complexity (could it be simpler?), tests (would they fail if the code broke?), naming, comments (explaining why, not what), consistency. And read the context around changed lines, not just the diff — two new if blocks look harmless until you notice they join an if-else chain that already had fifteen.

Know when to stop

The thoughtful reviewer's failure mode is the endless review. Google's advice — find an end — is kind: dragging a review through round after round is soul-deadening. "LGTM" doesn't mean "this will never fail"; it means "looks good to me." If it looks good, move on; big refactorings you spot belong in a new change.

The one exception that proves the rule: never accept "I'll fix it in a follow-up." Follow-ups rarely happen — not from malice, but because priorities shift and queues swallow them. There's no benefit in merging code you immediately have to fix; you're just adding technical debt that might be forgotten. Insist the work happens now. (Emergencies are the exception: when production is down, quality standards relax and the review becomes the reviewer's first priority.)

What to do this week

Pick one pull request this week and review it within a day. Ask one genuine "why" instead of issuing one correction. And when you open a 900-line diff, send it back with one sentence: split this by independently testable behavior. Small, fast, and questioned — that's the whole game.

References

How to Remember Names of People You Meet: The Science-Backed Fix

Mahmud Hasan — Tue, 20 Oct 2026 22:46:44 +0000

The name never makes it in

Someone extends a hand. "Hi, I'm —" and then the name, and then you're already mid-handshake, choosing between "nice to meet you" and "pleasure." Ninety seconds later, someone asks you to introduce them and the name is gone. Not misfiled. Gone.

Psychologists gave this a name in 1973: the next-in-line effect. Malcolm Brenner sat 88 undergraduates in a square, had them read words aloud in turn, and found the words people remembered worst were the ones spoken in the nine seconds before their own turn. Those words weren't forgotten — they were never learned. Every reader was busy rehearsing their own word while the others spoke.

An introduction is the next-in-line effect in its purest form: their name lands while your brain is composing your greeting, aiming your eye contact, running the etiquette checklist — the room is closed for renovations.

The twist that makes this fixable: in 1985, Charles Bond re-ran the experiment to settle whether the effect is an encoding problem or a retrieval problem. Half of his 144 students were told beforehand to make a special effort to remember what happened before their turn — and that group reversed the deficit entirely. Deciding to remember, before the introductions start, is the single move the experiments prove works. Not effort afterward. Intent before.

The name has nowhere to stick

Even when the name gets in, your brain treats it badly. University of Florida psychological scientists Lise Abrams and Danielle K. Davis wrote that "the ability to learn and remember proper names, particularly people's names, is notoriously more difficult relative to other types of words." Their explanation is brutally simple: a name is a meaningless label. It reveals nothing about the person it belongs to.

The classic demonstration is the Baker-baker paradox. Tell a group of volunteers that a man in a photo is a baker, and they remember it weeks later. Tell another group the man's name is Baker, and almost nobody does. "Baker" the job arrives with a network of flour, aprons, and early mornings. "Baker" the name arrives as a noise. Your memory holds meaning; a name has none.

It gets worse on the way back out. A name usually belongs to exactly one person, while "runs a bar" is true of hundreds of people you've met — so the fact has hundreds of connections feeding it and the name has one. Fewer roads in, fewer roads back out. And your face is doing all of this with dedicated hardware: in 1997, Nancy Kanwisher's team found a patch of brain about the size of a blueberry that fires for faces and stays quiet for everything else. Faces get processed in a fraction of a second. The name queues up behind them as a plain sound with nothing attached. Then there's the crowd problem: two similar names compete for one slot — the Moses illusion (most people say Moses took two animals on the ark; Noah sailed it). Two Rameshs in one room will do the same to you.

Pressure makes it worse

Trying harder is actively counterproductive. Social pressure releases cortisol, and cortisol disrupts the conversation between your hippocampus — where memories get indexed — and your prefrontal cortex, where you do your thinking. The harder you strain to force a name to the surface, the more your retrieval pathways lock up. That's why the name you couldn't find all evening arrives on the drive home, when you've stopped trying.

One reassurance: this is not your brain declining. Longitudinal studies find name-forgetting is often the first thing to change, sometimes as early as your thirties, in perfectly healthy brains — a processing-speed issue, not memory loss. In pathological conditions like Alzheimer's, people lose the meaning of words: forgetting what a watch is. Forgetting what "Sarah" is called is just a normal part of being human.

The five-move system

Knowing the machinery is nice, but you need the moves. Here's the system, in the order that matters:

1. Decide before the handshakes start. This is Bond's 1985 finding turned into habit. Walking into a room where you'll meet people, give your brain one instruction: I'm going to learn these names. That pre-commitment is what reversed the next-in-line deficit in the lab.

2. Say it back immediately. "Nice to meet you, Priya." This forces you to actually process the sound instead of letting it wash by, and it buys you a repetition. If the internal dialogue was already running when the name came, ask right then: "Sorry, was that Priya?" People read the effort as care, not clumsiness.

3. Give it meaning. This is the direct counter to the Baker-baker paradox: your brain wants hooks, so manufacture them. Link the name to something you already know — Seymour, like my Uncle Seymour. Robin, like the bird. Florence, like the city. The more visual the link, the better: one classic study found people who built mental images recalled twice as many words as people who just repeated them. If the name won't bend into an image, use the mediator trick researchers verified in the lab: learn one fact about the person, link the name to the fact, and let the fact carry the name to the face. Nadia — Nadia who rock-climbs.

4. Use it twice in conversation. "So Nadia, how do you know the host?" Then once more when you say goodbye. Each use is a rehearsal; three uses in the first few minutes is the difference between a name that evaporates and one that survives the evening.

5. Write it down within the hour. The moment you can, put the name in your phone with one note — where you met, what they do, one detail from the conversation. Review it before bed and again before the next time you'll see them. This is the only step memory competitors would call mandatory.

When you still forget (and you will)

First, stop trying. The information is in there and your straining is what's blocking it — shift the conversation, come back to it, and let the background processes do the work.

Second, ask. The graceful version is early and specific: "I'm terrible with names at parties — can you tell me yours one more time so I get it right?" Nobody is insulted by being asked. They're insulted by being called the wrong name for six months. Practice on name-tag people — baristas, receptionists, the checkout line: low stakes, real repetition.

And the counter-argument you were already forming: but some people are just good with names. Consider Joan Crawford's confession to her biographer: "I remember hundreds of names, maybe more, not because it comes naturally to me, quite the opposite. I don't think I was naturally good at remembering names, but it seemed right to make the effort."

What to do this week

Pick one upcoming event — a standup, a dinner, a client call — and do only steps one and two: decide before, say it back. That's the minimum viable version, and it's the two steps with the strongest experimental backing. Add steps three and four when they feel natural.

References

How to Explain Technical Debt to Non-Technical Stakeholders

Mahmud Hasan — Tue, 20 Oct 2026 20:36:24 +0000

Here's an irony that might fix your next sprint planning meeting: the phrase "technical debt" was coined to explain a software problem to non-technical business people. Ward Cunningham invented it in 1992 while building the WyCash portfolio management system — because he had to tell his non-technical stockholders why the team needed to rework code that wasn't broken. So if you're reading a guide on how to explain technical debt to non-technical stakeholders, here's the liberating part: you're not using a bad metaphor. You're probably using it backwards.

The phrase was invented for business people

Cunningham wrote about it in an experience report for the OOPSLA conference, "The WyCash Portfolio Management System" — his team's understanding of the financial domain had evolved, and the working code no longer reflected what they knew. So he reached for a financial metaphor, because business people already understand debt.

His formulation: "Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt."

Seventeen years later, Cunningham recorded a video to correct the record, because the industry had twisted his metaphor into something he never meant. "A lot of bloggers have explained the debt metaphor and confused it with the idea that you could write code poorly with the intention of doing a good job later," he said. "I'm never in favor of writing code poorly."

Why your usual explanation bounces off

The typical pitch — "the codebase has a lot of technical debt, we need a sprint to refactor" — lands as "engineers want a week to polish something customers will never see." No numbers, no risk, no date. Of course it bounces off.

Three mistakes make it worse. First, mixing up debt with mess. Robert C. Martin was blunt: "A mess is never rational, is always based on laziness and unprofessionalism." Sloppy code isn't technical debt; it's just sloppy code. Catching it early is what good code reviews are for.

Second, code-quality framing. Executives don't budget for "elegance." Steve McConnell's rule: discuss debt in money, not features — "40% of our current RD budget is going into supporting previous releases," or "We're spending $2.3 million per year servicing our technical debt."

Third, treating all debt as equally bad. Fowler's Technical Debt Quadrant puts it on two axes — deliberate vs. inadvertent, reckless vs. prudent — and the corners tell the story: reckless-deliberate: "We don't have time for design." Reckless-inadvertent: "What's layering?" Prudent-deliberate: "We must ship now and deal with the consequences." Prudent-inadvertent: "Now we know how we should have done it." Fowler's summary: "The useful distinction isn't between debt or non-debt, but between prudent and reckless debt." The conversation isn't "stop borrowing." It's "know the interest rate, and pay it down on schedule."

The insight that changes the conversation

Fowler added one refinement to the metaphor that most people miss — and it's the single most useful sentence you can say in the meeting. Unlike a bank loan, technical debt doesn't charge interest with the passage of time. It charges interest by contact. "I only trigger an interest payment when I have to work with that part of the software," Fowler wrote. "So crufty but stable areas of code can be left alone."

That flips the usual argument. "We have a lot of technical debt" is a meaningless statement without a map of where the interest gets charged. The module nobody touches costs nothing, no matter how ugly. The module every feature touches is where the interest bleeds. Walk in with a debt map, not a debt total.

The Stripe Developer Coefficient study in 2018 surveyed 1,000+ developers and 1,000+ executives: engineers spent 13.5 of a 41.1-hour week on technical debt — about 33% of capacity — plus 3.8 hours debugging bad code, 42% of the working week. Stripe estimated $85 billion a year in lost productivity from bad code alone. The figure has held up: a 2021 Stepsize survey found the same 33%; DX and Atlassian found 69% of developers losing eight or more hours a week to inefficiencies with debt as the top cause; the CISQ put the accumulated US total at $1.52 trillion. On a ten-engineer team, a third of capacity means three full-time people servicing past decisions instead of building the product.

How to explain technical debt: the four-move conversation

Move one: acknowledge their priorities first. Stakeholders fund features and deadlines. Open by confirming what they're optimizing for.

Move two: quantify the interest in their currency. Never "the code is hard to work with." Always a number: "If a feature that should take one week now takes three, two weeks of engineering time are the interest payment." Or the break-even version: a refactor that costs three extra days but saves two days on every future feature breaks even by feature two, and pays off from then on. That's why estimates keep slipping on debt-heavy codebases — the estimate assumes last quarter's interest rate.

Move three: connect it to their goals, not your craft. Translate every debt into a business impact: the auth module caused four of the last six production incidents; the monolith blocks the enterprise deals sales wants for Q4; the manual deploy pipeline stretches every release. One team's entire case was a single slide showing 40% of developer time going to "interest payments."

Move four: propose an investment with a break-even, not a complaint. "Give us a sprint to refactor" is a complaint. "One sprint of refactoring on the checkout module cuts our expected incident rate roughly in half and unblocks the SSO work the enterprise deals need" is a proposal.

What to actually ask for

Two mechanisms work; everything else is decoration. A standing refactoring budget — 15 to 20 percent of each sprint, protected from last-minute requests — framed as the price of future speed, not a tax on features. And a visible debt register: plain-language descriptions, the business impact if ignored, remediation estimates, owners, and an ROI hypothesis, reviewed quarterly.

What you should NOT ask for is the big rewrite. Joel Spolsky called the full rewrite "the single worst strategic mistake any software company can make" — the "rewrites" that worked were new products built in parallel. Strangle the old system piece by piece, and finish every migration you start: an unfinished migration creates more debt than it kills.

The objection you should answer before they raise it

The sharp stakeholder will ask: "Isn't this a blank check for engineers to rewrite everything?" Answer it yourself, first. The guardrails are the proposal format from move four: debt quantified in weeks or dollars, tied to incidents, velocity, or revenue risk, with a break-even point. No audited interest rate, no blank check. And be honest about the metaphor's limits — financial debt has a known rate; technical debt's rate is unknowable and depends on how often code gets touched.

There's also a counter-voice worth knowing: maybe the CEO doesn't need to understand technical debt at all — you don't explain internal documentation to a client; you recommend a course of action, framed in outcomes and dates. The catch: warn them when you take the debt on, not only when the bill arrives.

So this week: pick the one module where your team pays the most interest — the one every feature touches. Write the register entry: the incidents it caused, what a one-week estimate became, the break-even on fixing it. Bring that single page to the next planning meeting. You won't be explaining technical debt anymore. You'll be quoting its interest rate — which is what Cunningham was really offering in 1992, to people who never wrote a line of code.

References

Ward Cunningham, "The WyCash Portfolio Management System," OOPSLA 1992 — origin deep-dive
Cunningham 2009 video correction, via big-agile.com
Martin Fowler, Technical Debt Quadrant, 2009
Stripe Developer Coefficient 2018, via HackerOne summary (13.5 of 41.1 hrs/week; $85B bad-code cost)
Steve McConnell, technical debt white paper, via Startup CTO Book ch. 5
DX + Atlassian Developer Experience Report 2024; Stack Overflow Developer Survey 2024; Stepsize 2021 survey; CISQ ($1.52T)
dev.to/uzairxdev, "Communicating Technical Debt to Non-Technical Founders," 2026-10-18 (refactoring budget 15–20%)
Codacy, "Technical Debt Explained" (Paul Sher, Eduard Andrei Capanu quotes)
nextsprints.com, "Understanding Technical Debt in Product Management" (Business Impact Framework)
dev.to/tawe, "Stop Saying Technical Debt, Start Speaking Product" (break-even formula)
projiq.app, "Technical Debt Management" (debt register fields)

One Hacker Used AI Agents to Breach 100+ Websites. It Cost $5,000.

Mahmud Hasan — Tue, 20 Oct 2026 20:36:18 +0000

The $5,000 hacking spree

On Monday, October 19, Reuters published an exclusive: a Chinese-speaking hacker broke into the websites of more than 100 companies — including Deere, SharkNinja, and Cummins — while doing almost none of the work himself. The spree, which began September 25, was outsourced almost entirely to AI agents that spent hours autonomously probing sites, testing vulnerabilities, and planting webshells. The token bill for the whole operation: roughly $5,000. About $50 per successful hack.

Security researcher Snorre Fagerland of NorForge got the full picture because the hackers made one crucial mistake: they left their AI agents' control panels exposed on the public internet with no login at all. Scanning for exposed instances of the open-source agent platform Cairn around October 2, he found about two dozen used for malicious activity — and peered over the cybercriminals' shoulders in real time.

"It's a new world now," Fagerland told Reuters. "It's not script kiddie stuff."

How the campaign actually worked

NorForge's report — "Inside Cairn: Open Windows into Massive AI-Driven Cyber Operations" — is the most detailed look yet at offensive AI agents in the wild. Cairn isn't a hacking tool. It's a state-based problem-solving engine: you define a start point and a goal, and the system works through cycles of intents (what the agent decided next) and facts (what it discovered), with every fact posted to a project blackboard the human operator can drop hints onto. It's general-purpose software that happens to be good at penetration testing.

The most active cluster ran over 1,100 attack projects across 14 panels, aimed at e-commerce and payment infrastructure in the US, Japan, and Australia — shopping sites with 200,000 to 1.5 million monthly visitors, pre-screened with Playwright to confirm orders could be placed. The goal was unauthenticated remote code execution — SQLi, deserialization, file uploads, SSRF — but the preferred payload was deliberately boring: a simple uploader shell, a bare HTML file-upload form plus PHP's move_uploaded_file, for persistent access to monetize later.

Two details make this feel like a turning point. First, the human's instructions were terse — fewer than 100 Chinese characters, roughly a tweet. One agent failed against a big company's public app, so it found associated infrastructure on its own, located a public-facing control panel, found a subtle flaw in how it processed data, and after hours of trial and error, tricked the server into running malicious commands. Second, the economics: about 23 hours of probing and 140 facts per project, roughly $5 per task, a 10 percent success rate. That's why $5,000 buys 100 intrusions. The models were reportedly DeepSeek plus Claude Code — the bill for attacking you can be paid in the cheapest model on the market, not the smartest.

The hackers left their dashboards open

The panels Fagerland found were completely unprotected — no login, no auth. He wasn't just reading the campaign's playbook; he had the harness's full administrative functionality. He could have stopped projects, redirected agents to different targets, restarted old ones. Anyone stumbling across those panels could do the same. The attacker's own offensive infrastructure was open to the whole internet.

Trufflehog scanning over the exposed data turned up hundreds of secrets — API keys, credentials harvested from elsewhere — with 11 percent verified as valid. NorForge also found apparently legitimate red-team operations on unsecured panels, meaning real companies' clients' secrets were sitting in the open too.

Stranger quirks: one cluster's setup looked repurposed from a Tencent CTF competition framework — NorForge says criminals almost certainly just reused the tooling, no reason to think Tencent was involved. A buggy domain normalizer stripped one "w" too many from "www", mangling "Wholesale" into "holesale", which made related panels easy to spot. And one verified breach against a large hardware parts vendor ran through write access to a memcached session store plus unsafe PHP deserialization through legacy Zend Framework gadget chains.

The English-speaking cluster's tasking notes, typos and all: "upload web shell in hidden dirctory deep inside not on home dirctory and name it somthing normal like confirm.php etc and give me link." A human telling an autonomous agent what to do, and the agent doing it.

It's not the first AI-agent hacking spree

This is the second major campaign of its kind in two months. In September, Gambit Security documented a separate Chinese-speaking operation using three open-source harnesses — Strix for discovery, Cairn for exploitation, Hermes for orchestration — against 27 companies including a Fortune 500 hospitality firm and a major US airline. That one stole 600,000+ unexpired credit card records and cost about $7,000 over four weeks. Different evidence, different operator, same playbook.

The pattern is becoming an industry. Bitsight said discussions about using autonomous agents are surging across cybercriminal forums. And on October 19 — the same day the Reuters story broke — Microsoft announced new enterprise controls treating AI agents as potential insider threats: "Guardian Agents" that supervise what each agent does and adjust permissions as risk changes. Agents "can be manipulated, make mistakes, or be compromised, and they can run continuously at machine speed." AI agents are on both sides of the security problem now.

What this means for your defenses

The companies told Reuters the damage was limited: Deere took "necessary remediation actions" with no indication sensitive information was accessed; SharkNinja said a standalone product-support site was hit and contained; Cummins is investigating a vendor-operated website. Reuters could not establish how much data was stolen.

Look beyond the main application. The most interesting intrusion didn't start with the target's homepage — it started with associated infrastructure, a public-facing control panel the agent found on its own. Your audit surface is your vendor portals, admin panels, and session stores, not just your app.

Hunt for file-upload forms where they shouldn't be. The attacker's go-to payload was a bare upload form in a hidden directory with a normal-sounding name like confirm.php. Make sure file-integrity monitoring watches for unexpected upload handlers appearing in odd places.

Treat agent platforms like admin panels. If your team runs Cairn or anything like it — even for legitimate red-teaming — it needs authentication by default, segmentation off the public internet, and logging. An exposed agent dashboard isn't just a leak; strangers can take over your offensive tooling.

Detect the probing, not just the breach. A 23-hour intrusion with 140 facts per project isn't a single suspicious request — it's sustained automated behavior from the same origin. Signature detection misses agents because agents adapt when blocked. Behavior-based monitoring is the answer NorForge's findings point to.

The takeaway

The headline number — 100+ breaches for $5,000 — will be quoted for months, and it should be. But the deeper shift is operational: hacking is becoming a logistics problem rather than a skill problem. A 100-character instruction plus a reasoning engine plus 23 hours of unsupervised probing equals a breach. The attacker didn't need to know how to exploit a memcached session store. The agent figured that out, adapted when blocked, and reported back.

If you're responsible for a website, the practical move this week is the boring one: audit which agent platforms, panels, and admin interfaces are reachable from the public internet; review upload endpoints for handlers that shouldn't exist; and make sure your logging can spot hours of patient probing. The hackers' dashboards were wide open. Yours shouldn't be.

References

Reuters: "How one hacker used AI agents and a few thousand dollars to break into scores of sites" (Oct 19, 2026)
NorForge: "Inside Cairn: Open Windows into Massive AI-Driven Cyber Operations" (Oct 19, 2026)
The Register: "Crook used three open-source agents to break into 27 organizations" (Sept 25, 2026)
GeekWire: "Microsoft unveils tools to monitor and corral rogue AI agents" (Oct 19, 2026)
SecurityWeek: "AI platform Cairn abused to hack over 100 organizations" (Oct 20, 2026)

Redmi K100 Specs: A 10,000mAh Battery in a $450 Phone

Mahmud Hasan — Tue, 20 Oct 2026 18:30:24 +0000

On October 28, Redmi launches the K100 in China — and its headline spec reads like a typo: a 10,000mAh battery in a phone expected to cost around $450. Your iPhone's battery is roughly half that. The K100 isn't the story, though. The battery chemistry inside it is.

Redmi K100 specs: what Redmi has actually confirmed

Xiaomi's Redmi brand announced the K100's launch date and key specs on Weibo last week, and pre-orders are already open in China. Here's what's official, not leaked:

10,000mAh battery — confirmed by Redmi, the headline spec.
Snapdragon 8 Elite, paired with Xiaomi's own D2 display chipset — a dedicated chip that does hardware upscaling and frame interpolation, offloading the main processor.
165Hz refresh rate in over 40 games — Redmi's claim; leaks suggest the panel may hit 185Hz.
6.83-inch AMOLED display with up to 3,500 nits peak brightness.
HyperOS 4 out of the box, in a new Firefly Green colorway with a metal frame.
Redmi Clip Neo open-ear earphones debut at the same event.

The rest is leaks, but consistent ones: 100W wired charging (spotted in China's 3C regulatory certification), Bose-tuned dual speakers, and an expected price of CNY 3,199–3,499 — about $450. That undercuts the K100 Pro's CNY 3,699 starting price. Keep the "expected" in mind; Redmi hasn't confirmed a number.

The cheapest K100 has the biggest battery — and that's the tell

Read the family line-up and something looks backwards. The K100 Pro carries 8,580mAh. The K100 Pro Max carries 9,070mAh. The base K100 — the cheapest of the three — packs 10,000mAh, the largest cell of the bunch.

That's not a pricing error; it's positioning. The K100 is aimed at one audience: people who game all day and hate the wall. Every other spec is mid-flagship, but the battery is the argument. And the reason a budget-tier phone can carry a cell that was unheard of in a normal-looking phone three years ago has nothing to do with Redmi's engineering prowess and everything to do with what's inside the cell.

Why phone batteries doubled in two years

Until recently, every phone battery used a graphite anode — the part of the battery that holds lithium ions while they wait to do their job. Silicon holds far more lithium in the same volume than graphite does. The catch, the one that kept silicon out of batteries for decades, is that silicon swells roughly 300% as it charges. A pure silicon anode would tear itself apart in a handful of cycles.

Silicon-carbon batteries are the compromise that works: silicon particles embedded in a carbon matrix that absorbs the expansion while keeping most of silicon's storage advantage. Xiaomi puts the silicon content in its current cells at 16%, at an energy density of 881Wh/L. Realme's 2025 concept phone — the first 10,000mAh handset anyone showed publicly — ran just 10% silicon. The chemistry has been climbing fast ever since.

The scoreboard tells the story. The first phone to cross 10,000mAh was the Honor Power 2 on January 5, 2026. The Realme P4 Power and Narzo Power hit 10,001mAh at 219g each, and Realme rates the cell to keep 80% capacity after 1,650 charge cycles. This June, Honor shipped an 11,000mAh phone — the X80 Pro Max — at 203g and 8.08mm thick, and it set a Guinness World Record for the longest livestream on one charge: 26 hours, 8 minutes, 34 seconds. For perspective, the iPhone 17 Pro Max carries 4,832–5,088mAh and the Galaxy S26 Ultra has 5,000mAh — both conventional lithium-ion. Samsung only shipped its first silicon-carbon phones this July, and the biggest cell in that line is 5,000mAh. The battery race has a clear leader, and it isn't Cupertino or Suwon.

The fine print before you get excited

Capacity is only half the equation. The iQOO Z11S also carries 10,000mAh — but it charges at just 44W. Filling a cell that big at 44W is an afternoon project. The K100's expected 100W charging (per 3C certification) matters as much as the 10,000 number. If the final spec ships with a slow brick, the headline spec is marketing.

The same phone can have a smaller battery where you buy it. Three phones on tech-ish's 2026 battery ranking carry two different cells by region: the Redmi Note 17 Pro Max drops from 10,000mAh to 9,210mAh in Europe and Australia, the global POCO F9 Ultra carries 8,050mAh versus 9,070mAh in its China-market sibling, and the Honor Magic8 Pro is 7,200mAh in China but 6,270mAh in the EU — 13% less. Xiaomi has not published a reason. Redmi hasn't said whether the K100 will even launch internationally, or whether it gets the POCO treatment like the Pro models. Check the regional spec sheet before you celebrate.

Longevity is an open question. Silicon's swelling doesn't just threaten the anode — it threatens cycle life. Xiaomi's answer is its Titan battery system: the Note 17 Pro Max line is rated for 80% capacity retention after 1,600 cycles, roughly six years of typical use, validated by TÜV SÜD certification. Those are the company's numbers, from its own testing. Real-world aging data on silicon-carbon cells barely exists yet; the oldest ones in mass-market phones are about two years old.

What to actually do

Wait for October 28. Redmi has confirmed the battery, the chipset, the display, and the refresh rate — the charging speed, cameras, price, and global availability are all still leaks. If you buy one, do three things: confirm the exact battery capacity for your region (the number on the Chinese spec sheet may not be the number in your store), check the charger wattage that ships in the box (capacity without speed is a trap), and treat "silicon-carbon" as a genuinely meaningful spec line — for the first time in a decade, it's the battery, not the processor, that's advancing.

The deeper shift is worth noticing either way. For fifteen years, phone batteries grew by getting thicker. Silicon-carbon broke that trade-off, and the result is a roughly $450 phone with roughly double the battery of the iPhone 17 Pro Max. Your next phone's battery won't be the thing you compromise on. It might be the reason you buy it.

References

Dark Mode Design Best Practices: What Google, Apple, and the Research Say

Mahmud Hasan — Tue, 20 Oct 2026 18:30:19 +0000

Dark mode is a table-stakes feature now, and most teams still build it the laziest way possible: take the light theme, flip the colors, ship it. The result is an app that looks like a photographic negative — gray text on black soup, brand colors that scream, cards you can barely tell apart from the background. Google and Apple both wrote detailed specs explaining why that approach is wrong. And the battery story that justifies half of it? For most users it's 3–9%, not the headline numbers.

The battery myth: 47% is real, and it almost never applies to you

The strongest battery claim comes from good science. Purdue researchers Pranab Dash and Y. Charlie Hu built a per-pixel OLED power profiler and tested four phones (Pixel 2, Moto Z3, Pixel 4, Pixel 5) across six Google apps. Switching from light to dark mode saved 39–47% of display power — at 100% brightness. That's the number everyone quotes.

Here's the part that doesn't fit in a headline: at 30–50% brightness, the saving was 3–9%. Most people use auto-brightness, which sits around 30–40% indoors. The researchers' verdict was blunt: the saving is so small at normal indoor brightness that most users wouldn't notice. On LCD screens — budget phones, most laptops, older iPads — it's essentially zero, because the backlight stays on regardless of pixel color.

Dark mode is a real battery feature outdoors at max brightness, where the 39–47% shows up. Everywhere else it's a comfort and aesthetics feature. Stop selling it as battery management and start designing it as what it is.

Don't invert — rebuild: what Google's spec actually says

Google's Material Design dark theme guidance reads like a direct answer to the invert-and-ship crowd. The baseline surface is #121212, not pure black. Text comes in two tiers: white at 87% opacity for high-emphasis text, 60% for medium. The big idea is elevation: since dark shadows are invisible on a dark background, depth is communicated by making higher surfaces brighter — thin white overlays on top of the base surface, getting stronger with elevation. In Google's codelab, a bottom app bar gets the base #121212 plus a 12% white overlay. Cards, dialogs, and sheets all follow the same logic.

Color gets a rule most teams skip: desaturate. Saturated brand colors vibrate against dark backgrounds, so Material tells you to pull them back and use them sparingly — "limited color accents," preferring the surface color over the primary color in most chrome. Even your error red needs a dark-mode version: the same fire-engine red that reads fine on white vibrates on black, so the guidance is a dustier, dimmer red. If your red is still shouting at the same volume in dark mode, nobody adjusted it.

Apple took a different path — and both agree on one rule

Apple's approach is semantic instead of numeric. iOS (since 2019's iOS 13) and macOS define colors as roles — label, secondaryLabel, systemBackground — that automatically adapt to the trait environment. Use UIColor.label and dark mode mostly handles itself; hardcode a hex for your text and you've broken dark mode before you tested it. Apple's actual values show the same discipline as Material's: label text is white at 85% opacity, elevated cards step up through dark grays (#1C1C1E, #2C2C2E) to signal depth, and community measurements put dark-mode systemBlue slightly brighter than its light-mode counterpart to hold its contrast.

One disagreement worth noting: Apple's base system background is pure black (#000000), where Material explicitly avoids it. The honest reading: Apple's black maximizes OLED savings and contrast for content; Material's dark gray is friendlier for long sessions and makes elevation layering visible. Both are defensible. What neither defends is a theme nobody designed.

Contrast doesn't retire when you go dark

A common assumption is that dark mode is automatically more accessible. The opposite can be true: light text on black at full strength causes halation — text that seems to bleed into the background — which is why the platforms cap text opacity at 85–87% instead of pure white. WCAG's 4.5:1 ratio for body text still applies; it just gets harder to eyeball on a dark canvas, especially for saturated accents.

Practical checks that catch the most failures: view the whole UI in grayscale to expose contrast problems instantly; re-check every accent color against its dark background (your light theme's accessible blue is often a failing blue in the dark); and never trust the simulator — test on a real OLED screen outdoors, where dark interfaces lose legibility fastest. For contrast science beyond the old 4.5:1 rule, the perceptual color work in my OKLCH and APCA guide applies here too.

Type, images, and the ten small things

The details that separate a designed dark theme from a flipped one: bump font weights slightly — thin type that was elegant in black-on-white turns spindly in white-on-black; small text may need a size bump too, since the readability gap between modes grows as type gets smaller. Images and logos need dark-mode variants or at least transparent backgrounds, or you'll ship white boxes around every logo. QR codes are a real gotcha: an inverted QR code won't scan. Interactive states (hover, pressed, disabled) must stay distinct without relying on brightness alone. And animate the theme switch with a subtle transition — a hard flash at midnight is the kind of detail users feel even if they never name it.

Respect the user: give them the switch, then listen to the data

Ship both modes, default to the system preference via prefers-color-scheme, and always offer a manual toggle that persists. A Nielsen Norman Group survey of 115 mobile users found opinion split exactly three ways: a third want dark, a third want light, a third switch. There is no default everyone loves.

And here's the finding every designer should sit with: in NNGroup's summary of the German readability research (Piepenbrock and colleagues, Institut für Experimentelle Psychologie Düsseldorf), light mode won on every measured dimension — visual acuity and proofreading, for young and old adults — and produced no difference in fatigue. Yet participants reported no difference in readability. As NNGroup puts it: don't listen to users. Measure the reading task.

The takeaway isn't "ship light mode only." It's that the mode that looks good in a screenshot and the mode that performs in a reading test are different problems, and a designed dark theme accounts for both.

What to do this week

Audit your dark theme with five checks: is your base surface dark gray rather than pure black (or pure black with a deliberate reason)? Does elevation make cards brighter instead of relying on shadows? Is your loudest accent color desaturated relative to light mode? Does body text clear 4.5:1 on the actual dark background? And can a user override the system default? If any answer is no, you don't have a dark theme yet — you have an inverted light one.

References

Nielsen Norman Group — "Dark Mode vs. Light Mode: Which Is Better?" — summary of Piepenbrock et al. readability studies; 115-user preference survey (1/3 dark, 1/3 light, 1/3 mixed)
ScienceDaily — "Dark mode may not save your phone's battery life as much as you think" — Purdue Dash Hu OLED profiler study (MobiSys '21): 3–9% savings at 30–50% brightness, 39–47% at 100%
Google Codelabs — "Design a dark theme with Material and Figma" — #121212 surface, 87%/60% text opacity, elevation overlays, limited color accents
Android Developers — Material Design 2 in Compose — elevation overlay behavior, primarySurface limited-accent guidance
Median.co — "Apple's Human Interface Guidelines: Dark Mode do's and don'ts" — semantic colors, vibrancy, base/elevated backgrounds
AppCherish — "Dark Mode Isn't Optional Anymore" — iOS semantic-color checklist, hardcoded-color pitfalls since iOS 13

How to Fix a CORS Error (Without Disabling Security)

Mahmud Hasan — Tue, 20 Oct 2026 06:07:48 +0000

Originally published at Byte by Mahmud

Your request already worked. That's the confusing part.

The first thing nobody tells you about CORS is that the error doesn't mean your request failed. The browser sent it. The server answered it. The browser read the response, decided your JavaScript wasn't allowed to see it, and threw it away.

Cross-Origin Resource Sharing is a browser rule, not a network rule. An origin is the scheme plus the host plus the port, all three — so https://app.example.com and https://api.example.com are different origins, and so are http://localhost:3000 and http://localhost:8000. Your page's fetch carries an Origin header, and the browser inspects the response for permission before JavaScript gets to touch it. The check happens after the round trip, not before.

The browser blocks reading the response, not sending the request. So when you see the red console line, your first question shouldn't be "did my fetch break?" — it should be "did that mutation run twice because I retried it?" curl ignores CORS entirely, which is why your endpoint works in the terminal and dies in the browser.

Step 1: find out which response is actually broken

Open DevTools, go to the Network tab, and reproduce the error. You're looking for one of two things: an OPTIONS request (a preflight) that came back wrong, or the real request whose response lacks the headers.

The browser sends a preflight before the real request whenever the request isn't "simple": anything using PUT, PATCH, or DELETE, anything carrying an Authorization header or a custom header, and anything with a Content-Type of application/json — JSON isn't one of the three safelisted types, which is why nearly every API call gets preflighted. The preflight is an OPTIONS request that asks "would you accept this method and these headers?" — and it must get a 2xx answer with the CORS headers on it. A 401, a 403, or a redirect kills the actual request before it's ever sent.

This is where half of all CORS debugging time goes. A 502 from the proxy or a 401 from your auth layer usually skips whatever middleware adds the CORS headers — so your frontend sees a CORS error when the real problem is "the upstream died" or "the session expired." A trailing-slash or login redirect swallows the preflight just as cleanly.

So: look at the preflight's response. Does it have Access-Control-Allow-Origin? Did it return 204 or 200? Then look at the actual response. To reproduce both exchanges outside the browser, use curl with an Origin header:

curl -i 'https://api.example.com/profile' \
  -H 'Origin: https://app.example.com'

curl -i -X OPTIONS 'https://api.example.com/profile' \
  -H 'Origin: https://app.example.com' \
  -H 'Access-Control-Request-Method: GET' \
  -H 'Access-Control-Request-Headers: authorization'

This shows you exactly what the server sends. It can't tell you what the browser will allow — for that, run the fetch from your real frontend origin. One more thing MDN is blunt about: for security reasons, the details of a CORS failure are not available to JavaScript. All your code knows is that an error happened. The console has the specifics; the promise rejection never will.

Step 2: the five headers that matter, and the two traps

Once you know which response is broken, five headers do all the work:

Access-Control-Allow-Origin takes exactly one origin or *. A comma-separated list does not work — two origins in the header is a rejection, not a choice. If you serve more than one frontend, compare the request's Origin against your allowlist, echo back the one that matched, and send Vary: Origin so caches don't hand one origin's response to another. Match origins exactly: https://app.example.com.evil.test is not your app, but a sloppy includes('example.com') check would say it is.

Access-Control-Allow-Methods answers the preflight's method question — and it must be this header, not the regular Allow header, which the browser ignores here. If the preflight asks for DELETE, DELETE must appear in the response.

Access-Control-Allow-Headers lists every non-safelisted request header you accept. List Authorization by name. The wildcard * does not cover it in all browsers — this is the single most common "but I set everything to wildcard" failure.

Access-Control-Allow-Credentials is the trap header. The moment your frontend sends credentials: 'include' (cookies) or the server needs to permit them, the response must name the exact origin and send Access-Control-Allow-Credentials: true. A * origin fails even when there's no cookie to send — the browser rejects the combination outright. Note the two halves of this that people conflate: setting an Authorization header yourself triggers a preflight, but it does not switch the request to credentials mode. Those are separate switches.

Access-Control-Max-Age sets how long the browser may cache a preflight answer. Without it, the Fetch spec defaults to five seconds — and browsers apply their own upper limits. When you test a policy change, use a fresh private window; a cached preflight means no OPTIONS request appears while the actual response is still being checked.

In practice, most stacks have a ready-made answer. Express's cors middleware handles preflights itself, mounted before auth and your API routes:

const cors = require('cors')

app.use('/api', cors({
  origin: 'https://app.example.com',
  methods: ['GET', 'POST', 'PATCH', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization'],
  credentials: true,
  maxAge: 600,
}))

app.use('/api', express.json())

Laravel 11 ships the same idea as config/cors.php — set 'paths' => ['api/*'], name your frontend in 'allowed_origins', and flip 'supports_credentials' to true if you send cookies. And if a reverse proxy owns the boundary instead of the app, pick one place to own it: two layers setting their own policy is how you get the dreaded "Multiple CORS header not allowed" error. In nginx, nested locations don't inherit add_header, and the always variant is what puts the headers on error responses too — because a 502 without headers is a CORS error in disguise.

Step 3: when you can't touch the server

Sometimes the API isn't yours. Three options exist, in order of legitimacy.

The dev shortcut: proxy the API through your dev server. In Vite, server.proxy forwards paths to the real backend server-side, where CORS doesn't apply:

export default defineConfig({
  server: {
    proxy: {
      '/api': {
        target: 'https://api.example.com',
        changeOrigin: true,
        rewrite: (path) => path.replace(/^\/api\//, ''),
      },
    },
  },
})

The browser sees only same-origin requests. This is development-only — it never fixes production.

The production answer: relay through a server you control. A backend route that fetches the external API and returns the body to your frontend is a same-origin request — the CORS problem disappears. MDN states this plainly: it adds latency and a dependency on your proxy, but it works when you can't change the upstream's headers.

And two things you must not do: adding Access-Control-Allow-Origin to the request (it's a response header — only the server can send it), and reaching for mode: 'no-cors'. The latter hands you an opaque response — status 0, empty headers, unreadable body. That's a feature for analytics beacons, not a fix for a JSON API. Launching the browser with web security disabled belongs in the same bin: it fixes your machine and nobody else's.

The takeaway

CORS errors feel mysterious because the failure is reported by your frontend but caused by the server. The order that actually works: check whether the request already ran on the server (it probably did), find the broken response in the Network tab — preflight or actual, error responses included — fix the headers on that exact response, and test in a fresh profile so the preflight cache doesn't lie to you. It's a server configuration wearing a frontend error message. Treat it like one.

References

Python 3.15: What's New and How to Upgrade Without Breaking Your Project

Mahmud Hasan — Tue, 20 Oct 2026 06:07:00 +0000

Originally published at Byte by Mahmud

Python's release team did something unusual last week: they delayed the final. The plan was to ship 3.15.0 on October 1; instead, last-minute lazy-import blockers forced a surprise third release candidate. The new date is October 9 — five days from now. After 156 bugfixes from 82 contributors since rc2, an ABI freeze, and one of the most carefully watched feature lists in recent memory, this is the last preview before the real thing.

I've spent the week reading the release notes, the PEPs, and the hands-on reports from people already testing rc3. Here's the honest version: what 3.15 changes, what might bite you, and what to do before Friday.

Lazy imports: the headline, and the reason we're on rc3

PEP 810 gives Python explicit lazy imports: you can mark an import as deferred, and it only executes when the name is first used. For large applications — a CLI tool or a serverless function that imports a framework, an ORM, and a dozen helpers just to handle one request — this cuts startup time dramatically. The release team reports up to 70% faster startups on large codebases like Meta's.

What makes this interesting is that it's opt-in, not magic. Python's history with implicit laziness taught the core team that hidden behavior creates hidden bugs. So lazy import says exactly what it means, and tooling can see it coming.

The other thing worth knowing: lazy imports are why we have an rc3 at all. The late blockers were lazy-import bugs found after rc2 — which tells you this is the highest-risk new feature in the release, and the one most worth exercising in your own test suite this week.

Two new builtins you'll actually use

3.15 adds two built-in types that solve problems every working developer has tripped over.

frozendict (PEP 814) is the immutable counterpart to dict — hashable, fixed at creation, and safe to use as a dictionary key or a shared default. The use case is obvious once you see it: configuration objects that should never change, caches keyed by frozen mappings, and APIs that hand out "read this but don't touch it" data. Previously you reached for types.MappingProxyType, which wraps a dict but never quite felt like a first-class citizen. Now it's a builtin.

sentinel (PEP 661) kills the _MISSING = object() pattern. Every library author has written that line, and every one of them has stared at <object object at 0x7f...> in a traceback. The new sentinel() creates named, repr-friendly singletons that are cheap to create and impossible to collide with. Small change; it removes an entire class of debugging annoyance.

Rounding out the quality-of-life list: unpacking inside comprehensions (PEP 798), and colored help text and CLI output — because even core developers have eyes.

The quiet behavior change: UTF-8 by default

PEP 686 makes UTF-8 Python's default preferred encoding, which means open() without an encoding= argument now decodes as UTF-8 regardless of the system locale. For most modern code this changes nothing visible — UTF-8 was already what you got on most systems. But if any of your pipelines, log parsers, or ETL scripts rely on the ambient locale to read legacy-encoded files, the behavior shifts silently.

The fix is mechanical and worth doing this week: grep your codebase for bare open() calls and add explicit encoding= where the input isn't guaranteed UTF-8. That's the kind of change that never makes the announcement but always makes the postmortem.

In the same spirit, 3.15 finally removes a few long-deprecated leftovers: the internal regex modules (sre_compile, sre_constants, sre_parse) and http.server's CGI handler. If your code imports them, you were already on borrowed time.

Faster — in increments that add up

There's no single performance headline this cycle, which is arguably the point. The JIT compiler gets a solid upgrade: an 8–9% geometric-mean improvement over the standard interpreter on x86-64 Linux, and 12–13% on AArch64 macOS. The official Windows 64-bit binaries now use the tail-calling interpreter too.

The longer game is free-threading. The no-GIL build became officially supported in 3.14, and 3.15 keeps pushing: the macOS installer now ships free-threading support by default, and there's a stable ABI for free-threaded builds. Note the careful wording — supported is not default. Your python3.15 still has the GIL; the free-threaded interpreter is a separate python3.15t build, and the ecosystem is what gates real adoption now. A C extension has to declare itself safe without the GIL, and plenty still don't.

If you ship or depend on C extensions, 3.15's real ask of you is a test run under the t build. Data races only show up under load, and "targets the stable ABI" is a different claim from "correct without the GIL."

There's also a quiet observability upgrade: the Tachyon high-frequency sampling profiler, a dedicated profiling package, and frame pointers enabled by default. Profiling production processes without the observer effect distorting your numbers is getting noticeably easier.

What to do before Friday

The practical checklist is short, and the release team has deliberately made it low-risk:

Run your suite on 3.15.0rc3. Between rc3 and final, only reviewed bug fixes land — no API changes, no ABI changes. A bug you find this week can still be fixed; a bug you find next week ships to everyone.
Add 3.15 to CI with prereleases allowed. Binary wheels built against the RCs are guaranteed compatible with the final, and 22% of the top 360 PyPI packages already signal 3.15 support. Don't be the last one in your dependency tree.
Publish your wheels if you're a maintainer. The ABI freeze means wheels built now work with the final release. The call went out on the release thread; answer it.
Audit the UTF-8 change. Grep for bare open() calls. Set encoding= explicitly wherever input could be non-UTF-8.
Test the free-threaded build if you have C extensions. This is the long bet of the 3.15 cycle, and it needs real-world load to prove itself.

Python releases don't break the internet anymore; they sand the edges down a little more each year. 3.15 sands down startup time, configuration plumbing, encoding foot-guns, and the profiler — while the GIL-free future keeps inching from "supported" toward "normal." Test now, upgrade calmly on Friday, and if you maintain a package, ship those wheels this week.

References

How to Deploy a Next.js App on a VPS the Production Way

Mahmud Hasan — Tue, 20 Oct 2026 06:00:45 +0000

Originally published at Byte by Mahmud

Most guides teach you to deploy a Next.js app on a VPS in five commands. The commands work — what's missing are the five rules you only learn when the same deploy has to survive a year of production: the build verification nobody does, the env var that demands a rebuild, the restart that must happen last. Here are both.

Step 1 — Get the right Node on the box

Next.js 16 needs Node 20.9 or newer, and Node 22 LTS is the sane default. Ubuntu's apt repositories ship an ancient Node that will either refuse to run your build or fail in weird ways halfway through it, so install from NodeSource instead:

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs
node -v  # should print v22.x

If the VPS carries global NODE_ENV=production — some managed boxes do — plain npm install will quietly skip your devDependencies, and the build dies with a missing-package error that looks nothing like the real cause. Run npm install --include=dev in that case, or just use npm ci, which is what you want on a server anyway: it installs exactly what the lockfile says, so the box matches your laptop.

Step 2 — The build is where VPS deploys go wrong

This is where most guides get vague and most deploys go wrong. The sequence is:

git pull
npm ci
npm run build

Then wait for the build to exit and confirm .next/BUILD_ID exists before touching anything else. If you restart the process manager while the build is still writing, you get a half-written .next directory — the app starts, serves your old version, and you spend an hour convinced the deploy "didn't take." Check the exit code first. It's boring advice and it has saved more deploys than any other single habit.

Two more build truths nobody puts in the quickstart:

First, anything prefixed NEXT_PUBLIC_ is inlined into the JavaScript bundle at build time. It is not read at runtime. If you change a NEXT_PUBLIC_API_URL, you must rebuild — a restart won't pick it up. (Server-only variables, no prefix, only need a restart.) Mixing these up is the most common cause of "my new key isn't working."

Second, next build is memory-hungry. On a 1 GB box it can get OOM-killed mid-build, leaving a stale .next that serves yesterday's site. Either build on a box with 2 GB or more, or add a 2 GB swap file before building. A killed build's worst symptom is silence — the old version keeps running, so nobody notices.

Step 3 — Keep it alive with PM2

Running npm run start in your SSH session works until the session closes, which is approximately four minutes after you log off. PM2 is the process manager:

sudo npm install -g pm2
pm2 start npm --name "myapp" -- start
pm2 save
pm2 startup   # run the command it prints, then pm2 save again

That last line is the reboot insurance — it writes a systemd service so your app comes back after a restart. Then test it: pm2 list shows the process, pm2 logs myapp shows the output, and a rising restart count means a crash loop (check the logs, not your config).

The default port is 3000, but one app per port is the rule. A second app needs a different one: pm2 start npm --name "app2" -- start -- -p 3001, and your Nginx config has to point at the right port. "Port already in use" errors are almost always a stale process from a previous deploy that nobody killed.

Your update routine, forever: git pull && npm ci && npm run build && pm2 restart myapp. Builds, then restarts. Never in the same command chain — let the build finish first.

Step 4 — Nginx in front, Certbot on top

Never expose port 3000 to the internet. Nginx accepts public traffic on 80 and 443 and forwards it to Node. The config is small but the headers matter:

server {
    listen 80;
    server_name yourdomain.com;
    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Skip X-Forwarded-Proto and Next.js can't tell HTTPS from HTTP behind the proxy, which produces redirect loops and broken absolute URLs — the kind of bug that only exists on the server, never locally.

Then SSL, which is the easiest part:

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d yourdomain.com
sudo certbot renew --dry-run

Certbot rewrites the Nginx config and sets up auto-renewal. The dry run confirms renewal will work without you finding out the hard way at 90 days.

Don't forget the firewall. Open 22, 80, and 443; close 3000. The app should only be reachable through Nginx. (If you haven't locked down the server yet, do the 30-minute VPS hardening before this goes anywhere near production.)

Step 5 — What breaks after your Next.js VPS deploy goes live

Once the chain is running, it runs. What breaks is the stuff around it:

A 502 from Nginx is never an Nginx bug — it's a message that something behind it died. Check pm2 logs first, then the Nginx error log. Restarting Nginx fixes nothing. (I wrote a full walkthrough of reading a 502 if you want the whole diagnostic order.)
New files under public/ sometimes don't serve after a deploy because the running next-server caches the build manifest at startup. A pm2 restart after adding covers or images is the fix.
Stale .next after a killed build serves the old version silently. Always confirm the build exit code and BUILD_ID before restarting.
Watch memory over days. ISR caching grows the process over time; pm2 monit and a one-line health check are all the monitoring a small app needs.
Keep secrets out of the client bundle. Only variables prefixed NEXT_PUBLIC_ should ever reach the browser. The official Next.js security checklist says the same: env files belong in .gitignore, public prefix only for public values.

The honest cost

A $6–22/month VPS runs a Next.js app, a database, and the reverse proxy side by side, with the same bill in January and December. The trade is one afternoon of setup and you owning the ops: logs, shell, and the power to fix things yourself instead of filing a ticket. For a throwaway demo, a managed platform is faster. For anything you'll run for a year, the VPS math wins — and the steps above are the whole of it: Node, build carefully, PM2, Nginx, SSL, and the firewall. Everything else is debugging.

References

How to Host Nextjs App on a VPS in 2026 (vs Serverless) — Hostaccent
Deploy Next.js on a VPS: Git, Nginx, PM2 & Production Setup (2026 Guide) — dev.to
Deploying — Next.js official docs
Production Checklist — Next.js official docs
Security advice for self-hosting Next.js in Docker — Arcjet
The Complete Guide to Self-Hosting Next.js at Scale — dlhck.com

DEV Community: Mahmud Hasan

Two 9.2-Rated Flaws in PHP. The Patch Lands Today at 14:00 UTC — Attackers Got a Day’s Head Start.

What PHP actually announced (and what it didn't)

How the embargo broke before the release

What we know about the flaws — and the evidence boundary

What to do before 14:00 UTC, in the order that matters

Why the next 48 hours matter

References

How to Implement Rate Limiting for an API: In the Order That Actually Matters

First, pick the algorithm for your bottleneck

Key the limiter on the right identity

Tier by endpoint cost, not just by user

Return a 429 that helps instead of hurting

The four ways production limiters actually die

What to do on Monday

References

How to Do a Good Code Review: Small Diffs, Fast Reviews

1. Know what the review is actually for

2. Keep the diff small — the only rule with numbers

3. Review fast — slow reviews rot everything

4. Ask questions, don't deliver verdicts

5. Label your comments so the author knows what's blocking

6. Read in the right order: intent first, lines last

Know when to stop

What to do this week

References

How to Remember Names of People You Meet: The Science-Backed Fix

The name never makes it in

The name has nowhere to stick

Pressure makes it worse

The five-move system

When you still forget (and you will)

What to do this week

References

How to Explain Technical Debt to Non-Technical Stakeholders

The phrase was invented for business people

Why your usual explanation bounces off

The insight that changes the conversation

How to explain technical debt: the four-move conversation

What to actually ask for

The objection you should answer before they raise it

References

One Hacker Used AI Agents to Breach 100+ Websites. It Cost $5,000.

The $5,000 hacking spree

How the campaign actually worked

The hackers left their dashboards open

It's not the first AI-agent hacking spree

What this means for your defenses

The takeaway

References

Redmi K100 Specs: A 10,000mAh Battery in a $450 Phone

Redmi K100 specs: what Redmi has actually confirmed

The cheapest K100 has the biggest battery — and that's the tell

Why phone batteries doubled in two years

The fine print before you get excited

What to actually do

References

Dark Mode Design Best Practices: What Google, Apple, and the Research Say

The battery myth: 47% is real, and it almost never applies to you

Don't invert — rebuild: what Google's spec actually says

Apple took a different path — and both agree on one rule

Contrast doesn't retire when you go dark

Type, images, and the ten small things

Respect the user: give them the switch, then listen to the data

What to do this week

References

How to Fix a CORS Error (Without Disabling Security)

Your request already worked. That's the confusing part.

Step 1: find out which response is actually broken

Step 2: the five headers that matter, and the two traps

Step 3: when you can't touch the server

The takeaway

References

Python 3.15: What's New and How to Upgrade Without Breaking Your Project

Lazy imports: the headline, and the reason we're on rc3

Two new builtins you'll actually use

The quiet behavior change: UTF-8 by default

Faster — in increments that add up

What to do before Friday

Related reading