洪 民憙 (Hong Minhee)

@hongminhee@hackers.pub · 587 following · 390 followers

Hi, I'm who's behind Fedify, Hollo, BotKit, and this website, Hackers' Pub!

Fedify, Hollo, BotKit, 그리고 보고 계신 이 사이트 Hackers' Pub을 만들고 있습니다.

Fedify、Hollo、BotKit、そしてこのサイト、Hackers' Pubを作っています。

嗨，我是 Fedify、Hollo、BotKit 以及這個網站 Hackers' Pub 的開發者！

Website
hongminhee.org
GitHub
@dahlia
Hollo
@hongminhee@hollo.social
DEV
@hongminhee
velog
@hongminhee
Qiita
@hongminhee
Zenn
@hongminhee
Matrix
@hongminhee:matrix.org
X
@hongminhee
0
1
0
bgl gwyng @bgl@hackers.pub
Public

근데 cabal처럼 기본이 스냅샷 모드인건 별로 같다. cabal로 locking하려면 시간으로(스냅샷을 특정할) 해야한다;; npm같이 각 패키지 버전과 lock이 있는 편이, 일단 심리적으로 더 든든하고, 또 가장 원자적인 동작을 더 확실하게 만든단 점에서 좋다.

대신 그 위에서 스냅샷(이라고 해야하나, 다른 이름이 있던거 같기도한데)을 다시 구현할수 있다. Expo같은 경우에 expo 패키지에 따라 나머지 expo-* 들의 버전이 결정되도록 한다.

0
1
0
0
1
0
Juntai Park @arkjun@hackers.pub
Public
Shared by 洪 民憙 (Hong Minhee)

불과 작년까지도, DB설계시에 uuid 를 쓰지 않는 키값은 int 보다 bigint 를 선호했으나, 이제는 로그성 데이터같은 빈번하게 등록되는 데이터가 아닌 이상 int 를 사용한다. bigint 의 사용은 당연히 미래를 위한 결정이었지만, 내가 만드는 서비스들이 웬만해서는 int 를 뛰어넘지 않는다는 것을 깨달았고 (약 20억이면 충분), 언젠가 bigint 로 마이그레이션해야 하는 서비스가 되었으면 좋겠다.

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

인용한 글의 내용과는 상관 없는 이야기인데, 현재는 단문에서는 단문이든 게시글이든 인용할 수 있는 반면, 게시글에서는 단문도 게시글도 인용을 못 하게 되어 있다. 별 생각을 안 하고 그렇게 만든 거긴 한데, 잘 생각해 보니 오히려 인용 기능은 게시글에서 더 유용할 것 같다.

하루 빨리 게시글에서도 인용이 가능하게 개선을 하도록 하겠습니다…



RE: https://hackers.pub/@xt/2025/stackage-why

0
0
0

洪 民憙 (Hong Minhee) shared the below article:

스태키지 큐레이션이 성공할 수 있었던 것은 하스켈이라는 언어와 생태계의 특징도 컸습니다.

juxtapose @xt@hackers.pub

인용: https://hackers.pub/@bgl/0195f0eb-88dd-77e3-a864-f0371e85b270

스태키지(Stackage)는 하스켈이 (의외로) 성공하여 해키지(Hackage)가 거대해지자, 그 거대함 때문에 발생하는 불편을 해소하는 한 방책으로 고안되었습니다. 그런데 당시에 해키지만큼 거대한 생태계를 갖추고 있으면서 동시에 "컴파일이 성공한다면 실행도 아마 성공할 것"이라는 훌륭한 속성을 갖는 언어는 달리 없었죠. 러스트가 있지 않으냐? 스태키지가 처음 나온 게 2012년입니다. 러스트는 아직 crates.io 도 자리잡기 전이었죠. (사실 이 시점의 러스트는 지금과는 언어 자체가 많이 다른 언어였고요.)

하스켈의 패키지 버저닝 정책에 따르면, 후방호환성 깨지는 변경은 반드시 메이저 버전을 올려야 하고, 마이너 버전만 올리는 변경은 후방호환성 유지될 때에만 가능합니다. 이런 정책 당연히 좋지만, 사람이 내용을 잘 숙지하고 지켜야 의미가 있습니다. 후방호환성을 깨면서 마이너 버전만 올리는 실수는 어떤 개발자든 할 수 있죠.

