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

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

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

嗨,我是 FedifyHolloBotKit 以及這個網站 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
6
17
0
0
7
2
6
3

Deno에서는 deno.jsontasks에 들어가는 커맨드가 반드시 deno_task_shell을 통해서 실행되기 때문에 최소한의 이식성이 보장되는데 (예를 들어, Windows에서도 sh에 가깝게 돌아간다는 게 보장됨), Node.js에서는 package.jsonscripts에 들어가는 커맨드가 그냥 그 시스템의 기본 셸로 돌아가는 것 같다. Windows 대응을 어떻게 해야 할 지 고민이네…

2

JavaScript 번들러를 쓰려고 하니까 확실히 모듈 사이의 원형 의존성을 상당히 엄격하게 잡는 것 같다. 그냥 인터프리터로 실행할 때는 Python처럼 모듈 실행하다 도중에 다른 모듈 실행하고 다시 돌아와서 마저 실행하는 식으로 해결되는 면이 있었는데, 아무래도 정적 분석이 들어가다 보니 그렇게 하기는 어려운 듯. 이참에 모듈을 더 잘게 나누기로 했다. 다행히 그걸로 모두 해결되는 케이스라서…

3

어쩌다 보니 Fedify에서 JSR 의존성을 걷어내게 되었는데, 가장 골치아픈 게 @std/encoding 패키지인 것 같다. 어째서인지 npm 쪽에는 base64, base64url, base58, hex 등의 인코딩 및 디코딩을 모두 제공하는 패키지가 없어 보인다. 게다가 대체로 Uint8Array가 아니라 Node.js API인 Buffer에 의존한다.

그냥 @std/encoding을 포크해서 npm에 올려버릴까 싶기도 하고…

3

Smalltalk의 클래스 레퍼런스 문서는 스스로를 기술할 때 일인칭을 쓴다고 한다. “나는 추상 클래스입니다. 내 인스턴스들은 객체의 컬렉션입니다” 같은 식.

3
3
2
1

FediDev KR 스프린트 두 번째 모임이 이번 주 토요일입니다! 아직 참가 신청 안 하신 분들은 늦지 않게 신청하시기 바랍니다.[1]


  1. 신청서 양식 마지막에 빈 입력란이 있는데 실수로 추가된 것입니다. 이벤터스에서 한 번 신청 양식을 정하면 수정할 수가 없다고 하네요. 그냥 아무 글자나 넣고 신청하시면 됩니다. ↩︎

2
5
2

Mastodon에서 여태까지 Webpack을 쓰고 있었는데 드디어 Vite로 넘어갔다고. 지난 주였나 테스트 때문에 Mastodon 설치할 일이 있었는데 RAM 4 GB짜리 VPS에서 Webpack 돌다가 얼어버렸던 경험이 있다. 그 때는 “이야, 아직 Webpack을 쓰네” 하며 RAM 8 GB로 올려서 어떻게 해결은 했지만, 황당하긴 했다.

3
4
4
4
4
2
0
1
2

요 며칠 동안은 Fedify 작업을 했고, 오늘은 오랜만에 Hollo 작업을 할 예정…이긴 한데, 주로 코딩보다는 PR 리뷰하는 게 주가 될 듯? 잘 하면 오늘 새 릴리스를 할 수도 있다.

4

5월 24일(土) 한국 연합우주 개발자 모임(FediDev KR)에서 두 번째 스프린트 모임을 개최합니다! 장소는 뚝섬역 5번 출구쪽에 위치한 튜링의 사과(@TuringAppleDev튜링의 사과)입니다.

참고로 스프린트 모임이란 함께 모여서 오픈 소스 코딩을 하는 자리인데, 한국 연합우주 개발자 모임의 스프린트에서는 새로운 연합우주 서비스나 앱을 개발하거나, 번역이나 문서에 기여하는 등 연합우주와 관련된 다양한 오픈 소스 활동을 모여서 함께 합니다. 지난 스프린트 모임의 기록을 스프린트 블로그(@sprints.fedidev.kr한국 페디버스 개발자 모임)에서 살펴보실 수 있습니다.

저는 그날 Fedify, Hollo, Hackers' Pub에 기여하시고자 하는 분들을 옆에서 도와드릴 예정입니다. Fedify, Hollo, Hackers' Pub에 기여해보고 싶었던 분들이 계시다면 모임에 참가하여 저와 함께 스프린트를 해보는 것도 좋을 것 같습니다.

이번 모임에 관심이 있으신 분은 행사 신청 페이지를 참고하시기 바랍니다.

7
1
3
4

Fedify에 드디어 RFC 9421을 얼추 구현했고, 이제 상호운용성 테스트를 위해 Mastodon의 특정 브랜치를 실제로 인스턴스로 띄워서 액티비티를 송수신해봐야 한다. 그런데 Mastodon 띄우기가 너무나 귀찮다… (Mastodon 띄우기 귀찮아서 ActivityPub 개발 시작한 사람.)

3

예전부터 생각하던 건데, git reset --hard를 인자 없이 쓰면 git stash로 동작하거나, 아니면 적어도 인자 없이 썼을 때 오류가 나게끔 설정할 수 있었으면 좋겠다. 별 생각 없이 날려도 괜찮겠지 싶어서 git reset --hard 쳤다가 몇 분 뒤에 후회하는 경우가 종종 있다.

2
2
2
5
4
7
1
1
14
2

먼 미래에는 어떻게 될 지 잘 모르겠지만, 일단 코딩 에이전트한테 LSP를 툴로 쥐어 줘야 하는 게 아닌가 하는 생각이 요즘 많이 든다.

4
4

After reviewing FEP-5624: Per-object reply control policies and GoToSocial's interaction policy spec, I find myself leaning toward the latter for long-term considerations, though both have merit.

FEP-5624 is admirably focused and simpler to implement, which I appreciate. However, 's approach seems to offer some architectural advantages:

  1. The three-tier permission model (allow/require approval/deny) feels more flexible than binary allow/deny
  2. Separating approval objects from interactions appears more secure against forgery
  3. The explicit handling of edge cases (mentioned users, post authors) provides clearer semantics
  4. The extensible framework allows for handling diverse interaction types, not just replies

I wonder if creating an that extracts GoToSocial's interaction policy design into a standalone standard might be worthwhile. It could potentially serve as a more comprehensive foundation for access control in .

This is merely my initial impression though. I'd be curious to hear other developers' perspectives on these approaches.

4
1
2