https://djot.net/ djot이라고 Markdown 개발자가 Markdown의 문제점을 고쳐서 내놓은 마크업 언어이다. 이러고보니 Deno같군.
bgl gwyng
@bgl@hackers.pub · 99 following · 123 followers
GitHub- @bglgwyng
@bglbgl gwyng 제가 알기로는 Markdown 만든 사람은 아니고 Pandoc 제작자이자 CommonMark 스펙 공동 저자이신 분이예요!
SolidJS로 앱 만들다가 아이콘셋이 필요해져서 패키지를 뒤져보는데, 마이너 생태계답게 마지막 업데이트가 삼사년 전인 패키지들만 나온다. 아이콘셋에 업데이트가 필요 없긴 하지. 그래도 최근에 업데이트 된 패키지가 걸리적거리는게 없을 것 같달까. 그러다 활발히 업데이트 중인 unplugin-icons를 찾았다. 이것은 SolidJS용 패키지가 아니었다. 아이콘셋도 아니었다. 거의 모든 아이콘셋을 거의 모든 프레임워크에서 사용할 수 있게 해주는 도구다. 이런 문물이 있었다니. 누가 만들었나 함 보자. 제작자는 Anthony Fu... 아아 또 그인가. 오늘도 비 React 웹 생태계엔 Anthony Fu의 은혜가 넘친다.
내 글만 볼 수 있는 my 버튼을 추가했습니다.
새로운 반응이 생긴 글들은 알림을 표시합니다.
yearit.com
개인 맵 Private map을 가질 수 있고, 연인, 가족이나, 지도를 공유하면 좋은 동호회(낚시, 캠핑, 라이딩...) 분들이 공유할 수 있는 맵으로 쓸 수도 있습니다.
맵에 아무나 읽을 수 있는 권한을 주고, 블로그나, 회사 페이지 등에도 임베드할 수 있습니다.
아직은 UI가 심히 엔지니어 손 맛인데, 계속 고민하고 있습니다.
It looks like a new minor release of #Hollo (v0.7.0) will be out soon, the first in several months.
Hackers Public @ Seoul 송년회 ---- 2025년의 마지막을 해커들과 함께해요.
Hackers' Public @ Seoul 송년 네트워킹 밋업은 발표보다 대화, 형식보다 연결을 중심으로 진행됩니다. 라이트닝 토크도 지원받습니다. 만들었던 것·배운 것·고민했던 이야기를 자유롭게 얘기해보도록 해요.
많은 관심 부탁드립니다~
- 🗓 12/21(일) 14:30~18:30
- 🎤 라이트닝 토크 5분 자유 참여
- 📌 1차 모집: 11.26~12.5 (회원 대상)
- 신청하기 👉 https://event-us.kr/hackerspubseoul/event/117468
bgl gwyng shared the below article:
도커로 구축한 랩에서 혼자 실습하며 배우는 네트워크 프로토콜 입문 #4
자손킴 @jasonkim@hackers.pub
이 글은 네트워크 계층과 애플리케이션을 연결하는 L4 전송 계층의 핵심 개념을 소개합니다. 포트 번호를 통해 애플리케이션을 식별하고, UDP와 TCP 프로토콜의 특징과 패킷 형식을 설명합니다. UDP는 실시간성을, TCP는 신뢰성을 중시하며, TCP는 3-way handshake로 연결을 설정하고, 흐름 제어, 혼잡 제어, 재전송 제어를 통해 데이터 전송을 관리합니다. 특히 TCP 커넥션의 상태 전이 과정과 4-way handshake를 통한 연결 종료 과정을 상세히 다룹니다. 이 글을 통해 독자는 L4 전송 계층의 작동 방식과 TCP의 신뢰성 있는 데이터 전송 메커니즘에 대한 깊이 있는 이해를 얻을 수 있습니다.
Read more →
요즘 새로운 프로젝트를 진행중이다.
Optique 發表 資料 아직도 만드는 中… 이걸 이렇게 며칠씩 붙잡고 있는 게 말이 되나…
그나저나 Slidev는 소프트웨어 프로그래머를 爲한 정말 잘 만든 發表 슬라이드 作成 소프트웨어 같다. 特히, 슬라이드에 TypeScript 코드를 꽤 包含해야 하는 發表 資料를 만든다면 Slidev를 使用해 볼 것을 勸한다. Twoslash가 支援된다…!
꼭 TypeScript 코드가 아니더라도 特定 줄들을 順序대로 強調하는 것도 되고, 라이브로 코드를 고칠 수도 있다. 비포 애프터로 두 코드를 比較할 때도 매직 무브로 괜찮은 演出이 可能하다.
아무튼 Slidev 最高…!
글투를 넘어 말투를 최대한 부드럽게 상상해보면, 공격적인 글투의 글도, 공손한 조언의 말투처럼 느껴질 때가 있습니다. 확실히 말과는 달리 글에는 많은 컨텍스트를 스스로 채워 넣어야만 합니다. 다 같은 동종 업계 업자끼리 부드럽지만, 지식 알멩이가 있는 대화들이 돌아 다니면 눈이 즐겁습니다. 컨텍스트를 최대한 부드럽게 채워 넣으며 대화가 이어지길 바랍니다.
(말투같은 느낌의 단어로 글투로 쓰다 보니, 살짝 낯설어서 낱말을 찾아 봤습니다. 있긴 있는데, 써 본적이 거의 없는 낱말 같습니다.)
이제 Lumo (GitHub)에서 fixpoint를 바탕으로 상호 재귀 가능한 함수 묶음을 정의할 수 있다. 슬슬 MVP의 끝이 보인다. 다음 스텝은 코드젠이다.
System.IO.readFile 쓰지 마세요.
System.IO.readFile 쓰지 마세요.
System.IO.readFile 쓰지 마세요.
첫째, System.IO.readFile 은 String 을 반환합니다. 이건 심각한 문제입니다. String 을 쓰지 마세요. 외부 세계와 I/O 를 할 때에는 ByteString 을 써야 합니다. 유니코드 문자열을 다룰 때에는 Text 를 쓸 수 있습니다. String 은 시간적으로도 공간적으로 비효율적입니다. 이건 어쩔 수 없습니다. 하스켈은 리눅스 커널보다 오래됐습니다. 그리고 하스켈이 String 을 만들 때에는 아직 하스켈에 모나드도 없던 시절이며, 타입 클래스가 과연 유용하겠는가를 두고 의견이 분분하던 시절이며, 파일 하나가 100 메가바이트가 넘어간다는 것이 과대망상으로 여겨지던 시절입니다. 특히 유니코드보다 더 먼저 나온 언어에 적절한 유니코드 문자열 타입이 있을 수는 없었습니다. 아무튼 String 은 레거시입니다. System.IO.readFile 로 그림 파일을 읽는 프로그래머는 사후세계에서 JPEG XL 파일을 십육진법 표기로 1 바이트씩 읽은 뒤 종이에 그려 내는 형벌에 처해집니다. String 을 쓰지 마세요.
둘째, System.IO.readFile 은 FilePath 를 요구합니다. 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 을 놓아주어야 합니다.
一般 Kyungmi Ahn ꉂꉂ(ᴖᗜᴖ*) 
통신판매업자 신고하자마자 하루에 2~3통씩 스팸, 피싱이 온다. 중소기업 진흥 어쩌고, 뭐시기 팀장이란 전화가 온다. (통신판매업자 정보는 완전 오픈되어 있다.) 정부가 내가 모르면 손해 보는 걸 적극적으로 전화까지 하며 챙기는 일은 없기! 때문에 듣자 마자 끊는다. (이런, 믿음이 장점이 될 때가 있구나) "안녕하세요"부터 쎄한 느낌이 오는 전화들이다. 이렇게 법적으로 추적 가능한 전화(휴대폰 번호가 찍힌다)로, 대범하게 피싱 시도를 계속한다.
그냥 넘어가지 않고, 정부 사이트에 의심 신고를 하려 하니, 개인 정보를 무섭게 요구해서 멈칫한다.
12月 6日 서울에서 開催되는 liftIO 2025에서 〈Optique: TypeScript에서 CLI 파서 컴비네이터를 만들어 보았다〉(假題)라는 主題로 發表를 하게 되었습니다. 아직 liftIO 2025 티켓은 팔고 있으니, 函數型 프로그래밍에 關心 있으신 분들의 많은 參與 바랍니다!
호버(hover)는 잘못된 인터페이스입니다. 사용자가 어떤 목표를 달성하기 위해 호버를 해야만 하는 인터페이스를 만들면 안 됩니다. 호버에는 장식적 효과 이상의 기능이 있어서는 안 됩니다.
예전에는 이것을 설명하는 데에 많은 말이 필요했고 참 힘들었습니다. 이제는 좀 쉬워졌죠. 터치스크린입니다. 손바닥만 한 스마트폰부터 대문짝만 한 키오스크까지, 이제 터치스크린은 싫어도 불가피하게 써야만 하는 물건이 되어 버렸습니다.
그런데 터치스크린에는 호버가 없죠. CSS 에 @media (hover: hover) 같은 게 있긴 하지만, 당연히 이것만 믿고 인터페이스 설계를 해서는 안 될 것입니다. 그런 식으로 "호버 있음" 과 "호버 없음" 을 따로 지원한다는 것은 번거롭고, 실수하기도 쉽고, 망가지기도 쉽고, 관리하기는 어렵습니다. 설령 터치스크린 있는 장치에서 터치를 활성화하거나, 비활성화하거나, 마우스를 끼우거나 빼거나 등등 할 때마다 그 정보가 무수한 계층을 뚫고 애플리케이션까지 올바르게 전달된다고 쳐도요.
굉장히 오랜만에 들어와서 쓰는 근황입니다.
- TIS-100의 모든 레벨을 클리어했습니다. 다음 목표는 아마 Opus Magnum 아니면 A=B가 될 것 같습니다.
- 올해 여름부터 지금까지 7문제를 백준에 출제했습니다. 여기의 맨 아래에서 보실 수 있습니다. 개인적으로 가장 재밌었던 문제는 SWAP-C Sort인데 그만큼 어렵습니다.
- 웹 기반으로 뭔가 만들 게 생겨서 프레임워크를 알아보다가 Solid를 써보기로 결정했습니다. 웹 UI는 Flowbite, 그래픽 요소는 Konva를 쓰게 될 것 같습니다.
- 그런데 이쪽을 첫삽을 뜨기도 전에 갑자기 굉장히 어려운 퍼즐틱한 문제 하나의 풀이가 완성되어서(....) 논문(?!)을 하나 쓰기 시작했습니다. 이런 거 받아주는 저널 어디 없을까요(????)
저게 38만 킬로미터 떨어진 허공에 떠 있는 물체고, 1억 5천만 킬로미터 떨어진 광원의 빛을 반사해서 내 눈에 보인다는 게 가끔 정말 생경하게 다가올 때가 있다.
RE: https://bsky.app/profile/did:plc:4sujqnbd47ey26qcvajqoxa2/post/3m4ueopbvzw23
새로운 서비스를 실험하고 있는데요.
너무 연속으로 컨텐츠를 봐서 피로해지는 서비스가 아닌, 어쩌다 접속해서 멍 때릴 수 있는 서비스를 고민하며 기획을 했습니다. 가끔 버스 창밖을 바라보며 멍때리는 것처럼요. 멍때리다 창밖의 간판들이 가끔 눈에 들어 오듯, 글이나 낙서가 눈에 띄면 어떨까 싶어서, 초기 인연이 있는 분들에게 부탁해서 다양한 글을 좀 채워 넣으려 했습니다. (AI로 목업을 채워 넣으면 맛이 없을 것 같아서, 실제 다양한 사람들의 글을 원했습니다.) 이게 매우 어려운 벽이다를 실감하고 있습니다.
- SNS 성격의 서비스는 이용하기 싫다.
- 이미 이용 중인 SNS가 여러 개라, 또 추가하기 싫다.
- 로그인 해서 보니, 그다지 나한테 맞지 않는다.
- 몇 번 로그인해서 봐도 흥미가 생기지 않는다.
- 가끔 접속해서 보는 소소한 재미가 있을지도 모르겠다.
- ...
0번은 어차피 제외고, 초기 지인 분들은 적어도 3번까지는 가 주길 기대했는데, 1번조차 넘질 못하고 있습니다. 쓸만한 서비스 혹은, 기획을 조정하면서 고민해 볼 가치가 있는지 보기 위해선, 그래도 1번은 넘어 가야 뭘 할텐데 말입니다. 부탁을 받은 지인들 조차 1번을 넘기 어려운데, SNS 서비스를 홍보한다는 건 꽤 험난한 길이겠습니다.
처음 제가 해커스펍의 1번 문턱을 넘었던 이유를 생각해보면, 저는 사람이었던 것 같습니다. 같은 직군에 있는 사람들이 모여 있어, 대화가 잘 통할 것 같아서 선뜻 들어 온 게 아닐까 싶습니다. 몇 달을 써 보면서 결론은, 해커스펍은 분명 자기만의 영역이 있는 서비스란 생각이 듭니다. 좋다는 생각을 가지기 까지는 좀 써봐야 아는 건데, 해커스펍이 꽤 어려운 걸 돌파했구나란 생각이 듭니다.
혹시 ikariam이라는 게임을 즐겨 본 분 계신가요? 그거, 은근 재밌게 했는데, 주변에서 제가 하는 걸 보더니 "어떻게 그런 게 재밌냐"고 묻는 사람들이 대부분이긴 했습니다. 오랜만에 찾아 보니 아직도 ikariam은 잘 살아 있네요. 멍때림이 싫지 않은 사람들이 분명 있긴 있을텐데, 어떻게 그 분들을 찾아 1번을 넘어가게 할까 고민이네요.
yearit.com
여행 기분내며, 이동하는 동안 멍도 때리고, 여기 저기 낙서하는 서비스입니다.
여러 사정으로 하스켈로 개발하진 못했는데, 언젠가 여건이 되면 서버들을 하스켈로 포팅하고 싶습니다.
#이어잇 #yearit #여행 #낙서
YearIt - Travel the world, doo...
난 학생때부터 컴퓨터 좋아하다보니 자연스럽게 프로그래머가 되고 싶어하는 중고딩들 모이는 커뮤니티 활동을 했었음.
그런데 내가 활동하던 곳은 가정환경이 불우한 애들 위주로 모여있더라고... 집안에 투병자 있어서 빚이 2억이던 우리집이 상류층으로 분류될 정도였음.
그러다가 언제 한번 모여서 학교 공부에 대해 얘기한 적이 있음.
냉정하게 우리 가정환경 따져봤을 때 수능봐서 대학갈 사람들은 아니다. 그래도 학교가 아주 의미없는 곳은 아니니 그 안에서 챙길건 챙겨보자. 했음.
굳이 가져갈걸 찾는다면, 국어는 형태소와 품사 정도만 구분할 줄 알면 되고(NLP), 수학은 행렬이랑 기하와 벡터 기초 정도만(3D, 공간), 과학은 물리2만(이상하게 도움되는 잡다한 이론들) 대략 뭔소리를 하는지 보면된다. 그럼 어디가서 돈버는데는 문제없을거. 라는 결론 도출하고 그거 공부만 하기로 했음.
결론은 여기 있던 애들 대학이랑 연은 없어도 전부 취업은 원하는 분야로 20대 초반에 다했음.
3090은 진짜 젊어서는 비트코인 캐고 늙어서는 llm 돌리는 불쌍한 세대네
최근 몇 달간 개발을 하는 것에 대한 현타가 심하게 왔었는데, 프로그래밍을 처음 시작했던 중학생 시절부터 남긴 흔적들을 되짚어 보면서 내가 진짜 뭘 하고 싶었던건지 되짚어봤고, 이제 다시 회복이 되가는 것 같음.
알고계십니까? 고대의 언어인 줄 알았던 Smalltalk 친척 Self는 놀랍게도 최근까지도 업데이트가 되고 있습니다. https://selflanguage.org/
JavaScript의 .prototype 개념에도 영향을 주었다고 알려진 Self가 어떤 언어인지 궁금하시다면 Series about Self(lobste.rs)를 읽어보세요. 프로그래밍 언어에 대한 여러분의 시야가 넓어지는 데에 도움이 될 겁니다.
한국어 번역:
- 발표자료 대본 다이어트
- 코스모슬라이드 다듬는 작업
- 브라우저 스터디 준비
진짜 이름만 들어도 아는 프로젝트들 사이에 있는 Fedify...
We invest globally in the open software components that underpin Germany's and Europe's competitiveness and ability to innovate. Improving the security, stability, and reusability of open software components directly enhances the productivity, competitive edge, and capacity for innovation of startups and small and medium-sized businesses. We’re excited to be working with these maintainers and FOSS communities, and to support the software that forms the foundation of the infrastructure of the 21st century.
Here are some of the projects the Sovereign Tech Fund has recently commissioned work on:
Scala, SDCC, Let's Encrypt, Servo, chatmail, Drupal, Fedify, openprinting, PHP, Apache Arrow, Open SSL, R Project, Open Web Docs, conda, systemd, and phpseclib
NameSilo API 옛날부터 생각만 하다가 방금 처음 써 봤는데, 생각보다 너무 쉽고 간단해서 깜짝 놀랐다.
문제가 심각하다.
아니, 그냥 API 키 발급 누르면 즉시 나오고, 그걸로 내 계정의 모든 것을 다 할 수 있으며, 심지어 연장이나 신규 구입 등 카드 결제 일으키는 행위도 할 수 있다고. 있는 거라고는 API 키를 읽기 전용으로 하는 거랑, "Block Restorations" 뿐이다. 도메인 네임을 제때 연장 못해서 소유권 잃은 경우, 좀 더 큰 돈을 내고 소유권을 회복할 수 있는데 이걸 restoration 이라고 한다. 이건 돈이 많이 들고 환불도 어려운 행위이기 때문에, 이것만 API 키로 못하도록 설정하게 해 준다는 것이다.
그러니까 이거 말고는 권한 관리도 없고, 여러 개의 API 키 중에서 하나만 폐지(revoke)하는 기능도 없고, 모든 API 키를 폐지하는 기능도 안 보이고, 이 API 키를 최근에 사용한 IP 주소는 어디냐 같은 기록도 아무 데도 안 보이고, 하다못해 이 API 키로 행할 수 있는 결제액의 상한 같은 것도 설정할 수 없고, 아무것도 없어!
나는 나 자신을 믿지 않는다. 나는 반드시 사고를 칠 것이다. 엔지니어라면 당연히 그렇게 가정해야 한다! 더구나 이 API 키는 내 도메인 네임의 소유권을 다 상실시킬 수도 있는 물건...? 내가 뭔가 잘못 이해하고 있는 건가? 멀쩡한 관리 페이지가 따로 있는데 네임사일로가 꽁꽁 숨겨 놔서 못 찾고 있는 건가?
거의 10년 넘게 쓰던 서비스인데 진지하게 탈출 고민이 생겼다.
여러분은 서비스가 "쓰기 쉽다는 이유로" 탈출을 고려하는 장면을 보고 계십니다. 이것이 2025년이다.
I'll write a detailed blog post soon, but I'm thrilled to share that Fedify has received investment from the Sovereign Tech Fund, which means I'll be able to focus exclusively on the Fedify project for the next year or so.
早晩間 블로그 글로 仔細히 풀겠지만, Fedify 프로젝트가 STF로부터 投資를 받게 되어, 제가 앞으로 約 一年 동안 Fedify 프로젝트에만 專念할 수 있게 되었습니다.
이번 연휴 때 서울에서 모각작, 모각코 하실 파티를 만들어보려고 페북메신저 채널을 만들었습니다.! 파이브스팟이나 원루프사당을 쓸 것 같습니다.
https://m.me/cm/AbbiwdoizU4gxbqc/?send_source=cm:copy_invite_link
아직 Bash랑 zsh만 지원하긴 하지만… Optique에 셸 완성 기능을 얼추 구현한 것 같다. (아직 정식 릴리스는 안 함.)
SC2TS: TypeScript로 포팅한 스타크래프트 2 리플레이 파서
SC2TS를 공개했습니다. 처음에는 Claude Code를 공부하기 위한 연습 프로젝트로 시작했던 작업이었습니다.
왜 TypeScript로 포팅했을까요?
여러 이유가 있었지만, 크게 다섯 가지 이유로 정리할 수 있습니다.
첫째, 충분히 흥미로운 프로젝트여야 했습니다. 끝까지 완성할 수 있는 동기부여가 필요했는데, 이 프로젝트는 그럴 만한 가치가 있다고 판단했습니다.
둘째, 이미 관련 경험이 있었습니다. 예전에 Blizzard의 공식 라이브러리인 s2protocol에 Pull Request를 보내본 적이 있어서, 프로젝트의 구조와 동작 방식에 어느 정도 익숙했습니다.
셋째, 선례가 있었습니다. 이미 Go 언어로 포팅된 버전이 존재했기 때문에, TypeScript로도 충분히 구현 가능하다는 확신이 있었습니다.
넷째, 적절한 난이도였습니다. 내부 구현을 세세하게 다 알고 있지는 않았지만, 충분히 복잡하면서도 AI의 도움을 받아 해결할 수 있는 수준이라고 판단했습니다.
다섯째, 그리고 가장 중요한 이유는 스타크래프트 2 관련 분석 사이트를 AI 기능과 함께 만들어보고 싶었는데, 기존 s2protocol이 더 이상 공식 지원을 받지 못하게 되었기 때문입니다. 이 문제를 해결하기 위해서는 직접 TypeScript 버전을 만드는 것이 최선의 선택이었습니다.
사실 이러나 저러나.. 중간에 잠깐 휴가도 있었어서 생각보다는 오래걸렸네요.
TypeScript와 React에 File-based App 서버를 부착하여 단순하지만 완결성있는 풀 스택 개발 환경을 구축할 수 있습니다. 여기에 AGENTS.md 파일이나 mcp.json을 추가한다면 풀 스택 프로젝트에 바이브코딩까지 얹을 수 있겠습니다.
https://forum.dotnetdev.kr/t/typescript-react-file-based-app-c-api/13812
bgl gwyng shared the below article:
PyCon JP 2025 후기
Jaeyeol Lee @kodingwarrior@hackers.pub
이 글은 PyCon JP 2025에 참가한 한국인 개발자의 생생한 후기를 담고 있습니다. 저자는 PyCon KR에 꾸준히 참여해왔지만, 해외 컨퍼런스는 처음이라 설렘과 기대를 안고 일본으로 향했습니다. 히로시마에서 열린 이번 행사에서 저자는 다양한 세션에 참여하고, Findy와 Python Asia Association에서 주최한 DrinkUp 파티, 그리고 PKSHA Technology의 파티에 참여하며 여러 개발자들과 교류했습니다. 특히 FastAPI 개발자인 tiangolo와의 만남, Neovim을 사용하는 데이터 엔지니어와의 공감대 형성, 그리고 Emacs 사용자에게서 느낀 위기감 등 재미있는 에피소드들이 인상적입니다. "Innovation is a side effect of solving problem"이라는 tiangolo의 어록은 깊은 인상을 남겼습니다. 이 글은 PyCon JP가 외국인을 위한 배려가 돋보이는 행사였으며, 다양한 주제의 세션과 네트워킹 기회가 많았음을 강조합니다. 다음 PyCon JP에 발표자로 참여하고 싶다는 의지를 밝히며, 한국 커뮤니티도 외국인이 즐길 수 있는 컨텐츠가 늘어나기를 바라는 마음을 전합니다.
Read more →구트현엑은.. 가끔만 들어가도 싸우는 사람이 너무 많이 보여서 피곤함. 근데 싸우는 이유가 다 하찮음. 아이돌이 아니면 아이돌팬이 못생겼다는 이유로 싸우고. 향수 열일곱번 뿌렸다고 싸우고. 스카에서 공부안하고 다꾸했다고 싸우고. 엄마아빠에게 사랑받았다는 이유로 싸우고. 인터넷 세상이 다 그런거고 유희라지만. 가장 큰 문제는 타임라인이 이상해서 내가 팔로우를 잘 가꾼다고 해서 저런 내용을 안 볼 수 있는 환경이 아니라는 것임...
요즘 리모트 서버에서 코딩을 하고 있는데, 클로드 코드 돌려두고 자꾸 멍때리게 되어서 디스코드 알람을 만들었다
최근 며칠간 WAH라는 이름의 WebAssembly 인터프리터를 만들고 있다. ~와! 샌즈!~
WAH의 특징이라면 C로 작성되어 있는데 헤더 하나로 구성되어 있다는 점과, 거의 대부분의 코드를 Gemini가 짰다는 것 정도일까? (Claude Code도 좀 사용했지만 코드 생성은 Gemini가 다 했다.) Gemini가 디버깅을 시키면 답답한 게 사실이라서 최대한 프롬프트에 정보를 많이 넣고 few-shot으로 생성하게 하는 걸 목표로 했는데 생각보다 잘 되었다. 예를 들어서 한 프롬프트는 다음과 같았다. 저 문장 하나 하나가 시행착오의 결과이다.
@wah.h 에 if~else~end 명령을 구현하고, 대응되는 test_*.c 파일들이 모두 성공하도록 (또는, 해당 테스트에서 잘못된 점이 있을 경우 그 원인을) 고쳐줘. 아직 loop 관련된 코드는 처리할 필요 없고 테스트 중에 그걸 테스트하는 게 있다면 주석 처리해(지우지는 마). 컴파일과 실행은 &&로 한 번에 하도록 해. 정확한 구현 방법은 이래야 해: if~else~end에서 마지막 end는 사라지고, if는 else 직후 명령으로 이동하는 conditional jump로 재활용하며, else는 unconditional jump로 바뀌어(즉 실행기 입장에서 br과 else의 동작은 똑같아야 해! else를 아예 없애고 br로 대체할지 말지는 알아서 정해). 그러니까, if A B C else D E F end G 같은 명령이 있다면 preparsing 이후에는 if <offset to D> A B B C else <offset to G> D E F G 형태가 되어야 한다는 뜻이야. WebAssembly 명세에 따르면 if 문에는 block type이 따르는데, 이 타입을 사용해서 validation을 진행하는 것도 정확히 구현해야 해(block type이 function type (T1..Tn)->(U1..Um)이면 현재 스택에 T1..Tn 타입이 들어 있고 end 이후에는 U1..Um 타입이 들어 있어야 하고, 일반 타입 T가 들어 있다면 ()->(T)와 동일하게 취급함). block type은 validation 이후 preparsing 과정에서 사라져서 런타임에는 반영되지 않도록 해.
솔직히 너무 많이 요구하는 거 아닌가, 안되면 validation 부분을 어떻게 뺄지 고민하고 있었는데 시도 세 번만에 800줄짜리 diff가 떡하니 나오고 일단 보기에는 틀린 부분이 없어서 놀랐다. 물론 삽질도 많이 했는데 가장 많이 한 삽질은 테스트를 작성할 때 수동으로 WebAssembly 바이너리를 짜면서 바이트 숫자를 잘못 세어서 오류가 나는 거랑, 분명 WebAssembly opcode를 사용해야 하는데 자기 마음대로 코드를 정해 버린다거나 하는... 그런 우스운 상황이었다.
우습기도 하고 놀랍기도 하지만 이 코드를 내가 직접 짜지 않는 이유는 귀찮아서...라기보다는 내가 이걸로 하고 싶은 일이 따로 있고 WebAssembly 인터프리터를 만드는 게 주 목표는 아니기 때문이다. (원래 하고 싶은 일은 나중에 언급할 듯.) WebAssembly 구현이라고 하면 기술적으로 복잡해 보이지만, 내 용도에서 유래하는 몇 가지 조건(대표적으로 결정론적인 동작)을 제약으로 걸면 기술적으로 복잡하다기보다는 그냥 노가다에 가까워지기 때문에 끌리지 않는 것도 있긴 하다. 이전의 Angel이 과연 얼마까지 바이브 코딩으로 할 수 있는지를 테스트하는 목표였다면, 이번에는 정말로 목표를 달성하는 수단으로 기능할지 실험해 볼 작정이다.
https://github.com/lifthrasiir/wah/ 정식으로 공개했다. 현재 4800여줄. WebAssembly 1.0 거의 완전 지원, 2.0은 SIMD를 포함해 8~90% 정도 지원하는 정도까지 왔다. 하지만 아직 API 문제를 완전히 풀진 못해서 모듈 링킹이 안 되는 치명적인 문제가 있다...
요것이 진정한 Domain-Driven Development...
프로젝트 홍보: No programming language https://github.com/hoxy/no-lang
http://logitext.mit.edu/main
재미있는 웹 앱 중 하나. 논건 대수(Sequent Calculus)를 사용해 1차 논리("모든 대상에 대해"나 "어떤 대상이 있어"를 서술할 수 있는 논리)의 명제를 상호작용을 통해 증명해 볼 수 있다.
예를 들어 A /\ B -> A (A 그리고 B이면 A이다)를 증명하려면
- 위 명제를 입력칸에 넣는다.
->를 눌러 명제 안의 "이면"을 증명에서 쓸 수 있는 가정(|-의 왼쪽에 있는 것)으로 바꾼다.- 가정의
A /\B를 눌러 "그리고"의 양 측에 해당하는 가정A와B각각을 얻는다. - 가정이나 결론의
A를 눌러 가정을 사용하는 것으로 증명을 끝낸다.
보다 입문자에게 친절한 설명은 http://logitext.mit.edu/tutorial 에서 읽어볼 수 있다.
bgl gwyng shared the below article:
[잘라먹는 프로그래밍 언어론] 타입 체계는 명제 논리와 닮아있다 (커리-하워드 대응)
RanolP @ranolp@hackers.pub
이 글은 함수 타입, 합 타입, 곱 타입과 논리 연산의 대응 관계를 탐구하며, 특히 부정(negation)을 타입 시스템에서 어떻게 표현할 수 있는지에 대해 설명합니다. "P가 아니다"는 "P이면 거짓이다"와 동치라는 점을 이용하여, 타입 이론에서 값이 없음을 거짓으로 해석하고, 이를 통해 "정수를 0으로 나눌 수 없다"는 명제를 타입으로 표현하는 방법을 제시합니다. `div_by_zero :: Int -> ⊥`와 같은 표현을 통해 타입 체계와 명제 논리 간의 커리-하워드 대응을 보여주며, 타입 시스템이 논리적 추론과 어떻게 연결되는지에 대한 통찰력을 제공합니다.
Read more →
지원할만한 회사 정리하는 타래
[리디] 풀스택 엔지니어
- https://ridi.career.greetinghr.com/ko/o/106674
최근 며칠간 WAH라는 이름의 WebAssembly 인터프리터를 만들고 있다. ~와! 샌즈!~
WAH의 특징이라면 C로 작성되어 있는데 헤더 하나로 구성되어 있다는 점과, 거의 대부분의 코드를 Gemini가 짰다는 것 정도일까? (Claude Code도 좀 사용했지만 코드 생성은 Gemini가 다 했다.) Gemini가 디버깅을 시키면 답답한 게 사실이라서 최대한 프롬프트에 정보를 많이 넣고 few-shot으로 생성하게 하는 걸 목표로 했는데 생각보다 잘 되었다. 예를 들어서 한 프롬프트는 다음과 같았다. 저 문장 하나 하나가 시행착오의 결과이다.
@wah.h 에 if~else~end 명령을 구현하고, 대응되는 test_*.c 파일들이 모두 성공하도록 (또는, 해당 테스트에서 잘못된 점이 있을 경우 그 원인을) 고쳐줘. 아직 loop 관련된 코드는 처리할 필요 없고 테스트 중에 그걸 테스트하는 게 있다면 주석 처리해(지우지는 마). 컴파일과 실행은 &&로 한 번에 하도록 해. 정확한 구현 방법은 이래야 해: if~else~end에서 마지막 end는 사라지고, if는 else 직후 명령으로 이동하는 conditional jump로 재활용하며, else는 unconditional jump로 바뀌어(즉 실행기 입장에서 br과 else의 동작은 똑같아야 해! else를 아예 없애고 br로 대체할지 말지는 알아서 정해). 그러니까, if A B C else D E F end G 같은 명령이 있다면 preparsing 이후에는 if <offset to D> A B B C else <offset to G> D E F G 형태가 되어야 한다는 뜻이야. WebAssembly 명세에 따르면 if 문에는 block type이 따르는데, 이 타입을 사용해서 validation을 진행하는 것도 정확히 구현해야 해(block type이 function type (T1..Tn)->(U1..Um)이면 현재 스택에 T1..Tn 타입이 들어 있고 end 이후에는 U1..Um 타입이 들어 있어야 하고, 일반 타입 T가 들어 있다면 ()->(T)와 동일하게 취급함). block type은 validation 이후 preparsing 과정에서 사라져서 런타임에는 반영되지 않도록 해.
솔직히 너무 많이 요구하는 거 아닌가, 안되면 validation 부분을 어떻게 뺄지 고민하고 있었는데 시도 세 번만에 800줄짜리 diff가 떡하니 나오고 일단 보기에는 틀린 부분이 없어서 놀랐다. 물론 삽질도 많이 했는데 가장 많이 한 삽질은 테스트를 작성할 때 수동으로 WebAssembly 바이너리를 짜면서 바이트 숫자를 잘못 세어서 오류가 나는 거랑, 분명 WebAssembly opcode를 사용해야 하는데 자기 마음대로 코드를 정해 버린다거나 하는... 그런 우스운 상황이었다.
우습기도 하고 놀랍기도 하지만 이 코드를 내가 직접 짜지 않는 이유는 귀찮아서...라기보다는 내가 이걸로 하고 싶은 일이 따로 있고 WebAssembly 인터프리터를 만드는 게 주 목표는 아니기 때문이다. (원래 하고 싶은 일은 나중에 언급할 듯.) WebAssembly 구현이라고 하면 기술적으로 복잡해 보이지만, 내 용도에서 유래하는 몇 가지 조건(대표적으로 결정론적인 동작)을 제약으로 걸면 기술적으로 복잡하다기보다는 그냥 노가다에 가까워지기 때문에 끌리지 않는 것도 있긴 하다. 이전의 Angel이 과연 얼마까지 바이브 코딩으로 할 수 있는지를 테스트하는 목표였다면, 이번에는 정말로 목표를 달성하는 수단으로 기능할지 실험해 볼 작정이다.
bgl gwyng shared the below article:
내가 LLM과 함께 코딩하는 방식
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
이 글은 저자가 LLM(Large Language Model)을 활용하여 코딩하는 방법에 대한 개인적인 경험과 팁을 공유합니다. LLM 코딩 에이전트 사용 시 맥락 제공의 중요성을 강조하며, Claude Code 모델을 선호하는 이유와 그 장단점을 설명합니다. 세부적인 지시를 위해 GitHub 이슈를 활용하고, 설계는 사람이, 구현은 LLM이 담당하는 역할 분담을 제안합니다. 또한, 프로젝트 지침을 담은 *AGENTS\.md* 파일의 중요성과 Context7을 활용한 문서 제공 방법을 소개합니다. 계획 모드를 통해 LLM이 스스로 피드백 루프를 돌도록 유도하고, 필요한 경우 손 코딩을 병행하여 코딩의 재미를 유지하는 전략을 제시합니다. 이 글은 LLM을 단순한 도구가 아닌 협력적인 동료로 활용하여 개발 효율성을 높이는 방법을 모색하는 개발자들에게 유용한 인사이트를 제공합니다.
Read more →
이제 자신이 보여주고 싶지 않은 추천사를 가리는 기능도 추가되었습니다. 메인 페이지에서 링크 타고가시면 사용 가능해요. 많은 이용 부탁드립니다.
https://referral.akaiaoon.dev/ 이 링크에서 사용 가능하고, 내가 받은 추천사는 https://referral.akaiaoon.dev/u/:username 으로 볼 수 있습니다. 아래 말코링님의 추천사 리스트를 참조해 주세요.
그러고보니 첫 컨트리뷰터 malkoG 님의 PR이 머지되었습니다.
이거 아무리 봐도 옛날에 본 심리검사 문항 같다. 이런 느낌으로
제 GitHub 프로젝트 중 별 400개를 받은 프로젝트가 나왔습니다!
여기까지 오는데 정말 많은 격려와 응원해주셔서 감사합니다. ㅠㅠ