그런데 하스켈의 경우, 인간이 실수해도 기계가 잡아 줄 여지가 처음부터 매우 큰 언어이고, 예를 들어 어떤 함수가 핵미사일을 발사할 수 있는지 아닌지를 함수 실행 없이도 식별할 수 있는 언어라고들 하죠. 하스켈의 마지막 표준이 2010년에 나왔으니 2010년을 기준으로 하면, 당시 하스켈이 제공하는 "컴파일 시간 보장"의 범위는 그야말로 독보적이었습니다. (하스켈보다 더 강한 보장을 제공하는 언어들은 있었지만, 그만한 라이브러리 에코시스템이 없었고요.)

그래서 스태키지라는 모형이 의미가 있었습니다. A라는 패키지의 새 마이너 버전이 해키지에 올라오면, 스태키지에서 자동으로 가져갑니다. 스태키지는 같은 큐레이션에 포함된 다른 패키지들 중 A에 의존하는 패키지들을 추리고, 얘네한테 A의 새 버전을 먹여도 빌드가 잘 되는지 검사합니다. 이들 중 하나라도 깨지면? A 패키지는 해키지에서는 버전이 올랐으나, 스태키지에서는 버전이 오르지 않게 됩니다. 그리고 A 패키지의 제공자에게 자동으로 깃허브 멘션 알림이 갑니다!

("패키지 저자"와 "패키지를 스태키지에 제공하는 제공자"가 같은 사람이 아니어도 된다는 점도, 노동력의 효과적 분담에 한몫했습니다.)

이 모든 과정이 자동화되어 있는데, 이것만으로도 99.99%의 호환성 문제가 사라지고, 그러면서도 웬만한 라이브러리들은 충분히 최신 버전으로 쓸 수 있습니다. LTS와 나이틀리가 구분되어 있는 것도, LTS가 GHC 버전에 대응하여 여러 버전이 유지되는 것도, 실제 개발에서 아주 편리하고요.

스태키지가 개쩌는 부분은 "버저닝 정책에 완벽하게 부합하는데도 현실적으로 후방호환성 파괴를 일으키는" 변경점들도 잡아낸다는 것입니다. 아주 단순한 예시로 "많이 쓰이는 이름"이 있습니다. 예를 들어 어떤 라이브러리가 아주 널리 쓰이는데, 제공하는 네임 바인딩은 몇 개 안 되고, 그래서 대부분의 사용자가 그걸 그냥 전역 네임스페이스에 다 반입해서 쓴다고 칩시다. 어느 날 이 라이브러리가 process 라든지 f 같은 새 네임을 추가 제공하기 시작하면? 정책 규범에 따르면, 이것도 마이너 버전만 올려도 되는 변경점이 맞습니다. 하지만 현실에서는 많은 패키지들을 박살내겠죠. 언어를 막론하고 있을 수 있는 일인데, 이런 것들까지 스태키지에서 아주 높은 확률로 다 잡힙니다.

그리고... 이런 게 잘 된다는 것은 언어 그 자체의 특성도 있지만, 생태계 전체의 문화적인 특성도 있는데요. 하스켈도 라이브러리 제작자가 충분히 악독하다면, 컴파일러에게 안 잡히면서 인류문명멸망시키는 코드 변경을 얼마든지 슬쩍 끼워넣을 수 있습니다. 악의가 아니더라도 부주의로 후방호환성을 깰 수 있고요. 그런데 하스켈은 대부분의 라이브러리 설계자들이 "되도록 많은 것을 컴파일 시간에 잡고 싶다"라는 명확한 욕망으로 설계를 하는 경향이 뚜렷합니다. 그래서 호환성 문제는 웬만하면 스태키지 선에서 잡히고, 스태키지 큐레이션은 지난 10년 동안 실무상 아주 유용한 도구로 기능해 온 것이죠.

어지간하면 큐레이션만 잘 고르고 잘 갱신하면 되고, 종속성 목록에는 mypkg >= 2.1.1 && < 2.1.2 이런 거 하나도 관리 안 하고 그냥 mypkg 라고만 써도 된다는 것이, 솔직히 개짱편합니다. 다행히 지난 10년 동안 "문제의 소지는 컴파일 시간에 검출하는 게 좋다"라는 생각이 더 널리 받아들여져서, 다른 언어들도 이런 접근을 더 시도할 여지가 생긴 것 같군요.

Read more →
2
0
1
Perlmint @perlmint@hackers.pub
Public
Shared by 洪 民憙 (Hong Minhee)

