sendActivity를 그냥 inbox URL만으로 하고 싶은데...
洪 民憙 (Hong Minhee)
@hongminhee@hackers.pub · 1004 following · 706 followers
Hi, I'm who's behind Fedify, Hollo, BotKit, and this website, Hackers' Pub! My main account is at
@hongminhee洪 民憙 (Hong Minhee)
.
Fedify, Hollo, BotKit, 그리고 보고 계신 이 사이트 Hackers' Pub을 만들고 있습니다. 제 메인 계정은:
@hongminhee洪 民憙 (Hong Minhee)
.
Fedify、Hollo、BotKit、そしてこのサイト、Hackers' Pubを作っています。私のメインアカウントは「
@hongminhee洪 民憙 (Hong Minhee)
」に。
Website
- hongminhee.org
GitHub
- @dahlia
Hollo
- @hongminhee@hollo.social
DEV
- @hongminhee
velog
- @hongminhee
Qiita
- @hongminhee
Zenn
- @hongminhee
Matrix
- @hongminhee:matrix.org
X
- @hongminhee
아아ㅡ 객체지향 쪽 면접을 준비하려면 트루쓰 쏘-셜에도 가입이 되어있는 극우기득권남성의 책을 바이블처럼 참조해서 봐야 한다니ㅡ
아아ㅡ 객체지향 쪽 면접을 준비하려면 트루쓰 쏘-셜에도 가입이 되어있는 극우기득권남성의 책을 바이블처럼 참조해서 봐야 한다니ㅡ
아예 .well-known/webfinger만 리다이렉트 걸어서 이메일 호스팅마냥 간단하게 커스텀 도메인 핸들을 주고 싶었는데 쉽지 않을 것 같다...
Actor의 uri 도메인과 웹핑거 핸들 도메인을 다르게 설정할 수 있는가?? (실행시켜본 건 아니고 코드만 봤을때) 마스토돈 - 일단 uri 도메인으로 웹핑거 쿼리를 때린 후 uri가 일치하면 된다 (그래서 여러 서버들이 uri 도메인을 같이 쓰는건 어려울듯...) 미스키 - 무조건 uri 도메인으로 넣어버리는 듯 하다...
아예 .well-known/webfinger만 리다이렉트 걸어서 이메일 호스팅마냥 간단하게 커스텀 도메인 핸들을 주고 싶었는데 쉽지 않을 것 같다...
Actor의 uri 도메인과 웹핑거 핸들 도메인을 다르게 설정할 수 있는가?? (실행시켜본 건 아니고 코드만 봤을때) 마스토돈 - 일단 uri 도메인으로 웹핑거 쿼리를 때린 후 uri가 일치하면 된다 (그래서 여러 서버들이 uri 도메인을 같이 쓰는건 어려울듯...) 미스키 - 무조건 uri 도메인으로 넣어버리는 듯 하다...
洪 民憙 (Hong Minhee) shared the below article:
자기소개
루 @roo_37@hackers.pub
연합우주에 첫 발을 내딛는 루/Roo입니다. SI 1년차 풀스택 웹 개발자로서 웹 개발 전반과 UI/UX, 접근성을 학습하며, DB와 데이터 엔지니어링에도 관심을 두고 있습니다. AI Vibe Coding, 설명 가능한 AI, AI 윤리와 같은 주제에도 흥미를 느끼며, Technical Writing, 번역, 다국어 처리에도 참여합니다. 취미로는 마작(작혼, 일번가, 천봉), 야구(삼성라이온즈), 닌텐도(피크민, 포켓몬), 만화/애니메이션 감상, 언어 공부(듀오링고 1880일), 별 보기, 풍경 사진 촬영, 동물 사랑 등이 있습니다. MBTI는 INFJ-T이며, 불안장애 및 우울증 치료 중입니다. 개발 이야기 외에 다양한 취미와 일상 이야기는 트위터(@Roo_star_)에서 만나볼 수 있습니다.
Read more →
洪 民憙 (Hong Minhee) shared the below article:
헬: 하스켈 방언 기반의 셸 스크립팅 언어
박준규 @curry@hackers.pub
Chris Done이 개인적인 셸 스크립팅 용도로 만든 하스켈 방언 기반의 셸 스크립팅 언어인 헬(Hell)을 소개합니다. 저자는 bash의 난해한 문법과 서브 프로세스 의존성 등의 단점을 극복하고자 헬을 개발하게 되었습니다. 헬은 모듈, 패키지 시스템, 추상화 기능 없이 매우 기본적인 기능만을 제공하며, 하스켈의 장점(탄탄한 개념, 동시성, 가비지 컬렉션, 정적 타입 등)을 활용합니다. 헬은 기존 하스켈의 직관을 재사용하고, 안정성과 단순성을 추구하여 자동화 스크립팅에 적합하도록 설계되었습니다. 헬은 냉정하게 완결된 소프트웨어를 지향하며, 스크립팅의 한계를 명확히 정의하여 불필요한 기능 확장을 방지합니다. 릴리스 페이지에서 정적 링크된 리눅스 바이너리를 다운로드할 수 있으며, 구현에 대한 자세한 내용은 소개 슬라이드를 참고할 수 있습니다.
Read more →알아요 안다구요
@woaol벨 결국 그렇게 됐군요…
파서가 얼추 돌아가기 시작했다. 이제 최적화해야지
Macintosh HD ← もはや"Macintosh"でもなければハードディスクドライブでもない
〈타입 검사는 해결책이 아니라 증상이다〉(Type Checking is a Symptom, Not a Solution).
난 이 글에 동의하지 않는데, 여러 측면에서 그렇지만, 한 측면에만 집중해서 얘기해 보자면: 좋은 아키텍처는 훌륭한 프로그래머를 요구하지만 타입 시스템은 훌륭한 프로그래머를 요구하지 않기 때문이다.
누구나 훌륭한 프로그래머가 되어야만 하는가? 혹은 될 수 있는가? 좋은 아키텍처를 그릴 수 있는 훌륭한 프로그래머가 아니라면 소프트웨어 개발을 해서는 안 될까? 좋은 아키텍처에만 의존하는 것은 잠재적으로 엘리트주의를 끌어들이기 쉽다: 「어떤 시스템이 오작동하는 것은 아키텍처가 나쁘기 때문이다. 아키텍처가 나쁜 이유는 그걸 설계한 프로그래머가 수준 미달이기 때문이다」와 같이.
반면 타입 시스템은 일단 도입만 하면 누구나 그 덕을 볼 수 있다. 팀 내의 프로그래머들의 역량이 뛰어나든 뛰어나지 않든. 훨씬 평범한 보통 사람에게 유리하다. 타입 시스템이 미봉책일 수는 있지만, 그 미봉책이 더 많은 사람들을 프로젝트에 참여할 수 있게 해준다고 생각한다.
벌써 이번주 일요일이 해커스펍 오프라인 모임이라니... 시간 진짜 빠르다.....
오이카페 이슈 트래커에 ActivityPub 관련해서 기여할 수 있는 이슈를 몇 가지 등록했습니다!
We're excited to share an update on #Fedify's development! While we're actively working on Fedify 1.9 in the main branch, we've also begun preparations for Fedify 2.0 in the next branch.
Before you get too excited about revolutionary new features, we want to set clear expectations: Fedify 2.0 will primarily focus on cleaning up technical debt that we couldn't address due to backward compatibility constraints. This means removing deprecated APIs and making breaking changes that will ultimately result in a cleaner, more maintainable codebase. Think of it as a major housekeeping release—necessary work that will make Fedify better in the long run.
Some of the planned improvements include adding readonly modifiers throughout our types and interfaces to better enforce our immutability-by-default principle, implementing our own RFC 6570 URI Template library for symmetric expansion and pattern matching, and various CLI tool migrations to our new Optique framework for better cross-runtime support. While the majority of changes will be about refinement rather than revolution, these updates will strengthen Fedify's foundation and improve interoperability across the #fediverse. You can track all planned changes in detail by checking out the Fedify 2.0 milestone on our GitHub repository.
@hongminhee洪 民憙 (Hong Minhee) 이쁘네요! (키보드 산 지 얼마 안되신 걸로 압니다만..😂)
@arkjunJuntai Park 맞아요. 그래서 참고 있습니다… 😂
5월에 앱코 무접점 키보드를 구입했는데 세일 소식에 또 한번 뽐뿌가 휘몰아친다.
앱코, ‘무접점 키보드’ 최대 30% 할인 특가 행사 진행 > 뉴스/신제품 | 쿨엔조이 https://share.google/QaZTUFHi5HedUerIM
오라일리 ActivityPub 책이 1회독 했을때는 '음, 이런게 있구나' 하고 넘겼던 것 같은데, 한달 뒤에 cosmoslide 한 사이클 돌게 하고 난 뒤에 읽으면 '아, 이게 이거구나' 할만한 포인트가 많을 것 같다.
@hongminhee洪 民憙 (Hong Minhee) 역시 그렇군요. 비슷한 기능 두 개를 독립적으로 개발하고 main에 한번에 병합하는 상황에서 쓰지 않을까? 했어요.
@youngseokchoi 그럴 수 있겠네요. 그럴 일이 별로 없을 것 같긴 하지만요… 😅
(Octopus merge) Git에서 parent commit이 세 개 이상인 merge
저는 한번도 써본적 없어서, 활용하는 사람이 있는지 궁금하네요
(Octopus merge) Git에서 parent commit이 세 개 이상인 merge
저는 한번도 써본적 없어서, 활용하는 사람이 있는지 궁금하네요
@youngseokchoi 저는 필요했던 적이 없는 것 같네요… 🤔
We all dodged a bullet (npm attack) https://xeiaso.net/notes/2025/we-dodged-a-bullet/
지금 리눅스 진영에서 컨테이너/네임스페이스의 입지가 어떻게 될까요? 사실 요즘 서비스 배포할때는 죄다 컨테이너 쓰잖아요? 근데 또 컨테이너로 할수 있는 것중 상당수는 그냥 기존 권한 관리로도 가능하단 말이죠? 근데 컨테이너를 쓸땐 기존 권한 관리를 그냥 없는셈 치고 접근하게 되는데 이게 정말로 다들 동의하는 방식인지가 궁금합니다.
안녕하세요!
@mizisuHeecheol Kim 반갑습니다. 어서 오세요!
@cheeaunChee Aun 🤔 fyi we are looking at building a new emoji picker for Mastodon, and
@chaosexanimaecho ✨ will try it make it reusable by others as a react component. We brainstormed a lot about it and plan to use some nice tricks (like using indexeddb) to reduce the amount of loaded data, while supporting multiple languages for example
@renchapRenaud Chaput
@chaosexanimaecho ✨ I'm still a huge proponent of using native OS emoji pickers 😬
I respect all the hard work, but this is an issue for *every* web site and browser/standards folks seem like not prioritizing this with <input type="emoji"> or some JS method to invoke OS emoji pickers 🤷♂️
pnpm 쪽에서 왠지 구현을 할 것 같은 인상의 트윗을 https://x.com/ZoltanKochan/status/1965410213160518067
컴파일러 책 얇은 거 하나 읽고 있는데 문맥자유문법(CFG)이 나와서 오랜만이야 친구 하면서 보는 중...언어학 덕질했던 사람으로선 이걸 보니 하나 떠오르는 게 하나 있는데, 1957년 Syntactic Structures에서 촘스키는 이 CFG를 갖고 닝겐의 자연어가 지니는 통사적 성질(의미 아님)을 마르코프 과정을 통해서 설명하기엔 한계가 있음을 지적하며 변형문법(Transformational Grammar)를 제안한 게 생각난다. 즉, 닝겐 자연어의 통사 정보를 설명할 문법을 제안한 것(다시 한 번 말하지만 의미가 아님). 물론 이후엔 훨씬 더 발전하고 추상화됐고, PCFG라 하여 CFG에 확률을 넣은 CFG 확장판도 있다[1]. 참고로 오토마타 이론에서 나오는 촘스키-슈첸버거 위계나 촘스키 정규형할 때 얘기하는 그 촘스키 맞다.
개인적으로 촘스키의 저 시절 연구들이 되게 재밌다고 생각하는데 (물론 훑어만 봤지만...) 이후엔 사실상 오토마타 이론쪽으론 손 뗀 것 같아서 좀 아쉽기도 함...여튼 컴파일러 책 보다가 갑자기 생각나서 씀. 그나저나 도대체 난 언제 쯔음 나만의 프로그래밍 언어를 만들 수 있을까?
정규언어에서 은닉 마르코프 모형으로 확장시키는 거랑 똑같다. ↩︎
@hongminhee洪 民憙 (Hong Minhee) 오픈톡방 위주로 돌아가는 커뮤니티이긴 합니다 ㅋㅋ
@kodingwarriorJaeyeol Lee (a.k.a. kodingwarrior)
앗, 카카오톡인가요… 접근성이 떨어지는군요. 😭
(개인적 감상)음, kotlin 의 구조적 동시성 구문은 kotlinx (언어 내장이 아니라) 에 속해 있기 때문인가 왜케 코드가 눈에 안들어오냐. 직관적으로 읽히지 않네... scope 를 관리하는 부분은 swift 가 좀 나아보인다.
비동기 프로그래밍:
async,Promise, ...: X- AI 에이전트 갈구고 딴짓하기: O
@saram사람 안녕하세요! 반갑습니다!
Typescript Backend Meetup이라고 타입스크립트 백엔드 개발하는 사람들 모임이 있는데, 많은 비중의 사람들이 NestJS 쓰는 듯?
여기서 Fedify 언급하면서 "연합우주란 세계가 있다 츄라이 츄라이", "NestJS는 아니지만, 개발자를 위한 소셜 서비스 해커스펍이 있다"하고 약파는 내용의 발표를 해보면 어떨까.. 싶다.....
이제 타입 검사기 짜는 데에는 익숙해지고 있는데 검수 이후에 타입 정보를 어떻게 코드 생성 과정에서 유용화하는지 모르겠다
모든 노드에 고유 식별자를 부여하고 외부에 거대한 해시맵 Expr → Type을 만드는 수밖에 없나?
이제 타입 검사기 짜는 데에는 익숙해지고 있는데 검수 이후에 타입 정보를 어떻게 코드 생성 과정에서 유용화하는지 모르겠다
Typescript Backend Meetup이라고 타입스크립트 백엔드 개발하는 사람들 모임이 있는데, 많은 비중의 사람들이 NestJS 쓰는 듯?
여기서 Fedify 언급하면서 "연합우주란 세계가 있다 츄라이 츄라이", "NestJS는 아니지만, 개발자를 위한 소셜 서비스 해커스펍이 있다"하고 약파는 내용의 발표를 해보면 어떨까.. 싶다.....
Optique를 사용해보고 싶어서 만들어봤어요: https://github.com/jcha0713/togl
외계 생명체에게 메시지를 보낼 때 유용할지도 모릅니다.
트잇타 사담계도 터지고, 뭔 별의별 되도않는 싸불이 너무 당연하다는듯이 일어나버리니까 이렇게 된 이상 연합우주로 트친들을 전부 데려와야겠다는 사명감이 생겼다(?)
AWS CDK는 C#을 포함한 여러 프로그래밍 언어를 지원하는데, CDK를 AWS 없이도 테스트해볼 수 있는 환경을 조성하기 위해 Localstack을 이용할 수 있습니다. 이번 .NET 10에 도입되는 FBA를 사용하여 CDK 로컬 환경을 구축하고 실험해볼 수 있는 예제를 만들어봤습니다. :-D
https://forum.dotnetdev.kr/t/aws-cdk-localstack-net-10-fba-aws/13725
https://contribute-suggestion.vercel.app/
대강 배포는 했어요
프론트 버그가 많아서 고쳐야 하지만 일단 올리긴 올림
깃헙 토큰은 각자 받아서 사용해야 됩니당
좋은 건지 나쁜 건지 모르겠다. (좋은 건지 나쁜 건지 모르겠던 또 다른 예는 Deno의 Node.js API 호환 추가…)
security/urgent fix로 마킹된 경우를 제외한 최신 의존성을 인스톨 시 제외해주는 옵션을 패키지 매니저들이 implement 해야 할 듯 (구현은 누가)
We've implemented the node:http client and server APIs in Cloudflare Workers, allowing developers to migrate existing Node.js applications with minimal code changes. This post explains how we built a bridge between the Workers serverless environment and Node.js's traditional HTTP model, complete with examples for running frameworks like Express.js at the edge. https://blog.cloudflare.com/bringing-node-js-http-servers-to-cloudflare-workers/
클로드 코드 맥스를 끊었는데 머릿속에서 스쳐지나가는 사이드 플젝 아이디어들을 하루만에 프로토타입으로 만들 수 있어서 좋은 것 같다... 클로드 데스크톱 + 클로드 코드 조합으로 데톱이 기획하고 코드가 개발하는 느낌으로 쓰는 중
이런 거 만드는 중 클로드 코드 쪼아가면서 프로토타입은 만들었고 버그랑 ui 좀 뜯어 고쳐야 함 이름도 생각이 안 나서 대충 적어놨는데 이름 추천해주실 분...
요즘 여러 supply chain attack과 'AI로 필요한 거 만들어 쓰면 되지 않냐' 라는 생각에 의존성을 줄여야 한다는 생각이 빠르게 퍼지고 있는 것 같은데, 나는 조금 재고의 여지가 있다고 생각하는 편 (하지만 언제나 zero-deps lib이 있다면 그걸 먼저 고르긴 하지) https://x.com/jaeholee_dev/status/1965254296037196080
이미 지원할 곳들을 조금 선정하긴 했지만, 여전히 프론트엔드 개발자로 일할 수 있는 곳들을 찾고 있습니다. 기존에 고장나있었던 cv를 조금 고쳐놨습니다 (원래 read cv 산이었던 것을 백업받아 홈페이지에 합체...)










