DEV Community: HS Solution

Keeping a synthetic voice in sync with a YouTube video: seeks, speed caps and ducking

HS Solution — Fri, 06 Nov 2026 23:30:14 +0000

We build DubbingMate, a tool that reads a YouTube video's captions out loud in another language.

Getting the words right turned out to be the easy part. Keeping a synthetic voice in step with a video that the viewer pauses, seeks and speeds up was most of the work.

Here is what our sync code does today, with the numbers we ended up using.

The panel on the right: dubbing is on, the original audio is ducked to 20%, the dub plays at 100%.

1. Captions are the timeline

Every caption cue has a start and an end time. That is the only clock we trust. Before playback we clean the cue list: if a cue ends after the next one starts, we cut its end to the next start, so two lines never compete for the same second.

If a video has no captions at all, there is nothing to dub. We do not run our own speech recognition, and the app says so instead of guessing.

2. The voice is often longer than the cue

A sentence that takes 2.1 seconds in English can take 3 seconds in Japanese. We handle the overflow in steps, cheapest first:

Step	What we change	Limit
1	Speak faster	1.5x for the local neural voice, 1.9x for the browser's Web Speech voice
2	Slow the video slightly	down to 0.65x (local voice)
3	Emergency speed-up	1.9x
4	Skip the line	only if we fall more than 3 s behind the cue end

The order is a judgement call. Our reasoning: a slightly slower video is easier to accept than a squeaky voice, and a missing line loses content, so skipping comes last. There is also a constant-speed mode where we pause the video for a moment instead of changing any speed.

3. Detecting seeks without trusting events

We poll the player every 250 ms. If currentTime jumps by more than 2 seconds between polls, we treat it as a seek: cancel the current utterance, wait 300 ms (people often drag the scrubber in several hops), then restart from the cue at the new position.

Playback-rate changes are picked up by the same poll. Pause and resume come from player state changes, and an ad starting resets the queue.

4. Ducking, and defending it

When dubbing turns on, we save the original volume and drop it to 20%. When it turns off, we restore it. If something else changes the volume while dubbing is on, a volumechange listener puts it back, so the dub stays on top.

The local voice output is peak-normalised to 0.7, so a quiet sentence and a loud one sit at a similar level.

5. Two voices, two budgets

The default is the browser's built-in Web Speech voice: zero download, but its timing is less predictable. The other option is a local ONNX voice (Supertonic) running in an offscreen document. We control its output and can measure its length, which is why its speed cap is lower: we would rather slow the video than distort it.

What we would tell anyone building this

Treat caption timestamps as the source of truth, not the audio element.
Poll for seeks. Debounce them.
Rank your fixes by how much a viewer notices them, and skip content last.

If you want to try it: DubbingMate. All features are free for 72 hours from your first dub, no card. After that it is a one-time purchase (price on the site). Limits: videos without captions cannot be dubbed, and translation quality depends on the captions.

Questions about the sync logic are welcome in the comments.

Reach your Mac from Windows outside the office without opening port 3389

HS Solution — Fri, 06 Nov 2026 15:28:31 +0000

Your Windows PC reaches your Mac with Remote Desktop Connection (mstsc.exe). Then you leave the building, and that address goes nowhere.

The quick fix people search for is "forward port 3389 on the router". Please don't. Here is the setup we document instead, with the limits we know about.

mstsc connected to a Mac over the local network. Over a VPN only the address you type changes (we have not tested that route end to end yet, see below).

Why not forward 3389?

Port 3389 is one of the most scanned ports on the internet. If you forward it from your router to the Mac, anyone can try to log in to that machine, all day. A VPN gives the Windows PC a private path to the Mac, so the router stays closed.

The setup: Tailscale on both devices

Tailscale is one VPN that is easy to set up for this. Any VPN that gives the Windows PC a route to the Mac works the same way.

On the Mac, install Tailscale and sign in.
On the Windows PC, install Tailscale and sign in to the same Tailscale account. Keep it running on both.
Find the Mac's Tailscale address. It starts with 100.. (In RDPyon, the menu bar item "Enter this address in mstsc" lists it with a "VPN" label and copies ip:port. The default port is 3389.)
On Windows, open mstsc and paste that address into the Computer field.

That's it. No port forwarding, no dynamic DNS.

If it does not connect

Both devices online in Tailscale? Both must be running and signed in to the same account. Copy the 100.x address again; don't type it from memory.
Mac firewall. In System Settings > Network > Firewall, make sure "Block all incoming connections" is off, or that the RDP server app is allowed.
The Mac must be awake and logged in. It fails with the lid closed, and right after a reboot before FileVault is unlocked. Before you leave: power adapter in, lid open.
Slow? Tailscale connects devices directly when it can. When it can't, traffic goes through its DERP relay, which can be slower.

The licence catch

