oed

Vim에 관심있는, 혹은 Vim을 사랑하는 여러분, 안녕하세요.

한국어권 Vim 사용자 모임 vim.kr입니다. 오늘은 vim.kr에서 공식적으로 주최하는 모임 소식을 전해드리려 합니다.

혹시 *빔교정학원 모임(vimrc)*을 들어보신 적 있으신가요? vimrc 밋업은 2019년과 2022년에 3년 간격으로 개최된 바 있는데, 2025년부터는 저희 vim.kr이 그 바통을 이어받아 공식적으로 진행하게 되었습니다.

지난 7월 2일, 기존 vimrc 밋업을 주최하셨던 박현우(lqez)님께 연락을 드렸고, 이어 7월 6일 첫 회의를 통해 vim.kr에서 본 행사를 이어가기로 확정하였습니다.

이번 vimrc 밋업은 이전과는 조금 다른 방식으로 준비되고 있습니다. 특정 연사자가 발표하는 자리가 아니라, 모든 참가자가 동등한 입장에서 자신이 Vim을 어떻게 활용하는지 경험과 노하우를 공유하는 자리를 지향합니다. 즉, 발표 중심의 형식보다 네트워킹과 상호 교류에 초점을 맞춘 밋업입니다.

행사 규모는 약 36명으로 계획 중이며, 일정은 11월 둘째 주에서 셋째 주 사이로 조율하고 있습니다. 현재 대관 장소도 검토 중이니, 혹시 행사 장소 후원에 관심 있는 분이 계시다면 연락 부탁드립니다.

행사 관련 최신 소식은 vim.kr 디스코드를 통해 안내드릴 예정입니다.

많은 관심과 참여 부탁드립니다. 감사합니다.

Open source projects I'm currently maintaining:

• Fedify, an ActivityPub server framework for TypeScript
• Hollo, an ActivityPub-enabled single-user microblogging software
• BotKit, an ActivityPub bot framework for TypeScript
• LogTape, a modern logging library for TypeScript
• Upyo, a simple and modern email sending library for TypeScript
• Optique, a type-safe combinatorial CLI parser for TypeScript

https://t.co/93TfrsznNC

좋은 내용이였다. 앞으로 에이전트 매니저 역할을 겸해야 하는 개발자들이 생각해볼만한.

Managing implementations you don't understand is a problem as old as civilization. (and every manager in the world already deals with this!) Find an abstraction layer you can verify!

How does a CTO manage an expert? -> Acceptance Tests

How does a PM review an Eng feature? -> Use the product

How does a CEO check the acccountant? -> Spot check key facts

We'd like to recognize some excellent contributions from our #OSSCA (Open Source Contribution Academy) participants who have been working on #Fedify.

@gaebalgom개발곰 contributed PR #339, which introduces the @fedify/elysia package to provide Elysia integration for Fedify. This work addresses issue #286 by creating a plugin that enables developers using #Bun and #Elysia to integrate Fedify's #ActivityPub capabilities into their applications. The contribution includes the core integration module, documentation, examples, and proper monorepo configuration, making Fedify accessible to the Elysia community.

@r4bb1t submitted PR #315, implementing comprehensive AbortSignal support across multiple APIs to resolve issue #51. This contribution adds request cancellation capabilities not only to lookupWebFinger() but also to lookupObject(), DocumentLoader, and the HTTP signature authentication flow (doubleKnock()), allowing developers to properly handle timeouts and abort ongoing requests throughout the entire request chain. The implementation includes extensive test coverage for cancellation scenarios across all affected components and lays the groundwork for adding --timeout options to various CLI commands like fedify lookup, fedify webfinger, and fedify nodeinfo, making federated applications more robust and responsive.

@ooheundaoed addressed a testing infrastructure issue with PR #350, fixing a race condition in PostgreSQL message queue tests that was causing intermittent failures (issue #346). By adding explicit initialization before concurrent message queue listeners, this fix prevents table creation conflicts that were affecting test reliability, ensuring more consistent PR testing for all contributors.

