Profile img

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:.

FedifyHolloBotKit、そしてこのサイト、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
2
6
0
0
1
4

부연설명을 하자면. Git에선 브랜치 자체로는 '변경 사항'이라는 의미가 없습니다. 왜냐면 끝점만 있고 시작점만 있으니까요. 변경 사항을 논하려면 비교 대상인 커밋이 필요합니다.

Rebase를 하는 이유는 연속된 커밋들로(예쁩니다) '변경 사항'을 나타내기 위해서입니다. 그 의도한 '변경 사항'을 만들기 위해, 비교 대상이 될 커밋을 바꾸는게 리베이스입니다. 그러니까 개발자가 의도한 diff를 그대로 표현하지 못해서, diff = head - x니까 이 방정식을 만족시키는 x 커밋을 찾아서 diff를 의도한데로 계산되게 만드는거지요.

참 뻘스럽습니다.

1
14
3
4
3

친구 회사에서 react-form-mozard의 잠깐 언급되었는데, Generator 기반인게 문제가 되어 도입이 바로 기각되었다. yield*async, await, try, catch 등등과 달리 혐오스러운 외양을 갖고 있는게 문제가 되었다. 여러분 제발 키워드 차별을 멈춰주세요ㅠㅠ

5

오래 전

현대 컴퓨터는 계산기라기보다는 복사 기계에 더 가깝다

는 문장을 읽었고 그것에 대해 종종 생각함. 생각해 보면 정말 하는 일이 대개 그런 것에 속한다고 느낌. 어딘가에 있다는 데이터를 모으고 가공하고 정제해서 또 어딘가에 두고 그걸 누군가 가져갈 수 있게 하는 일 끊임 없이 반복함. 데이터의 형식이나 크기나 여러 속성이 다양하고 그래서 다루는 방법과 기술에도 많은 차이가 있지만 어쨌든. 요즘 종종 인용되는 타입 검사는 해결책이 아니라 증상이다(Type Checking is a Symptom, Not a Solution)에 대한 반응들을 보고 직렬화 글과 거기 인용된 인터넷은 디버깅 모드로 돌아가고 있다는 글까지 떠올랐음.

