DEV Community: MRZHU

A random question button should not ignore the room

MRZHU — Tue, 08 Sep 2026 07:43:00 +0000

The interesting part of an icebreaker generator is not Math.random(). It is deciding which questions should reach that line.

In the current Break The Ice implementation, the homepage picker has three settings: Work, Parties, and Team meetings. There is also an Any group option. This is a small interaction, but it makes the random output less arbitrary. A question about a party playlist belongs in a different pool from a question about a crowded calendar.

This is a development note about our Fun Icebreaker Questions generator, with a few details that are useful for other small random-content tools.

Select the pool before selecting the item

A category change should immediately produce a question from the new category. It is frustrating to choose Parties and keep looking at the work question from the previous state.

In React, the change handler passes the new category into the picker function directly. Calling setCategory(nextCategory) and then relying on the old state value in that same handler would use the previous render's category.

Here is the important shape, simplified:

function onCategoryChange(nextCategory) {
  setCategory(nextCategory);
  chooseQuestion(nextCategory);
}

That explicit argument matters more than adding another animation to the button. The interface has just made a promise about context; the next piece of text needs to keep it.

Avoid the immediate repeat, but describe the guarantee accurately

The picker removes the current question from the candidate array before selecting the next question:

const candidates = nextPool.filter(item => item !== question);
const choices = candidates.length ? candidates : nextPool;
const next = choices[Math.floor(Math.random() * choices.length)];

This prevents the most visible disappointment: pressing Another question and seeing the same sentence. The fallback also handles a pool containing only one item.

It does not promise that a question will never repeat during the session. A previous question can return after an intervening draw. For a facilitator working through an entire deck, a shuffled queue with a cursor would offer a different guarantee. For a quick homepage picker, excluding the current item keeps the implementation simple.

That distinction is worth putting into product language. “Another question” fits this behavior. “Never see a repeat” would not.

Treat copying as an action that can fail

A copy button is useful because the question often travels somewhere else: a meeting agenda, a video-call chat, or a host's notes.

The current component waits for navigator.clipboard.writeText before showing Copied. If the clipboard call fails, the page leaves the question visible and asks the person to select it manually. Drawing another question clears both the success and error states.

Without that reset, a new question can inherit the old question's Copied label. The data changed, but the feedback still describes a previous action. Small tools are full of this kind of state dependency.

Context is also a content decision

An office prompt can joke about software or inboxes without asking someone to expose a real conflict. A party prompt can use the snacks and music already in the room. A team prompt can invite a tiny win or a working preference.

The practical review is to read each question with its selected category visible. Could a person answer in one sentence? Does the question depend on backstory strangers will not have? Can somebody pass without becoming the center of attention?

These checks are more useful than making the array longer for its own sake. The randomizer can only select what it has been given.

If you are building a similar tool, try three manual checks: switch categories while watching the displayed question, draw several times to check immediate repeats, and test the clipboard failure state. They cover three different promises: relevance, change, and usable feedback.

Prepared with AI assistance from the project's current implementation. The product link above is our own project.

Building fair higher-or-lower clues for a daily football guessing game

MRZHU — Tue, 08 Sep 2026 01:26:14 +0000

A daily player-guessing game has a tiny interface, but its feedback model can become surprisingly messy. While working on Wordle Cup, I found that the hardest part was not choosing a mystery player. It was making sure every failed guess taught the player something reliable.

Separate comparison types

I started by dividing clues into three groups:

Exact categories such as nationality, club, league, and position.
Ordered values such as age, height, and shirt number.
Contextual facts that depend on a season or roster snapshot.

Exact categories are simple matches. Ordered values need direction as well as color: a miss should say whether the target is higher or lower. Contextual facts need an explicit date, because a club or shirt number can change even when the player record is otherwise correct.

This distinction removed several awkward special cases from the UI. Instead of every field deciding its own behavior, the clue definition now determines how it is compared and displayed.

Normalize before comparing

User input and roster data rarely use identical strings. Accents, initials, suffixes, and common aliases can make a valid guess look invalid. I treat normalization as a data concern rather than a visual patch.

A useful normalization pass can:

trim and collapse whitespace;
compare case-insensitively;
normalize Unicode consistently;
map known aliases to one player ID;
keep the displayed name separate from the lookup key.

The important rule is that normalization helps identify a player; it should not silently merge two different people.

Make clue direction unambiguous

An arrow only works when the question behind it is obvious. For height, “up” can mean the target is taller. For age, it can mean older. For a shirt number, the direction is numerical but not necessarily meaningful football knowledge.

I therefore keep the operator attached to the clue definition and pair the arrow with accessible text. Color alone is not enough, especially on a dense mobile grid.

The comparison result can be modeled as a small, predictable object:

type ClueResult = {
  state: "match" | "miss";
  direction?: "higher" | "lower";
  label: string;
};

That shape is easy to test and keeps rendering logic boring, which is a compliment in a daily game.

Test the boundaries, not just the happy path

The bugs that matter tend to sit at the edges:

equal numeric values;
a player who changed clubs;
two players with similar names;
missing height or jersey data;
a guess that is valid in the database but outside today's pool;
narrow mobile layouts with long club names.

I use fixture players that deliberately trigger each case. A single end-to-end “correct answer” test does not tell us whether the clues remain trustworthy after a roster update.

