bgl gwyng

뭔가를 잘 설명하는 방법에 대해 생각해봤는데. 일단 내가 어떤 내용을 말하고 싶은 욕구를 참아내야다. 어떤 재치있는 비유를 꼭 써야겠다거나, 아니면 '통찰'을 전달하고 싶다거나.

대신 상대방의 무지에 공감해야한다. 그 무지란게, 많은 경우 진짜 멍청해서 그런게 아니라, 대충 얼개는 파악하고 있음에도 뜬금없는 부분에서 뜬금없는 오해를 하고 있어서 완전한 이해를 막는다거나 하는 경우가 많다. 그래서 그 귀여운 멍청을 함께 디버깅해야한다. 요게 지식뿐만 아니라 공감능력이 필요한 부분.

크롬 개발자 도구의 네트워크 디버거에, 특정 상황에서(제 경우엔 400 Bad Request 에러 발생) 응답 본문이 빈 문자열로 표시되는 버그가 있는거 같습니다???

역시 하스켈을 가르친 덕택일테지...

마지막 멘티가 취직에 성공해서 기분이 좋구만

유튜브 쇼츠 안보이게 해주는 크롬 확장. 왜 진작에 쓸 생각을 안 했지?

https://chromewebstore.google.com/detail/remove-youtube-shorts/mgngbgbhliflggkamjnpdmegbkidiapm

코드에디터의 탐색기 동작을 이렇게 개선하면 좋겠다.

지금 큰 프로젝트에서 이파일 저파일 돌아다니다보면 너무 많은 디렉토리들이 expand되어서 필요한 디렉토리를 찾는게 어려워진다. 이때 expand되어 있는 디렉토리중에, 직접 탐색기안에서 찾아서 들어간 경우가 있고, Go to Definition나 방금 닫은 창 다시 열기 등의 간접적인 방법으로 expand된 경우가 있다. 후자의 간접적인 방식으로 열린 파일이 닫혔을때 이로 인해 열린 디렉토리 중 전자의 방식으로 열리지 않은 것을 자동으로 닫아줬으면 좋겠다. 일종의 가비지 컬렉트?

...인데 https://github.com/microsoft/vscode/issues/150869 똑같은 제안이 있었는데 업보트가 부족해서 나가리됐구나ㅠ

내가 Git 쓰다가 왕대빵 커밋 똥히스토리 남기는 전형적인 패턴이다.

1. 간단한 기능 A를 추가하려고 한다.
2. A를 추가하려면 기존의 설계 B를 고쳐야한단걸 깨닫는다.
3. B를 고친다.
4. A를 추가한다.

이렇게 3, 4의 변경이 한데 들어가 있는 무근본 커밋이 탄생한다. 2 -> 3 사이에 stash를 하면 간단히 해결되는 문젠데 매번 까먹고 실천을 못한다.

요즘 하스켈 LSP가 너무 느려서 코드 수정하고 저장해서 오토포매팅 기다리는동안(몇초 걸림) LLM이 먼저 나서서 포매팅해준다;;

크런치ㅠㅠ 너무 기대된다ㅠㅠ

Zed는 아직 쓰지도 않는데도 요즘 보기드문 장인정신이 느껴지는 소프트웨어라 호감이 간다. 지금 쓰고있는 Windsurf는 VS Code 포크떠서 AI 채팅만 추가했는데 하루에 3번 터져서 에디터를 재시작해야한다(AI 채팅 패널이 터지는거라 VS Code가 아닌 Windsurf 문제로 보임). 5조 투자받은건 어따썼니??

지금 GraphQL Client로 Altair를 쓰고있는데, 요즘 이런 류의 API 테스트 툴에 살짝 회의가 든다. 쓰다보면 일찌감치 스크립팅을 하고싶어지고 그건 그냥 JS로짜면 된다. API 테스트 환경도 그냥 개발 환경과 같이 관리하면 되서 오히려 더 편하다. Postman은 조금밖에 안써봐서 모르겠다.

