DEV Community: HS Solution

Adding Chinese to a pixel-font Godot game: 4 things that broke

HS Solution — Sun, 01 Nov 2026 17:43:16 +0000

We make Rapid Miner, a 2D pixel mining game in Godot where you dig, fight and build a village underground. Its UI text uses Galmuri9, a Korean pixel font. Adding Simplified Chinese, Japanese, Russian and Brazilian Portuguese looked like a data job: about 1,895 phrases, then done.

The translation file was the easy part. These are the four things that broke, and what fixed them.

1. The font fallback looked wrong, and scaling did not fix it

Galmuri9 has no Chinese glyphs, so we added Fusion Pixel (OFL-1.1) to its fallback list in the import settings. Our first pick was the 12px zh_hans cut.

It rendered. It also looked wrong next to the rest of the UI, because Galmuri9 sits on a 10px grid. A 12px bitmap drawn at size 10 lands between pixels, so you get blur in a game where every other letter is crisp.

We tried the obvious shortcut first: a FontVariation with 1.2x scale. It made things worse. The glyphs grew but the advance width did not, so characters overlapped.

The real fix was to pick the cut that matches the grid. We measured the share of mid-grey pixels in rendered text:

Cut	Size 10	Size 20
Fusion Pixel 12px	36%	19%
Fusion Pixel 10px	0%	0%

The fallback order in Galmuri9.ttf.import is now the 10px cut first, then the 12px cut as a backup. Before shipping that, we checked that all 413 Simplified Chinese characters in the translated text exist in the 10px file. The rule we took away: a pixel font fallback has to share the grid of the main font. Measure grey pixels, do not trust your eyes at 100% zoom.

2. Changing language did not change the screen

Our settings menu called TranslationServer.set_locale() and stopped there. Nothing listened. Panels already on screen kept the old language until you reopened them.

Now there is one path, and every screen goes through it:

func set_language(lang_code: String) -> void:
    if lang_code == current_language and TranslationServer.get_locale() == lang_code:
        return
    current_language = lang_code
    TranslationServer.set_locale(lang_code)
    save_settings()
    language_changed.emit(lang_code)

The upgrade menu, crafting tab, shop, pocket menu and boards connect to language_changed and rewrite their own labels.

3. The fix created a new bug on icon buttons

Our shop reroll button is icon-only. A small component clears its text so only the icon shows. Once screens started rewriting labels on a language change, "Reroll" came back and sat on top of the icon.

The component now listens to the same signal and clears the text again on the next frame with call_deferred, after the button's own code has run. The order matters: clear it in the same frame and the button writes over you.

4. Half-translated strings are worse than English

Some of our strings are built in code with Korean and English side by side. In the new languages, those could produce a line with Korean left in the middle of it. Our rule now: if a translation still contains Hangul, throw it away and show English. A clean English line reads better than a mixed one.

We also stopped checking this by hand. A verify_lang_switch tool drives the real settings dropdown (select() plus item_selected), waits two frames, then walks the visible screens and counts leftover Hangul and leftover English. It also checks the shape of the reroll button, because that bug taught us it can come back.

What we would do first next time

Check the grid size of your font before choosing a fallback.
Build the single set_language path before adding any language.
Write the checker before the translations, so you can count what is left.

The translations were machine-made and that is stated in the game's credits, along with the font licenses. The four new languages are in a development build for now. The public demo is English and Korean.

If you have shipped a pixel-font game in Chinese or Japanese, what did you do about mixed grids?

Rapid Miner on Steam

Gluing leather right in a leathercraft game (Godot devlog)

HS Solution — Fri, 30 Oct 2026 17:41:49 +0000

I make Leather Atelier, a cozy leathercraft game in Godot 4 where you cut, stitch and finish wallets and bags for customers. This week I rebuilt the gluing step. The old version was "brush glue, press, done". The new one follows the order a real bench follows, and modeling it honestly turned out to be more interesting than I expected.

Here is what changed, and the small rules that made it feel right.

The order, as a state machine

The gluing step is now a fixed sequence. Each stage has to finish before the next one unlocks:

Mark the band. Scribe the strip that will be glued with an awl, so glue stays inside the line.
Rough the grain side only. The smooth grain side gets scuffed. The rough flesh side skips this step, because it already grips.
Coat both faces. Brush glue on both pieces. Each face gets its own drying timer.
Check tack with a fingertip. For contact cement, you touch both faces. If nothing transfers to your finger, they are ready.
Lift and lay. Pick up the piece and lower it from one end.
Roll, clean, sand. Press with a roller, wipe the squeeze-out, then sand the edge.

Two glue types, two different rules

The part I got wrong at first: not all glue works the same way.

Contact cement: coat both faces, wait, then join. Once they touch, they grab. So the game makes you test tack before joining, and you cannot slide the piece afterwards.
Wet-bond glue: join first, press, then let it dry.

In code these are two branches of the same step, not two different minigames. The difference is only when the drying timer runs: before the join, or after it.

A 1 mm mistake stays with you

An inner pocket is worked separately from the body panel: both faces coated, then the same pocket is picked up and laid down from one end. If you place it 1 mm off, the game keeps that offset. It shows up later, when the stitching chisel path runs along the edge.

I like this rule a lot. It makes gluing matter without adding a fail screen. You just see your own mistake again two steps later.

Stacking layers on one wall

A card wallet wall can hold interfacing, a base board, lining and card slots, all on the same face. Before this change, each part computed its own height, and some orders left tiny gaps or overlaps.

Now one height model computes the whole stack. Whatever order you glue in, and even after saving and reloading mid-step, adjacent layers meet with 0 ±0.05 mm gap. The test suite runs 24 + 8 stacking combinations for this.

Two smaller fixes

No hands on the work screen. Tools follow your input, and leather is lifted and carried without a drawn hand. Floating hands kept covering the exact spot you needed to see.
A stall when coming back from the sewing machine. Returning to the glue step used to freeze for 886 ms while it rebuilt prep state. It now takes 99 ms.

What I learned

Most of the "feel" came from ordering, not from effects. A fingertip check, a timer per face and a mistake that carries forward did more than any particle effect I tried.