(이 글은 Hackers' Pub에서 제공하는 Markdown 문법 가이드에 익숙해지기 위한 시도로 작성함.)

5

CJS/ESM 문제를 한 번 밟으면 그날 하루는 순삭이다. 심지어 이 문제는 자바스크립트 생태계 전반에 광범위하게 걸쳐 있기 때문에 파악도, 해결도 쉽지 않다. require(esm)이 모든 걸 해결해줄 것이라고 생각했지만 갈 길이 멀다...

4
4

올만에 컴파일러 lexical analysis 설명 읽으니깐 짱 재밌으면서도 동시에 쓰여진 코드도 이해하려고 하니깐 머리가 터질 것 같군...닝겐이 자연어를 처리하는 과정도 재밌는데 기계가 입력 기호들을 처리하는 걸 들여다볼 수 있다는 사실 그 자체가 되게 신기한 것 같다. 전자는 언어라는 추상적 정보를 뭉탱이로 있다가 유링게슝하게 여러 층위로 쪼개서 (예: 통사, 의미) 순차적 혹은 병렬적으로 처리한다는 게 재밌고 후자는 기호를 임의의 단위로 쪼개는 과정들을 구현 수준에서 디테일하게 볼 수 있다는 게 짱 신기하다...여튼 머리도 식힐 겸 운동하러 가야지.

2

LogTape 1.1.0 is out! This release brings “fingers crossed” logging—buffer debug logs quietly, then get the full context when errors occur. Plus a new emit() API for integrating external log sources. Check it out:

https://hackers.pub/@hongminhee/2025/logtape-110

0

Claude에 따르면 대부분의 JavaScript 엔진에서 배열을 비울 때 a.length = 0과 같이 대입하는 게 가장 빠르고 최적화가 잘 된다고 하는데, 이걸 믿어야 할 지 말아야 할 지… 이게 사실이라고 해도 참 답이 없다고 느낀다. 🤦

5
1
1

소스코드 사이의 안정적인 하이퍼링크를 만들수 있는 기능이 없다. 가령 A.hs에서 주석을 쓰면서 B.hs의 foo란 함수의 구현의 특정 부분을 언급하고자 할때, 그냥 B.hs L:77 이렇게, 소스코드가 수정이라도 되면 바로 유효하지 않게되는 방식으로 언급할수 밖에 없다. 만약 소스 코드 어디에서든 전역적인 심볼을 자유롭게 선언할 수 있다면 이 문제를 해결할 수 있을텐데...

2

LWN.net의 What every programmer should know about memory 시리즈를 훑어 보고 나서 든 생각인데, 현대적인 컴퓨터의 메모리 모델이란 건 사용성 관점에서는 놀라울 정도로 투명하게 추상화되어 있으면서 동시에 성능 관점에서는 무시무시할 정도로 새는 부분이 많은 추상화인 것 같다.

인상깊었던 부분 중 하나는, 코드를 실행해 보기 전에는 완벽한 최적화가 사실상 불가능한 메모리 접근 패턴이 드물지 않게 발생할 수 있다는 건데, 이런 부분 때문에 JIT 컴파일러가 AOT 컴파일보다 잠재적으로 더 우수한 성능을 낼 수 있다는 주장이 있었던 걸까 싶다.

6
1
2

TypeScriptの型推論を活用してCLIのバリデーションコードを削除できた話を書きました。「バリデーションせずパースせよ」(Parse, don't validate )の考え方をCLIパーサーに適用したOptiqueというライブラリを作った経緯について。

TypeScriptの型推論でCLIバリデーションをなくせた話

2
0
0
2
5
4

소스코드 사이의 안정적인 하이퍼링크를 만들수 있는 기능이 없다. 가령 A.hs에서 주석을 쓰면서 B.hs의 foo란 함수의 구현의 특정 부분을 언급하고자 할때, 그냥 B.hs L:77 이렇게, 소스코드가 수정이라도 되면 바로 유효하지 않게되는 방식으로 언급할수 밖에 없다. 만약 소스 코드 어디에서든 전역적인 심볼을 자유롭게 선언할 수 있다면 이 문제를 해결할 수 있을텐데...

3

타입 검사는 해결책이 아니라 증상이다〉(Type Checking is a Symptom, Not a Solution).

난 이 글에 동의하지 않는데, 여러 측면에서 그렇지만, 한 측면에만 집중해서 얘기해 보자면: 좋은 아키텍처는 훌륭한 프로그래머를 요구하지만 타입 시스템은 훌륭한 프로그래머를 요구하지 않기 때문이다.

누구나 훌륭한 프로그래머가 되어야만 하는가? 혹은 될 수 있는가? 좋은 아키텍처를 그릴 수 있는 훌륭한 프로그래머가 아니라면 소프트웨어 개발을 해서는 안 될까? 좋은 아키텍처에만 의존하는 것은 잠재적으로 엘리트주의를 끌어들이기 쉽다: 「어떤 시스템이 오작동하는 것은 아키텍처가 나쁘기 때문이다. 아키텍처가 나쁜 이유는 그걸 설계한 프로그래머가 수준 미달이기 때문이다」와 같이.

반면 타입 시스템은 일단 도입만 하면 누구나 그 덕을 볼 수 있다. 팀 내의 프로그래머들의 역량이 뛰어나든 뛰어나지 않든. 훨씬 평범한 보통 사람에게 유리하다. 타입 시스템이 미봉책일 수는 있지만, 그 미봉책이 더 많은 사람들을 프로젝트에 참여할 수 있게 해준다고 생각한다.

@hongminhee洪 民憙 (Hong Minhee) 글의 전체적인 논지가 일관되지 않은거 같습니다. '시간을 일급 개념으로 하자'는건 정말 200% 공감하는 얘긴데, 이건 또 그런 타입시스템을 만들잔 얘기란 말이죠. 응? 제 짐작으론, 저자는 타입 시스템 자체를 반대한다기 보다는, 현재 타입 시스템이 고도화 되는 방향인 더 강력한 추상화보다는, 물리 세계에서의 동작을 잘 묘사하는 쪽이 더 중요하다고 하는거 같습니다. 근데 제목에서 어그로를 살짝 끌어보려다가 글 전체가 좀 중구난방이 된 느낌입니다.

2
2
2
3
1
1
2
3
3
1

아예 .well-known/webfinger만 리다이렉트 걸어서 이메일 호스팅마냥 간단하게 커스텀 도메인 핸들을 주고 싶었는데 쉽지 않을 것 같다...

Actor의 uri 도메인과 웹핑거 핸들 도메인을 다르게 설정할 수 있는가?? (실행시켜본 건 아니고 코드만 봤을때) 마스토돈 - 일단 uri 도메인으로 웹핑거 쿼리를 때린 후 uri가 일치하면 된다 (그래서 여러 서버들이 uri 도메인을 같이 쓰는건 어려울듯...) 미스키 - 무조건 uri 도메인으로 넣어버리는 듯 하다...

2

Actor의 uri 도메인과 웹핑거 핸들 도메인을 다르게 설정할 수 있는가?? (실행시켜본 건 아니고 코드만 봤을때) 마스토돈 - 일단 uri 도메인으로 웹핑거 쿼리를 때린 후 uri가 일치하면 된다 (그래서 여러 서버들이 uri 도메인을 같이 쓰는건 어려울듯...) 미스키 - 무조건 uri 도메인으로 넣어버리는 듯 하다...

1

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

자기소개

@roo_37@hackers.pub

연합우주에 첫 발을 내딛는 루/Roo입니다. SI 1년차 풀스택 웹 개발자로서 웹 개발 전반과 UI/UX, 접근성을 학습하며, DB와 데이터 엔지니어링에도 관심을 두고 있습니다. AI Vibe Coding, 설명 가능한 AI, AI 윤리와 같은 주제에도 흥미를 느끼며, Technical Writing, 번역, 다국어 처리에도 참여합니다. 취미로는 마작(작혼, 일번가, 천봉), 야구(삼성라이온즈), 닌텐도(피크민, 포켓몬), 만화/애니메이션 감상, 언어 공부(듀오링고 1880일), 별 보기, 풍경 사진 촬영, 동물 사랑 등이 있습니다. MBTI는 INFJ-T이며, 불안장애 및 우울증 치료 중입니다. 개발 이야기 외에 다양한 취미와 일상 이야기는 트위터(@Roo_star_)에서 만나볼 수 있습니다.

Read more →
5

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

헬: 하스켈 방언 기반의 셸 스크립팅 언어

박준규 @curry@hackers.pub

Chris Done이 개인적인 셸 스크립팅 용도로 만든 하스켈 방언 기반의 셸 스크립팅 언어인 헬(Hell)을 소개합니다. 저자는 bash의 난해한 문법과 서브 프로세스 의존성 등의 단점을 극복하고자 헬을 개발하게 되었습니다. 헬은 모듈, 패키지 시스템, 추상화 기능 없이 매우 기본적인 기능만을 제공하며, 하스켈의 장점(탄탄한 개념, 동시성, 가비지 컬렉션, 정적 타입 등)을 활용합니다. 헬은 기존 하스켈의 직관을 재사용하고, 안정성과 단순성을 추구하여 자동화 스크립팅에 적합하도록 설계되었습니다. 헬은 냉정하게 완결된 소프트웨어를 지향하며, 스크립팅의 한계를 명확히 정의하여 불필요한 기능 확장을 방지합니다. 릴리스 페이지에서 정적 링크된 리눅스 바이너리를 다운로드할 수 있으며, 구현에 대한 자세한 내용은 소개 슬라이드를 참고할 수 있습니다.

Read more →
9
2
1
6