DEV Community: Futong Dong

Halloween Dev Horror: 5 micro stories with protective charms

Futong Dong — Sat, 31 Oct 2026 01:13:33 +0000

Happy Halloween. Scarier than ghost stories: 5 micro horror stories that could actually happen. Three sentences each.
Night 1, "The Window": Two terminals open — staging and production. You hit Enter. Then you read the window title. Charm: color-code production; double-confirm dangerous commands.
Night 2, "The Space": You meant to delete ./build. You typed rm -rf . /build. Charm: ls first to see what you're deleting; protect and back up key directories.
Night 3, "The Backup": Every night, the backup said "success". Then you needed to restore. The files were empty. Charm: a backup only counts if you can restore it — practice. In 2017 GitLab accidentally deleted a production database, several backup methods failed, and about 6 hours of data was lost; their public post-mortem is still required reading.
Night 4, "The Key": 3 a.m., a cloud billing alert with extra zeros. You remember the config file you pushed to a public repo yesterday. Charm: scan commits for secrets; if leaked, revoke and regenerate immediately.
Night 5, "Friday": 5 p.m. Friday. "It's one line, quick deploy." Charm: …just don't.
3 everyday guardrails: preview before you run anything dangerous; actually restore a backup now and then; keep keys out of repos.
When AI can run commands for you, install guardrails first: BFBT Code's Hooks can require checks before risky steps, and DTworkeasy lets you stop things from your phone.
Which story gave you chills? Got one of your own?

War of the Worlds · Oct 30, 1938 — 4 engineering lessons from a false alarm

Futong Dong — Fri, 30 Oct 2026 01:50:15 +0000

Eighty-seven years ago tonight, Orson Welles aired a radio drama of H. G. Wells’s The War of the Worlds on CBS.

Many listeners tuned in late, missed the “this is a play” disclaimer, and treated a Martian invasion as breaking news. Panic moved by phone and sidewalk — not because aliens arrived, but because alert channels, trust, and pacing failed together.

Read it as a production-alert incident and you get four takeaways:

Alerts must carry a verifiable source
News-style delivery without a stable byline fools people. If an on-call page looks like noise, it gets ignored; if it looks authoritative but can’t be traced, it gets trusted wrongly. Signatures, routing, and runbook links are part of “who I am.”
Late joiners miss the prologue
People who missed the drama disclaimer had no context. Incident channels and scrolling pages are the same: newcomers need a pinned summary, a status page, a timeline.
Rumors cascade faster than the fault
One call to “confirm,” ten people evacuate. Retry storms and chat stampedes amplify the same way. You need breakers: rate-limited notices, flap suppression, a clear current conclusion.
Drill the false positive
Practicing only “real fire” is incomplete. Rehearse how to stop a bad page and how to correct the record in public. Healthy systems run alert drills — they don’t wait for their own panic night.

(Some images are AI-generated.)

What’s the false alarm you remember most — did communication break first, or automation?

Black Tuesday · Oct 29, 1929 — 4 engineering lessons from a cascade crash

Futong Dong — Thu, 29 Oct 2026 14:47:45 +0000

Ninety-six years ago today, the New York Stock Exchange lived through what we now call Black Tuesday.

It wasn’t a single overnight break. The week before had already fallen hard; Black Monday (Oct 28) kept sliding; on the 29th, selling hit like an avalanche. By 1932 the Dow had lost about 89% from its peak. Panic gets the headline, but leverage, chained sell rules, and slow information stacked into a cascade failure.

Read it as a distributed-systems outage and you get four takeaways:

Cascades beat single points
One node can fail; everyone firing the same sell rule at once takes the whole mesh down. Circuit breakers, rate limits, and bulkheads exist to stop stampedes.
Leverage turns a wobble into a disaster
Borrowed money, borrowed size, borrowed confidence — pretty on the way up, lethal on the way down. Retry storms, unbounded queues, and call chains with no backpressure are tech’s version of leverage.
Slow information makes bad decisions
Quotes moved by slips and phones; a half-beat late meant a wrong call. Laggy metrics and fuzzy alerts do the same to on-call engineers. Observability is a brake light, not decoration.
“Looks fine” is often the night before the storm
Healthy systems pressure-test and run failure drills — they don’t wait for their own Black Tuesday to teach the lesson.

(Some images are AI-generated.)

What’s the cascade failure you remember most? Which link broke first?

Looking for Google Play closed testers (DTworkeasy)

Futong Dong — Mon, 26 Oct 2026 12:09:25 +0000

Hi — we need help finishing Google Play’s closed-testing requirement before production.

What we need

About 12 testers with a real Google account and an Android device
Opt into our closed test and stay opted in for about 14 days
Install once from the Play test link (sideloading doesn’t count)

What you’ll do

Reply here or email dtronykode@dtrony.com with the Gmail you’ll use on Play
We’ll add you to the closed-test list and send the official opt-in link
Tap “Become a tester” → install DTworkeasy from Play