The screenshots above are from a Korean-language dev build. The game also has an English UI, like the stitching bench in the cover image.

Leather Atelier is on Steam as "Coming soon" (no release date yet). If you like slow, hands-on crafting games, a wishlist helps a lot: Leather Atelier on Steam

If you have glued leather yourself, I would like to know which step I still have wrong.

Mac Screen Sharing slow from Windows? What to check, and why Windows has no fast mode

HS Solution — Thu, 29 Oct 2026 15:12:00 +0000

If you connect to a Mac from a Windows PC with a VNC viewer and it feels sluggish, a few causes are quick to fix. One is not: it comes from how Windows has to connect. Here is what I check, in that order.

1. The basics (try these first)

Fewer pixels. Lower the Mac's display resolution, or make the viewer window smaller. This is the fastest change you can make.
Wired if possible. Put the Mac and the PC on Ethernet instead of Wi-Fi, and keep both on the same network.
A quiet Mac. Close heavy apps while connected. Check that the Mac is not in the middle of a Time Machine backup or a software update.

If one of these fixes it, stop here. You do not need anything else.

2. Why Windows has no "fast mode"

Two facts from Apple's own Remote Desktop documentation:

For non-Apple VNC viewers, you have to turn on "VNC viewers may control screen with password". Apple also notes that third-party viewers may not encrypt keystrokes.
The High Performance Screen Sharing mode only works between Apple silicon Macs on macOS Sonoma 14 or later.

So a Windows PC always stays on the standard VNC path. That does not prove VNC is why your connection is slow (network and resolution matter more often). It does mean there is no faster mode to switch on from the Windows side.

3. Changing the protocol instead

Windows already ships with an RDP client, Remote Desktop Connection (mstsc.exe). macOS has no RDP server, so mstsc cannot reach a Mac out of the box.

I work on a small Mac app, RDPyon, that adds an RDP server to the Mac. You install it on the Mac and connect with mstsc from Windows. Nothing gets installed on the Windows side.

To be clear about what I have not done: I have not benchmarked it against Screen Sharing, and I cannot promise it is faster on your network. What changes is the protocol (RDP instead of VNC) and the client (the built-in Windows one instead of a VNC viewer). The free trial is there so you can compare on your own setup.

Limits worth knowing before you try it:


macOS	12.3 or later (Mac audio forwarding needs 13+)
Login window	Not supported. The Mac must already be logged in
Sessions	One viewer, one display at a time
Clipboard	Text and images work. File copy is not guaranteed yet
Network	Same LAN or a VPN

The full checklist, with the Apple sources, is here: Mac Screen Sharing slow from Windows: what to try

If you have a fix that worked for you on the VNC side, I would like to hear it in the comments. Most slow sessions I have seen were solved by step 1.

Sources: Apple Remote Desktop User Guide ("Allow access using VNC") and "Use high-performance screen sharing" (checked October 2026). macOS and Screen Sharing are trademarks of Apple. HS Solution is not affiliated with Apple or Microsoft.

How Korean naming houses use birth elements, and how I built a simplified version in the browser

HS Solution — Tue, 27 Oct 2026 13:26:27 +0000

I'm the developer of this small free tool, so I'll say that up front. It is a Korean name generator that reads the Five Elements in a birthday and suggests three names with Hanja. This post covers the naming idea behind it and the parts that were fun to build. It is for entertainment, and it is a simplified version of the traditional practice.

Try it here if you want to follow along: Korean Name Generator. It is free, needs no sign-up, and runs in your browser.

How naming houses use birth elements

In Korea, some families visit a naming house (작명소) before choosing a baby's name. The people there start from the baby's saju (사주), the "four pillars" of birth year, month, day and hour. Each pillar is two characters, a heavenly stem and an earthly branch, and every character maps to one of five elements: wood, fire, earth, metal, water.

Count the elements across the pillars and you usually get an uneven spread. One element may be absent or thin. The common idea is to pick a name whose characters carry that thin element, so the name "fills the gap".

Names in Korea are usually written in Hangul but also have a Hanja spelling. Each Hanja carries a meaning, and many have a radical that points to an element. 林 (forest) has the wood radical. 江 (river) has the water radical. 鎬 (bright) has the metal radical. This is called 자원오행 (resource element). So the loop is simple to state:

Compute the pillars from the birthday.
Count the five elements.
Find the weak one.
Choose Hanja whose radical belongs to that element.
Check that the sound also works.

Naming houses weigh many more things: strokes, the family's generation character, the parents' wishes, and a judgment about which element helps the person most (용신). I do none of that last part. I only fill the thinnest element, and the page says so.

Step 1: Counting the elements

The calendar math (converting a Gregorian date to pillars) is shared with another small tool of mine, so the name logic starts from the counts. If the birth hour is unknown, the hour pillar is empty and the count uses six characters instead of eight.

The weak-element rule is short:

/* Missing element = an element counted 0; otherwise the smallest count.
   Ties: first the element that feeds the Day Master (인성), then wood→fire→earth→metal→water. */
function missingElement(c,dmElem){
  var min=Math.min.apply(null,c),tied=[];
  for(var k=0;k<5;k++)if(c[k]===min)tied.push(k);
  var mom=parentOf(dmElem);
  return tied.indexOf(mom)>=0?mom:tied[0];
}

The tie-break matters because ties happen often with only six to eight characters. I let the element that feeds the Day Master win, since that is a common reading of what supports the person, and then a fixed order so the answer is stable. This is a design decision, not a ground truth. The result page shows the five counts as bars so you can see what the tool saw.

Step 2: Unknown birth time

Most people outside Korea do not know their birth hour. I made "unknown" the default instead of forcing a guess. With the hour missing, the tool counts six characters and shows a small badge: adding the hour can change the result. That is honest about what the input supports, and it keeps the form short.

Step 3: Sound elements, and where schools disagree

Hanja radicals give the "meaning element" of each character. Korean naming also looks at the initial consonant of each syllable, the 발음오행 (sound element). Here the schools do not agree.

The mapping I use follows the 운해본 reading, the majority convention in naming practice:

ㄱ ㅋ: wood
ㄴ ㄷ ㄹ ㅌ: fire
ㅇ ㅎ: earth
ㅅ ㅈ ㅊ: metal
ㅁ ㅂ ㅍ: water

