JSR 지원이 pnpm과 Yarn에 들어오려는 것 같다.

技術者向けSNS「Hackers' Pub」の招待枠を持っています。ActivityPubに対応し多言語サポートもある、エンジニアや技術に興味がある方のためのコミュニティです。参加希望の方はDMやコメントでメールアドレスをお知らせください。招待状をお送りします。

#HackersPub #テック #プログラミング

RE: https://hackers.pub/@hongminhee/0195faee-783f-7d33-ad90-88c497655ab9

【拡散希望】

Hackers' Pub（ハッカーズ・パブ）は現在開発中の、ソフトウェアエンジニアと技術愛好家の為のActivityPub対応ソーシャルネットワークです。現在は韓国語中心のコミュニティが形成されていますが、日本のエンジニアの方々にも参加していただきたいと考えています。

Hackers' Pubは短文の投稿^[1]と長文の記事^[2]の両方をサポートしています。日常的な会話や簡単な質問は短文投稿で、詳細な技術解説やチュートリアルなどは長文記事で表現できます。QiitaやZennのような技術ブログ機能と、MastodonやMisskeyのようなタイムライン機能を兼ね備えた一つのプラットフォームで、両方の利点を享受できます。何よりもActivityPubプロトコルに対応している為、Mastodon、Misskey、Akkoma等と連携可能です。（このアカウントもHackers' Pubから投稿しています！）

技術的な特徴として、拡張Markdownによるテーブル、脚注、警告ボックス、ダイアグラム、数式などの多様な記法をサポートし、構文ハイライト、行ハイライト、差分表示などの強力なコードブロック機能も備えています。また、様々な言語での投稿が可能で、将来的には自動翻訳機能も予定しています。

Hackers' PubはAGPL-3.0ライセンスの下で開発されているオープンソースプロジェクトです。コードの貢献や機能提案も歓迎しています。

現在はまだ開発段階のため招待制となっています。Hackers' Pubに興味がある方は、DMや返信でメールアドレスをお知らせいただければ、招待状をお送りします。技術コミュニティの一員として、ぜひご参加をお待ちしております。よろしくお願いいたします。

Of which name do you think, when you think of “invention of the web”?

If it's a man, this site is for you to study: https://nowebwithoutwomen.com/

Or this book, Broad Band: https://www.penguinrandomhouse.com/books/545427/broad-band-by-claire-l-evans/

If you give talks, these are especially great resources for getting history straight.

홈서버는 괜히 SBC로 하지 말고
걍 컴퓨터 업글하고 남은 데스크탑/랩탑을 서버로 굴리거나
SBC를 쓸 거면 앗싸리 싼걸 여러개 사서 클러스터링을 하는게 나은 것 같아요

어이쿠, CBPV가 무엇의 약자인지 써놓지를 않았네요. Call-By-Push-Value의 약자입니다. "Push"가 들어가는 걸로 CBV랑은 완전히 다른 것이 되는데요, 어찌 다른지는 글에서 다뤄보도록 하겠습니다.

다음 글은 CBPV에 대해서 써볼까 합니다. CBV(Call-By-Value)나 CBN(Call-By-Name)은 전공자라면 한번쯤은 들어봤을 이름이지만, CBPV는 특정 분야 석박사가 아니면 들어본 적 없을 것 같네요. 하지만 실제 컴파일러 구현(GHC지만...)도 논의되고 있는 만큼 앞으로 유명해지지 않을까 싶어 미리 다뤄보려고 합니다.

좀 쓰다 급하게 마무리하고 자러 갑니다. Hacker's Pub 가입 이후 처음이라 올리긴 하는데요…

옥텟 규칙으로 본 IETF RFC 9110 “HTTP Semantics” https://eonj.github.io/trouble.log/2025-04-09.an-octet-aspect-to-ietf-rfc-9110/

GeekNews의 〈소프트웨어 엔지니어로 산다는 건 미친 짓이야〉 주제에 @youknowone 님께서 쓰신 좋은 댓글:

소프트웨어 개발이 어려운 일이라는 사람들은 본인이 그 일을 하는 이유가 뭘까요? 고되고 힘든 일이지만 보람있는 일이라서 하시나요? 이 업계에서 그런 분들은 그리 많지는 않았던 것 같습니다. 남들이 못하는 것 같으니까 어렵다고 주장하는거지, 실상은 그게 본인한테 가장 쉬운 일이니까 하시는 것 아닌가요? 남들이 좀 띄워준다고 자화자찬하면서 나만 특별한 양 여기면서 눈을 가리지 말고 주위를 봐야합니다. 이공계에서 어떤 분야가 방구석에서 인터넷 좀 보고 독학한다고 (잘 하면) 몇달만에 현업에 투입할 수 있는 전문가가 됩니까?

(…중략…)

물론 남들이 가지지 못한 훌륭한 손재주를 가진 사람은 존중받아 마땅하지만, 약간의 손재주를 연마했다고 해서 소싯적 배워둔 손재주로 평생 먹고 살면 좋을텐데 왜 그럴수 없을까, 나는 이런 훌륭한 손재주를 가졌는데 다른 사람들처럼 힘들게 일하지 않아야 하는 것 아닐까, 나는 남들은 쉽게 하지 못하는 대단한 재능을 가진 것이 아닐까 등등의 특별한 나에 심취하는건 교만에 가까운 일이 아닐까 합니다.

@zerodice0검은곰 님, 어서 오세요!

@kodingwarriorJaeyeol Lee @xtjuxtapose @lionhairdino 언급된 사용자 이름 스타일에 변화를 줘 봤습니다.

@kodingwarriorJaeyeol Lee @lionhairdino 언급된 사용자한테만 검색됩니다. 언급되지 않은 사용자들한테는 검색되지 않고요!

@xtjuxtapose @kodingwarriorJaeyeol Lee @lionhairdino 좋아 보이네요!

리) 드디어 자체적으로 플로우를 생산하기 시작한 해커스펍. 응원합니다.

@kodingwarriorJaeyeol Lee @lionhairdino 지금 생각해 보니 그냥 두꺼운 글씨를 안 쓰면 좀 낫지 않을까 싶기도 하네요.

한번 k8s 를 써보고 나니 지금 있는 시스템을 도커 컴포즈로 기운 시스템에서 k8s 로 이전하고 싶어지긴 하덥니다

특히 컨테이너 바깥 호스트에 있는 nginx 하고는 바이바이 하고 싶긴 함 이제는

@lionhairdino 안 그래도 @kodingwarriorJaeyeol Lee 님께서 이런 PR을 보내주신 바 있습니다.

메타적인 얘기지만, 저는 오늘 “Kubernetes는 적정 기술인가?”라는 떡밥이 Hackers' Pub 내부적으로 발생했다는 사실이 아주 기쁩니다. 여태까지는 Hackers' Pub 자체에 대한 떡밥이거나, GeekNews나 X에서 넘어온 떡밥이었거든요.

k8s를 제대로 공부안하고 있는 이유는 딱 봤을때 k8s의 primitive 위에서 조화롭고 아름다운 뭔가가 만들어질거같은 느낌이 들지 않기 때문이다. 하스켈 튜토리얼 챕터1만 봐도 제대로 공부해봐야겠다 생각이 드는거랑 반대의 이유.

...인데 사실 저 느낌이 완전 틀렸을수 있다. 애초에 ops를 아름답게 하는 방법을 우리가 모르는 걸수도 있고. 또는 ops 자체가 현실의 지저분한 일임을 알기에 그걸 마주하지 않으려고 핑계대는 걸수도 있고. 약간의 상상의 나래를 펼쳐보자면, Pod 2개를 합성하는 연산을 정의하는 방식으로 쌓아올려나가면 어떨까 싶다. 지금은 Pod의 합성이란건 암시적으로 이루어지는데, 한 Pod의 노출된 ip:port를 다른 Pod이 보고 있으면 그게 합성이다;;

쿠버네티스도 간단하게 쓸 수 있죠. 요즘 k3s 같은거 쓰면 구성도 쉽고, 사용도 그냥 kubectl apply -f deployment.yaml 하면 끝인데. 이렇게만 쓰면 도커컴포즈랑 그렇게 다르지 않습니다.

