洪 民憙 (Hong Minhee)

차별금지법안이 제안됨과 동시에 격렬한 반대 메시지가 쌓이고 있네요.

부디 열화와 같은 성원으로 찬성해주시기 부탁드립니다

https://pal.assembly.go.kr/napal/lgsltpa/lgsltpaOpn/list.do?menuNo=&lgsltPaId=PRC_O2N5O1M1M1V9T1T1S0S9R5R9Z1A1Y3&searchConClosed=0&refererDiv=S

Hongdown 0.2.0 is out! Hongdown is an opinionated #Markdown formatter written in #Rust, and this release brings #WebAssembly support, so you can now use it as a library in #Node.js, #Bun, #Deno, and browsers.

New features:

• Smart heading sentence case conversion with ~450 built-in proper nouns
• SmartyPants-style typographic punctuation ("straight" → “curly”)
• External code formatter integration for code blocks
• Directory argument support for batch formatting

Try it in the browser: https://dahlia.github.io/hongdown/

Release notes: https://github.com/dahlia/hongdown/discussions/10

if people no longer read the code, API is no longer targeting humans, is there still a need for "good API design"? is it still worth the effort to figure out what would be the best for users, instead of the best of ai to understand/use? I don't know.

CLIツールを作ってると、「--repoで指定したリポジトリのブランチだけ補完候補に出したい」みたいな場面があるんですよね。でも普通のCLIパーサーだと各オプションが独立してて、これが意外と難しい。

TypeScript向け型安全CLIパーサーOptiqueで、この問題を解決する仕組みを作ったので、記事にまとめました。

https://zenn.dev/hongminhee/articles/aedde5d7fcc40e

Your CLI's completion should know what options you've already typed by @hongminhee https://lobste.rs/s/5se1tq #javascript #programming
https://hackers.pub/@hongminhee/2026/optique-context-aware-cli-completion

When building CLI tools, shell completion usually treats each option in isolation. But sometimes valid values for one option depend on another—like branch names depending on which repository you're targeting.

Wrote about how I solved this in Optique, a type-safe CLI parser for TypeScript.

https://hackers.pub/@hongminhee/2026/optique-context-aware-cli-completion

① CJK 환경에서 리눅스의 사용편의성이 윈도에 비견될만한가?
　아니요, 아직 멀었음. 이건 전제로 두고 이야기를 시작함.
② 리눅스 시스템 관리에 CLI가 필수이거나 UAC가 켜져있는 윈도보다 더 크게 불편한 점이 있는가?
　전혀 아니요, 10년도 더 전에 리눅스 써보고 그 경험이 아직도 유효하다고 생각하시면 안 됨. 요즘 전부 GUI로 클릭 두세 번에 다 해결되고, 윈도랑 크게 차이도 안 남.
③ 리눅스 한국어 입력기에 근본적인 사용성 문제가 있는가?
　아니요, OOTB로 작동하지 않는 것 이외에, IBus나 Fcitx에 근본적인 사용성 문제가 있다는 생각은 한 번도 해본 적 없음.

Consider Git's -C option:

git -C /path/to/repo checkout <TAB>

When you hit Tab, Git completes branch names from /path/to/repo, not your current directory. The completion is context-aware—it depends on the value of another option.

Most CLI parsers can't do this. They treat each option in isolation, so completion for --branch has no way of knowing the --repo value. You end up with two unpleasant choices: either show completions for all possible branches across all repositories (useless), or give up on completion entirely for these options.

Optique 0.10.0 introduces a dependency system that solves this problem while preserving full type safety.

Static dependencies with or()

Optique already handles certain kinds of dependent options via the or() combinator:

import { flag, object, option, or, string } from "@optique/core";

const outputOptions = or(
  object({
    json: flag("--json"),
    pretty: flag("--pretty"),
  }),
  object({
    csv: flag("--csv"),
    delimiter: option("--delimiter", string()),
  }),
);

TypeScript knows that if json is true, you'll have a pretty field, and if csv is true, you'll have a delimiter field. The parser enforces this at runtime, and shell completion will suggest --pretty only when --json is present.

This works well when the valid combinations are known at definition time. But it can't handle cases where valid values depend on runtime input—like branch names that vary by repository.

Runtime dependencies

Common scenarios include:

• A deployment CLI where --environment affects which services are available
• A database tool where --connection affects which tables can be completed
• A cloud CLI where --project affects which resources are shown