오늘 개발은 ! 하나 빼먹은거 못찾아서 귀중한 2시간 날아가고 시작~

펑터를 지하철 노선으로 설명해도 좋을거 같다. 서울의 지하철 노선도를 외우고 있는거랑 서울의 지리에 대해 빠삭한 거랑은 거리가 멀다. 그리고 지하철만으로 서울의 모든 곳을 구석구석 돌아다닐수 없다. 중간에 내려서 걷거나 버스를 타야 한다. 하지만 효율적인 경로를 찾는데 큰 도움이 된다는 사실은 부정할수 없다.

F : 지하철 노선도 -> 서울에서 F는 지하철 노선도를 참고해 현실에서 실제로 지하철을 타는 행위가 된다. 우리는 서울의 지하를 돌아다니고 싶어서 지하철을 타는게 아니다. 서울을 돌아다니고 싶은데 여기에 지하철의 도움을 빌리는거다.

프로그래밍도 어떤 경로를 찾는것으로 이해할 수 있다. f : a -> b란 함수를 구현하는 것은 a에서 출발해서 b에 도착하는 길을 찾는 것이다(도착만 한다고 장땡이 아니란 점에서(=타입만 맞는 쓸모없는 함수를 구현하기) 위에서 든 지하철 비유랑 갈라지기 시작한다).그런데 함수(경로)는 무수히 많고 그중에 내가 원하는걸 하나 찾아내는건 어려운 일이다. 이때 좀더 단순한 이해하기 쉬운 지도와(다른 카테고리), 그 지도를 따라서 움직이는 방법(펑터)를 알고있으면 도움이 된다. 펑터 F : C -> D는 D라는 넓은 영토를 돌아다닐때 C라는 지도의 도움을 받는 방법으로 볼수있다.

한 2년전부터 XState 대충 알고 쓰면서 느끼는 점들.

1. 처음부터 정의가 verbose하고 그걸 작성하는게 수고로운건 알고있었다. 하지만 LLM을 믿고 쓰기로 결정했는데, 지금 2025년에도 여전히 LLM이 상태머신 설계를 잘 못한다. 얘한테 설계를 맡겨놓으면 뭐랄까, 성의가 없다고까지 느껴진다. 왜 그런거지?

2. Snapshot은 subscribe할 수 있다. 근데 그 Snapshot을 유발한 Transition이 같이 전달이 안된다. 사실 이게 필요했던 핵심 기능이었어서 이게 안된다는걸 알고 매우 당황했다. Transition에 반응하는건 오로지 상태머신 내에 설계된 action을 통해서만 가능하고, 상태머신을 구독하는 쪽에서는 안된다. 왜 이렇지?

3. 상태머신을 확장하는 방식이 제한적이다. 이미 정의해놓은 action, actor들을 다른걸로 override하는 방식을 제공하는데, 상속 비스무리하다는 점에서 한계가 느껴진다. 실제로 사용하면서도 그 한계를 느꼈다.

종합하면 아직까진 수지타산이 안 맞다.

요즘 '이건 잘못된 코드지만 당분간 고칠일이 없기를 기도하자'고 하며 넘어간 코드들에서 나온 버그들을 계속 고치는 중이다.

과거의 나의 정확한 안목에 뿌듯해하며 동시에 피눈물을 흘리고 있다.

데이터에 대한 modality, 가령 동기/비동기, 더 나아가 캐시됨, 캐시되었지만 stale됨 등에 대해 일반적인(polymorphic) 함수를 만드려면 HKT가 필요하다. Relay와 같은 현존하는 JS 상태관리 라이브러리들은 저런 modality를 한번에 다 지원하는 대신, 확장에 열려있지 않는 구조로 되어있다. 타입을 제대로 지원못한다고 해서 구현을 못하는건 아닐테니, HKT 없음이 주된 이유는 아니겠지만 말이다.