근데도 쿠버를 쓰지 말라는 이유는, '잘못 쓸 여지'가 많기 때문입니다

쿠버를 쓰다 보면, 괜히 GitOps 하고 싶어서 ArgoCD 깔고, 서비스 메시 한다고 Istio 깔고, prometheus 깔고, thanos 셋업하고, EFK 스택 만들고, 이러다보면 아무도 유지보수 못하는 쿠버네티스 클러스터가 완성됩니다. 아니면 옵스 엔지니어가 주 40시간 전체를 이거를 간신히 존속시키는데에만 다 쓰고 나머지 아무것도 못 합니다.

이런거 다 참을 수 있고 k3s로 깔고 kubectl apply -f 만 치고 살거면 쿠버 쓰셔도 됩니다.

첨부한 사진이 무슨 링크드인에 '2025년 쿠버네티스 표준 구성' 이라고 돌아다니던데, 제발 이러지 마세요.

도커컴포즈 쓰면 이런걸 아예 못 하게 되니까 오히려 장점인거죠. 잘못 쓸 여지가 없음.

쿠버세란 옵스 엔지니어 연봉을 뜻한다

@akastoot악하 홈 서버에서는 그냥 Docker Compose 정도로도 웬만큼 커버가 되는 것 같아요.

사실 애초부터 Drizzle ORM이 클라이언트에서 계산되는 칼럼 같은 기능을 제공해 주면 일이 이렇게 복잡하지 않을 것 같은데. 무슨 ORM이 게터(getter)를 정의할 수 없는 건지… 아니면 있는데 나만 모르고 있는 건가!?

PostgreSQL에서는 GENERATED ALWAYS AS 절을 통해 생성된 칼럼을 지원하는데, 이게 간단한 사칙연산이나 문자열 연결 정도는 쉽게 가능하지만, 이 안에서 서브쿼리를 쓸 수 없기 때문에 조금만 복잡한 계산도 할 수가 없다. 나 같은 경우에는 {"foo": 1, "bar": 2, "baz": 3}과 같은 jsonb 값이 있을 때 이로부터 6과 같은 합산을 해야 하는 상황인데, sum() 같은 집계 함수를 쓸 수 없기 때문에 원하는 동작을 만들어 내지 못한다… 최후의 카드로 커스텀 함수 정의해서 쓰는 방법이 있긴 한데… 음…

내가 k8s 자체를 딱히 좋아하느건 아닌데(어차피 잘 몰라서 좋고 싫고 할것도 없음), 근데 요즘은 처음부터 k8s 쓰는게 오버엔지니어링은 아니게 되었다. k3s같은 것도 있고(NixOS로 하면 5분이면 띄운다), 어차피 머신 적을때는 별로 설정할것도 없을 것이다. 혹시 뭔가 +알파로 해줘야할게 있을때 helm install로 날먹 할수 있다는 여지도 있다. 그 다음에 서비스 운영은 이제 docker-compose up하냐, kubectl apply -f deployment.yaml 하냐의 차이가 된다.

근데 또 복잡하지 않은 인프라라면, 때가되서 k8s로 옮기는 것도 크게 어렵지 않을 것이다. 나는 '옮기는' 종류의 일을 매우 하기 싫어/두려워하기 때문에(DB 마이그레이션 처럼) 그냥 service.k3s.enabled = true 해버린다.

RE: https://hackers.pub/@ujuc/0196189f-1c95-7120-831b-27d7c51e8f38

Hollo도 코드 정리를 좀 해야 하는데… 사실 Fedify 빼고는 다 개판이긴 함. Fedify 만들다가 힘 다 빼서 그 뒤에는 대충 짰기 때문…

개판으로 짜 뒀던 Hackers' Pub 코드, 더이상은 무리라서 리팩터링을 조금씩 해보고 있다. (여러분이 생각하는 것 이상으로 개판입니다.)

