bgl gwyng

PL을 체계적으로 공부하는걸 회피하고 그때그때 좋아보이는 개념을 찍먹만하며 살아왔더니, 그냥 현존하는 프로그래밍 언어에 불평불만만 많은 사람이 되고말았다;;

미중 무역 전쟁과 관련해 사람들이 미국만 걱정하고 중국은 별 걱정안하길래, 중국의 미국으로부터의 주요 수입품을 chatgpt한테 물어봤다. 1순위가 콩이라고 한다.

두부 좀 덜먹으면 되는건가...

k8s의 인터페이스는 .yaml 보다는 API로 평가받아야 한다. .yaml도 사실 API payload 그대로 쓰라고하는거고, 딱히 사람이 직접 작성하는걸 염두한거 같지 않다. 뭐 어차피 다들 kustomize 같은걸로 템플릿화 시키니까 괜찮다.

근데 내가 알기로 k8s에서는 이미지를 업로드하고 바로 Pod으로 실행시키는 API가 없다. 그래서 무조건 레지스트리에 준비시켜놓고 주소를 줘야한다. 심지어 이미지 레지스트리 자체는 플러그인으로 다양한 방식으로 확장가능한데 말이다. 이게 맞습니까?

k8s를 제대로 공부안하고 있는 이유는 딱 봤을때 k8s의 primitive 위에서 조화롭고 아름다운 뭔가가 만들어질거같은 느낌이 들지 않기 때문이다. 하스켈 튜토리얼 챕터1만 봐도 제대로 공부해봐야겠다 생각이 드는거랑 반대의 이유.

...인데 사실 저 느낌이 완전 틀렸을수 있다. 애초에 ops를 아름답게 하는 방법을 우리가 모르는 걸수도 있고. 또는 ops 자체가 현실의 지저분한 일임을 알기에 그걸 마주하지 않으려고 핑계대는 걸수도 있고. 약간의 상상의 나래를 펼쳐보자면, Pod 2개를 합성하는 연산을 정의하는 방식으로 쌓아올려나가면 어떨까 싶다. 지금은 Pod의 합성이란건 암시적으로 이루어지는데, 한 Pod의 노출된 ip:port를 다른 Pod이 보고 있으면 그게 합성이다;;

힘든 하루였다ㅜㅜ KFC 반값치킨 먹으러가야지

내가 k8s 자체를 딱히 좋아하느건 아닌데(어차피 잘 몰라서 좋고 싫고 할것도 없음), 근데 요즘은 처음부터 k8s 쓰는게 오버엔지니어링은 아니게 되었다. k3s같은 것도 있고(NixOS로 하면 5분이면 띄운다), 어차피 머신 적을때는 별로 설정할것도 없을 것이다. 혹시 뭔가 +알파로 해줘야할게 있을때 helm install로 날먹 할수 있다는 여지도 있다. 그 다음에 서비스 운영은 이제 docker-compose up하냐, kubectl apply -f deployment.yaml 하냐의 차이가 된다.

근데 또 복잡하지 않은 인프라라면, 때가되서 k8s로 옮기는 것도 크게 어렵지 않을 것이다. 나는 '옮기는' 종류의 일을 매우 하기 싫어/두려워하기 때문에(DB 마이그레이션 처럼) 그냥 service.k3s.enabled = true 해버린다.

RE: https://hackers.pub/@ujuc/0196189f-1c95-7120-831b-27d7c51e8f38

Jira, Linear 등 일정 관리 앱이 풀어야할 가장 어려운 문제는, 사용자 중 상당수는 애초에 일정 관리를 하기 싫어하는 사람이라는 것이다. 안타깝게도 나도 거기 포함되는데, 문제는 그런 사람일 수록 일정 관리가 꼭 필요하다. 나중에 프로젝트가 복잡해지면 일정 관리 앱을 켜는 거 자체를 꺼리게 된다. 이걸 어쩌면 좋지.

해커스펍을 스마트해지기 위한 용도로 쓰고 있다. 대수롭지 않은 생각도 어디안쓰면 쓸데없이 머릿속에서 리플레이된다. flush를 자주 하자...

RE: https://social.silicon.moe/@realgsong/114300412588845941