In each case, you can't know the valid values until you know what the user typed for the dependency option. Optique 0.10.0 introduces dependency() and derive() to handle exactly this.

The dependency system

The core idea is simple: mark one option as a dependency source, then create derived parsers that use its value.

import {
  choice,
  dependency,
  message,
  object,
  option,
  string,
} from "@optique/core";

function getRefsFromRepo(repoPath: string): string[] {
  // In real code, this would read from the Git repository
  return ["main", "develop", "feature/login"];
}

// Mark as a dependency source
const repoParser = dependency(string());

// Create a derived parser
const refParser = repoParser.derive({
  metavar: "REF",
  factory: (repoPath) => {
    const refs = getRefsFromRepo(repoPath);
    return choice(refs);
  },
  defaultValue: () => ".",
});

const parser = object({
  repo: option("--repo", repoParser, {
    description: message`Path to the repository`,
  }),
  ref: option("--ref", refParser, {
    description: message`Git reference`,
  }),
});

The factory function is where the dependency gets resolved. It receives the actual value the user provided for --repo and returns a parser that validates against refs from that specific repository.

Under the hood, Optique uses a three-phase parsing strategy:

1. Parse all options in a first pass, collecting dependency values
2. Call factory functions with the collected values to create concrete parsers
3. Re-parse derived options using those dynamically created parsers

This means both validation and completion work correctly—if the user has already typed --repo /some/path, the --ref completion will show refs from that path.

Repository-aware completion with @optique/git

The @optique/git package provides async value parsers that read from Git repositories. Combined with the dependency system, you can build CLIs with repository-aware completion:

import {
  command,
  dependency,
  message,
  object,
  option,
  string,
} from "@optique/core";
import { gitBranch } from "@optique/git";

const repoParser = dependency(string());

const branchParser = repoParser.deriveAsync({
  metavar: "BRANCH",
  factory: (repoPath) => gitBranch({ dir: repoPath }),
  defaultValue: () => ".",
});

const checkout = command(
  "checkout",
  object({
    repo: option("--repo", repoParser, {
      description: message`Path to the repository`,
    }),
    branch: option("--branch", branchParser, {
      description: message`Branch to checkout`,
    }),
  }),
);

Now when you type my-cli checkout --repo /path/to/project --branch <TAB>, the completion will show branches from /path/to/project. The defaultValue of "." means that if --repo isn't specified, it falls back to the current directory.

Multiple dependencies

Sometimes a parser needs values from multiple options. The deriveFrom() function handles this:

import {
  choice,
  dependency,
  deriveFrom,
  message,
  object,
  option,
} from "@optique/core";

function getAvailableServices(env: string, region: string): string[] {
  return [`${env}-api-${region}`, `${env}-web-${region}`];
}

const envParser = dependency(choice(["dev", "staging", "prod"] as const));
const regionParser = dependency(choice(["us-east", "eu-west"] as const));

const serviceParser = deriveFrom({
  dependencies: [envParser, regionParser] as const,
  metavar: "SERVICE",
  factory: (env, region) => {
    const services = getAvailableServices(env, region);
    return choice(services);
  },
  defaultValues: () => ["dev", "us-east"] as const,
});

const parser = object({
  env: option("--env", envParser, {
    description: message`Deployment environment`,
  }),
  region: option("--region", regionParser, {
    description: message`Cloud region`,
  }),
  service: option("--service", serviceParser, {
    description: message`Service to deploy`,
  }),
});

The factory receives values in the same order as the dependency array. If some dependencies aren't provided, Optique uses the defaultValues.

Async support

Real-world dependency resolution often involves I/O—reading from Git repositories, querying APIs, accessing databases. Optique provides async variants for these cases:

import { dependency, string } from "@optique/core";
import { gitBranch } from "@optique/git";

const repoParser = dependency(string());

const branchParser = repoParser.deriveAsync({
  metavar: "BRANCH",
  factory: (repoPath) => gitBranch({ dir: repoPath }),
  defaultValue: () => ".",
});

The @optique/git package uses isomorphic-git under the hood, so gitBranch(), gitTag(), and gitRef() all work in both Node.js and Deno.

There's also deriveSync() for when you need to be explicit about synchronous behavior, and deriveFromAsync() for multiple async dependencies.

Wrapping up

The dependency system lets you build CLIs where options are aware of each other—not just for validation, but for shell completion too. You get type safety throughout: TypeScript knows the relationship between your dependency sources and derived parsers, and invalid combinations are caught at compile time.

