洪 民憙 (Hong Minhee)

@hongminhee@hackers.pub · 605 following · 404 followers

Hi, I'm who's behind Fedify, Hollo, BotKit, and this website, Hackers' Pub!

Fedify, Hollo, BotKit, 그리고 보고 계신 이 사이트 Hackers' Pub을 만들고 있습니다.

Fedify、Hollo、BotKit、そしてこのサイト、Hackers' Pubを作っています。

嗨，我是 Fedify、Hollo、BotKit 以及這個網站 Hackers' Pub 的開發者！

Website
hongminhee.org
GitHub
@dahlia
Hollo
@hongminhee@hollo.social
DEV
@hongminhee
velog
@hongminhee
Qiita
@hongminhee
Zenn
@hongminhee
Matrix
@hongminhee:matrix.org
X
@hongminhee
0
0
0
0
0
0
0
0
0
Erick @erick@gts.erick.sh
Public
Shared by 洪 民憙 (Hong Minhee)

I think it’s fun to see all the support and rant reactions about Microsoft rewriting #TypeScript tooling in #Go instead of C# or Rust.

Notice that I said "fun", not "interesting". It’s fun because this is just the latest version of "vim vs. emacs" or "tabs vs. spaces". Everyone has opinions, everyone has their favorite programming language, but at the end of the day, 0% (or a very close number) of the people ranting about it are actually working on the project. It’s always easy to criticize someone else’s work when you have nothing at stake.

0
1
0
0
0
0
0
0
0

박준규 replied to the below article:

우분투에서 snap 으로 docker 를 설치했다가 후회한 얘기

Juntai Park @arkjun@hackers.pub

우분투에서 snap으로 설치한 Docker가 OpenTelemetry(OTel) 스키마 버전 충돌로 인해 갑자기 작동을 멈춘 문제에 대한 경험을 공유합니다. Docker 데몬이 실행되지 않고 모든 컨테이너가 사라지는 상황이 발생했으며, ChatGPT를 통해 snap 자동 업데이트 중 OTel 설정이 손상되어 스키마 버전 불일치(1.21.0 vs. 1.26.0)가 원인임을 확인했습니다. snap 대신 apt를 이용한 Docker 설치가 더 안정적이라는 판단하에, snap Docker를 제거하고 apt를 통해 Docker를 재설치하는 과정을 상세히 설명합니다. 이 경험을 통해 테스트 서버의 중요성을 깨닫고, 모니터링, 빌드, 도커 설정 등 백업의 필요성을 강조합니다.

Read more →
0
0
0
0
1
0
Juntai Park @arkjun@hackers.pub
Public
Shared by 洪 民憙 (Hong Minhee)

개발을 하다보면 종종 편하고 빠른 길에 대한 유혹을 받는다. 뿌셔버려도 되는 장난감이야, 맘대로 하면 되겠지만, 내가 하거나 누군가 이어받아 유지보수해야 할 회사의 일이면 가능한 그 미래를 고려한 선택을 우선해서 코드를 짠다.

시간내에 빠르게 만들어서 돌아가게끔 만드는 것도 물론 중요하지만 미래의 나 (혹은 다른 누군가) 를 생각하면 조금이라도 더 나은 미래를 위해서 노력한다.

대충 일정상 그러지 못해서, 지금 고통 받는 중이라 하는 얘기.

0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Linear @linear@hackers.pub
Public
Shared by 洪 民憙 (Hong Minhee)

오늘의 일기

  • 웜업/쿨다운 포함해서 50분 인터벌 달리기를 했다. 그리고 집 돌아오는 길에 종아리에 쥐나서 길거리에 주저앉을 뻔했다. 슬슬 런데이 아저씨가 미워지는 구간에 진입 중.
  • GitHub Pages 에서 Netlify 로 무사히 이관했다. 다음 목표는 카테고리 별로 볼 수 있게 내비게이션 바 만들고 RSS 피드 깨진 거 원인 파악해서 고치기.
  • 네이버 블로그 백업용으로 GitHub Pages 를 만들면서 당시에 썼던 독서/영화 기록에 네이버 책/영화 서비스 링크를 전부 달아뒀었는데, 이번에 Netlify 로 옮기면서 전부 지웠다. 당시엔 하이퍼링크를 걸어두는 쪽이 더 범용성 있을 거라고 생각했는데 네이버 영화 서비스가 문 닫을 줄 누가 알았겠어요. 블로그로 정확히 뭘 하고 싶은지 목표가 뚜렷해야 이런 실수를 안 할 텐데, 장기적인 목표는 좀 더 천천히 생각해 봐야 할 거 같다.
  • 내 포스트를 공유한 사람 목록을 보고 싶은데 아직은 방법이 없는듯.
  • 블루스카이와 타임라인을 연결하고 싶은데 계정을 만든지 7일이 지나야 가능한 거 같다.
0
2
0
0
1
0
0
0
0
Fediverse Linux Users Group @fedilug@msky.ospn.jp
Public
Shared by 洪 民憙 (Hong Minhee)

