DEV Community: Marvin Tang

Building a browser-first PHP tools directory without pretending everything is offline

Marvin Tang — Sun, 13 Sep 2026 11:55:05 +0000

Kitset is a PHP-rendered directory that currently exposes 423 small browser tools. The interesting engineering problem was not adding one more calculator. It was deciding, for every tool, which work belongs on the server, which work belongs in the browser, and what the offline promise should actually mean.

Here is the boundary I ended up using.

1. Let PHP own discovery, not the user's working data

The server renders stable routes, titles, descriptions, categories, related tools, and the component configuration for each page. That gives every tool a predictable URL and keeps navigation usable before the interactive code mounts.

The tool itself is selected by a small component key and a JSON configuration. On the client, a registry mounts the matching module:

Kitset.register('gsc-workspaces', init);

function init(el, config) {
  if (config.mode === 'seo-launch-kit') seoWorkspace(Kitset, el);
}

That split matters. PHP does not need the title or meta description a visitor is drafting. It only needs to deliver the page and the code that can do the work.

2. Make privacy claims at tool level

For the SEO Launch Kit, the browser reads four fields: page title, site name, page URL, and meta description. A click handler builds a SERP preview, a robots.txt starter, a sitemap entry, and a WebPage JSON-LD object. There is no request in that calculation path.

The same pattern works for many text, calculation, and file utilities: use browser APIs, keep the working value in memory, and offer copy or download only after the result exists.

But I avoid turning that into a blanket architecture claim. Some utilities may need a remote URL, an API route, or a browser capability that is unavailable on a particular device. The public rule is narrower: inputs stay on the device whenever the task allows it. Each tool still needs its own review.

3. Treat the service worker as a cache policy, not a magic offline switch

Kitset precaches a small shell: the home page, the tools directory, My Kitset, core CSS and JavaScript, and icons. It does not precache 423 tool pages.

The fetch handler also has explicit boundaries:

if (request.method !== 'GET') return;
if (url.origin !== self.location.origin ||
    url.pathname.indexOf('/api/') === 0) return;

Static assets use a cached response when available while refreshing from the network. Navigations are network-first and fall back to a previously cached page, then to the home shell. That means an already visited route may remain useful during a connection failure. It does not mean the entire catalog is available on first install.

This wording is less exciting than “works fully offline,” but it survives inspection.

4. Keep local persistence equally bounded

Favorites, recent tools, and remembered setups use localStorage. The shared helper cleans URLs and limits stored collections. Result text is not sent through analytics; only an allowlist of aggregate event fields can reach gtag when it is present.

LocalStorage is convenience, not durable storage. It may be unavailable, cleared, or shared with anyone using the same browser profile. The UI therefore treats saved state as optional and keeps copy/download as the explicit handoff.

A checklist I now use

Can the task run entirely with browser APIs? If not, name the remote dependency.
Does any input cross the network? Verify the actual event path, not only the page copy.
What is precached, runtime-cached, or deliberately bypassed?
Does an offline claim describe a visited route or the whole product?
What is kept in memory, localStorage, a download, or a server database?
Can a user understand those boundaries without reading the source?

The main lesson is that “browser-first” is not one implementation technique. It is a collection of narrow, testable decisions. Server-rendered discovery, client-side work, bounded local persistence, and a conservative cache policy can coexist—as long as the product copy does not collapse them into a promise the code cannot keep.

A Good AI Workflow Brief Needs More Than a Prompt

Marvin Tang — Tue, 08 Sep 2026 09:17:49 +0000

Most AI workflow failures do not begin with a bad model response. They begin one step earlier, when a vague request is treated as a complete specification.

“Summarize these notes.”

“Research our competitors.”

“Update the project.”

Each sentence sounds actionable. None tells an AI system what evidence it may use, what it must not do, who reviews the result, or what would make the output acceptable.

A prompt can describe a task. A workflow brief defines the operating boundary around that task.

That distinction matters as soon as AI work touches real files, current facts, customer data, source citations, code, or external systems. In those settings, fluent output is not the same as a verified result.

The prompt is only one layer

A useful AI workflow has at least five controls:

A specific outcome
An evidence boundary
A data-safety boundary
A named review owner
Observable acceptance checks

These controls do not make a model infallible. They make errors easier to detect and responsibility harder to blur.

Consider this request:

Turn our meeting notes into a weekly project update.

An assistant could produce a polished update and still be wrong in several ways. It might infer that an unfinished feature shipped, silently combine old and new notes, omit an unresolved blocker, or phrase a proposal as an approved decision.

The problem is not prose quality. The problem is that the request leaves critical decisions unstated.

1. Define the outcome, not just the activity

“Summarize the notes” describes an activity. It does not describe the result someone needs.

A stronger outcome might be:

Produce a weekly status update for the product lead that separates completed work, current blockers, decisions needed, and next-week commitments.

This version names the audience and the decisions the output should support. It also gives the reviewer a basis for rejecting material that is interesting but irrelevant.

When writing the outcome, ask:

Who will use the result?
What decision or action should it support?
What shape should the result have?
What is explicitly outside scope?

2. Draw an evidence boundary

An AI system needs to know whether it should use only supplied material, rely on general knowledge, or conduct fresh research.

These are different operating modes:

Supplied sources only: Appropriate when the output must remain traceable to a controlled set of documents.
General knowledge with citations: Useful for background explanation, but claims that may have changed still need verification.
Fresh research required: Appropriate when current facts matter and the workflow includes source collection and citation.
Creative work with factual constraints: Allows invention in the presentation while preserving named facts, claims, or brand rules.

Without this boundary, a model may fill gaps with plausible material. That can be useful during brainstorming and dangerous in a status report, compliance review, or customer-facing document.

Evidence rules should also say what to do when information is missing. “Mark as unknown and list the missing source” is usually safer than “make a reasonable assumption.”

3. Name forbidden actions

Constraints often describe formatting: word count, tone, language, or file type. A workflow also needs to identify actions that would create risk.

Examples include:

Do not claim that work was approved, deployed, sent, or published without direct evidence.
Do not modify source files.
Do not contact customers or teammates.
Do not infer demographic or medical attributes.
Do not include secrets, private keys, or personal identifiers in the output.
Do not invent metrics to complete an empty field.

Why state the obvious? Because an automated system is often rewarded for completing the apparent task. If “complete the report” conflicts with “leave unsupported fields blank,” the safer behavior must be explicit.

A good forbidden-action list focuses on plausible shortcuts, not every imaginable mistake.

4. Separate preparation from approval

AI workflows often collapse three different states:

A draft exists.
The draft passed checks.
An authorized person approved its use.

Those states are not interchangeable.

For a code change, a patch can exist without tests passing. Tests can pass without a maintainer approving a merge. For an article, a draft can be complete without being published. For a business report, numbers can be checked without an executive approving the recommendation.

The brief should name a review owner and define the approval boundary. “Reviewed by the product lead before distribution” is much clearer than “review before use.”

Naming the role is usually enough. Naming the person is even better when the workflow is already assigned.

5. Use checks that can fail

“High quality,” “accurate,” and “professional” sound like success criteria, but they are difficult to test.

Useful acceptance checks are observable:

Every completed item links to an issue, pull request, or retained source note.
Every metric includes its date range and source.
Unresolved disagreements appear in a separate section.
No item is labeled shipped unless release evidence is present.
The final document stays under 600 words.
A named reviewer signs off before distribution.

If a check cannot fail, it probably will not control the workflow.

A compact workflow-brief schema

The brief does not need to be long. It needs to make the important boundaries explicit.

goal: >
  Produce a weekly project update for the product lead,
  separating completed work, blockers, decisions, and next steps.

audience: Product lead and engineering lead
review_owner: Project manager

inputs:
  - Approved meeting notes from this week
  - Current issue tracker export
  - Release log for the reporting period

evidence_boundary: Use supplied sources only
data_safety: Public or approved non-sensitive project data
consequence_level: Medium; review required before distribution

forbidden_actions:
  - Do not infer completion from an optimistic comment
  - Do not mark a feature shipped without release-log evidence
  - Do not invent owners, dates, or metrics
  - Do not send or publish the update

output:
  format: Markdown
  sections:
    - Completed
    - Blocked
    - Decisions needed
    - Next week

success_criteria:
  - Every completed item has a retained source reference
  - Conflicting evidence is shown rather than silently resolved
  - Unknown dates and owners remain explicitly unknown
  - The review owner approves the draft before distribution

Notice what is absent: elaborate role-play, motivational language, and a claim that one perfect prompt will solve the problem. The brief is closer to a small interface contract than a piece of persuasive writing.

A six-question preflight

Before running an AI workflow, answer these questions:

Is the desired outcome specific enough to reject irrelevant output?
Is the evidence source retained and clearly bounded?
Is sensitive data excluded or handled in an approved environment?
Are dangerous shortcuts explicitly forbidden?
Is one person or role responsible for review?
Are the success checks observable?

If one answer is missing, the best next action may be to improve the brief instead of running the workflow.

I built a free AI Workflow Brief Builder to make this preflight concrete. It runs in the browser, has no model connection, and exports the resulting brief as Markdown or JSON. You can also implement the same structure in a form, issue template, or internal runbook.