Show the data scope

The interface should tell players which roster or season it uses. That short note prevents a large class of reports that are really snapshot disagreements. It also makes maintenance more disciplined because an update changes a visible product contract, not just a hidden data file.

I have been applying these ideas to the football guessing games on Wordle Cup. The biggest lesson so far is that difficulty should come from football knowledge, not from unclear comparison rules. Once each guess produces dependable information, a very small game loop becomes much more satisfying to replay.

Keeping a 100-question quiz private in the browser

MRZHU — Sun, 30 Aug 2026 11:40:42 +0000

A quiz about personal experiences creates a simple product question. How much of the answer data needs to reach a server?

For a single-session quiz, the useful answer can be none of it.

The current version of RicePurityTest.party stores progress in sessionStorage. A refresh in the same tab can restore the current question and previous yes or no choices. Closing the tab clears that session. There is no account to create and no answer payload to sync.

The score calculation also stays in the browser. Each checked item subtracts one point from 100. That rule is visible in the site's methodology, so the result does not depend on a hidden model or personality inference.

The share flow needs its own privacy boundary. A result card can be useful without becoming a transcript. The card is drawn locally and contains the score, the number of checked items, a result label, an illustration, and the site name. It leaves out the individual questions.

This design has honest tradeoffs. There is no cross-device resume, no account history, and no way for the site operator to recover a lost session. Those limits are acceptable when the data is sensitive and the product promise is temporary, private use.

The reusable checklist is short.

Keep raw answers in browser storage with the narrowest useful lifetime.
Calculate the result locally when the rules allow it.
Make the scoring rule inspectable.
Generate share assets locally and exclude raw answers.
Explain what hosting and optional analytics can still observe.
Give the visitor a visible reset path.

The full privacy explanation states these boundaries in user-facing language. That page matters as much as the implementation. Privacy claims should describe the system people actually use.

I Turned the How to Fish Creature List Into a Search Tool

MRZHU — Tue, 25 Aug 2026 13:42:28 +0000

A flat table looked like the obvious way to publish a How to Fish fish list. It also became annoying almost immediately.

The game has ordinary catches, bosses, quest triggers, five progression stages, several lure tiers, and two rods in the early data. A player usually arrives with one narrow question. Which bait catches Pike? What can the Scientific Lure pull? Is Tuna a normal catch or part of a boss chain?

Scrolling through a long article makes each of those questions slower than it needs to be. I built a browser-side lookup instead.

The data model follows player questions

Each creature record uses a small set of fields.

type Creature = {
  name: string;
  island: string;
  type: "Regular" | "Boss";
  rod: string;
  bait: string[];
  note?: string;
};

The field named island needs a careful definition. For regular catches, it represents the stage where the relevant lure tier first appears. It does not claim that every creature is physically locked to one island. Bosses still need the correct encounter area and trigger.

That distinction belongs in the interface because it changes how a player reads the result.

One record can answer several searches

Pike is associated with the forest progression stage, the Fishing Rod, and both the Free Lure and Beginner Lure. A search index can combine those values into one lowercase string.

const searchable = [
  creature.name,
  creature.island,
  creature.rod,
  ...creature.bait,
].join(" ").toLowerCase();

The same record now responds to pike, forest, fishing rod, free lure, and beginner lure.

Filters handle the questions that should remain explicit. Island stage, bait, and a bosses-only toggle are easier to understand as controls than as query syntax. The implementation stays small enough to run without a backend.

Bosses should stay in the same index

I considered making a separate creature list for bosses. That would hide useful relationships.

Tuna is caught with the Professional Boss Lure and then used to trigger the Albatross. The Bowhead Whale comes from the Fish Bucket and later triggers the Mutated Bowhead Whale. A player searching either item should see the whole chain even if its records have different types.

Keeping everything in one dataset also makes reverse lookups possible. A lure page can group all creatures that include the same bait value. The fish finder and lure lookup become two views of the same source.

Empty states matter in small tools

A no-result screen should help the player recover. No matches is technically correct and practically weak.

The tool suggests clearing the island or bait filter because filter combinations are the common source of an empty result. It also keeps boss searching opt-in. A player looking for an ordinary fish should not have ten encounters mixed into the list by default.

The current searchable How to Fish fish list contains 34 documented creatures and encounters. It can be filtered by progression stage and bait, with bosses available as a separate view.

Static delivery fits the job

The data changes with game patches, but the query itself does not need a server. Astro generates the page, a short script filters the rendered rows, and every lookup stays in the browser.

That choice gives the page useful HTML before JavaScript runs. Search engines can read the creature names and relationships, while players still get instant filtering. It also avoids turning a small reference tool into an account product.

The difficult part was the wording

Code can filter incorrect data perfectly. The harder work was deciding what each field promised.

I compared the official Steam material with multiple published catch lists, kept patch-sensitive notes beside the affected records, and avoided inventing drop rates that the sources did not support. The interface says Lure or trigger because a Carrot and a Scientific Lure do different jobs even though both occupy the bait field.

Small reference tools earn trust through those distinctions. A fast wrong answer still wastes a cast.

How to Fish.ing is an independent fan project with no affiliation to Dazed Games or Valve. The dataset described here was checked for Patch 1.0.9 on August 25, 2026.

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.