CMake 3.20 즈음에서 add_test동작이 바뀐 것 같은데 generator expression중 conditional expression으로 인자 없음 혹은 정해진 값을 기대하는 코드가 인자 없음 대신 “”로 생성을 해버려서 동작이 완전히 틀려져버렸고, 4.0에서도 유지되고 있다. 어디서 바뀌었는지 릴리즈노트를 조금 봤는데 못 찾았다.

0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
bgl gwyng @bgl@hackers.pub
Public
Shared by 洪 民憙 (Hong Minhee)

스냅샷 방식이 이론적으로는 참 좋은데, 제대로 돌아가려면 사람들이 새로운 버전을 테스트하고 호환되는 버전을 업데이트하는 등의 잡다구리한 수고를 다 같이 해줘야 한다는 문제가 있(었)다. 하지만 요즘 잡다구리한 수고가 매우 저렴했으니 올바른 방법을 다시 밀고나갈수 있게되었다.



RE: https://hackers.pub/@hongminhee/0195f09a-a7d0-79aa-a819-bdcf97d6d830

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

Giving up the dylib dream—이 글에서 제안하고 있는 “안정적인 crates.io 미러” (“a ‘stable’ crates.io mirror”) 아이디어를 듣자마자 Haskell의 Stackage가 떠올랐다.

Stackage는 Haskell의 패키지 저장소인 Hackage에서 상소 호환되는 패키지들을 엄선한 스냅숏(curated snapshots)을 제공한다. 이는 글에서 언급된 여러 문제들을 해결한다:

  1. 모든 패키지가 함께 빌드되는 것을 보장하는 장기 지원(LTS) 릴리스 제공.
  2. 호환 가능한 의존성의 최소 집합을 해결함으로써 “의존성 지옥”(dependency hell) 방지
  3. 혁신을 가능케 하면서도 생태계의 안정성도 창출
  4. 검증되고 호환 가능한 패키지 세트를 제공하여 배포판 메인테이너를 도움

Stackage 모델은 특히 Stack이라는 툴체인을 통해 Haskell 쪽에서 꽤 성공을 거두었는데, 생태계 안정성과 발전 사이의 균형을 맞추는 방식으로, 아마 Rust에서도 잘 작동할 수 있을 것이다.

Giving up the dylib dream

octet-stream.net

0
0
1
0
0
0
Ahn Kiwook @aioo@hackers.pub
Public
Shared by 洪 民憙 (Hong Minhee)

Spring AI 문서를 보고 있는데 업그레이드 노트 중에 Claude Code를 이용해서 자동으로 업그레이드를 진행하는 방법을 안내하는 섹션이 있어서 흥미로웠다. 요약하면 Claude Code CLI 도구를 다운로드하고 제공된 프롬프트를 그대로 실행하라는 내용. 대 AI 시대에 발맞춰 앞으로 이런 방식도 많이 사용되려나 싶음.

Automating upgrading using AI

You can automate the upgrade process to 1.0.0-SNAPSHOT using the Claude Code CLI tool with a provided prompt. The prompt will guide the AI to perform the following tasks:

  1. Update the Spring AI BOM version to 1.0.0-SNAPSHOT
  2. Ensure all required repositories exist in your build configuration
  3. Update Spring AI artifact IDs according to the new naming patterns

To use this automation:

  1. Download the Claude Code CLI tool
  2. Copy the prompt from the update-to-snapshot.txt file
  3. Paste the prompt into the Claude Code CLI
  4. The AI will analyze your project and make the necessary changes

This approach can save time and reduce the chance of errors when upgrading multiple projects or complex codebases.

Upgrade Notes :: Spring AI Reference

docs.spring.io

0
0
0
juxtapose @xt@hackers.pub
Public
Shared by 洪 民憙 (Hong Minhee)

"pub"의 외래어 표기법에 따른 표기는 "펍"이 아니라 "퍼브"입니다. 유성음으로 끝나는 단어라서 "ㅡ"를 붙입니다. 이것은

  • log: "록"이 아니라 "로그"
    • blog: "블록"이 아니라 "블로그"
  • tag: "택"이 아니라 "태그"
  • egg: "엑"이 아니라 "에그"
  • dog: "독"이 아니라 "도그"
  • mug: "먹"이 아니라 "머그"
  • hub: "헙"이 아니라 "허브"
  • pad: "팻"이 아니라 "패드"
  • lid: "릿"이 아니라 "리드"
  • mud: "멋"이 아니라 "머드"

등등, 유성음으로 끝나는 영어 단어에 일관적으로 적용되는 규칙입니다.