최근 TS 코딩중에 async/sync에 대해 polymorphic한 인터페이스를 제공하려하다보니 HKT의 필요성을 느끼게 되었다. 해결책은 그냥 synchronous만 제공하기로;;

라이브러리를 좀 대국적으로 만드십시오!!!

Existential Lens란걸 알게되었는데 정의는 다음과 같다

data Lens s a = forall c. Lens (s -> (c, a)) ((c, a) -> s)

돌무식 렌즈(get, set 레코드)보다는 좀더 어렵지만 Van Laarhoven Lens보다는 훨씬 더 직관적이라서 렌즈의 이해에 도움이 많이 되었다.

전체 설명은 요깄다.

똥코드 짜놓고 TODO: refactor를 남기며 죄책감을 덜어내는중...

예전에(혹시 지금도?) 신문 컬럼에서 흔히 볼수 있는 글 구조가 있는데, 우선 뜬금없는 주제로 서문을 연다. 가령, '고대 그리스에는 이러저러한 풍습이 있었다' 하는 식으로.

이러고 글의 3/4 정도 지점까지 고대 그리스의 어떤 풍습에 대해 설명한다. 소재가 흥미로운데다가 기본적인 글솜씨는 있기에 술술 재미있게 익힌다. 이제 유익하고 흥미로운 내용이 끝나면 '하지만 작금의 대한민국의 현실은 어떠한가'며 갑자기 핸들을 꺽는다. 그리고 자기 하고싶은 말로 나머지 분량을 채우고 글이 마무리된다.

앞부분 3/4의 시사교양정보와 뒷부분 1/4의 아무말대잔치의 연관성을 찾아내는것은 오롯이 독자의 몫이다. 아마 수십년간 이 황금(?)패턴으로만 글을 수백편 써온 소위 평론가/칼럼니스트 등등이 상당수 있을것이다.

React Native 라이브러리 쓸때 제일 (충분한 까닭없이) 고통받는 경우가 JS 단에 노출되어야할 API가 쓸데없이 한번 래핑되서 네이티브 단에 숨어있는 경우인거 같다. 오히려 래핑을 안했으면 JS 단에서 알아서 쇼부를 볼텐데, 쓸수있는 인터페이스가 충분히 원자적이지 않아서 네이티브단 코드를 까거나 아니면 꼼수를 써야한다.

이름값 못하는 프로그래밍 개념들로 플러그인과 미들웨어가 있는데

• 플러그인: 플러그-인 하면 고장남
• 미들웨어: 가운데 두면 고장남

요즘 자기전에 진격거 애니보는데 개재밌다. 만화책으론 봐서 내용은 다아는데도 애니만의 재미가 따로 있다는게 느껴지네.

React 컴포넌트 디자인중에

<Container>
  <Header>...</Header>
  <Content>...</Content>
  <Footer>...</Footer>
</Container>

이런식으로 Header, Content 등의 컴포넌트는 Container 아래에서만 유효하게 동작하는 방식이 있는데, 이게 진짜 장점이 있는지 궁금하다. 차라리 header, content 등의 props로 뚫어놓는게 낫지않나.

에디터가 하스켈의 타입 에러메시지를 보여줄땐 호버링으로 뜨는 창으로는 부족한거 같다. 별도의 뷰를 만들어서 크게 보여주고 또 rich한 기능(메시지에 포함된 심볼로의 navigation 등)을 제공하면 좋겠다.

애플이 liquid glass로 사방에서 욕을 먹고있는데, 스샷들을 보면 그럴만하다 싶다. 근데 반투명한 배경의 창이 가지는 시맨틱이 뭘까? 언제 써야하고 언제 쓰면 안될지를 어떻게 구분해야하지.

기대를 갖고 HLS를 2.10으로 버전업했는데 여전히 너무 잘 터진다. 혹시 우리쪽 패키지 구조에 문제가 있는건가 싶기도한데...

오늘 멘토링 마지막날이라서 멘티 @oilpaintingkim 님을 A/S 차원에서 해커스펍에 초대했다

