@arkjunJuntai Park ActivityPub으로는 여전히 Hashtag로 될 것 같긴 한데 실제로 주제를 건 게시물의 예시를 봐야 알 수 있겠네요… 혹시 주제를 건 Threads 게시물이 보이면 제보 부탁드립니다. ㅎㅎㅎ

@arkjunJuntai Park @parksbSimon Park 요즘도 pnpm이 가장 빠르긴 한 것 같아요. 아, Bun이 더 빠른가? 잘 모르겠군요…

백문이 불여일견. 이렇게 나옵니다:

https://blog.joinmastodon.org/2024/07/highlighting-journalism-on-mastodon/

이제 단문에 포함된 대표 링크에 대해 Open Graph 메타데이터를 추출하여 표시하게 되었습니다. 또한, 링크에 fediverse:creator 메타데이터가 있을 경우, 저자의 연합우주 프로필까지 하단에 표시하게 됩니다.

@linear “조용한 공개”는 “공개”와 거의 모든 면에서 같지만 로그인 안 했을 때 Hackers' Pub 첫 화면에서 보이지 않는다는 점, 외부 연합우주 서버에서 “연합 타임라인”에 뜨지 않는다는 점만 달라요.

@parksbSimon Park 사견으로는 그냥 다들 Deno를 썼으면 좋겠네요…

모든 자바스크립트 개발자들이 단 하나의 패키지 매니저와 단 하나의 빌드 시스템, 단 하나의 모듈 시스템을 사용하면 좋겠다고 진심으로 생각한다

C++ 표준화 위원회(WG21)에게 C++의 원 저자인 비야네 스트롭스트룹Bjarne Stroustrup이 보낸 메일이 이번 달 초에 본인에 의해 공개된 모양이다. C++가 요즘 안전하지 않은 언어라고 열심히 얻어 맞고 있는 게 싫은지 프로파일(P3081)이라고 하는 언어 부분집합을 정의하려고 했는데, 프로파일이 다루는 문제들이 아주 쉬운 것부터 연구가 필요한 것까지 한데 뒤섞여 있어 구현이 매우 까다롭기에 해당 제안이 적절하지 않음을 올해 초에 가멸차게 까는 글(P3586)이 올라 오자 거기에 대한 응답으로 작성된 것으로 보인다. 더 레지스터의 표현을 빌면 "(본지가 아는 한) 스트롭스트룹이 이 정도로 강조해서 말하는 건 2018년 이래 처음"이라나.

여론은 당연히 호의적이지 않은데, 기술적인 반론이 대부분인 P3586과는 달리 해당 메일은 원래 공개 목적이 아니었음을 감안해도 기술적인 얘기는 쏙 빼 놓고 프로파일이 "코드를 안 고치고도 안전성을 가져 갈 수 있다"는 허황된 주장에 기반해 그러니까 프로파일을 당장 집어 넣어야 한다고 주장하고 있으니 그럴 만도 하다. 스트롭스트룹이 그렇게 이름을 언급하지 않으려고 했던 러스트를 굳이 들지 않아도, 애당초 (이 또한 계속 부정하고 싶겠지만) C++의 주요 장점 중 하나였던 강력한 C 호환성이 곧 메모리 안전성의 가장 큰 적이기 때문에 프로파일이 아니라 프로파일 할아버지가 와도 안전성을 진짜로 확보하려면 코드 수정이 필수적이고, 프로파일이 그 문제를 해결한다고 주장하는 건 눈 가리고 아웅이라는 것을 이제는 충분히 많은 사람들이 깨닫지 않았는가. 스트롭스트룹이 허황된 주장을 계속 반복하는 한 C++는 안전해질 기회가 없을 듯 하다.

@bglbgl gwyng @nyeongAn Nyeong (安寧) 저는 나중에 AI에게 지배 받을지도 몰라서 미리미리 존댓말을 쓰고 있습니다.