보통 외래어 표기법의 규칙이 무시되는 사례를 보면, 규칙이 모호성을 낳는다는 이유로 기피되는 경향이 있는데요. 예를 들어 "seat"와 "sheet"를 구분하려는 욕망으로 인해 /ʃiː/를 "시"로 표기하는 원칙을 깨고 후자를 "쉬트"로 적는 것이 있죠.

그런데 유성음으로 끝나면 "ㅡ"를 붙인다는 규칙은 원어의 유성 음가를 반영하는 동시에, 대체로 모호성을 해소하는 방향으로 표기를 만들어 주는 좋은 규칙입니다. 이 규칙이 없었으면 꼼짝없이

  • "dog"와 "dock"이 "독"이라는 동음이의어가 되고
  • "pig"와 "pick"도 "픽"이라는 동음이의어가 되고
  • "rug"와 "luck"도 "럭"이라는 동음이의어가 되고
  • "tag"와 "tack"도 "택"이라는 동음이의어가 되고

영 좋지 않았겠죠.

0
0
0

洪 民憙 (Hong Minhee) shared the below article:

juxtapose

juxtapose @xt@hackers.pub

The term "juxtapose" originates from the French "juxtaposer," combining "juxta-" (near) and "pose" (place), with Latin roots meaning "near" and "place." It is pronounced differently in the UK and General American English. As a verb, "juxtapose" means to place items side by side, particularly to highlight contrast or comparison. Related to this verb is the noun "juxtaposition," referring to the act of placing things together for this purpose. Understanding the etymology and usage of "juxtapose" enhances clarity in both writing and speech.

Read more →
0
0
0
0
0
0
0
1
0
0
1
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
bgl gwyng @bgl@hackers.pub
Public
Shared by 洪 民憙 (Hong Minhee)

난 요거 반대의 도구를 찾고 있는데, remote로 electron이나 tauri등을 띄운다음에 웹뷰를 브라우저로 볼수있게하는 것이다. 안그래도 지금 GitButler 깔았는데 remote 사용을 지원안해서 난감해졌다.

0
2
0
bgl gwyng @bgl@hackers.pub
Public

난 요거 반대의 도구를 찾고 있는데, remote로 electron이나 tauri등을 띄운다음에 웹뷰를 브라우저로 볼수있게하는 것이다. 안그래도 지금 GitButler 깔았는데 remote 사용을 지원안해서 난감해졌다.

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

블로그에 글 쓸만한게 생각나서 브레인스토밍 중인데, CLI 도구 중에 출력을 csv, yaml, json으로 내뱉는게 어떤거 어떤거 있을까요?

Ruby로 one-liner 스크립트 작성하고, CLI 도구 조합해서 나만의 요술봉 만드는 가이드 작성할것입니다요

0
1
0
0
0
0
Lionhairdino @lionhairdino@mastodon.social
Public

오버라이딩 을 재정의라 번역하는데, 왜 "(덮을 복)정의"라 안했을까? (물론 나도 어색하다) 재정의는 뭔가 기존 것을 치워버리고, 다시 정의하는 것이고, 오버라이딩은 기존 것을 그대로 두고, 그 위에 레이어를 두는 느낌이라 같은 듯 다르다.

만일 복정의라 번역한다면, 오버로딩을 중(거듭 복) 정의라 하는데, 이 것과 같은 글자를 쓰는 문제가 생길 수 있겠다.

재정의, 중복 정의는 나도 번역이 마음에 들긴 한데, 늘 재정의가 살짝 걸리적 거린다.

닉스 공부하며 노트하다가 비슷한 듯 다른 오버레이, 오버라이딩의 적당한 번역어가 떠오르지 않아 잡생각으로 빠졌다.

널리 알려진 적당한 짧은 번역 단어(보통 한자 한 두 글자)가 없으면, 그냥 원문이 낫지 않을까? 표기만 Overlay가 아니라 오버레이로.

0
0
0
Lionhairdino @lionhairdino@mastodon.social
Public

오버라이딩 을 재정의라 번역하는데, 왜 "(덮을 복)정의"라 안했을까? (물론 나도 어색하다) 재정의는 뭔가 기존 것을 치워버리고, 다시 정의하는 것이고, 오버라이딩은 기존 것을 그대로 두고, 그 위에 레이어를 두는 느낌이라 같은 듯 다르다.

만일 복정의라 번역한다면, 오버로딩을 중(거듭 복) 정의라 하는데, 이 것과 같은 글자를 쓰는 문제가 생길 수 있겠다.

