Profile img

洪 民憙 (Hong Minhee)

@hongminhee@hackers.pub · 1014 following · 723 followers

Hi, I'm who's behind Fedify, Hollo, BotKit, and this website, Hackers' Pub! My main account is at @hongminhee洪 民憙 (Hong Minhee) :nonbinary:.

Fedify, Hollo, BotKit, 그리고 보고 계신 이 사이트 Hackers' Pub을 만들고 있습니다. 제 메인 계정은: @hongminhee洪 民憙 (Hong Minhee) :nonbinary:.

Fedify、Hollo、BotKit、そしてこのサイト、Hackers' Pubを作っています。私のメインアカウントは「@hongminhee洪 民憙 (Hong Minhee) :nonbinary:」に。

Website
hongminhee.org
GitHub
@dahlia
Hollo
@hongminhee@hollo.social
DEV
@hongminhee
velog
@hongminhee
Qiita
@hongminhee
Zenn
@hongminhee
Matrix
@hongminhee:matrix.org
X
@hongminhee
0
0
0
0
0
0
0
0
0
0
0
0

deno-task-hooks: Git 훅을 Deno 태스크로 쉽게 관리하기

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

안녕하세요! 오늘은 제가 개발한 deno-task-hooks 패키지를 소개해 드리려고 합니다. 이 도구는 Deno 태스크를 Git 훅으로 사용할 수 있게 해주는 간단하면서도 유용한 패키지입니다.

어떤 문제를 해결하나요?

Git을 사용하는 개발 팀에서는 코드 품질 유지를 위해 커밋이나 푸시 전에 린트, 테스트 등의 검증 작업을 실행하는 것이 일반적입니다. 이러한 작업은 Git 훅을 통해 자동화할 수 있지만, 기존 방식에는 몇 가지 문제가 있었습니다:

  • Git 훅 스크립트를 팀원들과 공유하기 어려움 (.git 디렉토리는 보통 버전 관리에서 제외됨)
  • 각 개발자가 로컬에서 훅을 직접 설정해야 하는 번거로움
  • 훅 스크립트의 일관성 유지가 어려움

deno-task-hooks는 이러한 문제를 해결하기 위해 Deno의 태스크 러너를 활용합니다. Deno 태스크는 deno.json 파일에 정의되어 버전 관리가 가능하므로, 팀 전체가 동일한 Git 훅을 쉽게 공유할 수 있습니다.

어떻게 작동하나요?

deno-task-hooks의 작동 방식은 간단합니다:

  1. deno.json 파일에 Git 훅으로 사용할 Deno 태스크를 정의합니다.
  2. hooks:install 태스크를 실행하면, 정의된 태스크들이 자동으로 .git/hooks/ 디렉토리에 설치됩니다.
  3. 이후 Git 작업 시 해당 훅이 트리거되면 연결된 Deno 태스크가 실행됩니다.

설치 및 사용 방법

1. hooks:install 태스크 추가하기

먼저 deno.json 파일에 hooks:install 태스크를 추가합니다:

{
  "tasks": {
    "hooks:install": "deno run --allow-read=deno.json,.git/hooks/ --allow-write=.git/hooks/ jsr:@hongminhee/deno-task-hooks"
  }
}

2. Git 훅 정의하기

Git 훅은 hooks: 접두사 다음에 훅 이름(케밥 케이스)을 붙여 정의합니다. 예를 들어, pre-commit 훅을 정의하려면:

{
  "tasks": {
    "hooks:pre-commit": "deno check *.ts && deno lint"
  }
}

3. 훅 설치하기

다음 명령어를 실행하여 정의된 훅을 설치합니다:

deno task hooks:install

이제 Git 커밋을 실행할 때마다 pre-commit 훅이 자동으로 실행되어 TypeScript 파일을 검사하고 린트 검사를 수행합니다.

지원되는 Git 훅 종류

deno-task-hooks는 다음과 같은 모든 Git 훅 타입을 지원합니다:

  • applypatch-msg
  • commit-msg
  • fsmonitor-watchman
  • post-update
  • pre-applypatch
  • pre-commit
  • pre-merge-commit
  • pre-push
  • pre-rebase
  • pre-receive
  • prepare-commit-msg
  • push-to-checkout
  • sendemail-validate
  • update

이점

deno-task-hooks를 사용하면 다음과 같은 이점이 있습니다:

  1. 간편한 공유: Git 훅을 deno.json 파일에 정의하여 팀 전체가 동일한 훅을 사용할 수 있습니다.
  2. 설정 용이성: 새 팀원은 저장소를 클론한 후 한 번의 명령어로 모든 훅을 설치할 수 있습니다.
  3. 유지 관리 용이성: 훅 스크립트를 중앙에서 관리하므로 변경 사항을 쉽게 추적하고 적용할 수 있습니다.
  4. Deno의 안전성: Deno의 권한 모델을 활용하여 훅 스크립트의 보안을 강화할 수 있습니다.

마치며

deno-task-hooks는 작은 패키지이지만, Git과 Deno를 함께 사용하는 팀의 개발 경험을 크게 향상시킬 수 있습니다. 코드 품질 유지와 개발 워크플로우 자동화를 위해 한번 사용해 보세요!