Mastodon이나 Misskey 등에서 민감한 내용으로 지정한 단문의 내용이나 첨부 이미지는 이제 Hackers' Pub에서 뿌옇게 보이게 됩니다. 마우스 커서를 가져다 대면 또렷하게 보이게 됩니다. 다만, Hackers' Pub에서 쓰는 단문을 민감한 내용으로 지정하는 기능은 없습니다. (아마도 앞으로도 없을 것 같습니다.)

오늘 하려던 Fedify 작업은 얼추 끝내서, 다시 Hackers' Pub 작업에 손을 댑니다.

Coming soon in #Fedify 1.5.0: Smart fan-out for efficient activity delivery!

After getting feedback about our queue design, we're excited to introduce a significant improvement for accounts with large follower counts.

As we discussed in our previous post, Fedify currently creates separate queue messages for each recipient. While this approach offers excellent reliability and individual retry capabilities, it causes performance issues when sending activities to thousands of followers.

Our solution? A new two-stage “fan-out” approach:

1. When you call Context.sendActivity(), we'll now enqueue just one consolidated message containing your activity payload and recipient list
2. A background worker then processes this message and re-enqueues individual delivery tasks

The benefits are substantial:

• Context.sendActivity() returns almost instantly, even for massive follower counts
• Memory usage is dramatically reduced by avoiding payload duplication
• UI responsiveness improves since web requests complete quickly
• The same reliability for individual deliveries is maintained

For developers with specific needs, we're adding a fanout option with three settings:

• "auto" (default): Uses fanout for large recipient lists, direct delivery for small ones
• "skip": Bypasses fanout when you need different payload per recipient
• "force": Always uses fanout even with few recipients

// Example with custom fanout setting
await ctx.sendActivity(
  { identifier: "alice" },
  recipients,
  activity,
  { fanout: "skip" }  // Directly enqueues individual messages
);

This change represents months of performance testing and should make Fedify work beautifully even for extremely popular accounts!

For more details, check out our docs.

What other #performance optimizations would you like to see in future Fedify releases?

#ActivityPub #fedidev

Finished the #Fedify queue optimization work. Tests written, docs completed. Should make activity delivery much faster for high-follower accounts.

저는 AI에게 감사 인사를 하는 데에도 돈이 든다는 걸 깨달아버려서, 이제는 감사도 표하지 않는 삭막한 인간이 되고야 말았습니다.

참고로 Hackers' Pub은 대부분의 경우 Fedify의 bleeding edge 버전을 쓰고 있습니다.

@curry박준규 네, 맞습니다!

…라고 썼지만, Fedify의 신기능을 테스트하기 위해 Hackers' Pub에 적용해 보고 있습니다. ㅎㅎㅎ

와 보인다! 보여요!

이제 여기서 글 쓰면 블스에도 보이는 건가?

오늘 하루는 Fedify 작업을 해야 해서 아마도 Hackers' Pub 개발은 못 할 것 같습니다.

@curry박준규 네, 공간이 좁아서 검색창을 숨겨버렸어요… 물론 수동으로 https://hackers.pub/search?query= 뒤에 검색 키워드를 붙여서 들어가면 검색을 할 수 있긴 합니다. ㅋㅋㅋㅋ

🚀 GNOME 48 is here!
After months of hard work from contributors worldwide, this release brings exciting updates and improvements. 🎉

🔎 Check out what’s new in #GNOME48 in the release notes: https://release.gnome.org/48

그동안 동료들한테 Cursor 쓰자고했는데 그들이 오소독스 Emacs 매니아들이란 문제가 있었다.

작년에 Nix로 nvidia gpu 지원까지 포함해서 구축해놓은 k3s 클러스터에다가, 오늘 아침에 1시간만에 aider로 쓸수있게 DeepSeek R1을 띄웠고 한번 써보자고 했다. 최근에 한 것 중 가장 가성비 좋은 작업인듯 하다.

리브랜딩을 거친 것도 학습에 치명적인듯... 예를 들어 언어 설정 파일이 bsconfig.json에서 rescript.json으로 이름이 바뀌었는데, rescript.json이 이미 있음에도 bsconfig.json을 자꾸 만들려고 한다. 일일이 사전 지시를 넣어주어야 하는데 🤔