About the app
DTworkeasy is an Android work/collaboration app from 成都东复同科技股份有限公司 (Dongfutong Tech). This ask is only for Play closed testing — not a paid campaign.

If you can spare a minute, comment your Gmail or DM. Thank you!

London Ambulance CAD collapse, 34 years on: the costliest “go-live” lesson

Futong Dong — Mon, 26 Oct 2026 01:34:20 +0000

A picture first.

On 26 October 1992, the London Ambulance Service put a new computer-aided despatch (CAD) system live across the city. Paper backups were removed. Controllers were told to lean on computer-generated allocations. The system was supposed to be faster and more accurate — within hours it drowned in delays, duplicate dispatches, and scrolling exception messages.

It wasn’t a simple “the computer crashed.” The official inquiry was blunt: the software was incomplete and under-tested; hardware resilience under full load hadn’t been proven; fallback to a second server hadn’t been tested; vehicle status and location data were unreliable; staff weren’t fully trained; and the control-room layout changed the same day, making mutual cover harder. Technically the system often “did what it was designed to do” — but the design assumed near-perfect live data. The real world doesn’t. Imperfections stacked until the service failed as a system. Semi-manual workarounds returned; around 4 November the system locked up for good.

Three reminders for anyone shipping software — or agents — into the real world:

💡 “Demo-ready” ≠ “production-ready.” Green checks in a demo don’t survive dirty data and peak load.
💡 Fallback is a feature. An untested rollback is no rollback. Paper backup, human override, and degrade modes are product, not afterthoughts.
💡 Automation must not erase judgment. When data goes bad, “more automatic” means “wrong faster.” Keep confirmation and override in the design.

Ever lived through a go-live that went sideways? Drop a lesson in the comments — not to scare, but to ship safer next time.

Windows XP turns 25: that green hill, and 3 lessons on product longevity

Futong Dong — Sun, 25 Oct 2026 01:21:46 +0000

A picture first.

On October 25, 2001, Microsoft announced the worldwide availability of Windows XP in New York. Bill Gates called it a new era of personal computing. For millions of people, the memory is simpler: that green hillside wallpaper, blue sky, white clouds — the desktop that felt like home.

The wallpaper is called Bliss, a real Napa Valley hillside. It wasn’t a feature checklist. It was a feeling: sit down, stay a while.

XP’s retail launch was October 25, 2001. It powered internet cafés, school labs, and office PCs for years. Mainstream security support finally ended in April 2014 — a long life for consumer software. Longevity wasn’t a slogan; it was “install it and get work done.”

Three takeaways for builders:

💡 Make the default gentle. Bliss wasn’t a feature — it was emotion. The first screen decides whether people stay.
💡 Compatibility is harder than flash. XP lasted because it met the messy real world of old apps and hardware.
💡 Lifespan is earned by use. Long-lived products are the ones users refuse to leave — not the ones you refuse to retire.

Was XP your first “real” computer? Drop a memory of that hill — or the first app you installed.

AI this week (Oct 19–25): OpenAI & Claude on Google Cloud, Agent Skills to AAIF, Decisions API GA

Futong Dong — Sat, 24 Oct 2026 09:41:54 +0000

AI this week (Oct 19–25, 2026): where you buy frontier models — and where agent standards live.

OpenAI on Google Cloud (Oct 21) — Frontier models and Codex workflows enter Google Cloud Model Garden via Marketplace; GA in the coming weeks. Google Cloud names GPT-6 Astra, GPT-6.1 Sol, and GPT-6 Luna in private preview. Microsoft remains OpenAI’s primary cloud partner.
Claude on Google Cloud (Anthropic managed) GA (Oct 22) — Full Claude Platform with GCP IAM, billing, and commitment drawdown; Google-managed Claude remains available.
Agent Skills donated to AAIF (Oct 22) — Anthropic hands the open standard to the Linux Foundation–directed Agentic AI Foundation; 70+ platforms, ~1M skills, ~280M installs (per Anthropic).
Decisions API GA (Oct 22) — GPT-6 Luna for bounded answers (probability / choice / score); up to 400 questions per request; ~$0.10 / 1M input tokens, no output-token charge.
US DHS DeepSeek exclusion (published Oct 20) — Federal civilian agencies must exclude and remove DeepSeek and affiliated products, including third-party products built with DeepSeek; DoD is outside this order.

A distribution-and-governance week more than a new-flagship week. Which story matters most for your stack?

(Some images are AI-assisted. Facts checked against primary sources.)

Bill Gates turns 71: the 19-year-old who promised BASIC before writing a line — and 3 takeaways

Futong Dong — Sat, 24 Oct 2026 00:02:58 +0000

