洪 民憙 (Hong Minhee)

Introducing #Upyo!

A simple, cross-runtime email library that works seamlessly on #Deno, #Node.js, #Bun, and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.

Switch between #SMTP, #Mailgun, #SendGrid without changing your code. Available on #JSR & #npm!

https://upyo.org/

@jaredwhite Thanks! 🙏🏼

@hongminhee That API is a thing of beauty. Nicely done. 👏

By the way, check out this cute Upyo logo here! Just FYI, 郵票 (upyo) means postage stamp in Korean. You can view the SVG source code on GitHub.

I got suddenly inspired yesterday to build an email sending library for Node.js/Deno/Bun/edge functions. Meet Upyo: a TypeScript-first email library with a unified API that works across all JavaScript runtimes. It features pluggable transports (SMTP and Mailgun so far), built-in connection pooling, and comprehensive type safety. Still early days but already loving how clean the API turned out!

🎉 Huge shoutout to two amazing contributors from Korea's #OSSCA program who've made excellent contributions to #Fedify!

👏 @gaebalgom tackled a tricky terminal compatibility issue in PR #282, fixing the fedify node command's favicon display on terminal emulators without truecolor support (#168). His solution elegantly detects terminal capabilities and falls back to 256-color mode when needed—ensuring a great experience across different environments.

🌟 @joonnot enhanced Fedify's #WebFinger functionality in PR #281 by adding a configurable maxRedirection option to the lookupWebFinger() function (#248). He transformed a hardcoded limitation into a flexible, user-customizable parameter while maintaining perfect backward compatibility.

Both delivered thoughtful, well-implemented solutions that showcase the quality of contributions coming from the OSSCA program. Welcome to the Fedify community!

#ActivityPub #opensource #fedidev

If you ask the new Grok 4 for opinions on controversial questions, it will sometimes run a search to find out Elon Musk’s stance before providing you with an answer!
https://simonwillison.net/2025/Jul/11/grok-musk/

부제 : 기술 스택 선정 시 고려해야 할 기술의 발전 사이클과 자기 능력 평가

내가 프로그래밍 일을 하면서 갖게 된 몇 가지 경험적 지식이 있다. 오늘은 그 중 하나인 "힙스택 보존 법칙"을 설명해보려 한다. 명제는 간단하다.

힙스택을 3개 이상 고르면, 프로젝트는 산으로 간다.

꽤나 공감이 가는 문장일 거라 생각한다. 특히 주니어 시절 전혀 모르는 기술의 늪에 빠져 토끼굴을 파본 경험이 있다면 말이다. 그렇다면 왜 그런 것일까?

프로젝트의 생애

프로젝트는 탄생한다. 마치 갓난쟁이가 세상을 향해 울음을 터뜨리듯, 새로운 세계를 향해 발을 내딛는다. 이 시점에 프로젝트는 "알려져 있지 않다", 다시 말해 호환성을 확보한, 검증된 프로젝트가 아니다.

예시를 들어보겠다. Svelte(자체 템플릿 언어를 사용하는 웹 프레임워크) 같은 신규 프레임워크가 등장한다면, 기존 린터 도구나 포매터 도구와 처음엔 호환되지 않을 것이다. 어쩌면 사용하고 싶은 프로그래밍 언어가 Svelte 템플릿 언어 내부로 통합되지 않을 수도 있다.

ESLint(자바스크립트 생태계 사실상 표준 린터)같은 힙하지 않은 기술이라면 누군가가 호환 레이어나 플러그인을 만들었을 수 있다. 하지만 Biome(자바스크립트 생태계 신흥 린터 겸 포매터)같은 힙한 기술을 덧붙인다면? 어쩌면 호환성 확보를 위해 당신이 직접 코드를 작성해 연동해줘야 할 수도 있다.

우리는 이러한 호환 레이어 내지는 플러그인 이 충분히 많은 프로젝트를 가리켜 커뮤니티가 크다, 또는 성숙하다 고 부른다. 프로그래밍은 결국 두 퍼즐 조각을 끼워맞춰 연결하는 행위를 포함한다. 서로 다른 생각을 가진 프로그래머가 만든 퍼즐 조각이라면, 그 사이를 연결한 새로운 퍼즐 조각이 필요할 가능성이 높다.

그걸 전부 만드는 야크 털 깎기를 반복하다보면 사람은 지친다. 결국, 프로젝트를 산으로 보내버릴 가능성이 높아지는 셈이다.