재정의, 중복 정의는 나도 번역이 마음에 들긴 한데, 늘 재정의가 살짝 걸리적 거린다.

닉스 공부하며 노트하다가 비슷한 듯 다른 오버레이, 오버라이딩의 적당한 번역어가 떠오르지 않아 잡생각으로 빠졌다.

널리 알려진 적당한 짧은 번역 단어(보통 한자 한 두 글자)가 없으면, 그냥 원문이 낫지 않을까? 표기만 Overlay가 아니라 오버레이로.

0
0
0
Lionhairdino @lionhairdino@mastodon.social
Public
Shared by 洪 民憙 (Hong Minhee)

오버라이딩 을 재정의라 번역하는데, 왜 "(덮을 복)정의"라 안했을까? (물론 나도 어색하다) 재정의는 뭔가 기존 것을 치워버리고, 다시 정의하는 것이고, 오버라이딩은 기존 것을 그대로 두고, 그 위에 레이어를 두는 느낌이라 같은 듯 다르다.

만일 복정의라 번역한다면, 오버로딩을 중(거듭 복) 정의라 하는데, 이 것과 같은 글자를 쓰는 문제가 생길 수 있겠다.

재정의, 중복 정의는 나도 번역이 마음에 들긴 한데, 늘 재정의가 살짝 걸리적 거린다.

닉스 공부하며 노트하다가 비슷한 듯 다른 오버레이, 오버라이딩의 적당한 번역어가 떠오르지 않아 잡생각으로 빠졌다.

널리 알려진 적당한 짧은 번역 단어(보통 한자 한 두 글자)가 없으면, 그냥 원문이 낫지 않을까? 표기만 Overlay가 아니라 오버레이로.

0
2
0
0
1
0
0
1
0
0
0
0
Juntai Park @arkjun@hackers.pub
Quiet public

Hackers' Pub 에서 좋아요 느낌을 표현하고 싶을 때

  • 공유 혹은 댓글을 다는 방법이 있겠고
  • 그냥 지나치기는 아쉬워서
  • (우선은) 공유를 하고 있기는 한데,

잘하고 있는건가 싶은 생각이 들 때도 있다.

개인적으로 공유는 팔로워들에게 공유하고 싶을 때 쓰고 싶은 기능인데… 최근에 다소 남발하게 된다.[1]

서로 멘션 주고 받다가, 답글 마지막에 좋아요 하트 느낌으로 마무리 짓고 싶은 마음 뿜뿜할 때에도, 그냥 아무말 안하고 마무리 하기도 하고. (이모티콘 댓글 정도를 남긴다거나 하는 방법은 있음)

@hongminhee洪 民憙 (Hong Minhee) 님이 이모티콘 좋아요 기능을 고민중이라 하시니, 그때까지는 좀 더 공유 기능을 남발해 보는 걸로. 😂

결론 : 이 글은 무차별 공유에 대한 자기 합리화를 위한 글이었던 것입니다. 😅

  1. 좋아요 느낌의 표현으로도 병행해서 사용하고 있으므로 ↩︎

0
1
0
Juntai Park @arkjun@hackers.pub
Quiet public
Shared by 洪 民憙 (Hong Minhee)

Hackers' Pub 에서 좋아요 느낌을 표현하고 싶을 때

  • 공유 혹은 댓글을 다는 방법이 있겠고
  • 그냥 지나치기는 아쉬워서
  • (우선은) 공유를 하고 있기는 한데,

잘하고 있는건가 싶은 생각이 들 때도 있다.

개인적으로 공유는 팔로워들에게 공유하고 싶을 때 쓰고 싶은 기능인데… 최근에 다소 남발하게 된다.[1]

서로 멘션 주고 받다가, 답글 마지막에 좋아요 하트 느낌으로 마무리 짓고 싶은 마음 뿜뿜할 때에도, 그냥 아무말 안하고 마무리 하기도 하고. (이모티콘 댓글 정도를 남긴다거나 하는 방법은 있음)

@hongminhee洪 民憙 (Hong Minhee) 님이 이모티콘 좋아요 기능을 고민중이라 하시니, 그때까지는 좀 더 공유 기능을 남발해 보는 걸로. 😂

결론 : 이 글은 무차별 공유에 대한 자기 합리화를 위한 글이었던 것입니다. 😅

  1. 좋아요 느낌의 표현으로도 병행해서 사용하고 있으므로 ↩︎

0
0
0
0
0
0
0
0
0