Profile img

洪 民憙 (Hong Minhee)

@hongminhee@hackers.pub · 1017 following · 727 followers

Hi, I'm who's behind Fedify, Hollo, BotKit, and this website, Hackers' Pub! My main account is at @hongminhee洪 民憙 (Hong Minhee) :nonbinary:.

Fedify, Hollo, BotKit, 그리고 보고 계신 이 사이트 Hackers' Pub을 만들고 있습니다. 제 메인 계정은: @hongminhee洪 民憙 (Hong Minhee) :nonbinary:.

Fedify、Hollo、BotKit、そしてこのサイト、Hackers' Pubを作っています。私のメインアカウントは「@hongminhee洪 民憙 (Hong Minhee) :nonbinary:」に。

Website
hongminhee.org
GitHub
@dahlia
Hollo
@hongminhee@hollo.social
DEV
@hongminhee
velog
@hongminhee
Qiita
@hongminhee
Zenn
@hongminhee
Matrix
@hongminhee:matrix.org
X
@hongminhee
0
0
0
0
0
0
0
0
0

洪 民憙 (Hong Minhee) shared the below article:

복잡한 코드를 단순하게 줄여나갈 수록 발생하는 버그의 빈도나 심각도가 점진적으로 올라가는 경향이 있다고 느낀다

ㄹ @disjukr@hackers.pub

이 기술 블로그 포스팅에서는 코드 복잡도와 버그 심각도 사이의 미묘한 관계를 탐구합니다. 저자는 복잡도를 높이는 방향으로 문제를 해결할 때, 버그 빈도와 심각도를 점진적으로 줄일 수 있지만 최적의 해결책에 도달하지 못할 수 있다는 점을 지적합니다. 반대로, 복잡도를 낮추는 방향으로 접근하면 문제 해결에 드는 비용을 예측하기 어렵다는 어려움이 있습니다. 특히, 회사에서 코드 복잡도를 줄이는 대신 높이는 방향으로 문제 해결을 요구받는 상황에서 엔지니어로서의 자아와 현실 사이의 괴리를 느끼는 저자의 고충이 드러납니다. 개인 시간을 투자하여 더 나은 해결책을 찾아도, 이를 회사에 도입하는 데 많은 설득 비용이 소요된다는 점을 강조하며, 회사 내에서 자아실현을 포기해야 하는지에 대한 고민을 토로합니다. 이 글은 기술적 효율성과 조직적 요구 사이의 균형을 찾는 데 어려움을 겪는 개발자들에게 깊은 공감을 불러일으킬 수 있습니다.

Read more →
0
0
0
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Public

한국 연합우주 개발자 모임(FediDev KR)은 이름 그대로 한국에서 연합우주(fediverse)와 관계된 개발(프로그래밍 뿐만 아니라 문서화, 번역 등을 포함)을 하는 사람들의 모임입니다. 실제로 Hackers' Pub의 개발 논의도 이 모임에서 처음 나왔었고요. Hackers' Pub을 통해서 ActivityPub이나 연합우주에 관심이 생기셨다면 한 번 참여해 보셔도 좋을 것 같습니다.

참고로 올해에는 아직 개최한 적 없지만 비정기적으로 스프린트 모임도 하고 있습니다. @sprints.fedidev.kr한국 페디버스 개발자 모임 계정을 팔로하시면 스프린트 모임이 열리기 전에 미리 공지를 올릴테니 미리 확인하실 수 있을 거예요.

한국 연합우주 개발자 모임

한국에 거주하거나 한국어를 사용하는 연합우주(fediverse) 개발자들의 모임입니다.

fedidev.kr

0
0
0
0
0
0
0
0
0
1
0
0

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 scores

This 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.

Read more →
0
1
0
0
1
0
0
0
0
0
0
0
0
1
0
0
0
0
bgl gwyng @bgl@hackers.pub
Public

옛날에 만들어놓고 저 혼자는 잘쓰고 있는 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 등 다른 상태관리 라이브러리를 같이 쓴다면 연동이 깔끔하지 않을수 있습니다. 근데 평소에 쉽게 겪을 문제는 아니라고 보고, 또 추후에 설계를 수정해서 개선이 가능한 부분입니다.

Compose multiple forms into a single form wizard using a monadic approach. - gwyng-dev/react-form-mozard

GitHub - gwyng-dev/react-form-mozard: Compose multiple forms into a single form wizard using a monadic approach.

Compose multiple forms into a single form wizard using a monadic approach. - gwyng-dev/react-form-mozard

github.com · GitHub

0
0
0
bgl gwyng @bgl@hackers.pub
Public
Shared by 洪 民憙 (Hong Minhee)

