최근에 Apple의 Pkl에 옵션 추가하려 한 게 내 예상보다 스코프가 넓어서인지 SPICE(Pkl의 기능제안 프로세스인 듯) 작성해달라는 요청을 받았음. 문서 길이가 길어서 제미나이 CLI한테 내 PR 내용과 이미 있는 SPICE들 읽어서 작성해달라 요청했더니 소소한 실수 몇 개 빼고는 꽤 만족스럽게 작성해줬다!

https://github.com/apple/pkl-evolution/pull/24

AI와 함께 오라클 클라우드에 terraform으로 쿠버네티스 클러스터 올리기 해서 결국 성공했다... 맨날 콘솔로 만들땐 실패했었는데 역시 오라클은 자체서비스 믿지말고 무조건 외부서비스를 사용해야 한다는 생각이 더 강해졌다...

Its been a while! I just added #HackersPub (https://hackers.pub), #Elk (@elk) and #Elgg (@elgg) icons to https://iconography.fediverse.info

#코딩IDE

나중에 나올 IDE들은, 로컬 모델을 기본적으로 탑재하거나 뭐 그렇지 않을까?

http://logitext.mit.edu/main 재미있는 웹 앱 중 하나. 논건 대수(Sequent Calculus)를 사용해 1차 논리("모든 대상에 대해"나 "어떤 대상이 있어"를 서술할 수 있는 논리)의 명제를 상호작용을 통해 증명해 볼 수 있다. 예를 들어 A /\ B -> A (A 그리고 B이면 A이다)를 증명하려면

• 위 명제를 입력칸에 넣는다.
• ->를 눌러 명제 안의 "이면"을 증명에서 쓸 수 있는 가정(|-의 왼쪽에 있는 것)으로 바꾼다.
• 가정의 A /\B를 눌러 "그리고"의 양 측에 해당하는 가정 A와 B 각각을 얻는다.
• 가정이나 결론의 A를 눌러 가정을 사용하는 것으로 증명을 끝낸다.

보다 입문자에게 친절한 설명은 http://logitext.mit.edu/tutorial 에서 읽어볼 수 있다.

나는 매킨토시로 일기쓰는 사람이다 무섭지

rangho.is 사고싶다

그러면

• 블로그는 rangho.is/thinking에
• 메모장은 rangho.is/knowing에
• 발표자료는 rangho.is/talking에 다 집어넣을 수 있을텐데

너무 이른 시점에 일반화를 걱정하는 것은 위험할 수 있습니다. 자신이 코드를 작성하든 다른 사람의 코드를 이해하려 하든, 우리는 이 책에서 취한 접근 방식을 따를 것을 권장합니다. 즉, 일반적인 것부터 시작하지 말고 구체적인 예시부터 시작하세요. 그런 다음 그들이 어떤 측면을 공유하는지 관찰하세요. 학습자로서 이러한 순서는 더 쉬운 구체적인 예시를 토대로 더 어려운 추상적 개념을 이해할 기회를 더 많이 제공합니다. 저자로서 이러한 순서는 더 추상적인 발상이 타당성을 갖고 목적을 지닐 수 있도록 도와줍니다.

— 《Finding Success (and Failure) in Haskell》, 149쪽

문서와 플러그인 차이 때문에 결국 pulumi에서 terraform으로 갈아타고 말았다...

Real world Haskell use case arrived

https://tidalcycles.org/

최종적으로는 Monorepo로 구성했다. 각각이 장단점이 있는 선택지라서, 고민고민하다가, 개발중 반복작업을 최소화하는 쪽과 미래의 누군가 유지보수하기 편한 (혹은 내가 유지보수한다면 좀 더 편할 것으로 예상되는) 쪽에 무게를 두기로 했고 그렇게 Monorepo로 결정했다. 결국 AI의 추천대로 흘러가고 있..

최근 디스코드 메시지를 모바일 앱에서도 종종 확인해야 하는 경우가 있는데, 메시지의 글씨 크기가 작아서 불편하던 차에, 클래식 채팅 문자 크기 라는 옵션이 켜져있고 이 옵션이 켜져 있으면 글씨 크기가 작아진다는 것을 알게 되어, 바로 옵션을 꺼버렸다. (중년 개발자들에게 이 옵션을 끄는 것을 추천합니다.)

페디버스 인스턴스 하나쯤 만들고 싶다
그치만 너무 귀찮다
그치만 커스텀 이모지도 넣고 하고 싶다
그치만
그치만

의 무한 반복 중임 요즘

구글에 '해커스펍'을 검색해도 검색 결과에 hackers.pub이 보이지 않는다는 걸 알았다. '해커즈 퍼브'도 마찬가지다.

