Profile img

Jaeyeol Lee

@kodingwarrior@hackers.pub · 694 following · 509 followers

Neovim Super villain. 풀스택 엔지니어 내지는 프로덕트 엔지니어라고 스스로를 소개하지만 사실상 잡부를 담당하는 사람. CLI 도구를 만드는 것에 관심이 많습니다.

Hackers' Pub에서는 자발적으로 바이럴을 담당하고 있는 사람. Hackers' Pub의 무궁무진한 발전 가능성을 믿습니다.

그 외에도 개발자 커뮤니티 생태계에 다양한 시도들을 합니다. 지금은 https://vim.kr / https://fedidev.kr 디스코드 운영 중

Blog
kodingwarrior.github.io
mastodon
@kodingwarrior@silicon.moe
Github
@malkoG

흐름에 탑승해봅니다.

  • Hackers' Pub 개발에 조금은 기여를 했습니다. 아마도 앞으로도...
  • VisualBasic으로 프로그래밍을 시작해서 지금은 SoftwareEngineer 로 벌어먹고 살고 있습니다.
  • iOS 앱, 웹, Office문서의 HTML변환기, 모바일 게임, HTML5 게임, HFT 등 코드를 작성했다 말고는 공통점을 모르겠는 커리어를 쌓아(?)왔어요.
  • Emacs사용자였으나 이제는 그냥 VS Code를 쓰고 있어요.
  • 요즘 쓰는 언어는 Rust, Typescript, Power shell, C++, Python 정도인 것 같네요. 마지막 2개는 별로 쓰고 싶지는 않은데 어쩔 수 없이...
  • 한동안은 HomeAssistant에 zigbee 장치 세팅하느라 quirks 코드를 좀 작성 했지만 이제는 일단 다 돌아가서 손 놨네요. 정리해서 이것도 기여 해야하는데...
  • 요즘에는 macOS에서 실행되는 RDP서버 와 캘린더 일정 생성을 위한 크롤링 시스템(예전에 만든 같은 목적의 프로젝트에서 유지보수를 고려해서 새로 개발) 같은 것을 만들고 있어요
  • 맥미니 한대 들여서 로컬 LLM도 조금 건드려보다 말았네요.

잘부탁드립니다

12

수학 전공자로서, 한때는 프로그래머에게 수학이 왜 필요한지, 얼마나 중요한지 같은걸 열심히 설파하려던 적이 있었는데요, 그 흔적이 이런 영상들인데 https://youtu.be/ND2gJVxZUaM?si=RsvrjsgYWeFCJMUT 지금 와서는 (수학을 제가 다 까먹었기도 했고) 그런 실용적인 목적보다는, 그냥 ‘재밌으니까’ 다들 공부했으면 좋겠다는 생각입니다. 이는 수학 뿐만 아니라 뭐든지, 뭘 알아야한다/알아야하냐 같은 얘기보다 ‘재밌으니까’가 먼저 오는 환경을 생각합니다. 너무 이상적이긴 하지만요.

8
0
0

  • 어렸을 때 엑셀에 딸려 있는 VBA를 만지면서 개발을 시작했어요.

  • 고등학생 때 Scheme을 배우면서 우연찮게 리습의 마력에 빠져들었어요.

  • 백엔드는 Django로 시작했는데 업무에서는 어쩌다 보니 Spring을 쓰게 되었어요.

  • 그리고 어쩌다 보니 SwiftUI를 다루게 되었어요.

  • 지금은 포폴 추가할 겸 Rust와 SwiftUI를 되새길 겸 단어 암기 앱을 기획하고 있어요.

뭐 인생은 어쩌다 보니가 주는 매력이 있지 않겠습니까 어쩄든 잘 부탁드립니다

5

