Now trying to implement a JMAP transport for Upyo…

https://news.hada.io/topic?id=25285

추상화가 강력한 더 좋은 언어를 쓰는 것 이상의 확실한 방법이 없고, 그 외에는 그냥 임시방편이라고 생각함.

내 트리를 꾸며줘!

helix/kakoune는 selection 기능 정리에 힘을 줬는데, 나는 emacs의 mark식 selection이 가장 편하다. h/k는 형식을 지키기 위해서 복잡해진 감이 있음. 통일성 없는 vi보다는 낫긴 한데.

Meta, Valve의 Steam Deck용으로 설계된 Linux 스케줄러를 대규모 서버에 사용
------------------------------
- Valve의 Steam Deck를 위해 설계된 *SCX-LAVD 리눅스 스케줄러* 가 Meta의 대규모 서버 환경에서도 효과적으로 작동한다는게 공개됨
- 이 스케줄러는 *게임 콘솔 수준의 효율적 자원 관리* 를 목표로 설계된 것인데, Meta는 이를 통해 *서버 워크로드의 성능 향상* 과 *지연 시간 최소화* 를 추구
- 휴대용 게…
------------------------------
https://news.hada.io/topic?id=25293&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

iOS에서 내가 쓸 단모음 키보드 앱을 만들고 있다.

기존에 쓰던 앱들이 있긴 했는데, 하나는 어느샌가 키보드 자판 위에 툴바를 붙이더니 월 구독 결제를 안하면 숨길 수 없게 해놨고 다른 하나는 최근 iOS 업데이트 이후로 텍스트를 지울때 단어가 망가지는 문제가 생겨서 대체제를 찾다가 마음에 드는게 없어서 결국 직접 만들기로 결정함..

직접 만들어서 테스트하다보니 유저 입장에서 어떤 부분이 불편한지 - 해소해야할지 보인다. 재미는 있는데 생각보다 신경써야 할 게 많다.

(1.x, 3.x)는 모든 조건을 만족하기 때문에 변환기를 거쳐 마이그레이션할 수 있다. (1.x, 3.x-beta)도 모든 조건을 만족한다. 반면 (3.x-beta, 1.x)는 (1), (3)을 위반하기 때문에 변환기를 사용할 수 없다. (2.x-alpha.1, 3.x-alpha.0)는 (1), (2)를 위반한다. 이렇게 출발 버전부터 시작해 a ≺ b 관계를 만족하고, b가 목적 버전이 아닌 경우 안정 버전이어야 한다는 조건을 적용해 나가면 도착 버전까지의 경로도 얻을 수 있다.

그런데 실제로 이를 조건 분기로 구현해보면 상당히 복잡해진다. 더 일반화된 방법이 필요하다. 버전 관계를 다시 정의해보자. 변환기를 기준으로 생각해보면 모든 버전 사이에 순서가 있다고 할 수는 없다. 버전을 poset으로 모델링해보면 어떨까? a ≺ b 관계가 성립하는 경우에는 b의 변환기를 이용해 a를 마이그레이션할 수 있다. 이 관계가 성립하려면 (1) a가 안정 버전이고, (2) b가 알파 버전이 아니고, (3) major(a) < major(b)이어야 한다.

오랜만에 복잡한 문제를 단순한 형태로 모델링해서 해결했다. 문제 상황은 대략 라이브러리의 메이저 버전을 위해 자동 마이그레이션을 지원하는 것이다. 각 메이저 버전에는 이전 버전의 코드를 자동으로 변환해주는 변환기가 함께 배포된다. 만약 1.x에서 3.x로 업데이트할 때는 2.x 변환기, 3.x 변환기를 순차적으로 실행해야 한다. 즉, 하위 버전에서 출발해 상위 버전에 도착하는 경로를 구해야 한다.

그런데 베타 버전(x.y-beta)과 알파 버전(x.y-alpha.z)을 고려해야 한다. 베타 버전에는 직전 버전에 대한 변환기가 있고, 알파 버전에는 변환기가 없다. 나이브하게 생각해보면 출발 버전 유형과 도착 버전 유형의 조합에 대해 모든 경우를 분기해서 경로를 구할 수 있을 것처럼 보인다.