인스타 클론 코딩 만만하지 않은것으로 밝혀져...

요즘 유튜브 쇼츠에 3초면 다 보고 이해할 내용을 한심한 AI 더빙을 얹어서 30초로 늘린 동영상이 범람하고 있다. 유튜브 Shorters가 필요하다.

평소에 쓰는 모든 앱을 다크 모드로 하고 살다보니 어쩌다 라이트모드 화면을 보면 이렇게 된다

코딩중에 동작을 disable시키기 위해 주석을 많이 쓰는데, 이런것도 그냥 기본 문법에 Disable같은 키워드로 넣어 주면 좋겠다. 또 콘솔에 메시지를 찍을때 현재 소스 코드 위치를 찍는 것도 기본 기능으로 넣었으면 좋겠다.

이런 제안에 대해 거부감이 든다면(나도 듬), 그건 프로그래밍 언어의 문법이 완성된 코드라는 정적인 정보를 묘사하기 위함이라는 생각 때문일 거라고 짐작한다. 중간에 나오는 못난 코드들을 보조할 필요는 없다는 입장? 근데 사실은 못난 코드 보고 있는 시간이 코딩하는 시간의 99%다.

지금 쓰레드엔 ai 인사이트(가 있다고 주장하는) 포스팅 사이 사이에 부정선거 음모론 포스팅이 뜨는 상황인데 인외마경이 따로없다

@hollo 같은 얘기입니다ㅋㅋ근데 하스켈에서 '요청을 보내되 응답은 다른 쓰레드에서 받기'란 이펙트를 구분할수가 없지 않나요? 새 쓰레드를 띄울수있는 이펙트랑은 좀 다르다고 생각합니다. 새로 쓰레드를 띄우면 거기서 무제한으로 요청/응답을 할수있는데 그걸 바라진 않아서요.

평소에 함수형 언어 매니아들이 주장하는만큼 이펙트를 엄격하게 구분하는게 중요하다곤 생각안했는데, local first 앱을 만들다가 네트워크 요청을 포함한 IO와 그렇지 않은 IO를 구분해야하는 이유를 찾았다. 앱의 초기화 로직에 네트워크 요청이 숨어있으면 API 서버 장애시 앱이 아예 안켜지는 문제가 있다. 방금 이거랑 관련된 버그 찾느라 시간을 많이 썼다.

다들 그렇듯 나도 나이먹으면서 점점 관심없는 주제로 별로 안친한 사람들과 스몰토크하는 것에 익숙해졌는데, 여전히 사주팔자/점술 이런 얘기가 나오면 도저히 뭐라고 맞장구를 쳐야할지 모르겠다. 이야기하는 그룹에 그런거 좋아하는 사람이 여러명 있을땐 그들끼린 너무 즐겁게 그 주제로 꺄르르르호호호 하는데, 주제가 좋고 싫고를 떠나서 진짜 한마디도 할 마디도 거들수가 없더라. 그나마 비꼬지 않고 닥치고 있는게 철든 결과물인듯하다.

빨리 생활을 정상화시킨 다음 스위치2랑 젤다 왕눈을 사서 다시 비정상화시키고 싶다.

슈티를 페디버스에 연동하기 전에 UI 만드는 중인데 사실상 인스타 클론코딩이라서 좀 현타가 오고있다ㅋㅋ

유려한 애니메이션과 화면 전환을 갖춘 앱을 만들려면 실행중에 요소의 크기를 측정하는 등의 동작이 필수란걸 점점 깨닫고 있다. 또는, 정적으로 레이아웃 정보를 미리 알수있는 방법이 있다면 더 좋겠다만.

대학생때 친구(컴알못)가 노트북 견적 짜달라고 한적이 있는데, 성능 상관없고 최대한 싸게만 해달라고 했다. 그래서 운영체제 미포함 기기에 우분투 깔아서 30만원으로 맞춰줬다. 우분투를 영업하려는 의도는 전혀 없었고 싸게 해달라는 요구를 최대한 맞춘 결과였다. 걔가 그때 형편이 안 좋아서 한푼이라도 아끼는게 중요했고, 나는 나름 목적을 달성했다는 것에 뿌듯해했다. 리브레 오피스 깔아주면서 한글, 엑셀 대신에 이거 쓰면 된다고 설명했던 기억이 난다.

