I think the 
Lee Dogeon
@moreal@hackers.pub · 76 following · 69 followers
어느 한 개발자입니다.
GitHub- @moreal
내일(7월 1일) 개인 용무로 잠시 제주를 벗어나 서울에 이틀간 머물 예정인데요, 이날 5시 이후부터 여유 시간이 많아 만나서 이야기 나눌 분을 찾습니다.
자기소개 - 블로그 소개 및 Gravatar 프로필 참고
- 10여 년 전부터 웹 프로그래밍을 생산성과 취미로 즐겨하고 있는 컴퓨터 전공 4학년 학부생입니다.
- 이번 1학기에 졸업 요건을 대부분 만족하여 프런트엔드 개발 직군으로 구직 활동을 시작했습니다.
"대안: 의도를 선언하기" 부분이 아하 모먼트였습니다. 🤯
CPython 저장소에는 라벨을 달아놓으면 백포팅 PR을 알아서 만들어주는 봇이 있다 😲
https://github.com/python/cpython/pull/136027#issuecomment-3013426273
관련 이슈에도 알아서 PR 링크 걸어준다 😮
CPython 저장소에는 라벨을 달아놓으면 백포팅 PR을 알아서 만들어주는 봇이 있다 😲
https://github.com/python/cpython/pull/136027#issuecomment-3013426273
Hackers Pub은 개발자를 위한 블로깅 플랫폼이면서 SNS기능이 탑재된 흥미로운 서비스이지만, ActivityPub 프로토콜을 지원하여 Mastodon/Misskey/Thread 등의 SNS를 구독할 수 있는 연합우주 소프트웨어이기도 합니다.
연합우주 소프트웨어가 정확히 어떤 것인지 간단하게나마 파악할 수 있게 슬라이드로 정리해봤습니다. (해커스펍에 오지 않은 분들에게만 미공개)
기술적으로 어떤 물건인지 궁금하시다면 
@hongminhee洪 民憙 (Hong Minhee) 님이 쓰신 글도 한번 읽어보시는 것도 좋습니다.
막상 들어왔는데 어떤 계정을 팔로할지 모르겠다구요? 이 글도 참고할만할지도 모르겠네요.
해커스펍 온보딩 시각화자료도 준비해볼까 생각중이긴 한데, 뭐 암튼 적응에 도움되기를 바랍니다.
오픈소스 프로젝트에 여러분의 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 프로그래밍 사용량을 기여하는 것이 하나의 큰 축이 될 것입니다.
Hackers' Pub이 커뮤니티 자격으로 올해 파이콘 한국에 후원하게 되어, 8월 16일(土)–17일(日) 후원사 부스를 운영하게 되었는데요. 부스 운영을 도와주실 분을 한 분에서 두 분 정도 찾습니다! 이틀 중 하루만 도와주셔도 좋습니다. (당연하지만 저는 이틀 모두 나갑니다.) 도와주신 분께는 약소하지만 제가 점심과 저녁을 대접하겠습니다.
We're pleased to announce that #Node.js support has been merged and will be available in #BotKit 0.3.0.
Now you can build your #ActivityPub bots with both #Deno and Node.js, giving you more flexibility in choosing your preferred runtime environment.
Stay tuned for BotKit 0.3.0!
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 →GitHub 구현 세부사항이 바뀐 탓인지 깨진 것 같아서 PR을 올렸다. aria-label에서 aria-labelledby를 사용하게 변경되면서 기준점이 되는 버튼을 특정하기 위한 조건문이 참일 수 없게 되어서 조건문을 수정했다.
이미 누가 작업하고 있는 작업인지 여부를 쉽게 확인할 수 있을까?
Refined GitHub 확장의 list-prs-for-file 기능을 활용하면 확인할 수 있다
GitHub 구현 세부사항이 바뀐 탓인지 깨진 것 같아서 PR을 올렸다. aria-label에서 aria-labelledby를 사용하게 변경되면서 기준점이 되는 버튼을 특정하기 위한 조건문이 참일 수 없게 되어서 조건문을 수정했다.
VitePress localSearchPlugin 버그 디버깅하기
Lee Dogeon @moreal@hackers.pub
이 글은 Zenn 트렌드 봇 제작 중 VitePress 로컬 검색 기능의 버그를 발견하고 수정하는 과정을 담고 있습니다. Fedify 문서에서 검색 기능이 제대로 작동하지 않는 것을 확인한 후, 코드 블록 내의 특정 마크다운 문법(`markdown-it-jsr-ref` 플러그인)이 문제임을 밝혀냈습니다. VitePress의 `localSearchPlugin.ts` 파일을 분석하여, 헤딩 내의 `<a>` 태그를 처리하는 정규식의 non-greedy한 특성이 버그의 원인임을 알아내고, 정규식에서 `?` 기호를 제거하여 문제를 해결했습니다. PR을 통해 수정 사항을 제안하고 빠르게 머지된 경험을 공유하며, 디버깅 과정과 PR 준비에 대한 회고와 함께 개선점을 제시합니다. 이 글은 문제 해결 과정과 디버깅 경험을 통해 독자들에게 인사이트를 제공합니다.
Read more →이미 누가 작업하고 있는 작업인지 여부를 쉽게 확인할 수 있을까?
Refined GitHub 확장의 list-prs-for-file 기능을 활용하면 확인할 수 있다
블로그 글로도 적어봤습니다. 재현 환경 구성 하는거 너무 노가다인데 어떻게 잘 할까..
Hackers' Pub으로도 가져왔습니다
https://hackers.pub/@moreal/2025/vitepress-localsearchplugin-debugging
VitePress localSearchPlugin 버그 디버깅하기
이 글은 Zenn 트렌드 봇 제작 중 VitePress 로컬 검색 기능의 버그를 발견하고 수정하는 과정을 담고 있습니다. Fedify 문서에서 검색 기능이 제대로 작동하지 않는 것을 확인한 후, 코드 블록 내의 특정 마크다운 문법(`markdown-it-jsr-ref` 플러그인)이 문제임을 밝혀냈습니다. VitePress의 `localSearchPlugin.ts` 파일을 분석하여, 헤딩 내의 `<a>` 태그를 처리하는 정규식의 non-greedy한 특성이 버그의 원인임을 알아내고, 정규식에서 `?` 기호를 제거하여 문제를 해결했습니다. PR을 통해 수정 사항을 제안하고 빠르게 머지된 경험을 공유하며, 디버깅 과정과 PR 준비에 대한 회고와 함께 개선점을 제시합니다. 이 글은 문제 해결 과정과 디버깅 경험을 통해 독자들에게 인사이트를 제공합니다.
hackers.pub · Hackers' Pub
Link author:
VitePress localSearchPlugin 버그 디버깅하기
Lee Dogeon @moreal@hackers.pub
이 글은 Zenn 트렌드 봇 제작 중 VitePress 로컬 검색 기능의 버그를 발견하고 수정하는 과정을 담고 있습니다. Fedify 문서에서 검색 기능이 제대로 작동하지 않는 것을 확인한 후, 코드 블록 내의 특정 마크다운 문법(`markdown-it-jsr-ref` 플러그인)이 문제임을 밝혀냈습니다. VitePress의 `localSearchPlugin.ts` 파일을 분석하여, 헤딩 내의 `<a>` 태그를 처리하는 정규식의 non-greedy한 특성이 버그의 원인임을 알아내고, 정규식에서 `?` 기호를 제거하여 문제를 해결했습니다. PR을 통해 수정 사항을 제안하고 빠르게 머지된 경험을 공유하며, 디버깅 과정과 PR 준비에 대한 회고와 함께 개선점을 제시합니다. 이 글은 문제 해결 과정과 디버깅 경험을 통해 독자들에게 인사이트를 제공합니다.
Read more →블로그 글로도 적어봤습니다. 재현 환경 구성 하는거 너무 노가다인데 어떻게 잘 할까..
Arstechnica 에서 이런 글을 보았습니다.
A history of the Internet, part 2: The high-tech gold rush begins
제가 이것저것의 역사에 대하여 흥미가 많다는 말을 여기에 쓴 적이 있던가요? 게임이라거나 컴퓨팅이라거나 ...
사실 대강의 사연을 알고있던 저 2편보다는, 제가 모르던 사연이 더 많은 1편 An Ars Technica history of the Internet, part 1이 더욱 흥미로웠습니다.
그 와중에 글을 쓰는 방식과 디테일들이 마음에 들어서 글쓴사람을 클릭해보니 와우' -' 보물창고가 쨘 하고 나타나는 것이었습니다.
일단 처음에 눈에 띄여서 이 시리즈를 읽었습니다. 재미있었어요.
- A history of ARM, part 1: Building the first chip
- A history of ARM, part 2: Everything starts to come together
- A history of ARM, part 3: Coming full circle
그래서 ARM의 원래 이름은 Acorn RISC Machine. 도토리 RISC 머신이었던 것입니다 ' -' ...
다음에는 Amiga 의 역사를 읽어볼 생각이에요. 두근두근.
앞으로 Ars Technica 에 자주 가게 될 것 같네요. 어제까지는 그냥 "나와 비슷한 관점으로 이야기하곤 하는 웹진"이었는데요.
이야. 여기 컴퓨팅 역사 맛집이었어요.
Bill Atkinson, architect of the Mac’s graphical soul, dies at 74 를 통하여 30-plus years of HyperCard, the missing link to the Web를 알게 되었고, 위키피디아에서 HyperCard 항목을 읽었습니다. 하이퍼링크와 웹의 역사에 관해 이것저것 읽으면서 Project Xanadu 같은 것은 들어본 적이 있었지만, HyperCard 에 대해서는 오늘 처음 알게되었습니다. 기쁘네요.
역사는 사물의 본질에 대하여 여러 각도로 이해할 수 있는 수단이라 많이 좋아합니다:)
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 →JSR의 @std/* 패키지들이 모두 npm에도 올라왔으면 좋겠다. 하지만 그럴 일은 없겠지…
@hongminhee洪 民憙 (Hong Minhee) 지나가면서 JSR이 라이브러리 만드는 입장에서는 불편하다.. 같은 걸 들은 것도 같은데, JSR을 사용하시는데 있어서 불편한 점이 있으신가요?
오늘 발견한 흥미로운 링크들: Matt 타입스크립트 선생님은 종종 Effect 에 대해 트윗하는데 주로 이펙트를 찍먹해보시고 이걸 강의로 만들까말까 만들까말까 하신다. Michael EffectTS 의 BDFL 은 종종 맷 선생의 트윗에 답글을 달아 이펙트 얘기를 풍부하게 가꿔주신다.
오늘은 이펙트의 굿파츠에 대한 얘기로 스레드가 열렸다. https://x.com/mattpocockuk/status/1936083553483157714
나도 EffectTS 도입을 하고 싶지만 여러모로 기존 바닐라JS 스펙과 다른 모양의 코드가 나와서 여러모로 망설이고 있다. (내 기준 이펙트는 실행 코드를 작성하기 보다 실행 계획을 작성하는 개념으로 접근하고 있다) 프로덕션 코드를 새로 만든다면 EffectTS 도입을 고려하고 있지만 학습 난의도가 있어 이를 위해 함께 스터디하고 코드 마이그레이션 계획도 세워야하는데, 그럴 여유는 보통 없는게 현실.
아직은 neverthrow 부터 사용해보는 정도가 지금의 최선이라고 생각한다. 나는 throw 기반의 조건 제어 코드가 불편하다. try catch 안에서 if 절로 throw 하는 코드를 볼 때마다 불만이다. 복구할 수 있는 에러는 throw 하지 않는게 옳다고 생각한다. 물론 언어의 문제도 있지만... 그렇게 스레드를 읽던 중 effectively 라는 애매한 이름의 Alegbraic effects 를 구현한 라이브러리가 공개되어 있다는 것을 발견했다. 작성자 본인도 뻔뻔하게 홍보한다고 어필하고 있다. ;) effectively
EffectTS 라는 이름도 애매하지만 Effectively 는 더 애매하다. 인기가 많아지기 전에 그럴듯 한 이름으로 브랜딩되면 좋겠다. 아, 그렇게 생각하는 이유는 TS 씬에 이런 라이브러리/프레임워크가 자주 거론되면 좋겠다는 생각 때문이다.
얘기하고 싶은 것은, 아이러니하게 이 effectively 의 readme 가 매우 간결하고 읽기 쉽게 EffectTS 에 대해 소개하고 있기 때문이다. effect.website 의 문서는 뭔가 개선이 필요하다. 없는게 없이 다 있지만 실제 읽다보면 어려운 부분이 많고 더 많은 설명이나 예제가 필요한 경우가 생긴다. 미카엘 본인도 문서 개선 필요는 공감하는 것 같다. (해당 스레드 발언 추정) 그리고 또 다른 유저가 포스트를 안내해주셨는데, Effect-like code without Effect 짧게 읽기 좋다. 게다가 이 포스트가 담긴 사이트의 프로덕트도 유용해 보인다.
시작부터 Result 나 Optional 을 제공하는 언어가 많은 소프트웨어 엔지니어들에게 높은 선호도를 가지는 이유가 있다고 본다.
- 1.0 릴리스는 2026년 예정
- 베타 릴리스를 함으로써 코어 언어 기능은 이제 안정적
- 표준 라이브러리와 툴체인은 계속 바뀔것
https://github.com/krafton-ai/Orak
Orak (오락) is a foundational benchmark for evaluating Large Language Model (LLM) agents in diverse popular video games.
@hongminhee洪 民憙 (Hong Minhee) hackers.pub 을 구동시키는 Fedify 프로젝트라고 광고하셔야죠 ㅋㅋ
mmap을 백엔드로 Vec 같은 인터페이스를 쓸수 있는 프로젝트, memvec 입니다. AI의 힘으로 문서를 보충하여 0.2.0 을 릴리즈했습니다. https://crates.io/crates/memvec
C# NotNull 같은 기능을 TypeScript에서는 asserts <arg> is Exclude<T, null> 같이 쓸 수 있고 vitest에서는 assert.isNotNull처럼 쓰면 되더라 📝
React 문서 읽다가 _단어_는 처럼 되어있는 부분이 렌더링이 되지 않아서 CommonMark 스펙을 보니 중간에 들어간 강조는 처리하지 않는 것이 의도된 사항이다.
Many implementations have also restricted intraword emphasis to the * forms, to avoid unwanted emphasis in words containing internal underscores. (It is best practice to put these in code spans, but users often do not.)
때문에 *단어*는 을 쓰는 것이 맞다. 그런데 한글은 기울임꼴로 썼을때 옆 글자를 침범하기도 하여 보기 좋지 않았다. 그래서 관련해서 찾아보니 아래와 같은 논의가 있어서 단문으로 남겨놓는다.
https://github.com/mdn/translated-content/issues/1537
한국타이포그라피학회의 관련 연구도 있더라 😮
http://koreantypography.org/wp-content/uploads/thesis/kst_j0_1.pdf
2개월 전에 애자일 이야기 글을 편하게 읽고 싶었던 것과 검색 기능의 필요를 느껴 삼아 작성했던 프로젝트[1]를 아카이브 했습니다. 글도 다 읽었고 읽으면서 수정하다 보니 내가 쓸만큼의 무언가는 되어서 특별히 더 동기가 남아있지 않았기 때문입니다. 불필요하게 SSR로 돌려서 서버 비용이 나가는 것이 걱정거리로 남아있었는데 그것도 어제 오늘 작업해서 이제는 GitHub Pages로 배포하기 때문에 아카이브할 수 있게 되었습니다. 그냥 놔둬도 괜찮지만 괜히 신경 쓰여서 아카이브로 돌려놓습니다.
코드 퀄리티는 좋지 않을텐데... 혹여나 수정이 필요하신 분은 AGPL-3.0 라이센스이니 편하게 포크해서 사용하시면 될 듯합니다.
https://github.com/moreal/agilestory.blog/
https://agilestory.blog
아카이브된 옛날 글을 보면 플래시를 쓰는 경우가 있어서 Ruffle 같은 걸 써서 지원해야 하나 했었는데, Internet Archive에서는 이미 Ruffle로 플래시 파일들을 지원하는구나
https://blog.archive.org/2020/11/19/flash-animations-live-forever-at-the-internet-archive/
React 문서 읽다가 _단어_는 처럼 되어있는 부분이 렌더링이 되지 않아서 CommonMark 스펙을 보니 중간에 들어간 강조는 처리하지 않는 것이 의도된 사항이다.
Many implementations have also restricted intraword emphasis to the * forms, to avoid unwanted emphasis in words containing internal underscores. (It is best practice to put these in code spans, but users often do not.)
때문에 *단어*는 을 쓰는 것이 맞다. 그런데 한글은 기울임꼴로 썼을때 옆 글자를 침범하기도 하여 보기 좋지 않았다. 그래서 관련해서 찾아보니 아래와 같은 논의가 있어서 단문으로 남겨놓는다.
https://github.com/mdn/translated-content/issues/1537
한국타이포그라피학회의 관련 연구도 있더라 😮
http://koreantypography.org/wp-content/uploads/thesis/kst_j0_1.pdf
오픈소스 컨트리뷰톤이..... 다음주까지 마감인 사실... 라시나요...?
#자기소개 를 해볼까요.
@ranolpRanol☆P 와 동일인입니다...만 해당 계정은 근시일 내에 살릴 계획이 없습니다.
@ranolp 계정은 프로그래밍 언어론/해커스펍 사용기 위주 계정입니다.
- 다시 말하자면 그 외 일상적인 내용은 트위터에서 이야기한다는 뜻입니다...
- TypeScript와 얼추 호환되면서 제정신인 타입 추론 규칙을 가진 언어를 만들려고 타입 이론을 공부하고 있습니다.
- 좀 많이 전에는 Bidirectional Typing (J. Dunfield, N. Krishnaswami)을 읽었었고,
- 독일에 있는 튀빙겐 대학 내에서 연구하는 대수적 효과 언어 Effekt도 간단히 살펴보았었습니다.
- 최근에는 힌들리-밀너-다마스 타입 추론 위에 얹은 부타입 확장을 살펴보고 있습니다.
- 캠브릿지 대학 연구인 MLsub (S. Dolan and A. Mycroft)...
- 을 단순화한 Simple-sub (L. Parreaux)을 시작으로 MLstruct, Ultimate Conditional Syntax 등 홍콩대 연구를 많이 보고 있습니다
- MLscript가 정말 흥미로운 언어에요 ReScript but more Kotlin처럼 생겼음
- 올해 들어서 An Infinitely Large Napkin으로 군론과 군의 작용, 위상수학과 대수 위상(호모토피만), 그리고 범주론을 배웠습니다.
- 형식적 증명 보조기에도 관심이 많습니다.
- Software Foundation을 통해 Coq (현 Rocq)를 약간 배웠습니다.
- Lean 4도 약간 맛보기를 했습니다.
- 의존 타입/마틴 뢰프 타입(MLTT)/호모토피 타입(HoTT) 등을 배워 간단한 증명 보조기도 만들어보고 싶네요.
- 아마 An Infinitely Large Napkin 스터디가 끝나면 HoTT 스터디를 하지 않을까 싶네요.
안녕하세요, 페미위키 개발팀입니다. 개발팀 활성화를 위해 이리저리 둘러보다 해커스펍에 대해 알게 되었습니다. 여건이 되면 페미위키 개발에 대해서 얘기할 수 있는 기회를 만들어보려 합니다!
더불어 페미위키 개발팀에서 오픈소스 컨트리뷰터 & 개발팀을 모집합니다! 페미니스트시라면 정체성 불문, 거주국 불문하고 모시고 있습니다. 함께 페미니즘 정보집합체 만들어가요!
@hongminhee洪 民憙 (Hong Minhee) 엇 저 Reports of Deno's Demise Have Been Greatly Exaggerated 글 읽고서 글에 있는 링크따라 계정 페이지에서 Early Access 신청해놨었는데 언젠가부터 디스코드 deploy-ea 채널도 보이고 그랬던 것 같습니다 🤔
@hongminhee洪 民憙 (Hong Minhee) 아 근데 오늘 새벽 공지 보니까 deploy-ea 채널에 있으면 자동으로 얼리 엑세스에 참여할 수 있나봐요. 저 Discord Early Access Role만 얻으면 될지도... 🤔
@hongminhee洪 民憙 (Hong Minhee) 엇 저 Reports of Deno's Demise Have Been Greatly Exaggerated 글 읽고서 글에 있는 링크따라 계정 페이지에서 Early Access 신청해놨었는데 언젠가부터 디스코드 deploy-ea 채널도 보이고 그랬던 것 같습니다 🤔
기존 MAU가 몇인지는 모르겠지만 Deno 2 이후로 수치가 2배가 되었다고 한다. 최근에 Node.js 호환성 지원이 좋은 선택이었을까 같은 의문을 던졌었는데 아무래도 효과가 크기는 했던 모양이다.
그리고 Deno Deploy에 배포되는 서버들이 보통 단일 리전에 위치한 데이터베이스와 소통하는 풀스택 앱이었는데 과다 트래픽으로 인해 다른 리전으로 보내게 되면 지연시간이 급증하였다고 한다. 특정 리전에 고정하여 사용하거나, 셀프 호스트 리전을 운용할 수 있다고 하는 것 같은데 어떤 모양새로 나올지 모르겠지만 요 부분이 가장 기대된다 👀
뒷부분은 스킵..
셀프 호스트는 Enterprise 플랜에서만 쓸 수 있나보네
한국 페디버스 개발자 모임에서 주최한 스프린트에 다녀왔다. 기여하고자 했던 https://github.com/fedify-dev/fedify/issues/169 는 또 JSON-ish 관련 이슈로 해결하지 못했지만 소규모 모임에서 얻을 수 있는 좋은 분위기와 에너지를 맘껏 느껴 좋았다. PR은 보내지 못했지만 Fedify 마스코트(이름 없음)로 키링 만들어 나눠드려 그나마 다행이었다. 행사 준비하고 진행해준 @hongminhee洪 民憙 (Hong Minhee) 님께 감사드린다.
페디버스 행사가 있는 날에 하필 트위터 서비스가 고장나서 오랜만에 마스토돈에 글 남겨본다 ㅋㅋ
오늘 박현우 님(
@lqezPark Hyunwoo)께서 Fedify 로고로 배지를 만들어 와주셨습니다! FediDev KR 두 번째 스프린트 모임 오신 분들께 나눠드리고 있어요.
최근 Deno Deploy의 리전이 줄어든 것을 포함하여 이야기가 나왔던 Deno의 쇠퇴에 대한 오해를 풀기 위한 해명문(?) 같다.
기존 MAU가 몇인지는 모르겠지만 Deno 2 이후로 수치가 2배가 되었다고 한다. 최근에 Node.js 호환성 지원이 좋은 선택이었을까 같은 의문을 던졌었는데 아무래도 효과가 크기는 했던 모양이다.
그리고 Deno Deploy에 배포되는 서버들이 보통 단일 리전에 위치한 데이터베이스와 소통하는 풀스택 앱이었는데 과다 트래픽으로 인해 다른 리전으로 보내게 되면 지연시간이 급증하였다고 한다. 특정 리전에 고정하여 사용하거나, 셀프 호스트 리전을 운용할 수 있다고 하는 것 같은데 어떤 모양새로 나올지 모르겠지만 요 부분이 가장 기대된다 👀
뒷부분은 스킵..