@hongminhee洪 民憙 (Hong Minhee) 제가 tsgo에 가장 기대하는 부분 중 하나입니다.... 😂

SMC made it just in time for the merge window! Now it's finally possible to reboot M1/M2 with an upstream kernel ;)

This also allows to enable the power gpios for e.g. wifi and allows us to upstream drivers for the power button, hardware sensors, battery status and RTC next.

https://lore.kernel.org/asahi/175334693659.1935861.13683239351116261977.b4-ty@kernel.org/

#asahilinux

한창 개발중인 다음 버전의 Hackers' Pub입니다. 프런트엔드를 전면 개편하고 있습니다. 프레임워크도 Fresh에서 SolidStart로 아예 바꿨습니다.

각 enum값의 정의와 이것의 번역이 번들에 그대로 박혀들어가는 게 기분이 영 좋진 않구만

Hackers' Pub 전면 개편 준비하며 배우는 Relay. 배울 가치가 있는 기술 같다. 모바일 네이티브 앱 개발에도 Relay가 생겼으면.

I switched from IBus to Kime (https://github.com/Riey/kime — a Korean IME written in Rust 🦀). I can now input Korean flawlessly in Wayland + Niri + Flatpak. #kime #ibus #ko #linux

제가 꾸준히 개발하고 운영하는 서비스들을 소개합니다.

• 나루: 한국의 Geocities/Neocities를 지향하는 개인 웹사이트 호스팅 플랫폼
• 오이카페: 2000년대 인터넷 감성을 느낄 수 있는 오에카키 커뮤니티
• 타이포 블루: 메일링 리스트 기능을 지원하는 텍스트 전용 블로깅 플랫폼

모두 공익을 위한 비영리 프로젝트이며, AGPLv3 하에 소스 코드가 공개되어 있습니다.

@bglbgl gwyng 당장은 안 되는데 논의해볼만한 기능일 것 같아요

@bglbgl gwyng 뭔가 Bunja 생각이....

이거 모든 2-letter code의 조합이 테이블 형태로 나와 있는 게 뻘하게 웃기다

@hongminhee洪 民憙 (Hong Minhee) @bglbgl gwyng @robin 음 근데 또 기본 타입을 type 대신 interface로 만든 다음에 평소에 하시던 대로 만드는 것도 아예 불가능한 선택지는 아닐 것 같긴 한데 Relay GOI 스펙의 회색지대를 건드리는 느낌일 순 있겠네요 ㅋㅋㅋㅋㅋㅋ

@robin @hongminhee洪 民憙 (Hong Minhee) @bglbgl gwyng 요거는 아마 최선이 User - Viewer 나눠서 조회자만 볼 수 있는 필드 모아두듯이 각 권한별로 타입을 나눠서 기본 타입에 서브필드로 넣는 정도가 아닐까 싶어요 🤔 물론 그렇게 하는 게 좋은 방법일지는...... 😅

이와 비슷하게 청개구리 스택 경로라는 것도 생각해 볼 수 있겠다. 예를 들어 Deno를 선택했으면 Fresh는 청개구리 스택 경로가 아니다. 그런데 Deno를 선택한 다음 Next.js를 선택하면 오히려 청개구리 스택 경로가 된다.

여성향 커미션 중개 플랫폼 크레페를 운영하는 쿠키플레이스에서 시니어 백엔드 엔지니어 채용을 진행중입니다. 채용공고에 해당 직무 소개, 복지, 연봉, 회사문화의 내용이 포함돼 있습니다. 많은 관심 부탁드립니다. Node.js, TypeScript, GraphQL에 대한 높은 숙련도 및 지식으로 팀에 기여해주실 분을 쿠키플레이스에서 극진히 기대하고 있습니다.

크레페에서는 이런 기술스택을 사용합니다

• Node.js, TypeScript, Vitest, Fastify
• GraphQL 　- Yoga, Relay, Pothos, Prisma
• ElasticSearch, MongoDB, FCM
• Docker, Github Actions
• AWS 　- ElasticBeanstalk, CloudWatch, Aurora PostgreSQL, Lambda, SES, S3, ElastiCache (Redis)
• Grafana, Sentry

구성원의 성장과 덕질을 지원해요

• 희망 도서 구매 (만화책 및 TRPG 룰북 포함)
• 워크샵 및 교육 프로그램 지원
• 전시, 공연 및 각종 행사 티켓 지원
• 월 5만 크레페 포인트
• 전동작탁 AMOS JP-EX COLOR
• 6인용 TRPG/보드게임 테이블

지원자님이 예상하실 수 있는 처우는 이래요

• 연봉: 최소 8000만원 ~ 최대 2억원 (주 40시간)
• 스톡옵션 부여에 열려있는 포지션

Node.js 커뮤니티는 환경 변수를 너무 좋아하는 것 같다. 거의 라이브러리 API의 일부로 생각하는 듯?

Deno만 해도 환경 변수는 --allow-env 플래그를 통해 명시적으로 허용하지 않으면 접근 못하고, Haskell에서도 getEnv는 String이 아니라 IO String을 반환하게 되어 있다.

반면 Node.js에서는 process.env로 너무 쉽게 접근 가능해서 그런가, 환경 변수 접근이 입출력이라는 생각을 아예 안 하는 모양이다.

다행히도 최신 프리뷰 릴리즈에서 수정된 것 같다

JS Error 클래스에

class Error {
  ...
  throw() {
    throw this
  }
}

이런 메소드 있으면 편할 것 같은데 왜 없지? 예를 들면:

# 현재
const user = findUser();
if (!user) {
  throw new Error("Not found user");
}

# `throw` 메소드
const user = findUser() ?? new Error("Not found user").throw();

이렇게 쓸 수도 있고 이름 별로면 raise 써도 되고 TC39 에 한번 제안해볼까...

Kobalte 이슈를 또 하나 밟았음....... 영 맘에 안 든단 말이지 https://github.com/kobaltedev/kobalte/issues/606

@kodingwarriorJaeyeol Lee 아 이거 Fedify package.json에 exports condition이 import로 되어 있어서 그런 것 같은데 @hongminhee洪 民憙 (Hong Minhee) default로 바꿔야 require(esm)이 돌 것 같네요 👀

Fresh 못 써먹겠는 많은 이유 중 하나: 가끔 빌드 결과가 Chromium 계열 브라우저에서 하이드레이션이 실패하는 형태로 나온다. 골 때리는 건 빌드 자체도 비결정적이라서 똑같은 소스 코드 그대로 다시 빌드하면 해결된다는 것…

@kodingwarriorJaeyeol Lee Node 22부터 require(esm) 지원되는데 그걸로도 안 되나요?

Biome 2.1 has been released!

It's a relatively minor maintenance release, but still has some goodies:
* Faster scanner
* Improved type inference
* New rules
* Many fixes!

https://biomejs.dev/blog/biome-v2-1/

오늘의 Zed 싱글벙글: Inlay Hint에 non-ASCII 텍스트가 있을 경우 Go to Definition하려고 커맨드 누른 채로 커서 올리면 에디터 전체 패닉 남

아는 친구한테 들은 얘기인데, 최근 이직한 회사에서 Python을 쓰는데 린트나 포매터 같은 것도 전혀 설정을 안 해놓고 살고 있기에 도입하자고 했더니 “그런 거 쓸 거면 Python 안 쓰죠”라는 말과 함께 제안을 거절 당했다고 한다. Python에서도 린트나 포매터는 물론이고 타입 체커까지 붙여서 살려면 살 수 있지만, 어쩐지 그런 거 신경 쓸 사람들은 최근 10년 사이에 다들 다른 언어로 넘어가 버리고 그런 거 신경 안 쓰는 사람들만 Python을 계속 쓰게 된 게 아닌가 싶은 생각이 들었다.

@bglbgl gwyng @hongminhee洪 民憙 (Hong Minhee) DSL 정의가 잦거나 좀 많이 유연한 형태로 코드를 작성할 필요가 있는 언어들(Lean/Agda/Coq가 예시로 언급된 걸 본 듯한)은 포매터에 대한 저항이 이해가 가기도 하는데, 요즘은 이런 경우에도 LLM 등을 사용해서 코드 스타일을 최소한의 수준(탭/스페이스 통일, trailing spaces 제거, 괄호 짝 및 인덴트 맞추기 등....)으로는 관리해주면 좋지 않을까 하는 생각을 해본 적이 있습니다 😂

@hongminhee洪 民憙 (Hong Minhee)

그런 거 쓸 거면 Python 안 쓰죠

프로그래밍 언어의 언권?투사가 되게 만드는 발언이군요. 어떤 프로그래밍 언어든 저런 취급을 받아선 안됩니다. 설령 PHP, 아니 Brainfuck이라고 하더라도 린터와 포매터는 갖추고 살아야합니다.

@bglbgl gwyng 성능이 좋고 가볍고 프레임워크 독립적이고 정도가 되겠습니다

• 솔리드 지원 넣기
• 스토어 구현 alien-signals 기반으로 교체하기
• TOE 지원 넣기
• 페이지네이션 지원 넣기
• 기타등등 까보면 할거 훨씬 많을듯

삵 테라포밍할 각을 봐야 하는데

슬프게도 한국의 일정이상 연차 FE 인재들은 두개의 대타트업들이 다 빨아간 것으로 판단이 된다.

@hongminhee洪 民憙 (Hong Minhee) @bglbgl gwyng 네넹 Nushell 내장 커맨드 및 플러그인들은 지정된 프로토콜에 따라 구조화된 데이터를 주고받고, 외부 커맨드(유저 바이너리들) 실행할 땐 stdin/out에 텍스트 형태로 주고받게 되는 건 맞는데 from 커맨드 써서 다시 Nushell 데이터타입으로 파싱할 수도 있습니다

@bglbgl gwyng Nushell을 찾으시나요 😂

@hongminhee洪 民憙 (Hong Minhee) @bglbgl gwyng Deno용 Environment API 플러그인을 깎으면 되지 않을까 싶기도 하네요.... https://vite.dev/guide/api-environment-runtimes.html

deno bundle이 돌아온 건 좋은데, 어째서 Rust로 만든 Rolldown 기반이 아니라 esbuild 기반인 걸까? 🤔

Bytecode Alliance Zulip에 생각보다 재밌는 얘기가 꾸준히 올라오는구만

이전에 다녔던 회사들에서 채용이 무너지면 회사도 무너지는 것들을 몇번 경험해서 채용에 상당히 신중한 편인데, 신중하게 뽑은 분은 역시 모셔오기 어려웠다. 그야말로 양극화의 시대다.

최근 한 달 동안 분석한 이슈의 결론이 물리 세계 때문이라는 결론이 나기 직전입니다. 측정값이 예상보다 오차가 훨씬 크게 날 수 있다 + 랜덤 생성기가 사실 충분히 랜덤이 아니었다의 환장의 콜라보... 모든 것이 예상 가능하게 돌아가는 컴퓨터 세상에서 살고 싶어요... 🤬🤬

I think the @fedifyFedify: ActivityPub server framework project has now reached full maturity. What this means is that all the low-hanging fruit has been addressed, and only the difficult problems remain. 😂

요즘 트위터에 하스켈 관련 계정들보면 Go를 가장 싫어하는 언어로 꼽는 경우를 자주 본다. C/C++/Java 등은 역사적인 맥락을 고려해 예우해주고, Python/JS 등등의 이상한 기능은 뭘 몰라서 잘못 만들었다고 이해해주는 반면, Go는 하스켈러들이 중요하게 여기는 가치들을 일부러 다 무시하고 만들기 때문에 괘씸가중치 x10 정도를 적용받는 듯하다.

잘 못만든 선언형 인터페이스보다는 잘 못만든 명령형 인터페이스가 낫다. 후자는 피똥싸면서 뭔가를 어찌저찌 해낼순 있는데, 전자는 아예 뭔가를 하는게 불가능한 경우가 많다.

Bun이 자꾸 웹 표준 API 사이에 슬쩍 비표준 API 추가하는 게 마음에 안 든다.

Javascript Weekly 뉴스레터에 @hongminhee洪 民憙 (Hong Minhee) 님의 Logtape가 소개되었습니다

나는 리액트에서 성능 자체가 떨어지는 부분보다(제대로 체감한적 없음), 성능을 고려해서 컴포넌트를 일부러 나눠야하는 점이 더 맘에 안든다.

오픈소스 프로젝트에 여러분의 gemini cli(등등)의 무료 사용량을 기여하세요

오픈소스 소프트웨어라는 소프트웨어 개발 방법은 그동안 대성공을 거두어 오고 있습니다. 여기에는 여러 요인이 있지만, 중요한 요인 중 하나는 이것입니다. 상업 소프트웨어든 오픈소스 소프트웨어든 공평하게 프로그래머의 시간을 들인 만큼 개발된다는 것이지요. 능력 있는 소프트웨어 개발자가 시간을 기여하면 오픈소스 소프트웨어는 상업 소프트웨어만큼이나 빠르게 성장할 수 있었습니다.

하지만 AI 프로그래밍의 시대가 빠르게 다가오고 있습니다. 앞으로 소프트웨어 개발은 프로그래머의 시간만으로 개발되지 않습니다. 상업소프트웨어는 AI 프로그래밍을 적극적으로 사용하여 이전과 다른 생산성으로 개발되기 시작할 것입니다. 상업 소프트웨어와 달리 오픈소스 소프트웨어는 언제나 그럴 수는 없습니다. 프로젝트의 성장과 유지를 위해 훌륭한 프로그래머들의 시간을 들이는 것을 넘어서, 훌륭한 프로그래머들이 시간에 더해 비용까지 들여야 한다면요.

상업 소프트웨어와 오픈소스 소프트웨어 사이의 불균등한 생산성의 시대가 코앞까지 다가오고 있습니다.

새로운 기여자 확보의 문제

문제는 여기서 그치지 않습니다. 오픈소스 프로젝트는 새 기여자를 얻기 더 힘들어져가고 있습니다. 왜냐하면 이제 'good first issue'라는 것은 의미가 없기 때문입니다. 그 정도로 쉬운 일은 새로운 기여자 대신 로봇이 해결할 가능성이 높고, 그 로봇은 새로운 기여자의 로봇일 수도 있습니다. 결국 AI 프로그래밍으로 기여하는 새 기여자는 이 프로젝트에 대해 거의 배우지 못하게 됩니다.

전통적인 오픈소스 생태계에서 'good first issue'는 단순히 쉬운 문제를 해결하는 것이 아니었습니다. 새로운 기여자가 프로젝트의 코드베이스를 이해하고, 개발 프로세스를 익히며, 커뮤니티와 소통하는 법을 배우는 학습 과정이었습니다. 하지만 AI가 이런 단순한 작업들을 대신 처리하게 되면, 새로운 기여자들은 진입 기회를 잃게 됩니다.

AI 프로그래밍의 현재 위치

AI 프로그래밍은 완벽하지 않습니다. 숙련된 전문가가 숙련된 도메인에서 작업하는 것만큼 잘하지는 못합니다. 하지만 비숙련된 프로그래머가 처음 보는 프로젝트에서 작업하는 것보다는 잘할 때가 많습니다.

그러나 많은 오픈소스 소프트웨어는 바로 이런 비숙련 기여가 성장의 한 축을 차지합니다. 처음 프로젝트에 참여하는 개발자들의 작은 기여들이 모여 거대한 프로젝트가 됩니다. 그리고 이런 비숙련 기여의 일부는 손쉽게 AI가 대체할 수 있는 기여입니다.

다행히도 지금은 AI 프로그래밍의 초창기입니다. Gemini CLI가 무료 사용량을 제공하듯이, 앞으로 여러 회사들이 비슷한 기회를 제공할 것입니다. Claude, ChatGPT, Copilot 등 다양한 AI 도구들이 개인 사용자에게 무료 크레딧을 제공하고 있습니다.

이것은 오픈소스 프로젝트에 기여할 새로운 기회로 삼을 수 있을까요?

주의: 이 글은 아무 프로젝트에나 방문해서 AI로 적당한 코드를 생성한 다음 패치를 보내라는 뜻이 아닙니다.

AI 프로그래밍은 (아직은) 마법이 아닙니다. "이 프로젝트를 겁나 멋지게 만들 기능을 추가해주세요"라고 한다고 해서 그런 패치가 나오는 식으로는 동작하지 않습니다.

이상적인 경우: AI 친화적 프로젝트

가장 좋은 방법은 프로젝트가 AI 친화적으로 준비되는 것입니다. 바로 작업할 수 있을 만큼 잘 정의된 이슈들이 있는 프로젝트라면, "nnn 번 이슈에 대해 작업해 주세요"라는 요청만으로도 누구나 기여할 수 있을 것입니다.

하지만 (적어도 아직은) 그런 프로젝트가 많지는 않을 것입니다.

현실적인 접근: AI가 잘하는 일들에 집중

대신 AI는 인간과 비대칭적으로 잘하는 기능이 있습니다.

이를테면 이슈에 minimal reproducible case가 보고되어 있지만 아직 구체적으로 발생하는 원인이 밝혀져 있지 않은 경우를 생각해봅시다. 버그를 고치는 사람이 해야하는 지루한 작업 가운데 하나는, 이 문제를 어떻게 수정할지를 생각하기에 앞서 이 문제가 어디서 발생하는지 찾는 것입니다. 디버거를 써야 할 수도 있고, 코드에 많은 trace log를 남겨야 할 수도 있습니다.

하지만 AI 코딩 에이전트는 테스트가 재현 가능하기만 하다면, 문제를 발생시키는 정확한 줄을 찾아내는 데 탁월합니다. 지치지 않고 정석적인 지루한 방법으로 꾸준히 로그를 추가하고 테스트를 다시 실행하면서 문제를 찾아내거든요.

어쩌면 문제의 원인이 아주 단순해서, 문제를 바로 수정할 수 있을지도 모릅니다! 그렇다면 패치를 제출해도 좋겠지요. 하지만 바로 수정하기까지는 어렵더라도 괜찮습니다. 버그 리포트와 실제 코드의 문제를 매핑하는 것은 그 자체로 지루하고 시간이 걸리는 일입니다. 이것을 대신하는 것으로도 큰 작업을 대신하는 것입니다.

주의: 모든 프로젝트가 AI 기여를 환영할 리는 없습니다. 충분히 유용하게 다듬어지지 못한 유형의 AI 기여는 스팸처럼 느껴질 가능성이 있음을 유의해야 합니다.

미래

사실 누구나 자기 라이브러리를 뚝딱 만들어낼 수 있게 되었다는 점에서 오픈소스 프로젝트에 참여하는 사람들의 동기와 기여 방식 자체가 크게 뒤바뀔 가능성이 높습니다.

AI 프로그래밍을 누구나 거의 무료로 사용할 수 있는 시대가 올까요? 아마 어느 정도의 사용량까지는 그럴 것입니다. 그것이 얼마나 많은 양일지에 따라서 오픈소스 프로젝트의 미래는 크게 바뀌겠지요.

만일 정말로 AI 프로그래밍을 누구나 무제한적으로 사용할 수 있다면, 대규모가 아닌 대부분의 오픈소스 프로젝트에는 더이상 협력이 필요하지 않을 것입니다. 진정으로 '어떻게'보다 '무엇을'이 더 중요한 시대가 온다면, 프로젝트의 목표를 확고하게 가진 사람이 극한의 완성도까지 프로젝트를 밀어붙이는 편이 훨씬 좋은 결과를 만들겠지요.

그런 시대가 올지 오지 않을지 모르겠습니다. 하지만 그 전까지는, AI 프로그래밍이 누구에게나 주어지는 기회이지만 프로젝트를 단숨에 완성할만큼 주어지지는 않는 시대가 유지되는 동안에는, 다음 세대의 오픈소스 기여의 방법은 AI 프로그래밍 사용량을 기여하는 것이 하나의 큰 축이 될 것입니다.

클플 뭐 서비스 낼때마다 리전 맨날 Earth 요따구로 해두니까 우주진출 뒤의 클플을 상상하게 됨