Profile img

Jaeyeol Lee

@kodingwarrior@hackers.pub · 649 following · 474 followers

Neovim Super villain. 풀스택 엔지니어 내지는 프로덕트 엔지니어라고 스스로를 소개하지만 사실상 잡부를 담당하는 사람. CLI 도구를 만드는 것에 관심이 많습니다.

Hackers' Pub에서는 자발적으로 바이럴을 담당하고 있는 사람. Hackers' Pub의 무궁무진한 발전 가능성을 믿습니다.

그 외에도 개발자 커뮤니티 생태계에 다양한 시도들을 합니다. 지금은 https://vim.kr / https://fedidev.kr 디스코드 운영 중

Blog
kodingwarrior.github.io
mastodon
@kodingwarrior@silicon.moe
Github
@malkoG
0
0
0
0
0
1
0
0
0
박준규 @curry@hackers.pub
Public

해커스펍 계정은 쓰기 전용으로, 우리인생은 읽기전용으로 사용하고 있다. 또는 기술 관련 콘텐츠는 해커스펍에 올리고 일상은 우리인생에 올리려고 한다.

클라이언트는 팬피를 쓰고 있는데 해커스펍은 마스토돈 API 구현이 안 되어 있어서 팬피에는 우리인생 계정을 연동했다.

그런데 팬피에서 재밌게 글을 읽다 보면 무심코 팬피에서(우리인생 계정으로) 해커스펍 글에 댓글을 달아서 뭔가 곤란하다⋯

그리고 해커스펍에 오신 분들은 거의 다 팔로우를 하고 있는데 동시에 우리인생에서도 팔로우를 해야해서(팬피에서 읽어야 하니까) 불편하다.

0
2
0
0
0
0
0
1
0
Fedify: ActivityPub server framework @fedify@hollo.social
Public
Shared by Jaeyeol Lee

We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:

Two-Stage Fan-out Architecture for Efficient Activity Delivery

now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.

This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.

For specific requirements, we've added a new fanout option with three settings:

// Configuring fan-out behavior
await ctx.sendActivity(
  { identifier: "alice" },
  recipients,
  activity,
  { fanout: "auto" }  // Default: automatic based on recipient count
  // Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);

Canonical Origin Support for Multi-Domain Setups

You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.

const federation = createFederation({
  // Use example.com for handles but ap.example.com for ActivityPub URIs
  origin: {
    handleHost: "example.com",
    webOrigin: "https://ap.example.com",
  },
  // Other options...
});

Optional Followers Collection Synchronization

Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.

await ctx.sendActivity(
  { identifier: sender },
  "followers",
  activity,
  { 
    preferSharedInbox: true,
    syncCollection: true,  // Explicitly enable collection synchronization
  }
);

Enhanced Key Format Compatibility

Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.

Improved Key Selection Logic

The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.

New Authorization Options

Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.

Efficient Bulk Message Queueing

Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:

If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.

CLI Improvements

The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.

Additional Improvements and Bug Fixes

  • Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
  • Fixed bundler errors with uri-template-router on Rollup
  • Improved error handling and logging for document loader when KV store operations fail
  • Added more log messages using the LogTape library
  • Internalized the multibase package for better maintenance and compatibility

For the complete list of changes, please refer to the changelog.

To update to Fedify 1.5.0, run:

# For Deno
deno add jsr:@fedify/fedify@1.5.0

# For npm
npm  add     @fedify/fedify@1.5.0

# For Bun
bun  add     @fedify/fedify@1.5.0

Thank you to all contributors who helped make this release possible!

Released on March 28, 2025. Improved activity delivery performance with large audiences through a two-stage queuing system. Sending activities to many recipients (e.g., accounts with many follow...

Release Fedify 1.5.0 · fedify-dev/fedify

Released on March 28, 2025. Improved activity delivery performance with large audiences through a two-stage queuing system. Sending activities to many recipients (e.g., accounts with many follow...

github.com · GitHub

0
0
0

Jaeyeol Lee shared the below article:

한국 소프트웨어 개발자들이 자주 틀리는 외래어 표기법

洪 民憙 (Hong Minhee) @hongminhee@hackers.pub

전에 단문으로 올렸던 글을 지속적으로 갱신해볼까 싶어 게시글로 만들어 봅니다.

영어 틀린 표기 올바른 표기
algorithm 알고리즘 알고리듬
app 어플 앱
application 어플리케이션 애플리케이션
BASIC 베이직 베이식
directory 디렉토리 디렉터리
front-end 프론트엔드 프런트엔드
launch 런치 론치
license 라이센스 라이선스
message 메세지 메시지
method 메소드 메서드
parallel 페러렐 패럴렐
proxy 프록시 프락시
release 릴리즈 릴리스
repository 레포지토리 리파지터리
shader 쉐이더 셰이더
shell 쉘 셸
Read more →
2
0
1

Jaeyeol Lee shared the below article:

Grokに、三井住友海上火災保険とあいおいニッセイ同和損害保険が合併した新会社の名称を考えてもらいました

のえる @noellabo@hackers.pub

## 要約： この記事では、Grokを用いて三井住友海上火災保険とあいおいニッセイ同和損害保険の合併を想定した新名称の提案を試みています。最初の提案として、親会社であるMS&AD保険グループの名を基にした「MS&AD保険」が挙げられましたが、アルファベットと記号で構成されているため、漢字やひらがなで表記できる名称が再度求められました。その結果、保険業界で重要な「信頼」を強調した「信頼保険（しんらいほけん）」という名称が提案されました。この記事は、AIが企業の合併シナリオにおいて、親しみやすく覚えやすい新名称を考案するプロセスを簡潔に示しています。

Read more →
0
0
1
0
1
0
0
0
0
0
0
0
0
2
0
0
0
0
0
0
0
0
0
0
0
1
0
0
1
0
0
0
0
0
0
1
0
0
0

Jaeyeol Lee shared the below article:

복잡한 코드를 단순하게 줄여나갈 수록 발생하는 버그의 빈도나 심각도가 점진적으로 올라가는 경향이 있다고 느낀다

ㄹ @disjukr@hackers.pub

이 기술 블로그 포스팅에서는 코드 복잡도와 버그 심각도 사이의 미묘한 관계를 탐구합니다. 저자는 복잡도를 높이는 방향으로 문제를 해결할 때, 버그 빈도와 심각도를 점진적으로 줄일 수 있지만 최적의 해결책에 도달하지 못할 수 있다는 점을 지적합니다. 반대로, 복잡도를 낮추는 방향으로 접근하면 문제 해결에 드는 비용을 예측하기 어렵다는 어려움이 있습니다. 특히, 회사에서 코드 복잡도를 줄이는 대신 높이는 방향으로 문제 해결을 요구받는 상황에서 엔지니어로서의 자아와 현실 사이의 괴리를 느끼는 저자의 고충이 드러납니다. 개인 시간을 투자하여 더 나은 해결책을 찾아도, 이를 회사에 도입하는 데 많은 설득 비용이 소요된다는 점을 강조하며, 회사 내에서 자아실현을 포기해야 하는지에 대한 고민을 토로합니다. 이 글은 기술적 효율성과 조직적 요구 사이의 균형을 찾는 데 어려움을 겪는 개발자들에게 깊은 공감을 불러일으킬 수 있습니다.

Read more →
0
0
0
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Public
Shared by Jaeyeol Lee

한국 연합우주 개발자 모임(FediDev KR)은 이름 그대로 한국에서 연합우주(fediverse)와 관계된 개발(프로그래밍 뿐만 아니라 문서화, 번역 등을 포함)을 하는 사람들의 모임입니다. 실제로 Hackers' Pub의 개발 논의도 이 모임에서 처음 나왔었고요. Hackers' Pub을 통해서 ActivityPub이나 연합우주에 관심이 생기셨다면 한 번 참여해 보셔도 좋을 것 같습니다.

참고로 올해에는 아직 개최한 적 없지만 비정기적으로 스프린트 모임도 하고 있습니다. @sprints.fedidev.kr한국 페디버스 개발자 모임 계정을 팔로하시면 스프린트 모임이 열리기 전에 미리 공지를 올릴테니 미리 확인하실 수 있을 거예요.

한국 연합우주 개발자 모임

한국에 거주하거나 한국어를 사용하는 연합우주(fediverse) 개발자들의 모임입니다.

fedidev.kr

0
0
0
0
0
0

Jaeyeol Lee shared the below article:

Browser-Native Translation and Language Detection APIs Coming Soon

洪 民憙 (Hong Minhee) @hongminhee@hackers.pub

Just reviewed the W3C draft for the Translator and Language Detector APIs. This is genuinely exciting development for web developers.

The proposal would add native browser support for:

  • Text translation between languages
  • Language detection of arbitrary text
  • Both with streaming capabilities

No more relying on third-party translation services or embedding external APIs for basic language operations. All processing happens locally in the browser.

The API design is clean and straightforward:

// Translation example
const translator = await Translator.create({
  sourceLanguage: "en",
  targetLanguage: "fr"
});

const translatedText = await translator.translate("Hello world");

// Language detection example
const detector = await LanguageDetector.create();
const results = await detector.detect("Hello world");
// Returns array of detected languages with confidence scores

This will be a game-changer for multilingual sites and applications. The browser handles downloading appropriate language models and manages usage quotas.

The spec is still in draft form but shows promising progress toward standardizing these capabilities across browsers. Looking forward to seeing this implemented.

Read more →
0
1
0
bgl gwyng @bgl@hackers.pub
Public
Shared by Jaeyeol Lee

옛날에 만들어놓고 저 혼자는 잘쓰고 있는 React 폼 라이브러리 react-form-mozard를 소개합니다.

폼 중에서 Stepper 또는 Wizard라고 하는, 여러 개의 폼을 순차적으로 합친 형태를 다룰때 씁니다. 그래서 하나의 폼에 대해서는 react-hook-form 등 을 쓰고, 그걸 여러개 조합할땐 react-form-mozard를 활용하면 됩니다.

순차적으로 합친 에서 느낌이 오지요? 모나드가... 그대를 부릅니다...

폼 말고 CLI를 만들때를 잠깐 생각해보죠.

const name = prompt("이름이?")
const age = prompt(`{name} 님, 나이가?`)
if (Number(age) < 20) {
  console.info("미성년자는 이용할 수 없습니다")
  return
}
const gender = prompt(`{name} 님, 성별이?`)

뭐 이런 흐름을 생각해볼 수 있는데요. 보시면 먼저 받은 입력값에 따라 이후의 메시지나, 제어 흐름이 달라질 수 있습니다. 즉, 모나딕하죠. 근데 이런 평범한 로직을 Stepper/Wizard 에서 짜게되면 코드게 쉽게 더러워 지는걸 알수 있습니다.

react-form-mozard의 step은 위 예제의 prompt와 같은 역할을 합니다. 그리고 그걸 Generator 위에 얹으면 모나딕한 폼 합성이 가능해집니다.

단점이라면... 지금은 React랑 강결합 되어 있어, XState 등 다른 상태관리 라이브러리를 같이 쓴다면 연동이 깔끔하지 않을수 있습니다. 근데 평소에 쉽게 겪을 문제는 아니라고 보고, 또 추후에 설계를 수정해서 개선이 가능한 부분입니다.

Compose multiple forms into a single form wizard using a monadic approach. - gwyng-dev/react-form-mozard

GitHub - gwyng-dev/react-form-mozard: Compose multiple forms into a single form wizard using a monadic approach.

Compose multiple forms into a single form wizard using a monadic approach. - gwyng-dev/react-form-mozard

github.com · GitHub

0
0
0
0
0
1
0
0
0
0
1
0
0
0
0
0
1
0
0
0
0
Jaeyeol Lee @kodingwarrior@hackers.pub
Public

Hackers' Pub에 글을 쓸만한게 뭐가 있을까 하고 생각해봤는데, 알고리즘 문제풀이 컨텐츠로 채우는것쯤은 금방금방 가능할 것 같지만 이런식의 양치기보다는 그래도 엑기스를 모아서 정제되어있는 형태의 글을 올리는게 나을 것 같아

0
0
0
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Public
Shared by Jaeyeol Lee

소프트웨어 개발자들이 자주 틀리는 외래어 표기법.

영어 틀린 표기 올바른 표기
app 어플 앱
application 어플리케이션 애플리케이션
directory 디렉토리 디렉터리
front-end 프론트엔드 프런트엔드
message 메세지 메시지
method 메소드 메서드
release 릴리즈 릴리스
repository 레포지토리 리포지터리

또 있을까요?

1
9
0
0
0
0
0
0
0
0
0
0
Cojette @cojette@hackers.pub
Public

자동으로 설정된 프로필은 어디에서 오는 걸까 (분명 어디엔가 쓴 이미지가 자동으로 연동된 걸텐데(랜덤으로 구우사마가 붙을 가능성은 매우 희박하다) 요즘 구우를 어디에서 썼는지 기억이 잘.

0
1
0
Hyunjin Cho @resistan@hackers.pub
Quiet public
Shared by Jaeyeol Lee

DEI 중에 접근성은 I에 가깝겠지만, 개발자 중에 관심 있는 사람은 적은 듯.

공동 작업을 위한 저장소 계정을 따로 만들고, 개인 계정을 협업자로 등록해서 작업을 하고는 있는데...

  • 수집할 정보도 많고,
  • 개개인의 관심사도 다르고,
  • 각자 사용 가능한 시간도 다를테고,
  • 함께 해줬으면 하는 전문가들이 있지만 말 꺼내기도 쉽지 않다.

저변을 넓히고 싶고, 토론의 장도 만들었으면 좋겠고, 하고 싶은 것도 많고. 그러나 나 역시 현생의 문제가 여전하다.

a11ykr has 11 repositories available. Follow their code on GitHub.

a11ykr - Overview

a11ykr has 11 repositories available. Follow their code on GitHub.

github.com · GitHub

0
1
0

Hacker's Pub에 입문한 한국어권 여러분을 위한 안내서

Jaeyeol Lee @kodingwarrior@hackers.pub

Hacker's Pub은 소프트웨어 업계 종사자들이 자유롭게 생각을 공유하고 소통할 수 있는 소셜 네트워크 서비스이자 블로깅 플랫폼입니다. ActivityPub 프로토콜을 지원하여 Mastodon, Misskey 등 다른 SNS 서비스 사용자들과도 연결되어 플랫폼 경계를 초월한 소통이 가능합니다. 이 글에서는 Hacker's Pub의 의미와 ActivityPub 프로토콜에 대한 간략한 소개, 그리고 커뮤니티에 기여할 수 있는 다양한 방법을 제시합니다. 오픈 소스로 개발되는 Hacker's Pub 생태계에 참여하여 함께 서비스를 발전시키고, 우리만의 클라이언트를 만들어 Hashnode와 같은 블로그 템플릿을 구축하는 미래를 기대해 볼 수 있습니다. Hacker's Pub은 상호 존중과 신뢰를 바탕으로 모든 이들이 자유롭게 의견을 나누고 함께 만들어가는 공간입니다.

Read more →
0
4
0
0
17
0
유루메 Yurume @yurume@hackers.pub
Public
Shared by Jaeyeol Lee

블루스카이를 연합우주보다 먼저 썼고, 해커뉴스에서 관련 주장에 대해서 꽤 싸우기도 한 입장에서 민희님의 글 〈Bluesky는 X의 훌륭한 대안일 수 있지만, 연합우주의 대안은 아닙니다〉에 대한 반대 의견을 제시하고자 한다. 이 의견이 연합우주에 대한 전면적인 비판이 아니라는 것을 의견을 제시하기에 앞서 확실히 해 둔다(그랬다면 Hackers' Pub에 들어 올 일이 없었겠지).

탈중앙화는 매력적인 개념임이 틀림 없다. 인터넷의 많은 중요한 요소들이 어느 정도 탈중앙화되어 있으므로 탈중앙화가 인터넷의 장점들에 큰 몫을 했다는 생각을 쉬이 할 수 있고, 어느 정도는 그게 사실이기도 하니까. 하지만 엄밀히 말하자면 탈중앙화는 기술적인 특징이지 그 자체로 장점이 아니며, 탈중앙화가 장점으로 작용하려면 연결고리가 필요하다. 이를테면 비트코인을 위시한 암호화폐는 본디 비잔틴 실패까지 대비할 수 있는 강력한 탈중앙화를 장점으로 내세웠으나, 결국 화폐로서 제대로 사용되기 시작하자 현실 경제와의 커플링 때문에 그 "장점"이 크게 희석되고 말았다. 현 시점에서 암호화폐는 무에서 유의 신뢰를 창조하여 신용화폐의 요건을 충족하는 데까지는 성공했고 그것만으로도 역사적인 일이기는 하지만, 그게 탈중앙화랑 무슨 상관이 있느냐 하면 글쎄올시다.

블루스카이가 연합우주보다 덜 탈중앙화되어 있음은 분명하다. 민희님의 글에서 지적되었듯, 블루스카이가 이런 선택을 한 가장 큰 이유는 온전한 소셜 네트워크 기능을 위해 전역 뷰가 필수적으로 필요하다고 보았기 때문이다. 반대로 말하면 연합우주는 더 탈중앙화를 하기 위하여 전역 뷰를 포기했는데, 이 때문에 연합우주에서의 "소셜 네트워크"는 트위터/X와는 구조가 크게 다르다. 노드 규모가 문턱값에 다다르지 못하면 다른 노드에 있는 사용자를 찾아서 팔로해야만 온전한 소셜 네트워크 구성이 가능한데, 연합우주 안에서는 이런 외부 사용자를 찾는 구체적인 방법을 제공하지 않는다. 물론 인터넷과 똑같이 검색 엔진이 존재할 수야 있겠지만, 크롤링으로 인한 부하와 프라이버시에 대한 의견 차이 때문에 현실적으로 작동하는 연합우주 내 검색 엔진은 없다고 알고 있다. 따라서 연합우주에서 소셜 네트워크의 구성은 연합우주 바깥의, 보통은 중앙화되어 있는, 다른 소셜 네트워크(이를테면 현실 인간 관계)를 빌어야만 하는데, 이러면 탈중앙화가 큰 가치가 있을까?

한편으로는 전역 뷰가 소셜 네트워크의 단점이라고 주장할 수 있는 여지도 있다. 트위터/X를 오래 써 본 사람이라면 다 알겠지만 한 무리의 사람들이 다른 의견을 가진 무리와 충돌하는 주된 통로는 검색이나 해시태그를 통한 노출, 즉 전역 뷰이기 때문이다. 그러나 현실의 규모 있는 연합우주 노드들을 살펴 보면 각 노드가 곧 한 무리에 대응하는 식으로 충돌을 미리 회피하는 형태로 구성되지, 딱히 이런 충돌을 막기 위한 접근을 가지고 있는 것은 아니다. 노드 운영자를 위해 차단하는 걸 추천하는 서버 목록 같은 게 돌아다니는 건 연합우주 바깥의 일이지 않는가. 결국 전역 뷰의 역할을 대체하는 소셜 네트워크 바깥의 또 다른 소셜 네트워크가 존재할 것이기에, 우리가 소셜 네트워크를 어떤 이유로든 유용하다고 여긴다면 전역 뷰가 없는 게 장점이 될 수는 없다.

모든 이들이 이런 사고 과정을 가지고 블루스카이나 연합우주를 선택했다고 생각하진 않지만, 적어도 현 시점에서 사용자들은 블루스카이(이 글을 쓰는 시점에서 약 3360만명)를 연합우주(FediDB와 Fediverse.party로부터 추정할 때 최대 1530만명)보다 선호하는 것은 틀림이 없다. 게다가 블루스카이의 규모는 최근 1년 사이에 10배 불어난 것이고, 조금 장애가 있었지만 현재는 잘 동작하는 것으로 보인다. 위의 논의와 결합해 보면, 블루스카이는 정석적인 스케일링에 성공하고 있는 반면 연합우주는 스케일링 문제를 회피하기 위해 온전한 소셜 네트워크의 구성을 포기했다고 볼 수도 있는 대목이다. 블루스카이가 못미더운 부분은 분명히 존재하지만, 연합우주가 더 좋은 소셜 네트워크 경험을 제공한다고 가정하고 블루스카이의 단점을 제시할 수는 없다. 마치 암호화폐를 논할 때 장점만 말할 수 없는 것과 마찬가지로 말이다.



RE: https://hackers.pub/@hongminhee/2025/bluesky-a-good-alternative-to-x-not-to-the-fediverse

2
0
0