옛날에 만들어놓고 저 혼자는 잘쓰고 있는 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 등 다른 상태관리 라이브러리를 같이 쓴다면 연동이 깔끔하지 않을수 있습니다. 근데 평소에 쉽게 겪을 문제는 아니라고 보고, 또 추후에 설계를 수정해서 개선이 가능한 부분입니다.

Compose multiple forms into a single form wizard using a monadic approach. - gwyng-dev/react-form-mozard

GitHub - gwyng-dev/react-form-mozard: Compose multiple forms into a single form wizard using a monadic approach.

Compose multiple forms into a single form wizard using a monadic approach. - gwyng-dev/react-form-mozard

github.com · GitHub

0
0
0
0
0
1
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Public

아마도 2006년이었던 것 같다. 처음 가본 대안언어축제에서 정말 충격적인 체험을 했었다. 당시는 Python이 대안 언어였던 시절… Io도 배우고 J도 배우고 Haskell도 배우고. 고등학생 때였는데, 동아리 사람들을 모두 데려가서 어른들에게 예쁨 받았던 기억도 있다. 행사가 어디서 후원을 받았었는지 기억은 안 나지만, 후원을 아주 크게 받았던 것만 기억이 난다.



RE: https://hackers.pub/@kodingwarrior/0195d560-1a2e-73db-847f-cd71b4d18653

0
0
0
0
0
1
0
0
0
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Public

개인적으로 Hackers' Pub 행동 강령에서 내세우고 싶은 곳이 있다면 이 부분이예요:

구조적 차별과 불평등에 대한 우리의 입장

우리는 현실 세계의 구조적 불평등이 온라인 공간에도 그대로 반영되고 있다는 현실을 직시합니다. Hackers' Pub은:

  • 성차별, 인종차별, 장애인 차별 등 우리 사회에 만연한 구조적 차별이 존재한다는 현실을 인식하고, 이러한 차별에 반대합니다.
  • “모든 사람을 동등하게 대우한다”는 명목 하에 이러한 구조적 불평등을 무시하거나 부정하지 않습니다.
  • 사회적 약자와 소수자에 대한 적극적인 포용 정책이 진정한 평등을 향한 필수적인 과정임을 확신합니다.
  • 차별과 혐오에 대항하는 발언과, 차별과 혐오 자체를 동일선 상에 두지 않습니다.
  • 우리는 이러한 구조적 차별이 결코 정당화될 수 없으며 반드시 극복되어야 할 과제임을 분명히 합니다.

Hackers' Pub Code of Conduct

hackers.pub

0
0
0
0
1
0
0
1
0
0
0
0
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Public

전체 사용자 초대 족보에서 원한다면 자신의 계정을 가리는 옵션을 추가하면 좋겠다는 @saschanazKAGAMI🏳️‍🌈🏳️‍⚧️ 님의 의견에 따라, 내 계정 족보에서 숨기기 버튼을 만들었습니다. 자신의 계정을 족보에서 숨기면 목록에 항목은 보이지만 이름이나 프로필 사진, 핸들은 가려지게 됩니다.



RE: https://sekai.social/notes/a5u6zpmnn3tf06pr

Hackers' Pub의 전체 사용자 초대 족보 페이지. “내 계정 족보에서 숨기기” 버튼이 보인다. 족보에서 어떤 계정은 “숨겨진 계정”으로 표시되고 있다.
0
1
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
3
0
0
0
0
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Public

@xiniha 님께서 Hackers' Pub에 눈에 보이진 않지만 큰 기여를 해 주셨습니다. Drizzle ORM 베타 버전에서 쓸 수 있는 릴레이셔널 API v2를 Hackers' Pub 코드 전체에 적용하는 큰 패치가 바로 그것입니다.

기능적으로 눈에 바뀌는 것은 없겠지만, 아마 성능상으로는 약간의 개선이 있을 수 있습니다. 기존에는 복잡한 관계 필터를 서브쿼리 방식으로 해 왔는데, 릴레이셔널 API v2를 쓰면 JOIN으로 바뀌는 것 같아요. 물론 PostgreSQL의 쿼리 최적화기가 뛰어나다면 두 방식 중 어떤 방식을 쓰든 같은 실행 계획을 수립할 것이므로 성능 차이가 없을 수도 있지만요. 아니면 더 느려질 수도 있겠죠. 거기까지 세세하게 비교 테스트해보진 않았습니다. 😅

참고로 해당 변경은 이미 배포된 상태입니다. 아무튼 고생해주신 @xiniha 님께 박수 부탁드립니다. 👏

We've launched Drizzle Relational Queries exactly a year ago and it's time to ship a fundamental upgrade. We've gathered a massive amount of valuable feedback from the community and going to addres...

Relational API v2 · drizzle-team drizzle-orm · Discussion #2316

We've launched Drizzle Relational Queries exactly a year ago and it's time to ship a fundamental upgrade. We've gathered a massive amount of valuable feedback from the community and going to addres...