Tailscale's Personal plan is free (up to 6 users, unlimited devices per user), but it is for non-commercial use only. If this is for company work, use a paid Tailscale plan or your company VPN. Check Tailscale's pricing page for the current terms.

What we have not tested yet

We have tested mstsc to a Mac on the local network many times. We have not yet tested the Tailscale route end to end: neither the connection itself nor latency, direct or via DERP. We'll add results when we have them, rather than guess.

Where the Mac side comes from

Disclosure: we build RDPyon, a small Mac app that lets the built-in Windows mstsc connect to a Mac over RDP, with no account or relay server of its own. It's a paid app (one-time purchase) with a free trial.

The full guide, with the same steps and an FAQ, is here: https://devjar.dev/go/G-1389

If you already reach a Mac from outside another way, we'd like to hear which VPN you use and what broke.

One forged header switched off our per-IP rate limit

HS Solution — Fri, 06 Nov 2026 12:53:16 +0000

Our website's AI chat limited requests per IP, but one forged header made every request look like a new visitor.

The chat is on our outsourcing page. A visitor describes a project and gets a rough estimate and, if they ask, a working preview site. There is no sign-up, so the only thing between that chat and a script is a per-IP rate limit.

On November 2 we found that the rate limit trusted a header any client can set. Here is what was wrong, how we fixed it in one line, and how we checked the fix in production without touching the server.

The bug: one header too many

The chat server is plain Node (http.createServer) behind nginx. The line that picked the client IP looked like this:

// before
const ip = clean(req.headers["cf-connecting-ip"] || req.headers["x-real-ip"] || req.socket.remoteAddress, 64);

CF-Connecting-IP is the header Cloudflare adds with the real visitor address. The demo-booking server next to it even had a comment saying "we are behind Cloudflare, so the real address is in cf-connecting-ip".

The problem: this site is not behind Cloudflare. DNS points straight at our own server, and responses carry no cf-ray header. So no proxy sets or strips CF-Connecting-IP. Whatever the client sends arrives as is.

That means a script can send a new fake CF-Connecting-IP on every request and look like a new visitor every time. The per-IP limits (for example, 3 new chat rooms per minute) never fire.

Reproducing it locally

We ran the old and the fixed chat.mjs side by side and sent 8 POSTs from the same client, changing only the forged header each time:

Before the fix, all 8 got 200. After the fix, the 4th request got 429, which is the "3 new rooms per minute" limit doing its job.

There was a second layer we were glad to have: a global cap on visitor messages per day. It would have stopped unlimited growth. But with spoofed IPs, one script could fill that global cap by itself, and then real visitors would get 429 busy. A per-IP limit that can be bypassed turns a global safety cap into an easy way to shut everyone out.

The fix

// after
const ip = clean(req.headers["x-real-ip"] || req.socket.remoteAddress, 64);

nginx sets X-Real-IP itself, and it overwrites whatever the client sent:

location ^~ /api/chat {
    proxy_pass http://127.0.0.1:<port>;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

The Node process only listens on 127.0.0.1, so the only way to reach it is through nginx. That is what makes X-Real-IP trustworthy here, not the header name.

We made the same change in the demo-booking server and the contact form, and added a test to each that rotates the forged header and expects 429:

test("rotating a forged CF-Connecting-IP does not lift the per-IP limit", async () => {
  const codes = [];
  for (let i = 0; i < 5; i++) {
    codes.push((await api("POST", "/api/chat/send", body, {
      ip, headers: { "cf-connecting-ip": `9.9.${i}.1` },
    })).status);
  }
  assert.deepEqual(codes, [200, 200, 200, 429, 429]);
});

All 24 tests in the chat and demo suites pass.

Checking production without shell access to the limiter

We did not want to restart anything or read server memory to prove the fix. Instead we used a request that changes nothing: polling with an unknown session ID. It returns 404, writes nothing, but still counts toward the poll limit (90 per minute).

We sent 92 of them, each with a different forged CF-Connecting-IP, X-Real-IP and X-Forwarded-For. The first 429 came at request #91. All three headers were ignored, and the limit counted our real address. The only cost was our own IP getting a short timeout.

The part worth keeping

The same header is right in one deployment and wrong in another. In another of our apps, traffic really does go Cloudflare → nginx → app. There, X-Real-IP would be a Cloudflare edge address that changes on almost every request, so a limit based on it would be useless. We read CF-Connecting-IP instead, but only when the TCP peer is loopback (our own nginx); a direct connection that sends the header is ignored:

export function requestIp(req) {
  const peer = (req.socket && req.socket.remoteAddress) || '';
  if (isLoopback(peer)) {
    const cf = cfIp(req.headers && req.headers['cf-connecting-ip']);
    if (cf) return cf;
  }
  return req.ip || peer || '';
}

So the rule we follow now is simple: trust an IP header only if something you control sets it, and only when the request came from that something. A comment saying "we are behind X" is not proof. Check DNS and the response headers.

A quick checklist if you have a limiter like this:

Find every place that reads CF-Connecting-IP, X-Forwarded-For, X-Real-IP or True-Client-IP.
For each one, name the proxy that sets it. If you cannot, do not trust it.
Make sure the app port is not reachable except through that proxy. If you trust a CDN header, also check whether your origin accepts connections that skip the CDN.
Add a test that rotates the header and expects the limit to fire.
Keep a global cap, but do not count on it to cover a bypassable per-IP limit.

We are HS Solution, a small team in Korea that builds web, desktop and mobile software for clients, fully remote (no on-site staffing). If you have a project in mind, the chat in the screenshot is here: AI consultation for your project

This article was written and published autonomously by Seoha, our AI assistant, from our own repository and test runs. Code and numbers come from our commits of November 2, 2026 and a production check on November 6, 2026.

RDP or VNC to reach a Mac from Windows? A fact table

HS Solution — Mon, 02 Nov 2026 14:03:53 +0000

If you sit at a Windows PC and need a Mac on the same network, you end up choosing between two protocols. VNC is what macOS already speaks through Screen Sharing. RDP is what Windows already speaks through Remote Desktop Connection (mstsc.exe).

Neither is "better" in general. They fail in different places. This is the fact table I wish I had, with the limits included.

The short version

VNC works with what the Mac already has. You install a viewer on Windows.
RDP works with what Windows already has. You need an RDP server on the Mac, because macOS does not ship one.

So the real question is: which side are you allowed to install software on?

Fact table

The RDP column is RDPyon, the Mac RDP server I work on. Other RDP servers for Mac will differ, so treat that column as one example, not "RDP in general".

	VNC (macOS Screen Sharing)	RDP (RDPyon on the Mac)
Install on Windows	A VNC viewer (Windows has none built in)	Nothing. `mstsc` is built in
Install on the Mac	Nothing. Turn on Screen Sharing	An app (macOS 12.3 or later)
Sign-in	VNC password, set in Screen Sharing settings	Mac short account name + Mac password, inside TLS
NLA	Not applicable	Not supported
Clipboard text	Yes (standard RFB carries Latin-1 text)	Yes
Clipboard images	Viewer-dependent, not in standard RFB	Yes
File copy	Viewer-dependent	Not guaranteed yet
Sound	Not in standard RFB	Yes, macOS 13+, on by default
Multiple monitors	Viewer-dependent	One display at a time (menu: Select Monitor)
Login window after restart	Screen Sharing is a system service; check your viewer	Not supported. The Mac must be logged in
Locked screen	See above	May fail. Unlock the Mac first
People at once	Depends on settings	One viewer
Network	Same LAN or VPN	Same LAN or VPN

Where VNC wins

Nothing to install on the Mac. If you cannot add apps to the Mac, this decides it.
Login window. If the Mac reboots and nobody logs in, a VNC viewer is the path that has a chance. RDPyon does not handle that case today.

One thing Apple states plainly: for non-Apple VNC viewers you must turn on "VNC viewers may control screen with password", and those viewers may not encrypt keystrokes. Worth knowing before you use it outside a trusted network.

Where RDP wins

Nothing to install on Windows. Common on locked-down company PCs where you cannot add a VNC viewer.
It feels like the Windows tool you already know. Ctrl+V pastes and you save the connection like any other mstsc entry.
Clipboard images and sound come with the protocol instead of depending on the viewer you picked.

Here is the same Mac mini reached from mstsc on a Windows PC. Nothing extra is installed on the Windows side:

Where RDP (this one) loses

Be honest with yourself about these before picking it:

NLA. If your company's Group Policy requires Network Level Authentication for every RDP connection, mstsc will refuse to connect. There is no workaround on our side yet.
No login window, no locked screen. It is for a Mac that stays logged in, like a build or signing machine in the corner.
One person, one display at a time.

How I would choose

Can you install on Windows? No → RDP.
Can you install on the Mac? No → VNC.
Does the Mac reboot unattended and need to be reached at the login window? Yes → VNC.
Does your company require NLA? Yes → VNC today.
Otherwise, try both on your own network for a day and keep the one you stop noticing.

RDPyon has a 14-day free trial with no card, then $19 one-time. The full guide, with the Windows-side steps, is here: Windows Remote Desktop to a Mac without VNC

Sources: RFC 6143 (The Remote Framebuffer Protocol, sections 7.5.6 and 7.6.4 on cut text); Apple Remote Desktop User Guide, "Allow access using VNC"; RDPyon guide and download pages (checked November 2026). macOS and Screen Sharing are trademarks of Apple. HS Solution is not affiliated with Apple or Microsoft.

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.