새로 오신 분들도 많이 계시니, 한 번 해 볼까요? 저부터 해보겠습니다.

  • Hackers' Pub을 만들고 운영하고 있습니다. (Hackers' Pub은 저희 집 홈 서버에서 돌아가고 있습니다… 😂)
  • 연합우주(fediverse)와 ActivityPub에 관심이 많고, 또 관련된 소프트웨어(@fedifyFedify: ActivityPub server framework, @holloHollo :hollo:, @botkitBotKit by Fedify :botkit:, Hackers' Pub…)를 만듭니다.
  • 좋아하는 언어는 Haskell인데 자주 쓰는 언어는 TypeScript입니다. 예전에는 Python을 좋아하고 자주 썼습니다.
  • 함수형 프로그래밍을 좋아합니다만, 좋아하는 만큼 잘 다루는지는 잘 모르겠습니다.
  • 옛날에는 덕 타이핑 언어를 좋아했는데, 나이가 들고 협업을 많이 하게 되면서 정적 타이핑 언어를 선호하게 되었습니다. 그래도 여전히 덕 타이핑 언어가 제공하는 특별한 생산성이 있다고 생각합니다.
  • 자유 소프트웨어와 오픈 소스를 좋아합니다. GPL을 좋아하지만, 트랜스젠더 배제적인 행보를 보인 적 있는 자유 소프트웨어 재단이나 여러 성추행 전적이 있는 Richard Stallman은 좋아하지 않습니다.
  • 소프트웨어 문서화에도 관심이 많습니다. 문서화가 소프트웨어 개발의 중요한 부분이라고 생각합니다. 문서화 도구들에도 관심이 많습니다.
  • 원래는 백엔드 개발자였는데 바로 전 직장이 블록체인 회사여서 백엔드 개발에서 손을 놓은 지 좀 되니까 이제는 잘 모르게 됐습니다. 재활이 필요합니다.
  • 현재는 일 안 하고 쉬고 있습니다.
  • 30대 후반, 기혼, 자녀는 없습니다. 서울에서 살고 있습니다.

아무쪼록 잘 부탁드립니다.

17
0
0

지금은 개발자가 아니지만 조금 추억 회상 겸 를 해보자면, 저는

  1. 중학교때 게임 개발로 프로그래밍 입문을 하고
  2. 고등학교때는 정보 올림피아드를 하다가
  3. 학부때 갑자기 수학을 전공 하다가
  4. 스타트업에선 웹 프론트엔드를 위주로 하다가
  5. 쟝고 장인이 되겠다며 백엔드를 파다가
  6. 갑자기 대학원에 가서 한국어 NLP를 하다가 (이때 ‘세줄요약기’와 챗봇 ‘하우하우’를 만들었습니다)
  7. 패션 연구에 끌려가서 한참 비전을 연구하다가 (style2vec, iTOO를 만들었습니다)
  8. 운 좋게 붙은 추천 논문을 시작으로, 추천 연구를 계속 해서 일단 박사를 받았는데
  9. 포닥 하러 와서는 또 XAI를 연구중입니다.

저는 이런걸 ‘다재무능’이라고 농담식으로 말하곤 하는데요, 실제로 저는 이제 소프트웨어 개발은 거의 못하고 그나마 자신 있는 분야도 박사 받은 분야 뿐이지만, 그래도 코딩하는것 자체는 무척 좋아했기에 미련이 남아서 해커스펍에도 오게 되었네요.

요컨대, 생각보다는 미래에 자신이 뭘 하고 있을지 예측하는건 어렵고, 이렇게 표류하듯 사는 사람도 많은것 같습니다.

8

탐라보다가 들켜버렸네요! 오랜만에 할 기회가 생겼습니다:)

  • 저도 해커스펍을 만드는 사람은 아니고, @kodingwarriorJaeyeol Lee 님께서 초대해주셔서 눌러 앉은뒤로 종종 트위터에서 잘 올리지 않는 이야기들을 여기서 하곤 해요.
  • 일단 대학원에서 PL 전공을하고 있는데요. 동료와 지인들에게서 딥한 타입 이론들을 듣는 것도 때로는 좋아하지만, 정적분석과 퍼징 같은 실용적인 프로그램 분석 기술에 더 관심이 많아요. JavaScript 생태계의 이런저런 툴체인들과 스펙 자체를 뜯어보고 기여하고 있습니다.
  • 좋아하는 언어는 Scala이고 연구할 때 주로 씁니다. 툴링이 좀 별로지만 정말 좋은 언어라고 생각해요. 그 외에도 TypeScript나 Golang, OCaml, Rust 가리지 않고 씁니다.
  • 함수형 언어... 이것저것 써본 적도 있고 관심도 가져왔지만 Scala가 제일 손에 익네요. Haskell에 늘 부채감을 느끼고 있습니다.
  • 이런저런 기술들에 관심이 많지만 그 모든 것을 follow-up할 여력은 되지 못해 늘 아쉽습니다. 무언가를 혼자서 알아가는 시간도 즐겁지만, 사람과의 교류를 통해 새로운 것을 알아가는 것을 즐깁니다. 기술 외적인 부분에서도요! 최근에는 커피 생두를 가공하고 변인 통제를 하는 것에 대한 이야기를 들었는데 정말 재밌었어요.
  • 에디터는 @xiniha 님의 추천이 첫 계기였던 것 같은데, 주로 Zed를 씁니다. 가볍고 빠르고 vim 키 바인딩도 익숙해지면 편하구요. 만족하고 있습니다.
  • 20대 중반...이네요. 분명 대학생이었는데 말이죠... 서울에서 살고 있는 시스헤테로남성입니다.
  • 사실 해시 거는 거 까먹어서 다시 작성했어요...

잘 부탁드릴게요

6

@kodingwarriorJaeyeol Lee 님에게 들킨 김에 써보는

  • 퍼리입니다. 언젠간 해커스 펍을 털로 뒤덮으려는 아름다운 마음을 품고 있습니다.
  • 재작년 부터 web3 쪽으로 전향했고 주로 코어 쪽을 건들고 있습니다. 하지만 여전히 블록체인은 잘 모릅니다.
  • 언어 만드는걸 좋아하고 관련 프로젝트들에 기여를 하고 있습니다
  • 좋아하는 언어는 러스트와 OCaml인데 안 쓴지 오래되서 조만간 까먹을거 같네요
  • 파서나 상태머신, 정적분석을 좋아합니다. - 관련해서 요즘은 개발하고 있는 언어에 린터를 만들고 있습니다
  • 활자 중독입니다. 해커스펍은 읽을게 많아 좋네요. 책은 주로 철학이나 건축 쪽을 읽고 있습니다.
  • 의외로 백엔드나 프론트엔드를 해본적이 없어서 항상 애매한 포지션에 있는 것 같습니다.
  • 밴드활동도 하고 있습니다. 원래 대충 모여서 술마시는 것에 의의를 뒀었는데 올해는 공연 뛸 일이 많아졌네요.
  • 20대 중반이고 서울에서 거주 중입니다

여러모로 잘 부탁드립니다. 추가로 깃헙 프로필은 https://github.com/notJoon입니다.

낫준 배상

9
1
0

이메일 주소가 깔끔한 사람을 보면 좋은 느낌이 듭니다.
자기 이름을 영어로 혹은 짧고 읽기 쉬운 닉네임으로 만든 이메일들.