오늘도 COMPILING!

디버깅 정보를 뽑을 수 없지만 데이터를 잔뜩 입력해볼 수 있는 환경에서 발생하는 오류의 재현 테스트 케이스를 코드로 작성하는데 성공했다. 이게 되니까 바로 의심 가는 곳 수정이 가능했고, 테스트 통과 ㅠ...

종이를 물고 있는 퍼렁공뇽

https://github.com/fedify-dev/fedify

Libghostty is coming. 👻 The first library will be libghostty-vt: a zero-dependency (not even libc!) library that provides an API for parsing terminal sequences and maintaining terminal state, extracted directly from Ghostty's real-world proven core. https://mitchellh.com/writing/libghostty-is-coming

しかしGitHubのサポートの処理が早いのはまあそれもそうかという感じだけど、ボランティアで回しているCodebergも5分以内とかで対応してくれるのは驚異的だよなあ

Codeberg とかも普通にスパムの被害には遭っているし（私個人の通知まで貫通してきた物の絶対数だけを見ても GitHub よりやや多い）、流石に攻撃の対象になっていることを以て批判するのは酷では

GitHub’s relevance as a development platform is rapidly devolving: I have gotten more spam on there and through there in the past couple of weeks than I will get in an entire year or two, and Copilot means they just don’t care.

Open Source deserves new homes. I’ll continue moving my projects away.

#GitHub #GiveUpGitHub #OpenSource #foss

회사에서 MLOps 를 구축해야 하는데 구축해본 적 있는 분이 있다면 커피챗을 좀 해보고 싶다...

Pheonix 트레이싱 도구를 이제서야 도입했고, Airflow 같은 것들도 제대로 써보고 싶은데 파이프라인을 제대로 구성해본 적이 없어서 생각은 하는데 아직 정확히 어떻게 구성해야 할지 잘 모르겠다..

토큰-링 네트워크에서 영감을 얻어 노드들이 서로 토큰을 돌려가며 서로 헬스체크하는 일종의 탈중앙화(?) 헬스체크 서비스를 대충 만들어보았다. 토큰 네트워크를 토큰이 돌며 노드들이 서로의 주소를 사인하고, 만약 다음 노드가 없거나 연락 불가하다면 이슈어에게 다시 돌려주는 방식의 단순한 토큰링 네크워크인데, 잘 작동해서 기분이 좋다.

요전번에 산 책 '관계형 데이터베이스 실전 입문' 첫 챕터를 정리했다. 정리하는 김에 원래 대학원에서 썼던 학술용 홈피도 싹 다 갈아엎을 겸 해서 맘에 드는 테마 하나 포크해서 블로그도 다시 만들어서 첫 포스트로 써서 올림...글로 쓰다보니 뭔가 보충하면 좋을 것 같은 내용들이 보였는데, 특히나 관계형 모델에서 튜플(=행)은 하나의 집합이라서 그 원소가 사실 순서가 없어도 되는데 실제 SQL로 표현되는 테이블에서는 순서가 있어야한다는 지점이 흥미로워서 다른 DB 개론서들 보면서 그 내용들을 추가하다보니 결국엔 형식적으로 정의하는 부분까지 넣게 됐다. 써놓고 보니 배보다 배꼽이 더 커진 듯한 느낌이지만...뭐 어때, 재밌으면 됐지!

https://rosettalens.com/s/ko/the-golden-rule-of-software-quality

최근에는 터미널에서 돌릴 수 있는 완성도 있는 테트리스를 만들어 보려고 하고 있어요
물론 강의실에서 그럴듯하게 테트리스를 하기 위함이지만...

제가 해커스펍 쓰면서 가장 좋아하게 됀 기능은 이모지 리액션이예요 😋

여러분 int *p를 (int *)(uintptr_t)p 캐스팅하지 마세요 출처라는 것이 바뀝니다

.NET 10의 File-based App으로 "당연히" .NET Framework 4.8을 타겟으로 하는 레거시 애플리케이션을 개발하는 것도 지원됩니다.

.NET Framework의 애플리케이션 인프라를 복합적으로 활용하는 log4net을 사용하는 애플리케이션을 File-based App 기반으로 어떻게 작성할 수 있는지 간단히 다루어봤습니다. :-D

이렇게 기존 레거시 코드를 옮겨올 수도 있으니 .NET Framework 기반 애플리케이션도 바이브코딩의 이점을 누리게 할 수 있을 것입니다.

#닷넷 #레거시 #바이브코딩 #현대화

https://forum.dotnetdev.kr/t/file-based-app-net-framework-4-8/13784/1

