DEV Community: MRZHU

A stale response can quietly break a recommendation tool

MRZHU — Sun, 16 Aug 2026 01:23:06 +0000

A recommendation page can perform the correct calculation and still show the wrong result. The failure happens when two valid requests finish in the wrong order.

Consider a player who starts a Members search, then switches to F2P while the first request is still running. The F2P request finishes quickly and the page shows F2P methods. A moment later, the slower Members response arrives. If the interface accepts it, Members-only methods replace the correct result even though the form still says F2P.

Nothing crashed. The API returned valid data twice. The screen became untrustworthy because an older answer won the race.

Give every request an identity

The finder on OSRS Money Maker keeps a counter for recommendation requests. Starting a search increments the counter and stores the new value locally.

const requestId = ++activeRecommendRequest.current

When the response returns, the handler compares its local ID with the current counter.

if (requestId !== activeRecommendRequest.current) return
setResults(response)

Changing a setting also increments the counter and clears the old result. Any response created before that change becomes stale immediately, even if the network request cannot be cancelled.

Player lookup needs the same protection

The page can load public Hiscores before it asks for recommendations. That adds another race. A player might type one username, start a lookup, then correct the name before the first lookup finishes.

The same request-ID pattern protects this path. Only the latest player lookup may update the stored profile or clear the loading state. The recommendation request also checks whether it is still current after waiting for Hiscores. This prevents a corrected username from being paired with the previous account's levels.

Loading state can become stale too

Race protection has to cover more than the final data. An old request should not clear the spinner for a newer request. It should not display an old error after a successful retry. It should not scroll the page to results that no longer match the selected settings.

The current-ID check belongs around every state change that depends on the request. That includes results, error messages, loading flags, and follow-up UI actions.

AbortController can save bandwidth when the API supports cancellation. The identity check still earns its place. Cancellation can arrive too late, and some intermediate work may already have completed. A small monotonic counter gives the interface a clear rule about which answer owns the screen.

The calculation can be perfectly accurate for the request it received. The product also has to prove that the response still belongs to the choices visible now.

Why an OSRS Money-Making Method Can Vanish from a Live Recommendation List

MRZHU — Thu, 13 Aug 2026 10:25:06 +0000

A method can be carefully reviewed, remain in a catalog, and still disappear from a live list of recommendations. That is not a data error. In my OSRS money-maker finder, it is often the correct result.

The catalog and the recommendation list answer different questions. The catalog says that a method has been examined and has usable requirements, item inputs, outputs, and action-rate assumptions. The live list asks whether that method fits this player right now.

The first test is eligibility. A members-only route should not appear for a free-to-play player. A Wilderness route is excluded when the player says no to Wilderness activity. Skill requirements, starting cash, and the preferred amount of attention can remove other methods.

The second test is the current market calculation. Inputs are valued at the live high price, outputs at the live low price, and Grand Exchange tax is deducted. If the result is zero or negative, the method is not recommended even though its reviewed record stays in the catalog. The method can return when the prices make sense again.

Keeping these two layers separate matters. Deleting an unprofitable method would erase useful reviewed information. Showing it as a recommendation would suggest that a historical review overrules the current numbers. Neither choice is honest.

This is also why the empty state is useful. When OSRS Money Makers finds no match, it means every reviewed option failed at least one declared condition or the current profit test. The player can change a real constraint, such as available cash or Wilderness preference, instead of being handed a filler suggestion.

The system is still an estimate. Live prices move, orders may fill slowly, and a player may not sustain the reviewed action rate. But a method that vanishes has at least failed a visible rule, not an unexplained score.

For recommendation software, exclusion logic deserves as much attention as ranking logic. A smaller list with defensible omissions is more useful than a large list that never says no.

I Stopped Treating “Available” as a Boolean

MRZHU — Wed, 12 Aug 2026 14:22:22 +0000

When I started building a status page for a newly released messaging app, I thought the job was simple: answer whether the app was available.

That assumption lasted about one afternoon.

“Available” turned out to hide several different states:

a store listing exists;
the listing belongs to the expected publisher;
the page shows Install, Pre-register, or Not available;
the user can create or use the required account;
the network path works in the user's region;
the feature has actually rolled out to that account;
the current build supports the feature being discussed.

A single boolean could not represent any of this without misleading somebody.

Model the decision, not the headline

I replaced the boolean with a small set of explicit observations:

type StoreState =
  | "not_found"
  | "pre_register"
  | "install"
  | "region_blocked"
  | "unknown";

type Evidence = {
  observedAt: string;
  sourceUrl: string;
  publisher?: string;
  storeState: StoreState;
  accountAccess: "works" | "blocked" | "untested";
  featureRollout: "present" | "missing" | "unknown";
};

The important part is not the union type. It is the refusal to collapse different questions into one confident answer.

For example, a reader in mainland China may be able to see an App Store page while still being unable to finish sign-in. Another reader may install the same build but not receive a feature flag yet. Both experiences are real, and neither is explained by “launched globally.”

Put time next to every changing fact

App availability is a cache with a very short half-life. I now attach an observation date to store state, publisher identity, version history, and official help pages. If an article says “there is no standalone app” but a verified publisher releases one later, the old article is not necessarily dishonest; it is simply date-bound.

This also changed the UI. Instead of a large green “available” badge, the page can say:

iOS listing verified on 12 August 2026. Android store state still varies by region. Account access was not independently tested.

That sentence is less exciting, but much more useful.

Separate safety evidence from marketing claims

Encryption language creates a similar problem. A product announcement, a store description, and a third-party security review are not equivalent evidence. I keep those layers separate and avoid converting “encrypted” into “safe.” Publisher identity, download source, account recovery, metadata behavior, and implementation review are different checks.

I keep the live decision pages for this experiment at WexChat Pro. It is an independent reference site, not an official X product. The broader engineering lesson applies to any fast-moving product: model what the user must decide, preserve the source and timestamp, and let uncertainty remain visible.

A status page should not merely report a launch. It should help a real person decide what to do next.

Which OCR Should I Use for Handwritten Math Answers?

MRZHU — Tue, 28 Jul 2026 02:17:11 +0000

I am building an English website for a Gaokao math paper. Gaokao is the university entrance exam in China.

Checking the objective questions is easy. Written questions give me a headache.

For a written math question, a student may fill half a page with fractions, square roots and small notes. Chinese students write very fast in the exam, so the handwriting can be squeezed together. There may be crossed-out formulas, arrows, or a new step added between two old steps. A geometry question can also have a diagram.

My first idea was to let the student take a photo and upload it. Then I thought about one simple problem. If OCR reads x + 1 as x - 1, everything after that is useless. The system may still give a very confident-looking grade.

This is the part I have not solved.

Tools I found

Mathpix looks closest to this problem. It is made for math and other STEM content. It can read images, PDFs and stroke data. I think I will test it first for paper photos.

MyScript iink is a different choice. It uses pen strokes when the user writes on a screen. This may be more accurate, but it also means I need to build a writing canvas and ask the student not to use paper.

I also checked Google Cloud Vision and Azure Document Intelligence Read. They can return handwriting and page layout. Maybe they can handle the Chinese or English notes while another service handles the formulas.

TrOCR is another direction if I want an open-source model. I have not found a clear answer about a whole page with mixed text, formulas and diagrams.

A vision model may help after OCR. I am careful about this idea. If a line is unclear, I want the system to mark it as unclear. I do not want the model to fill in the line because it knows what a normal solution should look like.

My rough plan

I will first reject photos that are blurred, cropped or badly tilted. After that, I may use one recognizer for formulas and another one for normal handwriting. I also want to keep the position and confidence of every recognized part, instead of saving only a cleaned-up answer.

The recognized work can then be compared with a solution and scoring rubric that I reviewed before the exam starts. When one important line cannot be read, the written score should stay provisional. It should not quietly become zero.

I have not tested this plan yet. I need to make a small test set with real Gaokao-style handwriting, including bad handwriting and crossed-out work. Testing only the clean examples from a service demo will tell me very little.