가장 인상적이었던 이메일은 r@google.com 이었습니다.
UTF-8과 GO 언어를 만든 롭 파이크.
그가 구글에 들어갈 때 선택한 이메일.
한 글자 이메일 주소라니. 센스 터지는 군.

한편으로 한글 이름을 영어로 rlawogh(김재호) 하거나,
숫자가 들어간 이메일을(rlawogh777) 보면 좋은 느낌이 들지 않습니다.

깔끔한 이메일을 보면 이 사람은 신중하고 좋은 결정을 하는 사람이라는 생각이 듭니다.
이런 생각은 편견일 수 있다는 걸 알면서도... 이 편견에서 빠져나오기가 힘드네요.😁

4

안녕하세요, 페미위키 개발팀입니다. 개발팀 활성화를 위해 이리저리 둘러보다 해커스펍에 대해 알게 되었습니다. 여건이 되면 페미위키 개발에 대해서 얘기할 수 있는 기회를 만들어보려 합니다!

더불어 페미위키 개발팀에서 오픈소스 컨트리뷰터 & 개발팀을 모집합니다! 페미니스트시라면 정체성 불문, 거주국 불문하고 모시고 있습니다. 함께 페미니즘 정보집합체 만들어가요!

페미위키 오픈소스 컨트리뷰터 & 개발팀 모집1. 우대 사항:

페미위키 편집 경험이 한 번 이상 있으신 분
AWS 경험이 필요하신 분
사실상 표준이 아닌 기술/서비스에 거부감이 덜 하신 분 (예: Vue.js, Less.js, GitLab, Nomad, PHP)
기억 나는 리눅스 명령어가 세 개 이상인 분
ARM 서버 운영 경험이 있으신 분
JS를 TS로 변환하면 개운하신 분
GitHub Actions 사용 경험이 있으신 분
PHP 문법을 기억하시는 분
git rebase를 쳐본 적 있으신 분
오픈소스를 사랑하시는 분2. 업무 내용

신규 프로젝트
* 레벨 제도
* 프로필 페이지
* 게이미피케이션 / 도전과제
* HA 구성

상시 업무
* 서비스 모니터링
* 버그 수정
* 기술 지원
* 소프트웨어 업그레이드관심 있다면 망설임 없이 https://github.com/femiwiki 접속!
8
0
1

Exciting news for the project! We're thrilled to announce that Emelia Smith (@thisismissemEmelia 👸🏻) has joined as a co-maintainer alongside Hong Minhee (@hongminhee洪 民憙 (Hong Minhee) :nonbinary:).

Emelia brings extensive experience in the ecosystem, having been a long-time contributor to Mastodon and a leading expert in trust & safety tooling for decentralized social networks. She's dedicated years to improving moderation systems and security across platforms.

Her recent contributions to Hollo have been substantial—implementing the reporting/flagging system and making significant improvements to OAuth and security features. These valuable contributions naturally led to her joining as a co-maintainer.

This collaboration marks an important milestone for Hollo as we continue building better single-user microblogging software for the fediverse. Welcome aboard, Emelia! 🚀

8
3
0
0
0
1

Node.js 개발자라면 꼭 읽어봤으면 하는 아티클 2선

일반적인 Node.js 애플리케이션을 개발할 때 프레임워크와 무관하게 함께 일하는 동료들에게 필수적으로 추천하고 싶은 아티클이 있다.

빠르고 유지보수 가능한 데이터베이스 패턴들

https://sophiebits.com/2020/01/01/fast-maintainable-db-patterns

특정 프레임워크나 ORM에 의존하지 않고도 N+1 Query, 캐싱 같은 일반적인 문제를 해결하며 유지보수 가능한 형태로 코딩하는 방법을 제시한다. DataLoader로 모든 문제가 해결된다고 생각할 수도 있지만, 근본적인 문제 해결 과정을 직접 고민해보는 것만으로도 엔지니어링 역량 향상에 큰 도움이 된다.

Next.js에서 보안을 고려하는 방법

https://nextjs.org/blog/security-nextjs-server-components-actions

React 관련 내용이 포함되어 있지만, 그 부분을 제외하고 읽어도 충분히 가치가 있다. 데이터를 클라이언트에 전달할 때 마스킹하거나 접근 권한을 검사하는 방법을 구체적으로 알려준다. 핵심은 별도의 플러그인이나 외부 시스템 없이도 간단하면서 효과적인 권한 검사 시스템을 구축할 수 있다는 점이다.

마무리

위 아티클들을 추천하는 이유는 간단하다. 특정 프레임워크에 결속되지 않으면서도 독립적이고 지역적으로 백엔드 애플리케이션에서 볼 수 있는 일반적인 문제를 해결할 수 있는 방법들을 제시하기 때문이다. 이런 접근법은 전체 코드베이스의 안전성과 성능을 크게 향상시키며, 결국 더 많은 개발자들이 행복하게 일할 수 있는 환경을 만들어준다고 생각한다.

대부분 프레임워크에 의존적이거나 플러그인에 의존해 전체 코드베이스를 올바르게 수정하기 어려워지는 모습을 여러번 보았다. 개인적으로 엔지니어링 문화에서 크게 해결하고 싶은 부분이다. JavaScript 뿐만 아니라 가능하면 언어나 런타임에 있는 근원적 요소만을 통해 문제를 해결하는게 건강하게 문제를 해결할 수 있는 방법이라고 본다.

6

vim을 쓸 사람은 다른 에디터를 써도 vim 모드를 쓰거나 만들거나 해서 어떻게든 vim처럼 쓰려고 하지만 결국 부족함을 느끼고 vim이나 neovim으로 돌아간다는 그런