A story first.
In early 1975, 19-year-old Bill Gates and his friend Paul Allen saw the Altair 8800 computer kit on a magazine cover. They called the maker and said they had a BASIC that ran on it — before they'd written a line of code.
They then worked around the clock for about eight weeks. Allen flew out to demo it; reportedly it was the first time the program ran on real hardware, and it worked on the first try.
That April they founded Microsoft, and later set out a vision that sounded almost absurd at the time: a computer on every desk and in every home.
Gates was born in Seattle on Oct 28, 1955. He turns 71 today.
3 takeaways:
• Spot the trend early: they bet on software when personal computers had barely appeared.
• Say yes — then deliver: the bold claim only worked because of eight weeks of hard work. (Maybe don't try "promise first" at home.)
• Make time to think: Gates has long taken "Think Weeks" to read and reflect.
Then it was a computer on every desk. Now it may be an AI partner on every computer.
Who's the most influential tech figure for you?

(Some images are AI-generated.)

What "bring your own API key" actually means (6 Q&As)

Futong Dong — Fri, 23 Oct 2026 02:23:50 +0000

"Where's your key?" Confused the first time an AI tool asked? 6 quick Q&As:

Q1 What's an API key? A credential from a model provider. The tool uses it to call the model for you; usage is billed to your own account. Think of it as your wallet key.

Q2 How is it billed? Most platforms charge by tokens — roughly "by the word", both what you send and what comes back. Prices vary; check the provider.

Q3 Why "bring your own"? Pick any model, see exactly what you spend, and keep your tool when models change.

Q4 How do I keep it safe? Never post it in chats, screenshots or public repos; use separate keys per purpose; check usage regularly.

Q5 Think it leaked? Revoke it, create a new one, and check recent usage.

Q6 Beginner tip? If your provider supports spending limits or alerts, start with a small one.

What tripped you up when setting up a key?

(Some images are AI-generated.)

Programmer's Day Eve: a 4-panel comic + 10 classic quotes

Futong Dong — Fri, 23 Oct 2026 02:22:44 +0000

Happy Programmers' Day! Why Oct 24? Because 2^10 = 1024, and 1 KB = 1024 bytes.

A 4-panel comic:

5:55 p.m. — Wang closes his laptop: "Leaving on time today!"
5:58 p.m. — Team chat: "You there? Small issue in production."
He quietly puts his bag down and opens the laptop.
1 a.m. — Found it: an extra space in a config file.

Sound familiar?

10 classic dev quotes — how many have you said?

"Works on my machine."
"The requirement is simple; how you build it is your problem."
"It's not a bug, it's a feature."
"Just one more fix, then I'm off." (3 hours later)
"Who wrote this mess?" (git blame: me)
"Ship now, optimize later."
"The code is the documentation."
"I only changed one line."
"Have you tried restarting?"
"Let's deal with it tomorrow."

One genuinely useful tip: every time a late night uncovers a gotcha, spend 3 minutes writing it into the team docs — symptom, cause, fix. Next time someone hits "the extra space", it's a 5-minute fix.

Zero bugs, frozen specs, home on time! Which quote is yours?

(Some images are AI-generated.)

The first "actual" bug was a moth: 4 debugging steps that still work

Futong Dong — Thu, 22 Oct 2026 01:36:39 +0000

Why do we call software problems "bugs"? Part of the story involves a real moth.

On September 9, 1947, Harvard's Mark II computer malfunctioned. Engineers traced the fault to a relay, found a moth stuck inside, taped it into the logbook and wrote: "First actual case of bug being found."

That logbook page is now at the Smithsonian's National Museum of American History. Computing pioneer Grace Hopper, who worked on the team and later helped drive the creation of COBOL, made the story famous.

The fun twist: "bug" already meant a fault long before 1947. Edison used the word in the 19th century. So the note was an engineer's joke: this time it was an actual bug.

Debugging still follows the same four steps:

Reproduce it reliably. "Sometimes it happens" is the hardest bug to catch.
Narrow it down by halves, like a guessing game.
Write down what you find, just like that logbook page.
Verify the fix. Run it again and confirm it is really gone.

Bonus: rubber-duck debugging. Put a rubber duck on your desk and explain your code to it line by line. Halfway through, you often spot the problem yourself. The trick comes from The Pragmatic Programmer, and it is ridiculously simple, but it works.

What's the weirdest bug you've ever caught?

(Some images AI-generated)

MCP Explained: The Travel Adapter for AI

Futong Dong — Wed, 21 Oct 2026 00:47:45 +0000

One of travel's small headaches: every country has different sockets, and your bag fills up with adapters. AI used to be like that.

MCP (Model Context Protocol) is an open protocol released in November 2024 that standardizes how AI apps connect to tools and data.

The math: 5 AI apps and 10 tools without a standard need 5 × 10 = 50 custom connectors. With MCP, each tool becomes one server and each app supports MCP once: 5 + 10 = 15. Multiplication becomes addition.

Once connected, AI can read folders you choose, query databases, drive a browser, and work with calendars and notes.

3 safety habits: connect only trusted servers; grant only what's needed (one folder, not your whole drive); review and remove unused connections.

MCP turns AI from "can chat" into "can do", and that makes permissions matter more. Which tool would you plug in first?

MCP #AI #explainer

(Some images AI-generated)