On a related note, if you learn better by building things, @fedifyFedify: ActivityPub server framework has a step-by-step tutorial where you create a federated microblog from scratch—implementing actors, inbox/outbox, following, and posts along the way:

https://fedify.dev/tutorial/microblog

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

GUI앱을 못보니까 콘솔로 출력해서 본다는 점이 정말... 나보다 낫군

According to @tchambersTim Chambers's My 2026 Open Social Web Predictions:

Fedify will power the federation layer for at least one mid-sized social platform (500K+ users) that adds ActivityPub support in 2026. The “build vs. buy” calculation for federation shifts decisively toward “just use Fedify.”

We're honored by this recognition and will keep working hard to make #ActivityPub adoption easier for everyone. Thank you, Tim!

#Fedify #fediverse #fedidev

Here's a #TypeScript API design challenge I'm working on: adding async support to #Optique (CLI argument parser) without breaking the existing sync API.

The tricky part is combinators—when you compose parsers with object() or or(), the combined parser should automatically become async if any child parser is async, but stay sync if all children are sync. This “mode propagation” needs to work at both type level and runtime.

I've prototyped two approaches and documented findings. If you've tackled similar dual-mode API designs, I'd love to hear how you approached it.

https://github.com/dahlia/optique/issues/52

목공용 절단도면 만들어주는 프로그램 뇌 비우고 Claude Code한테 시켰더니 때깔이 좋네

Stacked Diff 관리하려고 Sapling을 찍먹해봤는데, 이건 누가 hands on 세션을 하는게 아닌 이상 익숙해지는게 좀 어려울 듯.....

https://github.com/stadia/textsearch_ko 잘 쓰고 있는 pg 확장인데 너무 오래 된 것 같아 업데이트를 해봤습니다. 원본 https://github.com/i0seph/textsearch_ko

CI 실행 시간을 1/3로 줄였음

GitHub Workflows 어렵네.. 3년 동안 새로운 걸 배워보려고 하지 않은 업보가 이렇게. 즐거운 마음으로 해야 하는데 ㅎㅎ

NextJS 처음 써보는데, 챗봇 UI처럼 인터액티브한 웹앱을 만들때 도움이 되는 부분이 뭔지를 모르겠다. 처음엔 SPA + API 서버 만드는것과 비교해, 자명한 데이터 바인딩 보일러플레이트를 줄여줄거라 생각했다. 근데, 순수 SSR로 처리할 수 없는, 클라에서 상태를 업데이트하는 약간만 복잡한 플로우에서도 전혀 도움이 안된다.

일하다 막힐 때 위키피디아, 한국민족문화대백과사전, man 페이지 설명 읽는게 머리 식히는데 좋은 것 같음

정보가 부족한 에러 메시지로 인해서 약 하루를 버렸다. 정보가 부족한 것도 있지만, 믿음(?)이 부족해서 멀쩡한 곳만 잔뜩 쳐다보고 있었다.

Claude Code에 네이티브 LSP 지원 기능 추가
------------------------------
- 터미널에서 실행되는 *AI 기반 코딩 도구* 인 Claude Code 가 최신버전에서 *LSP (Language Server Protocol) 도구* 를 추가
- 이를 통해 *정의로 이동(go-to-definition)* , *참조 찾기(find references)* , *호버 시 문서 표시* 같은 *IDE 수준의 코드 인텔리전스 기능* 제공
- /terminal-setup 명…
------------------------------
https://news.hada.io/topic?id=25269&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

NextJS + Vercel AI SDK로 챗봇 UI 만들다가 수명이 줄겠네..

Jackson: Debian’s git transition

https://lwn.net/Articles/1051580/ #LWN

State of the Art가 별건가… 서령은 예술의 경지가 맞다. 입이 귀에 걸린 채로 먹고 온 것 같다. 잘 먹었습니다!!

오픈소스 프로젝트의 커뮤니티를 어떻게 운영해야 지속적으로 사람들이 참여하게 할 수 있을까..

@hongminhee洪 民憙 (Hong Minhee) 비슷한 접근이란 것만 알고 있습니다. 남은 문제를 개선하는데 어느쪽이 더 좋은 설계를 갖고있는지는 모르겠네요. 근데 Nix가 일종의 기본 레지스트리에 해당하는 nixpkgs의 규모가 더 클거 같은데, 그러면 당장 쓰기엔 수고가 덜할거 같네요.