3

한국 페디버스 개발자 모임에서 주최한 스프린트에 다녀왔다. 기여하고자 했던 github.com/fedify-dev/fedify/i 는 또 JSON-ish 관련 이슈로 해결하지 못했지만 소규모 모임에서 얻을 수 있는 좋은 분위기와 에너지를 맘껏 느껴 좋았다. PR은 보내지 못했지만 Fedify 마스코트(이름 없음)로 키링 만들어 나눠드려 그나마 다행이었다. 행사 준비하고 진행해준 @hongminhee洪 民憙 (Hong Minhee) 님께 감사드린다.

페디버스 행사가 있는 날에 하필 트위터 서비스가 고장나서 오랜만에 마스토돈에 글 남겨본다 ㅋㅋ

페디파이 마스코트로 만든 키링맥북도 오랜만 코딩도 오랜만 스프린트도 오랜만지하철 2호선 타고 성수로 넘어가며 본 풍경이 상쾌했다.
5

다른 페디버스 서버에서 온 메시지라 그런가, 약간 외계인이 보낸 전파 신호를 감지한 느낌이 든다.

5

AI직원의 출근거부사태에 이어, 업데이트가 몇분째 없길래 뭐하고 있냐고 물으니까 황급하게 다시 일하기 시작했다(아마 이용자가 몰려서인것으로 예상). 졸기까지하고 사람 다 됐구만.

6

I've been thinking about adding a debug dashboard to that shows all activities being sent and received in real-time. This would include filters by activity type, detailed inspection of JSON-LD content, signature verification details, and retry management for failed deliveries.

As a , would you find this useful for troubleshooting federation issues? Any other features that would be helpful in such a debugging tool?

1

The Official Python Documentary has published their teaser trailer at PyCon US 2025, and I'm so honored to be part of the story of Python along with other prominent Python figures.

Check the trailer, and watch the official launch of the documentary at EuroPython later this year.

youtu.be/pqBqdNIPrbo

0

5월 24일(土) 한국 연합우주 개발자 모임(FediDev KR)에서 두 번째 스프린트 모임을 개최합니다! 장소는 뚝섬역 5번 출구쪽에 위치한 튜링의 사과(@TuringAppleDev튜링의 사과)입니다.

참고로 스프린트 모임이란 함께 모여서 오픈 소스 코딩을 하는 자리인데, 한국 연합우주 개발자 모임의 스프린트에서는 새로운 연합우주 서비스나 앱을 개발하거나, 번역이나 문서에 기여하는 등 연합우주와 관련된 다양한 오픈 소스 활동을 모여서 함께 합니다. 지난 스프린트 모임의 기록을 스프린트 블로그(@sprints.fedidev.kr한국 페디버스 개발자 모임)에서 살펴보실 수 있습니다.

저는 그날 Fedify, Hollo, Hackers' Pub에 기여하시고자 하는 분들을 옆에서 도와드릴 예정입니다. Fedify, Hollo, Hackers' Pub에 기여해보고 싶었던 분들이 계시다면 모임에 참가하여 저와 함께 스프린트를 해보는 것도 좋을 것 같습니다.

이번 모임에 관심이 있으신 분은 행사 신청 페이지를 참고하시기 바랍니다.

7
1
3

Jaeyeol Lee shared the below article:

논리와 메모리 - 논리와 저수준(Low-level) 자료 표현(Data representation) (2 편 중 2 편)

Ailrun (UTC-5/-4) @ailrun@hackers.pub

이 글은 "논리적"이 되는 두 번째 방법인 논건 대수를 재조명하며, 특히 컴퓨터 공학적 해석에 초점을 맞춥니다. 기존 논건 대수의 한계를 극복하기 위해, 컷 규칙을 적극 활용하는 반(半)공리적 논건 대수(SAX)를 소개합니다. SAX는 추론 규칙의 절반을 공리로 대체하여, 메모리 주소와 접근자를 활용한 저수준 자료 표현과의 커리-하워드 대응을 가능하게 합니다. 글에서는 랜드(∧)와 로어(∨)를 "양의 방법", 임플리케이션(→)을 "음의 방법"으로 구분하고, 각 논리 연산에 대한 메모리 구조와 연산 방식을 상세히 설명합니다. 특히, init 규칙은 메모리 복사, cut 규칙은 메모리 할당과 초기화에 대응됨을 보여줍니다. 이러한 SAX의 컴퓨터 공학적 해석은 함수형 언어의 저수준 컴파일에 응용될 수 있으며, 논리와 컴퓨터 공학의 연결고리를 더욱 강화합니다. 프랭크 페닝 교수의 연구를 바탕으로 한 SAX는 현재도 활발히 연구 중인 체계로, ML 계열 언어 컴파일러 개발에도 기여할 수 있을 것으로 기대됩니다.

Read more →
12

Next.js 서버 액션은 서버 데이터를 가져오는 용도로 사용하기에 적합하지 않다. React 공식문서에서는 다음과 같이 말하고 있다.

Server Functions are designed for mutations that update server-side state; they are not recommended for data fetching. Accordingly, frameworks implementing Server Functions typically process one action at a time and do not have a way to cache the return value.

서버 액션이 여러 호출되면 바로 실행되는 대신 큐에 쌓이고 순차적으로 처리된다. 이미 실행된 서버 액션은 이후 취소할 수 없다.

이에 서버 액션을 데이터 가져오기로 활용하면 끔찍해지는 UX가 생길 수 있는데, 예를 들어 페이지의 목록 검색 화면에서 검색 후 데이터를 가져오는 상황에 않았다고 다른 화면으로 네비게이션이 불가능한 것은 일반적인 경험이 아니다.