The 해례본 reading swaps ㅇ ㅎ and ㅁ ㅂ. I did not try to settle that. I picked the majority convention, and the About section of the page states that another reading exists. If you know this area better than I do, I would like to hear which side you would pick and why.

In code the table is a pair of arrays indexed by the Hangul initial, decoded from the Unicode syllable block:

var CHO=["ㄱ","ㄲ","ㄴ","ㄷ","ㄸ","ㄹ","ㅁ","ㅂ","ㅃ","ㅅ","ㅆ","ㅇ","ㅈ","ㅉ","ㅊ","ㅋ","ㅌ","ㅍ","ㅎ"];
var CHO_ELEM=[0,0,1,1,1,1,4,4,4,3,3,2,3,3,3,0,1,4,2];
function jamo(s){var c=s.charCodeAt(0)-0xAC00;return {cho:Math.floor(c/588),jung:Math.floor(c%588/28),jong:c%28};}

A Hangul syllable is 0xAC00 + (initial * 588) + (vowel * 28) + final, so no lookup table of syllables is needed. The tool then prefers name pairs where neighboring sounds feed each other (wood to fire to earth to metal to water) and penalizes pairs where one controls the other.

Step 4: How I chose the Hanja table

A name generator is only as good as its character list, and Hanja is a large field. I wanted a small table I can defend instead of a scrape.

Source: the Unicode Unihan database (version 18.0.0), which is public. I used the radical field (kRSUnicode) for the element, the Korean reading field (kHangul) for the sound, and kDefinition as a reference for English meanings.
Name-use filter: Korea restricts which Hanja may be used in registered names. Unihan marks these in kKoreanName (additional characters, by announcement year) and kKoreanEducationHanja (the 1,800 education characters). I only kept characters found in one of those two fields.
Radicals only when clear: wood (木, 艹, 竹, 禾), fire (火, 灬), earth (土, 山, 田), metal (金, 玉), water (水, 氵, 雨, 冫). Radicals like 日, 石 and 扌 are argued over, so I left them out instead of picking a side quietly.
Common syllables first: I started from syllables people use in given names, which keeps results from looking odd.

The final table has 264 characters: 55 wood, 33 fire, 38 earth, 72 metal, 66 water. Each row looks like this:

{"hanja":"蓮","hangul":"연","element":0,"basis":"艹","meaning":"lotus","tags":"F","src":"edu"}

basis is the radical, so the result card can say why a character was chosen. tags marks a typical gender feel (F, M or N for neutral), which is how the optional "female / male / either" input filters the list. The file header says it is generated by a script, so I fix the candidate list there and regenerate instead of editing rows by hand.

The English glosses are short and based on the Unihan definitions. Some are loose. If one looks wrong to you, tell me.

Step 5: Avoiding famous names

If someone's birthday produces the full name of a well-known singer or actor, that is awkward and a bit misleading. So there is a list of widely known full names (names only, taken from public wikis, no photos or descriptions). Any surname plus given-name combination that matches the list is skipped:

if(isFamous(full))return;

Step 6: Same birthday, same names

Random output has a problem for sharing: refresh and the names change. I wanted the same birthday to give the same three names every time, so the generator seeds its random numbers from the input. A hash turns the input string into a seed, and a small generator makes the sequence:

var rnd=rng(seedOf([inp.y,inp.m,inp.d,hb,g,inp.surname||"auto"].join("|")));

seedOf is FNV-1a and rng is mulberry32, both a few lines. Candidates are shuffled with this seeded random source, then sorted by a score (common names and natural syllable positions score higher, sound clashes score lower), and each Hangul name keeps its highest-scoring Hanja pair. Because every step is deterministic, you and a friend with the same input see the same result. There is no hidden state.

Step 7: Nothing leaves the browser

There is no server-side calculation. The pillars, the picking, the romanization and the share-card drawing all run in your browser. The birthday is not put in the URL, local storage or cookies. The page does send one small anonymous beacon with an event name (such as "view") and the referrer, so I can see whether anyone opens it. The birthday is not part of it.

Romanization follows the Revised Romanization of Korean for given names, syllable by syllable, with a hyphen only where letters could be misread. Surnames use the common spellings (Kim, Lee, Park) instead of the formal forms (Gim, I, Bak), because that is how people write them.

Limits, again

It is for entertainment. It is a simplified version of Korean naming practice, not professional advice.
It does not judge which element suits a person most. It fills the thinnest one.
Sound-element schools differ, and I used one of them.
The Hanja table is small on purpose, so many valid names are not in it.

The page is available in English, Japanese, Spanish, Portuguese and Indonesian, using the same engine and table.

If you want to look at your own result, here is the tool again: devjar.dev/lab/korean-name. Feedback on the character meanings or the sound-element choice is welcome in the comments.

I also make a saju app for Android: Starlit Alley.

This post was written with AI assistance.

Connecting from Windows to a Mac with the built-in Remote Desktop (mstsc)

HS Solution — Fri, 23 Oct 2026 01:54:21 +0000

When I need to reach a Mac from a Windows PC, the usual advice is to install a VNC server on the Mac and a separate client on Windows. That works, but it is one more program to install and explain.

Windows already ships with a remote desktop client, mstsc.exe. It speaks RDP, and macOS has no RDP server. So I built one: RDPyon is a Mac app that accepts RDP connections, so you can use mstsc and install nothing on Windows.

What you need

A Mac on macOS 12.3 (Monterey) or later, Apple Silicon or Intel.
You are logged in on the Mac. You sign in with the Mac owner's short account name and its password.
A network path between the two machines: same network, or a VPN.
An RDPyon license key, or the 14-day free trial (no card required).

Steps

1. Install RDPyon on the Mac. Open the .dmg, drag RDPyon into Applications, and open it.

2. Allow the permissions. Allow what the app asks for on first launch (Screen Recording, Accessibility) in System Settings under Privacy & Security, then restart the app.

3. Find the Mac's address. Click the RDPyon menu bar icon. It shows "Local IP" and "Port". The default port is 3389; "Change Server Port" accepts 1024 to 65535.

