무슨 이야긴가 궁금해서 찾아보고 …. 너무 귀여워서 비명을 질렀어요…. 토끼가 전선을 갉아먹어서 서버가 다운되다니……..
bgl gwyng
@bgl@hackers.pub · 81 following · 91 followers
슈티를 함께 만들 팀을 만들고 있습니다. 관심 있으신 분, 또는 잘 모르겠지만 이야기를 나눠보고 싶은 분도 bgl@gwyng.com으로 편하게 연락주세요.
GitHub- @bglgwyng
shootee- www.shootee.io
@hongminhee洪 民憙 (Hong Minhee) 너무 가고 싶은데 육아 때문에 갈 수가 없어서 너무 아쉽습니다. 마음 같아서는 유튜브 라이브 해달라고 하고 싶어요.
@curry박준규 @hongminhee洪 民憙 (Hong Minhee) 아이를 델고오셔서 인류 최초의 네이티브 하스켈 스피커로 키워보는건 어떨까요?
@curry박준규 고맙습니다!
@hongminhee洪 民憙 (Hong Minhee) 서울하스켈숲 1회 워크샵 참가 신청서 링크가 공개되었습니다. 다만 대상이 ‘하스켈을 잘 모르는 사람’이네요⋯
@bglbgl gwyng @curry박준규 그것도 그렇네요. “하포자”라니… 😂
@hongminhee洪 民憙 (Hong Minhee) @curry박준규 마지막 5회차에서 모나드 가르치고 있는데 태반은 ADT 정의를 못 읽고 있었습니다. Elixir 하던 특정 팀만 잘 따라왔었어요.
@hongminhee洪 民憙 (Hong Minhee) 서울하스켈숲 1회 워크샵 참가 신청서 링크가 공개되었습니다. 다만 대상이 ‘하스켈을 잘 모르는 사람’이네요⋯
@curry박준규 @hongminhee洪 民憙 (Hong Minhee) 저의 회사에서 하스켈 부트캠프 진행해본 경험으로 조교가 꼭 필요하다고 생각합니다. 이미 하스켈 잘아시는분들이 가서 도와줄 필요가 있어요. 왜냐면 기초 문법부터 생소해서 하포자 엄청 일찍부터 생깁니다.
아마도 2006년이었던 것 같다. 처음 가본 대안언어축제에서 정말 충격적인 체험을 했었다. 당시는 Python이 대안 언어였던 시절… Io도 배우고 J도 배우고 Haskell도 배우고. 고등학생 때였는데, 동아리 사람들을 모두 데려가서 어른들에게 예쁨 받았던 기억도 있다. 행사가 어디서 후원을 받았었는지 기억은 안 나지만, 후원을 아주 크게 받았던 것만 기억이 난다.
RE: https://hackers.pub/@kodingwarrior/0195d560-1a2e-73db-847f-cd71b4d18653
bgl gwyng shared the below article:
복잡한 코드를 단순하게 줄여나갈 수록 발생하는 버그의 빈도나 심각도가 점진적으로 올라가는 경향이 있다고 느낀다
ㄹ @disjukr@hackers.pub
이 기술 블로그 포스팅에서는 코드 복잡도와 버그 심각도 사이의 미묘한 관계를 탐구합니다. 저자는 복잡도를 높이는 방향으로 문제를 해결할 때, 버그 빈도와 심각도를 점진적으로 줄일 수 있지만 최적의 해결책에 도달하지 못할 수 있다는 점을 지적합니다. 반대로, 복잡도를 낮추는 방향으로 접근하면 문제 해결에 드는 비용을 예측하기 어렵다는 어려움이 있습니다. 특히, 회사에서 코드 복잡도를 줄이는 대신 높이는 방향으로 문제 해결을 요구받는 상황에서 엔지니어로서의 자아와 현실 사이의 괴리를 느끼는 저자의 고충이 드러납니다. 개인 시간을 투자하여 더 나은 해결책을 찾아도, 이를 회사에 도입하는 데 많은 설득 비용이 소요된다는 점을 강조하며, 회사 내에서 자아실현을 포기해야 하는지에 대한 고민을 토로합니다. 이 글은 기술적 효율성과 조직적 요구 사이의 균형을 찾는 데 어려움을 겪는 개발자들에게 깊은 공감을 불러일으킬 수 있습니다.
Read more →인프라 작업을 점점 더 할수록 문제가 생겼을때 재부팅을 시도하는 시점이 앞당겨지고 있다. 그리고 그게 통한다...
개인적으로 Hackers' Pub 행동 강령에서 내세우고 싶은 곳이 있다면 이 부분이예요:
구조적 차별과 불평등에 대한 우리의 입장
우리는 현실 세계의 구조적 불평등이 온라인 공간에도 그대로 반영되고 있다는 현실을 직시합니다. Hackers' Pub은:
- 성차별, 인종차별, 장애인 차별 등 우리 사회에 만연한 구조적 차별이 존재한다는 현실을 인식하고, 이러한 차별에 반대합니다.
- “모든 사람을 동등하게 대우한다”는 명목 하에 이러한 구조적 불평등을 무시하거나 부정하지 않습니다.
- 사회적 약자와 소수자에 대한 적극적인 포용 정책이 진정한 평등을 향한 필수적인 과정임을 확신합니다.
- 차별과 혐오에 대항하는 발언과, 차별과 혐오 자체를 동일선 상에 두지 않습니다.
- 우리는 이러한 구조적 차별이 결코 정당화될 수 없으며 반드시 극복되어야 할 과제임을 분명히 합니다.
bgl gwyng shared the below article:
Browser-Native Translation and Language Detection APIs Coming Soon
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Just reviewed the W3C draft for the Translator and Language Detector APIs. This is genuinely exciting development for web developers.
The proposal would add native browser support for:
- Text translation between languages
- Language detection of arbitrary text
- Both with streaming capabilities
No more relying on third-party translation services or embedding external APIs for basic language operations. All processing happens locally in the browser.
The API design is clean and straightforward:
// Translation example
const translator = await Translator.create({
sourceLanguage: "en",
targetLanguage: "fr"
});
const translatedText = await translator.translate("Hello world");
// Language detection example
const detector = await LanguageDetector.create();
const results = await detector.detect("Hello world");
// Returns array of detected languages with confidence scoresThis will be a game-changer for multilingual sites and applications. The browser handles downloading appropriate language models and manages usage quotas.
The spec is still in draft form but shows promising progress toward standardizing these capabilities across browsers. Looking forward to seeing this implemented.
@bglbgl gwyng 음, 듣고 보니 그렇네요. “맞팔하기” 정도로 바꾸면 좀 나으려나요?
@hongminhee洪 民憙 (Hong Minhee) 제가 보기엔 '맞팔하기'면 충분히 좋은거 같습니다.
@hong_minhee洪 民憙 (Hong Minhee) '맞팔로'라는 레이블이 저는 좀 헷갈리는거 같습니다. 그동안 '맞팔로'라고 뜬 사람들이 '맞팔로'가 되어있는 상태인줄 알았습니다. 그래서 팔로를 안하고 있었는데요. 팔로/언팔로랑 달리 동작인지 상태인지가 헷갈리네요.
솔직히 나는 한 번도 corepack의 개념을 제대로 이해한 적이 없다… 걍 쓰라고 해서 따라 쳐서 썼을 뿐. 나 같은 사람이 더 있을 거라고 생각.
@hongminhee洪 民憙 (Hong Minhee) 저는 corepack 없어진다음에야 그런게 있었다는 사실을 알게 되었네요
옛날에 만들어놓고 저 혼자는 잘쓰고 있는 React 폼 라이브러리 react-form-mozard를 소개합니다.
폼 중에서 Stepper 또는 Wizard라고 하는, 여러 개의 폼을 순차적으로 합친 형태를 다룰때 씁니다. 그래서 하나의 폼에 대해서는 react-hook-form 등 을 쓰고, 그걸 여러개 조합할땐 react-form-mozard를 활용하면 됩니다.
순차적으로 합친 에서 느낌이 오지요? 모나드가... 그대를 부릅니다...
폼 말고 CLI를 만들때를 잠깐 생각해보죠.
const name = prompt("이름이?")
const age = prompt(`{name} 님, 나이가?`)
if (Number(age) < 20) {
console.info("미성년자는 이용할 수 없습니다")
return
}
const gender = prompt(`{name} 님, 성별이?`)뭐 이런 흐름을 생각해볼 수 있는데요. 보시면 먼저 받은 입력값에 따라 이후의 메시지나, 제어 흐름이 달라질 수 있습니다. 즉, 모나딕하죠. 근데 이런 평범한 로직을 Stepper/Wizard 에서 짜게되면 코드게 쉽게 더러워 지는걸 알수 있습니다.
react-form-mozard의 step은 위 예제의 prompt와 같은 역할을 합니다. 그리고 그걸 Generator 위에 얹으면 모나딕한 폼 합성이 가능해집니다.
단점이라면... 지금은 React랑 강결합 되어 있어, XState 등 다른 상태관리 라이브러리를 같이 쓴다면 연동이 깔끔하지 않을수 있습니다. 근데 평소에 쉽게 겪을 문제는 아니라고 보고, 또 추후에 설계를 수정해서 개선이 가능한 부분입니다.
#TeamSpaces is currently beating #TeamTabs, but only barely.
@
코틀린+스프링 백엔드 개발하다가 지금은 프론트엔드 개발하고 있다는게 다른 사람들에게 꽤 재밌는 이야기로 다가오는 것 같다. 당연히 선택의 이유에 대한 질문을 가장 많이 받는데, 가장 특이한 질문은 OOP가 그립지 않은지(?)라는 질문. (OOP도, AOP도 전혀 그립지 않다.)
그리고 이런 입장에서 BE vs FE 같은 대결 구도가 조금... 그렇다. 사실 업무상 관점이 좀 다를 수는 있어도, 다른 직군으로 분류할 정도로 기술적 관심사나 고민의 주제가 그렇게 까지 다른가 싶기도. 나중에 이 생각의 해상도를 좀 더 높여봐야겠다.
소프트웨어 개발자들이 자주 틀리는 외래어 표기법.
| 영어 | 틀린 표기 | 올바른 표기 |
|---|---|---|
| app | 어플 | 앱 |
| application | 어플리케이션 | 애플리케이션 |
| directory | 디렉토리 | 디렉터리 |
| front-end | 프론트엔드 | 프런트엔드 |
| message | 메세지 | 메시지 |
| method | 메소드 | 메서드 |
| release | 릴리즈 | 릴리스 |
| repository | 레포지토리 | 리포지터리 |
또 있을까요?
'탈중앙'같은 키워드가 대다수 사용자에게는 그다지 매력적이지 않은게 사실이지만, 적어도 나는 오래 전부터 RSS에서 얻고자 했던 것과 얻지 못 했던 것을 ActivityPub으로 얻을 수 있어서 너무 좋다. 특히 콘텐츠 생산자 입장에서는 정말 참여하지 않을 이유가 없을 것 같은데...
액티비티펍을 사용하는지는 중요하지 않지만 제품이 훌륭하면 그 기반이 되는 액티비티펍이 장점을 더욱 발휘하는게 있는 것 같음. 액티비티펍이 장점으로 먼저 내세워져서는 안되는 것 같음. 액티비티펍을 쓰는지는 개발자한테나 어필이 되는 것이 아닌가..
@curry박준규 완전 기대되네요. 약간, 다 아는 사람들이구먼... 이 그려지긴한데ㅋㅋ
@bglbgl gwyng 흥미로운 문제 풀 때는 하느님 생각이 안 나더라고요… ㅋㅋㅋ
@hongminhee洪 民憙 (Hong Minhee) 그렇네요ㅋㅋ 댓구를 맞추려고 하다보니 하지도 않는 생각을ㅋㅋ
다들 개발할때 '하느님 제게 왜 이딴 시련을 : 하느님 이런 흥미로운 문제를 풀 기회를 주셔서 감사합니다'의 비율이 어떻게 되시나요? 저는 근 몇달간은 거의 99:1에 육박하는거 같습니다
"es-git은 Node.js를 위한 현대적인 git 라이브러리예요. 간편하고 직관적인 인터페이스 덕분에 복잡한 git 작업도 쉽게 통합할 수 있으며, TypeScript 타입을 내장해 빠르고 안정적인 개발을 지원해요." https://github.com/toss/es-git
bgl gwyng replied to the below article:
Hacker's Pub에 입문한 한국어권 여러분을 위한 안내서
Jaeyeol Lee @kodingwarrior@hackers.pub
Hacker's Pub은 소프트웨어 업계 종사자들이 자유롭게 생각을 공유하고 소통할 수 있는 소셜 네트워크 서비스이자 블로깅 플랫폼입니다. ActivityPub 프로토콜을 지원하여 Mastodon, Misskey 등 다른 SNS 서비스 사용자들과도 연결되어 플랫폼 경계를 초월한 소통이 가능합니다. 이 글에서는 Hacker's Pub의 의미와 ActivityPub 프로토콜에 대한 간략한 소개, 그리고 커뮤니티에 기여할 수 있는 다양한 방법을 제시합니다. 오픈 소스로 개발되는 Hacker's Pub 생태계에 참여하여 함께 서비스를 발전시키고, 우리만의 클라이언트를 만들어 Hashnode와 같은 블로그 템플릿을 구축하는 미래를 기대해 볼 수 있습니다. Hacker's Pub은 상호 존중과 신뢰를 바탕으로 모든 이들이 자유롭게 의견을 나누고 함께 만들어가는 공간입니다.
Read more →@kodingwarriorJaeyeol Lee 좋은글 감사합니다
I just discovered why some of my followers from larger #Mastodon instances (like mastodon.social) would mysteriously unfollow me after a while!
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
Hello, world!
블루스카이를 연합우주보다 먼저 썼고, 해커뉴스에서 관련 주장에 대해서 꽤 싸우기도 한 입장에서 민희님의 글 〈Bluesky는 X의 훌륭한 대안일 수 있지만, 연합우주의 대안은 아닙니다〉에 대한 반대 의견을 제시하고자 한다. 이 의견이 연합우주에 대한 전면적인 비판이 아니라는 것을 의견을 제시하기에 앞서 확실히 해 둔다(그랬다면 Hackers' Pub에 들어 올 일이 없었겠지).
탈중앙화는 매력적인 개념임이 틀림 없다. 인터넷의 많은 중요한 요소들이 어느 정도 탈중앙화되어 있으므로 탈중앙화가 인터넷의 장점들에 큰 몫을 했다는 생각을 쉬이 할 수 있고, 어느 정도는 그게 사실이기도 하니까. 하지만 엄밀히 말하자면 탈중앙화는 기술적인 특징이지 그 자체로 장점이 아니며, 탈중앙화가 장점으로 작용하려면 연결고리가 필요하다. 이를테면 비트코인을 위시한 암호화폐는 본디 비잔틴 실패까지 대비할 수 있는 강력한 탈중앙화를 장점으로 내세웠으나, 결국 화폐로서 제대로 사용되기 시작하자 현실 경제와의 커플링 때문에 그 "장점"이 크게 희석되고 말았다. 현 시점에서 암호화폐는 무에서 유의 신뢰를 창조하여 신용화폐의 요건을 충족하는 데까지는 성공했고 그것만으로도 역사적인 일이기는 하지만, 그게 탈중앙화랑 무슨 상관이 있느냐 하면 글쎄올시다.
블루스카이가 연합우주보다 덜 탈중앙화되어 있음은 분명하다. 민희님의 글에서 지적되었듯, 블루스카이가 이런 선택을 한 가장 큰 이유는 온전한 소셜 네트워크 기능을 위해 전역 뷰가 필수적으로 필요하다고 보았기 때문이다. 반대로 말하면 연합우주는 더 탈중앙화를 하기 위하여 전역 뷰를 포기했는데, 이 때문에 연합우주에서의 "소셜 네트워크"는 트위터/X와는 구조가 크게 다르다. 노드 규모가 문턱값에 다다르지 못하면 다른 노드에 있는 사용자를 찾아서 팔로해야만 온전한 소셜 네트워크 구성이 가능한데, 연합우주 안에서는 이런 외부 사용자를 찾는 구체적인 방법을 제공하지 않는다. 물론 인터넷과 똑같이 검색 엔진이 존재할 수야 있겠지만, 크롤링으로 인한 부하와 프라이버시에 대한 의견 차이 때문에 현실적으로 작동하는 연합우주 내 검색 엔진은 없다고 알고 있다. 따라서 연합우주에서 소셜 네트워크의 구성은 연합우주 바깥의, 보통은 중앙화되어 있는, 다른 소셜 네트워크(이를테면 현실 인간 관계)를 빌어야만 하는데, 이러면 탈중앙화가 큰 가치가 있을까?
한편으로는 전역 뷰가 소셜 네트워크의 단점이라고 주장할 수 있는 여지도 있다. 트위터/X를 오래 써 본 사람이라면 다 알겠지만 한 무리의 사람들이 다른 의견을 가진 무리와 충돌하는 주된 통로는 검색이나 해시태그를 통한 노출, 즉 전역 뷰이기 때문이다. 그러나 현실의 규모 있는 연합우주 노드들을 살펴 보면 각 노드가 곧 한 무리에 대응하는 식으로 충돌을 미리 회피하는 형태로 구성되지, 딱히 이런 충돌을 막기 위한 접근을 가지고 있는 것은 아니다. 노드 운영자를 위해 차단하는 걸 추천하는 서버 목록 같은 게 돌아다니는 건 연합우주 바깥의 일이지 않는가. 결국 전역 뷰의 역할을 대체하는 소셜 네트워크 바깥의 또 다른 소셜 네트워크가 존재할 것이기에, 우리가 소셜 네트워크를 어떤 이유로든 유용하다고 여긴다면 전역 뷰가 없는 게 장점이 될 수는 없다.
모든 이들이 이런 사고 과정을 가지고 블루스카이나 연합우주를 선택했다고 생각하진 않지만, 적어도 현 시점에서 사용자들은 블루스카이(이 글을 쓰는 시점에서 약 3360만명)를 연합우주(FediDB와 Fediverse.party로부터 추정할 때 최대 1530만명)보다 선호하는 것은 틀림이 없다. 게다가 블루스카이의 규모는 최근 1년 사이에 10배 불어난 것이고, 조금 장애가 있었지만 현재는 잘 동작하는 것으로 보인다. 위의 논의와 결합해 보면, 블루스카이는 정석적인 스케일링에 성공하고 있는 반면 연합우주는 스케일링 문제를 회피하기 위해 온전한 소셜 네트워크의 구성을 포기했다고 볼 수도 있는 대목이다. 블루스카이가 못미더운 부분은 분명히 존재하지만, 연합우주가 더 좋은 소셜 네트워크 경험을 제공한다고 가정하고 블루스카이의 단점을 제시할 수는 없다. 마치 암호화폐를 논할 때 장점만 말할 수 없는 것과 마찬가지로 말이다.
RE: https://hackers.pub/@hongminhee/2025/bluesky-a-good-alternative-to-x-not-to-the-fediverse
@meWoojin Kim 팔란티어를 개발 문서에도 쓸수있나요?
@bglbgl gwyng 팔란티어는 기능이 정의된 소프트웨어라기보다는 기능 명세를 구축하는데 사용하는 일종의 SDK에 가깝다고 생각합니다. 주요 업무 이름을 기반으로 같은 업무를 서로 다른 부서에서 동시에 하고있다든지, 사이드이펙트가 큰 기능이 잘 알려지지 않은 채 개발되고 있는 등의 상황을 파악할 수 있는 모양으로 시스템을 구축할 수 있을 겁니다.
Nix 기반의 인프라 관리에 관심있으신 Go 고수분 계시다면 nix-snapshotter에 관심 가져보시는걸 추천드립니다. 지금 메인테이닝이 살짝 안되고있는데 기여자가 많아지면 좋겠네요.
사실 ... 이 미친 개발 문서 카오스에 팔란티어를 도입하면 어떻게 될지 궁금하긴 한데 다행인지 불행인지 회사는 그럴 정도의 돈은 없어보인다.
@meWoojin Kim 팔란티어를 개발 문서에도 쓸수있나요?
@bglbgl gwyng @curry박준규 JavaScript 쪽 ORM 중에서는 Prisma, Drizzle ORM, Kysely 정도 써 보았는데, 그 중에서는 그래도 Drizzle ORM이 제일 나은 것 같더라고요!
@hongminhee洪 民憙 (Hong Minhee) @curry박준규 저는 데이터모델을 정의하는 언어가 따로있는게 좋다고 생각해서 Prisma를 골랐거든요. 마이그레이션부터 다 해주겠다고 하는데 그때당시엔 아주 믿음직해보였습니다ㅋㅋ 이게 본인이 하기 싫은거일수록(저의 경우엔 마이그레이션이 특히) 프레임워크 형태로 주어지면 넙죽 받아먹게 되더라고요. 지금 고르라면 저도 Drizzle ORM을 시도해볼거 같습니다
한국은행은 여러 지표 및 보고서 등을 구독할 수 있도록 토픽 별 RSS 피드를 제공합니다. 하지만 <
@bglbgl gwyng 그나저나 슈티 앱 받으려고 했더니 한국 앱 스토어가 아니라서 못 받는다고 뜨네요… 미국 앱 스토어에도 올려주세요! 😭
@hongminhee洪 民憙 (Hong Minhee) 아하 놓치고있었네요. 가능한 빨리 열어보겠습니다.
@curry박준규 @bglbgl gwyng 오, 그러게요. 저도 Haskell 쓰실 줄 알았는데… 😲
@hongminhee洪 民憙 (Hong Minhee) @curry박준규 처음 삽뜰때 Prisma 쓰고싶었던게 컸습니다. 이후로 Prisma 계속 욕했지만요ㅋㅋ
지금 해커스펍은 Fresh를 활용한 MPA 앱으로 구현되어 있는데, 개인적으로 이것 때문에 이런저런 사용성 아쉬움을 느끼고 있었다. 그래서 해커스펍에 GraphQL API를 붙여서 SPA 프론트엔드를 새로 구현하겠다는 음모계획을 가지고, 이를 위한 기반 작업의 일환으로 Drizzle의 새로운 Relational Query Builder API(RQBv2)를 적용하는 PR을 만들어 보았다 😋
@bglbgl gwyng 왜 때문에 하스켈은 없죠?
@curry박준규 하나씩 바꿔나가야지요 언젠간..
@bglbgl gwyng 슈티의 기술 스택은 뭔가요?
@curry박준규 React Native, GraphQL(Relay), NodeJS, PostgreSQL, AWS, Pulumi 입니다. 아주 무난하지요.
얼굴인식 사진공유 카메라앱 슈티를 함께 만들 분을 찾습니다. 앱은 출시되어 있어 써보실수 있습니다. 이번달 내로 페디버스 연동을 끝내면 제가 생각한 MVP는 완성입니다. 앞으로도 개발해야할 부분들이 많고, 개중에 기술적으로 흥미로운 문제들도 다수 있습니다.
지금 2025년 상반기 투자유치를 목표로 팀 빌딩을 하고 있습니다. 관심 있으신 분, 또는 잘 모르겠지만 이야기를 나눠보고 싶은 분도 bgl@gwyng.com으로 편하게 연락주세요.
Nix 너무 좋다 예전에 새 mac 세팅할 때 독 비우는 게 제일 힘들었는데 local.dock.entries = []만 하면 깔끔하게 비울 수 있음
Hackers' Pub에 드디어 인용 기능이 구현되었습니다. 인용할 글의 링크를 복사한 뒤 단문 작성창에 붙여넣으시면 해당 글을 인용할지 묻는 창이 뜹니다. 확인을 선택하시면 해당 글이 인용되게 됩니다.
참고로 인용할 글은 꼭 Hackers' Pub의 글이 아니어도 ActivityPub을 지원하는 사이트의 아무 글이나 다 가능합니다. 예를 들어 Mastodon 인스턴스에서 글 링크를 복사해서 붙여도 동작합니다.
내가 쓴 글에 누가 어떻게 인용을 했나 궁금하실 경우, 글 아래에 있는 공유 아이콘 오른쪽에 위치한 반응 아이콘을 누르시면 확인할 수 있습니다. (원래는 공유한 사람 탭만 있었는데 인용 탭이 새로 생겼습니다.)
기술적으로는 FEP-e232 오브젝트 링크 스펙과 Misskey의 인용 확장 스펙, Pleroma의 인용 확장 스펙, 그리고 Fedibird의 인용 확장 스펙을 모두 구현하기 때문에, 인용 기능을 지원하는 현존하는 모든 ActivityPub 서비스와 호환됩니다.
RE: https://hackers.pub/@hongminhee/0195c73c-24f5-74c0-883d-1a0a0db14b6d
bgl gwyng shared the below article:
파이어폭스의 숨은 기능
가을별 @gaeulbyul@hackers.pub
파이어폭스에 숨겨진 유용한 기능들을 소개합니다. `about:config`를 통해 주소창에서 계산기 및 단위 변환 기능을 활성화하는 방법부터, 페이지 내의 모든 미디어를 한눈에 보고 다운로드할 수 있는 페이지 정보 활용법을 알아봅니다. 또한, 파이어폭스에 숨겨진 이스터에그 게임을 찾는 방법과 개발자 도구의 UI 크기를 사용자에 맞게 조절하는 팁도 제공합니다. 이 글을 통해 파이어폭스의 숨겨진 잠재력을 발견하고, 브라우징 경험을 더욱 풍부하게 만들어 보세요.
Read more →@hongminhee洪 民憙 (Hong Minhee) 
@gaeulbyul가을별 
@arkjunJuntai Park 복잡도가 어찌되는지 모르겠는데, 장문의 글을 렌더링할때도 버벅임이 좀 있었어요! (Draft를 좀 오래 묵혀놓긴 했었음)
@kodingwarriorJaeyeol Lee @gaeulbyul가을별 @arkjunJuntai Park 원인 찾아서 고쳤습니다. 조금 복잡한 버그였는데요…
- 일단 Markdown 렌더링 결과를 캐시를 안 하고 있었습니다.
- 근데 Markdown 렌더링 그게 뭐 별거라고 그렇게 느리냐 싶은데, 멘션된 사용자의 정보를 얻어오는 과정이 있어서 네트워크 I/O가 발생할 수 있고요. 연합우주니까 Hackers' Pub에서 아직 캐시한 적 없는 원격 사용자를 멘션하면 네트워크 요청이 이뤄질 수 있는 거죠.
- 문제는, 처음 한 번은 멘션된 사용자 정보가 없어서 받아온다 쳐도, 왜 매번 네트워크 요청이 일어나고 있었냐는 건데… 글 안에 (그… 중간에 Mastodon 위젯 같은 거 임베드하려다 깨진 부분에서) “어쩌다” 멘션된 @kodingwarrior@silicon.moe 때문에 그랬습니다.
- 사실 @kodingwarrior@silicon.moe 계정은
@kodingwarriorJaeyeol Lee (a.k.a. kodingwarrior) 
계정과 같은 계정인데요. (액터 ID가 동일.) Mastodon에 페디버스 핸들에 쓰일 호스트명과 웹에 쓰일 호스트명을 다르게 설정하는 기능이 있습니다. 다름 아닌 social.silicon.moe 인스턴스가 이를 이용해서 페디버스 핸들에서는 앞에 social.을 뗀silicon.moe를 쓰도록 설정해두고 있기 때문에 두 핸들은 사실 같은 것입니다. - 그런데 Hackers' Pub에서는 기존에 캐시된 계정이
@kodingwarrior@social.silicon.moe로 저장되어 있어서@kodingwarrior@silicon.moe로 검색하면 캐시 히트가 안 되는 것입니다. 그래서 캐시가 영원히 안 되는 효과가 있던 거죠.
일단 수정은 Markdown 렌더링 결과를 캐시하도록 맨 바깥에서 처리했고요. 다만, 핸들에 쓰이는 호스트명이 웹에 쓰이는 호스트명과 다른 케이스에 캐시가 안 되는 문제는 근본적으로 고쳐두긴 하려고 합니다.
냉동인간을 되살려도 그 사람들이 돈을 더 낼 것도 아닌데 뭐하러 냉동인간을 되살릴 연구를 하지?
bgl gwyng shared the below article:
2025 Q1 Review
Jaeyeol Lee @kodingwarrior@hackers.pub
작년 10월 쯤부터 강남에 파견근무를 가게 되었다. 간만에 돈벌이가 나쁘지 않은 생활, 요즘 받는거에 비하면 월급 두배 이벤트를 하고 있는데, 그만큼 너무 바빠졌다. 주말도 쉬지 않고 일했고, 설연휴도 삼일절 연휴도 쉬지도 못하고 일했다. 그러다 보니, 책을 읽을 시간도 없을 뿐더러, 사람을 만나러 다닐 여유도 거의 없다시피 했다. 일정을 잡는 것도 눈치봐야 하는 수준으로 바빠졌고, 이 일정이 언제 끝날지도 모르겟다.
그래서 블로그에 근황을 남기자니, "네.. 그냥 뺑이치고 있습니다..." 라고 밖에 요약이 되지 않는다.
요즘 근황이 어떻냐면....
블로그에 쓸만한 근황은 잘 없는 것 같지만, 그래도 몇가지 변경사항은 있는것 같아서 기록이라도 남겨야겠다. 대외활동을 하게 될 일은 당연히 없었어서 타임라인을 나열하기도 어렵고, "그냥 요즘 이런 변화가 생겼고, 이런 생각을 하고 있습니다" 정도로 남겨두겠다.
노트를 사서 끄적이는 습관을 들이려고 하는 중이다
삶에 변화를 좀 줘볼까하는 마음가짐에 프랭클린 플래너랑 속지를 구매했다. (사실 이런짓은 2016년/2020년 시도해본 적도 있었다) CEO 사이즈가 간편하기도 하고, 펜을 꽂을 수 있는 공간도 있어서 들고 다니면서 뭔가를 끄적이기에도 좋다.
<script data-allowed-prefixes="https://social.silicon.moe/" async src="https://social.silicon.moe/embed.js"></script>Post by @kodingwarrior@silicon.moeView on Mastodon
요즘은 일할때 아에 A4 용지 하나 꺼내서 거기다가 해야할 일들 나열하고, 어떤 Sub task를 해야하는지 시각적으로 쪼개기도 하는데, 키보드로 타이핑해서 할 일을 관리하는 것보다 역설적으로 더 관리가 잘 된다. 하나하나 남김없이 기록으로 남겨야겠다는 강박을 가지면 그것도 그것대로 집중이 안되었던 것 같다. 필요하면 그때그때 하나의 축약된 스냅샷을 남긴다면 모를까.
Getting Things Done 에 따르면, 할 일 관리 내지는 생산성의 끝판왕은 펜과 종이로 충분하다고도 설명하곤 했었는데, 왜 그런지는 요즘 들어서 실감하고 있다. 그렇다고, Vim을 사용하는 워크플로우가 별로이냐면 그것도 아니다. 각자, 담당할 수 있는 영역이 다를 뿐이고, 시각화가 필요하거나 시각적인 정보의 자유로운 배치를 원한다면 마우스로 어거지로 배치하느니 차라리 펜과 종이만한게 없다.
지하철 타고 다닐때나 버스를 타고 다닐때, 종이책을 들고 다니면서 읽거나 아이패드로 책을 읽곤 하지만, 책 자체가 내용이 많은건지 내 처리속도(1분당 1-2페이지)가 느린건지 유의미하게 읽는 양이 그렇게 많지는 않다. 꾸준히 읽는다는 것 자체에 의미를 둘 수는 있긴 하겠지만, '찔끔찔끔 읽으면서 내가 가져갈 수 있는게 무엇인가?'라는 실용적인 관점에서 접근해보니, 책 읽는데 시간을 들이기보다는 조금이라도 생각나는 것들을 다이어리에다가 기록이라도 남겨두면 이것들을 조합해서 밀린 계획들을 조금이라도 정리도 할 수 있고, 블로그에 글도 올리고, 블로그에 글을 올리겠다고 밀린 것들도 청산할 수 있고 일석이조 아닌가?
물론 책을 읽을 시간이 많으면 베스트겠다.
슬슬 취준을 시작하고 있다
지금 진행중인 3년이 넘는 계약도 슬슬 끝나간다. 취업 시장에 나올 수 있을때까지 한 6개월~1년 정도 남았다고 볼 수 있는데, 밥벌이를 하면서 취업 준비를 하기도 적당한 시기다. 사실은, "취업 준비"라는걸 제대로 해본 적도 없었다. 지금까지 해온 밥벌이도 그냥 코딩테스트는 그냥저냥 통과해서 그 운빨로 인턴을 시작하기도 했고, 그 다음부터는 지인(혹은 2차 지인)이 다니는 회사에 공식적인 전형이 없이 일을 해오긴 했었다. 그래서, 취업 준비를 하는 것도 이번이 처음이다.
여기에서도 간단하게 언급하긴 했었는데, 취준을 하게 된다면 프론트엔드 직군을 알아보거나 혹은 풀스택 직군을 알아보게 될 것 같다. 프론트엔드 직군을 생각하게 된 이유는 아래와 같다.
- 돈이 되는 제품을 만드는건 결국 프론트에서 시작한다.
아무리 기능이 많더라도 사용성이 구리거나 이쁘지도 않다면, 그걸 쓰려고 하는 고객도 잘 없다. 그것은 즉슨 돈벌이가 되지도 않는다. 기능을 특정 고객에게 맞춤형으로 개발한다고 한들, 사용성이 구리거나 이쁘지도 않으면 다른 경쟁업체에게 빼앗기기 일쑤다. 돈이 되는 일을 하고 가치를 창출하려면 프론트엔드를 하는게 불가피하다는 결론에 도달했다.
- 이왕 피할 수 없으면, 그냥 이대로 커리어로 끌고 가야겠다는 생각이 들었다.
본업은 분명히 백엔드로 시작하긴 했었지만, 실무에서 주로 하게 되었던 일들은 프론트엔드 할 사람이 없거나 혹은 일손이 모자라서 짬처리를 하는 일이었다. 거쳐갔던 회사 중에는 신중하게 기획하고 제품을 잘 만드는 것에 집중하고 기술스택을 가리지 않는 좋은 회사도 있었지만 이 경우는 짬처리와는 거리가 멀었다. 짬처리를 당하든, 내가 자발적으로 하게 되든, 결국에는 프론트엔드는 피할 수 없는 일이 되어왔다.
피할 수 없으면, 이걸로 계속 밥벌이를 하고 있으면, 그냥 이걸 내 커리어로 들고 가는게 맞지 않을까? 라는 생각이 들었다. 어차피, 백엔드도 그렇게 깊게 하지도 않았으니 프론트엔드가 손에 맞아가는 이 시점에 프론트엔드로 방향 트는 것도 방법이겠다 싶다.
프론트엔드 취준을 생각하면서도 걱정이 든다
프론트엔드 쪽으로 취업을 하려고 생각은 하고 있지만, 이래저래 걱정은 많다. 가장 먼저 드는 생각은, 내가 프론트엔드 개발을 할 때는 손이 그렇게 빠르지가 않다. Figma를 보면서 작업하면 금방이라고 느끼는 사람도 있겠지만, 하루에 10페이지-20페이지를 금방 찍어내는 사람이랑은 속도 차이가 좀 있는 것 같다.
거기다 처음부터 다시 배워야 하는 수준이다. 백엔드도 그렇게 깊게 하지는 않았지만, 프론트엔드는 더더욱 구조를 생각하면서 짜왔던 편도 아니거니와, 돌아만 가면 되는 수준으로 야매로 짜오긴 했다. 컴포넌트 나눠서 개발하는건 당연히 기본이긴 하지만, 잘 나누는지는 모르겠다. 그나마, "CSS는 과학이다"라는 마음가짐이었어서 CSS는 어느 정도 익숙하지만 딱 거기까지만인 것 같다.
지금까지 커리어를 이어오면서, 가장 취약했던 것도 사실은 프론트엔드이기도 하다. 퍼블리싱을 입히는 작업이 가장 괴롭게 느껴지기도 했었고, 다른 작업보다 심리적인 저항감이 있었어서 상대적으로 시간이 오래 걸리기도 했었다. (ADHD의 영향이 있어서일지도 모른다) 오히려 약점인 분야로 취업을 생각하고 있는 것도 어떻게 보면 이상하기도 하지만, "나는 프론트엔드 개발자다" 라는 마음가짐으로 임하게 된다면 그나마 저항감이 덜어질 것 같다.
당장은 할 수 있는 것부터 하고 있다
프론트엔드 개발자로서 어필하려면, 당장은 프론트엔드 개발자로서 포트폴리오가 될만한 것들을 만들어야 한다. 그러면서, 더더욱 의욕을 잃지 않을만한 것을 찾아서 만들어야 한다. 그래서 요즘은 나도 쓰고 남한테도 쓰라고 권장할 수 있는 앱을 만들려고 시도하는 중이다. 이 글을 쓰고 있는 Hackers Pub에 기여할 방법을 찾아보기도 하고, 직접 Mastodon 클라이언트를 만들고 있기도 하다. 다음 분기에는 꼭 출시하는게 목표다. 면접이나 과제 전형 준비는.... 일단 맞으면서 배워야겠지..
그래도 Full-stack 엔지니어(요즘 용어로는 Product 엔지니어) 라는 선택지도 완전히 버리지는 못해서 백엔드를 해야한다면 그때그때 습득하면 될 것 같다.
지금까지 읽은 책들
위에서 언급했다시피, 책 읽을 시간도 거의 확보하지 못했다. 집 - 사무실 - 집 - 사무실 루틴을 반복하는 것도 모자라서 최소 일주일에 한번 이상은 사무실에서 밤새기까지 해서 책을 읽을 정신적인 여력 조차도 없었다.
그나마 읽은 것들을 나열하자면....
- 또라이 제로 조직 (No Asshole Rule)
- 개인적으로 별로였다. 어떤 특징을 가진 사람을 또라이라고 규정하는 방식이나, 또라이라고 하는 사람이 조직에 얼마나 해로운지를 그럴듯한 설명을 하고 있지만, 이것도 주관적인 기준에 따라 다를 수 있기 때문에 평범한 사람도 또라이로 지목이 되어서 따돌림을 당하고도 남는 사회다.
- 일부는 납득은 되지만, 어조가 너무 노골적인 책이었어서 개인적으론 별로였다. 노골적인게 누군가에겐 사이다일 순 있겠지만, PTSD 있는 사람들에겐 피하라고 하고 싶은 책이다.
- RAG에 대한 책을 읽긴 했는데, 아직 공식적인 제목은 나오진 않았다. JPub에서 협찬을 받았지만, 출간 소식이 공식적으로 올라오면 그 때 링크를 달아두겠다.
- 큐레이션 : 정보 과잉 시대에서 쓸모에 맞게 조합해서 전시하는 것만으로도 어떤 가치를 전달할 수 있는지 잘 설명해주는 책이다. 알고리즘 기반의 추천이 어떻게 보면 이 시대의 큐레이션이라고 볼 수 있지 않을까?
- 노 필터(-ing) : 인스타그램 창업 스토리를 다루고 있는 책인데, 지금 읽고 있는 중이다. "사진을 찍고, 공유한다"라는 핵심적인 기능을 파고 들어서 시장에서 독보적인 위치를 차지해온 서사가 재밌다. 근데, 책 읽을 시간도 계속 없어져서 어느 시점부터는 맥락이 날아갈 것 같다.
And...?
이젠 좀 바쁜 것도 끝이 보이고, 이젠 진짜 하고 싶은거 많이 하면서 다음 분기를 보내고 싶다.
- Vim 행사 열기
- 좀 더 초보자들 친화적이고, 좀 더 많은 사람들에게 와닿고, 특히 Vim 자체에 어려움을 겪는 학생들에게도 Vim에 대해 가지는 "접하기 어렵다" 라는 고정관념을 타파할 수 있는 행사를 여는게 목표다.
- 지난 주부터 서베이를 돌렸는데, 44명이나 되는 분들이 응해주셨다. 이미 큰 행사를 열 것으로 계획하고는 있었지만, 정말 큰 행사가 될 것 같다
- JLPT N3 따기
- 듀오링고 일본어 모든 섹션을 다 완주하고 나서 자신감이 생겼다. 한자를 공부하는게 좀 고역이긴 하겠지만, 쪼끔이라도 잠깐 훑어보면 되지 않을까?라는 나이브한 생각이긴 하다. 어차피, 일본으로 넘어가는게 목표이기도 하겠다, N3 따는 걸로 시작해서 그 다음은 N2, 그 다음은 N1 점진적으로 따려고 한다.
- 일본 이민가기 프로젝트... 성공하겠지...?
- 만들고 있는 Mastodon Client를 플레이스토어에 출시하기
bgl gwyng shared the below article:
Bluesky는 X의 훌륭한 대안일 수 있지만, 연합우주의 대안은 아닙니다
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
최근 X(구 Twitter)를 떠나는 사용자들이 늘면서 Bluesky에 대한 관심이 높아지고 있습니다. Bluesky는 깔끔한 인터페이스와 과거 Twitter와 유사한 사용자 경험을 제공하며, '신뢰할 수 있는 이탈'이라는 매력적인 개념을 내세워 X의 유력한 대안으로 떠오르고 있습니다. 하지만 이 글에서는 Bluesky와 그 기반 프로토콜인 AT Protocol이 연합우주(fediverse)의 대안이 될 수 없는 이유를 설명합니다. Bluesky는 메시지 전달 방식 대신 공유 힙 방식을 사용하며, 이는 중앙 릴레이에 의존하게 만들어 탈중앙화의 이상과는 거리가 멀어집니다. 또한, 전역 뷰에 대한 집착은 차단 목록의 전체 공개와 같은 개인 정보 보호 문제를 야기하며, AT Protocol은 아직 특정 사기업에 의해 주도되고 있어 개방형 표준으로서의 한계를 가지고 있습니다. Bluesky는 이동 가능한 아이덴티티를 제공하지만, 여전히 중앙화된 요소에 의존하고 있으며, DM은 완전히 중앙화되어 있습니다. 결론적으로, Bluesky는 X의 훌륭한 대안이 될 수 있지만, 연합우주가 제공하는 탈중앙화된 가치와 경험을 대체하기는 어려울 것입니다. 이 글을 통해 Bluesky와 연합우주의 차이점을 명확히 이해하고, 자신에게 맞는 플랫폼을 선택하는 데 도움이 될 것입니다.
Read more →그동안(10+년;;) git이 엄청 잘만든 물건 같지는 않다고 생각하며 대충 쓰고있었는데, 요즘 branch 개념 자체가 근본적인 실수란 생각이 들기 시작했다. branch 대신에 변경의 시작과 끝, 양 끝점을 가지는 interval을 쓰는게 맞는거 같다(카테고리 이론의 작은 교훈: primitive는 양 끝점을 가지는게 좋다).
git을 쓰면 히스토리 길어진다고 squash merge 등을 하는데, (나도 하지만) 사실 기껏 만들어놓은 히스토리를 뭉개버리는 말도 안되는 동작이다. 만약 interval을 쓴다면 히스토리는 그대로 남기고 UI 단에서 fold/unfold 등을 해줄수 있을 것이다.
Darcs 등이 interval에 기초하는데, 지금은 일이 너무 바빠서 시도할 여유가 없다. 한번 숨고를 시간이 주어지면 멀쩡한 VCS를 탐색하는 시간을 가질것이다.
@bglbgl gwyng 저는 Darcs를 하스켈에 대한 빠심(?) 하나로 최근 써보고 있습니다. 마침 기여하고 싶은 패키지[1]의 저장소도 hub.darcs.net이기도 했고요.
Darcs 쓰면서 편한 점은 이미 추적(?)을 결정한 파일은 변경 사항을 커밋할 때 다시 add 하지 않아도 되고 바로 커밋[2]할 수 있다는 것입니다.
또 하나 편한 점은 파일에 여러 변경 사항이 혼재되어 있을 때 커밋을 나눠서 할 수 있다는 것입니다. 이건 제가 글재주가 부족해서 말로 설명하기 어려운데, 여러 변경 사항에 대해서 커밋을 시도할 경우 대화형으로 커밋 여부를 물어보는데 이때 원하는 변경 사항만 골라서 커밋을 하면 됩니다.
GHC[3]의 저장소가 현재는 GitLab이지만 과거에는 Darcs였었죠. 성능 이슈 때문에 이전했다고 하는데 지금은 문제가 해결됐는지 궁금하네요.
@bglbgl gwyng 사이먼 페이튼 존스의 고양이 이름이 하스켈인데 고양이 이름이 먼저였을까요, 프로그래밍 언어 이름이 먼저였을까요?
@curry박준규 처음 알았네요ㅋㅋ 이경우는 공통조상?이 짐작되긴 하죠
높은 목표를 가진 개발자라도 결국엔 아주 사소한 동기로 움직이는거 같다.
나같은 경우엔, 완벽한 프로그래밍 언어를 만드는 것이 목표인데(가능한지는 차치하고), 완벽하다는건 나말고 다른 누군가가 같은 문제 의식을 가진다면 똑같이 그곳에 다다를 거란걸 의미한다. 그 프로그래밍 언어의 설계에서 내 마음대로 결정할수 있는 부분은 없을 것이다. 설계에서 최적의 선택지만을 택해야 완벽할테니까 말이다. 그때가선 그 선택들이 너무 자명해서, 내겐 처음부터 선택의 여지가 없었다고 느낄것이다.
그럼에도 내가 결정할 수 있을 부분이 있기는한데, 그 언어의 이름에 뜬금없이 우리집 강아지 이름을 붙인다던가 하는 것이다. 이게 그 사소한 동기다.