이러면 RSC를 통해 무한 스크롤을 구현하지 못하는가? 에 대해서 의문이 생길 수 있는데 여기에 대해서 대안을 발견했다.

function ServerComponent({ searchParams }) {
  const page = parseInt((await searchParams).page ?? "1", 10)
  const items = await getItems(page)
  return (
    <Collection id={page}>
      {items.map(item => <InfiniteListItem key={item.id} {...items} />)}
    </Collection>
  )
}
"use client"

function Collection({ id, children }) {
  const [collection, setCollection] = useState(new Map([[id, children]]))
  const [lastId, setLastId] = useState(id)
  if (id !== lastId) {
    setCollection(oldCollection => {
      const newCollection = new Map(oldCollection)
      newCollection.set(id, children)
      return newCollection
    })
    setLastId(id)
  }
  return Array
    .from(collection.entries())
    .map(
      ([id, children]) => <Fragment key={id}>{children}</Fragment>
    )
}

대충 이런 꼴이다. 이러고 page를 증가시키거나 감소시키는건 intesection observer나 특정 엘리먼트의 onClick 이벤트 따위를 의존하면 된다. 이러면 데이터 가져오기 패턴을 RSC 형태로 의존할 수 있다. InfiniteListItem는 서버컴포넌트, 클라이언트컴포넌트 무엇으로 구현하더라도 상관없다. 가령 아래와 같은 식:

function ServerComponent({ searchParams }) {
  const page = parseInt((await searchParams).page ?? "1", 10)
  const { items, hasNext } = await getItems(page)
  return (
    <div>
      <Collection id={page}>
        {items.map(item => <InfiniteListItem key={item.id} {...items} />)}
      </Collection>
      {hasNext && (
        <IntersectionObserver nextUrl={`/?page=${page + 1}`} />
      )}
    </div>
  )
}

검색 조건이나 검색어에 따라 상태를 초기화시키려면 다음과 같이 표현하면 된다.

function ServerComponent({ searchParams }) {
  const page = parseInt((await searchParams).page ?? "1", 10)
  const query = parseInt((await searchParams).query ?? "")
  const { items, hasNext } = await getItems(page, query)
  return (
    <div>
      <Form action="/">
        <input name="query" />
        <button />
      </Form>
      <Collection id={page} key={query}>
        {items.map(item => <InfiniteListItem key={item.id} {...items} />)}
      </Collection>
      {hasNext && (
        <IntersectionObserver nextUrl={`/?page=${page + 1}&query=${query}`} />
      )}
    </div>
  )
}

매우 PHP스럽고, 암묵적이기도 하다. 다만 RSC의 데이터 가져오기 패턴을 활용하면서 기존 컴포넌트를 최대한 재사용할 수 있게 된다는 점이 좋다.

2

커서를 제대로 사용하는 12가지 방법
------------------------------
* 커서 디자이너가 말하는 커서 사용법인데, 잘 몰랐던 내용들이 있어 공유드립니다.
1. Cursor는 프로젝트 별로 규칙(Rules)을 세울 수 있음. Cursor > Setting > Cursor Settings로 접근하면 됨
2. Cursor는 .cursurignore 기능이 있어서, 테스트 케이스 파일을 편집할 수 없게 할 수 있음
3. .cursor 폴더 안에…
------------------------------
https://news.hada.io/topic?id=20595&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

1

이이이얏호우우우!

가자! 댓글 없는 청정 사회로!

フトスト!

3

오픈 엑세스에 올라와 있는 논문들 중 소프트웨어 공학과 관련된 내용들을 편집하여 책으로 낸 것이다. 원문이 논문이라 그런지 몰라도 주장이 그렇게 혁신적이거나 새로운 것은 없다 다만 연구를 통해서 본인들의 주장에 대한 근거를 확보했다는 것이 유의미하다. 바꿔 말해 이 책에서 말하는 것들은 믿고 따라도 되는 어느 정도의 과학적 근거가 있는 이야기들.

소프트웨어 엔지니어링 생산성 돌아보기
aladin.kr/p/7zTVn

0

여태까지 내가 팔로한 사람이 내가 팔로하지 않은 사람에게 단 댓글까지 타임라인에 떠서 불편하셨죠? @xiniha 님의 패치를 통해 이제 내가 팔로한 사람의 글이라도 내가 팔로하지 않은 사람에게 단 댓글인 경우에는 타임라인에 표시되지 않도록 수정되었습니다. 아, 그래도 여전히 내가 팔로한 사람의 프로필에 들어가면 그 사람의 모든 댓글을 다 볼 수 있긴 합니다.

기여해 주신 @xiniha 님께 감사드립니다.

9
1

Rust로 작성한 JPEG XL 디코더, jxl-oxide의 버전 0.12.0을 릴리스했습니다. https://github.com/tirr-c/jxl-oxide/releases/tag/0.12.0

CMYK 프로파일 등 복잡한 ICC 프로파일을 지원하기 위해 기존에 사용하던 Little CMS 2 (lcms2) 에 더해, Rust로 작성된 색 관리 시스템인 moxcms 지원을 추가한 것이 주요 변경사항입니다. CLI 툴의 기본 CMS는 아직 lcms2이지만 --cms moxcms 옵션으로 moxcms를 사용할 수 있습니다.

9

Excited to share that we just released ESMeta v0.6.0! Here's two new features that we're really excited about in this release. Since this is my personal account, I won't be introducing the entire toolchain, but if you're curious, check out on https://github.com/es-meta/esmeta/ (1/n)