github.com · GitHub

0
0
0
Juntai Park @arkjun@hackers.pub
Public

@hongminhee洪 民憙 (Hong Minhee) @curry박준규 다소 오래전의 글이기는 합니다만, (제가 외노자 시절에 찾아본 거라) 그때와 다르지 않다면 장음 표현이 올바른 쪽에 가까우나, 사실상 생략을 하는 편이고, 그 또한 맞는 것으로 인정되고 있습니다. (당시 기억으로 모두 다 생략하는 쪽이어서 찾아본 기억이 있네요)

https://m.blog.naver.com/PostView.naver?blogId=juntai81&logNo=18475324&navType=by

「サーバ」와「サーバー」과연 어느쪽인가?

一切唯心造.. | 블로그 · 장음부호「ー」의 수수께끼 「サーバ」와「サーバー」과연 어느쪽인가? 최근 몇년...

blog.naver.com · 네이버 블로그 | 一切唯心造 모든 일은 마음 먹기에 달렸다.

0
1
0
Simon Park @parksb@silicon.moe
Public

코틀린+스프링 백엔드 개발하다가 지금은 프론트엔드 개발하고 있다는게 다른 사람들에게 꽤 재밌는 이야기로 다가오는 것 같다. 당연히 선택의 이유에 대한 질문을 가장 많이 받는데, 가장 특이한 질문은 OOP가 그립지 않은지(?)라는 질문. (OOP도, AOP도 전혀 그립지 않다.)

Simon Park @parksb@silicon.moe
Public
Shared by 洪 民憙 (Hong Minhee)

그리고 이런 입장에서 BE vs FE 같은 대결 구도가 조금... 그렇다. 사실 업무상 관점이 좀 다를 수는 있어도, 다른 직군으로 분류할 정도로 기술적 관심사나 고민의 주제가 그렇게 까지 다른가 싶기도. 나중에 이 생각의 해상도를 좀 더 높여봐야겠다.

0
0
0
Simon Park @parksb@silicon.moe
Public
Shared by 洪 民憙 (Hong Minhee)

코틀린+스프링 백엔드 개발하다가 지금은 프론트엔드 개발하고 있다는게 다른 사람들에게 꽤 재밌는 이야기로 다가오는 것 같다. 당연히 선택의 이유에 대한 질문을 가장 많이 받는데, 가장 특이한 질문은 OOP가 그립지 않은지(?)라는 질문. (OOP도, AOP도 전혀 그립지 않다.)

0
0
0
박준규 @curry@hackers.pub
Public

이번에는 Grok에게 커밋 메시지[1] 작성을 부탁하다가 Changelog 작성하는 문서[2] 안내를 받았다.

  1. 그동안 내가 ‘메세지’라고 적었는데 홍민희 님의 글[3]을 보고 고쳤다. ↩︎

  2. https://keepachangelog.com/ko/1.0.0/ ↩︎

  3. https://hackers.pub/@hongminhee/0195d2c5-294d-7f92-b33e-db40eec4793a ↩︎

Keep a Changelog

동료가 git 로그를 changelogs에 덤프하게 내버려 두지 마세요.

keepachangelog.com

0
0
0
0
1
0
0
0
0
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Public

소프트웨어 개발자들이 자주 틀리는 외래어 표기법.

영어 틀린 표기 올바른 표기
app 어플 앱
application 어플리케이션 애플리케이션
directory 디렉토리 디렉터리
front-end 프론트엔드 프런트엔드
message 메세지 메시지
method 메소드 메서드
release 릴리즈 릴리스
repository 레포지토리 리포지터리

또 있을까요?

1
9
0
0
0
0
박준규 @curry@hackers.pub
Public
Shared by 洪 民憙 (Hong Minhee)

darcs tag[1]의 도움말을 읽다가 《Producing Open Source Software》[2]라는 책을 알게 되었습니다. 혹시 이 책의 한글 번역서가 있나요? 《오픈 소스로 미래를 연마하라》(인사이트, 2019)가 약간 비슷한 내용을 다루는 것 같긴 합니다.

  1. https://gist.github.com/nattybear/6beaa578a08b0272e22c6154a606b02f ↩︎

  2. https://producingoss.com/ ↩︎

darcs help tag. GitHub Gist: instantly share code, notes, and snippets.

darcs help tag

darcs help tag. GitHub Gist: instantly share code, notes, and snippets.

gist.github.com · Gist

0
0
0
0
0
0
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Public

WSGIは私の青春を燃やした抽象化層だった。@mitsuhikoArmin Ronacher さんのWerkzeugのコードを読んでPythonについて多くの事を学んだ。当時のWerkzeugのコードは今でもPythonで最も価値の有るコードの一つだと思う。



RE: https://misskey.io/notes/a5tgk6d7ywb80ms1

0
0
0
0
0
0