힙스택을 쓰려는 자, 그 무게를 견뎌라

그렇다면 힙스택을 3개 이상 고르고도 프로젝트가 제 항로를 벗어나지 않았다면, 왜 괜찮았던 걸까? 크게 두 가지 경우로 나눠 생각해볼 수 있겠다.

• 충분히 힙하지 않았다. 다시 말해, 성숙한 기술이다. (기술의 안정화)
• 힙함을 견딜 수 있었다. 다시 말해, 호환 레이어 를 작성할 능력이 된다. (능력의 성장)

위에선 3개 이상이라고 이야기했지만, 능력에 따라 4개, 5개도 괜찮은 사람이 있을지도 모른다. 다른 사람에겐 힙한 기술이, 그에겐 힙하지 않은 기술이 되어버리는 걸지도 모른다. 마치 백독불침, 천독불침, 만독불침의 기인이 되어가듯이.

하지만 그러한 기인이 되기 위해선 약한 독부터 차례로 내성을 길러야 한다. 우리는 그 과정을 학습 이라고 부르기로 했다. 왕관을 쓰려는 자, 그 무게를 견뎌야 하듯, 힙스택을 쓰려는 자. 그 학습의, 충돌의 무게를 견뎌라.

カノニカルなFEPの文書、私だけがおかしいと思っていたわけじゃなかったんだ。

そもそもカノニカルなFEPの文書がCodeberg.orgのMarkdownのプレビューなのがおかしくて、Codeberg Pagesあたりに正式なHTML版をホストするのが筋だろうと思うけど、まずそのために誰が手を動かすのという話になりそう。

以前にそういう話を見かけた気がしたけど、今探しても見当たらなかったのでただの妄想かもしれない

To follow up on my #ActivityPub C2S post from a few days ago, I wrote a blog article on my thoughts about improving the C2S protocol and a description of some related experimentation I've been doing.
https://www.stevebate.net/activitypub-client-api-a-way-forward/

🎉 Big thanks to @2chanhaeng for his first contribution to #Fedify! He implemented the new fedify webfinger command in PR #278, which allows isolated #WebFinger lookups for testing configurations. This addresses the need for developers to test WebFinger functionality without performing comprehensive object retrieval.

The contribution includes:

• A new fedify webfinger <handle> command that accepts @user@domain format handles or URIs
• Clean JSON output of WebFinger JRD results
• Proper error handling for invalid handles and lookup failures
• Complete #CLI integration with help text and usage examples

This was originally filed as issue #260 and marked as a good first issue—perfect for newcomers to learn the codebase structure while contributing meaningful functionality. The PR has been merged and will be included in the upcoming Fedify 1.8.0 release.

We appreciate all first-time contributors who help make Fedify better for the entire #fediverse community. Welcome aboard, ChanHaeng!

#opensource #fedidev

【OSC京都で #Fediverse に関連したセミナーを開催します！】
2025年8月3日（日）の13:00〜 オープンソースカンファレンス京都 #osckyoto で「分散型SNSユーザー有志」として、

「Fediverseのつくりかた 〜開発者・管理者たちの現場から〜」

と題してセミナー講演を行います！
登壇者として私のほか、
#fedibird 運営者の @noellabo さん
#Fedify #Hollo 等の開発者である @hongminhee さん
京都のMastodon地域サーバー #マストどす 管理人の @7_nana さん
をお呼びして開催します。
ActivityPubを中心としたFediverseの今が知れるセミナーです。ぜひご参加ください！

会場：KRP ルーム2B（2階）
日時：2025年8月3日（日）13:00〜
参加費：無料
セミナー詳細：
https://event.ospn.jp/osc2025-kyoto/session/2211664

Gemini로 이런 저런 정신나간 소설들을 작성하는 데 재미를 붙였었는데, 저번에 생성했던 작품은 수위가 제법 있어서 공개하기 꺼려졌지만 이번에 나온 건 그렇지 않아서 기분 좋게 공개할 수 있게 되었다. 그리하여 "산속 무녀들의 비밀"이라는 무녀무녀한 소설을 썼습니다. 홈페이지 레이아웃도 대부분 Gemini로 만들었다(여전히 사람 손길이 좀 필요하긴 했지만). https://w.mearie.org/maidens/

I just published a blog post about the OpenCLI initiative. I think it's time we had a way to standardize CLI automation!

Feedback, suggestions, and thoughts are more than welcome.

https://patriksvensson.se/posts/2025/07/introducing-open-cli