The important part is not the tool. It is the discipline of treating AI work as a bounded process with evidence, permissions, review ownership, and checks.

The practical payoff

A workflow brief will not eliminate model errors. It does something more operationally useful: it changes errors from vague surprises into detectable contract violations.

When a draft makes an unsupported claim, you can point to the evidence boundary. When an agent tries to take an external action, you can point to the forbidden-action list. When a polished output is mistaken for an approved one, you can point to the review owner and approval gate.

Better prompting helps an AI produce better text. Better workflow boundaries help a team decide whether that text can be trusted and used.

Disclosure: I built the linked AI Workflow Brief Builder. It is free to use and does not require an account.

I stopped writing content and started building tools. Here's the logic

Marvin Tang — Sun, 21 Jun 2026 07:56:21 +0000

A few months ago I stopped writing new content for most of my sites. Not because the writing was bad, but because I watched the traffic curve long enough to realize I was building for a search engine that had quietly changed the deal.

If you've searched for anything practical lately, you've seen it. You type a question, and the answer is already there — the AI Overview sits at the top of the page, pulls a response out of three or four sources, and you never click through. For a lot of queries, the click was the business model. Now it's gone.

The interesting part isn't that this is happening. It's which pages it happens to.

The asymmetry

An AI Overview is very good at collapsing an answer into a paragraph. "How many tablespoons in a cup." "Difference between let and const." "Best time to visit Kyoto." These are knowledge queries — the value is in knowing something, and a model that has read the whole web can hand you the knowing without the visit. If your page's job was to be the thing that knows the thing, you're now competing against a summary of yourself, shown above you, for free.

But there's a category the summary can't touch: queries where the value is in the doing, not the knowing.

"Format this 4KB of minified JSON." "Count the words in this draft." "Convert these 200 lines to snake_case." You can't satisfy any of those with a paragraph at the top of a results page. The user has data, and they need an interface to do something to it. The answer isn't information — it's a transformation, and the thing they want doesn't exist until they paste their input in. There's nothing for an Overview to summarize ahead of time.

That's a real moat, and a weird one, because it has nothing to do with how good your content is. It's about whether your value survives being described.

What I'm doing about it

So I've been running a small experiment around this idea — a hub of single-purpose browser tools at kitset.app, each one doing exactly one boring thing: a word counter, a JSON formatter, a case converter. No accounts, no uploads, everything client-side. The thesis I'm testing is plain: tools that depend on the user's own input are roughly immune to the "answer shown above the link" problem in a way that even very good articles are not.

Early read — it's holding up better than the content sites. But it's too soon to call a win, and there's an obvious counterargument I don't have a clean answer to: a single-purpose tool is also trivially easy for anyone (including the AI) to generate, so any individual tool has roughly zero defensibility. The moat is at the category level, not the tool level. I'm still chewing on that one.

What I'd take from it

A few things, if you build for the open web:

"Will this still earn a click in two years" is now a design question, not just a marketing one. If a page's entire value can be lifted into a snippet, assume it eventually will be.
Interaction is the cheapest available hedge. Anything that takes the user's input and returns a transformation has a property pure content doesn't: it can't be answered in advance.
This isn't a reason to stop writing. It's a reason to be honest about which pages are content and which are tools, and to stop expecting the first kind to behave like the second.

None of this is a grand strategy. It's mostly me reacting to a graph going down and trying to build the thing the graph can't eat. But the shift underneath it feels real, and I suspect more of us will be making this trade over the next couple of years.

I Rewrote One AI Prompt 15 Times to Kill the "AI Smell" in Product Reviews

Marvin Tang — Fri, 05 Jun 2026 03:43:36 +0000

You can smell an AI-written product review from the first sentence. "In today's fast-paced world, finding the right product can be a game-changer." Nobody talks like that. Nobody who has actually used a slow-feeder bowl for three months opens with a thesis statement.

I run a pet-gear review site, and I wanted to use AI to speed up drafting without producing that. What I found is that the prompt is the entire job. I ended up rewriting one review-drafting prompt around fifteen times, and the interesting part wasn't getting the AI to write more — it was getting it to write less like an AI. Here's what actually moved the needle, and the hard ceiling I kept hitting.

Why the first prompt failed

The naive version is the one everyone starts with:

Write a review of [product]. Make it sound natural and helpful.

What comes back is fluent and completely hollow. It has the shape of a review with none of the substance: sweeping adjectives, zero specifics, a conclusion that could apply to any product in the category. "Make it sound natural" does nothing, because the model's default register already is what it thinks natural sounds like — and its idea of natural is a marketing brochure.

The problem isn't fluency. The model has plenty. The problem is that generic prose is its lowest-energy output, and a vague prompt lets it sit there.

What actually worked

The fixes were all about removing the model's room to be generic.

A banned-phrase list. I keep an explicit blocklist in the prompt — "game-changer," "in today's world," "look no further," "when it comes to," "elevate your," "whether you're a... or a..." Naming the clichés is far more effective than asking for "no clichés," because the model can't reliably detect its own tells; it can follow a literal list.

Forced structure with required slots. Instead of "write a review," the prompt demands specific components: the use case it's actually for, who it's not for, and at least one concrete drawback. The single biggest jump in believability came from forcing a real negative. Reviews with no downside read as ads; humans instinctively distrust them. A required "here's what annoyed me" slot breaks the brochure tone instantly.

Specificity over judgment. I forbid bare evaluations. The model can't write "it works great" — it has to write under what conditions it behaves how. "Great for a strong puller" is a claim; "it works great" is filler. Forcing the conditional drags the text toward something testable.

Constrained voice and density. First person, restrained, no encyclopedia tone, no summarizing the entire product category before getting to the point. I cap how much throat-clearing it's allowed before the first concrete observation.

Each of these is a small rule. Stacked together, they pull the output out of brochure-land and into something that at least reads like a person wrote it.