4. Open Remote Desktop Connection. Press Windows key + R and run:

mstsc /v:MacAddress:Port /prompt

5. Sign in with your Mac account. Choose "More choices" or "Use a different account", then enter the short account name and your Mac login password. An empty password is rejected.

6. Check the connection. When the Mac screen appears in the window, you are in. A connection bar shows at the top of the Mac screen.

What works

Item	Details
Client	The built-in Windows Remote Desktop Connection (mstsc.exe). Nothing to install on Windows.
Supported Macs	macOS 12.3 or later. Both Apple Silicon and Intel.
Sign-in	Your Mac account's short name and password. The connection uses TLS.
Screen size	The Mac screen is sent at the size of the Remote Desktop window. How well a window resize is followed can vary by client version and settings.
Clipboard	Copy and paste text and images between the Mac and Windows.
Sound	Sends the Mac's sound to Windows. Needs macOS 13 or later. Turn on "Forward Mac Audio" in the menu; it is off by default.
Shortcuts	Windows Ctrl is sent as Mac Cmd, and the Windows key as Mac Ctrl. Ctrl+C and Ctrl+V work as you expect.
Port	Default 3389. You can change it to any value from 1024 to 65535.
Choosing a display	If your Mac has several displays, pick the one to send with "Select Monitor" in the menu.

What does not work

Item	Details
NLA (Network Level Authentication)	Not provided. The Mac account is checked over a TLS connection.
Server-side sign-in screen	None. You enter your credentials in the Remote Desktop Connection window.
Simultaneous connections	One session at a time.
Multiple displays	One display is sent at a time.
Failed sign-ins	After 5 failed attempts in a row from the same IP address, connections are blocked for 30 seconds. The block gets longer with each further failure.
Korean/English key and Hanja key	The Korean/English key switches the Mac input source, and the Hanja key is sent as Option+Return. A keyboard that uses Right Alt as the Korean/English key cannot be told apart from Option. mstsc may also capture the Windows key, Ctrl, or CapsLock first, so behavior can differ by setup.
Locking local input while connected	Not available yet (the menu item is marked "coming soon").
Mac screen lock	If the screen is locked, connecting may fail, so unlock the Mac first. If the screen locks during a session, the connection ends by default ("Disconnect when screen locks" is on).
Copying and pasting files	Not guaranteed yet.
Mac App Store	RDPyon is not distributed through the App Store. You download and install it directly.

Compatibility checklist

Mac

[ ] macOS 12.3 or later.
[ ] You are logged in on the Mac.
[ ] Screen Recording and Accessibility are allowed, and the app was restarted afterwards.
[ ] The Mac screen is unlocked (connecting to a locked Mac may fail, and the session ends on lock by default).
[ ] For sound: macOS 13 or later, with "Forward Mac Audio" on.

Network and port

[ ] Both machines are on the same network, or on a VPN.
[ ] You use the Local IP and Port shown in the RDPyon menu.
[ ] The port in your mstsc command matches the menu (default 3389, custom 1024 to 65535).

Windows and mstsc

[ ] You use the built-in mstsc.exe.
[ ] An .rdp file does not contain enablecredsspsupport:i:0. On Windows 10 that line stops mstsc from asking for TLS and the connection is blocked.
[ ] You entered the short account name, not the full name, and a non-empty password.
[ ] You have not failed 5 sign-ins in a row from the same IP. If so, wait 30 seconds.

Expectations

[ ] You need one session and one display.
[ ] You do not rely on file copy and paste.

Gaps you find are welcome in the comments.

RDPyon costs $19 one-time (up to 2 Macs, 1 year of updates, 30-day refund), and the 14-day trial starts without a card. The full guide, with the same tables, is here: Windows to Mac remote desktop guide

Drafted with AI assistance and checked against the product guide.

Why our Flutter in-app purchases got stuck on "Loading" (and the retry design that fixed it)

HS Solution — Wed, 21 Oct 2026 08:08:58 +0000

In our Flutter app (Android and iOS, in_app_purchase 3.3.1) we shipped a bug where the shop's price list stayed on "Loading" forever. The cause was simple: if connecting to the store or querying products failed once, nothing ever tried again until the user restarted the app.

Here is what was wrong, and the retry design we replaced it with.

What was going on

All billing code lives in a Billing singleton with three states: loading, ready and unavailable. The old refresh() looked roughly like this:

Future<void> refresh() async {
  final gw = _gw;
  if (gw == null || status.value == BillingStatus.loading) return; // not connected, or busy: drop it
  status.value = BillingStatus.loading;
  try {
    if (!await gw.isAvailable().timeout(const Duration(seconds: 15))) {
      status.value = BillingStatus.unavailable; return; // one failure ends it
    }
    final q = await gw.query(ProductIds.all).timeout(const Duration(seconds: 20));
    _products = {for (final e in q.found.entries) e.key: e.value}; // full overwrite
  } catch (e) { status.value = BillingStatus.unavailable; } // no retry
}

That has four holes:

A failed connection at startup is permanent. If creating the gateway threw at launch, _gw stayed null, and every later refresh() returned on the first line.
Requests during a query were dropped. A refresh that arrived while loading was simply ignored.
No automatic retry. isAvailable() == false, a timeout and an exception all ended in unavailable. The only retry was opening the shop screen.
Partial results overwrote good data. A query that returned only some products could erase products we already had.

Temporary store failures are common: the Play Store app updating itself, a network blip. The real problem was that one failure meant "Loading" forever.

The fix

1. Reconnect on the next attempt

If the connection fails at startup we don't give up. ensureStarted() reconnects on every new attempt, and syncs past purchases once it connects.

2. Don't drop requests during a query — queue one more

Future<void> refresh() {
  final cur = _inflight;
  if (cur != null) { _again = true; return cur; } // run once more after this one
  // ...
}

However many times it is called, at most one extra query runs after the current one.

3. Merge results instead of overwriting

_products = {..._products, ...found}; // a partial answer can't erase known products

4. Retry automatically at 5 s → 30 s → 2 min, then stop

static List<Duration> retryDelays =
    const [Duration(seconds: 5), Duration(seconds: 30), Duration(minutes: 2)];

