벌려둔 일이 너무 많아서 뭐부터 해야 할 지 정하질 못한 채 우왕좌왕하는 일이 많다.
bgl gwyng
@bgl@hackers.pub · 92 following · 116 followers
GitHub- @bglgwyng
@hongminhee洪 民憙 (Hong Minhee) 우왕좌왕의 결과물의 fedify, logtape, upyo, optique인거군요. 앞으로도 쭉 우왕좌왕하시면 될듯 합니다.
이거 아무리 봐도 옛날에 본 심리검사 문항 같다. 이런 느낌으로
제 GitHub 프로젝트 중 별 400개를 받은 프로젝트가 나왔습니다!
여기까지 오는데 정말 많은 격려와 응원해주셔서 감사합니다. ㅠㅠ
IQ 테스트로 인간을 판별하고 구분짓는것에는 불편한 느낌이 들지만(그게 쓸모없단 얘긴 아님), 그와중에 우리집 강아지 견종인 요크셔테리어가 똑똑한 견종으로 분류되는 글을 보면 진심으로 뿌듯하다...
https://github.com/bglgwyng/nix-x-cabal
한달간의 삽질끝에 Nix + Haskell 빌드 프레임워크를 완성했다. 늘 Nix, Haskell에 기여하고 싶었지만, 솔직히 이걸 내가 직접해야하는 상황이 올줄은 몰랐네. Nix 디버깅하느라 정말 개고통이었다..
bgl gwyng shared the below article:
공허한 참
박준규 @curry@hackers.pub
하스켈의 `all` 함수에 빈 리스트를 넣었을 때 왜 `True`가 반환되는지에 대한 의문을 "공허한 참(Vacuous truth)"이라는 개념을 통해 탐구합니다. 흔히 '구현이 그렇게 되어 있으니까'라고 생각할 수 있지만, 저자는 이 현상을 논리적으로 분석합니다. `all` 함수의 구현 방식과, 빈 리스트에 대한 연산 결과가 전체 결과에 미치는 영향을 설명하며, 공집합의 모든 원소가 짝수라는 명제가 참인 이유와 유사한 논리적 근거를 제시합니다. 이를 통해 코드와 수학 간의 연결고리를 발견하고, 마지막으로 ChatGPT가 생성한 유머러스한 이미지를 곁들여 독자에게 즐거움을 선사합니다.
Read more →역시 마니악한 주제로 라이트닝 토크하는 행사를 추가로 만들어야겠다
@z9mb1wwj 
@catamorphicCata 
@d01c2Hyunjoon Kim 
@icecream_mable구슬아이스크림 
@minju2996bbang 
@lionhairdino 
@akastoot악하 
@jihyeokJihyeok Seo 
@linea 
@woaol벨 
@theeluwin제이미 
@ranghoRangHo Lee 
@nebuletoHaze 
@jcha0713joohoon 
@hyunjoon 
@krepe90남기현 (Krepe) 
@cetaceanightskyCetacea 
@aiooAhn Kiwook 
@ink_punctuation책 읽는 프로그래머 
@yg1ee밀
오늘 Hackers' Public 행사 첫번째 모임에 와주셔서 정말 감사합니다! 정말 즐거웠습니다! 잘 들어가세요!
https://referral.akaiaoon.dev/
github referral 사이드 플젝을 드디어 외부공개했읍니다... 적당히 추천하시고, 본인이 받은 추천사는 https://referral.akaiaoon.dev/api/recommendations/:github_id 로 URL 링크를 거시면 대충 svg가 말려옵니다. 깃허브 프로필에도 마크다운으로 링크 가능합니다.
예:
아직 임시라 수정 요청 혹은 피드백은 환영합니다.
@akastoot악하 프사가 깨져서 안나옵니다
리액트 기본 파비콘 쓰는 페이지 어떤데
https://referral.akaiaoon.dev/
github referral 사이드 플젝을 드디어 외부공개했읍니다... 적당히 추천하시고, 본인이 받은 추천사는 https://referral.akaiaoon.dev/api/recommendations/:github_id 로 URL 링크를 거시면 대충 svg가 말려옵니다. 깃허브 프로필에도 마크다운으로 링크 가능합니다.
예:
아직 임시라 수정 요청 혹은 피드백은 환영합니다.
I wrote a post on my blog after a long time: Recent open source development updates.
오랜만에 블로그에 글을 썼습니다: 〈오픈 소스 開發 近況〉.
몇년전에 모 기업 공채를 지원했는데. 마지막 인적성 면접만 남긴 상태에서 간접적으로 그때까지의 점수를 짐작할 방법이 있었는데, 정말 99% 합격했다고 생각했다. 결국 인적성 면접보고 떨어졌는데 거기서 정말 점수를 엄청나게 까먹었단 얘기다. 근데 지금도 이유가 뭔지 모르겠다. 진짜 모든 질문에 무난~한 대답만 했는데 말이지... 그거 떨어지고 다른 회사 갔는데 거기서 커리어도 꽤 꼬여서, 종종 다시 생각하면 아쉬워진다.
부연설명을 하자면. Git에선 브랜치 자체로는 '변경 사항'이라는 의미가 없습니다. 왜냐면 끝점만 있고 시작점만 있으니까요. 변경 사항을 논하려면 비교 대상인 커밋이 필요합니다.
Rebase를 하는 이유는 연속된 커밋들로(예쁩니다) '변경 사항'을 나타내기 위해서입니다. 그 의도한 '변경 사항'을 만들기 위해, 비교 대상이 될 커밋을 바꾸는게 리베이스입니다. 그러니까 개발자가 의도한 diff를 그대로 표현하지 못해서, diff = head - x니까 이 방정식을 만족시키는 x 커밋을 찾아서 diff를 의도한데로 계산되게 만드는거지요.
참 뻘스럽습니다.
Git 떡밥이 지나갔군요. 리베이스가 왜 필요할까요? Git 브랜치에 시작점의 개념이 없기 때문입니다. 브랜치는 커밋 ref가 아니라 (시작 커밋 ref, 끝 커밋 ref)가 되어야 합니다.
Go로 JSON 패키지 만들고 이름을 고조선(go-joseon)이라고 지으면 어떨까란 생각이 들었음
포항공대 > 카이스트인 이유
포스텍은 '포스'가 있지만,
카이스트는 '텍'도 없기 때문,,,,
친구 회사에서 react-form-mozard의 잠깐 언급되었는데, Generator 기반인게 문제가 되어 도입이 바로 기각되었다. yield*가 async, await, try, catch 등등과 달리 혐오스러운 외양을 갖고 있는게 문제가 되었다. 여러분 제발 키워드 차별을 멈춰주세요ㅠㅠ
bgl gwyng shared the below article:
LogTape 1.1.0: Smarter buffering, seamless integration
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
LogTape 1.1.0 introduces smarter and more flexible logging with two major features. The first is "fingers crossed" logging, which buffers debug and low-level logs in memory and only outputs them when an error occurs, providing a complete sequence of events leading up to the problem. Category isolation prevents one component's errors from flushing unrelated logs, keeping logs focused and relevant. The second feature is direct log emission via the `Logger.emit()` method, which allows feeding logs from external systems like Kafka directly into LogTape while preserving original timestamps and metadata. This release also includes bug fixes and improvements across the ecosystem, such as fixes for potential data loss during high-volume logging and improved cross-runtime compatibility. Upgrading to 1.1.0 is backward-compatible and enhances debugging in production by providing complete context for every error without constant verbose logging.
Read more →@bglbgl gwyng ctags로 어떻게 되지 않을까요?
@curry박준규 ctags는 일종의 구현이고, 제가 찾는건 프로그래밍 언어 자체의 요소에 가까운거 같습니다.
소스코드 사이의 안정적인 하이퍼링크를 만들수 있는 기능이 없다. 가령 A.hs에서 주석을 쓰면서 B.hs의 foo란 함수의 구현의 특정 부분을 언급하고자 할때, 그냥 B.hs L:77 이렇게, 소스코드가 수정이라도 되면 바로 유효하지 않게되는 방식으로 언급할수 밖에 없다. 만약 소스 코드 어디에서든 전역적인 심볼을 자유롭게 선언할 수 있다면 이 문제를 해결할 수 있을텐데...
@bglbgl gwyng 단순히 링크 용도로만 남겨두는 게 아니라 실행 흐름을 점프시키는 용도로도 활용하면 더 좋겠군요!
키워드는 jmp 아니면 goto로 하면 좋을 것 같습니다.
리액티브 주석 시스템이라 이름 붙이며 될 것 같은데, 잠깐 검색으론 아직 그런 시도가 검색이 안되네요. 좋은 아이디어인데요. @bglbgl gwyng
@lionhairdino 자유롭게 전역적으로 unique한 심볼을 만들고(쉬움), 또 그걸 참조할 좋은 방법을 만드는게(잘 모르겠음) 필요하단 생각을 많이 합니다.
소스코드 사이의 안정적인 하이퍼링크를 만들수 있는 기능이 없다. 가령 A.hs에서 주석을 쓰면서 B.hs의 foo란 함수의 구현의 특정 부분을 언급하고자 할때, 그냥 B.hs L:77 이렇게, 소스코드가 수정이라도 되면 바로 유효하지 않게되는 방식으로 언급할수 밖에 없다. 만약 소스 코드 어디에서든 전역적인 심볼을 자유롭게 선언할 수 있다면 이 문제를 해결할 수 있을텐데...
@kodingwarriorJaeyeol Lee (a.k.a. kodingwarrior) 
@hongminhee洪 民憙 (Hong Minhee) ㅋㅋ아닙니다. 솔직히 제 취향이라 재밌네요..
@hongminhee洪 民憙 (Hong Minhee) 뮤트 기능 로드맵에 있나요?
Deno 2.5 is out —
⭐ Permission sets in config
⭐ Setup and teardown APIs to Deno.test
⭐ HTML entrypoint support in deno bundle
⭐ Runtime API for deno bundle
bgl gwyng shared the below article:
헬: 하스켈 방언 기반의 셸 스크립팅 언어
박준규 @curry@hackers.pub
Chris Done이 개인적인 셸 스크립팅 용도로 만든 하스켈 방언 기반의 셸 스크립팅 언어인 헬(Hell)을 소개합니다. 저자는 bash의 난해한 문법과 서브 프로세스 의존성 등의 단점을 극복하고자 헬을 개발하게 되었습니다. 헬은 모듈, 패키지 시스템, 추상화 기능 없이 매우 기본적인 기능만을 제공하며, 하스켈의 장점(탄탄한 개념, 동시성, 가비지 컬렉션, 정적 타입 등)을 활용합니다. 헬은 기존 하스켈의 직관을 재사용하고, 안정성과 단순성을 추구하여 자동화 스크립팅에 적합하도록 설계되었습니다. 헬은 냉정하게 완결된 소프트웨어를 지향하며, 스크립팅의 한계를 명확히 정의하여 불필요한 기능 확장을 방지합니다. 릴리스 페이지에서 정적 링크된 리눅스 바이너리를 다운로드할 수 있으며, 구현에 대한 자세한 내용은 소개 슬라이드를 참고할 수 있습니다.
Read more →〈타입 검사는 해결책이 아니라 증상이다〉(Type Checking is a Symptom, Not a Solution).
난 이 글에 동의하지 않는데, 여러 측면에서 그렇지만, 한 측면에만 집중해서 얘기해 보자면: 좋은 아키텍처는 훌륭한 프로그래머를 요구하지만 타입 시스템은 훌륭한 프로그래머를 요구하지 않기 때문이다.
누구나 훌륭한 프로그래머가 되어야만 하는가? 혹은 될 수 있는가? 좋은 아키텍처를 그릴 수 있는 훌륭한 프로그래머가 아니라면 소프트웨어 개발을 해서는 안 될까? 좋은 아키텍처에만 의존하는 것은 잠재적으로 엘리트주의를 끌어들이기 쉽다: 「어떤 시스템이 오작동하는 것은 아키텍처가 나쁘기 때문이다. 아키텍처가 나쁜 이유는 그걸 설계한 프로그래머가 수준 미달이기 때문이다」와 같이.
반면 타입 시스템은 일단 도입만 하면 누구나 그 덕을 볼 수 있다. 팀 내의 프로그래머들의 역량이 뛰어나든 뛰어나지 않든. 훨씬 평범한 보통 사람에게 유리하다. 타입 시스템이 미봉책일 수는 있지만, 그 미봉책이 더 많은 사람들을 프로젝트에 참여할 수 있게 해준다고 생각한다.
@hongminhee洪 民憙 (Hong Minhee) 글의 전체적인 논지가 일관되지 않은거 같습니다. '시간을 일급 개념으로 하자'는건 정말 200% 공감하는 얘긴데, 이건 또 그런 타입시스템을 만들잔 얘기란 말이죠. 응? 제 짐작으론, 저자는 타입 시스템 자체를 반대한다기 보다는, 현재 타입 시스템이 고도화 되는 방향인 더 강력한 추상화보다는, 물리 세계에서의 동작을 잘 묘사하는 쪽이 더 중요하다고 하는거 같습니다. 근데 제목에서 어그로를 살짝 끌어보려다가 글 전체가 좀 중구난방이 된 느낌입니다.
지금 리눅스 진영에서 컨테이너/네임스페이스의 입지가 어떻게 될까요? 사실 요즘 서비스 배포할때는 죄다 컨테이너 쓰잖아요? 근데 또 컨테이너로 할수 있는 것중 상당수는 그냥 기존 권한 관리로도 가능하단 말이죠? 근데 컨테이너를 쓸땐 기존 권한 관리를 그냥 없는셈 치고 접근하게 되는데 이게 정말로 다들 동의하는 방식인지가 궁금합니다.
'둠'의 개발자 존 카멕이 '게임의 스토리는 포르노 영화의 스토리와 똑같다. 있어야 하긴 하지만, 딱히 중요하진 않다고'라고 말한적이 있다. 뭐 곧이 곧대로 이해해도 괜찮은데 약간 재밌게 해석하는 방법이 있는데.
종종 스토리가 훌륭하다고 언급되는 게임들이 있다. 나한텐 그런 게임으로 하프라이프2가 처음이었는데, 실제로 해보면 흥미진진하고 몰입감이 상당하긴 하다. 근데 막상 엔딩을 보고 무슨 내용이었지, 하고 돌이켜보면 전체 플레이타임(한 40시간?)에 비해 그렇게 플롯이 밀도있지 않다는걸 깨닫게 된다.
- 죽기 싫으면 A로 가세요
- A로 가려면 무슨 아이템이 필요해서 B를 먼저 가야하네요?
- B로 갔더니, 여기가 아닌가벼~ C로 가야겠군요
- 이러쿵저러쿵하다가 결국 A에 도착
이런게 대부분이라, 의미있는 내용만 추리면 전체 게임의 스토리가 아마 세줄 요약도 가능할 것이다. 사실 하프라이프만 이런게 아니라, 대부분의 스토리가 훌륭하다는 게임이 까보면 이런식이다. 잉, 그럼 스토리가 좋다는 얘긴 다 허상이었나?
자, 근데 포르노 영화의 스토리가 어땠더라? 움베르토 에코가 어떤 영화가 멀쩡한 영화인지 포르노 영화인지 구분하는 방법을 알려주는 가벼운 에세이를 쓴 적이 있다. 여기서 포르노 영화라 함은, 21세기에 인터넷에서 볼수 있는 '야동'보단, 옛날에 영화관에서 상영되던, 꼴에 1시간이 넘는 상영시간을 가지는 포르노 '영화'를 뜻한다.
아무튼 그 방법이 뭐냐면. 가령, 남녀 주인공들이 만나서 택시를 타고 집으로 간다. 이때 집으로 가는 동안의 시간을 아무 편집없이 그대로 보여주면 그게 포르노다. 멀쩡한 영화는 당연히 쓸데없는 장면은 바로 끊고, 집에 도착해서 거사를 치르고, 그리고 다시 다음 내용으로 이어질 것이다. 하지만, 지금 당신이 보고 있는게 포르노 영화라면! 택시 타고 가는 아무 의미없는 장면을 10분간 본다음, 그 다음에야 원래 보려고 했던걸 보게 된다.
도대체 왜 10분 동안 택시 타는걸 보여줄까? 움베르토 에코의 대답은, 만약 그 쓸데없는 장면이 없이 주인공들이 바로 물고빨기 시작해버리면, 관객들이 그걸 못 버틸거란 것이다. 아무리 그걸 보려고 온 관객들이라지만, 너무... 바로 그래버리면 쪼끔 부담스럽고 그렇다. 그래서 완충제 역할을 할, 택시에서의 10분이 필요하다. 21세기의 포르노는 고전 포르노 영화에 비해 완충제 구간이 많이 짧아지긴 했지만, 그래도 여전히 흔적은 남아있다.
다시 게임으로 돌아와서. 눈치챘겠지만, 게임에서의 전투(나 아무튼 핵심 플레이)가 포르노의 섹스씬에 대응된다. 그럼 게임에서의 스토리는, 포르노 영화에서 남녀 주인공이 택시를 타고 가는, 플레이어의 정서적 안정감을 위해서가 아니라면 굳이 필요없는 그런 역할을 한다는 얘기가 된다. 게임의 즐거움은 총칼로 맘에 안드는 놈들을 한 3,000명 쯤 조지는데 있는데, 그게 아무리 즐거운 활동이라지만 브레이크가 전혀 없이 스트레이트로 3,000명을 해치우는것은 정서적으로 만만치않은 일이다. 그래서 100명씩, 30번씩 나눠서 죽일 방법이 필요하고, 그 사이를 매꿔주는것이 것이 하프라이프2에서의 '여기가 아닌가벼~'란 결론이다.
존 카멕 님아, 이런 의도로 말씀하신거 맞죠?
컴파일러 책 얇은 거 하나 읽고 있는데 문맥자유문법(CFG)이 나와서 오랜만이야 친구 하면서 보는 중...언어학 덕질했던 사람으로선 이걸 보니 하나 떠오르는 게 하나 있는데, 1957년 Syntactic Structures에서 촘스키는 이 CFG를 갖고 닝겐의 자연어가 지니는 통사적 성질(의미 아님)을 마르코프 과정을 통해서 설명하기엔 한계가 있음을 지적하며 변형문법(Transformational Grammar)를 제안한 게 생각난다. 즉, 닝겐 자연어의 통사 정보를 설명할 문법을 제안한 것(다시 한 번 말하지만 의미가 아님). 물론 이후엔 훨씬 더 발전하고 추상화됐고, PCFG라 하여 CFG에 확률을 넣은 CFG 확장판도 있다[1]. 참고로 오토마타 이론에서 나오는 촘스키-슈첸버거 위계나 촘스키 정규형할 때 얘기하는 그 촘스키 맞다.
개인적으로 촘스키의 저 시절 연구들이 되게 재밌다고 생각하는데 (물론 훑어만 봤지만...) 이후엔 사실상 오토마타 이론쪽으론 손 뗀 것 같아서 좀 아쉽기도 함...여튼 컴파일러 책 보다가 갑자기 생각나서 씀. 그나저나 도대체 난 언제 쯔음 나만의 프로그래밍 언어를 만들 수 있을까?
정규언어에서 은닉 마르코프 모형으로 확장시키는 거랑 똑같다. ↩︎
이미 지원할 곳들을 조금 선정하긴 했지만, 여전히 프론트엔드 개발자로 일할 수 있는 곳들을 찾고 있습니다. 기존에 고장나있었던 cv를 조금 고쳐놨습니다 (원래 read cv 산이었던 것을 백업받아 홈페이지에 합체...)
비동기 프로그래밍:
async,Promise, ...: X- AI 에이전트 갈구고 딴짓하기: O
안녕하세요, 백엔드 경력직 프로그래머 뽑고 있습니다. 로그를 모니터링하고 저장하는 시스템을 개발하는 포지션입니다. 기존 오픈소스 솔루션을 사용하긴 하지만 단순히 구축하고 운영하는 것은 아닙니다. 운영도 하지만 개발이 주된 업무 입니다. (오픈소스 솔루션 운영 포지션으로 착각하고 지원하시는 분들이 계셔서 사족을 넣었습니다) https://careers.linecorp.com/ko/jobs/2845/
요즘 #cosmoslide (https://github.com/cosmoslide/cosmoslide) 개발하면서 들고 있는 생각....
대부분의 액티비티펍 소프트웨어 인스턴스는 멀쩡하게 365일 24시간 동일한 위치에서 운영이 되고 있다고 가정이 된다. 내가 글을 올리면, 나를 팔로우 중인 모든 사람들의 inbox에 내가 글을 올렸다(Create(Note))는 Activity가 전달이 되는데, 각자가 운영되고 있는 서버 인스턴스가 멀쩡히 살아있다면.... 딱히 문제가 되지는 않는다.
문제는, 게시글을 작성하는 시점에 팔로워 중 누군가의 인스턴스가 죽어있을때도 있다는 점이다. 그런 경우를 대비해서 exponential backoff를 쓰든 아무튼 fallback 알고리즘이 동작하긴 하는데, 서버가 살아나면 당연히 전달이야 잘 되긴 한다. 그런데, Activity 전달이 실패하는 일이 잦으면 어떤 액티비티펍 소프트웨어를 쓰던간에 retry를 하기 위해서 계속해서 Queue에 쌓이고, 최종적으로는 Queue에 쌓인 것 때문에 적지 않은 오버헤드가 있을 것 같은데 모더레이터의 입장에선 어느 정도까지 감안할 수 있는가? 라는 생각이 문득 들었다.
사실 내가 왜 이런 글을 쓰고 있냐면, 위에서도 언급했다시피, 로컬호스트에서 실제로 서비스를 (맥북이 켜져있을때만) 서빙하고 있고 그걸 Tailscale로 연결해서 터널링을 하고 있다. 즉, 맥북을 켜놓고 있으면 Create(Note) Activity가 정상적으로 잘 전달되고, 맥북이 꺼져있으면 Activity 전달이 안되고 있다. 실제로, 이런 맥락에서 지금 테스트 중인 두 개의 인스턴스가 있다. 이런 실험적인 시도를 하면서 이래도 되는게 맞나 싶은 생각도 들고는 있다. 맥북을 켜놓으면, retry되고 있는 것도 다 consume되긴 하겠지만.... 찝찝하긴 찝찝하다.
개발하는 입장이라고 선해를 할 수는 있어도, 비뚤어진 관점에서 해석하면 누군가는 어뷰징의 관점으로 해석할 수 있는 가능성이 적지는 않다고 생각하고 있다. 이런 경우엔 모더레이터되는 분들한테, 내가 이런 tailscale 도메인으로 서빙하고 있다고 통지라도 하는게 나으려나... 아니면, 내가 구매해놓은 도메인을 tailscale 도메인으로 CNAME 걸어놓고 "이런 도메인으로 서비스 걸어놓을 예정이니까 이 도메인만은 제발 차단하지 말아주십쇼 헤헤" 라고 해야하나... 아예 서버를 만드는거다보니까 이런 고려사항이 생기는 것 같다.
근데, 한 편으로는 이런 생각이 든다. 물리적인 서버의 위치를 옮길 가능성이 많은 환경(예를 들면, 전시 상황)이면 어떡하지? ActivityPub이 사실은 분산된 웹 환경을 위해 나온 프로토콜이긴 하지만, 분산된 웹 환경이라는게 물리적으로 각자 다른 위치에 오랫동안 배치가 되어 있는 서버 뿐만이 아니라 위치가 자주 바뀔 수 있는 서버도 연합의 대상으로 포함이 될 수 있다면? 어떤 공상과학 영화(ex. 터미네이터4)들을 보면, 저항군이 독자적인 라디오 기지국 같은거 만들고 위치도 매번 다른 곳으로 옮기고 주파수를 매번 다르게 설정하면서 소식전달하는 모습을 볼 수 있는데, 액티비티펍도 어떻게 보면 그걸 고려한 설계도 포함될 수 있지 않나... 그런 생각도 든다..
주로 사용하는 형상관리도구인 퍼포스 CLI에 이런 기능이 있어 삽질을 크게 줄이고 있어요. p4 set 해보면 각각의 설정이 기본값인지 로컬 설정파일인지 서버측 설정인지 의도적으로 설정하지 않은 건지 표시해줍니다.
https://hackers.pub/@bgl/01992444-6229-7509-b23a-aed615f96d23
난 어떤 CLI 툴들이 자기가 실제로 쓰고있는 설정값(기본값이거나, 환경변수에서 왔거나, 파일에서 왔거나)를 읽는 명령어를 필수적으로 포함했으면 좋겠다. 사실 법제화까지 하고싶다..
커뮤니티에서 정치적 발언을 하는 것을 금지하는 것의 문제는, 정치적인(또는 그렇게 들린다고 다른사람들이 주장하는) 발언으로 문제가 생겼을때(안 생길수가 없다) 발언의 옳고그름을 떠나, 발언이 정치적인지 아닌지를 따지는쪽으로 흘러가기 때문이라고 생각한다.
아 물론, 대놓고 정치적 발언을 많이 해서 커뮤니티 구성원들을 피곤하게 하는건 좀 다른 문제고, 그걸 피하기 위해 정치적 발언을 금지하는 강령이 있는것일 테다. 근데 이건 그냥 각자 눈치껏 잘치기길 기대하는 수준이고, 커뮤니티의 방향성과는 무관한, 각자 지켜야할 운전 매너에 가깝다. 내 말은, 언젠가 커뮤니티내에서 큰 의견 차이가 생겼을때, '정치적 발언 안됨'이 해결책이 되길 기대할순 없단거다.
bgl gwyng shared the below article:
Stop writing CLI validation. Parse it right the first time.
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
This post introduces Optique, a new library created to address the pervasive problem of repetitive and often messy validation code in CLI tools. The author was motivated by the observation that nearly every CLI tool reinvents the wheel with similar validation patterns for dependent options, mutually exclusive options, and environment-specific requirements. Optique leverages parser combinators and TypeScript's type inference to ensure that CLI arguments are parsed directly into valid configurations, eliminating the need for manual validation. By describing the desired CLI configuration with Optique, TypeScript automatically infers the types and constraints, catching potential bugs at compile time. The author shares their experience of deleting large chunks of validation code and simplifying refactoring tasks. Optique aims to provide a more robust and maintainable approach to CLI argument parsing, potentially saving developers from writing the same validation logic repeatedly.
Read more →다시 힘을 내서 conal 리팩토링을 완성하고, haskell용 tree-sitter 바인딩을 만들고, 이것저것 마저 하자...
@hongminhee洪 民憙 (Hong Minhee) 근데 저는 어떤 언어든 디버깅용 로깅을 그냥 프리미티브로 제공하는게 맞다고 생각해요. stdout에다가 print하는 거랑 별개로 개발용으로요. 가령 console.log가 NodeJS 에선 그냥 print인데, 브라우저 개발자 도구에선 go to call site가 되는 제가 원하는 형태입니다.
제가 가장 좋아하는 언어에 기여를 했어요!
bgl gwyng shared the below article:
정치적인 컨텐츠에 대한 생각
Jaeyeol Lee @kodingwarrior@hackers.pub
이 글은 사회생활에서 금기시되는 정치 이야기가 우리의 삶과 얼마나 밀접하게 연결되어 있는지를 고찰합니다. 저자는 정치적인 것이 단순히 정부나 정책에만 국한된 것이 아니라, 사람이 개입하는 모든 영역에 존재한다고 주장합니다. 다양성을 존중하는 문화를 만드는 것조차 정치적 행위로 볼 수 있으며, 정치 혐오가 만연한 사회일수록 정치에 대한 관심이 더욱 필요하다고 강조합니다. 특히, 무심코 사용하는 표현이나 접하는 콘텐츠가 특정 정치적 의도를 담고 있을 수 있음을 경계하며, 정치적 프레임에 갇히지 않기 위해서라도 사회와 정치에 대한 꾸준한 관심이 중요하다고 역설합니다. 이 글은 정치적 무관심이 오히려 위험할 수 있음을 시사하며, 독자들에게 비판적 사고와 균형 잡힌 시각을 갖도록 촉구합니다.
Read more →
이제 Zed에서 Claude Code를 베타로 사용 가능
------------------------------
- Claude Code 와 Zed 의 통합이 공개 베타로 출시
- 새로운 *Agent Client Protocol (ACP)* 도입을 통해 다양한 에이전트와의 연결 확장 가능성 실현
- 개발자는 Zed 내에서 Claude Code를 실시간, 다중 파일, 커스텀 워크플로우와 함께 활용 가능함
- *Claude Code용 ACP 어댑터* 가 오픈소스로 공…
------------------------------
https://news.hada.io/topic?id=22887&utm_source=googlechat&utm_medium=bot&utm_campaign=1834
@bglbgl gwyng 예전에 《애자일 이야기》에서 읽은 김창준 씨의 글 〈인터뷰에서 진실을 들으려면〉이 떠오르네요.
@hongminhee洪 民憙 (Hong Minhee) 좋은 글 공유 감사합니다! 근데 저는 면접 시작전에 제가 '진실' 이상의 뭔가를 뽑아낼수 있다는 야무진 꿈을 꿨었네요.
강릉에 다녀왔습니다. #photography
방금 친구랑 모의면접을 봤는데(내가 면접관), 면접으로 알아낼 수있는게 딱히 있는지에 회의가 생겨버렸다. 아 물론, 내가 초보 면접관이라 면접스킬이 떨어지긴 한다만, 친구 얘기론(면접관 경험이 더 많음) 그래도 무난의 범위엔 든다고 한다. 이력서 기반으로 이것저것 물었는데, 만약에 이력서가 구라로 점철되있으면 그걸 걸러낼순 있었을 것이다. 근데 친구의 이력서는 당연히 그렇지 않았으니, 그냥 이력서가 구라가 아니란 사실 정도만;; 알아낼수 있었다. 이 이상 뭔가 더 꿰뚫어 보는게 가능할까... 하겠지? 그럼 어떻게 하는걸까.
지난 몇 달간 htmx로 웹 앱을 만들면서 느낀 점은, 골디락스 존의 하위 50% 애플리케이션에만 htmx가 적합하다는 것이다. 클라이언트 상태를 조금이라도 다뤄야 하는 순간이 오면 불행이 시작된다. 하이퍼미디어 시스템의 철학에 동의하는데, 그 구현은 아일랜드 아키텍처의 접근법이 더 나을 수도 있겠다는 생각이 든다. https://deno.com/blog/intro-to-islands