대-AI 시대가 열렸으면 내가 낯선 언어라도 린터, 컴파일러만 잘 되어 있으면 그걸로 피드백 줘서 PoC 하나 뚝딱할 수 있겠지? 싶어서 ReScript로 쇼기 만들어보고 있는데 아쉽게도 LLM 친구들이 ReScript를 잘 못한다

Getting back to #Fedify development today! Working on optimizing the outgoing activity queue to improve response times. Currently focusing on reducing latency when sending posts to large follower counts—should make the whole publishing experience feel much snappier.

https://github.com/fedify-dev/fedify/issues/220

#ActivityPub #fedidev

@curry박준규 그나저나 회사에서 Haskell 쓰시나요? 부럽습니다.

We've been working on adding custom background task support to #Fedify as planned for version 1.5.0. After diving deeper into implementation, we've realized this is a more substantial undertaking than initially anticipated.

The feature would require significant API changes that would be too disruptive for a minor version update. Therefore, we've decided to postpone this feature to Fedify 2.0.0.

This allows us to:

• Design a more robust and flexible worker architecture
• Ensure better integration with existing task queue systems
• Properly document the new APIs without rushing

We believe this decision will result in a more stable and well-designed feature that better serves your needs. However, some smaller improvements from our work that don't require API changes will still be included in Fedify 1.5.0 or subsequent minor updates.

We appreciate your understanding and continued support.

If you have specific use cases or requirements for background task support, please share them in our GitHub issue. Your input will help shape this feature for 2.0.0.

#ActivityPub #fedidev

오, HackersPub 기여할만한거 방금 떠오름

Patch releases for #Fedify versions 1.0.21, 1.1.18, 1.2.18, 1.3.14, and 1.4.7 are now available. These updates address two important bugs across all supported release lines:

1. Fixed a WebFinger handler bug that prevented matching acct: URIs with port numbers in the host. Thanks to @revathskumarRevath S Kumar for reporting and debugging the bug!
2. Resolved server errors that occurred when invalid URLs were passed to the base-url parameter of followers collections.

We recommend all users upgrade to these latest patch versions for improved stability and federation compatibility.

#ActivityPub #fedidev

@linear 1번은 페디버스에 한 표요! 💨

1. IT 관련 관심 있는 주제 아무거나 골라서 3~5분 정도 발표하는 자리가 생겼는데 fediverse 와 small web 중 뭘로 할지 아직도 고민중.
2. Swift만 8년을 쓰다가 정말 간만에 html/css 쓰려니까 작업 속도가 굼벵이가 따로 없다. 이것만큼은 나도 주니어. GitHub Pages 쓰면서 jekyll 이 익숙해져서 일단은 개인 블로그도 jekyll 로 만들었는데 요즘은 Hugo가 대세라는 것 같아 언젠가는 찍먹을 해 볼지도.
3. 폴더 내의 모든 파일에 대해 단어 replace 하기 : sed -i '' -e 's/old_word/new_word/g' *
4. 누가 iOS 개발 어떻냐고 물어볼 때마다 "애플이 만든 프로그램 위에 애플이 만든 언어로 코드를 짜서 애플이 제작한 기기 위에 동작하는 모바일 앱을 만들 건데 그게 애플이 관리하는 마켓 심사를 통과해야 하는 게 참으로 문제"라고 우스갯소리처럼 말해 왔는데 돌이켜보면 그건 내 직군에 대한 꽤 근본적인 불만이었는지도. URL만 있으면 누구나 어디서든 접속할 수 있는 웹의 힘이 막강하다고 느낀다. 진작 이쪽으로 사이드 프로젝트 파 볼 걸 그랬나? 싶고. 누군가는 모바일의 힘을 더 크게 생각하겠지만⋯.