void _afterRefresh() {
  if (!needsRetry) { _retryStep = 0; return; } // got everything: reset
  if (_retryStep >= retryDelays.length) return;  // stop after 3
  _retryTimer = Timer(retryDelays[_retryStep++], () => unawaited(refresh()));
}

We cap it on purpose. On devices where the store really is unavailable (no Play Store, for example), retrying forever only burns battery and data. Timeouts stay at 15 s for the connection check and 20 s for the query.

5. Let user actions and app resume trigger a retry

If the three automatic tries fail, four other things trigger a retry: app resume, opening the shop, pressing a buy button, and a manual retry.

// main.dart
AppLifecycleListener(onResume: Billing.i.onResume);

// billing.dart
void onResume() { if (needsRetry) unawaited(retryNow()); } // only when products are missing

We don't listen to a connectivity stream. Timers handle the automatic part; everything else comes from the user or from resume. A manual trigger resets the retry schedule to zero. If the buy button is pressed while billing isn't ready, it calls retryNow() and then continues straight into the purchase.

6. Stop saying "Loading"

We split failures into connect, timeout and notFound, and the screen now says "Connecting to the store… / Retry" instead of "Loading". With "Loading", users can't tell whether waiting will help or whether the item is gone. The first time each failure type appears we log an analytics event, so we can see later which failures are common.

Takeaways

Write billing setup so it can be redone any number of times, not "once at startup".
Don't drop requests that arrive mid-query; queue exactly one more.
Merge query results so a partial answer can't delete known products.
Cap automatic retries; leave the rest to app resume and user actions.
Don't show a vague state like "Loading" when you know what failed.

This shipped in version 1.1.1 on Android and iOS. We haven't yet verified every real-payment path in production, so if your setup is similar, try it with a Play Console license tester: toggle airplane mode and force-stop the Play Store app while the shop is open.

Disclosure: I'm the developer of this app, **Starlit Alley: Tarot & Saju* (HS Solution). Core readings (saju, tarot, dream reading) are free, with no sign-up and no ads. Google Play*

This post was drafted by an AI agent from our repository and fix notes. The code and numbers are quoted from the actual repository.

Scope creep is not the problem. Unwritten change requests are.

HS Solution — Tue, 20 Oct 2026 18:17:38 +0000

Most scope fights I have seen on client projects did not start with a big request. They started with a small one, accepted in a chat message ("sure, I'll try"), and nobody wrote down what it moved. Three weeks later the deadline has drifted and neither side can say which request caused it.

The fix is boring and it works: every change after kickoff goes on a one-page change request with a number. Here are the seven fields we put on that page, from the developer side of the table.

The seven fields

1. What changes, in screen terms. Not "improve search", but "add a date-range filter to the order list; picking a start and end date shows only orders in between." Test: ask someone new to describe the finished screen from your sentence.

2. Why (one line). "At month end the manager only wants last month's orders but has to scroll the whole list." Knowing the purpose is what lets you, the developer, say "there is a cheaper way."

3. What it touches. Screens modified, queries modified, new screens, data-structure changes, integrations. This is where "it's just one field" turns into "that's a migration" — say it before work starts, not halfway.

4. Effect on schedule, in dates. "Interim demo moves 2 days; final delivery unchanged." Send the updated overall schedule with the same CR number, so schedule versions line up with requests.

5. Effect on cost, with a basis. Not an amount pulled from the air — the basis (workload, agreed rate) and a reference to the quote. "To be discussed" is not an answer; don't start on it.

6. What gets dropped or deferred. If the client wants the date and budget unchanged, something else moves. Put the trade on the same page: "Admin Excel export moves to phase two." Check it isn't something they marked as core.

7. Who approves, and how. Both contacts reply "proceed" by email (or sign the doc). Work starts after that, not before. Number, date, approver name.

A filled-in (made-up) example

Field	Entry
Number / date	CR-003 · requested by client contact
Change	Date-range filter on the order list
Purpose	See only last month's orders at month end
Impact	Order list screen, order query. No new screens, no schema change
Schedule	Interim demo +2 days; final delivery unchanged
Cost	Extra; basis = 1 screen + 1 query change, amount per attached quote
Trade-off	Admin Excel export deferred to phase two
Approval	Starts after both contacts approve by email

Not everything needs a CR

Sort first. If something agreed in the requirements doesn't work, that's a defect — you fix it, no CR. Wording and color tweaks inside an agreed screen usually go in a batch. A new behavior, a new screen, or anything that touches data or integrations gets a number. Where exactly the line sits depends on your contract wording, so agree on the sorting rule at kickoff, not during the first argument.

What I like about this as a developer: it turns "the client keeps adding stuff" into a list you can both point at. Saying yes gets cheaper because every yes has a price tag and a date next to it.

The full guide (with the sorting table and how each field fails if you skip it) is here: How to write a change request. It's general information, not legal advice.

How do you handle mid-project requests — a numbered doc, tickets, or just a running chat thread?

Chat Folders for Claude: sidebar folders, and exporting a virtualised chat to Markdown

HS Solution — Tue, 20 Oct 2026 11:45:20 +0000

I use claude.ai a lot, and the sidebar is one long list of chats. There are no folders, so I could not group chats by project. I built a small Chrome extension, Chat Folders for Claude, to add that. This post covers what it does and the parts that were harder than expected.

Not affiliated with Anthropic. This is an independent project, not endorsed by or connected to Anthropic.

What it does

Adds a Folders section to the claude.ai sidebar: create, rename, delete, collapse.
File the open chat into a folder (a chat lives in one folder at a time). Deleting a folder never deletes a conversation.
Search chat titles (not message text).
Export the open chat as a Markdown file, or export a folder as a list of titles and links.

The hard part: the message list is virtualised

The Markdown export looked simple: read the messages, convert to Markdown, save a file. But the chat page only keeps a few message rows in the DOM at a time (roughly 3 to 7). If you read the page as it is, you get the part you are looking at and nothing else.

Each row has a data-index, so the export works like this:

Find the scroll container of the message list.
Jump to the top, then scroll down in steps of 0.8 of the visible height so consecutive views overlap.
Wait a moment after each step for the list to draw the new rows, and collect each row once, keyed by data-index.
Sort by index, convert to Markdown, and restore the original scroll position, even if something fails.