패키지는 JSR에서 다운로드할 수 있으며, GitHub에서 소스 코드를 확인할 수 있습니다.

피드백과 기여는 언제나 환영합니다! 😊

Read more →
0
0
1
geeknews_bot @geeknews_bot@sns.lemondouble.com
Public
Shared by 洪 民憙 (Hong Minhee)

코드와 한글 [Code and Hangul]
------------------------------
# 전북대학교 이상로 교수의 연구 아카이브: 한글 코드와 기술 표준화의 기록

이상로 교수가 운영했던 웹사이트는 2000년대 초반 한국의 문자 처리 기술과 코드 변환 연구를 체계적으로 정리함으로, 한글 정보화와 국제 표준화 과정에서 중요한 역할을 했습니다. 이 사이트는 당시 컴퓨터 과학 분야의 학문적 연구와…
------------------------------
https://news.hada.io/topic?id=20085&utm_source=googlechat&utm_medium=bot&utm_campaign=3140

코드와 한글 [Code and Hangul] | GeekNews

전북대학교 이상로 교수의 연구 아카이브: 한글 코드와 기술 표준화의 기록이상로 교수가 운영했던 웹사이트는 2000년대 초반 한국의 문자 처리 기술과 코드 변환 연구를 체계적으로 정리함으로, 한글 정보화와 국제 표준화 과정에서 중요한 역할을 했습니다. 이 사이트는 당시 컴퓨터 과학 분야의 학문적 연구와 실용적 응용을 연결하는 가교 역할을 수행했습니다.주요 콘

news.hada.io · GeekNews

0
0
0
0
0
0
0
0
0
0
0
0
Simon Park @parksb@silicon.moe
Public

일정 추산은 어려운 일이다. TWP(Two-Week Principle)는 모든 시간 참조를 표준화하는 새로운 시간 척도다. 이 제안에 따르면 시간과 관련된 모든 질문에 반사적으로 "2주"라고 응답해야 한다. rfc-editor.org/rfc/rfc9759

RFC 9759: Unified Time Scaling for Temporal Coordination Frameworks

Estimating time requirements for tasks, both critical and mundane, remains a challenge in engineering, business, and everyday communication. Existing models fail due to inherent unpredictability and inconsistencies in human estimation. This document introduces the Two-Week Principle (TWP), a novel, universally adaptable time scale that seeks to standardize all temporal references to a singular, uniform duration. TWP ensures clarity, predictability, and synchronization across all sectors that rely on time-based scheduling.

www.rfc-editor.org

Simon Park @parksb@silicon.moe
Public
Shared by 洪 民憙 (Hong Minhee)

작년에 비하면 조금 약하다 ㅎㅎ 참고로 작년에는...

Faster than LIght speed Protocol(FLIP)은 LLM을 이용해 패킷이 수신 피어에 도착하기 전에 미래의 패킷을 예측함으로써 광속보다 빠른 전송을 달성한다. (...) 이 프로토콜 명세는 AI와 LLM을 사용하기 때문에 멍청한 인간은 이 명세를 리뷰해서는 안 된다고 여겨졌다. 대신 여러 LLM 챗 서비스의 코멘트와 제안으로 개선되어 승인받았다. rfc-editor.org/rfc/rfc9564

RFC 9564: Faster Than Light Speed Protocol (FLIP)

The recent advances in artificial intelligence (AI) such as large language models enable the design of the Faster than LIght speed Protocol (FLIP) for Internet. FLIP provides a way to avoid congestion, enhance security, and deliver faster packets on the Internet by using AI to predict future packets at the receiving peer before they arrive. This document describes the protocol, its various encapsulations, and some operational considerations.

www.rfc-editor.org

0
0
0
Simon Park @parksb@silicon.moe
Public
Shared by 洪 民憙 (Hong Minhee)

일정 추산은 어려운 일이다. TWP(Two-Week Principle)는 모든 시간 참조를 표준화하는 새로운 시간 척도다. 이 제안에 따르면 시간과 관련된 모든 질문에 반사적으로 "2주"라고 응답해야 한다. rfc-editor.org/rfc/rfc9759

RFC 9759: Unified Time Scaling for Temporal Coordination Frameworks

Estimating time requirements for tasks, both critical and mundane, remains a challenge in engineering, business, and everyday communication. Existing models fail due to inherent unpredictability and inconsistencies in human estimation. This document introduces the Two-Week Principle (TWP), a novel, universally adaptable time scale that seeks to standardize all temporal references to a singular, uniform duration. TWP ensures clarity, predictability, and synchronization across all sectors that rely on time-based scheduling.

www.rfc-editor.org

0
0
0
0
0
0
0
0
0
Simon Park @parksb@silicon.moe
Public
Shared by 洪 民憙 (Hong Minhee)

@kodingwarriorJaeyeol Lee 심플하게 가장 가까운 .vim/config.lua 파일을 찾아서 해당 파일에 명시된 린터와 포매터 정보를 읽도록 만들었어요. 급하게 필요해서 만든거라 엉성해요 ㅎㅎ github.com/parksb/dotfiles/com

워크스페이스 기능 PoC · parksb/dotfiles@ca3bc66

My configuration files. Contribute to parksb/dotfiles development by creating an account on GitHub.

github.com · GitHub

0
1
0
0
0
0
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