@songbirds provided two test stability improvements with PR #344 and PR #347. The first PR adds skip guards to RedisKvStore tests as a workaround for a known Bun runtime issue, keeping the test suite functional while awaiting an upstream fix. The second PR resolves a race condition in the code generation process by randomizing output filenames, preventing conflicts during parallel test execution. These contributions help maintain a stable testing environment for the project.

Thank you all for your contributions to Fedify. Your work helps make federated social networking more accessible to developers.

#opensource #fedidev #fediverse

오늘의 짤

현재 시각은 23시 58분. Fedify에 NestJS를 지원한다고 온갖 삽질을 하다가 마지막을 보고 있는 시점에서 뭘할까 고민하다 가만히 있기는 좀 그래서 끄적이는 의식의 흐름대로 쓰는 글....

맥락이 싹다 휘발되기전에 내가 어떻게 우여곡절을 겪었는지를 좀 러프하게 요약해보자....

• Fedify 프로젝트를 NestJS 에서도 쓸 수 있도록 Fedify 모듈을 만들려고 했던 것에서부터 불행이 시작됨.

• 애초에 NestJS는 CommonJS 기반이고 Fedify는 ESM 모듈만 지원했어서, 이걸로 사용할 수 있녜마녜 하는 얘기가 오가는 중에 Node 22 버전에서 NODE_OPTIONS=--experimental-require-module 환경변수 걸면 esm 모듈을 가져올 수 있다는 사실을 알게됨.

• Fedify 프로젝트에 포함된 라이브러리로 넣기 이전에, 가설검증은 해봐야겠어서 기존에 NestJS 기반으로 만들려고 벼르고 있던 프로젝트에서 가설검증을 시도함

• 가설 검증 자체는 성공적이고 스무스했음. Fedify microblogging 예제를 돌릴 정도는 돌아갔던 것 같음.

• 하지만........ Fedify로 통합하는 과정이 문제가 있었는데... Fedify에 돌아가는 코드를 옮겨놓고, 그 코드가 의도하는대로 잘 뽑히는지가 문제였던 것이다.

• 예를 들면, NestJS는 Typescript 생태계에서는 거의 deprecated된 것으로 취급하는 Decorator 문법을 쓰고 있는데, deno 런타임에서는 지원안하는것은 물론이고, 패키징을 하는 것 자체는 성공했으나 npm 패키지를 가져다 쓰는 입장에선 계속해서 런타임 에러가 뜨는 것. 데코레이터 문법의 경우엔 tsconfig 파일을 또 별도로 수정해서 어떻게든 코드가 뽑히게 했음.

• 그래서 node_modules 를 직접 까보면서 코드가 어떻게 뽑히는지 직접 두눈으로 확인해보기도 하고, 민희님 도움 받아서 pnpm prepack 커맨드로 tgz 파일 만들어서 그걸 package.json에서 가져다 쓰는 것도 어쩌다보니 하게 되고... 패키징은 제대로 되었는데 왜 import 오류가 다시 뜨는가 하고 봤더니, 처음으로 돌아가서 NODE_OPTIONS 환경변수 문제였고. commonjs/esm 둘다 js 아웃풋이 나오도록 세팅하는 것도 해보고, 패키지 퍼블리시까지 겨우 성공

• 그러다가, 다시 왜 안 돌아가지하고 봤는데... 처음에 돌아가던 코드에서 좀 정리를 하다보니 안 돌아가게 된 케이스도 있었고, 어떤 부분은 NestJS 내부 구현(Express)을 몰라서 계속 똥볼을 찬 케이스도 있었고, 몇시간을 심연을 들여다 봤던 것 같다...

패키징하면서도 오류 터져서 빌드깨지는거만 체감상 한 10~15번 정도한 것 같은데 머리에 스팀 나는 줄 알았음...

이젠 된다... 진짜 험난한 여정이었다...