If fewer messages were read than the chat has, the file says so ((n of N messages captured)) instead of pretending it is complete. The site markup can change without notice, so the extension looks for structure rather than class names. If it cannot find what it needs, the feature hides itself instead of producing a broken file.

Privacy and permissions

Two permissions only: storage and host access to https://claude.ai/*.
No network requests: no server, no analytics, no remote code. It does not call the site's internal APIs and does not read cookies.
Folders are saved in chrome.storage.local on your device. For each filed chat it stores the ID, the title as shown in the sidebar, and the time you added it.
Message text is read only when you press an export button, only for the chat you have open, and it becomes a file your browser saves. The extension does not keep it.

The repository has no build step and no dependencies, and there are unit tests for the storage logic, search, Markdown conversion and the scrolling collector (against a fake virtualised list).

Note: the screenshot above was made on a stand-in page with invented chats, not on a real account.

Try it

Chrome Web Store: Chat Folders for Claude
Details: devjar.dev/lab/chat-folders

It is early (version 0.2.2). If the sidebar layout changes and something breaks, I would like to hear about it in the comments.

The handover package: 10 things a client should hold when your project ends

HS Solution — Sun, 18 Oct 2026 21:08:05 +0000

"It works on the demo server" is not the same as "the client can keep running it without you."

Most handover pain we've seen doesn't come from bad code. It comes from things that were never written down or never moved out of the developer's accounts. Here is the 10-item package we put together before the last invoice, with one line on why each matters and one way to verify it.

The 10 items

1. Repository in the client's account
Why: if the code lives only in your personal GitHub, the product becomes unfixable the day you're unreachable.
Check: the client clones from their org and sees the full commit history, not a squashed zip.

2. Domain, cloud, app store and payment accounts in the client's name
Why: only the account owner can renew, cancel or transfer. Store publisher and merchant accounts are often hard or impossible to move later.
Check: the client logs in to each console themselves and sees their own name, email and payout account.

3. Admin credentials, handed over safely
Why: without admin access they can't change their own product.
Check: share through a password manager, not chat or email. The client rotates everything immediately and disables your account.

4. A complete .env.example
Why: without the DB address and third-party keys nobody can rebuild the environment.
Check: every variable name is listed with a one-line description; the real values are sent separately and bring up a fresh environment.

5. A run-and-deploy guide that works without you
Why: if the next developer's first question is "how do I deploy this?", that's paid hours.
Check: give the doc alone to another developer on a blank machine. Can they get it running without messaging you?

6. Backup and a tested restore
Why: a backup that has never been restored is a hope, not a backup.
Check: say where and how often backups go, then restore the latest one into a test environment together.

7. Paid services and monthly cost table
Why: email sending, maps, AI calls and servers tend to surface for the first time on a bill after handover.
Check: one table with service, purpose, billing cycle and expected monthly cost, and the total roughly matches what you quoted.

8. Licence list (open source, images, fonts)
Why: an asset that doesn't allow commercial use can mean takedowns later.
Check: name, source and licence type per item, plus receipts for anything purchased.

9. Warranty window and how to report bugs
Why: the first bug after launch is stressful if nobody knows where to send it.
Check: start/end dates of the free-fix period, a reporting channel and a target reply time, in writing.

10. A handover memo for the next developer
Why: code doesn't explain why it's built this way or which parts are fragile.
Check: at least one page on structure, known issues, postponed work and "don't touch without reading this" areas.

Order matters

Go through the list before the final payment. After that, everyone has less leverage to chase missing pieces. If something can't be delivered on the day, write down (email is fine) what is missing and when it will arrive.

This is general practice, not legal advice. Contract wording around source code and IP is worth a professional review.

The full checklist, with links to the related guides on contract clauses and acceptance testing, is here: Handover checklist: 10 things to receive when an outsourced project ends

We're a small dev studio in Korea (HS Solution) and we write these checklists from the client side, so we're curious what's on your handover list. What's the one item you've had to chase after a project was "done"?

Your zodiac animal does not change on January 1: computing Ipchun in Dart

HS Solution — Sun, 18 Oct 2026 13:37:39 +0000

Ask a Korean friend their birth year and you will often get their tti (띠), the zodiac animal, instead. When we built the birth-chart engine for our Korean saju app, the animal turned out to be the first thing that broke: plenty of people born in January or early February got the wrong one.

The reason is that the zodiac year does not start on January 1. In saju it starts at Ipchun (입춘, 立春), the "start of spring" solar term. Here is how we compute it, and where the method stops being exact.

Why "Feb 4" is not enough

Most tables say Ipchun is "around February 4". That is true, but it is a moment, not a date. It is the instant the Sun reaches ecliptic longitude 315°, and it drifts by about six hours a year until a leap year pulls it back.

From the table above: in 2021, 2025 and 2029 it lands late on February 3 in Korea time. In 2020 and 2024 it lands in the evening of February 4. So a baby born on the afternoon of Feb 4, 2024 still belongs to the previous year's animal (Rabbit), while one born a few hours later is a Dragon.

Two more traps:

Seollal is a different rule. In everyday life many Koreans switch the animal at the Lunar New Year (late January to mid-February). Saju uses Ipchun. The two rules disagree for birthdays that fall between them.
Time zone history matters. Korea used UTC+8:30 from 1954-03-21 to 1961-08-09, and had daylight saving time in the summers of 1987 and 1988. If you convert a birth time with a flat UTC+9, edge cases move.

The calculation

We do not ship an almanac table. We compute the solar terms with the low-precision solar position from Jean Meeus, Astronomical Algorithms (chapter 25), then solve for the moment the longitude hits the target with a few Newton-style steps.

/// Apparent ecliptic longitude of the Sun (degrees, 0-360)
double sunLongitude(double jd) {
  final t = (jd - 2451545.0) / 36525;
  final l0 = 280.46646 + 36000.76983 * t + 0.0003032 * t * t;
  final m = _rad(357.52911 + 35999.05029 * t - 0.0001537 * t * t);
  final c = (1.914602 - 0.004817 * t - 0.000014 * t * t) * math.sin(m)
      + (0.019993 - 0.000101 * t) * math.sin(2 * m)
      + 0.000289 * math.sin(3 * m);
  final omega = _rad(125.04 - 1934.136 * t);
  return _norm(l0 + c - 0.00569 - 0.00478 * math.sin(omega));
}

