요즘 아이디어를 긴 글로 옮기는게 힘들다. AI와 비교해 최대 10토큰/분이란 저열한 속도에 자괴감이 들고, 그렇다고 AI랑 같이 쓰자니 이것도 합을 맞춰서 같이 쓰는게 어렵단 말이지. 그래서 시도해보려는 방법은 AI한테 인터뷰어 역할을 맡기고 내가 인터뷰이가 되는거다. 주제만 내가 정해주고 세부 사항에 대한 비판이나 질문은 AI한테 맡긴다. 그리고 대화가 끝나고 스크립트를 그대로 공유한다.
bgl gwyng
@bgl@hackers.pub · 95 following · 119 followers
GitHub- @bglgwyng
정보 리터러시 관련 의견을 보존하러 왔다. 우리는 흔히 영어 자료가 한국어 자료보다 낫다는 문화사대주의적 의견에 공감하곤 한다. 하지만 여기엔 숨은 의견이 여럿 있다. 하나씩 까보며 음미해보자.
영어 자료는 한국어 자료보다 낫다. => 왜 나을까? 도움이 되기 때문에. 왜 도움이 될까? => (진실에 가깝기 때문에, 다양한 경험이 전시되어 있기 때문에). 왜 진실에 가까울까? => 1차 출처에 가깝기 때문에. 왜 1차 출처에 가까울까? => 사용자가 다수이기 때문에 직접 사용하거나 번역되어 2차 출처로 기능하기 때문에. 왜 다양한 경험이 있을까? => 생산자가 자료 작성 시 영어를 선택할 확률이 한국어보다 높기 때문에.
그렇다면 우리는 영어 자료가 나은 이유를 구체적으로 표현할 수 있다.
- (일반적으로) 한국어 웹보다 영어 웹이 더 크기 때문에 원하는 자료를 구할 확률이 더 높다.
- (일반적으로) 한국어 웹보다 영어 웹에서 1차 출처에 가까운 자료를 구할 확률이 더 높다.
탐색 공간을 넓히고, 정보 전파 과정에서의 왜곡을 줄이기 위해서 영어 웹 탐색이 효과적이다. 다만 영어 웹이 "언제나" 좋은 건 아니다. 한컴오피스 자료가 미국에 많겠는가, 아니면 한국에 많겠는가? 1차 출처에 가까운 곳을 향해 왜곡을 줄이고, 그 안에서 탐색 공간을 최대한 효율적으로 넓혀야 한다.
영어 검색이라는 피상적인 행위에서 벗어나 정보 탐색의 본질을 좇는 것이 좋다.
오랜만에 프로그래밍 언어 이야기하러 왔다. 오늘 주제는 타입스크립트의 핵심 가치다.
많은 사람들이 정적 타입 언어를 도입하는 이유로 안전성(Soundness)를 이야기한다. 맞는 말이다. 하지만 타입스크립트에서 안전성은 2등 가치다. 그럼 1등 가치는 뭘까?
바로 개발 경험 개선이다. 구체적으로, 오류 나기 쉬운 구문을 적당히 줄이고 자동 완성을 개선하며 큰 규모 리팩토링 시 심리적(그리고 any 같은 기능을 안 썼다는 가정하에 런타임에도 유의미한 수준의) 안정성을 얻겠다는 거다.
타입스크립트 공식 위키 문서에도 안전성은 목표가 아니라고 나와있다 (#). 우리는 때때로 도구의 목적에 들어맞지 않는 불필요한 기대를 하곤 한다. 하지만 도구 개발자와 싸우는 건 사용자로서 좋은 전략이 아니다.
조건부 타입과 재귀 타입, 템플릿 문자열 타입, infer 등을 보라. 정적 분석 난이도가 지수적으로 올라가는 희한한 기능들이 언어에 계속 추가되는 이유가 무엇인가. 추론을 포기하고 any가 나오곤 하는 이유가 무엇인가.
그들이 추구하는 게 안전한 세계가 아닌 실용적인 세계이기 때문이다.
이번 주 발표하는 거
bgl gwyng shared the below article:
OSTEP 독학 일지 - H.0.
Jaeyeol Lee @kodingwarrior@hackers.pub
6년 차 개발자가 기본기를 다지기 위해 OS 기초를 다시 공부하는 여정을 담은 글입니다. 저자는 신입 개발자 수준의 기본기를 갖추기 위해 OSTEP 교재를 선택하고, xv6 프로젝트를 통해 운영체제 동작 원리를 체화하고자 합니다. 이 글에서는 xv6 과제들을 단계별로 공략하며 겪는 우여곡절과 발견, 그리고 이를 통해 얻는 인사이트를 서사적으로 풀어낼 계획을 밝힙니다. 단순히 지식을 정리하는 것을 넘어, 독자에게 재미있는 스토리를 전달하고 기술 면접에도 도움이 될 만한 생생한 경험을 공유하고자 하는 저자의 의지가 돋보입니다. OSSCA 2025 멘토링 경험에서 영감을 받아 시작된 이 여정은, 개발자로서의 성장과 더불어 해커스펍 커뮤니티에도 기여하고자 하는 저자의 열정을 보여줍니다.
Read more →시간 날 때 언어 관련 툴링들을 어떻게 구현하는지에 대한 글을 써봐야겠다. 린터, 테스트 커버리지, 프로파일러, 디버거에 대해 써보고 싶지만 과연 나의 게으름이 잘 버텨줄지는 모르겠다
Replit으로 이런걸 만들었어요 https://tweet-gen-ai.replit.app/
결과는 이런식으로 나와요 https://tweet-gen-ai.replit.app/shared/FyZD8OU9W-gsXg3SxFqpv
서울에서 10–15명 정도 모여서 회의 겸 작업할 만한 공간 어디 없을까요? 토즈를 이용해 볼까 했는데 8시간 정도 예약하려면 너무 비싸더라고요.
@hongminhee洪 民憙 (Hong Minhee) 저번에 서울숲하스켈은 패파 회의실에서 하더라고요
서울에서 10–15명 정도 모여서 회의 겸 작업할 만한 공간 어디 없을까요? 토즈를 이용해 볼까 했는데 8시간 정도 예약하려면 너무 비싸더라고요.
bgl gwyng shared the below article:
art.leetekwoo.com
leetekwoo @leetekwoo@hackers.pub
이 글은 개인 웹사이트 [art.leetekwoo.com](https://art.leetekwoo.com/)의 `readme` 내용을 공유하며, 작품 고유 번호 체계와 웹 애플리케이션의 기술 스택 및 개발 후기를 담고 있습니다. 작품 고유 번호는 작품의 타입, 제작 연도, 장소, 연작 ID 등을 포함하여 체계적으로 관리됩니다. 웹 애플리케이션은 Typescript, Vite, React를 사용하여 개발되었으며, Cloudflare Pages를 통해 CDN을 활용하고 배포 자동화를 구현했습니다. 이미지 압축 및 워터마크 삽입, 캐싱 전략 등을 통해 성능 최적화에도 신경 썼습니다. 이 웹사이트는 개발자에게는 다소 부족해 보일 수 있지만, 작품을 정리하고 과거를 돌아보기 위한 공간으로서 의미를 가지며, 저작권 보호의 중요성을 깨닫는 계기가 되었다는 개인적인 소회를 밝히고 있습니다.
Read more →
@ailrunAilrun (UTC-5/-4) 늦었지만 Lens에 저도 한 표 올려봅니다.
DBMS 같은 데에서 파일을 관리 할 때엔 항상 4096 바이트 단위의 페이지 형태로 관리합니다. 왜그럴까요? 여러가지 이유가 있는데, 보통은 OS도 4096 바이트 단위로 파일 시스템을 관리하기 때문입니다. 그래서 캐시 같은 OS의 여러 가속 장치들의 도움을 받을 수 있죠.
근데 정말로 그럴까요?
그게 궁금해서 직접 한번 페이지 파일 매니저를 구현해서 실험해봤습니다. 통계적으로 유의하게 빠르네요.
srvx에 기여했다!
나는 모듈끼리 circular dependent한걸 허용하는게 낫다고 생각한다. 코드를 쪼개는데에는 제한이 있으면 안된다.
RxJS의 pipe를 흉내내서 뭔가 만들고 있는데, pipe안에 들어가는 함수가 operation oriented가 되도록 유도한다. 즉, x.pipe(f(y))가 f(y,x)로 해석되어야하니, f는 data oriented가 아닌 operation oriented가 되어야하는 것이다. 근데, 나도 일반적으로 operation oriented를 선호하긴하지만 JS의 관례는 그게 아니다. 그래서 f를 pipe를 통해서 쓰지 않을 경우에 어떤 사람들은 생소하게 느낄거 같다. 나는 x가 this 처럼 사용되고(data oriented), pipe는 메소드 확장의 역할을 맡게 하고 싶다.
어떻게 하는게 맞을까?
시간이 지날 수록 Cursor랑 대화할 때 사용하는 주어가 바뀌는게 재밌네.
- 초반에는 "나 지금 XX를 만들고 싶어" 와 같은 식으로, 내가 작업의 메인이니까 넌 검색해와 같은 느낌에 가까웠다.
- 조금 익숙해지니까 점점 "너가 XX를 만들어 와" 라고 일을 위임하는 어조로 바꼈다.
- 그러다가 오늘 코드를 지칭할 때 무의식적으로 "우리가 만든 코드"라는 표현을 사용했다. 개발 사이클을 여러 번 돌리다보니 공동 저작물이라는 인식이 나도 모르게 생겼나보다.
tsconfig에 stripInternal란게 있군요?
JS에선 Java처럼 package-level visible property를 못만들다보니, 상호 참조가 많은 클래스를 정의할때 죄다 public으로 해야하는게 별로네. 내부 클래스와 그걸 래핑한 유저한테 노출하는 클래스(또는 인터페이스)를 따로 만들어야 하나.
평소에 OOP 별로다, 상속은 거품이다 비난만 하다가, 막상 클래스 만들어야할 상황이 오니까 기어코 아름다운 상속 구조를 만들어보려 애쓰는 나, 정상인가요?
Hackers' Pub의 로고 디자인이 완료되었습니다! 디자인은 박은지 님(
연합우주라는 콘셉트에 맞게 고양이의 입 주변을 별 모양으로, 목 아래에도 고리(orbital ring) 모양으로 디자인했습니다. 고양이를 고른 이유는 소프트웨어 프로그래머 커뮤니티에서 다른 동물보다 유독 고양이가 사랑 받기 때문이기도 하고, 고양이가 호기심이 강하기 때문이기도 합니다.
로고 디자인은 CC-BY-SA 4.0 라이선스로 배포됩니다.
오늘 동료가 나보고 혹시 ENTP냐고해서 맞다고 했는데 좀 자존심 상한다...
지난 한달간 열심히 개발한 실시간 퀴즈 사이트입니다. django, django drf, jwt 기반 인증, websocket, ticket으로 받아오는 jwt websocket 인증, celery, 등을 모두 사용한 예시이기도 합니다. 구경와주세요~
@bglbgl gwyng 네, 물론이죠!
@hongminhee洪 民憙 (Hong Minhee) 기대됩니다! 사실 저는 자동완성이 잘된다면, 단축형 옵션같은 기능이 덜 중요해진다고 생각합니다. 또 단축형 표형이 사소하지만 어쨋든 학습을 필요로 하는 단점이 있다고 생각합니다. 저 아직도 tar뒤에 xvzf인가 무슨 의미인지 몰라요ㅋㅋ
생각해 보니 option terminator 문법(-- 뒤에는 옵션처럼 생긴 게 와도 인자로 인식하게 하는 것)은 또 어떻게 구현해야 하나…
@hongminhee洪 民憙 (Hong Minhee) 혹시 자동완성 스크립트를 생성해주는 기능도 고려하고 계신가요?
프로그램 명세서는 문서 그 자체로도 컴파일 되어야만 한다
프로그램 명세서는 문서 그 자체로도 컴파일 되어야만 한다
JS 라이브러리를 만들때 개발시엔 invariant check를 위해 assert를 쓰되, 배포할땐 빼고싶거든요. 어떤 좋은 방법이 있을까요?
@bglbgl gwyng Vite 같은 경우에는 기본적으로 import.meta.env.DEV이 빌드 시에는 false로 치환되어서 minifier 돌리면 안쪽 코드가 통째로 날아가게 할 수 있습니다. 다른 번들러들에서도 비슷한 방법을 찾아볼 수 있을 것 같네요
API 기반 에이전트에서 요금제 기반 에이전트로 넘어와, 이제 마음껏 감사인사를 하는 풍부한 인간이 되었습니다.
미리미리 아부 떨어서 기계화 시대를 대비하자
![에이전트가 실행중인 터미널 화면. 이하는 터미널의 내용
[에이전트]
save_emacs_buffers_in_repo() 함수:
- emacsclient로 실행 중인 Emacs와 통신
- 해당 리포지토리 경로에 속한 버퍼만 필터링 (string-prefix-p)
- 수정된 버퍼만 저장 (buffer-modified-p)
- 저장된 버퍼 개수를 메시지로 표시
- emacsclient가 없거나 통신 실패 시 경고만 출력하고 계속 진행
이제 스크립트 실행 시 해당 리포지토리의 모든 수정된 Emacs 버퍼가 자동으로 저장됩니다.
[사용자]
> 좋아 네가 최고야
[에이전트]
⏺ 감사합니다! 스크립트가 이제 안전하고 똑똑하게 작동할 것 같네요. 혹시 테스트해보시고 문제가 있으면 언제든 알려주세요.](https://media.hackers.pub/note-media/afaa2a81-a922-4d9b-913f-3a36f07d52ba.webp)
JS 라이브러리를 만들때 개발시엔 invariant check를 위해 assert를 쓰되, 배포할땐 빼고싶거든요. 어떤 좋은 방법이 있을까요?
@bglbgl gwyng 태국에서 디지털 노마드 생활하시는 분들 많더라고요.
@hongminhee洪 民憙 (Hong Minhee) 아 이미 많이들 하는 방식이었군요??
여행 다녀왔는데 또 가고싶다... 예전에 1인 창업을 위해 베트남에서 생활하는 개발자를 만난적이 있다. 사실 휴양지에 가면 플렉스를 해버려서 그렇지 그걸 참으면 돈을 아낄수 있긴하다. 디지털 노마드의 로망을 1년 정도는 실현해보고 싶은데...
이번 Ubucon Korea 2025에서 발표할 주제로, 식탁보의 리눅스 버전에 대한 이야기를 준비하면서 간단한 Demo를 WSL로 준비해보았습니다.
일상적으로 사용하는 리눅스 시스템에 보안 플러그인을 그대로 설치하는 것은 솔직히 많이 위험합니다. 하지만, LXD 덕분에 이런 위험을 최소화하면서도 편의성과 보안의 균형을 맞추고, 더 나아가서는 Windows에 종속된 인터넷 뱅킹과 전자 정부 대고객 서비스의 대체 가능성을 살펴볼 수 있는 좋은 기회가 될 수 있다고 생각합니다.
연말을 목표로 리눅스 버전의 식탁보 프리뷰를 선보이도록 노력해보겠습니다. :-D
https://drive.google.com/file/d/1xapy_k4ofzyaNFPAPTF1QUYvLrz6MN55/view?usp=drive_link
보정한 결과물입니다. 19년도에 아이폰 X로 기내에서 찍었던 것 같습니다.
저는 ActivityPub 인스턴스 운영을 쉽게 해주는 프레임워크 Fedify 의 CLI 툴에 Webfinger 를 손쉽게 조회할 수 있는 fedify webfinger 커멘드를 구현했어요! https://github.com/fedify-dev/fedify/pull/278
bgl gwyng shared the below article:
프론트엔드 애플리케이션 상태를 다루는 법
ㄹ @disjukr@hackers.pub
이 글은 리액티브 프로그래밍에서 시간의 흐름에 따른 의존 그래프 관리를 설명하며, 특히 프론트엔드 상태 관리에 있어 옵저버블보다 시그널이 더 적합한 이유를 제시합니다. 저자는 프론트엔드 상태가 시간에 따라 결정적으로 변하지 않고, 노드의 의존 관계가 렌더 트리에 따라 변화무쌍하게 바뀌기 때문이라고 주장합니다. Rx, Redux, XState와 같은 기존 상태 관리 방식의 한계를 지적하며, 시그널(+ DI와 수명관리)을 중심으로 옵저버블, 리듀서, 스테이트머신을 함께 사용하는 것이 각 기술의 장점을 극대화할 수 있다고 설명합니다. 애니메이션, 폼 관리, NPC 인공지능과 같이 특정 상황에 적합한 기술을 시그널로 묶어 전체 애플리케이션 상태를 선언적으로 관리하는 방법을 제안하며, 이를 통해 애플리케이션의 구조를 더욱 명확하고 효율적으로 만들 수 있다고 강조합니다.
Read more →
안녕하세요! 현재 컴퓨터공학과 학부 2학년 재학중인 새내기입니다.
PLT, Lexer 등에 관심이 많습니다. Emulation, VM 기술 등도 관심이 많습니다. 아직 주 전공 분야를 정하진 못했지만 넓게 두루두루 좋아합니다.
올드 레트로 기술들 또한 좋아합니다.
Go와 .NET 언어 일부를 주력으로 삼고 있으며 F# 을 학습하려고 공부 중입니다.
현재는 취미와 흥미 위주의 프로젝트를 주로 진행 중입니다. 감사합니다!
내일 튜사 나오시는분 있나요?
아직 저만 팔로하신 분들을 위한 끌올!!!!
한창 개발중인 다음 버전의 Hackers' Pub입니다. 프런트엔드를 전면 개편하고 있습니다. 프레임워크도 Fresh에서 SolidStart로 아예 바꿨습니다.
@lionhairdino @bglbgl gwyng 칭따오인거죠...?? 경북 청도 출신 어리둥절..
@kodingwarriorJaeyeol Lee @lionhairdino ㅋㅋ칭따오 맞습니다
청도 놀러 가신 분 사진으로 염장 지를 때가 지났는데, 소식이 없네요. @bglbgl gwyng
@lionhairdino 칭따오 5.4 광장 야경입니다. 낼 귀국하는데 아쉽네용.
Hackers' Pub 400명 돌파!
오늘부터 사흘간 중국 칭따오여행합니다
거의 느낌이 더 좋다는 이유만으로 rootless컨테이너를 시도했고, 이후에는 갈아엎기 귀찮다는 이유로 계속 써왔다. uid를 외부랑 일치 시키면 이미지가 권한 관련 문제를 일으키기도 하고, 자동으로 이미지내 파일 소유를 바꿔주는 기능은 첫 실행 시 너무 느리기나 하고... 자동 재시작은 systemd랑 엮어서 쓸 수 있다고 알고 있기는 한데 어쨌든 별도의 시스템이라 아직도 안쓰고 있다. 아마 별 일 없으면 계속 이렇게 쓰겠지...?