This is particularly useful for tools that interact with external systems where the set of valid values isn't known until runtime. Git repositories, cloud providers, databases, container registries—anywhere the completion choices depend on context the user has already provided.

This feature will be available in Optique 0.10.0. To try the pre-release:

deno add jsr:@optique/core@0.10.0-dev.311

Or with npm:

npm install @optique/core@0.10.0-dev.311

See the documentation for more details.

I've been working on a tricky problem in Optique (my CLI parser library): how do you make one option's value affect another option's validation and shell completion?

Think git -C <path> branch --delete <TAB>—the branch completions should come from the repo at <path>, not the current directory.

I think I've found a solution that fits naturally with Optique's architecture: declare dependencies between value parsers, then topologically sort them at parse time.

const cwdString = dependency(string());

const parser = object({
  cwd: optional(option("-C", cwdString)),
  branches: multiple(argument(
    cwdString.derive({
      metavar: "BRANCH",
      factory: dir => gitBranch({ dir }),
      defaultValue: () => process.cwd(),
    })
  )),
});

Details in the issue:

https://github.com/dahlia/optique/issues/74#issuecomment-3738381049

@mariusor No worries at all! It's always helpful to hear different perspectives. Thanks for the feedback!

김칩스 먹고 싶은데, 近處(근처)에서 살 수 있는 곳이 없다… 온라인으로 注文(주문)해야 하나…? 😩

@mariusor I think there might be a misunderstanding here. The defaultValue function isn't the parser introspecting application logic—it's the opposite direction. The application injects the fallback behavior into the parser.

The parser doesn't need to know what that function does internally. It just calls it when the dependency option is absent. This is similar to dependency injection: the parser defines when to call the function, but the application defines what it does.

Without this, the alternative would be post-parse validation in application code, which loses the benefit of parse-time validation and, more importantly, shell completion—which was the original motivation for this feature.

@mariusor That's a good point for the Git example! However, from Optique's perspective as a general-purpose CLI parser, I don't think we can always assume that.

Some cases where a default value isn't straightforward:

• The dependency option might be required with no default (e.g., --database <name> for table completions)
• The default might need async computation (e.g., auto-detecting a Git root by traversing up directories)
• Computing the default might be expensive, so we'd want to defer it until we know the option wasn't provided

That's why the current design has an explicit defaultValue function as the second argument to derive()—it gives users control over what happens when the dependency option is absent.

I've been working on a tricky problem in Optique (my CLI parser library): how do you make one option's value affect another option's validation and shell completion?

Think git -C <path> branch --delete <TAB>—the branch completions should come from the repo at <path>, not the current directory.

I think I've found a solution that fits naturally with Optique's architecture: declare dependencies between value parsers, then topologically sort them at parse time.

const cwdString = dependency(string());

const parser = object({
  cwd: optional(option("-C", cwdString)),
  branches: multiple(argument(
    cwdString.derive({
      metavar: "BRANCH",
      factory: dir => gitBranch({ dir }),
      defaultValue: () => process.cwd(),
    })
  )),
});

Details in the issue:

https://github.com/dahlia/optique/issues/74#issuecomment-3738381049

It seems like the Claude models normalize all curly quotes into straight quotes, which is incredibly annoying for someone like me who uses curly quotes all the time.

요즘 fedify를 이용한 연합되는 블로그 만들기에 열 올리고 있는데... 참 재밌는 것 같아요. fedify도 참 잘 만든 라이브러리인 것 같구... 나중에 블로그 실서비스 하게 될 때가 기대되네요♡

I've been boycotting Samsung for years now. People outside Korea often seem surprised when I mention this—after all, Samsung is one of the most recognizable Korean brands globally. So let me explain.

It started after I read Think Samsung (三星(삼성)을 생각한다) by Kim Yong-chul, a former Samsung lawyer turned whistleblower. The book exposed systematic corruption, slush funds, and how the conglomerate wielded its influence to evade accountability. It painted a picture of a company that operated as if it were above the law.

But what pushed me from mere dislike to active boycott was the 2015 merger between Samsung C&T and Cheil Industries. This wasn't just questionable corporate governance—it was engineered to help Lee Jae-yong consolidate control of the Samsung empire. The merger ratio heavily undervalued Samsung C&T, and the National Pension Service, despite its fiduciary duty to Korean citizens, voted in favor of it. Korean pensioners lost billions.

The whole affair later became central to the corruption scandal that brought down President Park Geun-hye. Lee Jae-yong was convicted of bribery. And yet Samsung continues as if nothing happened.