2

Jaeyeol Lee shared the below article:

간단한 rpmbuild의 사용과 private rpm package 배포

Perlmint @perlmint@hackers.pub

마지못해 패키지를 만들어야 할 것 같은 사람을 위한 설명입니다. 제대로된 패키지를 만들고 싶은 경우에는 부족한 점이 많습니다.

대부분의 경우에는 프로그램을 직접 소스에서 빌드하는 일도 적고, 그걸 시스템 전역에 설치하는 일도 흔치는 않을 것입니다. 좋은 패키지매니저와 관리가 잘되는 패키지 저장소들을 두고 아주 가끔은 직접 빌드를 할 일이 생기고, 흔치 않게 시스템 전역에 설치할 일이 생길 수 있습니다. 어지간한 프로그램들은 요즈음의 장비에서는 별 불만 없이 빌드 할 만한 시간이 소요되나, 컴파일러처럼 한번 빌드했으면 다시는 하고 싶지 않은 프로그램을 다시 설치해야하는 경우도 있을 수 있습니다. 하필 이런 프로그램들은 결과물도 덩치가 매우 큽니다. 이럴 때는 최대한 간단하고 필요한 항목만 패키지에 넣어서 만들어두고 다시 활용하면 좋을 것이기에 이런 경우를 위한 rpmbuild에 대한 나름 최소한의 사용 방법을 정리해봅니다.

rpmbuild

rpmbuild는 rpm-build 패키지로 설치가 가능하며, 나름 단순하게 rpm으로 패키징을 할 수 있는 유틸리티입니다. spec파일에 패키지 정보, 빌드 명령, 설치 명령, 패키지가 포함해야 할 파일 목록을 작성해서 rpmbuild에 입력으로 넣어주면 빌드부터 시작해서 rpm패키지를 만들어줍니다. native 프로그램의 경우 디버그 심볼을 알아서 분리해서 별도의 패키지로 만들어주고, 필요한 의존성도 추정해서 명시해줍니다. 또한, 필요한 경우 하나의 spec 명세로 연관된 서브 패키지도(ex. 실행파일 패키지인 curl과 라이브러리 패키지 libcurl, 라이브러리를 사용하기 위한 개발 패키지 libcurl-devel) 같이 만들 수 있습니다.

작업 환경

rpmbuild는 기본으로 ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS,BUILDROOT}의 경로에서 동작하며 각 경로의 용도는 다음과 같습니다.

  • SOURCES에는 압축된 소스코드가 위치합니다.
  • SPECS에는 패키지 정의인 spec파일을 둡니다.
  • BUILD밑에서 빌드 작업이 진행됩니다.
  • RPMS에 바이너리 rpm결과물이 생성됩니다.
  • SRPMS에는 소스 rpm결과물이 생성됩니다.
  • BUILDROOT는 패키징 하기 위해 빌드 결과물을 모으는 경로입니다.

spec파일

spec파일은 패키지를 어떻게 빌드하고 어떤 항목들이 패키지에 포함될지, 패키지의 이름, 설명 및 의존성 등의 메타데이터, 패키지 설치, 삭제시의 스크립트를 정의할 수 있습니다. 보통 시작 부분에는 메타데이터 정의로 시작하며, 다음과 같은 기본적인 형태를 취합니다. 나름 단순하게 만든 python을 위한 spec을 예시로 들어보겠습니다.

Summary: Python %{version}
Name: python-alternative
Version: %{version}
Release: 1%{?dist}
Obsoletes: %{name} <= %{version}
Provides: %{name} = %{version}
URL: https://www.python.org
Requires: libffi openssl
AutoReq: no
License: PSFL

Source: https://www.python.org/ftp/python/%{version}/Python-%{version}.tgz

BuildRequires: libffi-devel openssl-devel
BuiltRoot: %{_tmppath}/%{name}-%{version}-%{release}-root

%define major_version %(echo "%{version}" | sed -E 's/^([0-9]+)\\..+/\1/' | tr -d)
%define minor_version %(echo "%{version}" | sed -E 's/^[0-9]+\\.([0-9]+)\\..+/\1/' | tr -d)

%description
Python

%package devel
Summary: python development files
Requires: %{name} = %{version}-%{release}

%description devel
Python development package

%prep
%setup -q -n Python-%{version}

%build
./configure --prefix=%{_prefix}

%install
%{__make} altinstall DESTDIR=%{buildroot}
%{__ln_s} -f %{_bindir}/python%{major_version}.%{minor_version} %{buildroot}/%{_bindir}/python%{major_version}

%clean
%{__rm} -rf %{buildroot}

%files
%{_bindir}/python*
%exclude %{_bindir}/idle*
%{_bindir}/pip*
%{_bindir}/pydoc*
%exclude %{_bindir}/2to3*
%{_libdir}/libpython*
%{_prefix}/lib/libpython*
%{_prefix}/lib/python*
%{_mandir}/man1/python*

%files devel
%{_includedir}/python*
%{_prefix}/lib/pkgconfig/python*

%로 매크로를 사용할 수 있으며, %package, %description, %files 같은 매크로는 인자를 주어서 서브 패키지를 정의하는데도 쓸 수 있습니다. 앞선 예제처럼 devel 이라고작성하면 메인 패키지이름 뒤에 붙여서 python-alternative-devel가 되며, curl - libcurl과 같은 경우에는 메인의 이름은 curl이고, 딸린 패키지를 정의할 때는 %package -n libcurl과 같이 -n옵션을 추가해서 지정할 수 있습니다. 몇몇 매크로는 단계를 정의하는 것과 같은 동작을 하며 다음과 같습니다.

