gemini-cli 이것저것 만져보는 중인데, gemini-2.5-pro 의 코드 수정능력이 생각보다 괜찮아서 좀 더 써볼 것 같다. VSCode 의 Gemini Code Assist 보다는 만족감이 더 높다. 다만 이미지 분석 용도는 아닌 것 같고. 코딩 용도로 쓰면 괜찮을 것 같다.

@fxunnamed 님, 어서 오세요!

@loomings언노운 님도 어서 오세요!

맞다 맞다 하면서, 청개구리 타래에 다 하트 눌렀습니다.(해커스펍에 중복 글 안보이는 타래 기능이 어여 들어 오길... 설마 TS 전혀 모르는 제가 TS 익혀서 기여할 수 있을 때까지 안들어오진 않겠지요) 여기 몇 분은 아실 것 같은데, 전 빅 황소 청개구리입니다. 튼튼한 손 발로 돌파해야 하는데, 얘들이 힘이 약해지고 있어요.

Hackers Pub은 개발자를 위한 블로깅 플랫폼이면서 SNS기능이 탑재된 흥미로운 서비스이지만, ActivityPub 프로토콜을 지원하여 Mastodon/Misskey/Thread 등의 SNS를 구독할 수 있는 연합우주 소프트웨어이기도 합니다.

연합우주 소프트웨어가 정확히 어떤 것인지 간단하게나마 파악할 수 있게 슬라이드로 정리해봤습니다. (해커스펍에 오지 않은 분들에게만 미공개)

기술적으로 어떤 물건인지 궁금하시다면 @hongminhee洪 民憙 (Hong Minhee) 님이 쓰신 글도 한번 읽어보시는 것도 좋습니다.

막상 들어왔는데 어떤 계정을 팔로할지 모르겠다구요? 이 글도 참고할만할지도 모르겠네요.

해커스펍 온보딩 시각화자료도 준비해볼까 생각중이긴 한데, 뭐 암튼 적응에 도움되기를 바랍니다.

@scariYounggun Kim 님도 어서 오세요!

@curzyMinseok Choi 님, 어서 오세요!

@bglbgl gwyng 제가 악한 영향력을 끼쳤군요… ㅋㅋㅋ

@hongminhee洪 民憙 (Hong Minhee) 근데 저도 한 10년전에 파이썬 프로젝트할때 Django 대신 Flask 골랐었는데, 아마 홍민희님 글 읽고 그랬던거 같아요.

@asitisdevAsitis 님, 어서 오세요!

@bglbgl gwyng 생각해보니 그런 것 같습니다. 역시 손발이 튼튼하면 머리가 고생을 안 한다!

애초에 Deno 붙잡고 있는 것도 청개구리 같네…

생각해 보면 Python으로 웹 개발 한창 할 때도 나는 Django를 별로 안 좋아해서 SQLAlchemy + Flask 조합만 썼었다. Flask 나오기 전에는 Werkzeug 위에서 인하우스 웹 프레임워크를 만들어 썼었고. Hackers' Pub에서는 React 안 쓰고 Solid 쓰려고 하고 있고… 나도 한 청개구리 스택 하는 것 같긴 함.

@theeluwin제이미 그러면 그냥 애플리케이션에서 강제하는 게 낫겠네요. ㅋㅋㅋ

Deno bundle is coming back in 2.4!

Here's a glimpse at the future of JavaScript (and what's already available to use in Deno)
⭐ explicit resource management (using)
⭐ Array.fromAsync
⭐ Error.isError
⭐ immutable ArrayBuffer
⭐ Random.Seeded
⭐ Number.prototype.clamp
⭐ keep trailing zeros
⭐ comparisons
⭐ random functions

https://deno.com/blog/updates-from-tc39

(user, quiz, option)을 response의 필드로 두고 (user, quiz)에 unique constraint를 걸면, option이 quiz 소속인지를 보장 할 수 없는데, 이거까지 보장하는건 쉽지 않습니다.

@theeluwin제이미 option 테이블의 기본 키를 (quiz_id, index) 정도의 복합 키로 만든 뒤에, response 테이블의 (quiz_id, option_index)를 option 키의 외래 키로 만들면 option이 어느 quiz의 소속인지 강제할 수 있지 않을까요?

어제 @perlmint 님이랑 얘기하다가 'hollo' 라는 이름을 한국어 '홀로' 에서 따왔다는 걸 알게됐는데, 한국어로 지은 이름은 거의 본 적 없어서 뭔가 신기했다. 이름 처음 봤을 때는 대충 'hollow' 정도 의미인가 했는데