인간관계에 있어 일을 주든, 투자를 해주든, 내가 영업하는 제품을 구매해주든 어느 한쪽 또는 양쪽에 이익을 가져다주지 못하는 관계인 경우 아예 연락이 끊기는 정도의 수순을 밟게 되는 것이 일반적임.

오픈소스 활동의 좋은 점은 저런 명확한 이익관계가 없더라도 한번 서로 인지된 사람이면은 가늘더라도 꽤 오랫동안 서로 연락하는 관계를 유지할 수 있다는 점임.

개발자도 우울증 많다고 얘기는 많이 들었다.

이런 점에 비춰봤을 때 오픈소스는 개발자의 우울감과 소외감 극복에 도움이 될 수 있다고 생각한다.

안녕하세요 랭호입니다

여기는 대피소 겸 나중에 긴 글 덤핑하는 용도로 써야겟다 히히

공개계는 블스, 사담계는 개인서버, 대피소는 여기 이렇게 해서 쓰리배럭 굴릴까 하는데요 제 서버가 DB 쿼리 문제때문에 좀 아파서 여기 자주 올지도 몰?라요 ㅋㅋ................

나중에 블로그 만들면 자랑하러 올게요

오늘 Fedify 모임에서 페디버스 인스턴스 만들어주는 서비스에 대해 나왔었는데 역시 한 번 구현은 해보고 싶다

상시 #연친소 #개발자_연친소 (개발자/프로그래머 버전, 250921 갱신)

대학교 탈출을 꿈꾸고 있는 학부생입니다. 아직은 취미(😭)로 게임/웹 개발을 하고 있고 간단한 SVG를 다룰 수 있습니다(갑자기??).

🌐 https://eatch.dev
🐱 https://github.com/EatChangmyeong
📝
https://blog.eatch.dev / @blog.eatch.devL"Widestring" (이전 중)
🎈 https://solved.ac/profile/dlaud5379 (💙₄ 2300, OVER 14313.8, CLASS 6)

해커스펍 언어 선택창을 보니까 ko-KR이랑 ko-KP 말고 ko-CN도 있구나 신기하네...

이제 WinForm과 WPF도 바이브코딩하는 시대입니다.

File-based app 기반의 템플릿과 Cursor, Github Copilot 등 MCP 서버를 활용할 수 있는 코딩 어시스턴트용 프롬프트를 결합한 개발 방법론, 도서, 아티클 등의 리소스를 준비하고 있습니다.

#바이브코딩 #AI #닷넷

https://github.com/rkttu/dotnet-fba-templates

asciinema 3.0 and Tailscale work kinda incredibly well together.

> ssh
> tmux
> asciinema stream -l $(tailscale ip -4):8022
> start slow command
> detach

Then load frood:8022 on my phone and keep an eye on the slow command while watching TV ✨

Git: Introduce Rust and announce that it will become mandatorty
L: https://lore.kernel.org/git/20250904-b4-pks-rust-breaking-change-v1-0-3af1d25e0be9@pks.im/
C: https://news.ycombinator.com/item?id=45312696
posted on 2025.09.20 at 08:17:33 (c=0, p=8)

와, 윈도우즈 지원 계획이 없다던 zellij를 어떤 지인분이 포크 떠서 윈도우즈 지원하는 버전으로 만드셨다...... https://github.com/KudoLayton/zellij

최근 며칠간 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이 과연 얼마까지 바이브 코딩으로 할 수 있는지를 테스트하는 목표였다면, 이번에는 정말로 목표를 달성하는 수단으로 기능할지 실험해 볼 작정이다.

Thinking about building “#Fedify Studio” (tentative name)—a web-based #ActivityPub debugging & development toolkit, like a supercharged version of ActivityPub.Academy and fedify inbox command. Imagine having a proper UI for testing activities, inspecting actors, debugging federation issues… Would this be useful for other ActivityPub developers out there?

#fedidev #fediverse

effect-ts 를 사용해보면서 느낀 장점 중 하나는... (단점이 아직 좀 더 많습니다... 3.x 인데도 코어 라이브러리 호출에 예외가 터지는 경험을 함.) async 에 대한 확인 작업이다. 이게 비동기인지 아닌지 걱정하지 않고 코드를 쓰게 된다.

내가 접근 가능한 언어 중 lua 나 ruby 또는 go 를 제대로 쓴적이 없어서 색다른 경험이긴 해. function color 구분하지 않고 호출하는 장점이 이런 느낌이구나.

예를 들면;

 const rotationUnit = unit || (yield* getCurrentLogRotationUnit());

