Hackers' Pubに興味はあるけれど、DMで招待状をお願いするのは気が引けるという方のために、Googleフォームを作成しました。メールアドレスを入力するだけで、Hackers' Pubの招待状をお送りします。たくさんのご応募をお待ちしています‼️
洪 民憙 (Hong Minhee)
@hongminhee@hackers.pub · 565 following · 372 followers
Hi, I'm who's behind Fedify, Hollo, BotKit, and this website, 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
현재 Hackers' Pub은 Fresh 2.0 알파 버전을 사용하고 있는데, Fresh 자체의 한계점도 많이 느꼈고 무엇보다 최근 몇 달 사이에 정식 릴리스를 향한 진전이 보이지 않기에 GraphQL 준비가 끝나면 프런트엔드를 SolidStart로 점진적으로 옮겨가고자 한다.
과연 나는 언제까지 compose.yaml에서 이미지 태그 수정하고 docker compose up -d를 하는 수동 배포 방식을 유지할 것인가…
개인적으로 영단어 “side effect”의 가장 적절한 번역은 “부작용”이라고 생각하고, 실제로 프로그래밍 이외의 분야에서는 여전히 이 번역어를 가장 많이 쓰는 것 같은데… 사람들이 “부작용”을 副作用이 아니라 否(?)作用이라고 착각하는 것을 염려해서인지 프로그래밍 분야에서는 “부수 효과” 같은 번역어를 더 많이 쓰는 듯하다. “부작용”의 “부”(副)는 “사장”–“부사장”할 때의 “부”인데 말이다.
바이브 코딩이 아니라 바이브 코칭이다. LLM의 작업을 쉴 새 없이 살펴보며 이상한 짓 시도할 때마다 옆에서 코칭해 줘야 함…
흑흑… 안돼! (Hackers' Pub은 Deno로 돌아가고 있습니다…)
LLM으로 번역 기능 만드는데 원본 서식을 그대로 유지하게 하는 게 정말 어려운 것 같다…
.github/copilot-instructions.md, .cursorrules, .windsurfrules, CLAUDE.md… 이것 말고도 많이 있을텐데, 어차피 들어가야 하는 내용은 다 거기서 거기. 지금은 한 파일에 적고 심볼릭 링크로 같은 곳을 바라보게 하고 있지만, .editorconfig처럼 그냥 어떤 식으로든 표준화가 되었으면 좋겠다.
대충 만든 Open Graph 이미지 생성기도 좀 제대로 다시 짜야 하는데… 지금은 너무 울퉁불퉁함.
Hackers' Pub에 다국어 콘텐츠 기능 추가하는 중… 일단 맨 처음에는 기계 번역 먼저 넣고, 나중에 수동 번역 기능도 넣으려고 합니다.
Drizzle ORM이 어서 Temporal.Instant를 지원했으면 좋겠다. 그 전에 드라이버가 먼저 지원해야 하려나? PostgreSQL의 timestamp with time zone 타입이 나노초 정밀도인데 Date는 밀리초 정밀도라 값이 손실되고 있다.
저도 비슷한 생각인데, Haskell이나 Rust는 코너 케이스를 다루지 않고는 컴파일도 못 하게 금지하는 경우들이 꽤 많고 (그래서 좋은 언어지요), 빠르게 해피 패스만을 검증하고 싶을 때는 Python 같은 널널한 언어(복잡하고 규모가 큰 소프트웨어를 만들 때는 나쁜 언어가 되지요)가 쉽게 느껴질 수 있다고 생각합니다. 즉, Haskell이나 Rust가 어렵다고 말할 때의 어려움은 개념적 이해의 난도라기 보다는 시행착오의 커브의 경사를 얘기하는 것 같아요.
비슷한 측면에서 저는 Python의 들여쓰기를 강제하는 문법이 프로그래밍 초심자에게 좋은 습관을 처음부터 정착시키는 데에는 일조할 수 있겠지만, 결코 쉽지는 않다고 생각합니다.
RE: https://hackers.pub/@bgl/01967f97-67ab-7a98-a6e5-16cb3ef31856
Hackers' Pub 저장소에 보내주신 
- https://github.com/hackers-pub/hackerspub/pull/44
- https://github.com/hackers-pub/hackerspub/pull/45
- https://github.com/hackers-pub/hackerspub/pull/46
- https://github.com/hackers-pub/hackerspub/pull/47
여러분의 많은 기여 감사합니다. 🙏
참고로 현재 hackers.pub에 배포된 게 어떤 버전인지 알고 싶다면 https://hackers.pub/nodeinfo/2.1에 들어가셔서 software.version을 보시면 됩니다. 버전의 마지막 부분인 빌드 넘버가 Git 커밋 해시입니다.
Temporal.Instant는 나노초 정밀도를 지원한다는 것 하나만으로 Date뿐만 아니라 JavaScript 생태계의 다른 모든 대안 시간 라이브러리가 대체할 수 없는 API라고 생각한다. 표준인데다 쓰기 쉬운 API는 덤.
몰랐는데 WezTerm을 만든 Wez Furlong이 원래 Watchman 만든 사람이었구나.
Hackers' Pub에 GraphQL API를 추가하고 있습니다. https://hackers.pub/graphql가 GraphQL 엔드포인트입니다. 아직 인증 기능도 없고 노출된 노드도 얼마 없습니다만, 차차 추가해 나갈 예정입니다. 다음은 예시 쿼리입니다:
{
actorByHandle(handle: "@hongminhee@hackers.pub") {
uuid
iri
type
handle
instance {
host
software
softwareVersion
}
name
bio
avatarUrl
url
}
}
@like_keyboard호띠 님 안녕하세요, 어서 오세요!
- Hackers' Pub에 GraphQL 도입을 위한 밑작업 (
@xiniha 님이 도와주실 예정)
- Solid 공부
- 새 작업용 키보드 구입 (아마도 게이트론 저소음 갈축이나 정전용량 무접점으로 갈 듯)
- BotKit 비용 최적화
@parameterfreak 님 어서 오세요!
한국어로 된 Fedify 튜토리얼인데, GeekNews에 올렸습니다.
Deno가 Node.js보다 인기 있는 놀라운 연합우주…
RE: https://hollo.social/@hongminhee/019661bd-601a-7df4-aa40-688011ec43ac
여태까지 JavaScript에서 eval()이 일반 함수인 줄로만 알고 있었는데, 직접 eval()과 간접 eval() 사이에 동작의 차이가 있다는 것을 알게 되었다.
Hackers' Pub은 Deno로 돌아가니까 Deno에 한 표 넣음.
다른 얘기지만 “에모지 리액션을 하나밖에 달지 못한다”는 Misskey의 제약이라고 알고 있습니다. Hackers' Pub도 그렇고 Pleroma/Akkoma도 그렇고 한 사람이 같은 게시물에 여러 에모지를 달 수 있게 되어 있어요.
뭘 먼저 할까?
- Hackers' Pub에 워크스페이스 도입
- Hackers' Pub 모델 코드에 테스트 추가
- 테스트를 용이하게 하기 위해 Fedify에 모킹 객체 지원 추가
Hackers' Pub에도 팀 계정 같은 걸 만들어야 하나 싶은 생각이 가끔 드는데… 이를테면 현재로서는 Hackers' Pub 공식 계정을 깔끔하게 만들 방법이 떠오르지 않는다. 안 쓰는 메일 주소로 새 계정을 파는 식으로 해야 하는데, 별로 그런 식으로 풀고 싶지가 않다.
PostgreSQL에서는 CTE에 INSERT/UPDATE/DELETE도 쓸 수 있구나. 그래서 동시에 2개 이상의 테이블에 삽입한다든가 하는 게 가능. 근데 내가 쓸 일이 있을까…?
https://www.postgresql.org/docs/current/queries-with.html#QUERIES-WITH-MODIFYING
현재의 이른바 “에이전틱” 코딩 어시스턴트들은 종래의 정적 분석 기술을 활용하지 못하는데, 아마도 머지 않은 미래에 둘이 결합될 날이 올 것 같긴 하다. 다시 말해, 애초에 LLM이 컴파일조차 안 되는 코드를 뱉지는 못하게 할 수 있을 거라고 생각한다. 그 때가 되면 정말 평균적인 사람 프로그래머가 이룰 수 있는 품질의 코드를 내놓을 수 있지 않을까? 컴파일도 되고, 겉보기에는 잘 돌아가지만, 몇몇 코너 케이스에서는 여전히 깨지는… 그럼 그때는 또 LLM이 QA도 하고 코드 리뷰도 해서 고치는 미래가…!?
며칠 동안 딴짓 많이 했으니 이제 다시 Hackers' Pub 작업을 해야지…
레코드 및 튜플 제안도 그렇고 어째서 JavaScript는 동등성 연산을 커스텀하게 구현할 수 있게 하지 않고 변죽만 울릴까? Symbol.equality랑 Symbol.hash 같은 거 정해주고 Map이든 Set이든 내부적으로 그거 쓰게 하면 좋을 것 같은데.
이것으로 BotKit 0.2.0에 넣으려고 생각했던 기능은 다 추가했다. 이대로 0.2.0 출시하면 되려나? 뭔가 놓친 게 없으려나? 🤔
“자고 일어나서 마저 해야지!” 하고 자고 일어났는데 어디까지 했고 뭘 해야 하는지 다 까먹었다.
Deno 표준 라이브러리에 parseMediaType()이라는 유용한 함수가 있었구나… 그것도 모르고 맨날 만들어서 썼네.
기분 전환 삼아 어제부터 오랜만에 BotKit 작업을 좀 했는데, 생각보다 빨리 0.2.0 릴리스가 가능할 것 같은 느낌? 추가하려던 기능 세 개 중에 두 개나 벌써 완료되었다.
역시 애플리케이션 만드는 것보다 라이브러리 만드는 게 더 재밌는 것 같다. 다들 이럴까, 내가 유독 그런 걸까?
거의 15년 전에 야심 넘치게 Benjamin C. Pierce의 Types and Programming Languages를 한 권 장만했지만 아직도 아주 깨끗하다. 앞으로도 읽을 일이 없을 것 같다… ㅋㅋㅋ
TypeScript에서 쓰는 브랜디드 타입(branded type) 패턴, 그럭저럭 쓸만하네.
바이브 코딩에 줄곧 Claude Sonnet 3.7만 쓰다가, 오늘 Gemini 2.5 Pro를 써 봤는데, 코딩을 더 잘 하는지는 잘 모르겠지만 응답 속도 하나만은 훨씬 빨라서 좋다. 바이브 코딩을 하다가 결국 답답함을 못 참고 내가 직접 코딩하게 되는 까닭 중 하나가 기다림의 지루함이었는데, 그 부분이 많이 완화된달까?
For my library and CLI projects, I've been writing documentation before writing any code. It helps me imagine the final interface early on, which usually leads to better design. Sure, sometimes I miss implementation details and have to revise later, but hey—it's just docs. Docs are easy to change.
This tiny habit has surprisingly big payoffs. When I focus on how things will be used rather than how they'll be built, I end up with interfaces that actually make sense.
Anyone else do this? Curious about your experience with documentation-first approaches.
RE: https://hollo.social/@hongminhee/01964c76-ef1e-7994-b3f0-57f967742566
갑자기 Hackers' Pub 코딩에 손에 안 잡혀서 다른 코딩이나 좀 해야겠다… 그것도 잘 안 잡히면 코딩 자체가 손에 안 잡히는 걸테니 그냥 놀아야지.
살면서 RTL 언어 지원을 한 번도 해 본 적이 없어서 무섭게 느껴진다. 아마 서양 프로그래머들도 CJK 보면 이런 느낌일까?