Profile img

Hi, I'm who's behind Fedify, Hollo, BotKit, and this website, Hackers' Pub! My main account is at @hongminhee洪 民憙 (Hong Minhee) :nonbinary:.

Fedify, Hollo, BotKit, 그리고 보고 계신 이 사이트 Hackers' Pub을 만들고 있습니다. 제 메인 계정은: @hongminhee洪 民憙 (Hong Minhee) :nonbinary:.

FedifyHolloBotKit、そしてこのサイト、Hackers' Pubを作っています。私のメインアカウントは「@hongminhee洪 民憙 (Hong Minhee) :nonbinary:」に。

Website
hongminhee.org
GitHub
@dahlia
Hollo
@hongminhee@hollo.social
DEV
@hongminhee
velog
@hongminhee
Qiita
@hongminhee
Zenn
@hongminhee
Matrix
@hongminhee:matrix.org
X
@hongminhee

제품(타이피)의 기술부채와 타협하지 않고 위지윅 에디팅의 끝을 보려고 하시나 보네요. 기술 역량 면에서 참 대단하십니다.

구현체는 Rust로 작성되어 웹에서는 상술한 바와 같이 WASM으로 빌드 후 캔버스에 출력하며, 모바일에서는 각 플랫폼으로 네이티브 빌드되어 각 플랫폼의 윈도우 핸들을 통해 텍스쳐 버퍼에 바로 출력합니다. 이를 통해 웹뷰 없는 모바일 위지윅 에디터를 구현하고자 합니다.

— finn (@devunt) November 7, 2025
5
3

anyway just learned python typing invented a new kind of voldemort type -- one which when named doesn't actually name it

`float` and `int` are two distinct types in the type system

but if you write `x: float` that actually means `x: float | int`. but if you write `x: float | int` that means `x: float | int | int`.

anyway that's why `ty` has a `JustFloat` extension that is an actual alias for actual `float` that doesn't expand to `float | int`, so you can actual refer to... just float

play.ty.dev/a8714369-9b4c-4028

1
0
0
2
2
3
2
1

12() 6() 서울에서 開催(개최)되는 liftIO 2025에서 〈Optique: TypeScript에서 CLI 파서 컴비네이터를 만들어 보았다〉(假題(가제))라는 主題(주제)發表(발표)를 하게 되었습니다. 아직 liftIO 2025 티켓은 팔고 있으니, 函數型(함수형) 프로그래밍에 關心(관심) 있으신 분들의 많은 參與(참여) 바랍니다!

11
5
4

2025년 터미널 에뮬레이터 현황: 방랑하는 챔피언들 1위 Ghostty, 2위 Foot, 3위 Kitty가 상위권을 차지함 세 터미널 모두 Unicode 처리 정확도(WIDE/LANG/ZJW/VS16) 항목에서 최고 점수 기록 VTE 기반 터미널(GNOME Terminal, Terminator, LXTerminal 등) 은 하위권 유지 성능(Elapsed time) 측면에서 Foot, WezTerm, tmux, Konsole 등이 빠름 (100초 미만) iTerm2와 Extraterm은 CPU를 과도하게 사용하며, 테스트 시간을 단축해야 했음

과연 이번에도 "돌고 돌아 iTerm2로 돌아옴"이 될 것인가?

https://news.hada.io/topic?id=24130 https://www.jeffquast.com/post/state-of-terminal-emulation-2025/

1
1
1

근데 이전에 HN에서 codex가 뭔가 복잡하고 길게 해야하는 일을 더 잘 수행한다고 올린 글 때문에 테스트를 진행해본거라... 오히려 codex는 중간중간에 안껴들어도 일을 잘하고 claude code는 중간에 껴들어야 일을 잘하게되는 차이가 생길 수 도 있음.