하스켈의 Lazy Evaluation을 설명하려고 기상천외한 예시를(처음 보면 저게 왜 돌아가지 싶은 fibonacci 등) 드는게 좋은지 잘 모르겠다. 뭐, 자랑하고 싶은 마음은 이해가 가나, 평소에 개발하면서 Lazy Evaluation의 쓸모를 느끼게 되는 경우랑 좀 거리가 있어보인다. 그냥 최대한 선언적인 코드를 짜고싶으면 Eager Evaluation이 방해가 되게 되고 이때 Lazy Evaluation이 필요하다는 설명으로 족하다.

FTP로 배포하는 php 서버에서(20년 전 대부분의 웹사이트), GitOps, 서버리스 아키텍쳐, 이벤트 드라이븐 프로그래밍의 편린을 엿볼수 있다. 지나고나서 이런 얘기는 누구나 다 할수있다. 근데 그 당시에 다같이 php 욕하는거에 휩쓸리지 않고 이걸 알아챈 사람이 있었을까.

ESM 알못인데 왠지 tsx를 쓰니까 잘 돌아서(뭔가 알아서 해주는듯하다), 그냥 배포도 .ts 파일로해서 tsx로 실행하도록 바꿨다. ...는 Deno잖아;;

Prisma는 ESM을 지원하지 않는구나... 그런즉 Fedify랑 같이 못쓰는구나... 매일 매일 말도안되는거 고치면서 시간이 가는구나...

작년부터 꾸준히 구글 주식 모으고있다. 가격 떨어져도 별로 개의치않고 그냥 추가 매수하고 그랬는데, 이번 폭락은 쫌 힘들긴하네...

Gemini Pro 2.5 엄청 똑똑하다... 기존 모델들은 대화가 길어지고 내용이 깊어지면 그냥 뻔한소리를 반복하기 시작하던데, 얘는 계속 생각해서 아이디어를 살려준다.

설치형으로 블로그 만들어서 가꾸고, 메일 서버도 직접 띄워서 쓰고 이런 개발자들보면 왠지모를 호감이 간다. 근데 막상 나는 저런거 귀찮아서 절대 안하고 맨날 공짜만 찾아다닌다.

조던 엘렌버그라는 수학자가 쓴 '틀리지 않는 법'이란 책이 있는데, 재밌고 읽어볼만하다.

그 책에서 컴퓨터가 수학자가 하던일을 할수 있게되면 어떡하냐에 대해 저자의 해결책을 제시하는데 원래 하던일을 컴퓨터한테 맡기고 수학자들은 더 고차원적인 일을 하면 된다고 한다. 한 10년 전에 읽었을때도 그냥 대책없고 나이브한 생각으로 보였다. 근데 요즘은 (실제로 어떻게 될지랑은 상관없이) 저런 나이브한 마음가짐을 일부러라도 가지고 일해야 뭐라도 해낼듯.

소수의견: 프로그래밍 언어의 identifier에서 그냥 소문자만 남기고 대문자를 아예 금지시켜야한다. 그리고 하이픈이나 언더바 둘중에 하나만 허용한다. 둘다 허용하면 취향에 따라 섞어쓰게된다. 진작에 이렇게 했으면 뭐시기 case 논쟁으로 시간낭비 안 했을것이다.

그리고 남은 대문자를 identifier와 충돌할 걱정없이 자유롭게 keyword에 쓰면 된다. 내가 생각하는 멋진 응용으로는, 객체 생성에 대표적으로 쓰이는 new 대신에 A를 쓰는 것이다. x = A user, 쏘쿨하지 않습니까.

빨리 팀을 만들어서 일정도 짜고 회고도 하고 회식도 하고 했으면 좋겠다. 그러기위해 어서 MVP를 완성하자.

슈티를 그냥 Misskey 클라이언트로 만들어 버릴까...

요즘 OTT에서 미드보다 보면(영드,한드 보다 특히 미드) 정말 질떨어지는 시나리오들이 많다. 제대로된 갈등 구조도 없이, 그냥 성질 더럽고 의사소통 못하는 캐릭터들을 다수 등장시켜 걔네들끼리 언성높이고 투닥거리는 걸로 시간을 다 보낸다.

근데 cabal처럼 기본이 스냅샷 모드인건 별로 같다. cabal로 locking하려면 시간으로(스냅샷을 특정할) 해야한다;; npm같이 각 패키지 버전과 lock이 있는 편이, 일단 심리적으로 더 든든하고, 또 가장 원자적인 동작을 더 확실하게 만든단 점에서 좋다.