@xtjuxtapose Nix는 제가 잘 아는 분야가 아니니 도커 컴포즈 쪽만 생각하고 이야기해보면.... 컴포즈는 쿠버네티스처럼 "편하게 이것저것 띄울 수 있는 플랫폼"이라고 보기에는 부족하거나 불편한 점이 꽤 많다고 느꼈습니다. 물론 앱 한두 개만 띄우고 말 거면 컴포즈가 훨씬 간단한 건 맞지만 개인적으로는 쿠버네티스의 플랫폼스러움이 주는 장점이 꽤나 크게 느껴지더라구요

@xtjuxtapose 부정적인 에모지는 넣지 않는 것으로 가닥을 잡아서 (대신 신고 기능을 만들 예정입니다), 아마 💔는 넣기 힘들 것 같지만, 😅는 넣을 수 있을 것 같습니다. 비좁은 UI가 문제긴 한데… 고려해 보도록 하겠습니다! 추가 자체가 어렵진 않을 것으로 보여서요.

📣 Exciting news! Fedify CLI is now available via Homebrew!

If you're using #Homebrew on macOS or #Linuxbrew on Linux, you can now install our CLI toolchain with a simple command:

brew install fedify

This makes it even easier to get started with building your federated server app. Try it out and let us know what you think!

#Fedify #ActivityPub #fedidev #fediverse

@curry박준규 음, 저로서는 재현이 안 되네요… 🙄

똑같은 얘기를 닉스, 닉스오에스, 닉스옵스로도 할 수 있어요. "아 이거 걍 선언형으로 파일 작성하고 nixops deploy --check 하나만 때리면 알아서 이것저것 다 뜨고 다 설정될 텐데 괜히 귀찮게 왜 쿠버네티스를"

근데 현실적으로는 그냥 도커 컴포즈가 제일 삽질의 총량이 적죠...

쿠버는 마세라티 문제가 맞음! 제발 쿠버 섣불리 쓰지마!
어케어케 쿠버를 쓰기로 결정했다면
istio 같은거 제발 쓰지마!!!!!!

@saschanazKAGAMI🏳️‍🌈🏳️‍⚧️ 그게 제일 바람직하다는 것에 저도 동의해요. 다만 현실적으로는 아무래도 DB라든지 MQ라든지 이것저것 같이 띄워야 하다 보니, 서비스 운영을 하려다 보면 그런 전체 형상 관리를 위한 추상화 계층이 있기는 있어야 하는 것 같아요. 물론 도커 컴포즈를 안 쓰고 앤서블로 그런 모든 것을 관리할 수도 있고, 아예 닉스나 닉스오에스를 써서 더 아름답게 할 수도 있겠습니다만... 도커 컴포즈 정도면 타협 가능한 것으로...

개인적으로 쿠버네티스를 편하게 쓰기 위한 공부를 어느 정도 마친 상태에서 보면 "아 이거 쿠버 하나만 떠 있으면 편하게 이것저것 띄우고 할 수 있는데 괜히 귀찮게 세팅해야 하네"라는 생각이 들기도 하지만 😅 쿠버네티스 잘 모르는 상태에서는 참 막막하겠다 싶긴 합니다....

RE: https://hackers.pub/@xt/01961970-a29f-78ff-baaf-1db2056a78e1

(도커도 쓰기 싫고 그냥 샌드박스된 바이너리 하나 돌리면 전부 알잘딱 돌아갔으면 좋겠어요)

RE: https://hackers.pub/ap/notes/01961970-a29f-78ff-baaf-1db2056a78e1

저, 저도 90% 이상의 경우 도커 컴포즈 정도가 적당한 추상화 수준이라고 생각해요...

실제로 쿠버네티스 쓰는 팀에서 일해 본 경험도 그렇고, 주변 이야기 들어 봐도 그렇고, 도입하면 도입한 것으로 인해 증가하는 엔지니어링 코스트가 분명히 있다는 점은 누구도 부인하지 않는 것 같은데요. 쿠버네티스를 제대로 쓰는 것 자체도 배워야 할 것도 많고, 엔지니어가 유능해야 하고, 망치도 들여야 하고... 웬만하면 전담할 팀이 필요하지 않나 싶어요. (전담할 '사람' 한 명으로 때우기에는, 그 사람 휴가 가면 일이 마비되니까.)

