Profile img

구슬아이스크림

@icecream_mable@hackers.pub · 45 following · 31 followers

인간의 언어처리와 LLM의 언어처리를 서로 비교하는 전산심리언어학(Computational Psycholinguistics)을 연구했'었'습니다.

하지만 CS덕질이 더 재밌다는 걸 깨닫고선 대학원을 탈출했습니다.

요즘은 데이터 엔지니어링과 컴파일러가 재밌어요.

Github
@kihyo-park
Blog
kihyo-park.github.io
Linkedin
kihyo-park
0

구슬아이스크림 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 →
12

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

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

6
4

구슬아이스크림 shared the below article:

2025 Q2/Q3 Review

Jaeyeol Lee @kodingwarrior@hackers.pub

이 글은 2025년 2분기 결산을 미루고 3분기에 몰아 작성한 개발자의 회고록입니다. 4월부터 9월까지 2~4주 단위로 굵직한 이벤트들이 연이어 발생하며 '업보 청산'의 시간을 보냈다고 합니다. 임금 미지급, 파이콘 발표 준비, Fedify 프로젝트 참여, UbuCon Korea 발표, PyCon KR 참여, Hackers' Public 주최, PyCon JP 참여 등 다사다난했던 3분기를 요약하고 있습니다. 특히 Fedify 프로젝트에 기여하며 NestJS 기반의 연합우주 소프트웨어 개발에 집중하고, Hackers' Public 밋업을 성공적으로 개최한 경험을 강조합니다. 현재는 수입이 거의 없는 상태이지만, 취업 준비와 외주를 병행하며 바쁘게 지내고 있습니다. Node.js 백엔드 엔지니어 또는 풀스택 엔지니어로서의 취업을 목표로 하고 있으며, 기술 면접 준비와 함께 OS 및 네트워크 관련 지식을 쌓고 있습니다. 마지막으로, 4분기에는 현재 진행 중인 프로젝트를 마무리하고 크리스마스 이전에 취업하는 것을 목표로 하고 있습니다.

Read more →
19

구슬아이스크림 shared the below article:

Optique 0.5.0: Enhanced error handling and message customization

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

Optique 0.5.0 is now available, bringing enhancements to error handling, help text generation, and overall developer experience while maintaining full backward compatibility. The update introduces better code organization by refactoring the large `@optique/core/parser` module into three focused modules: `@optique/core/primitives`, `@optique/core/modifiers`, and `@optique/core/constructs`. Error handling is improved with automatic conversion of default value callback errors into parser-level errors, and the new `WithDefaultError` class allows for structured error messages. Customization of default values in help text is now possible via an optional third parameter to `withDefault()`, enabling descriptive text instead of actual values. Additionally, the release provides comprehensive error message customization across all parser types and combinators, allowing context-specific feedback. These improvements aim to make Optique more user-friendly, especially for building CLI applications that require clear error messages and helpful documentation, making this release a significant step forward for developers using Optique.

Read more →
5
2

구슬아이스크림 shared the below article:

[잘라먹는 프로그래밍 언어론] 타입 체계는 명제 논리와 닮아있다 (커리-하워드 대응)

RanolP @ranolp@hackers.pub

이 글은 함수 타입, 합 타입, 곱 타입과 논리 연산의 대응 관계를 탐구하며, 특히 부정(negation)을 타입 시스템에서 어떻게 표현할 수 있는지에 대해 설명합니다. "P가 아니다"는 "P이면 거짓이다"와 동치라는 점을 이용하여, 타입 이론에서 값이 없음을 거짓으로 해석하고, 이를 통해 "정수를 0으로 나눌 수 없다"는 명제를 타입으로 표현하는 방법을 제시합니다. `div_by_zero :: Int -> ⊥`와 같은 표현을 통해 타입 체계와 명제 논리 간의 커리-하워드 대응을 보여주며, 타입 시스템이 논리적 추론과 어떻게 연결되는지에 대한 통찰력을 제공합니다.

Read more →
10

구슬아이스크림 shared the below article:

NestJS로 풀어보는 SOLID 원칙

Jaeyeol Lee @kodingwarrior@hackers.pub

