블로그 포스트를 Ghost(Pro)를 써서 하고 있는데, 이 서비스가 자체적으로 ActivityPub 서비스를 하나 시작해서, 블로그에 연합우주? 계정이 생겼다.( @index정진명의 굳이 써서 남기는 생각 ) 이 계정에, 트위터 엑소더스 때 만들었던 계정도 하나 어디 있는데(어디있더라…) 어떻게 정리할 수 있을지 모르겠다.
洪 民憙 (Hong Minhee)
@hongminhee@hackers.pub · 410 following · 276 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
Hello world!
洪 民憙 (Hong Minhee) shared the below article:
함수형 프로그래머한테 닉스 패키지 매니저의 derivation 소개하는 글
lionhairdino @lionhairdino@hackers.pub
이 글은 닉스의 핵심 개념인 derivation에 대해 설명합니다. Derivation은 패키지 빌드에 필요한 속성들의 집합으로, 닉스는 이를 통해 의존 관계를 순수하게 표현합니다. 패키지 A가 B에 의존한다면, A의 derivation이 B의 derivation에 의존하는 방식으로 명세서를 작성하고, 실제 패키지가 필요할 때 realize 동작을 통해 이펙트들의 영향을 받습니다. 이러한 선언적인 명세서 덕분에 닉스는 선언형 패키지 매니저라고 불립니다. Derivation 이름에 내용 기반 해시를 붙여 캐싱과 재현성을 높이지만, 작은 변화에도 해시값이 달라져 디스크 용량과 빌드 시간이 늘어나는 단점도 있습니다. Nixpkgs는 derivation 자체가 아닌, derivation을 생성하는 표현식들의 모음으로 구성됩니다.
Read more →할 말 없으니까 그나마 기술적인 내용이 있는 거 갖고오기: React로 게임 프로토타이핑하기
모바일에서 사진 올리기 편하게 바뀌었네.
빨리 팀을 만들어서 일정도 짜고 회고도 하고 회식도 하고 했으면 좋겠다. 그러기위해 어서 MVP를 완성하자.
무슨 생각 해요?
Hackers' Pub 기본 화면이 왜 연합우주일까 궁금해하면서 멍때리는 중
지금 페디버스에 관한 개념 이해는, "아 내 글이 공개되는 이메일 같은 거군"에서 멈춰 있습니다. 삶이 바빠 긴 개념 문서는 못보겠고, 가끔 짧게 떠먹여 주시는 것들로 차츰 채워가야겠습니다.
페디버스 지식이 얼마나 없냐 하면요. 마스토돈에서 글 쓰면, @mastodon.social이 붙고, 해커스펍에 글 쓰면 @hackers.pub이 붙는다는 걸 몰랐습니다. 양 쪽 프로필 그림으로 같은 것 쓰면서, 구별 없이, 무념으로 라이트하게 잘 쓰고 있긴 합니다.
@lionhairdino 말씀하신 접두사들에 덧붙여서, 이른바 "연산자 오버로딩"처럼 두 정의가 하나의 이름에 동시에 붙어 있는 경우 竝(나란히 병)을 쓰는 것도 고려함 직하다는 생각을 해 봤습니다. "병행", "병립", "병치" 등에 쓰이는... "오버레이"의 경우는 疊(겹쳐질 첩)이 먼저 떠오르네요. "중첩"이라든지 "첩첩산중" 등에 쓰이는 그거요.
그리고 꼭 한자어에는 한자 접두사를 붙여야 한다는 법이 있는 것은 아니니, 과감하게 고유어를 쓰는 것도 생각해 볼 수 있겠습니다. "겹정의"라든지, "덮정의"라든지... 아예 "겹뜻"이라든지...
개인적으로 커널-알멩이 번역처럼 한글 낱말에서 전혀 원 뜻이 느껴지지 않는 것들은 읽는데 힘들어 하지만, 겹정의는 충분히 이바닥에 자리 잡아도 되지 않을까 싶을 정도로 원 뜻이 살아 있습니다.
겹정의! 재정의보다 더 원 뜻에 가깝다고 생각이 드네요.
@gagl3 노트북에 붙였을 때 간지가 나는 Hackers' Pub 스티커를 만들고 싶다는 
@kodingwarriorJaeyeol Lee 님의 말씀이 있었습니다… 😂
@hongminhee洪 民憙 (Hong Minhee) @kodingwarriorJaeyeol Lee @gagl3 일본에는 라이브 코딩도 해주고 노트북에 붙일 스티커도 주는 「Hacker's Bar」 가 있는데, 이거 생각나고 재밌네요.
https://hackers.bar/
오버라이딩 을 재정의라 번역하는데, 왜 "(덮을 복)정의"라 안했을까? (물론 나도 어색하다) 재정의는 뭔가 기존 것을 치워버리고, 다시 정의하는 것이고, 오버라이딩은 기존 것을 그대로 두고, 그 위에 레이어를 두는 느낌이라 같은 듯 다르다.
만일 복정의라 번역한다면, 오버로딩을 중(거듭 복) 정의라 하는데, 이 것과 같은 글자를 쓰는 문제가 생길 수 있겠다.
재정의, 중복 정의는 나도 번역이 마음에 들긴 한데, 늘 재정의가 살짝 걸리적 거린다.
닉스 공부하며 노트하다가 비슷한 듯 다른 오버레이, 오버라이딩의 적당한 번역어가 떠오르지 않아 잡생각으로 빠졌다.
널리 알려진 적당한 짧은 번역 단어(보통 한자 한 두 글자)가 없으면, 그냥 원문이 낫지 않을까? 표기만 Overlay가 아니라 오버레이로.
@lionhairdino 말씀하신 접두사들에 덧붙여서, 이른바 "연산자 오버로딩"처럼 두 정의가 하나의 이름에 동시에 붙어 있는 경우 竝(나란히 병)을 쓰는 것도 고려함 직하다는 생각을 해 봤습니다. "병행", "병립", "병치" 등에 쓰이는... "오버레이"의 경우는 疊(겹쳐질 첩)이 먼저 떠오르네요. "중첩"이라든지 "첩첩산중" 등에 쓰이는 그거요.
그리고 꼭 한자어에는 한자 접두사를 붙여야 한다는 법이 있는 것은 아니니, 과감하게 고유어를 쓰는 것도 생각해 볼 수 있겠습니다. "겹정의"라든지, "덮정의"라든지... 아예 "겹뜻"이라든지...
Hackers' Pub 行動規範を拝見し、その根底にあるキーワードは「尊重」と「思いやり」だと強く感じた。だからこそ、僕はHackers' Pubを心から応援している。時間が経っても、その価値観がブレずに、前向きで明るいエネルギーがあふれる場所であってほしい。
それと、もうひとつだけ言うと、開発者のちょっとした日常の話とかも、もっと共有されるといいなって思う。（まずは自分から始めなきゃだけどね）
Hackers' Pub 행동 강령을 관통하는 큰 키워드가, 존중과 배려라고 느꼈고, 그래서 더욱 Hackers' Pub 을 응원하고 있는데, 오랜 시간이 흘러도 추구하는 가치에 흔들림이 없으면 좋겠고, 여기에 더해 긍정적이고 밝은 에너지가 가득한 공간이 되기를 소망한다.
한가지만 더 첨언하자면, 개발자의 소소한 일상 얘기들도 많이 공유되었으면 좋겠다. (우선 나부터도 해야겠지만)
Chrome Built-In AI (EPP)で変更
Canary 136.0.7103.0* 以降、すべての組み込み API に新しいエントリ ポイントがあります。
self.ai.* ではなく、self.* で直接 API を見つけることができるようになりました。静的
create() メソッドを使用して、これらの API をインスタンス化します。
await LanguageModel.create();
await Summarizer.create();
await Writer.create();
await Rewriter.create();
await LanguageDetector.create();
await Translator.create();同様に、静的 availability() メソッドが追加されました。
await LanguageModel.availability();
await Summarizer.availability();
await Writer.availability();
await Rewriter.availability();
await LanguageDetector.availability();
await Translator.availability();가끔 구글 트렌드로 "하스켈" 추이를 봅니다.
지역을 눈여겨 본 적이 없었는데, 지금 보니 "대전"이 1위, "광주"가 2위, 의외로 서울이 3위입니다.
오.. 해커스펍 가입함
인프라… 인프라 어렵군
코드와 한글 [Code and Hangul]
------------------------------
# 전북대학교 이상로 교수의 연구 아카이브: 한글 코드와 기술 표준화의 기록
이상로 교수가 운영했던 웹사이트는 2000년대 초반 한국의 문자 처리 기술과 코드 변환 연구를 체계적으로 정리함으로, 한글 정보화와 국제 표준화 과정에서 중요한 역할을 했습니다. 이 사이트는 당시 컴퓨터 과학 분야의 학문적 연구와…
------------------------------
https://news.hada.io/topic?id=20085&utm_source=googlechat&utm_medium=bot&utm_campaign=3140
일정 추산은 어려운 일이다. TWP(Two-Week Principle)는 모든 시간 참조를 표준화하는 새로운 시간 척도다. 이 제안에 따르면 시간과 관련된 모든 질문에 반사적으로 "2주"라고 응답해야 한다. https://www.rfc-editor.org/rfc/rfc9759
작년에 비하면 조금 약하다 ㅎㅎ 참고로 작년에는...
Faster than LIght speed Protocol(FLIP)은 LLM을 이용해 패킷이 수신 피어에 도착하기 전에 미래의 패킷을 예측함으로써 광속보다 빠른 전송을 달성한다. (...) 이 프로토콜 명세는 AI와 LLM을 사용하기 때문에 멍청한 인간은 이 명세를 리뷰해서는 안 된다고 여겨졌다. 대신 여러 LLM 챗 서비스의 코멘트와 제안으로 개선되어 승인받았다. https://www.rfc-editor.org/rfc/rfc9564
일정 추산은 어려운 일이다. TWP(Two-Week Principle)는 모든 시간 참조를 표준화하는 새로운 시간 척도다. 이 제안에 따르면 시간과 관련된 모든 질문에 반사적으로 "2주"라고 응답해야 한다. https://www.rfc-editor.org/rfc/rfc9759
내년 React Summit Asia는 싱가포르에서 열리는군요! 기회가 된다면 한번 꼭 가 보고 싶네요 🤩
슈티를 그냥 Misskey 클라이언트로 만들어 버릴까...
@parksbSimon Park 헉 어떻게 하셨나요
@kodingwarriorJaeyeol Lee 심플하게 가장 가까운 .vim/config.lua 파일을 찾아서 해당 파일에 명시된 린터와 포매터 정보를 읽도록 만들었어요. 급하게 필요해서 만든거라 엉성해요 ㅎㅎ https://github.com/parksb/dotfiles/commit/ca3bc66b03a9c2ed2dc7388bedc78fe9d62dbb08
@bglbgl gwyng 어라 Cabal이 기본적으로 스냅숏 모드로 동작하나요? Stack만 쓴 지 몇 년 되어서 Cabal이 그랬던가 기억이 가물가물하긴 한데요…
@hongminhee洪 民憙 (Hong Minhee) 음 표현이 좀 잘못된거 같네요. 버전에 constraint들 명시하면 그거 resolve해서 설치하겠죠. 제가 말하려고 했던건 lock이 개별 패키지 별로 안남고 indexed-state로 스냅샷 시간을 명시하는 방식이 마음에 안든가 거였습니다. cabal.freeze 또한 암호해시가 안 남고요.
남들은 바이브 코딩이다, MCP다 하고 있는데 나는 오늘 Neovim에 워크스페이스별 로컬 설정 파일을 적용하는 기능을 구현했다. 근데 어떡하나 이게 재미있는데...
불과 작년까지도, DB설계시에 uuid 를 쓰지 않는 키값은 int 보다 bigint 를 선호했으나, 이제는 로그성 데이터같은 빈번하게 등록되는 데이터가 아닌 이상 int 를 사용한다. bigint 의 사용은 당연히 미래를 위한 결정이었지만, 내가 만드는 서비스들이 웬만해서는 int 를 뛰어넘지 않는다는 것을 깨달았고 (약 20억이면 충분), 언젠가 bigint 로 마이그레이션해야 하는 서비스가 되었으면 좋겠다.
洪 民憙 (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년 동안 "문제의 소지는 컴파일 시간에 검출하는 게 좋다"라는 생각이 더 널리 받아들여져서, 다른 언어들도 이런 접근을 더 시도할 여지가 생긴 것 같군요.
CMake 3.20 즈음에서 add_test동작이 바뀐 것 같은데 generator expression중 conditional expression으로 인자 없음 혹은 정해진 값을 기대하는 코드가 인자 없음 대신 “”로 생성을 해버려서 동작이 완전히 틀려져버렸고, 4.0에서도 유지되고 있다. 어디서 바뀌었는지 릴리즈노트를 조금 봤는데 못 찾았다.
CMake 4.0이 나오면서 3.5미만에 대한 지원을 제거했다고 한다. 그러면서 최소 CMake 버전을 3.4로 지정되어있는 프로젝트는 스크립트를 실행해보지도 않고 실패 취급 해버린다.
퇴근도 했으니 바이오를 써보자...
허걱 대박. 초대한 사람 이제 50명째 찍음
스냅샷 방식이 이론적으로는 참 좋은데, 제대로 돌아가려면 사람들이 새로운 버전을 테스트하고 호환되는 버전을 업데이트하는 등의 잡다구리한 수고를 다 같이 해줘야 한다는 문제가 있(었)다. 하지만 요즘 잡다구리한 수고가 매우 저렴했으니 올바른 방법을 다시 밀고나갈수 있게되었다.
RE: https://hackers.pub/@hongminhee/0195f09a-a7d0-79aa-a819-bdcf97d6d830
플러그인과 미들웨어의 번역어로, '냅다 꽂기'와 '슬그머니 끼워넣기'를 제안합니다. 부정적인 어감은 의도한 바입니다.
그거 아십니까? XCode 업데이트는 거부할수 없고, 수락하면 보통 기존의 React Native 빌드가 터진다는 사실을... 해괴한 cpp 에러 메시지와 함께요
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:
- Update the Spring AI BOM version to 1.0.0-SNAPSHOT
- Ensure all required repositories exist in your build configuration
- Update Spring AI artifact IDs according to the new naming patterns
To use this automation:
- Download the Claude Code CLI tool
- Copy the prompt from the update-to-snapshot.txt file
- Paste the prompt into the Claude Code CLI
- 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.
"pub"의 외래어 표기법에 따른 표기는 "펍"이 아니라 "퍼브"입니다. 유성음으로 끝나는 단어라서 "ㅡ"를 붙입니다. 이것은
- log: "록"이 아니라 "로그"
- blog: "블록"이 아니라 "블로그"
- tag: "택"이 아니라 "태그"
- egg: "엑"이 아니라 "에그"
- dog: "독"이 아니라 "도그"
- mug: "먹"이 아니라 "머그"
- hub: "헙"이 아니라 "허브"
- pad: "팻"이 아니라 "패드"
- lid: "릿"이 아니라 "리드"
- mud: "멋"이 아니라 "머드"
등등, 유성음으로 끝나는 영어 단어에 일관적으로 적용되는 규칙입니다.
보통 외래어 표기법의 규칙이 무시되는 사례를 보면, 규칙이 모호성을 낳는다는 이유로 기피되는 경향이 있는데요. 예를 들어 "seat"와 "sheet"를 구분하려는 욕망으로 인해 /ʃiː/를 "시"로 표기하는 원칙을 깨고 후자를 "쉬트"로 적는 것이 있죠.
그런데 유성음으로 끝나면 "ㅡ"를 붙인다는 규칙은 원어의 유성 음가를 반영하는 동시에, 대체로 모호성을 해소하는 방향으로 표기를 만들어 주는 좋은 규칙입니다. 이 규칙이 없었으면 꼼짝없이
- "dog"와 "dock"이 "독"이라는 동음이의어가 되고
- "pig"와 "pick"도 "픽"이라는 동음이의어가 되고
- "rug"와 "luck"도 "럭"이라는 동음이의어가 되고
- "tag"와 "tack"도 "택"이라는 동음이의어가 되고
영 좋지 않았겠죠.
洪 民憙 (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 →TIL that apollo-rs supports GraphQL schema execution for introspection queries. Very interesting, but why only for introspection? 🥲
큰일이다. 해커스펍에서만 글 장문+단문 1000개 찍겠다
해커스 펍이 (이상할 정도로) 확장하는 힘이 느껴집니다. 어디서 오는 에너지일까요?!
@lionhairdino 저의 영업력 + 물 들어올때 빠른 속도로 노젓는 홍민희님의 피지컬! (아님)
해커스 펍이 (이상할 정도로) 확장하는 힘이 느껴집니다. 어디서 오는 에너지일까요?!
난 요거 반대의 도구를 찾고 있는데, remote로 electron이나 tauri등을 띄운다음에 웹뷰를 브라우저로 볼수있게하는 것이다. 안그래도 지금 GitButler 깔았는데 remote 사용을 지원안해서 난감해졌다.
오버라이딩 을 재정의라 번역하는데, 왜 "(덮을 복)정의"라 안했을까? (물론 나도 어색하다) 재정의는 뭔가 기존 것을 치워버리고, 다시 정의하는 것이고, 오버라이딩은 기존 것을 그대로 두고, 그 위에 레이어를 두는 느낌이라 같은 듯 다르다.
만일 복정의라 번역한다면, 오버로딩을 중(거듭 복) 정의라 하는데, 이 것과 같은 글자를 쓰는 문제가 생길 수 있겠다.
재정의, 중복 정의는 나도 번역이 마음에 들긴 한데, 늘 재정의가 살짝 걸리적 거린다.
닉스 공부하며 노트하다가 비슷한 듯 다른 오버레이, 오버라이딩의 적당한 번역어가 떠오르지 않아 잡생각으로 빠졌다.
널리 알려진 적당한 짧은 번역 단어(보통 한자 한 두 글자)가 없으면, 그냥 원문이 낫지 않을까? 표기만 Overlay가 아니라 오버레이로.
@lionhairdino 【覆】를 “덮다”라는 새김으로 쓸 때는 【복】이 아니라 【부】라고 읽어야 합니다. 그러니까 【覆定義】(부정의) 정도가 되겠네요.
실제로 중화권에서는 【覆寫】(부사)라는 번역어를 쓰고 있네요.
오버라이딩 을 재정의라 번역하는데, 왜 "(덮을 복)정의"라 안했을까? (물론 나도 어색하다) 재정의는 뭔가 기존 것을 치워버리고, 다시 정의하는 것이고, 오버라이딩은 기존 것을 그대로 두고, 그 위에 레이어를 두는 느낌이라 같은 듯 다르다.
만일 복정의라 번역한다면, 오버로딩을 중(거듭 복) 정의라 하는데, 이 것과 같은 글자를 쓰는 문제가 생길 수 있겠다.
재정의, 중복 정의는 나도 번역이 마음에 들긴 한데, 늘 재정의가 살짝 걸리적 거린다.
닉스 공부하며 노트하다가 비슷한 듯 다른 오버레이, 오버라이딩의 적당한 번역어가 떠오르지 않아 잡생각으로 빠졌다.
널리 알려진 적당한 짧은 번역 단어(보통 한자 한 두 글자)가 없으면, 그냥 원문이 낫지 않을까? 표기만 Overlay가 아니라 오버레이로.
Hackers' Pub 에서 좋아요 느낌을 표현하고 싶을 때
- 공유 혹은 댓글을 다는 방법이 있겠고
- 그냥 지나치기는 아쉬워서
- (우선은) 공유를 하고 있기는 한데,
잘하고 있는건가 싶은 생각이 들 때도 있다.
개인적으로 공유는 팔로워들에게 공유하고 싶을 때 쓰고 싶은 기능인데… 최근에 다소 남발하게 된다.[1]
서로 멘션 주고 받다가, 답글 마지막에 좋아요 하트 느낌으로 마무리 짓고 싶은 마음 뿜뿜할 때에도, 그냥 아무말 안하고 마무리 하기도 하고. (이모티콘 댓글 정도를 남긴다거나 하는 방법은 있음)
@hongminhee洪 民憙 (Hong Minhee) 님이 이모티콘 좋아요 기능을 고민중이라 하시니, 그때까지는 좀 더 공유 기능을 남발해 보는 걸로. 😂
결론 : 이 글은 무차별 공유에 대한 자기 합리화를 위한 글이었던 것입니다. 😅
좋아요 느낌의 표현으로도 병행해서 사용하고 있으므로 ↩︎
어디 이벤트할때 쫄래쫄래 찾아가서 구글 폼으로 이메일 쓱쓱 받아가지고 초대장 보내는 것도 괜찮을듯
Vim/Neovim의 시대가 가고, Vibe Coding 내지는 LLM 에이전트의 도움을 얻는 시대가 왔다지만, 난 아직까지는 전적으로 동의하지는 않음(부분적으로는 동의한다는 의미) 아직까지는 수제로 직접 코드를 짜는 것도 의미가 있고, CLI 기반의 에디터도 저마다의 발전을 하고 있다고 자신있게 말할 수 있음.
내가 생각하는 요오즘 시대 개발의 장점도 언급하면서 CLI 기반의 에디터는 어떤 위치에 있는지도 얘기해보고자 한다.
-
신뢰구간이 넓지 않아도 되는 작업을 할때는 AI를 사용하는 코드가 분명 시간을 확 줄여주고 결과적으로 생산성을 향상시키는 경향은 있지만, "정확함"을 위해서 프롬프트를 넣어야 하는데 그 프롬프트를 넣는 작업이 품이 많이 들때(넣어야 하는 맥락이 너무 많을때) 그렇게 정확하지는 않을뿐더러 맥락을 넣는 시간 때문에 차라리 내가 직접 짜는게 나을때가 많음. 수제로 직접 짜기 vs AI한테 전적으로 맡겨버리기 두 세계를 적절하게 오가면서 작업하는게 베스트이지 않나 싶음.
-
GUI 에디터 특유의 장점도 분명 있긴 있다. GUI 에디터가 올인원 기능을 갖추고 있는 경우도 많고 편의성 면에서 미니멀리즘을 추구하는 CLI 기반의 에디터보다 가진 기능이 많다. 남이 차려준 밥상이 그렇게 달달하지 않을 수 없다. 하지만, 그런 기능들을 제공하는 플러그인이나 자체 기능들의 내부 구현을 막상 까보면 CLI 도구에 의존하는 기능들이 많다. 특히, LSP/린터/포매터가 그렇다. 다만 추상화레이어를 어떻게 감쌌느냐 정도의 차이가 있는데, 그 추상화레이어를 커스터마이징하는데 있어서의 진입장벽은 CLI 기반의 에디터가 상대적으로 낮은 편이다. 왜냐면, 인고의 시간을 거쳐서 해온게 딱 그거라서(.....)
-
바이브 코딩은 분명 압도적인 속도로 코드가 짜여질 수 있게 하고, 단위시간당 코드가 짜여지는 양 자체도 어마어마하다. 특히, scaffolding을 할때 더더욱 빛을 발휘한다. 그렇기 때문에, 코드를 짜는건 기계/인공지능에 위임하고, 자세한 디테일을 채우는건 유저리서치를 하거나 와이어프레임을 그려서 기획을 더 보강하는 등 중요한 영역에 집중할 수 있게 된다. 코드를 짜는데 드는 시간은 최소한으로, 중요한 영역에 집중하기 위해 생각하는 시간을 더 많이 가지는 것은 분명 좋은 일이다. 관련해서는 이 글도 읽어보면 좋을 것 같다. https://two-wrongs.com/typing-fast-is-about-latency-not-throughput
물론, 코드를 짜는데 있어서 중요한 것은 리터러시이다. LLM이 코드베이스의 이해를 빠르게 할 수 있도록 도와주긴 하지만, 위에서 언급했듯 어느 정도 시점이 되면 결국엔 직접 짜고 직접 수정하는 일도 있어야 한다. 로컬 LLM이 발전한다 하더라도, LLM을 사용할 여력이 되지 않는 환경에서도 동일한 생산성을 유지할 수 있을까? 생산성이 일관적이지 않다면, 그렇지 않은 환경에 노출이 되었을때 어떻게 대응할 수 있을지가 중요한 포인트일 수 있다고 생각한다. 인자강, 즉, 사람 자체가 강해질 필요가 있다고 생각한다.
인공지능에 전적으로 의존하지 않고 수제로 직접 코드를 짜는 사람들이 기계/인공지능에 저항해서 어떻게 살아남을까를 생각해보면 인간공학에 기반해서 편집하는 테크닉이 더 연구될 필요가 있다.
GUI 기반의 에디터가 날이 갈수록 좋아지고 있는 상황 속에서 CLI 기반의 에디터가 살아남으려면 더더욱 CLI 기반의 도구와 궁합이 좋은 것을 내세워서 차별점을 내세울 필요가 있다. Neovim은 그런 관점에서 IDE와 유사한 경험을 제공하는 쪽으로 잘 발전되어 왔다고 보고 있다.
Vim/Neovim 생태계는 아직까지는 미래가 낙관적이라고 본다.
@kodingwarriorJaeyeol Lee 저는 VS Code를 오래 써서, Cursor든 Windsurf든 VS Code 포크들은 아무 비용없이 갈아탈수 있었는데요. 사실 저런 툴들의 진짜 강점은 API 요금제인거 같습니다. Claude Code 붙여서 종량제로 쓰면 그게 제일 퍼포먼스 좋겠지만 돈이 계속 나간다는게 상당한 압박인데, Windsurf 한달에 15달러 내면 그냥 채팅용으로도 쓸수있고, 개발자 입장에서 단 한개의 AI 구독이 되는게 가능해요. 그러니까 에디터 자체는 별로 안중요하고 그 뒤에 묶여있는 AI 상품이 매력적인 거죠.
Aider같은 걸로 비슷한 요금제를 구현하는게 가능할지 모르겠네요. 또는 로컬 LLM 성능이 궤도에 오르면 그때 또 많이 달라질거라 봅니다.
洪 民憙 (Hong Minhee) shared the below article:
hoonie-blog v1.1.1 등장!
레니 @renegade_v00@hackers.pub
개선된 기술 블로그 1.1.1 버전이 공개되었습니다. 이번 업데이트에서는 사용자 경험을 향상시키기 위한 다양한 개선 사항들이 적용되었습니다. 특히, 사이트 성능 최적화를 통해 로딩 속도를 개선하고, 반응형 디자인을 강화하여 다양한 기기에서 일관된 사용자 인터페이스를 제공합니다. 또한, 새로운 기능들을 추가하여 블로그 탐색 및 콘텐츠 접근성을 높였습니다. 이번 업데이트는 마치 게임 패치노트처럼 작성되어, 개발 과정과 변경 사항을 더욱 재미있게 확인할 수 있습니다. 블로그를 방문하여 새로운 기능들을 직접 경험하고, 개선된 사용성을 느껴보세요.
Read more →