그리고 이 일을 까맣게 잊고 살다가 1년후 쯤에 그 친구를 다시 만났는데, 보자마자 반응이

예전에 게임 회사에서 상점 시스템(게임 머니로 아이템 구입/선물을 처리하는거)을 개발하는 팀에서 일한적이 있다. 그때도 퇴사하기 직전에 취약점을 발견했었는데, 다행히 외부인은 쓸수없고 직원만 쓸수있는 취약점이긴 했다. 상점 시스템이 게임 머니를 관리하는 시스템과, 실제로 아이템을 인벤토리에 넣는 시스템이 분리가 되있어서 생긴 문제였는데, 가령 잡템을 100원에 구입하는척하며 실제론 인벤토리에 전설의 무기가 들어가게끔 할수 있었다. 그러니까 MSA인데 각 서비스가 서로를 100% 신뢰하고 있어서 생긴 문제? 어떤 직원이 마음먹고 그런 짓을 했다면 본격적으로 abnormarly detection을 하지 않는이상 적발하기가 매우 어려웠을 것이다.

공인인증서의 생체인증 기능 말인데요, 이거 개인키를 기기가 아닌 서버에 두고 서명하는 건가요?

삼쩜삼 수수료 왤케 비싸졌냐. 삼십삼으로 개명해야할듯.

정의로 이동(Ctrl + F12) 특:

잘 모르는데 불안정한 라이브러리를 쓸때의 디버깅은, 코드의 일부를 disable하고 버그가 재현되는지 보고 맞으면 범위를 좁히고 이런식으로 무지성 이진탐색을 수행하는 식으로 하게된다. 전혀 모르는 라이브러리에 대해서도 쓸수있는게 장점이긴한데, 반대로 이런건 하고나서 배우는게 진짜 1도 없다.

날씨가 너무 좋아서, 사무실에서 일하고 있으니 우울하고만.

어제 하스켈러들과 얘기하다가 느꼈는데, Linear Type이 얘기는 오래전부터 나왔지만 실제로 개발에 써본사람은 많지 않아서 약간 떡밥화?가 된거 같다. 나도 Linear Type에 대해선 예전에 Idris로 쓰여진 튜토리얼을 보고 흥미롭다고 생각한게 전부다. 근데 함수형 언어에 대해 GC가 필수라느니 C처럼 성능 최적화를 못한다느니 같은 이야기를 들을때 Linear Type을 언급하며 킹론상 가능하다능...이라고 하게된다(나말고도 많이들 그럴듯?) 하지만 정작 구체적으로 어떻게 구현하는지 공부해본적은 없다ㅋㅋIdris2가 궤도에 오르면 떡밥에서 벗어나려나.

React Native에 Portal이 없어서 좀 고생을 했는데, 일단 지원하는게 맞다곤 생각한다. 근데 Portal이 필요한 경우는 상태 트리랑 뷰 트리가 순서가 어긋나있을 때인데(non-monotone?) 이런 설계 자체가 문제일 수 있다. 보통 개발할때 뷰 트리 기준으로 생각하기 때문에 그런데, 상태 트리를 먼저 다 설계하고 렌더링은 최대한 단순하게 하면 될거 같긴한데, 음 이거 Redux잖아ㅋㅋㅋ

많은 언어에서 배열이 primitive로 주어지기 때문에 간과하기 쉬운데, 실제로 배열은 Binary Trie이다. 인덱스 0b01101010로 어떤 배열을 접근한다는건 왼오오왼오왼오왼으로 트리를 타고 내려가는 것이다. 실제로 칩에서 어떻게 동작할지를 상상해보면 좋다.