I'm under no illusion that my personal boycott hurts Samsung in any meaningful way. But some things aren't about effectiveness. They're about not being complicit.

일본 쇼와 시대에는 미소라 히바리라는 국민적 가수가 계셨다. 그녀는 울면서도 노래할 수 있었는데, 이것은 어떤 특수한 훈련 덕분이라고 알려져 있었다.

Turns out writing markdownlint rules was the easy part. Actually fixing all those lint errors manually? That was unbearable.

So I did what any reasonable person would do: rewrote the whole thing as an auto-formatter. Meet Hongdown—now you can enforce my peculiar Markdown style without the pain.

https://github.com/dahlia/hongdown

@twilliability Thanks for sharing this. I didn't know about the bootloader issue—I've been on iPhone for a while now, so I'm a bit out of the loop on Samsung's recent moves.

I've been boycotting Samsung for years now. People outside Korea often seem surprised when I mention this—after all, Samsung is one of the most recognizable Korean brands globally. So let me explain.

It started after I read Think Samsung (三星(삼성)을 생각한다) by Kim Yong-chul, a former Samsung lawyer turned whistleblower. The book exposed systematic corruption, slush funds, and how the conglomerate wielded its influence to evade accountability. It painted a picture of a company that operated as if it were above the law.

But what pushed me from mere dislike to active boycott was the 2015 merger between Samsung C&T and Cheil Industries. This wasn't just questionable corporate governance—it was engineered to help Lee Jae-yong consolidate control of the Samsung empire. The merger ratio heavily undervalued Samsung C&T, and the National Pension Service, despite its fiduciary duty to Korean citizens, voted in favor of it. Korean pensioners lost billions.

The whole affair later became central to the corruption scandal that brought down President Park Geun-hye. Lee Jae-yong was convicted of bribery. And yet Samsung continues as if nothing happened.

I'm under no illusion that my personal boycott hurts Samsung in any meaningful way. But some things aren't about effectiveness. They're about not being complicit.

@olivia Oh, I love that! “Kia kaha”—it has a powerful ring to it. It's fascinating to find such similarities between languages. Thanks for teaching me a beautiful phrase! Kia kaha with your website and Korean studies!

@olivia Welcome to the world of Korean language! Learning hangul is the most important first step. I checked out your website—it's a great initiative! Don't worry about it being rough; building something is the best way to learn. I look forward to chatting with you in Korean someday! Fighting! (That means “cheer up” or “go for it” in Korean. 파이팅 or 화이팅 in hangul.)

For the past few days, I've found myself wanting some ABS keycaps—GMK ones, to be exact.

Hongdown: An opinionated Markdown formatter in Rust https://lobste.rs/s/bstbd6 #show #rust
https://github.com/dahlia/hongdown

@cheeaun I considered it! But my requirements were pretty specific—like nuanced ordering for link references and footnotes based on their context. Building a custom formatter turned out simpler than trying to extend remark-lint for those edge cases.

Turns out writing markdownlint rules was the easy part. Actually fixing all those lint errors manually? That was unbearable.

So I did what any reasonable person would do: rewrote the whole thing as an auto-formatter. Meet Hongdown—now you can enforce my peculiar Markdown style without the pain.

https://github.com/dahlia/hongdown

I've always believed that structured logging shouldn't be complicated. Seeing Sentry echo this sentiment in their latest engineering blog post—and using LogTape to demonstrate it—is a massive validation for me.

They did a great job explaining why we need to move beyond console.log() in production. Really proud to see my work mentioned alongside such a standard-setting tool.

https://blog.sentry.io/trace-connected-structured-logging-with-logtape-and-sentry/

Windows special device names are cursed: https://chrisdenton.github.io/omnipath/Special%20Dos%20Device%20Names.html This is the subject of two recent Werkzeug CVEs. #windows #python #flask

One of the ways I'm dealing with AI slop at work is that when I'm giving feedback on the work I'm making sure to never assign the responsibility of the bad code to the AI. I'm directly saying that "this change that YOU made needs to be corrected". I'm always assigning the output of the AI to the person who put me in the position of reviewing the work. It is their responsibility to read the code that they're trying to review, they are responsible for 100% of the code, so they also get 100% of the blame when it's bad. If a change is confusing or nonsensical I'll ask "why did YOU make this change?". I'll never ask why an AI made a change, that we cannot know. All we can know is why someone thought it was acceptable to ship garbage, and we can assign them the responsibility for the garbage that they're willing to ship