이렇게 되면 병렬로 여러 일을 시키기에 codex가 더 적합할 수 도 있겠다는 가정을 해봄. 그래도 claude code가 결국 편할것 같은건 요즘 코딩하면서 테스트해본 결과 내 머리로는 최대 3개 이상의 작업을 동시에 병렬로 진행하는게 부하가 있음. 그래서 간단한 작업들 claude code web처럼 샌드박스에서 자동으로 돌려두는걸 codex로 해두고 내가 직접 상호작용하는 제품은 claude code를 사용하게 되지 않을까 싶음…

물론 어려운 작업들에서 작업 퀄리티 차이가 눈에 보일만큼 크다면 또 다르겠지만...

나중에 더 써보고 후기를 남겨보겠습니다.

2

codex에 비해서 claude code가 엄청 빠르다고 느꼈는데, 녹화해서 동시에 보면서 분석해봤는데 흥미롭다. gpt API 응답 속도나 claude API 응답 속도가 비슷했던 경험 때문에 인지 편향이 생겼을거라고 가정하고 녹화했다.

아주 간단한 테스트를 통해서 알게된 사실은 UX에서 오는 체감이 있는듯함. 동일한 코드베이스, 일, 프롬프트로 진행했는데 모든 일을 끝마치는데 걸린 속도는 비슷했음.

  1. 다만 Claude Code는 TODO 리스트를 통해서 일감 관리되고 있는 상호작용을 눈으로 확인할 수 있음
  2. 각 TODO 리스트가 끝났을때 중간 결과 같은것을 바로 알려줌
  3. 이 중간 결과를 보고 다음 명령어를 큐잉하게 되니 실질적으로 일 진행이 더 빠른 "느낌"을 받게됨.

두 제품 다 중간에 끼어들어서 일 방향을 수정하거나 일감을 큐잉하는등의 액션은 수행할 수 있는 것처럼 보여서 중간 결과를 알 수 있는게 복잡한 일을 하면 할 수록 큰 차이를 만들 수 있을것이라고 생각함.

이런 차이라면 학습하지 못한 자료에서 수행해야하는 일을 할때 조금 더 유의미한 차이가 생길것 같은데 나중에 테스트 해봐야겠다.

2
2
[Mon Nov 10 14:09:39 2025] Out of memory: Killed process 29426 (syncthing) total-vm:2418416kB, anon-rss:784kB, file-rss:3584kB, shmem-rss:0kB, UID:1000 pgtables:516kB oom_score_adj:200

1GB 짜리 SBC 에서 싱크싱을 systemd 유저 서비스로 띄워 두고 매일 몇 GB 정도 싱크를 하게 했더니 하루에 한 번씩 OOM 킬 당한다. 스와프 2GB 줘 봤지만 소용이 없다. 게다가 dmesg -T | grep "Out of memory" 에서 정확히 싱크싱만 잡히는 걸 보면 진짜로 싱크싱의 메모리 프레셔만 문제인 것 같다(스와프 아웃 속도가 문제가 아닌 것). 근데 다른 해결책도 보이지 않고, 또 저렇게 정기적으로 재시작당하게 냅둬도 아무 문제가 없어서, 냅두는 중…

2
2
1

洪 民憙 (Hong Minhee) shared the below article:

⌨️ Mac에서 Karabiner로 외부 키보드 오른쪽 Alt 한/영 전환하기

조내일 @tomorrowcho@hackers.pub

맥북에서 윈도우 키보드의 오른쪽 Alt 키를 한/영 전환 키로 사용하기 위한 설정 과정을 소개합니다. macOS 기본 설정으로는 왼쪽과 오른쪽 Option 키를 개별적으로 제어할 수 없어 Karabiner-Elements를 사용한 사용자 정의 키 매핑이 필요합니다. Karabiner 설치 후, Simple Modifications을 통해 right_option 키를 F18로 매핑하고, macOS 키보드 단축키 설정에서 '입력 소스 선택'을 F18로 지정해야 합니다. 만약 F18 키가 제대로 등록되지 않는다면, Karabiner의 드라이버 확장 프로그램 권한이 허용되었는지, 그리고 Devices 탭에서 외부 키보드의 'Ignore vendor events' 옵션이 활성화되었는지 확인해야 합니다. 이 설정을 통해 윈도우 환경에 익숙한 사용자도 맥에서 편리하게 키보드를 사용할 수 있습니다.