이 글은 NestJS를 사용하면서 마주할 수 있는 소프트웨어 설계의 복잡성을 SOLID 원칙을 통해 해결하고자 한다. SOLID 원칙은 단일 책임 원칙(SRP), 개방-폐쇄 원칙(OCP), 리스코프 치환 원칙(LSP), 인터페이스 분리 원칙(ISP), 의존 역전 원칙(DIP)으로 구성되어 있으며, NestJS의 Controller, Service, Repository 구조를 통해 SRP를 실현하고, Interceptor를 통해 OCP를, 인터페이스를 통한 LSP, Guard, Pipe 등을 통해 ISP를, DI 컨테이너를 통해 DIP를 구현하는 방법을 설명한다. 각 원칙 위반 사례와 개선 사례를 비교하여 코드의 응집도, 유지보수성, 확장성, 유연성을 높이는 방법을 제시하며, 다이어그램을 통해 각 원칙이 적용된 코드 구조를 시각적으로 보여준다. 이 글을 통해 독자는 NestJS를 사용한 개발에서 SOLID 원칙을 적용하여 더 나은 소프트웨어 설계를 할 수 있을 것이다.

Read more →
4

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

9
4

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

6

「Fedify Studio」(仮称)というウェブベースのActivityPubデバッグ・開発ツールを作ろうかと考えています。fedify inboxコマンドやActivityPub.Academyの強化版みたいなもので、アクティビティのテスト、アクターの検査、フェデレーションの問題調査などがちゃんとしたUIでできるイメージです。ActivityPub開発者の皆さんにとって需要ありそうでしょうか?

假稱(가칭) 「Fedify Studio」라는 웹 基盤(기반)의 ActivityPub 디버깅 및 開發(개발) 道具(도구)를 만들어 볼까 생각 ()입니다. fedify inbox 커맨드나 ActivityPub.Academy의 強化版(강화판) 같은 것으로, 액티비티 테스트, 액터 인스펙터, 聯合(연합) 이슈 디버거 ()을 제대로 된 UI로 提供(제공)하는 느낌인데요. ActivityPub 開發者(개발자) 분들께 需要(수요)가 좀 있으려나요?

4

구슬아이스크림 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 →
32
0
1

이제 자신이 보여주고 싶지 않은 추천사를 가리는 기능도 추가되었습니다. 메인 페이지에서 링크 타고가시면 사용 가능해요. 많은 이용 부탁드립니다.

https://referral.akaiaoon.dev/ 이 링크에서 사용 가능하고, 내가 받은 추천사는 https://referral.akaiaoon.dev/u/:username 으로 볼 수 있습니다. 아래 말코링님의 추천사 리스트를 참조해 주세요.

말코링님의 추천사

레퍼럴프로젝트의 새로운 기능 - 추천사 가리기
8

"두통과 함께하는 사람들"은 다음 주(22일 ~ 28일) 편두통 인식 개선 주간을 맞이해서 광화문에서 커피차 이벤트를 진행합니다! 주변에 많은 공유와 참여 부탁드려요.

  • 📆 언제? 2025년 9월 22일 (월요일) 오전 10시 ~ 오후 2시
  • 📍 어디서? 광화문 한국프레스센터 광장 [네이버 지도]
  • 📋 무엇을 하나요? 편두통 질환과 캠페인을 소개하며 다양한 기념품(안대와 귀마개 등)과 음료를 드립니다! 🎁🥤
  • 왜 하나요? 국제적으로 진행하는 캠페인의 일환으로 편두통에 대한 오해를 해소하고 편두통을 알리는걸 목표로 합니다.

오랫동안 열심히 준비하던 것 중 하나입니다. 부스 놀러와주시면 기쁠 것 같아요.

편두통, 오해말고 이해를! 당일 배포될 팜플렛의 표지입니다.
6
0
0

이제 자바 메인을 이렇게 써도 된다니 놀랍군요

void main() {  
    var name = IO.readln("What is your name? ");  
    IO.println("Hello, " + name);  
}  
5
5

이 분의 유명한 강연이.... 요거 https://youtu.be/30YWsGDr8mA?si=yMtG1rulnISpLL0Z 인데

내용을 적당히 추리자면


복잡하거나 난해하거나 어려운 것들을 단순한 것으로 만들기 위해서

  1. 난해한 것들을 단순하게 만들어주는 훌륭한 도구를 사용하거나
  2. 찾는데서 삽질하는 빈도를 줄이기위해 좋은 레퍼런스를 확보하거나
  3. 시간순으로 설명하거나
  4. 가려져있는 것들을 가시화할 것을 권장

어떤 것에 대해 질문을 올리면 Read The Fucking Manual 라는 질타를 받거나, 복잡하거나 어렵지만 다들 접하는 이슈이기 때문에 당연히 알아야 하는 것처럼 느껴지지만 그것이 자신만의 문제는 아니라고 결론냄.