오랜만에 소프트웨어 프로그래머로 일하고 있는 고등학교 동창을 만나서 몇 시간 즐겁게 수다도 떨고 자극도 받고 왔다. 취미로 분산 데이터베이스를 만드는 등 자기 계발을 아주 열심히 하고 있어서 본받아야겠다고 생각했다.

@curry박준규 저는 WSL 안에서 sshd랑 tailscaled 깔아서 바로 접속했었어요.

@kodingwarriorJaeyeol Lee 앞으로의 행보를 응원합니다…!

이름에 들어간 커스텀 絵文字(에모지) 렌더링 具顯(구현)하는 거 정말 짜쳐요.

https://serafuku.moe/notes/a5j9oaaww1

@arkjunJuntai Park 어라… 이상하네요. 🤔 rel="me" 속성이 빠지거나 한 건 아닌데…

타임라인과 RSS 피드에 단문 없이 게시글만 보는 필터를 추가했습니다.

@arkjunJuntai Park 헛 빠르시네요 ㅋㅎㅎ

아직 招待制(초대제)이긴 하지만 Hackers' Pub도 velog의 代案(대안)입니다! 게다가 ActivityPub도 支援(지원)하기 때문에 Mastodon이나 Misskey 等(등) 다른 聯合宇宙(연합우주)(fediverse)와도 아무 問題(문제) 없이 相互(상호) 疏通(소통) 可能(가능)하답니다.

https://uri.life/@newflow/114179231102154137

@arkjunJuntai Park 아마 이제 고쳐졌을 겁니다. 확인해 보시겠어요?

@arkjunJuntai Park 아, 이건… @ 문자가 @로 들어가서 그런 것 같습니다. Threads가 틀린 건 아니고, Hackers' Pub 쪽에서 고쳐야 하는 문제 같아요. 금방 고칠 수 있을 것 같습니다!

아, rel="me" 속성이 대체 뭔지 궁금하신 분들은 @morealLee Dogeon 님께서 작성하신 rel="me" 메모를 참고하시면 도움이 될 것 같습니다.

마스토돈이 다른 계정의 팔로잉/팔로워를 잘 보여주는 것도 아니고, 그렇다고 팔로우할만한 계정을 잘 추천해주는 것도 아니라서 꽤 발품을 팔아아 했다. 그래서 '읽기는 트위터에서, 쓰기는 마스토돈에서' 해왔는데, 요즘엔 hackers.pub 덕분에 피드에 읽을거리가 많이 늘어났다.

@nyeongAn Nyeong (安寧) 오, 잘 되는 걸 보니 뿌듯하네요! 👍

이제 프로필의 링크에 인증 여부가 보이게 됩니다. 링크를 인증하기 위해서는, 링크된 페이지 측에서도 Hackers' Pub 프로필을 rel="me" 속성과 함께 링크해야 합니다. Mastodon이나 GitHub 같은 경우 프로필에 링크를 추가하면 rel="me" 속성이 추가되게 되어 있으니, Mastodon이나 GitHub 프로필 링크를 추가하면 인증은 자동으로 될 겁니다. 개인 웹사이트가 있으신 분들은 Hackers' Pub 프로필을 rel="me" 속성과 함께 링크하면 인증이 됩니다.

참고로 인증은 프로필 설정을 저장할 때 이뤄집니다. 이미 Mastodon이나 GitHub 프로필을 링크해 두신 분들은 인증 표시가 안 뜰 수도 있는데, 그럼 프로필 설정에 들어가셔서 저장 버튼을 한 번 눌러주시면 인증 버튼이 붙을 겁니다.

@honnip 안녕하세요, 어서오세요!

Hackers' Pub의 숨은 기능 하나. 어떤 페이지에서든 URL의 쿼리 문자열에 lang=ko처럼 ISO 639-1 언어 코드를 지정하면 그 페이지가 해당 언어로 표시됩니다. 이렇게 지정된 언어는 계정의 언어 설정이나 브라우저의 언어 설정보다 우선합니다. 제가 개발할 때 번역 잘 적용되나 확인하려고 만든 기능이랍니다.