물론 상위 함수가 effect 를 위해 제너레이터로 감싸져 있긴 하지만 이 부분은 여러 번 보고 쓰다 보니 익숙해 지더라. callback 함수 강제로 써야하던가 반대로 더이상 안쓰게 되던 경험과 비슷비슷함.

그리고 예외 처리 안하고 모두 값으로 wrapping 하는 것은 여러모로 바람직하다. 다른 플랫폼 기능 안쓰더라도 부분부분 option 이나 result 같은 것만 써도 더 나은 코드를 작성하는데 도움이 된다. 4.0 에는 좀 더 경량화 된다고 하니 업데이트 안되는 패키지 - eg. neverthrow 등 - 쓰는 것보다 그냥 effect-ts 의 에러 관리 기능만 적용해도 좋겠다.

throw 는 아무리 봐도 모던 goto 여...

C++에서 UB는 하드웨어 수준에서는 UB가 아니라고 생각했던 얼마 전에 나어게 경종을 올렸던 글. "Pointers are complicated" 시리즈. 주로 Rust에 관한 글이지만 abstract machine, memory model의 개념은 C++에도 있으며 하드웨어와는 확연히 다르다. 특히 포인터가 얼마나 까다로운 개념인지, 컴파일러가 어떠한 가정하에서 최적화를 수행하는지 다시금 익혔다.

• https://www.ralfj.de/blog/2018/07/24/pointers-and-bytes.html
• https://www.ralfj.de/blog/2019/07/14/uninit.html
• https://www.ralfj.de/blog/2020/12/14/provenance.html
• https://www.ralfj.de/blog/2022/04/11/provenance-exposed.html

연구자로서, 또한 한 명의 개발자로서 현 세대에 항상 궁금한 것은 AI가 얼마나 도움이 되느냐이다.

Haskell, OCaml은 말할 것도 없고, JavaScript, Python도 AI와 써 본 경험으로는 그들이 큰 도움이 되느냐는 질문에 자신있게 "그렇다"고 하기 힘든 경험만 해봤기 때문이다.

내가 코드의 형식에 대한 집착이 너무 심한 것이 원인일 수는 있겠으나... AI가 준 결과를 여기 바꾸고 저기 바꾸다보면 결국 내가 쓴 처음부터 코드가 된다.

얼핏 드는 생각으로는 거의 "타입도 없고 문서화도 잘 안되어 있는 환경에서는 사람들이 기능을 이해하기 어려우니 AI를 쓰겠다..."싶다가도, "그러면 내가 잘 아는 분야에 대해서 왜 AI를 써야하지?"하는 생각도 떨치기 힘든 상황이 자주 찾아온다.

결과적으로 나는 AI를 사용하려는 시도를 (적어도 일시적으로는) 멈추었다.

요즘 바이브 코딩이 유행이라길래 (그리고 @hongminhee@hackers.pub洪 民憙 (Hong Minhee) 님 글 보고 넘 좋아서 배워야 할 것 같아서) 일단은 학생은 제미나이 유료 플랜이 공짜길래, 제미나이 CLI로 코딩해보고 있습니다... 신기하네요

자기소개: 바이브코딩 116일차... 여전히 아는 건 없고 어떻게 동작하는지 모르겠지만 어쨌든 굴러가니 된 게 아닐까??의 마인드를 갖고 있는 삐비에요. 이번에 @kodingwarriorJaeyeol Lee 님이 추천해주신 #100일챌린지(오츠카 아미 저)를 읽고 감명을 많이 받았어요. 삐비도 해보고 싶다는 마음으로 해커스펍에 가입하게 되었습니당! 여태 바이브 코딩을 가챠 돌리는 느낌으로 해왔더니 한계가 많이 보이더라구영... 진심 어디서부터 시작해야할지 막막하지만, 100일동안 어떻게든 열심히 해보겠습니다...!!!!!!!!!!!

매일 최소 한 시간씩~! 바이브코딩 위주(할 줄 아는 게 이것뿐이라!)에 공부를 곁들이는 식으로~! 100일 챌린지 시작해보겠습니다!

問題としてソフトウェアがAGPLだと感染する (個人的にはプラグインが拡張するソフトウェアのコードを含まない限りコピーレフトの制約に縛られることを望んでいない)のでどうしようってなる

この場合はプラグインAPIの概念をコアに分離してKagura (Mastodon API, Admin UI等)自体をそれのプラグインとして実装するのが妥当なんだろうけど悩む

ただその場合はコアにapkit.serverを実装しないと結局ライセンスに縛られかねない (Mastodon APIの実装側をAGPLにする方針の場合)