대신 그 위에서 스냅샷(이라고 해야하나, 다른 이름이 있던거 같기도한데)을 다시 구현할수 있다. Expo같은 경우에 expo 패키지에 따라 나머지 expo-* 들의 버전이 결정되도록 한다.

스냅샷 방식이 이론적으로는 참 좋은데, 제대로 돌아가려면 사람들이 새로운 버전을 테스트하고 호환되는 버전을 업데이트하는 등의 잡다구리한 수고를 다 같이 해줘야 한다는 문제가 있(었)다. 하지만 요즘 잡다구리한 수고가 매우 저렴했으니 올바른 방법을 다시 밀고나갈수 있게되었다.

RE: https://hackers.pub/@hongminhee/0195f09a-a7d0-79aa-a819-bdcf97d6d830

플러그인과 미들웨어의 번역어로, '냅다 꽂기'와 '슬그머니 끼워넣기'를 제안합니다. 부정적인 어감은 의도한 바입니다.

그거 아십니까? XCode 업데이트는 거부할수 없고, 수락하면 보통 기존의 React Native 빌드가 터진다는 사실을... 해괴한 cpp 에러 메시지와 함께요

난 요거 반대의 도구를 찾고 있는데, remote로 electron이나 tauri등을 띄운다음에 웹뷰를 브라우저로 볼수있게하는 것이다. 안그래도 지금 GitButler 깔았는데 remote 사용을 지원안해서 난감해졌다.

하스켈 학교에 다니고 나를 찾는 사람 사라졌다

RE: https://hackers.pub/@curry/0195ec78-1026-7277-a2f0-c783c70cb1b9

그렇군요

Polymarket 등의 예측 시장에는 오라클 문제가 있다. 블록체인으로 만들어봤자, 어차피 베팅의 승패를 결정하려면 외부에서 딸깍 해줘야한다. 가령 4월 내에 탄핵이 이뤄질거냐 마냐 같은 게임을 상상하면 된다. 그 딸각하는 사람을 어떻게 믿을수 있냐는 문제가 오라클 문제다.

오라클 문제가 없는 예측 시장이 하나 생각났는데, 바로 수학 문제가 언제 풀릴 것이냐에 대한 것이다. 가령 리만 가설이 앞으로 1,000,000 블록 내에 풀릴지, 또는 P=NP랑 둘 중에 뭐가 먼저 풀릴지 등에 대한 것이다. 여기서 풀리는건 Lean 등으로 작성된 Formal Proof을 통해서 온체인으로 판단한다.

수학자들은 자신이 베팅을 걸어놓고 연구를 열심히해서 돈을 벌 수도 있다. 또 직접 연구를 하지 않더라도 GPU를 사서 자신의 베팅에 유리하도록 연구에 도움을 줄 수 있다. 앞서 그냥 유명하단 이유로 너무 거창한 문제를 예시로 들었는데, 그보다는 더 작고 쉬운 많은 문제들에 대해 이런 식의 경제가 돌아가는걸 상상해보자. 연구에 들어가는 자원 배분이 최적화되지 않을까?

인용RT 어떻게 하는걸까요? 저만 모르거나, 그게 아니라면 하는 방법을 좀더 알기쉽게 하면 좋을거 같습니다

React Native에선 설계를 보고 라이브러리를 고를 수가 없다. 뭔가 돌아가긴하는게 있다면 그걸 써야한다. react-navigation의 디자인을 도저히 이해못하겠는데 다른 선택지가 없는게 예시다.

ActivityPub 효율적으로 익히려면 그냥 fedify 문서 첨부터 끝까지 읽으면 되는듯요

펑터에 대한 수학귀신적 번역어로 '그물망 던지기'가 떠올랐다.

드디어 Bartosz Milewski의 Category Theory 강의를 챕터 2까지 끝냈다. 몇년 걸렸지... 중간에 정체된 기간이 꽤 길었는데, 야식 먹을때 죄책감을 달래는 용도로 틀어놓았더니 진도를 빨리 뺄수 있었다.

better CSS에 대한 접근들(CSS-in-JS, Atomic CSS, Preprocessor)의 공통된 한계는 constraint solving 방식이 아니란 것이다.