%package

유사성을 보면 spec파일의 맨 첫부분은 메인 패키지의 %package에 해당하는 것이 아닌가 싶습니다. <Key>: <Value>의 형태로 메타정보를 작성합니다. 대부분은 Key를 보면 무슨 값인지 추측 할 만합니다. 나중에 설명할 %files에서 나열한 파일을 rpmbuild가 분석하여 자동으로 패키지가 필요로 하는 의존성을 추정해서 추가 해 줍니다. python 스크립트, perl 스크립트, native 실행파일 등을 분석해서 알아서 추가해주는 것 같은데, 경우에 따라서는 틀린 의존성을 추가해주기도 합니다. 이 때는 AutoReq: no를 설정하여 자동 의존성 추가를 막을 수 있습니다. 이 python-alternative 패키지는 /usr/local/bin/python%{version}을 설치하는데 아마도 같이 포함되는 python 스크립트에 의해서 /bin/python을 의존성으로 추정하여 요구합니다. 패키지 스스로가 제공하는 의존성은 미리 설치 되어있기를 요구하지 않게 동작하는 것 같으니 보통은 문제가 없습니다만, 이 경우에는 스스로 제공을 하지 않기 때문에 python을 설치하기 위해서 python이 필요한 경우가 발생하므로 AutoReq를 껐습니다.

%prep

준비단계로 소스코드의 압축을 해제하고 필요한경우 패치를 적용합니다. %setup 매크로를 이 안에서 보통 사용하며, %setupSource에 명시된 파일명의 압축 파일을 SOURCES 밑에서 찾아서 압축을 풉니다. 그리고 동일한 이름의 디렉토리로 이동을 합니다. 앞선 예제에서는 SOURCES/Python-%{version}.tgz의 압축을 풀고 Python-%{version}으로 이동을 합니다. 패치가 필요한 경우 보통 이 뒤에 패치를 적용하는 명령들을 추가 합니다.

%build

설정, 컴파일 등을 수행하는 단계입니다. 이곳에서 자주 하는 매크로로 %configure, %make_build 등이 있습니다. %configure는 configure를 prefix 및 기타 몇가지 일반적으로 쓰이는 옵션을 추가하여 실행해주며, %make_buildmake와 비슷하게 모든 타겟을 빌드 합니다. 예제에서는 둘다 안쓰고 있고, 심지어 실제 빌드는 안하는데 어쨌든 이후의 %install까지 지나고나서 빌드 결과물만 맞는 위치에 만들어지면 대충 패키지를 만드는데는 별 문제는 없는 것 같습니다.

%install

여기서 빌드 결과물을 설치하는 명령을 작성합니다. 일반적으로 %make_install을 사용하여 make install DESTDIR=%{buildroot}와 비슷한 명령을 수행하여 %{buildroot}밑에 빌드 결과물이 prefix를 유지하여 설치되게 합니다. 예제의 %{__ln_s} -f %{_bindir}/python%{major_version}.%{minor_version} %{buildroot}/%{_bindir}/python%{major_version}을 보면 추정 할 수 있듯이, 패키지에 포함시킬 파일들을 %{buildroot}밑에 생성을 하면 되며, 추가적인 심볼릭 링크는 패키지를 빌드하는 시점에는 존재하지 않지만, 패키지를 설치하게되면 존재하게 될 %{_bindir}/python%{major_version}.%{minor_version}를 향하는 것을 %{buildroot} 밑인 %{buildroot}/%{_bindir}/python%{major_version}에 만듭니다.

%files

패키지에 포함될 파일 목록을 작성합니다. glob 양식으로 파일 목록을 작성할 수 있습니다. %{buildroot} 밑에 생성 되었지만 어느 %files에도 포함되지 않은 파일이 있는 경우에는 빌드를 실패합니다. 그러므로 %exclude를 사용해서 명시적으로 제외해줘야 합니다.

기타 매크로

rpmbuild에서는 기본으로 다양한 매크로를 제공하고 있습니다. --define "_libdir %{_prefix}/lib64"와 같은 옵션을 실행시에 주어서 실행시점에 매크로를 덮어 쓸 수도 있고, 앞선 spec파일 내의 %define major_version 와 같이 다른 매크로와 셸 명령을 활용하여 매크로를 정의 할 수도 있습니다. 원하는 동작을 안하는 것 같은 경우에는 --show-rc옵션을 사용하여 매크로가 어떻게 정의되어있는지 확인해 볼 수 있습니다.

빌드

rpmbuild의 매뉴얼을 보면 자세하게 나와있지만 가장 단순하게는 rpmbuild -bb <specfile>로 바이너리 패키지를 빌드할 수 있습다. 이 때, 압축된 소스코드는 미리 SOURCES밑에 두어야 합니다.

private rpm package 배포

직접 비공개 패키지 저장소 프로그램을 실행하여 제공하는 방법도 있겠지만, 최대한 간단하게 할 수 있는 방법으로, rpm관련 패키지 설치 명령이 입력으로 http등의 URL도 받는 것을 활용하여 적당한 장비에서 http로 서빙을 해주면 됩니다.

Read more →
4

간만에 필받아서 aider 커꾸(commit 꾸미기) 함.
gum 이라는 훌륭한 쉘꾸 도구 + git pretty format + delta 썼어요