한국 연합우주 개발자 디스코드
https://discord.com/invite/B2ABMBpHNA

排外主義に乗る人の多くは、例えば非正規移民の存在そのものを「不法」としているし、それは交通法規違反の様な、ある程度フェアなイメージで語れるような「不法」ではない。

不法行為をする日本人も同じ様にダメですよね、という様な説明に頷くと、たぶん落とし穴にハマってしまいます。

日語裡有很多像「○っ○り」的單字如: びっくり、すっかり、そっくり、ぐっすり、がっかり、たっぷり、こっそり、てっきり、やっぱり 等 請注意分別。
　＊
日本語には「○っ○り」という形の語が非常に多く、以前『日本語尾音索引 普及版』(笠間書院)で数えてみたところ、83ありました。初級〜中級の学習者には、この中から20くらいは紹介しています。
なぜこの形が多いのか、という研究などあるのかな。#日本語教育
　＊
ちなみに、以下が83の「○っ○り」
うっかり、がっかり、きっかり、しっかり、すっかり、どっかり、ばっかり、ぽっかり、ちゃっかり、ぽっきり、めっきり、ちょっきり、ありっきり、まるっきり、がっくり、こっくり、しっくり、じっくり、そっくり、とっくり、ぱっくり、びっくり、ぽっくり、むっくり、ゆっくり、にっこり、ひょっこり、あっさり、どっさり、ばっさり、もっさり、がっしり、ぎっしり、ずっしり、どっしり、びっしり、みっしり、ぐっすり、げっそり、こっそり、ごっそり、のっそり、ひっそり、ほっそり、ぐったり、はったり、ばったり、ぴったり、べったり、ゆったり、かっちり、→

중국어권 언어는 대충 zh-(tw|hk|mo) → zh-hant, zh-(cn|sg) → zh-hans 정도로 처리를 해뒀는데 … 갑자기 궁금해져서 API 서버로 들어오는 헤더에서 대충 뽑아보니까 -hk/-sg/-mo는 이렇더라.

- zh-hk > en > zh-hant > 이하 생략
- zh-sg > en > (ms|ta)-sg > zh-hans > 이하 생략
- zh-mo > pt-mo > zh-hk > zh-hant > en > 이하 생략

#L10N

Discord は主にユーザコミュニティな気がするし、もっと言えば日本語のそういったコミュニティをあまり知らない

Discordもまあまあみかける気はするがそうなのかもなー

わたしはDiscordのUIがなぜかめちゃくちゃ苦手

@mck Yeah, I could specify the script instead of the region in the language code, but the internationalization framework I'm using doesn't support it. 😩

日本ではソフトウェア技術コミュニティにおいて、DiscordよりSlackの方がより一般的な印象。🤔

Just dropped Hollo 0.6.4 with a minor bug fix.

A quick question for Hong Kongers: If a website or app doesn't support zh-HK locale and only offers zh-CN and zh-TW, which one do you prefer?

해커스펍의 정체. 버튼을 누르면 어떻게 되나요

최신 Unicode Han Database 중 숫자 표현을 보면 아래 라인이 포함되어 있다. 근데 저 유니코드를 검색해보니 兆조가 나오고 이는 두번째 값인 1000000000000 이 맞는 값인 것 같은데

U+5146	kPrimaryNumeric	1000000 1000000000000

kPrimaryNumeric 속성 설명에 의하면 첫 번째 값이 가장 일반적인 것으로 취급되는 것이 맞다는 것 같아서 의문이 들었다 🤔

If an ideograph has more than one numeric value, the first one is to be considered the most common one, and that first value is used for the Numeric_Value property of the ideograph.

Claude에게 물어보니 지역적이거나 역사적인 이유가 있을 것이라 해서 중국에서 다르게 쓰나 싶었는데, 위키백과 문서들을 참고하니 兆조의 의미가 시대에 따라 달라져 왔기도 했고, 표기법(셈법?)에 따라 또 다른 듯 하다. 지금 사용하는 단위마다 10000배씩 변화하는 방식은 만진법이라고 하는 것 같다.

• https://ko.wikipedia.org/wiki/조_(수)#하수
• https://ko.wikipedia.org/wiki/10의_12제곱#한자_수사
• https://ko.wikipedia.org/wiki/중국어_수사

A quick question for Hong Kongers: If a website or app doesn't support zh-HK locale and only offers zh-CN and zh-TW, which one do you prefer?