Read more →
2
1
2
2
4

리눅스 랩탑(amdgpu, rocm)에서 ollama 써서 아주 잠깐 로컬 LLM 시도해 본 소감: 생각보다 잘 되는데, 한편으로 왜 OpenAI 의 적자가 저렇게 터무니없는 규모라는 것인지도 이해했다. 어디가 병목인지는 알겠는데 그래서 그에 대한 대응책은 GPU 를 증설하기 시작해서 그냥 많이 증설했습니다. 를 하고 있다는 것이군 진짜로… 이게 인류의 갈 길이라니… 사이버펑크보다 현실이 더 사이버펑크다

5

tauri로 프로그램을 작성하는데 내부 상태를 뷰로 보여주기 위한 작업이 너무 귀찮았다. mount시점에 전부 다시 로드 해야하고, 변경 요소마다 command만들고 요청 날려야하고, 혹시라도 BE내부에서 변경될 수 있는 값이면 이것도 이벤트 만들어야하고, rust타입가지고 매크로로 쉽게 찍어낼 수 있을 것 같은데... 복잡한 타입은 좀 더 고민이 필요하겠지만...

3

洪 民憙 (Hong Minhee) shared the below article:

브라우저 스터디 기록 (3)

Jaeyeol Lee @kodingwarrior@hackers.pub

## 기술 포스팅 요약: 텍스트 레이아웃과 폰트 렌더링의 심연 이 글은 [Web Browser Engineering](https://browser.engineering) 독학 과정 중 Chapter 3의 텍스트 레이아웃을 다루며, 특히 폰트 렌더링의 복잡성을 강조합니다. 가변폭 글자의 정밀한 렌더링을 위해 단어 단위 렌더링과 baseline, ascent, descent 개념을 소개하고, 폰트마다 다른 기준선을 고려한 글자 배치 과정을 설명합니다. Linux 환경에서 tkinter의 폰트 측정 성능 문제를 지적하며, 폰트 정보를 캐싱하여 렌더링 속도를 개선하는 방법을 제시합니다. 연습문제 풀이에서는 중앙 정렬, `<abbr>`, soft-hyphen 지원 외에 `<sup>`, `<sub>` 태그를 구현하며 기준선 스택 관리 방식을 설명하고, `<pre>` 태그 지원을 위한 라인 단위 렌더링 방식을 소개합니다. 이 글은 텍스트 레이아웃의 깊이를 이해하고, 실제 브라우저의 렌더링 과정을 엿볼 수 있는 인사이트를 제공합니다.

Read more →
7
5
4
4
5
3
7

님들 고스트(아마 Pro?)로 블로깅하면 연합우주 연동되는 거 알고 있음? 고스트에서 포스트 퍼블리시할 때마다 연합우주에도 포스트 만들어주고 해당 연합우주 계정으로 다른 계정 포스팅에 댓글도 달아줄 수 있음… 어떻게 돌아가는지 참고 → https://hackers.pub/@jm@guji.jjme.me

4
4

길을 가다 "없는 것 빼고는 다 있다"는 문장을 보았다.

가능한 모든 품목의 집합을 UU로 둔다면, 가게가 실제로 보유한 재고는 SUS \subseteq U로 표현 할 수 있고, 없는 것의 집합은 USU \setminus S로 표현할 수 있다.

즉, "없는 것 빼고 다 있다"는 "전체(UU)에서 없는 것(USU \setminus S)을 제외하고 남은 모든 것은 있다"로 작성할 수 있고, 이는

xU(US)  :  xS\forall x \in U \setminus (U \setminus S) \; : \; x \in S