I would like some advice

Has anyone here used these tools for handwritten mathematics from phone photos?

I mainly want to know:

Is Mathpix good enough for multi-line calculation?
Is keeping the pen strokes worth the extra work?
What open-source model should I put into the test?
How do you decide that an answer is too unclear to grade?

The project is here: gaokaoexam.org

At present I still do not know whether photo upload is practical, or whether I should ask students to write on a screen. If you have worked on a similar problem, I would like to hear what failed in your first attempt.

I Stopped Tuning Prompts and Started Collecting Real Comments

MRZHU — Tue, 12 May 2026 12:53:10 +0000

When I started building an AI comment generator, my first instinct was obvious:

Tune the prompt harder.

I tried to make the model sound more casual. Then more specific. Then less robotic. Then more like a real TikTok user. Then less like a marketing intern pretending to be a real TikTok user.

That approach worked a little.

But after a while, it felt wrong.

I was asking AI to invent the shape of a good comment from second-hand assumptions. I was not looking closely enough at the thing I was trying to generate.

The better question was not:

“How do I prompt the model to write better comments?”

The better question was:

“What do real high-engagement comments actually look like?”

That changed the project.

Prompt tuning is second-hand data

Prompt tuning is useful, but it can become a trap.

If I write:

“Make this comment sound natural, casual, and engaging,”

the model has to guess what “natural” means.

If I write:

“Make this comment sound like TikTok,”

the model usually reaches for a vague internet voice. Short sentences. A little humor. Maybe an emoji. Maybe a phrase like “this is so real.”

That can produce something passable, but it is still built on a stereotype of the platform.

It is second-hand data.

The model is not learning from what people actually liked, replied to, argued with, or remembered. It is learning from my opinion about what I think people like.

That felt too weak for a product.

So I started collecting real comments

For this project, I started collecting high-engagement short-form video comments as research material.

The goal is to keep expanding this into a much larger dataset, eventually tens of thousands of high-like and high-reply comments across different niches.

That matters because “good comment” is not one thing.

A good comment on a fitness transformation video is different from a good comment on a gaming clip. A good comment under a storytime video is different from a good comment under a creator advice video.

If I only tune prompts, I miss that.

If I look at real comments, patterns start to show up.

One high-liked comment says more than a generic prompt

One comment in my dataset had 243,581 likes:

“Everyone talking about Meryl, however, no one pointed out Anne's shaky voice after Meryl's glare, that's top notch acting right there.”

That comment works because it is not just praise.

It does three things:

It notices a specific detail
It points out that other viewers missed it
It makes a judgment

That is much stronger than:

“Great acting, such an amazing scene.”

The second comment is positive, but empty. It could be posted under almost any clip.

The first comment proves the viewer actually saw something.

That is the kind of pattern I want the product to learn from.

The useful signal is in the pattern, not the exact sentence

I do not want to copy high-liked comments.

That would be useless and wrong.

The useful part is the structure.

For example, this pattern appears again and again:

“Everyone is talking about X, but no one is mentioning Y.”

That is a powerful comment shape because it creates a small discovery moment. The commenter is not just reacting. They are reframing what everyone else is watching.

Another common pattern is:

“I thought X was the point, but Y is what got me.”

That works because it has a turn.

Another one:

“As someone who has been in this situation, this part is painfully accurate.”

That works because it adds lived context.

These are not magic phrases

They are interaction patterns.

That is what I missed when I was only tuning prompts.

The product lesson

When I started working on Comment Generator Pro[www.commentgenerator.pro], I thought the hard part would be generating enough comment variations.

Now I think the hard part is building the right input system.

A comment generator should not just produce text. It should protect the user from producing generic text.

That means the tool needs to be grounded in real comment behavior.

Not just prompt tricks.
Not just tone sliders.
Not just “make it casual.”

Real data changes what you notice.

High-like comments are often specific, but not polished.
They are emotional, but not always positive.
They are short, but not empty.
They often contain a twist, a missed detail, or a personal admission.

That is hard to invent from a prompt alone.