(For the mechanical drafting I leaned on Claude — it's good at following a strict, rule-heavy prompt like this. The prompt design was the work; the generation was the easy part.)

The ceiling no prompt gets past

Here's where I have to be honest, because it's the whole point.

Every technique above improves how the review reads. None of them improves whether it's true. You can make AI text sound like a person who used the product for three months. You cannot make it into a person who used the product for three months.

The things that make a review actually worth reading — how it held up after real use, the specific way it failed that the product page never mentions, the exact measurement, the photo of the thing dirty and dented on your kitchen floor — the model doesn't have any of that. If you let it fill those gaps, it invents them, and now you're not writing a thin review, you're writing a confidently false one. That's worse.

So the line I settled on: AI drafts and structures; a human supplies the experience. The prompt produces a clean, specific, human-sounding skeleton. Then someone who has actually handled the product fills in the parts only use can produce — and cuts anything the draft asserted that isn't true. On a pet site especially, where people make decisions that affect an animal's health, getting that division wrong isn't a style problem.

This also happens to line up with where search is going. Google's "helpful content" push is explicitly hunting for first-hand experience and demoting content that's generated to rank. A pile of fluent, experience-free reviews is exactly the target. The fluency was never the moat. The experience is.

That's the workflow behind pawpry.com — AI for the draft, a real person for the parts that matter. The prompt engineering got me a better starting line, not a finish line.

The takeaway

If you're using AI to draft content, spend your effort on the prompt, not on editing the output into shape afterward — a good prompt prevents the AI smell, late editing only masks it. But know exactly what the prompt can and can't buy you. It buys readability. It does not buy experience, and the moment you ask it to fake experience, you've built the thing everyone — readers and search engines alike — is learning to filter out.

Solo indie dev, writing these up as I go. If you've found prompt tricks that kill the AI tone, I'll take them — and I'm curious where everyone else draws the human-in-the-loop line.

From ASP.NET + MSSQL to PHP + MySQL: Migrating a Names Site Without Mangling the Accents

Marvin Tang — Sat, 30 May 2026 13:05:41 +0000

My baby-name site started life on ASP.NET with a MSSQL backend. It worked. The reason I rewrote the whole thing in PHP + MySQL had nothing to do with the code being bad — it was everything around the code.

This is the migration writeup: why I left a stack that was technically fine, the MSSQL → MySQL gotchas that actually cost me time (the worst one was thematically perfect for a names site), and what the new stack let me build that the old one was quietly blocking.

The real reason: hosting, not code

ASP.NET is a perfectly good framework. The problem is its habitat. For a solo dev shipping small sites:

Windows hosting is scarce and pricier. The cheap, plentiful end of the hosting market is overwhelmingly Linux/LAMP. Windows + IIS plans are fewer, cost more, and the budget ones I could find were the least stable.
The servers were worse. More downtime, slower support, fewer knobs I was allowed to touch.
Changes were awkward. Deploying and tweaking a .NET app on shared Windows hosting was consistently more friction than scp + a PHP file on a LAMP box.

PHP + MySQL inverts all three: hosting is everywhere, it's cheap, the quality bar at the same price is higher, and extending the site later is far less ceremony. For a content/data site I plan to keep adding to, "easy to extend on cheap, stable hosting" beats "technically elegant on expensive, fragile hosting" every time.

So the port was a means to an end. The end was the database.

The schema migration: MSSQL → MySQL

A names site is mostly database. The dictionary is ~19,862 names; the popularity layer is 63,890 US Social Security Administration records spanning 1880–2024; the geographic layer is ~6.5M state-level rows. Porting that is where the work lived.

The type and syntax mapping that mattered:

MSSQL                      ->  MySQL
-------------------------------------------------------
INT IDENTITY(1,1)          ->  INT AUTO_INCREMENT
NVARCHAR(n)                ->  VARCHAR(n)        (utf8mb4)
NVARCHAR(MAX)              ->  TEXT / LONGTEXT
BIT                        ->  TINYINT(1)
DATETIME2                  ->  DATETIME
GETDATE()                  ->  NOW()
ISNULL(x, y)               ->  IFNULL(x, y) / COALESCE
LEN()                      ->  CHAR_LENGTH()
[bracketed].[columns]      ->  `backticked`.`columns`
SELECT TOP 10 ...          ->  SELECT ... LIMIT 10
... OFFSET n FETCH m       ->  ... LIMIT m OFFSET n
a + b   (string concat)    ->  CONCAT(a, b)

None of these is hard individually. The cost is that they're scattered through every query and stored procedure, so a "find and replace" mindset misses things — especially string concatenation with +, which silently becomes numeric addition in MySQL instead of erroring.

The collation trap (where the accents died)

Here's the one that bit me, and it's almost funny that it happened on a names site of all things.

Names are full of non-ASCII characters: José, Zoë, Renée, François, Søren. The original MSSQL database stored these fine under its own collation. When I did the first bulk import into MySQL, a chunk of names came back as Jos?, Ren?e, or worse — mojibake like JosÃ©.

Two separate things were wrong:

The column character set. Defaulting to utf8 in MySQL is a trap — historical MySQL utf8 is only 3 bytes and can't store the full Unicode range. The correct choice is utf8mb4 with a utf8mb4_unicode_ci (or 0900_ai_ci) collation, end to end: table, connection, and client.
The import encoding. Exporting from MSSQL and loading into MySQL without pinning the encoding on both sides re-interpreted the bytes. The fix was exporting as UTF-8 explicitly and telling LOAD DATA INFILE the same with CHARACTER SET utf8mb4.

The lesson I'd tattoo on past-me: set utf8mb4 on the database, the table, and the connection (SET NAMES utf8mb4 / PDO charset=utf8mb4) before importing a single row. Fixing encoding after the data's already mangled means re-importing from source, because you can't always tell a correctly-stored é from a double-encoded one after the fact.

Moving 6.5M rows

For the bulk data — especially the state-level records — row-by-row inserts were a non-starter. The path that worked:

Export each MSSQL table to UTF-8 CSV.
LOAD DATA INFILE into MySQL with the charset pinned, indexes added after the load (building indexes during a multi-million-row insert is dramatically slower).
Spot-check a sample of accented names against the source before trusting the whole load.

The app layer

The PHP rewrite itself was the least surprising part. Data access went from ADO.NET to PDO with prepared statements (parameterized everywhere — a data site is a giant SQL-injection surface if you're lazy). Paging went from OFFSET/FETCH to LIMIT ... OFFSET. The routing and templating got rebuilt but conceptually mapped one-to-one.

I'll be honest that I leaned on Claude to accelerate the mechanical parts of the port — translating stored-procedure logic and grinding through the query rewrites. It's good at the tedious 1:1 translation; the judgment calls (the collation decision, the index-after-load ordering) were still mine to get wrong first.

What the new stack unlocked

Here's the payoff, and the reason the migration was worth it. On the old stack, every new feature was a fight with the hosting. On PHP + MySQL, adding to the site got cheap enough that I could turn a static name dictionary into something closer to a data product:

Query-driven tools straight off the SSA tables — popularity by birth year, year-over-year trending movers, a name → US-state lookup over those 6.5M rows, side-by-side comparison of two names across 145 years.
Research reports generated from the same dataset — decade-by-decade breakdowns, per-state rankings, long-arc analyses like which mid-century names have effectively gone extinct.

None of that was impossible on the old stack. It was just expensive and annoying enough that I never did it. That's the quiet cost of a high-friction stack: not the features you can't build, but the ones you don't bother to.

You can see where it landed at 9babynames.com. The migration is invisible to visitors — which is exactly the point.

Solo indie dev, writing these up as I go. If you've done a MSSQL → MySQL move, I'm curious whether the collation/charset step bit you too, or whether I just walked into it.

I Cloned My Dog-Name Site to Build a Cat-Name Site. The Routing Layer Bit Back.

Marvin Tang — Wed, 27 May 2026 07:36:06 +0000

I run a dog-name site. A few weeks ago a reader emailed asking the obvious question: "Do you have one for cats?"

I didn't. But I had a fully built PHP content site sitting right there — browse names by breed, by origin, by color, by size; a name-detail page for every entry; clean URLs all the way down. Cats are just dogs with a different attitude and a smaller breed list, right? I figured I'd clone the whole thing in an afternoon.

It did not take an afternoon. And the part that ate the time wasn't the data or the templates — it was the routing layer. This is the story of what doesn't copy over when you "just clone" a content site, written down so the next person (or future me) doesn't repeat it.

The shape of the thing

Both sites are plain PHP — no framework. Every page is a file under pages/, and a clean URL gets rewritten to it with a query string. So /breeds/letter/a/page/2 becomes pages/breeds.php?letter=a&page=2. Nice URLs for users and search engines, ordinary PHP underneath.

The catch is that the rewrite has to happen in two completely different places, because the site runs in two completely different environments.

In production it's Apache, so the rules live in .htaccess:

# /breeds, /breeds/letter/{a}, /breeds/page/{n}
RewriteRule ^breeds(?:/letter/([a-z]))?(?:/page/(\d+))?/?$ pages/breeds.php?letter=$1&page=$2 [L,QSA,NC]

Locally I develop with PHP's built-in server (php -S localhost:8080 router.php), which knows nothing about .htaccess. So the same route has to exist again, as a preg_match in router.php:

if (preg_match('#^/breeds(?:/letter/([a-z]))?(?:/page/(\d+))?/?$#i', $uri, $m)) {
    $_GET['letter'] = $m[1] ?? '';
    $_GET['page']   = $m[2] ?? '';
    require __DIR__ . '/pages/breeds.php';
    return true;
}

One logical route, two physical definitions. On a single site that's already a low-grade tax: every time I add a route I edit two files and keep two regexes in sync. It works, I'd made my peace with it.

Cloning doubled the tax into something worse

Here's the thing I didn't think through before I copied the folder. The site has dozens of routes — name detail, categories, the dictionary, search, comparison pages, a pile of 301s for legacy URLs. Each one already lived in two places. Clone the site, and now every route lives in four places, across two repos.

The first time I added a cat-specific route, I added it to the cat site's .htaccess, tested it on production, and it worked. Then a week later I went to test something locally and got a 404 — because I'd never mirrored that rule into the cat site's router.php. The local and production routing had silently drifted apart. On the dog site I'd trained myself to edit both. On the fresh clone, I hadn't built that muscle yet, and the duplication just quietly rotted.

That's the trap with cloning: you copy the code, but you don't copy the discipline the code silently depends on.

What actually didn't transfer

Beyond routing, a few assumptions I'd hardcoded for dogs leaked through:

Breed counts. The dog site assumes a long breed list with its own pagination thresholds. Cats have far fewer recognized breeds, so pages that were comfortably full on one site looked empty on the other. The layout "worked" but felt broken.
Category vocabulary. "Working dogs," "herding," "guardian" — none of that maps to cats. The category system was generic enough to run with cat data, but the seed categories were dog-shaped, so half of them were nonsense until I redid them.
Copy and microcopy. Every "your new puppy" string. Cloning finds these the hard way, one user-facing typo at a time.

None of these were hard. They were just invisible until real data hit them — which is exactly the kind of thing a clone hides from you, because the code compiles and the page renders. It's the content that's wrong, and content doesn't throw exceptions.

What I'd do instead (and am slowly refactoring toward)

The honest takeaway: I shouldn't have cloned a site. I should have built one engine and two instances.

Concretely, the routing table should be defined once, as data, not twice as code:

// routes.php — single source of truth
return [
    ['pattern' => '#^/breeds(?:/letter/([a-z]))?(?:/page/(\d+))?/?$#i',
     'page'    => 'breeds.php',
     'params'  => ['letter', 'page']],
    // ...
];

router.php loops over that array for local dev. And a small build script can generate the .htaccess rewrite block from the same table for production. One definition, two consumers — instead of four hand-maintained copies. The entity ("dog" vs "cat") becomes a config value: breed list, categories, and copy strings get injected, while the engine stays identical.

I'm not all the way there yet — the cat site shipped on the cloned codebase because shipping beat refactoring. But every route I touch now, I move into the shared table instead of duplicating it. The fork is slowly converging back into an engine.

If you want to see the two instances side by side, the cat site is live at icatnames.com and the original dog site it grew out of is idognames.com — same bones, different animal, and (now) a slowly shrinking amount of duplicated routing.

The lesson in one line

Cloning copies your code but not the invisible discipline it relies on. If a site has any duplicated-but-must-stay-in-sync layer, a clone doesn't double your maintenance — it squares it.

How do the rest of you handle dev-vs-prod routing parity without a framework? I'd genuinely like to hear if there's a cleaner pattern than "generate one from the other."

Cocos Creator 2D Physics on iOS: Notes on Fixed Timestep, ProMotion, and CCD

Marvin Tang — Sun, 17 May 2026 09:56:26 +0000

Cocos Creator's 2D physics looks solid in editor preview. Bouncing balls behave. Collisions trigger. Frame rate sits at 60. Then you ship to iOS, install on an actual device, and small things start to feel off — a ball that occasionally tunnels through a thin wall, gameplay that feels subtly faster on newer iPhones, a stuck collision after the user backgrounds the app and reopens it.

None of these are obvious bugs. They're the result of how the engine's physics interacts with iOS-specific runtime behavior that doesn't show up in desktop testing.

After shipping a 2D physics-based ricochet game built on Cocos Creator 3.x to the App Store, here's the short list of things I'd configure differently if I were starting over.

1. ProMotion silently changes your simulation

iPhone 13 Pro was the first iPhone with ProMotion, and every Pro model since has it. ProMotion means the display refreshes at up to 120Hz. WebViews and native runtime loops driven by CADisplayLink follow that refresh rate, which means requestAnimationFrame — and the Cocos Creator game loop bound to it — can fire up to 120 times per second on these devices.

If your physics integration uses the per-frame delta time directly — velocity += accel * dt; position += velocity * dt — your simulation now runs at a different effective resolution on a 120Hz device than on a 60Hz device. Same starting state, same input, slightly different physical outcome. Players on newer iPhones experience a subtly different game.

The fix is to lock physics to a fixed timestep, decoupled from rendering. In Project Settings → Physics 2D, set the Fixed Time Step explicitly (1/60s is the standard choice):

import { PhysicsSystem2D } from 'cc';

PhysicsSystem2D.instance.fixedTimeStep = 1 / 60;

Rendering still happens at whatever rate the device offers. Physics ticks at 60Hz regardless. Behavior becomes consistent across devices.

2. Don't integrate with variable dt

Even on a constant 60Hz display, the actual frame interval can vary — a thermal-throttled iPhone can drop to 45fps mid-game, or hit 30fps if other apps are competing for CPU. The classic accumulator pattern handles this without breaking the simulation:

const FIXED_DT = 1 / 60;
let accumulator = 0;

update(deltaTime: number) {
  accumulator += deltaTime;
  while (accumulator >= FIXED_DT) {
    this.stepPhysics(FIXED_DT);
    accumulator -= FIXED_DT;
  }
  // Optional: interpolate render position using accumulator / FIXED_DT
}

Cocos Creator's built-in physics system does this internally once you configure a fixed time step. But if you're running any of your own integration — custom forces, custom motion on non-rigidbody entities, gameplay logic that touches positions — apply the same pattern there. The moment any part of your simulation uses raw deltaTime, you've reintroduced the inconsistency you just fixed.

3. CCD is not on by default, and you usually want it

A ball moving at 1000 px/s in a 60Hz simulation moves about 16.7 px per frame. If your wall collider is 10 px thick — or your ball is small and your wall is at an angle — there's a real chance the ball is in front of the wall on frame N and behind it on frame N+1, with no collision detected in between.

Discrete collision detection misses these. The fix is continuous collision detection, which in box2d terms means setting the bullet flag on the rigid body:

const rb = this.getComponent(RigidBody2D);
rb.bullet = true;

Two things to know:

CCD has a real CPU cost. Apply it only to bodies that actually move fast — typically the player projectile, not every dynamic body in the scene.
It only protects against passing through static and kinematic bodies. Two CCD-enabled dynamic bodies can still miss each other under box2d's defaults.

If you have geometry that's both fast-moving and dynamic-on-dynamic, supplement with manual raycasts between frames. Sample the start and end positions, fire a raycast along that segment, snap to the first hit.

4. Touch input lands later than you think

A user taps the screen. The native touch event arrives at the WebView. WebView forwards it to JavaScript. Your input handler runs. Cocos Creator's event system dispatches it on the next tick. Your physics responds on the tick after that.

That's two to three frames of latency between the finger landing and the ball reacting. At 60Hz that's 33-50ms — noticeable in a precision physics game where the player is reading visual feedback to aim.

You can't eliminate the WebView → JS hop, but you can avoid adding more delay:

Don't queue input into a buffer that's drained on the next physics tick. Handle it in the same tick if the input affects current-frame simulation.
For aiming-style mechanics, render a preview of the trajectory the moment the touch starts, and only commit to a physics force on release. The visual responsiveness masks the input lag — by the time the player releases, they've already been seeing what would happen.

5. Background/foreground destroys your physics state

When the user switches to another app and comes back, the JS event loop has been suspended for an arbitrary duration — seconds, minutes, hours. The next update() call receives a delta time that reflects that entire pause.

If you pass that delta unfiltered into your physics step, the accumulator from section 2 runs hundreds or thousands of fixed steps in a single tick. The game freezes for a moment, then resumes with the ball teleported across the level — through walls, past triggers, anywhere.

Two complementary fixes:

// Clamp delta to prevent runaway accumulation
update(deltaTime: number) {
  const safeDt = Math.min(deltaTime, 0.1);
  // ... use safeDt for physics
}

// Pause physics on visibility change
document.addEventListener('visibilitychange', () => {
  PhysicsSystem2D.instance.enable = !document.hidden;
});

The clamp protects you from runaway dt. The visibilitychange handler is cleaner — physics genuinely shouldn't tick when the user can't see the game. Use both.

6. Determinism is fragile, and you probably don't need it

If you ever want replay validation, network sync, or "the same level always plays out the same given the same input," you need deterministic physics. Floating-point math across iOS device generations — and especially across iOS vs Android — is not guaranteed to produce bit-identical results, even with a fixed timestep.

This is solvable: fixed-point math, integer-only simulation, or running physics on a server. Each path is heavyweight.

For most single-player physics games, the right answer is to not need determinism. Save state snapshots instead of replays. Validate completion server-side based on outcomes (level cleared, score reached) rather than exact motion paths. Build replay sharing as a video, not a deterministic simulation.

Pre-ship checklist

Before submitting a Cocos Creator 2D physics game to App Review, I'd now check:

Physics fixed timestep is set explicitly, not left to default
Fast-moving rigid bodies have bullet = true
Input handlers process within the same tick as the affected physics step
deltaTime is clamped, and physics pauses on visibilitychange
Tested on at least one ProMotion device (iPhone 13 Pro or later) and one older device

None of this is obscure. It's just easy to miss when desktop preview looks perfect.

The game these notes come from is Juicy Ricochet — playable in the browser at phyfun.com or as a native iOS build on the App Store. Most of what's above is the result of behavior I didn't see until I was running on a real iPhone in real hands.

Mapping TikTok's 46 Hidden Emoji Codes: A Reverse Engineering Story

Marvin Tang — Fri, 08 May 2026 09:04:05 +0000

A while back I noticed something in a TikTok comment thread that didn't make sense to me. People were typing what looked like emojis I'd never seen in any standard keyboard. A shaking face. A specific cartoon thumbs-up that didn't match the iOS or Android version. A speechless head-tilt.

At first I assumed they were stickers, or some creator-only feature. But the more I scrolled, the more I noticed regular accounts using them in plain text comments. They were typing something. The platform was rendering it as a custom emoji.

What I found over the next two weeks turned into TTEmos — a reference site for TikTok's 46 undocumented hidden emoji codes. This is the technical version of how that worked.

The first lead

The first thing I did was right-click "Inspect" on a comment that contained one of these mystery emojis. The DOM showed an <img> tag pointing to an asset on TikTok's CDN. Nothing unusual there, except that the user had clearly typed plain text into the comment box — the input field had no emoji picker open, and there was no sticker UI involved.

That meant somewhere between the user typing and the comment rendering, TikTok was doing a text replacement.

I went to the DevTools Network tab, posted a test comment with the text [smile], and watched. Two things happened:

The submit request sent the literal string [smile] to the API, with no client-side replacement.
When the comment came back from the server and rendered, the text was gone and an image was in its place.

So the replacement was happening on render, against a known list of codes the platform recognized.

Finding the list

The next step was figuring out where this known list lived. The likely candidates were:

A JS bundle on the web client that did the replacement after fetch
Server-rendered HTML that arrived with the image already in place
A separate config endpoint the client fetched on load

I spent about an hour going through bundled JS files in the Sources tab, looking for anything that mapped a square-bracket-wrapped string to an image filename. After narrowing it down, I found a chunk of code with the structure I was looking for. Roughly (paraphrased — not the literal source):

const EMOJI_MAP = {
  "[smile]":     "/emoji/smile.png",
  "[happy]":     "/emoji/happy.png",
  "[shock]":     "/emoji/shock.png",
  // ...
};

function renderCommentText(text) {
  return text.replace(/\[\w+\]/g, (match) => {
    const asset = EMOJI_MAP[match];
    return asset ? `<img src="${asset}">` : match;
  });
}

Once I had the map, I had the codes. There were 46 of them.

Validation

Having a list extracted from a JS file is a hypothesis, not a confirmed reference. The list could include codes that no longer worked. It could exclude codes that lived in a different code path. I needed to validate every entry on the live platform.

So I made a test account and started typing each code into comments, one at a time. For each code I checked:

Does the code render as an emoji at all?
Is the rendered emoji visually distinct from the others?
Does it render the same way in different contexts (comment, caption, reply)?
Does it survive the Edit flow without breaking?

Most codes passed cleanly. A few were interesting:

Three codes were effectively deprecated — they were in the JS map but rendered as literal text on the live platform.
Two codes had visually identical outputs (they pointed to the same asset).
Some codes had region-specific rendering — they worked normally in some locales but not others.

I documented each of these on the reference site as separate metadata fields.

The reference site itself

Once I had the validated list, the question became how to make it useful.

The temptation with this kind of niche knowledge is to write a long blog post listing everything. That's how most fragments of this list had been published before — buried in Reddit threads, halfway through YouTube tutorials, scattered across screenshots in TikTok comments themselves. The problem is that a blog post is something you read once. People who actually wanted to use these codes needed something they'd come back to dozens of times.

So I built a static site. No backend. No database. One page with all 46 emojis, a search/filter, and a one-click copy button on each one.

The architecture was deliberately boring:

ttemos.com/
├── index.html        # main reference page
├── emojis.json       # the validated 46 entries
└── assets/
    └── *.png         # locally hosted emoji images

A small bit of JavaScript handles search, filter, and copy-to-clipboard:

async function copyCode(code, button) {
  try {
    await navigator.clipboard.writeText(code);
    button.classList.add('copied');
    setTimeout(() => button.classList.remove('copied'), 1500);
  } catch (err) {
    // fall back to a hidden textarea + execCommand for older browsers
    fallbackCopy(code);
  }
}

That's the whole product. The user opens the site, finds the emoji they want, clicks copy, pastes into a TikTok comment. Three seconds.

I hosted my own copies of the emoji-style icons rather than hot-linking to TikTok's CDN. Hot-linking would have been faster to set up but fragile — TikTok could change their CDN paths at any time and the reference site would break overnight without me even noticing.

A note on undocumented features

There's an ethics question hovering over this kind of project worth addressing directly.

Documenting an undocumented but publicly visible feature isn't reverse-engineering an API in the harmful sense. The codes are publicly visible in the product. Users are typing them in plain text. The codes don't bypass any security boundary, don't expose private data, and don't unlock anything that wasn't already accessible.

What I tried to avoid was anything that would cross a line:

I didn't rehost TikTok's actual emoji image assets at scale. The reference site uses my own icons in a similar style.
I didn't build automation that posts to TikTok programmatically.
I didn't document anything else that came up while looking for the emoji map — internal API endpoints, auth flows, anything in that category stayed in DevTools and out of the article.

The goal was a reference. Nothing more.

What I'd do differently

Two things, looking back:

Build the validation harness first. I validated codes one by one manually, which took hours. If I were starting again, I'd write a small test script that takes a list of candidate codes, posts each one to a throwaway test account, and reports back which render and which don't. The platform makes that easy because the rendered output is in the DOM after submission.

Track the source of each code. Some codes came from the original JS map, some came from community Reddit threads I cross-referenced, and a few I discovered by trying patterns that weren't in either source. I didn't track which was which. When the platform updated their map a few months later and three codes broke, I had no record of which sources had been most reliable historically.

What's there now

TTEmos currently has all 46 validated codes with metadata about regional differences and deprecation status. The full reference is at ttemos.com.

It's a small static site. It will probably never grow into anything bigger. But every time someone wants to type a hidden TikTok emoji, the site is there.

The broader point — for anyone building something similar — is that platforms quietly accumulate undocumented features, and there's real value in being the person who writes them down. Not for the SEO. Not for affiliate clicks. Just because the documentation should exist and nobody else is making it.

What undocumented features have you mapped? Drop a comment.

Building 24 Random Tools in One App: An Architecture Story

Marvin Tang — Fri, 08 May 2026 08:53:12 +0000

When I started RandTap, I had a list of about eight tools I wanted to build. A dice roller. A coin flip. A password generator. A random number generator. A few others. Each one was a single-purpose utility I'd looked for separately on the web and never found a clean version of.

Eight became twelve. Twelve became eighteen. By the time I shipped, the app had 24 tools, with more queued. And along the way, the architecture question stopped being "how do I build a dice roller" and started being "how do I build a system that can hold 24 unrelated tools without collapsing into spaghetti."

This post is about what I learned. If you're building any kind of multi-tool app — a calculator collection, a converter suite, a generator hub — the patterns here might save you some time.

Why one app, not 24

The first decision was strategic, not technical. I could have shipped 24 separate single-purpose web pages. SEO-wise, that's probably better — each page can target its own keywords without competing.

But each tool was tiny. A dice roller is maybe 200 lines of code. A coin flip is 50. Building 24 separate sites would have meant 24 separate deployments, 24 sets of analytics, 24 navigation experiences for the user, and 24 places I'd need to update if I changed something cross-cutting like the theme or the sound system.

Bundling won. The trade-off was accepting that no single tool gets to optimize its URL structure perfectly. The win was a coherent product that compounds — every tool I add benefits from the shared shell.

The shell vs the tool

The first architectural decision that actually mattered was separating the shell from the tools.

The shell is everything that's the same regardless of which tool you're using:

Navigation (sidebar, header, tool picker)
Theme (dark/light mode, accent color)
Settings (sound on/off, haptic feedback, history retention)
Layout grid (tool content area, action buttons, result display)
Cross-cutting features (copy result, share, history)

The tools are the thing-specific logic:

A dice roller knows about face counts and rolls
A password generator knows about character classes and length
An animal facts tool knows about a database of facts

Once I was clear on this division, the architecture got dramatically simpler. Each tool became a self-contained module that exposed a small interface to the shell:

interface Tool {
  id: string;            // 'dice-roller'
  name: string;          // 'Dice Roller'
  category: ToolCategory;
  icon: IconName;

  // The tool's main UI, rendered inside the shell
  render: () => Component;

  // The 'generate' action when the user taps the main button
  generate: (state: ToolState) => Result;

  // Format a result as text for clipboard / share / history
  formatResult: (result: Result) => string;
}

That's it. Every tool implements that interface. The shell handles everything else.

Local state vs global state

The second pattern that mattered was being strict about state ownership.

A tool like the dice roller has its own state — what dice are selected, what the last roll was, the visual animation status. None of that needs to be visible outside the tool. Treating it as global state would have created cross-tool dependencies that don't actually exist in the user's mental model.

So tool state is local. Each tool manages its own state with whatever pattern makes sense for that tool — useState for simple ones, useReducer for complex ones, a small state machine for animation-heavy ones.

But there's a small slice of state that belongs to the shell and is visible everywhere:

Active tool ID (which tool is currently displayed)
Theme (dark/light, accent color)
Settings (sound, haptics, history toggle)
Recent results (the cross-tool history)

That's global. Tools can read it, but they can't write to most of it directly. They emit events ("a result was generated"), and the shell decides what to do with them.

This split kept the codebase navigable as it grew. When I added the 18th tool, I didn't have to think about what global state might conflict. I just wrote a self-contained module that conformed to the Tool interface and registered it.

Routing and lazy loading

With 24 tools, bundling everything into a single JavaScript file would have made the initial page load slow. Most users open RandTap to use one or two tools — they don't need the code for the other 22.

The fix was lazy loading. Each tool lives in its own module, and the shell loads them on demand:

const TOOL_REGISTRY: Record<string, () => Promise<{ default: Tool }>> = {
  'dice-roller':  () => import('./tools/dice-roller'),
  'coin-flip':    () => import('./tools/coin-flip'),
  'password-gen': () => import('./tools/password-gen'),
  // ... 21 more
};

async function loadTool(id: string): Promise<Tool> {
  const loader = TOOL_REGISTRY[id];
  if (!loader) throw new Error(`Unknown tool: ${id}`);
  const module = await loader();
  return module.default;
}

The first time a user opens a tool, there's a small loading state while the chunk downloads. After that, it's cached for the session.

For SEO, each tool also has a server-rendered shell with the tool's name and description in static HTML. Search engines see real content even before the JS runs. This was a cheap win that significantly improved indexing.

The web-to-iOS port

About six months in, I started thinking about an iOS version. The web app was working, but App Store distribution opens up a different audience and a different monetization model.

The naive plan was to wrap the web app in a WebView and ship it. This works, technically. But it doesn't feel like an iOS app. Tap latency is wrong. Animations don't feel native. Haptics don't trigger correctly. Users can tell.

The harder plan — and the one I went with — was to rewrite the UI shell natively, while keeping the tool logic largely shared.

The key insight was that the shell-vs-tool division I'd already made paid off here. Each tool's logic was already isolated and platform-independent. The shell — navigation, theme, settings — was the only part that had to be rewritten for iOS.

That's roughly 30% of the codebase, not 100%. A meaningful saving.

In practice, the iOS version uses a native shell and bridges into the tool logic through a thin adapter layer. The dice roller's "given current state, return the next roll" logic is functionally the same on both platforms.

Some adaptations were unavoidable:

Animations are native on iOS (UIKit / CoreAnimation), not the same web CSS animations. They take similar parameters but produce different results.
Haptics are a real iOS feature — iPhones have a Taptic Engine that's much richer than the limited browser vibration API. The iOS version uses much more nuanced haptic feedback than the web version can.
Persistence uses UserDefaults on iOS, localStorage on web. The interface I exposed to tools is the same; the implementation differs underneath.
Offline behavior is different. The iOS version is fully offline by default; the web version assumes connectivity for some features (like sharing).

What I'd do differently

A few things, looking back:

Define the Tool interface earlier. I wrote the first six tools without a shared interface, then refactored them when the seventh tool revealed the pattern. The refactor was painful. If I'd seen the pattern from tool one, the codebase would be cleaner today.

Build the history feature later. I added cross-tool history early, before I knew what users actually wanted to do with it. Most of that code went unused. If I were starting now, I'd ship without history and add it only when users asked.

Treat the shell as a product. The shell is at least as important as any individual tool. It's what makes the whole experience coherent. I underinvested in it for the first version and paid for it later when I had to retrofit settings, theme, and accessibility properly.

Pick the tool boundaries by user intent, not technical convenience. Some of my early tools were split because they were technically separate modules in my head, even though users would have wanted them combined. (Example: I shipped a "random number" tool and a "random number range" tool as two tools. They should always have been one tool with a range toggle.)

What's there now

RandTap currently has 24+ tools across categories: dice, decisions, generators, randomizers, and a small "fun" category for things like animal facts. It's free to use on the web with no account, and the iOS version is on the App Store with full offline support.

You can play with the web version at randtap.com.

The architecture I described isn't anything novel. It's just the same separation-of-concerns pattern applied to a niche category that doesn't usually get architectural treatment. If you're building any kind of tool collection, the shell-vs-tool split, strict state boundaries, and lazy loading are probably worth applying from day one.

What multi-tool patterns have you found helpful? Drop a comment.

The Infinite HTTPS Redirect Loop That Hit Me at 2am (and How X-Forwarded-Proto Saved My Site)

Marvin Tang — Thu, 30 Apr 2026 08:28:17 +0000

Earlier this year I migrated phyfun.com from www to non-www. On paper it's a five-minute job. In practice it took the site down for several hours, generated thousands of Search Console errors, and taught me more about SiteGround's hosting stack than I ever wanted to know.

This is the war story. If you're on SiteGround, or any Nginx-in-front-of-Apache hybrid setup, and you've ever wondered why your .htaccess HTTPS redirect rules don't behave the way the docs say they should — this post is for you.

The plan

phyfun.com is a browser physics-games site that's been online for years. The domain was historically configured with www.phyfun.com as canonical, with the bare domain redirecting to www. I wanted to flip that — make the bare domain canonical, redirect www to bare.

The reasoning was simple. I'd been moving toward shorter, cleaner URLs across all my sites, and Search Console was showing weird canonical conflicts on a few pages. Cleaning up the canonical was on my "do this when I have an evening" list for a while.

So one evening I sat down to do it. The plan was:

Add canonical tags pointing to non-www on all pages.
Update sitemap to use non-www URLs.
Add 301 redirects in .htaccess from www to non-www, and from HTTP to HTTPS.
Update Search Console with the non-www property as canonical.
Wait, watch, sleep.

Steps 1 and 2 were trivial. Step 3 is where everything went wrong.

The naive redirect rule

Here's the .htaccess I started with — the kind of rule you'll find in approximately every Stack Overflow answer about Apache HTTPS redirects:

RewriteEngine On

# Force HTTPS
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Force non-www
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [L,R=301]

This is correct on a vanilla Apache setup. It is not correct on SiteGround. I deployed it. The site went down.

What I saw in the browser: ERR_TOO_MANY_REDIRECTS. What I saw in the Apache logs (after I figured out where SiteGround keeps them): every single request was being 301'd back to itself, in an infinite loop.

I rolled back. The site came up. I went to make coffee.

Why this fails on SiteGround

It took me an embarrassing amount of digging to understand what was happening. The short version:

SiteGround runs Nginx in front of Apache. Nginx terminates TLS. By the time the request reaches Apache, it's already been decrypted, and Apache sees a plain HTTP request — even when the user is browsing over HTTPS.

So when my .htaccess rule says:

RewriteCond %{HTTPS} off

Apache evaluates %{HTTPS} as off for every single request, including HTTPS ones, because that's what Apache sees. The rule then 301-redirects the request to HTTPS. The browser follows the redirect, hits Nginx, which terminates TLS again, hands the now-HTTP request to Apache, which sees %{HTTPS} = off, redirects again, and the cycle continues until the browser gives up.

This is a really common gotcha on hosts that use this kind of hybrid setup — SiteGround, certain WP Engine configurations, some Cloudways stacks, anywhere there's a TLS-terminating reverse proxy in front of Apache. If you've never run into it, count yourself lucky.

The fix: X-Forwarded-Proto

The fix is to stop trusting Apache's view of the protocol and instead read the header that Nginx adds when forwarding the request. That header is X-Forwarded-Proto, and it contains the actual protocol the client used (http or https).

Here's the corrected rule:

RewriteEngine On

# Force HTTPS — using X-Forwarded-Proto for Nginx-in-front-of-Apache hosts
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Force non-www
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [L,R=301]

The key change is RewriteCond %{HTTP:X-Forwarded-Proto} !https instead of RewriteCond %{HTTPS} off. Apache's %{HTTPS} is wrong on this kind of host. The header is right.

A few things worth knowing about this syntax:

%{HTTP:HeaderName} is how you access an arbitrary HTTP header in mod_rewrite. The HTTP: prefix tells Apache to look in the request headers, not its built-in environment variables.
The ! negates the match. So !https means "if X-Forwarded-Proto is anything other than https, redirect."
This works because Nginx faithfully sets X-Forwarded-Proto when forwarding. If you ever set this rule on a host where Nginx isn't doing that, the rule will silently misbehave. Confirm your host actually sets the header before relying on it. You can check with curl -I or by dumping headers in a tiny PHP file.

After deploying this, the site came back up. The redirect loop was gone. I made more coffee.

The bonus problem: .aspx zombie URLs

While I was already in .htaccess, I decided to deal with another issue I'd been ignoring.

phyfun.com had been on a different platform years ago, and that platform used .aspx URLs. When I rebuilt the site on a different stack, those URLs went away — but the wider web had no way to know that. Old links to .aspx pages were still being requested, by humans and bots, years later.

For a long time those requests had been hitting my generic 404 page, which returned a 200 OK status with "page not found" content. This is what's called a soft 404 — the response body says "not found" but the HTTP status code says "OK". Google really doesn't like this. Search Console had been flagging hundreds of these for ages, which I'd been politely ignoring.

The right answer for URLs that are gone and never coming back is HTTP 410 Gone, not 404. The semantic difference matters:

404 Not Found means "the resource isn't here right now, maybe try later."
410 Gone means "this resource is permanently gone, stop asking, deindex it."

Google treats them very differently. 410s drop out of the index much faster than 404s.

The .htaccess rule:

# Permanently mark old .aspx URLs as gone
RewriteRule \.aspx$ - [G,L]

The [G] flag returns 410 Gone. The - means "don't substitute the URL." The [L] stops further rewrite processing for these URLs.

Within a few weeks of deploying this, Search Console's "Soft 404" report stopped growing. Within about two months, the old .aspx URLs were essentially fully removed from Google's index. The Search Console error counts dropped from "hundreds, occasionally rising" to "zero."

If you have a site with a long history of URL changes, run a "soft 404" audit. Anything that's permanently gone should return 410, not 404, and definitely not 200.

The full corrected .htaccess

For reference, here's roughly what I ended up with:

RewriteEngine On

# 1. Force HTTPS (Nginx-in-front-of-Apache aware)
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# 2. Force non-www
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [L,R=301]

# 3. Permanently mark old .aspx URLs as Gone
RewriteRule \.aspx$ - [G,L]

# 4. Standard rewrite rules for the rest of the site below…

That's the migration in three blocks. The first one is the trap I fell into. The second is straightforward. The third is the tidying-up that should have happened years earlier.

Lessons learned

Trust your host's actual stack, not the generic Apache docs. "Nginx-in-front-of-Apache" is a different deployment from "vanilla Apache," and a lot of standard .htaccess snippets are subtly wrong on it. Always check what your host actually runs before pasting Stack Overflow rules.

X-Forwarded-Proto is the canonical way to detect protocol behind a reverse proxy. Not just for Apache — Express, Flask, Django, every web framework has equivalent helpers (req.protocol with trust proxy, request.is_secure, request.scheme with SECURE_PROXY_SSL_HEADER). If you've ever wondered why your framework "thinks" HTTPS is HTTP, this is usually the answer.

Soft 404s are not the same as 404s. Google treats them differently. If a page is permanently gone, return 410. If a page is broken right now but might come back, return 503. If you're just genuinely unsure, 404. The status code matters.

Test redirect rules on a staging copy first. I didn't, because the rule was "obvious." It wasn't. Twenty minutes of staging would have saved me three hours of production hot-fixing. I keep saying I've learned this lesson and I keep proving I haven't.

Search Console mostly fixes itself if you fix the underlying signals. The soft 404 cleanup showed me that GSC reports are largely a function of what your server actually sends. Once the server stops sending bad signals, the reports clear, often without further intervention.

Wrapping up

If you're hosting on SiteGround or any similar Nginx-in-front-of-Apache stack and you've ever had a redirect rule that "just doesn't work," X-Forwarded-Proto is probably what you need.

If you have an old site with URLs that no longer exist, switching them from soft 404 to 410 Gone is one of the lowest-effort, highest-leverage hygiene moves available — especially if Google's been quietly downranking those URLs for years.

And if you've ever taken down your own site at 2am, welcome. The club has many members.

The Hidden Complexity of Two-Player Browser Games — A Practical Guide to Keyboard Input

Marvin Tang — Thu, 30 Apr 2026 07:35:09 +0000

I run 2playerfun.com, a site dedicated entirely to two-player browser games where both players share one keyboard. It's a niche that turned out to have more technical depth than I expected.

When I started, I assumed local multiplayer was the easy case. No netcode. No latency. No matchmaking. Just two players, one keyboard, browser-side state. What could go wrong?

What could go wrong, it turns out, is that two people pressing keys on a single keyboard at the same time is a surprisingly hostile environment.

This post is about what I've learned. If you're building a local-multiplayer browser game, or you've just always wondered why every two-player web game uses WASD and arrows specifically, read on.

Keyboard hardware actually matters

The thing nobody tells you when you start: keyboards have a property called N-key rollover (NKRO), and most keyboards don't have very good NKRO.

In practice this means: a cheap membrane keyboard might only register two or three simultaneous key presses correctly. If Player 1 is holding W and A to move diagonally, and Player 2 presses an arrow key at the same time, the keyboard might just not send the third event. Or worse, it might send a "ghost" event for a key that wasn't actually pressed.

This is hardware. There's nothing you can do about it from the browser. But there are things you can do that make the problem less common.

Why every 2P game uses WASD + Arrows

If you've played any local multiplayer browser game, you've seen this layout:

Player 1: WASD (movement) + nearby action keys (Q, E, F, Space)
Player 2: Arrow keys (movement) + nearby action keys (Enter, comma, period, M, /)

This isn't an accident. WASD and arrow keys live on opposite sides of the keyboard, on different rows of the underlying key matrix. On most keyboards, this means they're far less likely to ghost into each other than, say, WASD and TFGH would be.

You can almost always press WASD + arrows + 2–3 nearby action keys simultaneously without issues, even on a cheap keyboard. That's why the convention exists. It's a hardware-aware layout choice that the genre converged on through trial and error.

Lesson: if you're inventing your own scheme, don't put both players' keys in the same physical region of the keyboard. Use the WASD/arrow split unless you have a strong reason not to.

Browser event handling — the things that bit me

Once you've got your key layout, you have to actually capture the inputs in the browser. Here's where I learned a few things the hard way.

1. Use `keydown` and `keyup`, not `keypress`

The keypress event is deprecated and doesn't fire for non-character keys like arrows or modifiers. Use keydown for "key went down" and keyup for "key was released":

window.addEventListener('keydown', (e) => {
  // Handle press
});

window.addEventListener('keyup', (e) => {
  // Handle release
});

2. Use `event.code`, not `event.key` or `event.keyCode`

event.keyCode is deprecated.
event.key returns the character ("a", "A", "ArrowLeft"), which changes with keyboard layout (AZERTY vs QWERTY) and shift state.
event.code returns the physical key location ("KeyA", "ArrowLeft"), which is consistent across layouts.

For game input, you almost always want the physical key, not the character. Use event.code:

window.addEventListener('keydown', (e) => {
  switch (e.code) {
    case 'KeyW':    player1.up = true; break;
    case 'ArrowUp': player2.up = true; break;
  }
});

3. Handle key repeat correctly

When a key is held, the browser fires keydown repeatedly. For movement keys this is fine — your game loop reads the state every frame. For action keys (jump, shoot), you want to fire the action only on initial press, not on every repeat.

Two common patterns:

// Pattern A: skip repeats with event.repeat
window.addEventListener('keydown', (e) => {
  if (e.repeat) return;
  if (e.code === 'Space') player1.jump();
});

// Pattern B: track held keys, fire action on transition
const heldKeys = new Set();

window.addEventListener('keydown', (e) => {
  if (heldKeys.has(e.code)) return;
  heldKeys.add(e.code);
  if (e.code === 'Space') player1.jump();
});

window.addEventListener('keyup', (e) => {
  heldKeys.delete(e.code);
});

I prefer Pattern B because it gives you a clean "what's currently held" state for movement, plus reliable transition detection for actions, from the same data structure.

4. `preventDefault` aggressively (but not indiscriminately)

Browsers have default behavior for many keys:

Space scrolls the page.
Arrow keys scroll the page.
Tab moves focus.
/ may open browser search.
F1–F12 do various OS/browser things.

If your game uses any of these for input, call event.preventDefault() or the browser hijacks the key:

const gameKeys = new Set([
  'Space',
  'ArrowUp', 'ArrowDown', 'ArrowLeft', 'ArrowRight',
  'KeyW', 'KeyA', 'KeyS', 'KeyD',
  'Enter',
]);

window.addEventListener('keydown', (e) => {
  if (gameKeys.has(e.code)) {
    e.preventDefault();
  }
  // ... handle game input
});

Whitelist your game keys. Don't blanket-preventDefault everything — users still need Ctrl+R, Ctrl+Tab, and so on for browser functions. I've seen games that swallow Tab and break focus navigation site-wide. Don't be that game.

5. Focus matters

Your game needs focus to receive keyboard events. If you're rendering into a <canvas>, the canvas itself doesn't receive keyboard events by default. Two options:

Listen on window — simplest, but globally captures keys.
Make the canvas focusable with tabindex="0" and listen on the canvas — better for embeddable games.

For a dedicated 2P game page, window is fine. For games embedded inside a larger page, scope to the canvas.

The input architecture I actually use

Here's the pattern I use across 2playerfun games:

const players = {
  p1: { up: false, down: false, left: false, right: false, action: false },
  p2: { up: false, down: false, left: false, right: false, action: false },
};

const keyMap = {
  KeyW:       ['p1', 'up'],
  KeyS:       ['p1', 'down'],
  KeyA:       ['p1', 'left'],
  KeyD:       ['p1', 'right'],
  Space:      ['p1', 'action'],

  ArrowUp:    ['p2', 'up'],
  ArrowDown:  ['p2', 'down'],
  ArrowLeft:  ['p2', 'left'],
  ArrowRight: ['p2', 'right'],
  Enter:      ['p2', 'action'],
};

window.addEventListener('keydown', (e) => {
  const mapping = keyMap[e.code];
  if (!mapping) return;
  e.preventDefault();
  const [who, what] = mapping;
  players[who][what] = true;
});

window.addEventListener('keyup', (e) => {
  const mapping = keyMap[e.code];
  if (!mapping) return;
  const [who, what] = mapping;
  players[who][what] = false;
});

// In game loop:
function update(dt) {
  if (players.p1.up)    p1Sprite.y -= speed * dt;
  if (players.p1.down)  p1Sprite.y += speed * dt;
  if (players.p1.left)  p1Sprite.x -= speed * dt;
  if (players.p1.right) p1Sprite.x += speed * dt;
  // ... same for p2
}

The key idea: keep input state in a structured object that the game loop reads, instead of mutating game state directly in event handlers. This decouples input from game logic and makes a few things much easier:

Customizable key bindings — just rebuild keyMap.
Replay systems — serialize the players state per frame.
AI opponents — let the AI write to the state object the same way the keyboard does.
Networked multiplayer later — the state object is what you'd send over the wire.

This pattern looks trivial in isolation, but the savings compound over a dozen games.

The mobile/touch reality

Honest answer: local multiplayer on mobile is mostly broken.

In theory you can put two touch zones on screen — one player on the left, one on the right. In practice this works for very simple games (tap-to-jump, swipe-to-move) but breaks down for anything needing simultaneous directional + action input. The device is also held by one person, which adds awkward physical dynamics.

For 2playerfun, my pragmatic answer is: most games are desktop-only, and mobile users see a polite "this game works best on a desktop with two players sharing a keyboard" message. Trying to force mobile two-player support has been more trouble than it's worth, and the audience that wants couch co-op is mostly on laptops anyway.

What I wish I'd known earlier

Test on a cheap keyboard. Your nice mechanical board with full NKRO will tell you nothing about what 90% of your users experience. Buy a $15 USB membrane keyboard and test 2P games on it. You will find ghosting issues you didn't know existed.

Use event.code from day one. Switching from event.key or event.keyCode later means rewriting input across every game. Save yourself the rework.

Don't blanket-preventDefault. Be specific about which keys your game uses, and let the rest behave normally.

Build the input layer once, reuse it. The keyMap → state object → game-loop-reads-state pattern works for almost every local 2P game I've built. Once it's working, copy it forward.

Wrapping up

Local multiplayer browser games feel like a niche from 2008, but the genre is having a quiet renaissance. People want to play games together in person again. Sharing a couch and a laptop is a perfectly valid form of multiplayer, and the browser is an extremely accessible platform for it — no installs, no accounts, no friend codes, no matchmaking.

If you're building one, I hope some of this saves you a few hours.

If you're just looking to play one, 2playerfun.com has a couple hundred of them, all using roughly the input architecture above.

Building a Gacha Tower Defense in Cocos Creator: Wave System, Merge Logic, and 28 Enemy Types

Marvin Tang — Fri, 24 Apr 2026 10:41:35 +0000

I wrote recently about migrating from LayaAir to Cocos Creator. This post is the follow-up: what I actually built with Cocos after the migration settled.

The game is Cosmic Summon, a gacha merge tower defense. Players summon heroes randomly, place them on a grid, and combine duplicates to evolve them through seven rarity tiers. Enemies spawn in 50 waves themed around real constellations. Bosses appear every five waves.

This post walks through the technical decisions behind three of the core systems: the merge mechanic, the wave progression, and the enemy variety system.

The Merge Mechanic

The merge mechanic is the heart of the gameplay loop. When a player places two heroes of the same type on adjacent grid cells, they combine into a higher-tier version of that hero.

Implementing this cleanly in Cocos Creator came down to three decisions.

First, the grid is a logical structure, not a visual one. Heroes are rendered at pixel-perfect positions but their merge eligibility is determined by grid coordinates stored on the hero component itself:

@ccclass('HeroUnit')
export class HeroUnit extends Component {
  @property
  heroType: string = '';

  @property
  tier: number = 1;

  @property
  gridX: number = 0;

  @property
  gridY: number = 0;

  canMergeWith(other: HeroUnit): boolean {
    if (this.heroType !== other.heroType) return false;
    if (this.tier !== other.tier) return false;
    if (this.tier >= 7) return false;
    return this.isAdjacent(other);
  }

  isAdjacent(other: HeroUnit): boolean {
    const dx = Math.abs(this.gridX - other.gridX);
    const dy = Math.abs(this.gridY - other.gridY);
    return (dx + dy) === 1;
  }
}

Second, the merge animation is handled by the Cocos Animation component, not by manually tweening properties. The animation plays on a temporary placeholder node while the old heroes are destroyed and the new hero is instantiated underneath. This lets the visual feel smooth even when the game logic is doing three things at once.

Third, the merge trigger is evaluated on placement, not continuously. The old approach ran merge checks every frame, which was fine for small boards but slowed down on mobile with 20+ units on screen. Evaluating only on placement cut the CPU overhead substantially.

The Wave Progression System

50 waves is enough that designing them manually would be tedious and error-prone. I built a wave configuration system based on JSON data, evaluated at runtime:

interface WaveConfig {
  waveNumber: number;
  constellation: string;
  spawns: EnemySpawn[];
  isBossWave: boolean;
  durationSeconds: number;
}

interface EnemySpawn {
  enemyType: string;
  count: number;
  delayMs: number;
  spawnPattern: 'single' | 'cluster' | 'stream';
}

The wave data lives in a JSON file shipped with the game. At runtime, the wave manager reads the config for the current wave, schedules enemy spawns through Cocos's scheduler, and triggers the wave completion event when all enemies are defeated or reach the base.

This separation of wave configuration from wave logic made iteration vastly faster. When playtesting revealed that wave 23 was too easy, I adjusted the JSON file, not the code.

One useful pattern: rather than spawning enemies instantly, each spawn is scheduled with a delay. This gives waves a sense of rhythm rather than a wall of enemies arriving simultaneously. For the 5-wave boss cadence, the boss spawn is preceded by a 2-second pause and a visual warning effect.

The Enemy Variety System

28 enemy types sounds like a lot, but the complexity comes from how they interact with each other and with the player's hero composition, not from the types being mechanically unique.

Each enemy is a composition of behaviors rather than a monolithic class:

@ccclass('Enemy')
export class Enemy extends Component {
  @property([Component])
  behaviors: Component[] = [];

  @property
  hp: number = 100;

  @property
  speed: number = 50;

  takeDamage(amount: number) {
    const reflect = this.getBehavior(ReflectBehavior);
    if (reflect && reflect.shouldReflect()) {
      reflect.reflectDamage(amount);
      return;
    }
    this.hp -= amount;
    if (this.hp <= 0) this.onDeath();
  }

  onDeath() {
    const split = this.getBehavior(SplitBehavior);
    if (split) split.spawnSplitUnits();
    this.node.destroy();
  }

  getBehavior<T extends Component>(type: new () => T): T | null {
    return this.behaviors.find(b => b instanceof type) as T || null;
  }
}

Behaviors are reusable: StealthBehavior vanishes for N seconds, SplitBehavior spawns smaller enemies on death, ReflectBehavior bounces damage, SummonBehavior spawns minions during lifetime, ShieldBehavior absorbs a fixed amount before taking hit damage.

A Reflector Splitter enemy is simply an enemy with both ReflectBehavior and SplitBehavior attached. This compositional approach made adding new enemy types trivial, usually just a new config entry referencing existing behaviors.

Performance Considerations

With up to 40 active enemies plus 15 heroes plus projectiles plus UI, the scene can hit several hundred nodes during peak combat. A few patterns that helped.

Object pooling for projectiles and hit effects. These are spawned frequently and destroyed frequently. Pooling eliminates the allocation cost:

const pool = new NodePool('Projectile', 50);
const projectile = pool.get() ?? instantiate(projectilePrefab);
pool.put(projectile);

Avoid per-frame array allocations in update loops. Reusing a single array reference across frames rather than creating new arrays each update saved measurable frame time on lower-end phones.

Batching sprite draws. Cocos Creator supports auto-batching for sprites in the same atlas. Grouping projectile sprites and enemy sprites into their respective atlases meant the whole scene rendered in a handful of draw calls rather than dozens.

What I'd Do Differently Next Time

Two things.

First, I'd design the merge system's edge cases earlier. The current implementation handles the common cases well but had weird behavior when players rapidly placed and removed units in the same frame. Fixing it required refactoring the placement event queue late in development.

Second, I'd build a dev-mode wave editor from the start. I eventually built one to accelerate balance testing, but the first 30 waves were designed with manual JSON editing, which was slow and error-prone. An in-editor tool would have paid for itself many times over.

Playable

Cosmic Summon runs in any modern browser at phyfun.com with no download or account required. The iOS version is currently in App Store review.

If you're building anything in Cocos Creator and want to see a working example of these patterns, the game is a decent reference for gacha systems, merge mechanics, and wave-based progression in a single project.

This article was written with AI assistance.

DEV Community: Marvin Tang

Building a browser-first PHP tools directory without pretending everything is offline

1. Let PHP own discovery, not the user's working data

2. Make privacy claims at tool level

3. Treat the service worker as a cache policy, not a magic offline switch

4. Keep local persistence equally bounded

A checklist I now use

A Good AI Workflow Brief Needs More Than a Prompt

The prompt is only one layer

1. Define the outcome, not just the activity

2. Draw an evidence boundary

3. Name forbidden actions

4. Separate preparation from approval

5. Use checks that can fail

A compact workflow-brief schema

A six-question preflight

The practical payoff

I stopped writing content and started building tools. Here's the logic

The asymmetry

What I'm doing about it

What I'd take from it

I Rewrote One AI Prompt 15 Times to Kill the "AI Smell" in Product Reviews

Why the first prompt failed

What actually worked

The ceiling no prompt gets past

The takeaway

From ASP.NET + MSSQL to PHP + MySQL: Migrating a Names Site Without Mangling the Accents

The real reason: hosting, not code

The schema migration: MSSQL → MySQL

The collation trap (where the accents died)

Moving 6.5M rows

The app layer

What the new stack unlocked

I Cloned My Dog-Name Site to Build a Cat-Name Site. The Routing Layer Bit Back.

The shape of the thing

Cloning doubled the tax into something worse

What actually didn't transfer

What I'd do instead (and am slowly refactoring toward)

The lesson in one line

Cocos Creator 2D Physics on iOS: Notes on Fixed Timestep, ProMotion, and CCD

1. ProMotion silently changes your simulation

2. Don't integrate with variable dt

3. CCD is not on by default, and you usually want it

4. Touch input lands later than you think

5. Background/foreground destroys your physics state

6. Determinism is fragile, and you probably don't need it

Pre-ship checklist

Mapping TikTok's 46 Hidden Emoji Codes: A Reverse Engineering Story

The first lead

Finding the list

Validation

The reference site itself

A note on undocumented features

What I'd do differently

What's there now

Building 24 Random Tools in One App: An Architecture Story

Why one app, not 24

The shell vs the tool

Local state vs global state

Routing and lazy loading

The web-to-iOS port

What I'd do differently

What's there now

The Infinite HTTPS Redirect Loop That Hit Me at 2am (and How X-Forwarded-Proto Saved My Site)

The plan

The naive redirect rule

Why this fails on SiteGround

The fix: X-Forwarded-Proto

The bonus problem: .aspx zombie URLs

The full corrected .htaccess

Lessons learned

Wrapping up

The Hidden Complexity of Two-Player Browser Games — A Practical Guide to Keyboard Input

Keyboard hardware actually matters

Why every 2P game uses WASD + Arrows

Browser event handling — the things that bit me

1. Use keydown and keyup, not keypress

2. Use event.code, not event.key or event.keyCode

3. Handle key repeat correctly

4. preventDefault aggressively (but not indiscriminately)

1. Use `keydown` and `keyup`, not `keypress`

2. Use `event.code`, not `event.key` or `event.keyCode`

4. `preventDefault` aggressively (but not indiscriminately)