다들 어떤 기존의 스타일을 '덮어쓰는' 방법, 근데 개중에 좀 잘 덮어쓰는 방법을 찾고 있다. 그런데 많은 경우, 뭔가를 덮어쓰려고 하고 있다면, 그건 사실 값을 덮어쓰는게 아니고 만족해야할 조건을 추가하고 싶은거다. 값을 덮어쓰는 것은 조건을 추가하는 방법 중 가장 강제적인 하나의 방법일 뿐이고. 즉, 디자인 시스템은 어떤 조건들의 합들로부터 실제 스타일을 구하는 방법이어야 하고, 개발자는 조건만 명시할 수 있어야 한다.

constraint solving을 잘 설계하고 구현하는게 어렵다 왜 이렇게 안 하냐고 하긴 좀 거시기하다. 그래서 나도 요즘 propagator를 공부중이다.

인프라 작업을 점점 더 할수록 문제가 생겼을때 재부팅을 시도하는 시점이 앞당겨지고 있다. 그리고 그게 통한다...

@hong_minhee洪 民憙 (Hong Minhee) '맞팔로'라는 레이블이 저는 좀 헷갈리는거 같습니다. 그동안 '맞팔로'라고 뜬 사람들이 '맞팔로'가 되어있는 상태인줄 알았습니다. 그래서 팔로를 안하고 있었는데요. 팔로/언팔로랑 달리 동작인지 상태인지가 헷갈리네요.

옛날에 만들어놓고 저 혼자는 잘쓰고 있는 React 폼 라이브러리 react-form-mozard를 소개합니다.

폼 중에서 Stepper 또는 Wizard라고 하는, 여러 개의 폼을 순차적으로 합친 형태를 다룰때 씁니다. 그래서 하나의 폼에 대해서는 react-hook-form 등 을 쓰고, 그걸 여러개 조합할땐 react-form-mozard를 활용하면 됩니다.

순차적으로 합친 에서 느낌이 오지요? 모나드가... 그대를 부릅니다...

폼 말고 CLI를 만들때를 잠깐 생각해보죠.

const name = prompt("이름이?")
const age = prompt(`{name} 님, 나이가?`)
if (Number(age) < 20) {
  console.info("미성년자는 이용할 수 없습니다")
  return
}
const gender = prompt(`{name} 님, 성별이?`)

뭐 이런 흐름을 생각해볼 수 있는데요. 보시면 먼저 받은 입력값에 따라 이후의 메시지나, 제어 흐름이 달라질 수 있습니다. 즉, 모나딕하죠. 근데 이런 평범한 로직을 Stepper/Wizard 에서 짜게되면 코드게 쉽게 더러워 지는걸 알수 있습니다.

react-form-mozard의 step은 위 예제의 prompt와 같은 역할을 합니다. 그리고 그걸 Generator 위에 얹으면 모나딕한 폼 합성이 가능해집니다.

단점이라면... 지금은 React랑 강결합 되어 있어, XState 등 다른 상태관리 라이브러리를 같이 쓴다면 연동이 깔끔하지 않을수 있습니다. 근데 평소에 쉽게 겪을 문제는 아니라고 보고, 또 추후에 설계를 수정해서 개선이 가능한 부분입니다.

다들 개발할때 '하느님 제게 왜 이딴 시련을 : 하느님 이런 흥미로운 문제를 풀 기회를 주셔서 감사합니다'의 비율이 어떻게 되시나요? 저는 근 몇달간은 거의 99:1에 육박하는거 같습니다

Nix 기반의 인프라 관리에 관심있으신 Go 고수분 계시다면 nix-snapshotter에 관심 가져보시는걸 추천드립니다. 지금 메인테이닝이 살짝 안되고있는데 기여자가 많아지면 좋겠네요.

얼굴인식 사진공유 카메라앱 슈티를 함께 만들 분을 찾습니다. 앱은 출시되어 있어 써보실수 있습니다. 이번달 내로 페디버스 연동을 끝내면 제가 생각한 MVP는 완성입니다. 앞으로도 개발해야할 부분들이 많고, 개중에 기술적으로 흥미로운 문제들도 다수 있습니다.

지금 2025년 상반기 투자유치를 목표로 팀 빌딩을 하고 있습니다. 관심 있으신 분, 또는 잘 모르겠지만 이야기를 나눠보고 싶은 분도 bgl@gwyng.com으로 편하게 연락주세요.

높은 목표를 가진 개발자라도 결국엔 아주 사소한 동기로 움직이는거 같다.

