洪 民憙 (Hong Minhee)

@curry 헉… 천만다행이네요

마인어에는 지진을 뜻하는 고유어가 없다...?

마인어는 사용인구로 따지면 오스트로네시아어족의 맹주라 할 수 있는 큰손이다. 오늘날 말레이시아와 인도네시아를 비롯한 지역에서 쓰이며, 총 화자는 2억 5천만 명이 넘을 것으로 추산되니, 한국어는 명함도 내밀 수 없는 규모다. 언어학계는 마인어의 조상이 PAn(Proto-Austronesian language, 오스트로네시아조어)이라는 것을 거의 확신하고 있다.

PAn 은 수천 년 전 타이완섬에 살던 사람들이 썼을 것으로 추정되는 언어다. 이 사람들은 거대한 타이완섬에 살다가, 어째 답답했는지 아니면 거기 계속 살다가는 먼 미래에 정체자를 배워야 하는 운명을 예감한 것인지, 바다로 뛰쳐나갔다. 이들은 유유히 배를 타고 대양을 누비며 세계 곳곳에 정착한 것으로 추정된다.

전근대에 원양 항해라니 죽음을 자초하는 행위 아닌가? 게다가 타이완섬 앞으로 나가면 약속의 열대저기압 지옥태풍존이잖아? 그런데 PAn 으로부터 분화한 언어들, 오스트로네시아어족의 분포 범위를 보면 무시무시하다. 동으로는 태평양 건너 남미에서, 서로는 인도양 건너 아프리카 대륙 앞 마다가스카르에 이른다! 유럽인들이 "Age of Discovery" 운운하기보다 수천 년 전에, 나침반도 육분의도 없던 시절에, 지구에서 가장 큰 바다를 건너 다닌 비결? 현대의 학자들은 이런저런 짐작만 할 뿐이다. 이들의 항해술은 주로 문자가 아니라 구술로 전승되었기 때문이다.

그런데 아무튼 기원이 타이완섬이고, 타이완섬은 환태평양 지진대의 영향권에 있으므로, PAn 에도 "지진"을 뜻하는 어근이 있는 것은 거의 확실시된다. 현재 언어학계의 다수설은 linuʀ 이다. 여기서 많은 파생형이 발생하였는데 예를 들어 linog 만 봐도 수우우많은 오스트로네시아계 언어들이 이 말을 "지진"으로 쓰고 있음을 알 수 있다.

하지만 마인어에는 이 "linuʀ"에서 파생한, "지진"을 뜻하는 고유어가 전혀 보이지 않는다. 어떻게 된 것일까? 당장 지리적으로나 언어계통적으로나 마인어와 인접한 자바어에도 linuʀ 에서 왔음이 분명해 보이는 ꦭꦶꦤ꧀ꦝꦸ (lindhu) 가 있는데, 마인어에서는 뜬금없이 gempa bumi 라는 표현을 쓴다. 알고 보면 이것은 산스크리트어(?!) भूमिकम्प (bhūmikampa) 에서 온 것이다.

마인어의 조상인 고대 말레이어에 산스크리트어 차용 단어가 많은 것은 사실이다. 하지만 아무리 그래도 "지진"은 인간 생활에 직결되는 중요한 단어이고, 바로 근처의 다른 모든 오스트로네시아어족 정착지에서 모두 "linuʀ" 파생형을 쓰고 있는데, 왜 고대 말레이어는 "지진"의 고유어를 버리고 산스크리트어를 썼을까?

흥미로운 가설은, 하필 마인어가 분화 형성된 지역만 지진대를 멋지게 비켜 가면서, 지진이 너무 오랫동안 없었기 때문에 (!) 고유어가 사멸했다는 것이다.

마인어는 오늘날에는 말레이시아와 인도네시아 전역에서 널리 쓰이지만, 옛날에는 말레이 반도와 말레이 제도에서 주로 쓰는 언어였고, 그보다 더 아주 먼 옛날에는 보르네오 섬의 서부에서 쓰인 것으로 추정된다. 실제로 ArcGIS 의 동남아시아 지진 지도를 보면, 이 지역들만 절묘하게 지진대에서 벗어나는 것을 볼 수 있다...!

#hollo 에서도 한 포스팅에 많은 이미지 첨부된 것 잘 보이는 것 같네요..

Hackers' Pub 행동 강령을 관통하는 큰 키워드가, 존중과 배려라고 느꼈고, 그래서 더욱 Hackers' Pub 을 응원하고 있는데, 오랜 시간이 흘러도 추구하는 가치에 흔들림이 없으면 좋겠고, 여기에 더해 긍정적이고 밝은 에너지가 가득한 공간이 되기를 소망한다.

한가지만 더 첨언하자면, 개발자의 소소한 일상 얘기들도 많이 공유되었으면 좋겠다. (우선 나부터도 해야겠지만)

Hackers' Pub 行動規範を拝見し、その根底にあるキーワードは「尊重」と「思いやり」だと強く感じた。だからこそ、僕はHackers' Pubを心から応援している。時間が経っても、その価値観がブレずに、前向きで明るいエネルギーがあふれる場所であってほしい。

それと、もうひとつだけ言うと、開発者のちょっとした日常の話とかも、もっと共有されるといいなって思う。（まずは自分から始めなきゃだけどね）