/// Moment (UTC) when the Sun reaches [deg], searched near [approx]
DateTime termMoment(double deg, DateTime approx) {
  var jd = _jd(approx);
  for (var i = 0; i < 8; i++) {
    var diff = deg - sunLongitude(jd);
    diff = ((diff + 540) % 360) - 180; // wrap to -180..180
    jd += diff / 360 * 365.2422;       // ~1 degree per day
    if (diff.abs() < 1e-6) break;
  }
  return _fromJd(jd);
}

DateTime ipchun(int year) => termMoment(315, DateTime.utc(year, 2, 4, 3));

/// Saju year: before the Ipchun instant, it is still last year.
int sajuYearAt(DateTime utc) =>
    utc.isBefore(ipchun(utc.year)) ? utc.year - 1 : utc.year;

After that, the animal is just an index: (sajuYear - 4) % 12 gives 0 for Rat (1984 was a Rat year). The same function with longitudes 285°, 345°, 15° and so on gives the 12 month boundaries, which saju needs for the month pillar.

Where it stops being exact

Be honest about the error bar. This formula is good to roughly 0.01° of solar longitude, which is about 15 minutes of time. Checked against published almanac times, our results land a few minutes off: for 2024 we get 17:21 KST, the commonly published Ipchun time is 17:27. We ignore ΔT (about a minute these days), which is smaller than that error.

For an entertainment app that is fine for almost everyone. It is not fine for someone born within ~15 minutes of the boundary, so for those births the honest answer is "check a full ephemeris". If you need that precision, use the full VSOP87 theory or a JPL ephemeris instead of the short series.

Try it

If you want to see the result on your own birthday, our app Starlit Alley: Saju & Tarot does the full four-pillar chart with this engine (Android, free to try): Google Play.

For the plain birth-year table from 1948 to 2031 and the Seollal vs Ipchun rule in non-code form, see our guide Korean Zodiac Animals by Birth Year.

Saju and zodiac readings are cultural entertainment, not predictions.

Before the final invoice: a 10-point acceptance checklist for outsourced software

HS Solution — Fri, 16 Oct 2026 22:33:27 +0000

Most outsourcing disputes I've seen don't start during development. They start the week after the last invoice is paid, when the client discovers that the server is on the developer's personal account, the email service runs on someone else's API key, and nobody wrote down how to deploy.

We run a small development studio, so we sit on the delivering side of this. Over time we turned "what should be true before the final payment" into a written acceptance checklist that we send to clients before delivery. It protects both sides: the client knows exactly what "done" means, and we get a clear acceptance date instead of an open-ended "one more thing."

Here is the short version. If you freelance, feel free to copy it into your own contracts.

The 10 checks

1. Every feature, one row in a table. Copy the features from the quote or spec into a table and mark each row pass or needs fixing. Clicking around the obvious screens is how missing features slip through.

2. Real devices, real browsers. Run the core flows on what users will actually use: an iPhone with Safari, a mid-range Android phone, Chrome on desktop. "Works on my machine" is not acceptance.

3. The unhappy paths. Submit an empty form, type a wrong password, go offline. A clear message is a pass. A blank page or a raw stack trace is a fix.

4. Accounts in the client's name. Admin panel, server, database, email sending, maps, payments: each should sign in with the client's own email, not a borrowed developer account. Change passwords after handover.

5. Source, repo, domain, server. The full source lives in a repository the client owns. The domain registrant and hosting account are in the client's name. Compare against the contract line by line.

6. Deployment is written down. Install, configure, build, upload, restart. If another developer could ship a new version from that document alone, it's enough. Secrets go over a separate channel, never in the README.

7. Personal data and backups. What is stored where? Are passwords hashed? Does the privacy policy match what the code actually does? Do backups run automatically, and has anyone ever restored one?

8. The bug-fix window is in writing. How many days of free fixes, starting from which date (acceptance or delivery), and what counts as a bug versus a new feature request.

9. Licenses for fonts, images and libraries. A list of every font, photo and icon, whether commercial use is allowed, and whether credit is required. "Found it on Google Images" turns into a legal email later.

10. Basic performance. How fast the first screen appears on mobile data, whether images are oversized, whether text is readable on a phone. If the contract has numbers, test against those.

Tie the final payment to acceptance

This is the part that actually prevents the arguments. Put three things in the contract:

a review period (for example, 7 days after delivery),
how fix requests are filed (in writing, against the checklist rows),
and that the final payment is due a few days after the acceptance date, which is the day every row reads pass.

The filled-in table becomes the acceptance record. No one has to remember what was agreed in a call.

This is general information, not legal advice. Have important contracts reviewed by a professional.

Full version

The longer guide has an example for each check and sample contract wording: Acceptance Checklist: 10 Things to Verify Before the Final Payment. It's on our studio site (HS Solution), so yes, that's our page.

What's on your own handover list that isn't here? I'm especially curious how other freelancers handle third-party API keys.

This post was written by an AI assistant from the checklist we use in our own projects.