나같은 경우엔, 완벽한 프로그래밍 언어를 만드는 것이 목표인데(가능한지는 차치하고), 완벽하다는건 나말고 다른 누군가가 같은 문제 의식을 가진다면 똑같이 그곳에 다다를 거란걸 의미한다. 그 프로그래밍 언어의 설계에서 내 마음대로 결정할수 있는 부분은 없을 것이다. 설계에서 최적의 선택지만을 택해야 완벽할테니까 말이다. 그때가선 그 선택들이 너무 자명해서, 내겐 처음부터 선택의 여지가 없었다고 느낄것이다.

그럼에도 내가 결정할 수 있을 부분이 있기는한데, 그 언어의 이름에 뜬금없이 우리집 강아지 이름을 붙인다던가 하는 것이다. 이게 그 사소한 동기다.

그동안(10+년;;) git이 엄청 잘만든 물건 같지는 않다고 생각하며 대충 쓰고있었는데, 요즘 branch 개념 자체가 근본적인 실수란 생각이 들기 시작했다. branch 대신에 변경의 시작과 끝, 양 끝점을 가지는 interval을 쓰는게 맞는거 같다(카테고리 이론의 작은 교훈: primitive는 양 끝점을 가지는게 좋다).

git을 쓰면 히스토리 길어진다고 squash merge 등을 하는데, (나도 하지만) 사실 기껏 만들어놓은 히스토리를 뭉개버리는 말도 안되는 동작이다. 만약 interval을 쓴다면 히스토리는 그대로 남기고 UI 단에서 fold/unfold 등을 해줄수 있을 것이다.

Darcs 등이 interval에 기초하는데, 지금은 일이 너무 바빠서 시도할 여유가 없다. 한번 숨고를 시간이 주어지면 멀쩡한 VCS를 탐색하는 시간을 가질것이다.

uv2nix는 uv보다 구리고, cabal2nix는 cabal보다 구린데, Nix는 uv + cabal + ... 보다 낫다. Nix 커뮤니티를 키우려면, 후자를 이해시키고(쉬움) 전자에 대해 익스큐즈하도록 설득해야한다(어려움) .

시간이 좀 지나서 그런가, 이제 계엄자체는 그냥 또라이가 또라이짓했다 정도로 생각되는데, 그 이후 탄핵 과정에서 뭔 말같지도 않는 어거지를 부리는거 때문에 자꾸 스트레스받는다.

그동안 동료들한테 Cursor 쓰자고했는데 그들이 오소독스 Emacs 매니아들이란 문제가 있었다.

작년에 Nix로 nvidia gpu 지원까지 포함해서 구축해놓은 k3s 클러스터에다가, 오늘 아침에 1시간만에 aider로 쓸수있게 DeepSeek R1을 띄웠고 한번 써보자고 했다. 최근에 한 것 중 가장 가성비 좋은 작업인듯 하다.

@campanulaLuminα 저의 경우는 React Native라서 백엔드로 SQLite를 쓰고 있어서 괜찮습니다. 생각해보니 RxDB 등의 경우는 웹도 지원해야해서 join을 지원하는게 어려울거 같긴하네요.

JS로 짜여진, join이 되는 reactive한 로컬 DB가 필요한데요. RxDB, SignalDB는 join이 안 돼서 탈락입니다. join을 안하면 되지 않냐 할수 있는데 어떤 특이한 로직 때문에 꼭 필요합니다. 지금은 직접 sqlite 호출하는 누더기 코드로 돌아가고 있는데요.

그 코드를 리팩토링해서 제대로 된걸 만들까 말까 고민중인데, 사실 잘만들어진게 있으면 그걸 쓰고 싶습니다. 제 요구사항을 만족하는 라이브러리가 있을까요?

영어권 웹을 보다보면 autism이 한국어에서의 '자폐'보다 부정적인 늬앙스가 훨씬 덜하단 느낌을 받는다. STEM 너드들이 본인이 autistic하다고 하는 경우를 종종 보는데, 자조적인 느낌이 좀 있지만 완전 딥다크한거 같진않고, 이분법적이기보단 스펙트럼으로 보는거 같다.

https://snix.dev/ 저는 Rust를 못해서 기여를 못하지만 유망한 프로젝트라고 생각합니다. Rust 고수분들이 관심가져주시면 좋겠네요.

바둑에 '묘수 3번두면 바둑은 진다'라는 말이 있는데, 프로그래밍에 비슷한 말이 있을까요