복잡하고 어려운 코드들은 이유가 있으며, 그 배경에는 온갖 예외처리라던가 다양한 요구사항을 충족하다보니 생겨난 방대한 코드라던가 블랙박스 그 자체인 시스템들이 있기 때문에 잘 모르는 것도 이상한 것이 아니라고 강조

3

"듀오링고는 이 모델을 “작은 형태의 부의 재분배”라고 설명합니다. 미국, 유럽, 한국과 같은 부유한 국가의 유료 구독자들이 지불하는 수익을 통해 브라질, 베트남, 과테말라와 같은 빈곤한 국가의 사람들이 무료로 양질의 교육을 받을 수 있도록 하기 때문입니다. 이는 듀오링고가 단순히 수익을 추구하는 기업이 아니라, 핵심 사명과 비즈니스 모델을 일치시켜 사회적 가치를 창출하고 있음을 보여줍니다." https://yozm.wishket.com/magazine/detail/3351/

1
3

DDIA (Designing Data Intensive Application) 2판을 읽고 있다.

처음 빌딩블록 얘기부터 정리를 잘해주는듯..

DB: 데이터를 저장하여, 자신 또는 다른 애플리케이션이 나중에 다시 찾을 수 있도록 한다 (데이터베이스)

Cache: 비싼 연산의 결과를 기억하여 읽기 속도를 높입니다 (캐시)

Index: 사용자가 키워드로 데이터를 검색하거나 다양한 방법으로 필터링할 수 있도록 허용합니다 (검색 인덱스)

Stream: 이벤트와 데이터 변경이 발생하는 즉시 처리합니다 (스트림 처리)

Batch: 주기적으로 축적된 많은 데이터를 분석합니다 (배치 처리)

4

살짝 다른 차원에서 확장해서 바라보는 얘기이긴 한데 그냥 첨언하자면 언어학의 하위 분야인 화용론에서 전제(Presuppositions)라는 주제랑 연결되는 것 같네요. 댓글에 프랑스 왕은 머머리다 예문도 써주신 걸 보니 더욱 더 그런 것 같고요. 간단하게 설명드리자면, 일단 한국어 예문으로 하면 살짝 오해의 소지가 있어[1] 영어 예문을 갖고 쓰면 다음과 같이 생각해볼 수 있습니다.

  • P: The King of France is bald.[2]
  • Q: There exists an entity that is King of France.

이 때 P의 명제가 참일 수 있는 이유는 Q를 전제로 깔고 가기 때문입니다. 이렇게 Q를 전제로 갖고 가면 P에 부정을 넣어도 (The King of France is not bald 혹은 ¬(The King of France is bald)) 여전히 그 명제는 참입니다. 하지만 실제 현실에서 Q는 거짓입니다. 왜냐하면 오늘날 프랑스는 군주국가가 아니니깐요. 그럼에도 불구하고 P는 여전히 참을 진리값으로 가지죠.

따라서 실제로 전제를 이렇게 정의하기도 합니다 (Levinson, 1983, p. 175).

  • A sentence P sematically presupposes a sentence Q iff:
  • (a) P ⊨ Q
  • (b) ~P ⊨ Q

참고로 여기서 "⊨"는 "함의한다"를 지칭하는 기호입니다 (예: "하스켈은 함수형 언어다."란 문장은 "하스켈은 언어다"란 걸 함의하죠.).

그렇다면 Q가 전제되는 건 알겠는데, 이 진리값이 무엇이느냐에 대한 질문이 생길 수 있습니다. 이에 대해서 언어학자들은 보통 크게 두 가지로 봅니다. 하나는 참으로 간주하는 거고, 다른 하나는 참도 거짓도 아니다라고 보는 거죠. 전자같은 경우엔 어떻게 보면 기계적으로 바라보는 거고, 후자의 경우엔 참/거짓이라는 기존 이치논리(two-valued logic) 혹은 1 또는 0으로 하는 불 논리에서 확장해서 Kleene의 삼치논리(three-valued logic)로 가게 되죠.

참고로 전제 성립 여부 포함 화용론 전체에서 깔고 가는 가장 큰 가정이 하나 있는데, 이 경우에는 바로 해당 발화(utterance) P, 즉 '프랑스왕은 머머리다'라는 명제가 이루어질 때 화자와 청자가 프랑스에는 왕이란 개체가 존재한다(=Q)라고 암묵적으로 서로 동의한다라는 가정입니다.


  1. 사실 문제가 영어 관사 'The'에서 시작되기 때문이라서 그렇습니다. ↩︎

  2. 논리형으로 치환하면 다음과 같습니다: ∃x(KoF(x) & ∀y(KoF(y) → y=x) & Bald(x)) where KoF stands for "King of France". ↩︎