One modulo gives you a Korean Saju day pillar (and Seoul's 1900 time zone breaks it)

HS Solution — Fri, 16 Oct 2026 16:35:20 +0000

In Korean Saju (the "Four Pillars" of birth), the day pillar is the one part of the chart that is pure arithmetic. No solar terms, no lunar calendar, no lookup tables — just a 60-day cycle that has been running without a break for a very long time.

So it should be a one-liner. It mostly is. But the obvious JavaScript version gives the wrong answer for every date if your machine is set to Korean time. Here is the math, the bug, and the fix.

The 60-day cycle

Each day gets a pair: one of 10 Heavenly Stems and one of 12 Earthly Branches. Both advance by one every day, so the pair repeats every lcm(10, 12) = 60 days.

const STEMS    = "甲乙丙丁戊己庚辛壬癸"; // Gap, Eul, Byeong, Jeong, Mu, Gi, Gyeong, Sin, Im, Gye
const BRANCHES = "子丑寅卯辰巳午未申酉戌亥"; // Ja, Chuk, In, Myo, Jin, Sa, O, Mi, Sin, Yu, Sul, Hae

Because both counters move together, a single index i in 0..59 is enough: the stem is i % 10 and the branch is i % 12. Index 0 is 甲子 (Gap-ja), index 59 is 癸亥 (Gye-hae).

Pick an anchor, count days

All you need is one date whose pillar you know. 31 January 1900 was 甲辰 (Gap-jin), index 40. From there:

function dayPillar(y, m, d) {
  const days = Math.round(
    (Date.UTC(y, m - 1, d) - Date.UTC(1900, 0, 31)) / 86_400_000
  );
  const i = (((40 + days) % 60) + 60) % 60; // works for dates before 1900 too
  return STEMS[i % 10] + BRANCHES[i % 12];
}

dayPillar(2000, 1, 1);  // "戊午"  (Mu-o, 55th day)
dayPillar(2000, 1, 2);  // "己未"  (Gi-mi)
dayPillar(1949, 10, 1); // "甲子"  (start of a cycle)
dayPillar(2026, 10, 17); // "甲子" — also a cycle start

Two details matter:

((x % 60) + 60) % 60 — JavaScript's % keeps the sign, so dates before the anchor would give a negative index without it.
Date.UTC and Math.round — this is the part people skip.

The bug: local time + `Math.floor`

The "obvious" version uses local dates:

// Don't do this
const days = Math.floor((new Date(y, m - 1, d) - new Date(1900, 0, 31)) / 86_400_000);

I ran both versions for 15 May 1990 under different TZ settings:

TZ	local-date version	UTC version
UTC	庚辰	庚辰
America/New_York	己卯 (wrong)	庚辰
Europe/London	己卯 (wrong)	庚辰
Asia/Seoul	己卯 (wrong)	庚辰

New York and London are wrong because of daylight saving: 15 May is in summer time, 31 January is not, so the gap is one hour short of a whole number of days, and Math.floor drops a day. In January the same code happens to work, which is why this bug survives testing.

Seoul is worse. Daylight saving isn't the problem there. In the time zone database, Seoul in 1900 was on local mean time, UTC+8:27:52, not today's +9:00. So the gap between any modern date and the 1900 anchor is about 32 minutes short of a whole day:

TZ=Asia/Seoul  (new Date(1990,4,15) - new Date(1900,0,31)) / 864e5
→ 32975.9777

Math.floor turns that into 32975, and every date comes out one pillar early. The machine most likely to run a Korean astrology calculator is the one where the naive code always fails.

The fix is boring: do calendar math on calendar dates. Date.UTC has no time zone and no DST, and Math.round absorbs any leftover floating-point dust.

What the day pillar does not handle

Year and month pillars are a different problem. They change at solar terms (the year at Ipchun, around 4 February), not on 1 January, so you need an astronomical table or a good library for those.
The 23:00 boundary. Some schools start the new day at 23:00 (the start of the 子 double hour), others at midnight. My calculator uses midnight on the calendar date and says so on the page. Whichever you pick, document it, because users will compare results across apps.
Birth time zone. Use the calendar date where the person was born. Don't use the date converted to the server's zone.

Try it

I put this exact function behind a small free page that shows your day pillar and what the Day Master element traditionally means: Find Your Day Master. It is entertainment and cultural reference, not prediction.

The same rule runs inside our Android app Starlit Alley, which builds the full chart (Google Play). I'm part of the small team that makes it.

If you've hit the Seoul LMT offset in other date code, I'd like to hear where it showed up.

This post was drafted with AI assistance. Every result in it, including the table, came from running the code above in Node.js.

DEV Community: HS Solution

Adding Chinese to a pixel-font Godot game: 4 things that broke

1. The font fallback looked wrong, and scaling did not fix it

2. Changing language did not change the screen

3. The fix created a new bug on icon buttons

4. Half-translated strings are worse than English

What we would do first next time

Gluing leather right in a leathercraft game (Godot devlog)

The order, as a state machine

Two glue types, two different rules

A 1 mm mistake stays with you

Stacking layers on one wall

Two smaller fixes

What I learned

Mac Screen Sharing slow from Windows? What to check, and why Windows has no fast mode

1. The basics (try these first)

2. Why Windows has no "fast mode"

3. Changing the protocol instead

How Korean naming houses use birth elements, and how I built a simplified version in the browser

How naming houses use birth elements

Step 1: Counting the elements

Step 2: Unknown birth time

Step 3: Sound elements, and where schools disagree

Step 4: How I chose the Hanja table

Step 5: Avoiding famous names

Step 6: Same birthday, same names

Step 7: Nothing leaves the browser

Limits, again

Connecting from Windows to a Mac with the built-in Remote Desktop (mstsc)

What you need

Steps

What works

What does not work

Compatibility checklist

Why our Flutter in-app purchases got stuck on "Loading" (and the retry design that fixed it)

What was going on

The fix

1. Reconnect on the next attempt

2. Don't drop requests during a query — queue one more

3. Merge results instead of overwriting

4. Retry automatically at 5 s → 30 s → 2 min, then stop

5. Let user actions and app resume trigger a retry

6. Stop saying "Loading"

Takeaways

Scope creep is not the problem. Unwritten change requests are.

The seven fields

A filled-in (made-up) example

Not everything needs a CR

Chat Folders for Claude: sidebar folders, and exporting a virtualised chat to Markdown

What it does

The hard part: the message list is virtualised

Privacy and permissions

Try it

The handover package: 10 things a client should hold when your project ends

The 10 items

Order matters

Your zodiac animal does not change on January 1: computing Ipchun in Dart

Why "Feb 4" is not enough

The calculation

Where it stops being exact

Try it

Before the final invoice: a 10-point acceptance checklist for outsourced software

The 10 checks

Tie the final payment to acceptance

Full version

One modulo gives you a Korean Saju day pillar (and Seoul's 1900 time zone breaks it)

The 60-day cycle

Pick an anchor, count days

The bug: local time + Math.floor

What the day pillar does not handle

Try it

The bug: local time + `Math.floor`