유닛 테스트를 짜기 위해서 유닛 테스트 인프라를 만들어야한다... 일단 손수 테스트하고 후속작업으로 하자...

"해외 참가자"의 경우, 지원 가능한 최대 금액은 $200 입니다. https://2025.pycon.kr/fa

• 바다 건너 비행기로 가야 하는 지역인가 ⭕️
• 항공편 이용료가 유동적인 싯가인가 ⭕️
• 사용하는 언어가 다른가 ⭕️

= 해외

오호라

• 8월 16일-17일 파이콘 일반 참가
• 8월 23일 FEConf 발표 참가

휴가철이라 제주 ↔️ 김포 항공료 너부 부담되는데;;

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

오픈소스 프로젝트에 여러분의 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 프로그래밍 사용량을 기여하는 것이 하나의 큰 축이 될 것입니다.

새롭게 다시 태어난, 또 만들어버린 boilerplate. 이제는 진짜 monolithic 하고 Pocket Galaxy라는 이름에 걸맞는 boilerplate입니다.

Django + Vue(Vuetify) 조합이구요, nginx가 이것저것을 다 처리합니다.

백엔드는 /api에서 서빙하고, 기타 기본적인 static 캐싱이나 로깅 등 전부 기초적인건 제공합니다.

간단한 웹사이트 하나 만들겠다는게 어쩌다 여기까지 왔는지.... 암튼 이제는 진짜 최소한의 웹사이트 만들때 뚝딱 하면 만들수 있을것 같습니다 제발...

내부용 툴 만들때 애용해보세요.

https://github.com/theeluwin/pocket-galaxy

Hackers' Pub도 모더레이션 기능을 빨리 구현하고 모더레이터 분들을 모셔야…

오늘 만난 분에게 유튜브 출연 제의를 하다 알게 되었는데, 생각보다 부모님도 프로그래머인 경우가 – 그리고 아직도 2대에 걸쳐 현업인 경우도 이제는 꽤 많을 것 같다. 그래서 혹시 동반 출연 가능하실지 여쭤봤는데 과연… 관심있는 분들의 DM 기다립니다 ㅋㅋ

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

하스켈 db 라이브러리 Opaleye를 쓰려고, Arrow를 봤었는데. 지금은 Arrow를 안 쓰고 Applicative 스타일로 넘어간 것 같습니다. 일정 수준에 다다른 라이브러리 제작자들도 느낀 거지요. 추상화가 고급스럽고 좋긴 하지만, Arrow는 너무 갔다고. (<- 몇 년 전 이야기로, 어디까지나 혼자 추측입니다.) Arrow가 뭔지 알고는 있는 것 같은데, 아직도 쓰려면 (읽는 것 말고) 입술이 마릅니다. Opaleye 예시가 Arrow를 안 쓰니 훨씬 마음이 편하게 접근하네요.

같은 류에서 킬러 기능이 탑재됐다면, 좀 어려워도 꾸역 꾸역 가져다 쓰지만, 그렇지 않은 경우는 고급스러운 모양보다는, 쓰기 편한 게 장땡입니다.

Gemini CLI가 미쳐 날뛰기 시작했다…

Coming soon

차일피일 미루던 Fedify 이슈 자잘한 거 30개 만들기를 이제 정말 해야 한다…

@theeluwin제이미 오… 축하드립니다! 축하드려야 하는 거 맞죠?

아 9월부터 강의를 합니다 (교수가 되었습니다). 무슨 과목을 맡게될지는 모르겠지만 꿈에 그리던 기깔난... 마치 IoT로 도배된 집과도 같은 강의를 해보겠습니다 기대해주세요. 그리고 언젠가 이 경험들이 쌓여서 파이콘에서라도 발표하면 좋겠네요.

그동안 웹 백엔드 따로, 프론트엔드 따로 만들어서 인스턴스 2개에 올리는 느낌으로 작업했는데... 지금 목표는 뿅 하면 웹사이트가 생기는거라서 compose도 빼버리고, 도커 이미지 하나에 전부 때려박아서 정말 딱 이 이미지 하나만 ECS 같은데에라도 올리면 짠 하고 곧바로 돌아가게끔 하고 있는 중. 앞으로 이걸로 온갖 강의 보조도구(퀴즈 사이트 등)를 만들 예정.

inertia.js를 django+vue로 활용하는걸 검토해봤으나... 묘하게 익숙해지지가 않고, 문서나 use case가 적고, 뭔가 문제가 생겼을때 막힐것 같은 예감이 들어서... 그냥 django 따로 vue 따로 각자 pure하게 가기로 결정하였습니다,,, @kodingwarriorJaeyeol Lee

