Hello! I'm Hong Minhee (洪 民憙), an open source software engineer in my late 30s, living in Seoul, Korea. I'm bisexual and non-binary (they/them), and an enthusiastic advocate of free/open source software and the fediverse.
I work full-time on @fedify, an ActivityPub server framework in TypeScript, funded by @sovtechfund. I'm also the creator of @hollo, a single-user ActivityPub microblog; @botkit, an ActivityPub bot framework; Hackers' Pub, a fediverse platform for software developers; and LogTape, a logging library for JavaScript and TypeScript.
I have a long interest in East Asian languages (CJK) and Unicode. I post mostly in English here, though occasionally in Japanese or in mixed-script Korean (國漢文混用體), a traditional writing style that interleaves Chinese characters with the native Korean alphabet. Wanting to write in that style was actually one of the reasons I joined the fediverse. Feel free to talk to me in English, Korean, Japanese, or even Literary Chinese!
安寧하세요! 저는 서울에 살고 있는 30代 後半의 오픈 소스 소프트웨어 엔지니어 洪民憙입니다. 兩性愛者(bisexual)이자 논바이너리(non-binary)이며, 自由·오픈 소스 소프트웨어(F/OSS)와 聯合宇宙(fediverse)의 熱烈한 支持者이기도 합니다.
STF(@sovtechfund)의 支援을 받아 TypeScript用 ActivityPub 서버 프레임워크 @fedify 開發에 專業으로 任하고 있습니다. 그 外에도 싱글 유저用 ActivityPub 마이크로블로그 @hollo, ActivityPub 봇 프레임워크 @botkit, 소프트웨어 開發者를 위한 聯合宇宙 플랫폼 Hackers' Pub, JavaScript·TypeScript用 로깅 라이브러리 LogTape 等의 製作者이기도 합니다.
東아시아 言語(이른바 CJK)와 Unicode에도 關心이 많습니다. 이 計定에서는 主로 英語로 포스팅하지만, 때때로 日本語나 國漢文混用體 韓國語로도 씁니다. 聯合宇宙에 오게 된 動機 中 하나가 바로 國漢文混用體로 글을 쓰고 싶었기 때문이기도 하고요. 韓國語, 英語, 日本語, 아니면 漢文으로도 말을 걸어주세요!
Instead of just passing text to an #LLM, it autonomously gathers context from linked pages and references to produce translations that actually understand what they're #translating.
@aburka You're judging before you've tried, and that's the disservice. You're assuming your skills will dull if you use an agent, and you're treating that assumption as a conclusion. That's the mistake. Try it first. See what actually happens. Then adjust your thinking based on experience, not fear.
I'm using them for months now, and in no way is it dulling my skills. I haven't learned as much as a programmer in years personally.
And I'm saying this also because I saw multiple people now who I knew learned throughout the year what AI agents are and it didn't click, until they took the time over Christmas to really dive in.
If you are a programmer and an AI hold-out, and you have some time off during Christmas: gift yourself a 100 USD subscription to Claude Code and … try it. But really try it. Take a week if you can afford it and dive in. It will change your opinion on these tools.
I love that this game is always emphasizing how this character speaks heavily English-accented Japanese. I guess because she's a golden retriever, and those are from Scotland. Someone greeted her with ごきげん in hiragana, and she replies with ゴキゲン in katakana. Very cute way of depicting an accent textually. She's also constantly littering her Japanese with bits of English, written in hiragana or katakana.
ALT text
Screenshot of a video game on a Nintendo DS. Two dog characters are speaking. One says: う〜ん、それが、あまりゴキゲンじゃないで〜す・・・。
ALT text
Screenshot of a video game on a Nintendo DS. Two dog characters are speaking. One says: う〜ん、それが、あまりゴキゲンじゃないで〜す・・・。
I have been trying to create a list for #fosdem26 and realized that (ironically) most of the people in the socialweb track ... does not have a fediverse account listed there.
I am also at fault, btw, so shame to me.
If you know someone who is presenting at #fosdem26 please send them my way. I will update this thread with the list of confirmed speakers.
I'm working on a new JavaScript/TypeScript library for natural language translation powered by LLMs. I want a name that feels elegant, memorable, and reflects the essence of translation.
I've narrowed it down to four candidates from different linguistic roots. Which one do you think fits bets?
Xindaya (信達雅): Derived from Yan Fu (嚴復)'s Three Pillars of Translation—faithfulness (信), expressiveness (達), and elegance (雅).
Vertana (वर्तन): Means transformation, turning, or process. It evokes the fluid and sacred process of transforming meaning from one language to another.
Glosso (γλῶσσα): The root for tongue or language. It's the origin of terms like glosssary and polyglot.
Fanyi (飜譯): The direct and minimal term for translation. It's punchy and honors the long-standing tradition of translation in East Asia.
I'm working on a new JavaScript/TypeScript library for natural language translation powered by LLMs. I want a name that feels elegant, memorable, and reflects the essence of translation.
I've narrowed it down to four candidates from different linguistic roots. Which one do you think fits bets?
Xindaya (信達雅): Derived from Yan Fu (嚴復)'s Three Pillars of Translation—faithfulness (信), expressiveness (達), and elegance (雅).
Vertana (वर्तन): Means transformation, turning, or process. It evokes the fluid and sacred process of transforming meaning from one language to another.
Glosso (γλῶσσα): The root for tongue or language. It's the origin of terms like glosssary and polyglot.
Fanyi (飜譯): The direct and minimal term for translation. It's punchy and honors the long-standing tradition of translation in East Asia.
@hongminhee I haven't compared all pairs but they catch slightly different typing errors, disagree with each other on what is an error and for the longest time, mypy found the most things that I agreed was an error. I imaging pyright has features optimized for syntax checking in an IDE, and pyrefly is optimized for slowly moving a large monorepo at facebook to being typed.
I'm betting ty is going to be a faster mypy, but I don't know. Just being a faster thing is astrals thing, tho.
@hongminhee Mypy can check types in Python metaprogramming patterns that other type checkers don't even try to handle. Typechecking Django models is one example.
With high-performance #Python type checkers like #Pyright, #Pyrefly, and #ty now available, what's the value proposition of #Mypy? Is it the reference implementation? Or does Mypy still have the most features? I'm not trying to knock Mypy, I'm genuinely asking because I don't know.
I sent my HHKB Pro 2 to a keyboard modding service to get it lubed and have the stabilizers balanced. I just got it back and am trying it out now. It's still a little stiff since it was just lubed, but I'm happy that the stabilizer rattle is definitely gone!
I have this bad habit. When something annoys me enough times,
I end up building a library for it. This time, it was CLI validation code.
See, I spend a lot of time reading other people's code. Open source projects,
work stuff, random GitHub repos I stumble upon at 2 AM. And I kept noticing this
thing: every CLI tool has the same ugly validation code tucked away somewhere.
You know the kind:
if (!opts.server && opts.port) { throw new Error("--port requires --server flag");}if (opts.server && !opts.port) { opts.port = 3000; // default port}// wait, what if they pass --port without a value?// what if the port is out of range?// what if...
It's not even that this code is hard to write. It's that it's everywhere.
Every project. Every CLI tool. The same patterns, slightly different flavors.
Options that depend on other options. Flags that can't be used together.
Arguments that only make sense in certain modes.
And here's what really got me: we solved this problem years ago for other types
of data. Just… not for CLIs.
The problem with validation
There's this blog post that completely changed how I think about parsing.
It's called Parse, don't validate by Alexis King. The gist? Don't parse data
into a loose type and then check if it's valid. Parse it directly into a type
that can only be valid.
Think about it. When you get JSON from an API, you don't just parse it as any
and then write a bunch of if-statements. You use something like Zod to parse
it directly into the shape you want. Invalid data? The parser rejects it. Done.
But with CLIs? We parse arguments into some bag of properties and then spend
the next 100 lines checking if that bag makes sense. It's backwards.
So yeah, I built Optique. Not because the world desperately needed another CLI
parser (it didn't), but because I was tired of seeing—and writing—the same
validation code everywhere.
Three patterns I was sick of validating
Dependent options
This one's everywhere. You have an option that only makes sense when another
option is enabled.
The type system now understands that when server is false, port literally
doesn't exist. Not undefined, not null—it's not there. Try to access it and
TypeScript yells at you. No runtime validation needed.
Mutually exclusive options
Another classic. Pick one output format: JSON, YAML, or XML. But definitely not
two.
I used to write this mess:
if ((opts.json ? 1 : 0) + (opts.yaml ? 1 : 0) + (opts.xml ? 1 : 0) > 1) { throw new Error('Choose only one output format');}
(Don't judge me, you've written something similar.)
Now?
const format = or( map(option("--json"), () => "json" as const), map(option("--yaml"), () => "yaml" as const), map(option("--xml"), () => "xml" as const));
The or() combinator means exactly one succeeds. The result is just
"json" | "yaml" | "xml". A single string. Not three booleans to juggle.
Environment-specific requirements
Production needs auth. Development needs debug flags. Docker needs different
options than local. You know the drill.
Instead of a validation maze, you just describe each environment:
No auth in production? Parser fails immediately. Trying to access --auth in
dev mode? TypeScript won't let you—the field doesn't exist on that type.
“But parser combinators though…”
I know, I know. “Parser combinators” sounds like something you'd need
a CS degree to understand.
Here's the thing: I don't have a CS degree. Actually, I don't have any degree.
But I've been using parser combinators for years because they're actually… not
that hard? It's just that the name makes them sound way scarier than they are.
I'd been using them for other stuff—parsing config files, DSLs, whatever.
But somehow it never clicked that you could use them for CLI parsing until
I saw Haskell's optparse-applicative. That was a real “wait, of course”
moment. Like, why are we doing this any other way?
Turns out it's stupidly simple. A parser is just a function. Combinators are
just functions that take parsers and return new parsers. That's it.
// This is a parserconst port = option("--port", integer());// This is also a parser (made from smaller parsers)const server = object({ port: port, host: option("--host", string())});// Still a parser (parsers all the way down)const config = or(server, client);
No monads. No category theory. Just functions. Boring, beautiful functions.
TypeScript does the heavy lifting
Here's the thing that still feels like cheating: I don't write types for my CLI
configs anymore. TypeScript just… figures it out.
TypeScript knows that if action is "deploy", then environment exists but
version doesn't. It knows replicas is a number. It knows force is
a boolean. I didn't tell it any of this.
This isn't just about nice autocomplete (though yeah, the autocomplete is great).
It's about catching bugs before they happen. Forget to handle a new option
somewhere? Code won't compile.
What actually changed for me
I've been dogfooding this for a few weeks. Some real talk:
I delete code now. Not refactor. Delete. That validation logic that used to
be 30% of my CLI code? Gone. It feels weird every time.
Refactoring isn't scary. Want to know something that usually terrifies me?
Changing how a CLI takes its arguments. Like going from --input file.txt to
just file.txt as a positional argument. With traditional parsers,
you're hunting down validation logic everywhere. With this?
You change the parser definition, TypeScript immediately shows you every place
that breaks, you fix them, done. What used to be an hour of “did I catch
everything?” is now “fix the red squiggles and move on.”
My CLIs got fancier. When adding complex option relationships doesn't mean
writing complex validation, you just… add them. Mutually exclusive groups?
Sure. Context-dependent options? Why not. The parser handles it.
But honestly? The biggest change is trust. If it compiles, the CLI logic works.
Not “probably works” or “works unless someone passes weird arguments.”
It just works.
Should you care?
If you're writing a 10-line script that takes one argument, you don't need this.
process.argv[2] and call it a day.
But if you've ever:
Had validation logic get out of sync with your actual options
Discovered in production that certain option combinations explode
Spent an afternoon tracking down why --verbose breaks when used with
--json
Written the same “option A requires option B” check for the fifth time
Then yeah, maybe you're tired of this stuff too.
Fair warning: Optique is young. I'm still figuring things out, the API might
shift a bit. But the core idea—parse, don't validate—that's solid.
And I haven't written validation code in months.
Still feels weird. Good weird.
Try it or don't
If this resonates:
Tutorial: Build something real, see if you hate it
I'm not saying Optique is the answer to all CLI problems. I'm just saying
I was tired of writing the same validation code everywhere, so I built something
that makes it unnecessary.
Take it or leave it. But that validation code you're about to write?
You probably don't need it.
I got suddenly inspired yesterday to build an email sending library for Node.js/Deno/Bun/edge functions. Meet Upyo: a TypeScript-first email library with a unified API that works across all JavaScript runtimes. It features pluggable transports (SMTP and Mailgun so far), built-in connection pooling, and comprehensive type safety. Still early days but already loving how clean the API turned out!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