로 표현 할 수 있다.

하지만, 여집합(complement)의 여집합은 원래 집합이 되기 때문에

U(US)=SU \setminus (U \setminus S) = S

가 되고, 위 명제는 결국 xS  :  xS\forall x \in S \; : \; x \in S로 축약할 수 있고, 동어반복(tautology)이기 때문에 정보값은 없지만 항상 참으로 볼 수 있다.

2

Just opened an issue for a major new task for : building an smoke test suite.

To ensure Fedify-built servers federate correctly with the wider , we're planning to run automated E2E tests in against live instances of Mastodon, Misskey, and more. This is crucial for a framework's reliability.

You can see the full plan and discussion here:

https://github.com/fedify-dev/fedify/issues/481

1
4
0
1
0
1
1

youknowone replied to the below article:

abab, asc, 123, abc

@disjukr@hackers.pub

흔히 사용되는 JavaScript의 배열 정렬 방식인 `arr.sort((a, b) => a - b)`는 코드를 읽는 개발자에게 혼란을 줄 수 있습니다. 이 글에서는 이러한 정렬 코드를 볼 때마다 오름차순인지 내림차순인지 확인해야 하는 번거로움을 줄이기 위해, 더 명확한 함수 이름을 사용할 것을 제안합니다. `sortAsc(arr)`와 같이 오름차순을 의미하는 함수명도 좋지만, `sort123(arr)` 또는 `sortAbc(arr)`처럼 정렬 방향을 직관적으로 나타내는 이름을 사용하면 코드의 가독성을 더욱 향상시킬 수 있습니다. 이처럼 명확한 이름은 코드를 이해하는 데 필요한 인지적 노력을 줄여주어, 개발 생산성 향상에 기여할 수 있다는 점을 강조합니다.

Read more →
7
3

XiNiHa replied to the below article:

abab, asc, 123, abc

@disjukr@hackers.pub

흔히 사용되는 JavaScript의 배열 정렬 방식인 `arr.sort((a, b) => a - b)`는 코드를 읽는 개발자에게 혼란을 줄 수 있습니다. 이 글에서는 이러한 정렬 코드를 볼 때마다 오름차순인지 내림차순인지 확인해야 하는 번거로움을 줄이기 위해, 더 명확한 함수 이름을 사용할 것을 제안합니다. `sortAsc(arr)`와 같이 오름차순을 의미하는 함수명도 좋지만, `sort123(arr)` 또는 `sortAbc(arr)`처럼 정렬 방향을 직관적으로 나타내는 이름을 사용하면 코드의 가독성을 더욱 향상시킬 수 있습니다. 이처럼 명확한 이름은 코드를 이해하는 데 필요한 인지적 노력을 줄여주어, 개발 생산성 향상에 기여할 수 있다는 점을 강조합니다.

Read more →
7
1

洪 民憙 (Hong Minhee) shared the below article:

abab, asc, 123, abc

@disjukr@hackers.pub

흔히 사용되는 JavaScript의 배열 정렬 방식인 `arr.sort((a, b) => a - b)`는 코드를 읽는 개발자에게 혼란을 줄 수 있습니다. 이 글에서는 이러한 정렬 코드를 볼 때마다 오름차순인지 내림차순인지 확인해야 하는 번거로움을 줄이기 위해, 더 명확한 함수 이름을 사용할 것을 제안합니다. `sortAsc(arr)`와 같이 오름차순을 의미하는 함수명도 좋지만, `sort123(arr)` 또는 `sortAbc(arr)`처럼 정렬 방향을 직관적으로 나타내는 이름을 사용하면 코드의 가독성을 더욱 향상시킬 수 있습니다. 이처럼 명확한 이름은 코드를 이해하는 데 필요한 인지적 노력을 줄여주어, 개발 생산성 향상에 기여할 수 있다는 점을 강조합니다.

Read more →
7
2