아쉽게도 아직 커스텀 커맨드 기능이 없는 듯…

Gemini CLI 공개 됐네. 어떠려나…

We're pleased to share that Encyclia has joined our success stories.

@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.

This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.

We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.

Learn more about Encyclia at https://encyclia.pub/. 📚

#fedidev #openscience

We are pleased to announce the release of #Fedify 1.7.0. This release was expedited at the request of the Ghost team, who are actively using Fedify for their #ActivityPub implementation. As a result, several features originally planned for this version have been moved to Fedify 1.8.0 to ensure timely delivery of the most critical improvements.

This release focuses on enhancing message queue functionality and improving compatibility with ActivityPub servers through refined HTTP signature handling.

Native retry mechanism support

This release introduces support for native retry mechanisms in message queue backends. The new MessageQueue.nativeRetrial property allows queue implementations to indicate whether they provide built-in retry functionality, enabling Fedify to optimize its retry behavior accordingly.

When nativeRetrial is set to true, Fedify will delegate retry handling to the queue backend rather than implementing its own retry logic. This approach reduces overhead and leverages the proven retry mechanisms of established queue systems.

Current implementations with native retry support include:

• DenoKvMessageQueue — utilizes Deno KV's automatic retry with exponential backoff
• WorkersMessageQueue — leverages Cloudflare Queues' automatic retry and dead-letter queue features
• AmqpMessageQueue — can now be configured to use AMQP broker's native retry mechanisms

The InProcessMessageQueue continues to use Fedify's internal retry mechanism, while ParallelMessageQueue inherits the retry behavior from its wrapped queue.

AMQP message queue improvements

Alongside Fedify 1.7.0, we have also released @fedify/amqp 0.3.0. This release adds the nativeRetrial option to AmqpMessageQueueOptions, enabling you to leverage your AMQP broker's built-in retry mechanisms. When enabled, this option allows the AMQP broker to handle message retries according to its configured policies, rather than relying on Fedify's internal retry logic.

Configurable double-knocking

The new FederationOptions.firstKnock option provides control over the HTTP Signatures specification used for the initial signature attempt when communicating with previously unknown servers.

Previously, the first knock for newly encountered servers always used RFC 9421 (HTTP Message Signatures), falling back to draft-cavage-http-signatures-12 if needed. With this release, you can now configure which specification to use for the first knock when communicating with unknown servers, with RFC 9421 remaining the default.

Summary

This release maintains Fedify's commitment to reliability and compatibility while laying the groundwork for more efficient message processing. The native retry mechanism support will particularly benefit applications using queue backends with sophisticated retry capabilities, while the double-knocking mechanism addresses real-world compatibility challenges in the ActivityPub ecosystem.

For detailed technical information about these changes, please refer to the changelog in the repository.

#fedidev #fediverse

Object.keys() 했는데 값의 개수가 1이 아니면 편두통이 온다 난 그냥 이런 사람인듯

@z9mb1wwj 총 세 명까지 가능하다는데 이미 두 분이 도와주신다고 하네요. 😅 말씀만으로도 너무 감사합니다!

리액트 작업하면 vs code 탭 두 개 한 화면에 브라우저 한 화면에 디자인 전달받아서 하면 figma나 시안 확인용 화면 하나에 모니터 세 개쯤은 있어야 하던데 노트북만 들고 카페에서 코딩하는 건 어떤 종류의 작업일까….

@jaeholee 저도 Claude Max 구독해서 씁니다… 코딩 에이전트 중에서는 가장 만족스러운 것 같아요.

@annyeong안녕 님과 @nebuletoHaze 님, 두 분께서 도와주시기로 했습니다! 감사합니다!

@gnh1201어둠사자 감사합니다! 혹시 다른 지원자 분이 없으시면 연락 드릴게요!

@annyeong안녕 오… 감사합니다! 행사 가까워지면 연락 또 드릴게요!

@bin_bash_shell이수호 오오… 감사합니다! 혹시 아무도 지원자가 없으면 연락 드릴게요!

Hackers' Pub이 커뮤니티 자격으로 올해 파이콘 한국에 후원하게 되어, 8월 16일(土)–17일(日) 후원사 부스를 운영하게 되었는데요. 부스 운영을 도와주실 분을 한 분에서 두 분 정도 찾습니다! 이틀 중 하루만 도와주셔도 좋습니다. (당연하지만 저는 이틀 모두 나갑니다.) 도와주신 분께는 약소하지만 제가 점심과 저녁을 대접하겠습니다.

이거 너무 싼거같은데 사기아닌가...? contabo 써 보신 분?