사실 Hackers' Pub은 저희 집 홈 서버인 Mac mini M4 깡통 모델에서 돌아가고 있을 뿐만 아니라, 배포도 compose.yaml 파일의 image: 필드를 매번 손으로 고친 뒤 docker compose up -d를 치는 전근대적인 방식으로 이뤄지고 있습니다… 뭔가 자동화를 하고 싶긴 한데 귀찮은 마음이 커서 아직까지 이대로 살고 있네요.

그것 아십니까? 國立國語院(국립국어원)은 漢字(한자) 【茶(다)】에 本音(본음)인 「다」 말고는 慣用音(관용음) 「차」가 있다는 것을 認定(인정)하지 않습니다. 그 代身(대신), 【차】가 이미 固有語化(고유어화)된 낱말이라고 봅니다. 그래서 《標準國語大辭典(표준국어대사전)》에서도 【다례】는 【茶禮(다례)】라고 밝히면서도 【차례】는 【차禮(예)】라고 밝히고 있습니다…

오.. 해커스펍 가입함

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

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

안녕하세요! 오늘은 제가 개발한 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에서 소스 코드를 확인할 수 있습니다.

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

FYI Fedify implements FEP-8fcf, so you can just pass the syncCollection: true option to turn on followers collection synchronization if you use Fedify!

https://mastodon.social/@dansup/114225342328813426

Pixelfed will be implementing FEP-8fcf: Followers collection synchronization across servers

https://codeberg.org/fediverse/fep/src/branch/main/fep/8fcf/fep-8fcf.md

인용: 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년 동안 "문제의 소지는 컴파일 시간에 검출하는 게 좋다"라는 생각이 더 널리 받아들여져서, 다른 언어들도 이런 접근을 더 시도할 여지가 생긴 것 같군요.

よかった！金曜日ではなく土曜日だった！

https://hollo.social/@hongminhee/0195ead2-f6af-7493-9412-b6f5581d1b63

허걱 대박. 초대한 사람 이제 50명째 찍음

@renchap Here it is!

https://writings.hongminhee.org/2024/12/a-year-with-the-fediverse/

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.

큰일이다. 해커스펍에서만 글 장문+단문 1000개 찍겠다

@lionhairdino 저의 영업력 + 물 들어올때 빠른 속도로 노젓는 홍민희님의 피지컬! (아님)

해커스 펍이 (이상할 정도로) 확장하는 힘이 느껴집니다. 어디서 오는 에너지일까요?!

오랜만에 大都食堂(대도식당)에 와서 點心(점심)부터 소고기를 먹었다…

Apple, 대한민국에 ‘나의 찾기’ 기능 추가 도입

대한민국 사용자도 이제 나의 찾기 앱을 사용해 Apple 기기와 개인 물품의 위치를 지도상에서 확인하는 것은 물론 자신의 위치를 가족 및 친구와 공유할 수 있다. https://www.apple.com/kr/newsroom/2025/03/apple-brings-additional-find-my-capabilities-to-south-korea/

많은 부분 Hackers' Pub에서 이미 사용하고 있는 패턴들. 그리고 기본 키를 uuid로 했을 때 지역성(locality)가 떨어져서 성능상 손해를 보는 문제는 UUIDv7을 쓰면 해결된다.

RE: https://sns.lemondouble.com/notes/a61hofry16

@lionhairdino 【覆】를 “덮다”라는 새김으로 쓸 때는 【복】이 아니라 【부】라고 읽어야 합니다. 그러니까 【覆定義】(부정의) 정도가 되겠네요.

실제로 중화권에서는 【覆寫】(부사)라는 번역어를 쓰고 있네요.

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

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

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

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

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

박원순과 장제원은 자살로 말을 할 수 없다. 가해자가 죽어서 죽은 자가 되었고 죽은 자가 말을 없다는 것을 이용해서 죽어서도 가해를 저지른다. 너무 역겹다.

해커스펍 영업할 때 mood

https://youtu.be/gW1wo8EehOk?si=NYRBOiB03b0veaqo

참고로 Hackers' Pub은 딱 한 번 뿐이긴 하지만 핸들을 바꿀 수 있답니다.

사실 ActivityPub이나 WebFinger 명세에서는 핸들을 바꿀 수 없다는 제약이 있지는 않아요. 다만 대부분의 ActivityPub 구현들이 액터 ID에 핸들의 일부를 포함시키기 때문에 바꿀 수 없게 되었을 뿐…^[1]

자세한 설명은 Fedify 문서의 Actor identifier and WebFinger username 항목을 읽어보시면 됩니다.

RE: https://serafuku.moe/notes/a6199pgz4v

@julian @MastodonEngineering Hmm, strange… 🤔

@hongminhee @MastodonEngineering I did a little bit of digging. The tag is read here and stored unchanged for later processing: https://github.com/mastodon/mastodon/blob/b4e56822c72db54ba338940e2517a4e25e2159a6/app/lib/link_details_extractor.rb#L199

It is then passed to the account resolver, still as an unchanged string: https://github.com/mastodon/mastodon/blob/b4e56822c72db54ba338940e2517a4e25e2159a6/app/services/fetch_link_card_service.rb#L158

The account resolver calls its internal function "process_options" to parse the string, which is supposed to strip the leading "@" here: https://github.com/mastodon/mastodon/blob/b4e56822c72db54ba338940e2517a4e25e2159a6/app/services/resolve_account_service.rb#L70

So it's correct that both variants should work the same. I wonder what's going wrong.