# Define the git log format string with color formatting for better readability
local GIT_FORMAT="%C(bold yellow)Hash:%C(reset) %C(bold cyan)%h%C(reset) %C(dim white)(%cd)%C(reset)%n"
GIT_FORMAT+="%C(bold yellow)Author:%C(reset) %C(bold white)%an%C(reset) %C(dim white)<%ae>%C(reset)%n"
GIT_FORMAT+="%C(bold yellow)Message:%C(reset) %C(bold white)%s%C(reset)"

# Define the date format
local DATE_FORMAT="%Y-%m-%d %H:%M:%S"

# Perform the commit with aider and show a styled commit summary
aider --commit && \
gum style \
  --border rounded \
  --padding "0 2" \
  --border-foreground 39 \
  "$(git log -1 \
      --pretty=format:"$GIT_FORMAT" \
      --date=format:"$DATE_FORMAT" \
      --color=always)" && \

# Show detailed changes using delta for side-by-side diff with line numbers
git show -1 --color=always --stat --patch | delta --side-by-side --line-numbers
2

🤔

Protocols such as ActivityPub are widely used and useful, but unfortunately are not the best option when efficiency is important. Messages are in plain JSON format, which is wasteful, and extensions by various implementations complicate the implementation.

XQ's focus on replacing JSON with Protocol Buffers seems misguided. While serialization efficiency matters, ActivityPub's fundamental bottlenecks are in its multi-hop network architecture and request patterns. Optimizing message format without addressing these core architectural inefficiencies is like polishing doorknobs on a house with structural issues. True performance gains would require rethinking the communication model itself.

https://github.com/misskey-dev/xq

3
0
0

DuckDB 인 액션 - SQL만 알면 되는 로컬 데이터 분석, DuckDB로 가볍게 시작한다 (마크 니드햄, 마이클 헝거, 마이클 시몬스 (지은이), 김의윤 (옮긴이) / 인사이트 / 2025-05-07 / 28,000원) feed.kodingwarrior.dev/r/qmINu

aladin.co.kr/shop/wproduct.asp

0

내가 제일 좋아하는 프로그래밍 문법, "파이프라이닝"
------------------------------
- *파이프라이닝* 은 프로그래밍 언어에서 코드의 가독성과 유지보수성을 높이는 중요한 기능임
- *데이터 흐름을 왼쪽에서 오른쪽, 위에서 아래로 자연스럽게* 표현할 수 있게 해주는 방식
-
Rust 와 같은 언어에서 파이프라이닝은 코드의 흐름을 명확하게 하고, IDE 의 자동 완성 기능을 통해 개발 생산성…
------------------------------
https://news.hada.io/topic?id=20473&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

0

랭체인으로 RAG 개발하기 : VectorRAG & GraphRAG - 현직 AI Specialist에게 배우는 RAG! 파이썬, 오픈AI, Neo4j로 실습하며 개념과 원리를 이해하고, 오픈AI와 딥시크 비교 분석까지! (서지영 (지은이) / 길벗 / 2025-04-25 / 29,000원) feed.kodingwarrior.dev/r/9pIEy

aladin.co.kr/shop/wproduct.asp

0

미래의 기술은 'AI'가 아니라 '집중력'임
------------------------------
- LLM은 반복 작업 자동화와 브레인스토밍 등에 유용하지만, *맹목적인 의존은 문제 해결 능력 저하를 초래할 수 있음*
- 특히 *새로운 문제에 대한 LLM의 신뢰도는 낮아* , 인간 엔지니어의 판단력이 중요함
- 구글 같은 검색엔진은 탐색과 활용의 균형을 제공하지만,
LLM은 즉시 ‘활용’(exploitation)만 유…
------------------------------
https://news.hada.io/topic?id=20458&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

0

Vibe 코딩은 저품질 작업에 대한 변명이 될 수 없어요
------------------------------
- *AI 기반 바이브 코딩* 은 혁신적이지만, *품질 없는 속도는 위험* 하다는 경고의 글

"더 빨리 움직이고, 더 많이 망가뜨려라"
"vibe coding, 두 명의 엔지니어가 50명의 기술 부채를 만들어낼 수 있는 방식"
- 이 실리콘밸리의 오래된 슬로건을 비튼 표현은 최근 엔지니어링 커뮤니티에서 “vibe coding…
------------------------------
https://news.hada.io/topic?id=20449&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

0

터미널에 대해 궁금한 점이 생겨 자료를 찾다 보니 Windows Console Team에서 연재한 시리즈물을 발견했는데, 그 내용이 참 유익했다.

Windows Command-Line Series:

  1. Backgrounder
  2. The Evolution of the Windows Command-Line
  3. Inside the Windows Console
  4. Introducing the Windows Pseudo Console (ConPTY)
  5. Unicode and UTF-8 Output Text Buffer

콘솔 앱이 터미널과 입출력을 주고 받는 것을 공기처럼 당연하다고 생각했는데, 그 과정에는 커서 이동이나 개행 등과 같은 제어 문자를 렌더링하거나 SIGINT 같은 시그널을 발생시켜주는 처리가 존재했다. 터미널과 콘솔 앱이 서로 분리된 구조가 과거 물리 터미널로부터 비롯된 것도 흥미로웠고 말이다. 사실 이해 못 한 부분이 아직 많아서 다음에 또 읽어볼 생각이다.

6
0
0

배그로 설명하는 수학, 실험, 과학의 관계

수학: 배그에서 총을 쏠 때 총알 궤적
실험: 현실에서 총을 쏘면 배그와 동일한 총알 궤적이 나올까? 궁금한데? 쏴서 비교해보자!
과학: 실험 몇 번 해보니까 배그랑 현실이랑 총알 궤적이 같더라! 앞으로 총알 궤적 예측할 때는 배그켜서 확인하자!

0