오, ChatGPT Atlas 쓰는 중인데 해커스펍에서도 자음과 모음이 분리 안되고 있어!! 완전 짱이다
Song Yongseok
@mexicorea@hackers.pub · 48 following · 19 followers
SWE
GitHub- @mexicorea
ChatGPT Atlas 쓰고 있는데, 트위터에 와다다 쓴 내용을 정리하자면.... 실용적인 관점에서 보면 굉장히 좋은건 맞는 것 같다. 퍼플렉시티에서 만들었다는 AI 기반의 브라우저 Comet과 비교하면 어떤지는 모르겠다만, 내가 Atlas 쓰고 있는 입장에서의 주관적인 경험을 남기자면 이렇다.
- 웹 페이지로 제공되는 모 교과서 페이지로 테스트 해봤는데, 확실히 학습용으로는 괜찮은 듯. PDF 문서 내용가지고 질답 주고받기도 괜찮다.
- 첨부된 이미지를 보면 알겠지만, 웹 페이지로 제공되는 교과서 뿐만이 아니라 웹 상에 업로드된 PDF 교재도 질답을 주고 받을 수 있고 퀄리티도 적당히 괜찮은 편이다. (로컬에 있는 파일도 접근이 된다!!)
- 각 페이지마다 ChatGPT와 대화를 할 수 있는 버튼이 있는데, 여기서 "ChatGPT에게 묻기" 버튼에서 열리는 대화창은 브라우저의 각 탭마다 (페이지 단위가 아니다) 붙어있다.
- 즉, A 페이지에 대해 뭔가를 물어보면 A 페이지에 대한 맥락을 가지고 답변을 해주고, 다시 B 페이지에 대해서 뭔가를 물어보면 B페이지에 대한 맥락도 같이 입력되어서 종합적인 답변을 내주는 식으로 동작한다.
- 다만..... 브라우저에서 질답을 주고받은 내용이 왼쪽 사이드바에 와다다다 하고 히스토리가 누적되어서 어느 정도는 관리가 필요할 수 있다.
I recorded a one hour video of me implementing a thing for one of our code bases with codex and claude. It might be boring in the first 15 minutes, but I went through most of it. https://www.youtube.com/watch?v=X8M6U3QiC8Q
마인크래프트 내에 레드스톤으로 물리적으로 언어모델을 만든 사람이 나타남... 그러니까 간단한 디지털 회로도 아니거 언어모델을 만듬 ㅋㅋㅋ 외부 언어모델을 연결한것이 아닙니다;; 말그대로 트랜스포머를 구축해놨던데 세상은 넓고 천재는 많다... www.youtube.com/watch?v=VaeI...
I built ChatGPT with Minecraft...
2025년 가장 인기 있는 프로그래밍 언어
------------------------------
- Python > Java > C++ > SQL > C# > JavaScript > TypeScript > C > Shell > Go > R > PHP > Kotlin > Rust > Dart > Swift
- IEEE Spectrum 조사 결과 Python 이 올해도 1위를 차지, JavaScript 는 3위에서 6위로 떨어짐
- 이 변화는 웹 개발에 많이 쓰이는 JavaScript가 *AI 기반 코딩* (예: vibe cod…
------------------------------
https://news.hada.io/topic?id=23330&utm_source=googlechat&utm_medium=bot&utm_campaign=1834
“주문과 동시에 조리를 시작합니다“라는 문구를 보고.
어떻게 조리시작 시점과 주문 완료 시점 사이에 정시성을 보장할 수 있을까. 조리시작 시점의 동시성을 보장하려면 주문을 예측해야만 한다.
요즘 세상이다보니 복잡한 상황을 표현하는 인터페이스의 동작에 대해 논의할 때 서로 다른 뇌들을 동기화하는데 엄청난 의사소통비용을 들이고 또 그 결과가 딱히 좋지도 않아 논의가 핵심에 집중하는 대신 의사소통비용의 남발로만 이어지는 상황을 그냥 동작하는 시뮬레이션을 그 자리에서 즉시 만들어 대응할 수 있다. 아니 그냥 조건을 나열해 기계한테 던져주고 시뮬레이션 만들어달라고하면 순식간인데 뭐하러 커뮤니케이션 비용을 부담하며 고통스러운 회의를 하나. 걍 그때그때 아이디어에 따라 코드를 생성해 돌아가는걸 직접 그 자리에서 보고 정하면 된다.
예전에는 보스가 어떤 (말도 안 되는) 스펙을 열거하면서 구현 가능성을 물을 때 굉장히 보수적으로 접근했고, 대개의 경우 기본값은 불능이지만 어렵게 어찌 대처하면 가능할 수 있겠단 관점으로 바라봤는데, 지금은 웬만하면 구현할 수 있을 테니 구현 걱정일랑 말고 사업에만 더 집중하실 수 있게 개발팀에 대한 어떤 믿음, 안정감을 드리는 방향으로 바뀐 것 같다. 결국 그것도 내 역할 중 하나였다는 생각이 들고, 대개의 경우 결과물의 질은 어차피 두 시나리오 모두 비슷하게 나왔다. (잘 되기 어렵겠다고 한 후 어찌 구현한 상태 ~= 어지간하면 다 할 수 있다고 한 후 어찌 구현한 상태)
보스가 "간단한 주제니까 모두 소집해서 10분 안에 해치우자" 쪽인데 나는 이걸 반대로 보고 있어서 힘들다. 10분밖에 안 걸릴 회의라면 애초에 텍스트로도 능히 소통 가능하단 이야기인데 그런 회의일랑 가급적 지양하고, 최소 30분 이상 소요될 복잡한 사안일 때 비로소 회의를 잡는 게 어떻겠냐고..
Song Yongseok shared the below article:
내가 LLM과 함께 코딩하는 방식
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
이 글은 저자가 LLM(Large Language Model)을 활용하여 코딩하는 방법에 대한 개인적인 경험과 팁을 공유합니다. LLM 코딩 에이전트 사용 시 맥락 제공의 중요성을 강조하며, Claude Code 모델을 선호하는 이유와 그 장단점을 설명합니다. 세부적인 지시를 위해 GitHub 이슈를 활용하고, 설계는 사람이, 구현은 LLM이 담당하는 역할 분담을 제안합니다. 또한, 프로젝트 지침을 담은 *AGENTS\.md* 파일의 중요성과 Context7을 활용한 문서 제공 방법을 소개합니다. 계획 모드를 통해 LLM이 스스로 피드백 루프를 돌도록 유도하고, 필요한 경우 손 코딩을 병행하여 코딩의 재미를 유지하는 전략을 제시합니다. 이 글은 LLM을 단순한 도구가 아닌 협력적인 동료로 활용하여 개발 효율성을 높이는 방법을 모색하는 개발자들에게 유용한 인사이트를 제공합니다.
Read more →
이제 자신이 보여주고 싶지 않은 추천사를 가리는 기능도 추가되었습니다. 메인 페이지에서 링크 타고가시면 사용 가능해요. 많은 이용 부탁드립니다.
https://referral.akaiaoon.dev/ 이 링크에서 사용 가능하고, 내가 받은 추천사는 https://referral.akaiaoon.dev/u/:username 으로 볼 수 있습니다. 아래 말코링님의 추천사 리스트를 참조해 주세요.
〈타입 검사는 해결책이 아니라 증상이다〉(Type Checking is a Symptom, Not a Solution).
난 이 글에 동의하지 않는데, 여러 측면에서 그렇지만, 한 측면에만 집중해서 얘기해 보자면: 좋은 아키텍처는 훌륭한 프로그래머를 요구하지만 타입 시스템은 훌륭한 프로그래머를 요구하지 않기 때문이다.
누구나 훌륭한 프로그래머가 되어야만 하는가? 혹은 될 수 있는가? 좋은 아키텍처를 그릴 수 있는 훌륭한 프로그래머가 아니라면 소프트웨어 개발을 해서는 안 될까? 좋은 아키텍처에만 의존하는 것은 잠재적으로 엘리트주의를 끌어들이기 쉽다: 「어떤 시스템이 오작동하는 것은 아키텍처가 나쁘기 때문이다. 아키텍처가 나쁜 이유는 그걸 설계한 프로그래머가 수준 미달이기 때문이다」와 같이.
반면 타입 시스템은 일단 도입만 하면 누구나 그 덕을 볼 수 있다. 팀 내의 프로그래머들의 역량이 뛰어나든 뛰어나지 않든. 훨씬 평범한 보통 사람에게 유리하다. 타입 시스템이 미봉책일 수는 있지만, 그 미봉책이 더 많은 사람들을 프로젝트에 참여할 수 있게 해준다고 생각한다.
친구 회사에서 react-form-mozard의 잠깐 언급되었는데, Generator 기반인게 문제가 되어 도입이 바로 기각되었다. yield*가 async, await, try, catch 등등과 달리 혐오스러운 외양을 갖고 있는게 문제가 되었다. 여러분 제발 키워드 차별을 멈춰주세요ㅠㅠ
마선생님이 그리웠는데 여기서 뵙네요(?)
식탁보 3.0을 준비하면서, 이번에 매우 흥미로운 기능을 하나 추가하게 되었습니다. Claude Desktop에서 MCP 서버로 식탁보를 등록하면, 원하는 금융 기관이나 공공기관에 샌드박스로서 접속할 수 있게 연결시켜주는 기능입니다.
현재는 카탈로그에 있는 사이트를 찾아주어 들어가는 정도이지만, 좀 더 강화하여 주요 기관들의 거래 및 업무 처리 URL들을 데이터베이스화하거나 Claude의 자체 검색 기능으로 찾은 웹 사이트 주소를 바로 전달하는 것도 기술적으로 가능하게 구현해둔 상태입니다. (이 때 해당 웹 사이트에서 쓰는 플러그인 정보가 있다면 샌드박스 내에 매칭해서 자동 설치도 해줍니다.)
차근차근 준비해나가고 있으며, 이번 추석 연휴 기간 중에 마무리 짓는 것을 목표로 진행 중이니 많은 관심과 성원 부탁드립니다! 😉
Did you know your MacBook has a sensor that knows the exact angle of the screen hinge?
It’s not exposed as a public API, but I figured out a way to read it and make it sound like an old wooden door.
Source code and a downloadable app to try it yourself: https://github.com/samhenrigold/LidAngleSensor
커뮤니티에서 정치적인 주제를 금지하면 결국 관리자가 보기에만 정치적이지 않은, 자기 입맛에 맞는 정치적인 글만 남더라구요
10만년만에 백엔드 코드를 건들기 시작했다
확실히 스타트업에 들어오고 충분한 시간이 지나면 풀스택이 되는게 맞다
의외로 잘 안 알려진 도구인데, mise가 정말 좋습니다. 다들 mise 쓰고 행복한 개발 하세요.
우리 Claude Code가 Claude Code를 공부하고 있어요
work ethic 좋은 동료분들과 일함으로써 얻는 개인적인 만족감이 좀 지대한 편이다. 코딩 실력이나 지식의 수준, 사업의 성공 같은 것들보다도, 동료분들의 어떤 면면들, 힘든 상황에서도 흔들리지 않고 옳음을 추구하려는 노력, 고고한 자정 정신 같은 게 참... 눈부시게 빛나고, 때로 존경스럽다.
코딩테스트 준비 뭐부터 하면 되나요?
- 이러면누가알려주겠지
@z9mb1wwj 자신의 레벨에 따라 다른데요,
- 코테 시스템 자체에 익숙하지 않은 경우(내 코드를 제출해서 채점을 받는다는 것에 익숙하지 않은 경우)
- 프로그래머스 - 코딩테스트 에서 Lv. 0 문제들을 풀면서 일단 코테 방식에 익숙해지는 것을 추천드립니다.
- 코테 문제들을 봤는데 너무 어렵다 - 기초 필요
- 기초적인 코테 알고리즘들을 책을 통해 공부하시는 것을 추천합니다. https://ebook-product.kyobobook.co.kr/dig/epd/ebook/E000002942452 나 https://product.kyobobook.co.kr/detail/S000001033111?utm_source=google&utm_medium=cpc&utm_campaign=googleSearch>_network=g>_keyword=>_target_id=aud-901091942354:dsa-435935280379>_campaign_id=9979905549>_adgroup_id=132556570510&gad_source=1 같은, 코딩 테스트를 다루는 서적을 집중적으로 공부해 보시는걸 추천드립니다(근처 도서관에 가시면, 코딩 테스트 관련 서적이 몇 권 있을 거에요).
- 나는 코테 좀 익숙한데 좀 어려운 문제 보면 주춤거림
- https://solved.ac/ 솔브드는 언제나 당신을 환영합니다.
역시 수제코딩을 해야 감각이 늘고 리터러시가 생긴다..... 뇌에 힘주고 해야하는건 수제코딩..
@kodingwarriorJaeyeol Lee 사람이 쓰는 프로그램 사람 손으로 만들자 - 수제코딩장려운동
단문(Note)과 긴 게시글(Article) 모두에서 Markdown을 지원할 뿐만 아니라 구문강조와 TeX 수식을 지원한다는 점에서 Hackers' Pub은 연합우주에서 가장 소프트웨어 프로그래머가 쓰기에 적합한 플랫폼이라고 자부합니다.
오늘은 정말 유익한 프로그래머 회식을 가졌다
- @kodingwarriorJaeyeol Lee 님의 피자 맛집 소개 및 퇴사 기념 무료 핏짜
- 함수형팔이, 언어팔이, IDE팔이들의 무제한영업제공사건
- 소비자는 관측되지 않음
‘앞/전’과 ‘뒤/후’의 비대칭성은 한국어 학습자들에게 지옥을 선사할 것이다.
참고로 이거 다 국립국어원의 잘못이 아니라 한국어의 잘못임. 이건 표준국어대사전이 그냥 현실을 반영했을 뿐이다. 즉 이 글을 읽고 있는 당신도 0.000001% 정도 잘못이 있다.
- ‘앞일’은 미래인데(예: 앞일을 예측하다), ‘뒷일’도 미래다(예: 뒷일을 부탁하네). 맞죠?
- 마찬가지로, ‘앞길’은 미래다(예: 앞길이 창창한 젊은이). 그런데 ‘뒷길’도 미래다(예: 자식의 뒷길을 생각하면 걱정이 앞선다).
- ‘뒷날’도 미래고(예: 우리는 뒷날 또 만나게 되었다), ‘훗날’도 미래다(예: 훗날을 기약하다). 그런데 ‘앞날’도 미래다(예: 앞날이 창창하다). 희한하게 ‘전날’만 과거이다.
- 그런데 ‘앞날’은 간혹 과거를 가리킬 수도 있다(예: 일찍이 앞날의 폭군은 있었고…).
- 관형사형에 ‘뒤’나 ‘후’를 붙여서 시점을 나타낼 수 있다(예: “고친 뒤의 모습” 또는 “고친 후의 모습”). 그런데 반대로 하려면 관형사형이 아니라 명사형을 써야 한다(예: “고치기 전의 모습”). 그리고, ‘전’만 쓸 수 있다. ‘앞’은 여기서 아예 쓸 수 없다.
- ‘후일’은 미래의 아무 날이나 다 가리키며, 특정한 날을 가리킬 수 없다. 반면 ‘전일’은 직전, 즉 인접한 과거의 1일만 가리킨다.
- 그런데 또 ‘전날’은 인접한 과거의 1일을 가리킬 수도 있고, 과거의 아무 날을 가리킬 수도 있다.
- 그런데 또 ‘훗날’은 미래의 아무 날을 뜻하며, 인접한 미래의 1일을 가리킬 수 없다.
- ‘전년’과 ‘후년’은 각각 과거의 아무 해, 또는 미래의 아무 해를 가리킬 수 있다. 대, 대칭인가?!
- 하지만 특정한 해를 가리키는 경우, ‘전년’은 인접한 과거의 해를 가리킨다. 반면 ‘후년’은 ‘올해의 다음다음 해’이다.
- …뭐라고? 왜냐하면 미래의 해들은 순서대로 ‘내년’-‘후년’-‘내후년’이기 때문이다. 책상 엎어버리고 싶죠?
- 참고로 ‘내후년’은 동음이의어이다. 올해가 2025년이라면 내후년은 2027년을 가리킬 수도 있고 2028년을 가리킬 수도 있다. (이게 언어냐?)
- ‘후년’이 ‘올해의 다음다음 해’가 되는 이 원리는 오직 ‘년’에만 적용된다. 예를 들어 ‘후일’, ‘후주’, ‘후월’ 등에는 그런 의미가 없다.
- ‘후일’은 미래의 아무 날이다. 하지만 ‘후주’와 ‘후월’은 인접한 미래의 것 하나만 가리킨다.
- ‘전년’은 인접한 과거의 해이지만, 과거의 모든 해를 다 가리킬 수도 있다(예: 우리는 전년의 기록들을 검토하여 그 사람의 행적을 조사해 보기로 했다).
- 반면 ‘전일’, ‘전주’, ‘전월’은 오직 인접한 과거의 하나만 가리킬 수 있다.
- ‘전달’과 ‘훗달’도 비대칭이다.
도대체 이걸 어떻게 배워서 쓰라는 것인지. 생각해 보면 나도 실제로 이렇게 쓰고 있다는 것도 기가 찬다.
그밖에:
- ‘지난날’에는 특정한 날을 가리키는 뜻이 전혀 없다. 반면 ‘지난주’, ‘지난달’, ‘지난해’는 모두 과거의 인접한 하나만 가리킨다.
- ‘다음 날’과 ‘다음날’은 의미가 완전히 다르다. ‘다음날’은 ‘정하여지지 아니한 미래의 어떤 날’이다. 따라서 인접한 미래의 1일을 가리킬 때에는 ‘다음 날’만 쓸 수 있다. (도저히 못 외우시겠으면 그냥 ‘이튿날’로 피신하시라…)
OpenFreeMap survived 100k requests per second
Link: https://blog.hyperknot.com/p/openfreemap-survived-100000-requests
Discussion: https://news.ycombinator.com/item?id=44846318
미안해 내가 더 잘 할게 우리 처음부터 다시 시작해보자
정보 리터러시 관련 의견을 보존하러 왔다. 우리는 흔히 영어 자료가 한국어 자료보다 낫다는 문화사대주의적 의견에 공감하곤 한다. 하지만 여기엔 숨은 의견이 여럿 있다. 하나씩 까보며 음미해보자.
영어 자료는 한국어 자료보다 낫다. => 왜 나을까? 도움이 되기 때문에. 왜 도움이 될까? => (진실에 가깝기 때문에, 다양한 경험이 전시되어 있기 때문에). 왜 진실에 가까울까? => 1차 출처에 가깝기 때문에. 왜 1차 출처에 가까울까? => 사용자가 다수이기 때문에 직접 사용하거나 번역되어 2차 출처로 기능하기 때문에. 왜 다양한 경험이 있을까? => 생산자가 자료 작성 시 영어를 선택할 확률이 한국어보다 높기 때문에.
그렇다면 우리는 영어 자료가 나은 이유를 구체적으로 표현할 수 있다.
- (일반적으로) 한국어 웹보다 영어 웹이 더 크기 때문에 원하는 자료를 구할 확률이 더 높다.
- (일반적으로) 한국어 웹보다 영어 웹에서 1차 출처에 가까운 자료를 구할 확률이 더 높다.
탐색 공간을 넓히고, 정보 전파 과정에서의 왜곡을 줄이기 위해서 영어 웹 탐색이 효과적이다. 다만 영어 웹이 "언제나" 좋은 건 아니다. 한컴오피스 자료가 미국에 많겠는가, 아니면 한국에 많겠는가? 1차 출처에 가까운 곳을 향해 왜곡을 줄이고, 그 안에서 탐색 공간을 최대한 효율적으로 넓혀야 한다.
영어 검색이라는 피상적인 행위에서 벗어나 정보 탐색의 본질을 좇는 것이 좋다.
오랜만에 프로그래밍 언어 이야기하러 왔다. 오늘 주제는 타입스크립트의 핵심 가치다.
많은 사람들이 정적 타입 언어를 도입하는 이유로 안전성(Soundness)를 이야기한다. 맞는 말이다. 하지만 타입스크립트에서 안전성은 2등 가치다. 그럼 1등 가치는 뭘까?
바로 개발 경험 개선이다. 구체적으로, 오류 나기 쉬운 구문을 적당히 줄이고 자동 완성을 개선하며 큰 규모 리팩토링 시 심리적(그리고 any 같은 기능을 안 썼다는 가정하에 런타임에도 유의미한 수준의) 안정성을 얻겠다는 거다.
타입스크립트 공식 위키 문서에도 안전성은 목표가 아니라고 나와있다 (#). 우리는 때때로 도구의 목적에 들어맞지 않는 불필요한 기대를 하곤 한다. 하지만 도구 개발자와 싸우는 건 사용자로서 좋은 전략이 아니다.
조건부 타입과 재귀 타입, 템플릿 문자열 타입, infer 등을 보라. 정적 분석 난이도가 지수적으로 올라가는 희한한 기능들이 언어에 계속 추가되는 이유가 무엇인가. 추론을 포기하고 any가 나오곤 하는 이유가 무엇인가.
그들이 추구하는 게 안전한 세계가 아닌 실용적인 세계이기 때문이다.
AI가 현실 세계에 주는 가치가 도대체 뭐가 있나 싶어 좀 회의적이었는데, 그나마 제일 효과적인 데가 개발 쪽이라면 테크 진영에서 아싸리 이쪽에 더 풀베팅 해줬으면 좋겠다. 그럼 이제 효과 대비 비용이 높아 그간 제대로 못 건드려왔던 도메인에도 소프트웨어 혁신의 햇볕이 닿게 되는 것이지. AI native가 될 이제부터의 개발자들은 kinda 지구에 큰 빚을 지고 있는 것이다. 최선을 다한 좋은 소프트웨어로, 보다 나은 세상을 만들지 못하면 곤란한...
비테 documentary is coming
Hackitty's Paw
modern-screenshot 이란 물건을 접하게 됐는데 얘는 html-to-image 로부터 포크 떠진 아이이고, 걔는 또 dom-to-image 로부터 포크 떠진 아이인데 vercel satori 가 더 낫다는 얘기도 본 것 같다. 한편, 우리 팀은 html2canvas 로부터 포크 뜬 html2canvas-pro 를 써보고 있었으며... (정신 없음)
시간이 지날 수록 Cursor랑 대화할 때 사용하는 주어가 바뀌는게 재밌네.
- 초반에는 "나 지금 XX를 만들고 싶어" 와 같은 식으로, 내가 작업의 메인이니까 넌 검색해와 같은 느낌에 가까웠다.
- 조금 익숙해지니까 점점 "너가 XX를 만들어 와" 라고 일을 위임하는 어조로 바꼈다.
- 그러다가 오늘 코드를 지칭할 때 무의식적으로 "우리가 만든 코드"라는 표현을 사용했다. 개발 사이클을 여러 번 돌리다보니 공동 저작물이라는 인식이 나도 모르게 생겼나보다.
연구실 홈페이지를 쉽게 만들고 관리 할 수 있는 pelican 기반 bolierplate를 만들고 있습니다...만, 이건 말이 bolierplate지 사실상 theme도 포함인거라 디자인이 좀 들어가있어야하는데... 여기서 막혔습니다,,, 다른 부분은 완전 완성인데ㅜㅜ
JS 라이브러리를 만들때 개발시엔 invariant check를 위해 assert를 쓰되, 배포할땐 빼고싶거든요. 어떤 좋은 방법이 있을까요?
@bglbgl gwyng Vite 같은 경우에는 기본적으로 import.meta.env.DEV이 빌드 시에는 false로 치환되어서 minifier 돌리면 안쪽 코드가 통째로 날아가게 할 수 있습니다. 다른 번들러들에서도 비슷한 방법을 찾아볼 수 있을 것 같네요
내 마음 속엔 해커즈 펍에 들어온 이상 나도 뭔가 이제 해커가 아니어선 곤란하다는 어떤 압박감 같은 것이 있다.. 뒤를 돌아 나가기보단 정말 해커가 되어 이 자리에 머무를 수 있어야겠지..
Song Yongseok shared the below article:
OSSCA: Fedify 프로젝트 기여자들을 위한 안내
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
이 글은 오픈 소스 컨트리뷰션 아카데미 참여자, 더 나아가 Fedify 프로젝트에 기여하고자 하는 모든 이들을 위한 안내서입니다. Fedify 프로젝트 참여를 위한 준비 사항과 소통 채널, 개발 환경 설정, 그리고 프로젝트 구조에 대한 이해를 돕는 것을 목표로 합니다. 먼저 Fedify Discord 서버에 참여하여 자기소개를 하고, 연합우주(fediverse)에 대한 기본적인 이해를 쌓기 위해 계정을 만들어보는 과제가 주어집니다. JavaScript와 TypeScript에 대한 간략한 소개와 함께, Fedify가 ActivityPub 프레임워크로서 연합우주 SNS 소프트웨어 개발을 쉽게 만들어주는 도구임을 설명합니다. 저장소를 포크하고 클론하는 방법, Node.js, Deno, Bun 등 다양한 런타임 환경 설정 방법, 그리고 Visual Studio Code를 활용한 개발 환경 구성 방법을 상세히 안내합니다. 마지막으로, Fedify 저장소의 구조와 린트, 테스트 실행 방법을 소개하며, 기여할 일감을 찾는 방법과 추가 정보 링크를 제공합니다. 이 글을 통해 독자는 Fedify 프로젝트에 실질적으로 기여하기 위한 첫걸음을 내딛을 수 있으며, 오픈 소스 기여에 대한 자신감을 얻을 수 있습니다.
Read more →한창 개발중인 다음 버전의 Hackers' Pub입니다. 프런트엔드를 전면 개편하고 있습니다. 프레임워크도 Fresh에서 SolidStart로 아예 바꿨습니다.
@mexicoreaSong Yongseok 안녕하세요! 반갑습니다!
@kodingwarriorJaeyeol Lee 덕분입니다. 잘 부탁드립니다 :)