@icecream_mable구슬아이스크림 언어학과 논리학에서 "전제"로 번역되는 단어가 다르다는 걸 오늘 알았네요. 논리학에서는 premise가 전제고, presupposition은 그와는 별개의 것인데 (번역이 따로 있는지는 모르겠습니다만) 언어학에서는 presupposition을 "전제"로 번역하는군요.

본문으로 돌아가서, 제시하신 문장에서 핵심은 주석에서 언급하셨듯 "the"의 사용에 있겠죠. 영어에서 "the"는 청자와 화자가 암묵적으로 동의할법한 후술하는 대상을 얘기하니까요. 대상을 나타내는 메타 변수 x에 대해 "the" x라는 표현의 presupposition이 existence of x이겠습니다. 억지로 번역해본다면 "그 프랑스 왕은 대머리다"라고 했을 때 청자와 화자가 공통적인 (잘못됐을 수도 있는) 인식인 "프랑스 왕이 (그곳에) 존재한다"를 공유하고 있다고 할 수 있겠습니다.

3
2

네이티브 니홍고 스피커 부러운점: 다국어 지원하는 '씹덕'겜을 할때 타 언어로 바꾸는 걸 대부분 고려에도 안 올릴 정도로 '언어적씹덕정체성'이 높은 점

딴 언어 원어민들에게 "내 모국어는 모에하지 않아"라는 감상이 드물지 않게 나올 때 일본어쟁이들이 "일본어는 모에하지 않아"라곤 하지 않으니까

이게 왜 부럽냐면
지금이야 더빙까가 옛날에 비해 기승을 부리지 않지만(근데 이것도 씹덕 사이에서나지 비-씹덕 킹반인들에게는 아직 입지가 부족한 거 같고)
옛날엔 정말 "한국어는 모에하지 않다"라는 이유로 까는 더빙까가 많았기에…

0

오는 11월 8일 토요일 오전 10시, 광운대학교에서 열리는 FOSS for All 컨퍼런스에 여러분을 초대합니다.

FOSS for All 컨퍼런스는 "Free and Open Source Software for All"이라는 슬로건 아래, 모두를 위한 오픈 소스 컨퍼런스를 목표로 하는 비영리 오픈소스 커뮤니티 주도의 컨퍼런스입니다.

FOSS for All 컨퍼런스는 오픈소스 소프트웨어와 커뮤니티에 관심 있는 누구나 참여할 수 있으며, 개발자, 기여자, 디자이너, 번역가, 기획자 등 다양한 역할의 사람들이 경험과 지식을 공유하는 장으로 기술 발표, 커뮤니티 부스, 패널 토크 등 다양한 프로그램이 마련될 예정입니다.

많은 후원과 참여를 부탁드리겠습니다. 고맙습니다. :-D

https://event-us.kr/fossforall/event/110400

3
17
0
0

나루 UI를 전면적으로 개편했습니다. 먼저 메인 화면에 오이카페타이포 블루의 광고를 넣었고요 (...) 파일 탐색기와 에디터를 좀 더 사용하기 편하게 개선했습니다. 또, 어떤 이유로든 나루를 떠나 다른 곳에서 사이버 보금자리를 차리고 싶은 분들을 위해 나루 갠홈 다운로드 기능을 추가했습니다. 앞으로도 잘 부탁드립니다!

광고가 삽입된 나루 홈페이지 스크린샷새로워진 나루의 파일 탐색기 스크린샷갠홈 다운로드 버튼 스크린샷
8
0
0

PgEdge가 오픈 소스로 전환됨
------------------------------
- 분산 PostgreSQL 전문 기업
pgEdge 가 핵심 컴포넌트를 기존의 소스 공개 방식에서 *오픈 소스 라이선스* 로 전환
- 기존에는 Spock, Snowflake, Lolor 같은 주요 엔진과 확장 기능이
pgEdge Community License 로 제공되어 사용에 제약이 있었음
- 이번에 모든 핵심 저장소를
PostgreSQL License 로 재…
------------------------------
https://news.hada.io/topic?id=23050&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

0

Finally, embrace provisional trust. The wizard model means working with “good enough” more often, not because we're lowering standards, but because perfect verification is becoming impossible. The question isn't “Is this completely correct?” but “Is this useful enough for this purpose?”