엔지니어만 100명이 넘는 곳이라면 확실히 도입의 이득이 더 크겠지만, 반대로 혼자 하는 프로젝트라면 도무지 수지타산이 안 나올 것이라고 생각합니다. 따라서 쟁점은 그 손익분기점이 어디냐일 텐데... "대부분의" 서비스는 대성공하기 전까지는 도입 안 해도 되지 않나, 조심스럽게 말씀드려 봅니다. 즉 쿠버네티스가 푸는 문제는 마세라티 문제인 것이죠...

특히 클라우드 남의 컴퓨터 를 쓰지 않고 베어메탈 쓰는 경우는 더더욱...

RE: https://hackers.pub/@hongminhee/019618b4-4aa4-7a20-8e02-cd9fed50caae

@curry박준규 어라… 아예 안 보인다고요? 아마 버그 같은데 살펴보겠습니다.

Hackers' Pub의 에모지 반응 기능은 Mastodon의 좋아요, Misskey 계열, Pleroma 계열, kmyblue 및 Fedibird의 에모지 반응 기능과 호환됩니다. 기술적으로는 기본 에모지인 ❤️는 Like 액티비티로 표현되며 그 외 나머지 에모지는 EmojiReact 액티비티로 표현됩니다. Mastodon, kmyblue, Fedibird의 좋아요는 ❤️ 에모지 반응으로 변환됩니다 (Misskey의 동작과 유사). 또한, Misskey 계열과 달리 한 사람이 한 콘텐츠에 여러 에모지 반응을 남길 수도 있습니다 (Pleroma 계열의 동작과 유사). Hackers' Pub 사용자가 남길 수 있는 에모지 반응은 ❤️, 🎉, 😂, 😲, 🤔, 😢, 👀 이렇게 7종이며, 그 외의 에모지 및 커스텀 에모지는 보낼 수는 없고 받는 것만 됩니다.

에모지 반응 기능이 배포되었습니다. 당분간 버그가 좀 있을 수도 있지만 양해 바랍니다. 전 이제 차단을 구현하러 가겠습니다…

Update: 이제 합니다!

https://www.prisma.io/blog/prisma-orm-6-6-0-esm-support-d1-migrations-and-prisma-mcp-server

RE: https://hackers.pub/@bgl/01960fc7-4502-777d-9761-01bfe6b87ed7

ANSI SQL 표준에서 NULL 값이 서로 DISTINCT하지 않은 것은… 그 성질이 아주 편할 때도 많지만, 그렇지 않을 때는 아주 골치가 아프다. 특히 UNIQUE 제약 조건이나 색인과 결부되면 더욱 그렇다.

@kodingwarriorJaeyeol Lee 홈 서버니까 아직은 괜찮긴 해요. ㅎㅎㅎ 나중에 규모 커지면 결국 옮기긴 해야 하는데 미래의 제게 미루고 있습니다…

Kubernetes를 아직도 쓸 줄 모르는 1人… Hackers' Pub도 그냥 Docker Compose로 운영하고 있습니다. 🙄

RE: https://hackers.pub/@ujuc/0196189f-1c95-7120-831b-27d7c51e8f38

하.. S3는 글로벌하게 네임스페이스를 구분하지 않았으면 좋겠다... 이름 짓기 너무 힘들다ㅠ.ㅠ.

@curry박준규 Dependent Haskell은 흥미로운 내용을 다루기에는 아직 너무 갈 길이 멀고... 그렇다고 동기만 다루자니 좀 심심하네요. 아마 Agda나 Coq등을 조금 다뤄보지 않을까 싶습니다. 관련 내용으로 Dependent Haskell을 좀 언급할 수는 있겠습니다.

Jira, Linear 등 일정 관리 앱이 풀어야할 가장 어려운 문제는, 사용자 중 상당수는 애초에 일정 관리를 하기 싫어하는 사람이라는 것이다. 안타깝게도 나도 거기 포함되는데, 문제는 그런 사람일 수록 일정 관리가 꼭 필요하다. 나중에 프로젝트가 복잡해지면 일정 관리 앱을 켜는 거 자체를 꺼리게 된다. 이걸 어쩌면 좋지.