Profile img

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

FedifyHolloBotKit、そしてこのサイト、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
2
3

마스토돈 CEO 자리에서 물러납니다
------------------------------
- *Mastodon 창립자 Eugen Rochko* 가 약 10년 만에 CEO 자리에서 물러나며, *상표권과 자산을 비영리단체에 이양*
- 프로젝트가 개인 중심이 아닌 *커뮤니티 중심 구조* 로 유지되도록 하는 것이 핵심 목표
- 소셜미디어 운영의 *정신적 부담과 대중의 기대* 가 사임 결정의 주요 배경으로 언급
- 지난 10년…
------------------------------
https://news.hada.io/topic?id=24472&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

2
5
2
1
0
2
7

많은 언어들의 많은 패키지 매니저들이, 패키지에 대한 테스트를 돌릴 방법은 제공하면서(npm test 등) 막상 그 패키지 레포를 클론떴을때 그 패키지를 사용하는 아무 예제나 실행시켜볼 쉽고 통일된 방법은 잘 제공 안하는 거 같다. 가령 examples/*의 코드들을 실행시킬 방법은 npm 패키지들마다 제각각이다. 왓더??

3

많은 언어들의 많은 패키지 매니저들이, 패키지에 대한 테스트를 돌릴 방법은 제공하면서(npm test 등) 막상 그 패키지 레포를 클론떴을때 그 패키지를 사용하는 아무 예제나 실행시켜볼 쉽고 통일된 방법은 잘 제공 안하는 거 같다. 가령 examples/*의 코드들을 실행시킬 방법은 npm 패키지들마다 제각각이다. 왓더??

1
3
0
0
4
4

오늘은 xml parser와 unzip 처리해주는 라이브러리와 Cursor의 도움을 좀 받아 워드, 엑셀, 파워포인트 ooxml 파일을 파싱해서 텍스트와 서식 정보, 이미지, 파워포인트는 발표자 노트, 엑셀은 셀 데이터를 가져오는 파서를 만들었다.

원랜 야크셰이빙할 생각은 별로 없었는데 기존 라이브러리 등이 내가 원하는대로 안 되는게 커서 결국 삽을 펐다. LLM의 도움이 아예 없었으면 오늘 안에 다 못 만들었을 것 같다.

그래도 이게 OOXML 포맷이 압축 파일이고 그 안에 xml로 되어있는 구조라는걸 알고 있었어서 이런 바퀴를 재발명할 생각도 할 수 있었던 것 같다. 저녁까지만 해도 머리에 쥐날 것 같았는데 다 되니까 세상에 이렇게나 뿌듯할수가…

  • 관성적으로 코딩 관련에는 Claude Sonnet 4.5 위주로 사용했는데 요즘 GPT-5/5.1 Codex 써보고 굉장히 놀라는 중. 역시 AI쪽 분야는 관성적인 행동을 버리고 다양하게 계속 찍어먹어봐야 장단점을 알고 필요할 때 요긴하게 쓸 수 있는 것 같다.
샘플 파워포인트 슬라이드직접 만든 파서로 처리한 결과
0

오늘은 xml parser와 unzip 처리해주는 라이브러리와 Cursor의 도움을 좀 받아 워드, 엑셀, 파워포인트 ooxml 파일을 파싱해서 텍스트와 서식 정보, 이미지, 파워포인트는 발표자 노트, 엑셀은 셀 데이터를 가져오는 파서를 만들었다.

원랜 야크셰이빙할 생각은 별로 없었는데 기존 라이브러리 등이 내가 원하는대로 안 되는게 커서 결국 삽을 펐다. LLM의 도움이 아예 없었으면 오늘 안에 다 못 만들었을 것 같다.

그래도 이게 OOXML 포맷이 압축 파일이고 그 안에 xml로 되어있는 구조라는걸 알고 있었어서 이런 바퀴를 재발명할 생각도 할 수 있었던 것 같다. 저녁까지만 해도 머리에 쥐날 것 같았는데 다 되니까 세상에 이렇게나 뿌듯할수가…

  • 관성적으로 코딩 관련에는 Claude Sonnet 4.5 위주로 사용했는데 요즘 GPT-5/5.1 Codex 써보고 굉장히 놀라는 중. 역시 AI쪽 분야는 관성적인 행동을 버리고 다양하게 계속 찍어먹어봐야 장단점을 알고 필요할 때 요긴하게 쓸 수 있는 것 같다.
샘플 파워포인트 슬라이드직접 만든 파서로 처리한 결과
4
5
1
3

@ailrunAilrun (UTC-5/-4) @hongminhee洪 民憙 (Hong Minhee) 사실 예전에 말씀하신 연구 주제를 처음 들었을때, 쓸모가 확 와닿지 않았어요. 메타프로그래밍을 그냥 CPP 매크로 정도로 생각해서, 그걸 굳이 타입안전하게 해야하나?라고 속으로 생각했는데요. 점차 메타프로그래밍이 생각보다 훨씬 흔한 패턴이란걸 알게됐단 말이죠. 두 프로그램의 상호작용을 기술하거나, Nix에서 쉘스크립트를 다루거나 할때요. 그러면서 그 연구 주제의 중요성을 점점 느끼고 있는 중이에요.

청중이 정확히 어떤 그룹인지는 모르겠지만, 어쩌면 그분들이 저와 비슷한 첫 인상을 가질수 있단 생각이 드네요. 그래서 그런 오해를 피할수 있도록 연구의 응용처를 소개하는데 충분한 시간을 할당하시는게 좋지 않을까 생각이 듭니다.

3

If you're a software developer and need to create a presentation with a lot of code, I highly recommend you consider Slidev (by @antfu.meAnthony Fu). Especially if you need to include TypeScript code!

Slidev is web-based presentation software made for software developers. It offers a wide variety of ways to present code in your slides, like highlighting specific code in sequence, displaying TypeScript type information in tooltips through Twoslash integration, a “magic move” feature that compares the before and after of your code with a cool animation, the ability to embed the Monaco editor, and more.

This was my first time using Slidev, but I was captivated by its rich feature set. You should give it a try too!

2

그나저나 Slidev는 소프트웨어 프로그래머를 ()한 정말 잘 만든 發表(발표) 슬라이드 作成(작성) 소프트웨어 같다. ()히, 슬라이드에 TypeScript 코드를 꽤 包含(포함)해야 하는 發表(발표) 資料(자료)를 만든다면 Slidev를 使用(사용)해 볼 것을 ()한다. Twoslash가 支援(지원)된다…!

꼭 TypeScript 코드가 아니더라도 特定(특정) 줄들을 順序(순서)대로 強調(강조)하는 것도 되고, 라이브로 코드를 고칠 수도 있다. 비포 애프터로 두 코드를 比較(비교)할 때도 매직 무브로 괜찮은 演出(연출)可能(가능)하다.

아무튼 Slidev 最高(최고)…!

4
2
1

이번 겨울에 연대에서 발표를 하나 할 것 같다. 이를 위한 발표자료를 준비 중인데… 완전 대중도 아니고 전문가도 아닌 청중에게 무엇을 어느정도까지 어떻게 설명해야할지… 고민이 많다. 😵‍💫

0

Dang it, PostgreSQL is so good.

I did a data export thing. The options I needed were there. Then I needed more options, and then they were also there. They worked the way I guessed. It was fast. It was reliable. Then I thought “oh, what about sequences?!?”, but they already had that covered. My seemingly easy task turned out to be…easy.

1

Dang it, PostgreSQL is so good.

I did a data export thing. The options I needed were there. Then I needed more options, and then they were also there. They worked the way I guessed. It was fast. It was reliable. Then I thought “oh, what about sequences?!?”, but they already had that covered. My seemingly easy task turned out to be…easy.

2
0
0

돌이켜보니 내가 처음으로 소프트웨어의 '품질'을 경험한게 스타1이랑 디아2였다. 게임이 재밌는거랑 별개로, 그때 기준으로 저 두 게임은 소프트웨어로써 품질이 훌륭했다. 그당시 다른 게임들은 느리고, 심각한 버그가 있고, UI가 덜컹 거리기 일쑤였다. 스타1, 디아2는 게임을 켤때부터 끌때까지 매끄러운 경험을 줬다.

7
0
4
1

좋은 소식 공유하자면...

사실 요 며칠간 외국계 회사에서 work trial을 했는데요. 수습도 통과했고, 지금까지 받아왔던 것에 비해 훨씬 좋은 처우환경에서 일할 수 있게 되었습니다..

파이썬 기반의 환경에서 개발하는 중이고, 제가 마침 빠삭한 도메인에서 일하게 되었다고 하네요

17
2
4

System.IO.readFile 쓰지 마세요.

System.IO.readFile 쓰지 마세요.

System.IO.readFile 쓰지 마세요.

첫째, System.IO.readFileString 을 반환합니다. 이건 심각한 문제입니다. String 을 쓰지 마세요. 외부 세계와 I/O 를 할 때에는 ByteString 을 써야 합니다. 유니코드 문자열을 다룰 때에는 Text 를 쓸 수 있습니다. String 은 시간적으로도 공간적으로 비효율적입니다. 이건 어쩔 수 없습니다. 하스켈은 리눅스 커널보다 오래됐습니다. 그리고 하스켈이 String 을 만들 때에는 아직 하스켈에 모나드도 없던 시절이며, 타입 클래스가 과연 유용하겠는가를 두고 의견이 분분하던 시절이며, 파일 하나가 100 메가바이트가 넘어간다는 것이 과대망상으로 여겨지던 시절입니다. 특히 유니코드보다 더 먼저 나온 언어에 적절한 유니코드 문자열 타입이 있을 수는 없었습니다. 아무튼 String 은 레거시입니다. System.IO.readFile 로 그림 파일을 읽는 프로그래머는 사후세계에서 JPEG XL 파일을 십육진법 표기로 1 바이트씩 읽은 뒤 종이에 그려 내는 형벌에 처해집니다. String 을 쓰지 마세요.

둘째, System.IO.readFileFilePath 를 요구합니다. FilePath 도 사실 String 입니다. 그냥 별명(type synonym)이에요. 이것은 String 이기 때문에 비효율적이며, String 은 문자열이지 바이트열이 아니기 때문에 (인코딩을 전혀 통제할 수 없기 때문에) 파일 경로를 표현하는 타입으로 부적절합니다.

해결책: 먼저 System.OsPath 의 설명을 읽어 보세요. 그리고, file-io 패키지의 System.File.OsPath 모듈을 읽어 보세요. 여기 있는 함수들의 설명을 openBinaryFile 부터 하나씩 읽어보고 쓰세요. 이것들은 파일 경로에 OsPath 를 쓰기 때문에 String 의 비효율이 없고 인코딩도 올바르게 처리할 수 있습니다. 입출력 데이터에는 ByteString 을 씁니다. 바이트열을 유니코드 문자열로 변환할 때에는 예를 들어 Data.Text.Encoding.decodeUtf8Lenient 를 쓸 수 있습니다. 그럼 이제

  • 간단히 System.File.OsPath.readFile' 에게 OsPath 를 넘기고 ByteString 을 효율적으로 받아 와서 국밥처럼 든든하게 메모리에 올려 두고 작업을 하든지
  • 전국구 마법사라면 복대는 기본이라고 외치며 withBinaryFile앙갓썸Iteratee I/O 로 절묘하게 엮어서 뭔가 개멋있게 하든지
  • 하스켈 갓고수이기 때문에 흑마법사답게 보일러실 문을 따고 지하로 들어가 포… 포… 으악! P 로 시작하는 그것을 획득하여 누구도 예상할 수 없는 타이밍에 hGetBuf 의 암기를 슉. 슈슉. 슈슈슉. 슉. 날리든지

아무튼 이제는 String 을 놓아주어야 합니다.

7
3

12() ()에 할 Optique 發表(발표)()한 슬라이드 資料(자료)를 만들고 있는데, Optique具顯(구현) 細部事項(세부사항)까지 다뤄야 할 지, 아니면 使用者(사용자) 立場(입장)에서의 콘셉트나 API 같은 걸 爲主(위주)로 다뤄야 할 지 苦悶(고민)이네… 具顯(구현) 디테일을 다루려고 하면 주어진 發表(발표) 時間(시간)인 30() 안에 못 끝낼 것 같다는 느낌도 들어가지고…

3
1
3

Vim에서 Quickfix List라는 걸 처음 알게 되었다.

기존 코딩 흐름은

G 코딩 코딩 Vim을 닫는다. Vim을 닫는다. 코딩->Vim을 닫는다. cabal build cabal build Vim을 닫는다.->cabal build 에러 확인 에러 확인 cabal build->에러 확인 Vim을 연다. Vim을 연다. 에러 확인->Vim을 연다. 에러가 발생한 행(row)으로 간다. 에러가 발생한 행(row)으로 간다. Vim을 연다.->에러가 발생한 행(row)으로 간다. 에러가 발생한 행(row)으로 간다.->코딩

이랬는데 Quickfix List를 이용하면

G 코딩 코딩 :make :make 코딩->:make :copen :copen :make->:copen Enter를 눌러서 에러가 발생한 행으로 이동 Enter를 눌러서 에러가 발생한 행으로 이동 :copen->Enter를 눌러서 에러가 발생한 행으로 이동 Enter를 눌러서 에러가 발생한 행으로 이동->코딩

이렇게 Vim을 나가지 않고도 빌드 결과를 확인하고 에러가 발생하면 그곳으로 바로 점프할 수 있다!

.vimrc에 이렇게만 적으면 된다.

set makeprg=cabal\ build
6
2
2
1
1
3