https://www.oneusefulthing.org/p/on-working-with-wizards

마지막으로, 잠정적 신뢰를 받아들이세요. 마법사 모델은 ‘충분히 좋은’ 상태로 더 자주 작업하는 것을 의미합니다. 기준을 낮추기 때문이 아니라 완벽한 검증이 불가능해지고 있기 때문입니다. 핵심 질문은 “이것이 완전히 정확한가?”가 아니라 “이것이 이 목적에 충분히 유용한가?”입니다.

— 위 인용을 DeepL로 번역

전적으로 동의하고 애자일 관점에서도 좋은 방향이라고 생각하지만, 완벽주의적인 성향이 있는 사람으로서 무시하기 어려운 심리적 저항이 꽤 자주 발생하곤 한다. 에이전트를 위한 지침을 자세히 적는 것으로 최대한 타협할 수 있을 것 같은데 아직 맘에 쏙 드는 방법을 발견하지는 못함.

1

오래 전

현대 컴퓨터는 계산기라기보다는 복사 기계에 더 가깝다

는 문장을 읽었고 그것에 대해 종종 생각함. 생각해 보면 정말 하는 일이 대개 그런 것에 속한다고 느낌. 어딘가에 있다는 데이터를 모으고 가공하고 정제해서 또 어딘가에 두고 그걸 누군가 가져갈 수 있게 하는 일 끊임 없이 반복함. 데이터의 형식이나 크기나 여러 속성이 다양하고 그래서 다루는 방법과 기술에도 많은 차이가 있지만 어쨌든. 요즘 종종 인용되는 타입 검사는 해결책이 아니라 증상이다(Type Checking is a Symptom, Not a Solution)에 대한 반응들을 보고 직렬화 글과 거기 인용된 인터넷은 디버깅 모드로 돌아가고 있다는 글까지 떠올랐음.

(이 글은 Hackers' Pub에서 제공하는 Markdown 문법 가이드에 익숙해지기 위한 시도로 작성함.)

5

Perl을 만든 언어학자 Larry Wall이 쓴 글 중에 종종 다시 읽어 보는 글

Human languages therefore differ not so much in what you can say but in what you must say. In English, you are forced to differentiate singular from plural. In Japanese, you don’t have to distinguish singular from plural, but you do have to pick a specific level of politeness, taking into account not only your degree of respect for the person you’re talking to, but also your degree of respect for the person or thing you’re talking about.

Programming is Hard, Let's Go Scripting...

그렇기 때문에 사람의 언어는 당신이 그렇다고 생각하고 있던 것과는 많이 다르다. 영어로 얘기할때는 단수와 복수를 확실히 구분해야만 한다. 일본어에서는, 단수와 복수를 구분할 필요는 없지만, 정중함의 정도를 조절할 줄 알아야 한다. 즉, 상대방에 대한 존경을 표현할 수 있는 정도를 선택해야 하고, 상대방의 입장에서 내가 존중 받아야 하는 정도를 생각해서 말해야 한다.

프로그래밍은 어렵다, 스크립팅의 세계로 가보자...

9

LWN.net의 What every programmer should know about memory 시리즈를 훑어 보고 나서 든 생각인데, 현대적인 컴퓨터의 메모리 모델이란 건 사용성 관점에서는 놀라울 정도로 투명하게 추상화되어 있으면서 동시에 성능 관점에서는 무시무시할 정도로 새는 부분이 많은 추상화인 것 같다.

인상깊었던 부분 중 하나는, 코드를 실행해 보기 전에는 완벽한 최적화가 사실상 불가능한 메모리 접근 패턴이 드물지 않게 발생할 수 있다는 건데, 이런 부분 때문에 JIT 컴파일러가 AOT 컴파일보다 잠재적으로 더 우수한 성능을 낼 수 있다는 주장이 있었던 걸까 싶다.

6
3
0
0

지금 리눅스 진영에서 컨테이너/네임스페이스의 입지가 어떻게 될까요? 사실 요즘 서비스 배포할때는 죄다 컨테이너 쓰잖아요? 근데 또 컨테이너로 할수 있는 것중 상당수는 그냥 기존 권한 관리로도 가능하단 말이죠? 근데 컨테이너를 쓸땐 기존 권한 관리를 그냥 없는셈 치고 접근하게 되는데 이게 정말로 다들 동의하는 방식인지가 궁금합니다.

3
6

最近(최근) 한창 開發中(개발중)인 Fedify 基盤(기반) ActivityPub 서비스 2():

完全(완전) 期待中(기대중)!!

6