코드 수정 제안 반영은 해당 줄을 대치하는 방식으로 처리해도 충분했는데 이제 그래프 매칭 문제로 바꿔야겠다

그동안 Nix 쓰면서 고통도 많이 받았는데 그래도 주변에 꾸준히 Nix를 권한다. Nix가 '빌드'라는 소프트웨어 개발의 아주 일반적인 문제를 한방에 푸는 방법론이기 때문이다. 물론 아직 몇가지 문제가 좀 있지만(잘 안된다, 불편하다 식의 단순한 문제는 아니다), 나 자신도 그 해결책을 위한 몇가지 아이디어를 가지고 있고, 머지않은 미래에 풀릴거라 생각한다.

UNIX 철학이 작은 기능을 확실하게 수행하는 프로그램들을 만들어 조합하자인데, ls, cat, grep 등이 그 예시다. 내가 볼땐 Nix도 생각도 거기에 해당된다. Nix도 좋은 의미로 의외로 꽤 작다.

어제 송년회에서 오라클 이야기가 너와서 나도 써보려고 하는데... n8n이라도 올려야겠다.

Optique 문서를 보다가 argument ordering 파트에서 프로퍼티가 나타난(? appear) 순서대로 파서가 동작(? consume)한다고 되어 있어서 Object 타입인데 이게 작성한 순서대로 Object.entries() 같은 곳에서 순회되기를 기대할 수 있나 의문이 들었다(Object가 Map같은 거라고 생각했어서).

아래와 같이 타고 가면:

1. 20.1.2.5 Object.entries ( O ) (User call)
2. 7.3.23 EnumerableOwnProperties ( O, kind ) (called by 2. Let entryList be ? EnumerableOwnProperties(obj, key+value).
3. 10.1.11 [[OwnPropertyKeys]] ( ) (called by 1. Let ownKeys be ? O.[[OwnPropertyKeys]]().)
4. 10.1.11.1 OrdinaryOwnPropertyKeys ( O ) (called by 1. Return OrdinaryOwnPropertyKeys(O).)

아래와 같은 대목을 만나는데:

1. Let keys be a new empty List.
2. For each own property key P of O such that P is an array index, in ascending numeric index order, do
   1. Append P to keys.
3. For each own property key P of O such that P is a String and P is not an array index, in ascending chronological order of property creation, do
   1. Append P to keys.
4. For each own property key P of O such that P is a Symbol, in ascending chronological order of property creation, do
   1. Append P to keys.
5. Return keys.

만약 key가 array index가 아닌 문자열 혹은 Symbol이라면 프로퍼티 생성 발생의 오름차순 순서(? ascending chronological order of property creation)대로 순회(?)해야한다고 적혀있다.

아마.. 잘 못 찾아서 못 본 걸수도 있지만 chronological이나 creation 같이 검색했을때 스펙에서 이를 다루는 방법을 정의하지는 않는 것 같았다. 예를 들어, PropertyDescriptor이 auto increment 되는 고유 ID를 갖고 있어야 하고 이를 통해 정렬해야한다, 거나?

실제 구현을 보고 싶어서 GitHub에 있는 V8 미러로 가서 보니 key들을 OrderedHashSet으로 갖고 있는 듯 했다. 생각해보니 그러면 되네, 싶어서 더는 안 찾아봤다.

암튼 Optique 문서대로 생성 순서대로 동작할 것 같다!

가족들이 밋업 굿즈를 탐내는 건 처음이다. 다음번엔 앵그리 버전 한 표!

tauri로 패스워드 툴 만드는 이유, 레거시 프로덕트의 지속 여부를 결정할 때 llm을 어찌 썼는지, claude skill 활용 방법, 오라클 클라우드 쓰면 왜 좋은가, 개발자가 개발을 좋아하냐, 좋아 해야만 하냐, 개발자의 ethic 등... 2025년 라스트 개발 밋업이 알차네요.

LLM 도움이면 못할 것도 없을 듯 하여 블로그를 직접 만들고 싶은데, 스프링부트 + 그냥JS로 만들어도 괜찮을지 모르겠습니다. (사실 아는 게 그것 뿐입니다..) 혹시 조금 더 편리하고 좋은 스택이 있을까요?

지금 만드는 걸 좀 어떻게든 해야 보이든 할 텐데. UK Gov의 컴포넌트를 굉장히 참고하고 있습니다. 'looking good!'을 신경쓰다보면 쉬운 길은 많죠. 장애인 관련 홈페이지를 만들고 있습니다.

어제 해커스펍 송년회를 잘 다녀왔습니다. 이동하는 버스 안에서 제 해커스펍 주소를 QR 코드로 열심히 만들었는데, 막상 공유할 용기는 없어서 못 했네요 ㅋㅋ

전날까지도 갈까 말까 고민을 많이 했었는데, 부담감을 이기고 다녀오길 정말 잘했다는 생각이 들었습니다. 라이트닝 토크도 하나같이 유익했어요.

저는 클로드 코드는 아직 써보지 않았는데 (토큰이 살살 녹는다는 얘기를 들어서요 ㅋ ), 이야기를 듣다 보니 요즘 대세는 확실히 클로드 코드인가 싶더라고요. 이제 써볼까 생각만 하고 있었는데, 어제 라이트닝 토크 발표를 듣고 나니 “바로 시작해봐야겠다”는 생각이 들었습니다. 🐱‍💧

집에서 멀어서 좀 늦게 도착. 아무튼 왔다.

역시 전반적으로 클로드를 많이들 쓰시는구나- 하는 인상

해커스펍 송년회 인기 폭발이라 참여를 못하고 튕겨져 나왔어요 ㅎㅎ. 서로 말귀!가 통하는 사람들끼리 네트워킹 시간을 가질 수 있는 귀한 기회였습니다.

해커스펍 송년회를 다녀왔습니다. 발표를 라이트하게 가져간다 해서 라이트하게 질문 편하게 했는데, 질문 총량이 넘어가진 않았나 걱정될 정도로 많이 한 것같아 살짝 불안하지만, 재밌었습니다.

이미지를 리사이징, 다른 포맷으로 변환하는데, imagemagick은 올바르게 이미지를 처리하는데, imgage-rs, mozjpeg는 알 수 없는 점이 잔뜩 생긴다. 일단 되는 것 찾았으니...

https://github.com/makachanm/knife

개인적으로 진행하는 풀스택 프로젝트로써 단순한 싱글-유저 액티비티펍 블로그 플랫폼인 Knife를 제작중이다. 직접 이 플랫폼으로 글을 가끔 끼적이면서 조금씩 개선시킬 생각이다.

제 지인 분이 GitHub 에서 인종차별적 코멘트를 받으셨습니다. GitHub 계정이 있으시면 신고 부탁드립니다. 영어가 어려우시더라도 LLM으로 신고글 써달라고 하면 잘 써줍니다. 신고는 단 시간 내에 많이 찍혀야 실제 보고로 올라가기 때문에 가능하신 분들은 꼭 신고 부탁드립니다.

오늘 해커스펍 송년회에서 오라클 사용해도 될까? 주제로 발표한 로빈입니다! 행사 정말 재밌었고요 오라클 쓰는 이야기 GraphQL 이야기 플랫폼 비즈니스의 방향성 이야기 등등 마음껏 해주세요~

오늘 Hackers' Public @ Seoul 송년회에서 이야기한 "코딩 에이전트와 함께 이세계 던전 탐험하기: 새로운 환경의 코드 베이스를 빠르게 분석하는 방법"의 발표 슬라이드는 [다음 링크]에서 다운로드 받으실 수 있습니다! :)

RISC-V Mainboard For the Framework Laptop 13 Is Now Available https://hardware.slashdot.org/story/25/02/04/217248/risc-v-mainboard-for-the-framework-laptop-13-is-now-available?utm_source=rss1.0mainlinkanon

오늘 Hackers' Public @ Seoul 송년회에서 "개발자는 개발을 좋아해야 하는가? 에 대한 고찰"로 라이트닝 토크를 진행했습니다. 사실 제가 발표자인줄도 모르고 앞에서 이야기를 진행하게 되었는데, 많은 분께서 호응해주시고 또 경험에서 우러나온 진솔한 의견을 내주셔서 다양한 이야기가 오갈 수 있었습니다. 모두 감사드리며, 내년에 모두 원하시는 바 이루기를 기원하겠습니다. 🥰