【輪読会試験開催のお知らせ】
 ​:fedilug:​ 輪読会📖第0弾として
「〜自分でActivityPub対応SNSを作ってみよう〜『自分だけのフェディバースのマイクロブログを作ろう！』輪読会」
https://github.com/dahlia/fedify-microblog-tutorial-ja

を行います！申し込みは以下からできます！ぜひ参加してフィードバックをください！！
https://fedilug.connpass.com/event/348240/

0
0
0
0
0
0
0
0
0
0
0
0
Fedify: an ActivityPub server framework @fedify@hollo.social
Public
Shared by 洪 民憙 (Hong Minhee)

@PossiblyMaxMax Great question about our queue implementation! Fedify doesn't actually create separate physical queues, but rather uses a single logical queue where each message contains its own destination information.

For resource management, we generally rely on the underlying queue implementation (Redis, PostgreSQL, etc.) to handle concurrent processing efficiently. Since version 1.0.0, we've introduced ParallelMessageQueue which processes multiple messages concurrently with a configurable worker count—usually set close to your CPU core count for IO-bound operations.

We don't spin up new queues dynamically; instead, we focus on making the message processing scalable. You can control the parallelism level when using ParallelMessageQueue, and for high-volume instances, you can horizontally scale by running multiple worker processes that connect to the same shared queue backend.

This approach keeps the architecture simpler while still allowing for good throughput and resource utilization that can scale with your instance size.

0
0
0
Fedify: an ActivityPub server framework @fedify@hollo.social
Public
Shared by 洪 民憙 (Hong Minhee)

Just released @fedify/markdown-it-mention v0.3.0! This update adds support for bare handles (e.g., @username without domain) with the new localDomain option, allowing you to specify the domain for these shortened mentions.

Install via npm, Bun, or Deno:

npm add @fedify/markdown-it-mention@0.3.0
bun add @fedify/markdown-it-mention@0.3.0
deno add jsr:@fedify/markdown-it-mention@0.3.0
0
1
0
0
0
0
0
0
0
0
0
0
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Public
Shared by 洪 民憙 (Hong Minhee)

Hackers' Pub 쓰고 계신 분들 중에서, 자신의 Hackers' Pub 계정을 연합우주(fediverse)뿐만 아니라 Bluesky에도 노출하고 그쪽 사람들과 교류하고 싶으신 분이 있다면, 상단 검색창에 @bsky.brid.gy@bsky.brid.gy을 검색하셔서 나오는 프로필을 팔로해 보세요. 그리고 1분 정도 뒤에 Bluesky에서 본인ID.hackers.pub.ap.brid.gy로 검색하면 본인의 Hackers' Pub 계정이 Bluesky에서도 보이는 걸 확인하실 수 있을 겁니다.

0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
Linear @linear@hackers.pub
Public

오늘의 일기

  • hackers.pub 첫 포스트!
  • 첫 수영 수업을 다녀왔다. 전날 밤에 악몽 꿀 정도로 긴장했는데 다행히 가서 음파음파 잘 하고 왔다. (..)
  • SNS 여러 개는 도저히 못 쓰겠다는 결론을 내리고 블루스카이 탈퇴.
  • 스마트폰 사용 시간을 줄이기 위해 디스플레이를 흑백으로 바꿨다.
  • 과연 올해야말로 블로그 대통합을 이룰 수 있을 것인가? 네이버 블로그에 쌓여 있는 글을 모두 나만의 정적 웹사이트로 옮기고 애매하게 둥둥 떠 있는 github pages 는 없애는 게 목표.
0
0
0
0
0
0
Linear @linear@hackers.pub
Public
Shared by 洪 民憙 (Hong Minhee)

오늘의 일기

  • hackers.pub 첫 포스트!
  • 첫 수영 수업을 다녀왔다. 전날 밤에 악몽 꿀 정도로 긴장했는데 다행히 가서 음파음파 잘 하고 왔다. (..)
  • SNS 여러 개는 도저히 못 쓰겠다는 결론을 내리고 블루스카이 탈퇴.
  • 스마트폰 사용 시간을 줄이기 위해 디스플레이를 흑백으로 바꿨다.
  • 과연 올해야말로 블로그 대통합을 이룰 수 있을 것인가? 네이버 블로그에 쌓여 있는 글을 모두 나만의 정적 웹사이트로 옮기고 애매하게 둥둥 떠 있는 github pages 는 없애는 게 목표.
0
0
0
Fedify: an ActivityPub server framework @fedify@hollo.social
Public
Shared by 洪 民憙 (Hong Minhee)

Got an interesting question today about 's outgoing design!

Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.

In the , server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.

By creating individual queue items for each recipient:

  • Fast servers get messages delivered promptly
  • Slow servers don't delay delivery to others
  • Failed deliveries can be retried independently
  • Your UI remains responsive while deliveries happen in the background

It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.

This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!

What other aspects of Fedify's design would you like to hear about? Let us know!

A flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
0
5
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0