참고로 전면 개편 중인 Hackers' Pub 프런트엔드도 SolidStart 기반입니다!
XiNiHa
@xiniha@hackers.pub · 91 following · 116 followers
GitHub
- @XiNiHa
Bluesky
- @xiniha.dev
Twitter
- @xiniha_1e88df
Hackers' Pub의 로고 디자인이 완료되었습니다! 디자인은 박은지 님(@murinono무리노노)께서 해주셨습니다.
연합우주라는 콘셉트에 맞게 고양이의 입 주변을 별 모양으로, 목 아래에도 고리(orbital ring) 모양으로 디자인했습니다. 고양이를 고른 이유는 소프트웨어 프로그래머 커뮤니티에서 다른 동물보다 유독 고양이가 사랑 받기 때문이기도 하고, 고양이가 호기심이 강하기 때문이기도 합니다.
로고 디자인은 CC-BY-SA 4.0 라이선스로 배포됩니다.
XiNiHa shared the below article:
프론트엔드 애플리케이션 상태를 다루는 법
ㄹ @disjukr@hackers.pub
이 글은 리액티브 프로그래밍에서 시간의 흐름에 따른 의존 그래프 관리를 설명하며, 특히 프론트엔드 상태 관리에 있어 옵저버블보다 시그널이 더 적합한 이유를 제시합니다. 저자는 프론트엔드 상태가 시간에 따라 결정적으로 변하지 않고, 노드의 의존 관계가 렌더 트리에 따라 변화무쌍하게 바뀌기 때문이라고 주장합니다. Rx, Redux, XState와 같은 기존 상태 관리 방식의 한계를 지적하며, 시그널(+ DI와 수명관리)을 중심으로 옵저버블, 리듀서, 스테이트머신을 함께 사용하는 것이 각 기술의 장점을 극대화할 수 있다고 설명합니다. 애니메이션, 폼 관리, NPC 인공지능과 같이 특정 상황에 적합한 기술을 시그널로 묶어 전체 애플리케이션 상태를 선언적으로 관리하는 방법을 제안하며, 이를 통해 애플리케이션의 구조를 더욱 명확하고 효율적으로 만들 수 있다고 강조합니다.
Read more →XiNiHa shared the below article:
커뮤니케이션 지점은 도로위 신호등 같은 거다
ㄹ @disjukr@hackers.pub
커뮤니케이션 비용을 간과하는 사람들은 소통에 직접 소요되는 시간만을 고려하지만, 실제로는 그 이상의 숨겨진 비용이 발생합니다. 커뮤니케이션 지점은 마치 도로 위의 신호등과 같아서, 잦은 소통은 불필요한 지연을 초래합니다. 회신 지연, 컨텍스트 스위칭 등 다양한 요인들이 쌓여 업무 속도를 늦추는 주범이 됩니다. 이러한 커뮤니케이션 비용을 줄이는 가장 효과적인 방법은 문제 해결에 필요한 수단을 제공하여 불필요한 소통 자체를 줄이는 것입니다. 문제 해결 수단을 만드는 비용이 커뮤니케이션 비용보다 크다고 생각하는 것은 오산일 수 있으며, 장기적으로 볼 때 문제 해결 능력을 키우는 것이 훨씬 효율적입니다.
Read more →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/
한창 개발중인 다음 버전의 Hackers' Pub입니다. 프런트엔드를 전면 개편하고 있습니다. 프레임워크도 Fresh에서 SolidStart로 아예 바꿨습니다.
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
XiNiHa shared the below article:
Upyo 0.2.0 Release Notes
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Upyo 0.2.0 has been released, introducing new features to this cross-runtime email library that supports Node.js, Deno, Bun, and edge functions. The latest version expands its capabilities with Amazon SES transport support, enabling AWS Signature v4 authentication and session-based authentication. Additionally, comprehensive OpenTelemetry integration has been added, offering distributed tracing, metrics collection, and error classification without altering existing code. The OpenTelemetry transport automatically instruments email operations, tracking delivery rates and latency, and integrates with existing OpenTelemetry infrastructure. Community feedback is encouraged to further improve Upyo, whether through testing the new Amazon SES transport, implementing OpenTelemetry, or contributing to the GitHub repository. This release enhances Upyo's utility by providing more transport options and robust observability features, making it a valuable tool for developers needing reliable email sending across various environments.
Read more →이와 비슷하게 청개구리 스택 경로라는 것도 생각해 볼 수 있겠다. 예를 들어 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시간)
- 스톡옵션 부여에 열려있는 포지션
XiNiHa shared the below article:
힙스택 보존 법칙
RanolP @ranolp@hackers.pub
이 글에서는 프로젝트 진행 시 기술 스택 선정에 대한 경험적 법칙인 "힙스택 보존 법칙"을 소개하며, 힙한 기술 스택을 과도하게 선택할 경우 프로젝트가 산으로 갈 수 있음을 경고합니다. 저자는 신기술 도입 시 발생하는 호환성 문제와 그로 인한 추가 작업의 부담을 설명하며, 커뮤니티가 크고 성숙한 기술의 중요성을 강조합니다. 힙한 기술을 사용하더라도 프로젝트를 성공적으로 이끌 수 있는 두 가지 조건, 즉 기술의 안정성과 개발자의 숙련도를 제시하며, 힙스택을 사용하기 전에 충분한 학습과 경험을 통해 기술적 내성을 길러야 함을 역설합니다. 이 글은 기술 스택 선택의 중요성과 개발자의 역량 강화 필요성을 동시에 강조하며, 균형 잡힌 기술 스택 선택이 프로젝트 성공에 미치는 영향을 시사합니다.
Read more →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 에 한번 제안해볼까...
Fresh 못 써먹겠는 많은 이유 중 하나: 가끔 빌드 결과가 Chromium 계열 브라우저에서 하이드레이션이 실패하는 형태로 나온다. 골 때리는 건 빌드 자체도 비결정적이라서 똑같은 소스 코드 그대로 다시 빌드하면 해결된다는 것…
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!
아는 친구한테 들은 얘기인데, 최근 이직한 회사에서 Python을 쓰는데 린트나 포매터 같은 것도 전혀 설정을 안 해놓고 살고 있기에 도입하자고 했더니 “그런 거 쓸 거면 Python 안 쓰죠”라는 말과 함께 제안을 거절 당했다고 한다. Python에서도 린트나 포매터는 물론이고 타입 체커까지 붙여서 살려면 살 수 있지만, 어쩐지 그런 거 신경 쓸 사람들은 최근 10년 사이에 다들 다른 언어로 넘어가 버리고 그런 거 신경 안 쓰는 사람들만 Python을 계속 쓰게 된 게 아닌가 싶은 생각이 들었다.
아는 친구한테 들은 얘기인데, 최근 이직한 회사에서 Python을 쓰는데 린트나 포매터 같은 것도 전혀 설정을 안 해놓고 살고 있기에 도입하자고 했더니 “그런 거 쓸 거면 Python 안 쓰죠”라는 말과 함께 제안을 거절 당했다고 한다. Python에서도 린트나 포매터는 물론이고 타입 체커까지 붙여서 살려면 살 수 있지만, 어쩐지 그런 거 신경 쓸 사람들은 최근 10년 사이에 다들 다른 언어로 넘어가 버리고 그런 거 신경 안 쓰는 사람들만 Python을 계속 쓰게 된 게 아닌가 싶은 생각이 들었다.
그런 거 쓸 거면 Python 안 쓰죠
프로그래밍 언어의 언권?투사가 되게 만드는 발언이군요. 어떤 프로그래밍 언어든 저런 취급을 받아선 안됩니다. 설령 PHP, 아니 Brainfuck이라고 하더라도 린터와 포매터는 갖추고 살아야합니다.
XiNiHa shared the below article:
청개구리 스택 찬가
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
이 글은 저자가 기술 스택을 선택할 때 주류를 따르지 않고 대안적인 기술을 선택하는 경향, 즉 "청개구리 스택"을 추구하는 경험을 공유합니다. 청개구리 스택은 사용자가 적어 문제 해결에 어려움이 있을 수 있지만, 기술에 대한 깊이 있는 이해와 오픈 소스 기여 기회를 제공합니다. 또한, 후발주자로서 대안적인 설계를 통해 정석 스택보다 나은 이해를 제공할 수 있습니다. 여러 부품을 직접 조립하는 과정은 번거롭지만 각 기술에 대한 깊은 이해를 얻을 수 있게 합니다. 저자는 오늘의 정석 스택도 과거에는 청개구리 스택이었을 수 있음을 지적하며, LLM 시대에도 청개구리 스택이 주는 배움의 기회는 여전할 것이라고 주장합니다. Stack Overflow에 답이 없는 길을 걸으며 얻는 깨달음은 온전히 자신의 것이 될 것이라는 메시지를 전달하며, 독자들에게도 주체적인 기술 선택과 도전을 권장합니다.
Read more →XiNiHa shared the below article:
내가 지금 바이브코딩을 하고 싶어도 못하는 상황이라 답답한데
bgl gwyng @bgl@hackers.pub
이 글은 앱 개발 과정에서 프론트엔드, 백엔드, 그리고 라이브러리 개발에 AI를 활용하는 경험과 고민을 담고 있습니다. 특히, 간단한 CRUD 작업은 이미 자동화가 가능하지만, 복잡한 mutation 개발에는 테스트 환경 구축이 선행되어야 AI의 도움을 효과적으로 받을 수 있음을 강조합니다. 또한, 라이브러리 개발 자동화의 잠재적 위험성을 지적하며, 이는 코드의 '축적'이라는 특성상 현재 AI 수준으로는 어렵다고 분석합니다. 궁극적으로, 코드 에이전트 사업의 미래와 협업을 통한 코드 축적의 중요성을 역설하며, Gen AI를 넘어선 Zen AI의 필요성을 제기합니다. 이 글은 AI 개발 도구의 현황과 한계를 현실적으로 진단하고, 미래 개발 환경에 대한 깊이 있는 통찰을 제공합니다.
Read more →슬프게도 한국의 일정이상 연차 FE 인재들은 두개의 대타트업들이 다 빨아간 것으로 판단이 된다.
deno bundle이 돌아온 건 좋은데, 어째서 Rust로 만든 Rolldown 기반이 아니라 esbuild 기반인 걸까? 🤔
이전에 다녔던 회사들에서 채용이 무너지면 회사도 무너지는 것들을 몇번 경험해서 채용에 상당히 신중한 편인데, 신중하게 뽑은 분은 역시 모셔오기 어려웠다. 그야말로 양극화의 시대다.
최근 한 달 동안 분석한 이슈의 결론이 물리 세계 때문이라는 결론이 나기 직전입니다. 측정값이 예상보다 오차가 훨씬 크게 날 수 있다 + 랜덤 생성기가 사실 충분히 랜덤이 아니었다의 환장의 콜라보... 모든 것이 예상 가능하게 돌아가는 컴퓨터 세상에서 살고 싶어요... 🤬🤬
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 요따구로 해두니까 우주진출 뒤의 클플을 상상하게 됨
XiNiHa shared the below article:
How to pass the invisible
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
This post explores the enduring challenge in software programming of how to pass invisible contextual information, such as loggers or request contexts, through applications without cumbersome explicit parameter passing. It examines various approaches throughout history, including dynamic scoping, aspect-oriented programming (AOP), context variables, monads, and effect systems. Each method offers a unique solution, from the simplicity of dynamic scoping in early Lisp to the modularity of AOP and the type-safe encoding of effects in modern functional programming. The post highlights the trade-offs of each approach, such as the unpredictability of dynamic scoping or the complexity of monad transformers. It also touches on how context variables are used in modern asynchronous and parallel programming, as well as in UI frameworks like React. The author concludes by noting that the art of passing the invisible is an eternal theme in software programming, and this post provides valuable insights into the evolution and future directions of this critical aspect of software architecture.
Read more →Phew! That's it for the merge train: this ended up being a fuller day than I was hoping for. Don't stay up until 2 am kids. At least, not if you're Old™.
Anyways, I'm feeling really pleased about the progress on a lot of controversial features today, between the merge train and the meeting!
#bevy 0.17 is shaping up to be a really exciting release: hot patching, widgets, observers, tilemaps, light textures, transform overhaul... :) Community-driven open source is really wild like that: folks just come along and upset all your plans. Mostly for the better even!
회사에서 AI 도입 드라이브가 강한데 솔직히 하나만 했으면 좋겠다는 생각이 든다. 기존의 방식으로 일하는 것을 그만두든지 AI를 신경쓰지 말든지. 두개를 애매하게 다 하려니까 가랑이가 찢어진다.
실제로 Hackers' Pub은 Mac mini M4 깡통에서 돌아가는데, 아직 Asahi Linux가 M4를 지원 안 해서 macOS 안에 컨테이너 띄워서 돌리고 있어요. Asahi Linux가 M4 지원할 때까지 숨 참고 기다리는 중입니다…
XiNiHa shared the below article:
If you're building a JavaScript library and need logging, you'll probably love LogTape
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
LogTape offers a novel approach to logging in JavaScript libraries, designed to provide diagnostic capabilities without imposing choices on users. Unlike traditional methods such as using debug packages or custom logging systems, LogTape operates on a "library-first design" where logging is transparent and only activated when configured. This eliminates the fragmentation problem of managing multiple logging systems across different libraries. With zero dependencies and support for both ESM and CommonJS, LogTape ensures minimal impact on users' projects, avoiding dependency conflicts and enabling tree shaking. Its universal runtime support and efficient performance make it suitable for various environments. By using a hierarchical category system, LogTape prevents namespace collisions, offering a seamless developer experience with TypeScript support and structured logging patterns. LogTape provides adapters for popular logging libraries like Winston and Pino, bridging the transition for users invested in other systems. Ultimately, LogTape offers a way to enhance library capabilities while respecting users' preferences and existing choices, making it a valuable consideration for library authors.
Read more →XiNiHa shared the below article:
Announcing LogTape 1.0.0
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
LogTape 1.0.0 has been released, marking a significant milestone for this zero-dependency logging library designed for the modern JavaScript ecosystem. This release emphasizes API stability and introduces high-performance features such as non-blocking sinks for console, stream, and file logging, along with the `fromAsyncSink()` function for integrating asynchronous logging operations. New sink integrations include packages for AWS CloudWatch Logs and Windows Event Log, enhancing LogTape's versatility. The update also brings a visually appealing console logging experience with the `@logtape/pretty` package, and seamless integration with existing Winston or Pino setups through adapter packages. Key developer experience enhancements include programmatic access to log levels and improved browser compatibility. LogTape 1.0.0 streamlines logging infrastructure with a comprehensive package ecosystem, offering specialized packages for various logging needs. This release provides a stable and mature logging solution, making it easier to manage and optimize logging in JavaScript applications.
Read more →LogTape 1.0.0 출시 발표
LogTape 1.0.0이 출시되었습니다. 이 로깅 라이브러리는 현대적인 JavaScript 생태계를 위해 설계되었으며, 의존성이 없고 Node.js, Deno, Bun, 브라우저, 엣지 함수 등 다양한 런타임을 지원합니다. LogTape는 라이브러리 우선 설계를 통해 라이브러리 작성자가 사용자에게 부담을 주지 않고 로깅 기능을 추가할 수 있도록 합니다. 이번 릴리스에서는 고성능 로깅 인프라를 위한 비동기 싱크 옵션, AWS CloudWatch Logs 및 Windows Event Log와의 통합, 그리고 개발 경험을 향상시키는 예쁜 콘솔 로깅 기능이 추가되었습니다. 또한, 기존 Winston 및 Pino 로깅 시스템과의 원활한 통합을 위한 어댑터 패키지를 제공하여 LogTape를 사용하는 라이브러리를 쉽게 통합할 수 있도록 지원합니다. LogTape 1.0.0은 안정성과 성숙도를 제공하며, 다양한 로깅 요구 사항을 충족시키는 포괄적인 패키지 생태계를 구축했습니다.
hackers.pub · Hackers' Pub
Link author:
洪 民憙 (Hong Minhee)@hongminhee@hackers.pub
Nginx의 njs에 QuickJS 엔진 추가되니 기능이나 문법 제약도 거의 없어서 출근해서 해볼 성능 테스트만 제대로 되면 좀 복잡한 로직 필요한 리버스 프록시는 이걸로만 짤거같음. JS모듈들 대충 번들로 만들고 import해서 다 쓸수 있어서...
언어 구현을 하는 데에 최고의 언어는 뭘까... 예전엔 OCaml이라고 생각했었고 요즘은 Scala가 최고라고 생각하고 있기는 한데, 더 나은 대안 언어는 없을까? 탈JVM이 하고 싶다 (그렇다고 Scala Native는 아닙니다 진짜...)
LogTape 0.12.0을 불과 일주일 전에 릴리스했는데, 일주일 만에 또 LogTape 1.0.0 릴리스하기가 좀 뻘쭘하네… 삘 받아서 요 며칠 동안 LogTape 작업만 했더니만.
Zed는 아직 쓰지도 않는데도 요즘 보기드문 장인정신이 느껴지는 소프트웨어라 호감이 간다. 지금 쓰고있는 Windsurf는 VS Code 포크떠서 AI 채팅만 추가했는데 하루에 3번 터져서 에디터를 재시작해야한다(AI 채팅 패널이 터지는거라 VS Code가 아닌 Windsurf 문제로 보임). 5조 투자받은건 어따썼니??
LogTape 다음 버전부터는 널리 쓰이는 로깅 라이브러리인 Pino와 winston에 대한 어댑터를 함께 제공할 예정입니다.
With this latest PR, inference for `noFloatingPromises` is pushed to over 80% success rate in Vercel's repositories: https://github.com/biomejs/biome/pull/6404
While I targeted specific patterns used by their own `swr` library, all the fixes are generically applicable, meaning other code benefits too.
Do you want to use Biome's `noFloatingPromises`, but need support for some library that is important to you? Reach out to us and we can make it happen: https://biomejs.dev/enterprise/
🚀MoonBit Beta is here!
After 2 years of fast iteration, MoonBit enters its stable phase with regard to language syntax!
✨Built-in async
🛠 Fast tooling and IDE-aware error handling





