아... 이제서야 집 도착... FediDev KR 파이콘 부스를 지켜주셨던 
@akastoot악하 
@z9mb1wwj 
@hongminhee洪 民憙 (Hong Minhee) 
@nebuletoHaze 등등등 고생 많으셨습니다...
bgl gwyng
@bgl@hackers.pub · 87 following · 107 followers
슈티를 함께 만들 팀을 만들고 있습니다. 관심 있으신 분, 또는 잘 모르겠지만 이야기를 나눠보고 싶은 분도 bgl@gwyng.com으로 편하게 연락주세요.
GitHub- @bglgwyng
shootee- www.shootee.io
If you find it unbearable to be around people with big egos, you might want to consider whether your own ego is the problem.
파이콘 한국 2025의 Hackers' Pub 및 FediDev KR 커뮤니티 부스가 성공적으로 마무리되었습니다. 모두 여러분 덕분입니다.
양일간 부스 지키느라 도와주신 분들께 모두 감사드립니다! @nebuletoHaze 
@kodingwarriorJaeyeol Lee @akastoot악하 @z9mb1wwj 
@gaebalgom개발곰 🙏🏼
개방형 오피스가 코딩의 생산성을 저하시키는 일종의 또 다른 ADHD 상태를 만든다는 글이 올라왔다. 이에 대해 어느 정도는 그럴 수 있지 하고 생각하면서도 많은 부분에 대해 동의하지 않는데... 사무실 내의 소리나 환경적 문제를 제외하면 Slack 등의 업무용 메신저나 메일 등의 알림은 집에서도 사무실에서도 똑같이 발생한다. 내가 업무 시간 중 일정 시간 안에 답하면 되는 것이기 때문에 알림 설정을 미리 해두지 않으면 결국 어디서 일하던간에 알림으로 인한 스트레스나 방해는 똑같이 받게 된다는 점이다. 또한 사무실 내의 다른 소리나 시각적 문제로 집중력을 떨어트릴 수 있다. 근데 이것도 잘 생각해보면 집에서도 가족이나 동거인, 키우는 동물 등이 있다면 똑같이 발생할 수 있는 문제가 아닐까.
결국은 어디에서 일하던간에 본인이 편안한 환경을 만들고 생산성을 유지하기 위한 환경을 조성하고 관리할 필요가 있다. 다만 이 글은 본인의 생산성을 환경에 따라 측정해서 자신만의 데이터를 뽑아낸게 굉장히 의미있다. 아마 제품의 홍보 목적도 겸하는 것이 되겠지만 말이다.
트리시터 grammar 처음 짜봤는데 생각보다 꽤나 쉽고 재밌었음! 다음엔 MDX 지원 만들어봐야지....
장안의 화제 〈파이썬토룡신점〉, 나도 쳐봤다!
해커스펍 500명 돌파 나이스~
bgl gwyng shared the below article:
파서 콤비네이터: 하스켈 초보자를 위한 파싱
박준규 @curry@hackers.pub
이 글은 하스켈 초보자를 위한 파서 컴비네이터에 대한 입문 튜토리얼입니다. 파싱은 프로그래밍에서 흔히 발생하는 작업이지만, 정규 표현식이나 문자열 조작만으로는 복잡한 형식을 다루기 어렵습니다. 저자는 `Text.ParserCombinators.ReadP` 라이브러리를 사용하여 파서 컴비네이터를 소개하고, 이를 통해 더 읽기 쉽고 유지보수가 용이한 파서를 작성할 수 있음을 보여줍니다. METAR 보고서 파싱 예제를 통해 `satisfy`, `many1`, `<|>`, `option` 등의 기본적인 파서 콤비네이터 함수를 설명하고, 펑터와 모나드의 개념을 활용하여 파서를 구성하는 방법을 안내합니다. 또한, 파싱된 데이터의 유효성을 검사하고, 결과를 더 의미 있는 데이터 타입으로 변환하는 방법을 제시합니다. 이 튜토리얼을 통해 독자는 파서 컴비네이터의 기본 원리를 이해하고, 실제 데이터 파싱 작업에 적용할 수 있는 능력을 얻게 됩니다. 마지막으로, 저자는 독자들에게 배운 내용을 바탕으로 전체 METAR 보고서를 파싱하는 라이브러리를 만들어 Hackage에 제출해 볼 것을 권장하며, 파서가 없는 데이터를 만났을 때 `ReadP`를 자신 있게 사용할 수 있기를 바랍니다.
Read more →내일 파이콘 현장 가서 명함 뿌릴거임 우하하하
이번에 Amazon SES 메일 발송 처리를 추가해야 해서, Upyo 를 써 볼 수 있는 좋은 기회가 왔습니다. (SMTP 연동이어도 써볼 생각이었지만...)
README.md 의 Caution 을 보니 조금은 조심스럽지만, 한번 써보겠습니다!
Caution
This project is in early development and subject to change without notice.
개인적인 소망으로 https://unstable.upyo.org/logo.svg 로고에 한글도 들어가면 더욱 더 이쁠 것 같습니다!
bgl gwyng shared the below article:
Rust 컴파일러 개발 관련 명령어 모음집
notJoon @joonnot@hackers.pub
이 글은 러스트 컴파일러에 기여할 때 자주 사용하는 명령어와 작업 흐름을 소개합니다. 기본적인 빌드 명령어부터 특정 컴포넌트만 빌드하는 방법, 테스트 실행 및 `--bless`, `--force-rerun` 플래그 활용법을 설명합니다. Stage 시스템(Stage 0, 1, 2)을 구분하여 각 Stage의 역할과 사용법을 안내하고, UI 테스트 작성 규칙과 에러 주석 문법을 상세히 다룹니다. 또한, 직접 컴파일러 실행, 디버그 어설션 활성화, 백트레이스 활성화 등 디버깅 명령어와 컴파일러 버그 수정 워크플로우를 예시와 함께 제시합니다. 마지막으로, 자주 발생하는 문제와 해결법, 빌드 시간 단축 방법, 디버깅용 환경 변수 설정까지 다루어 러스트 컴파일러 개발에 실질적인 도움을 제공합니다. 이 글을 통해 러스트 컴파일러 기여자들이 효율적으로 개발하고 디버깅하는 데 필요한 지식을 얻을 수 있습니다.
Read more →
LLM에게 코딩 시키기, 요즘 바이브 코딩이라 불리는 일을 해 봤다. 동기는, 리니어 공간에서의 이미지 리사이즈 작업이 ImageMagick 같은 전문? 툴 없이 파이썬 라이브러리로만으로 가능한가? 라는 호기심.
의외로, 알려진 알고리즘을 적용하라는 지시에는 LLM이 매우 효과적으로 대응했다. 정형화되어 있는 작업은 그게 조금? 전문적이라고 해도 찰떡 같이 알아듣고 탬플릿처럼 코드를 만들어냈다. 거대 LLM은 지식의 범위가 매우 넓다고 절감했다.
오히려 문제는 쉽다고 예측했던 색영역 프로필 처리에서 일어났다. 존재하지 않는 메소드들을 계속 있다고 하며 라이브러리 버전 문제라고 우겼다. 제미나이도, chatgpt도 동일했다. 해당 라이브러리 문서를 직접 찾아보니, LLM들이 가져온 오브젝트는 유저에게 노출되지 않은 내부 C 코드에 있는 것들이었다.; 오브젝트는 내부를, 메소드는 문서화 되어 있는 API의 것을 조합해서 코드를 만들어 낸 것이었다.
인간 개발자는, 자기 전문 영역이 아닌 한 라이브러리의 내부 코드까지는 잘 보지 않는다. 즉 API 문서를 기반으로 작업을 해 나간다. LLM은 정반대였다. 오픈소스 라이브러리라면, 오히려 문서보다도 외부 문서화되지 않은 소스 코드가 더 잘 학습 되는 자료였던 것이다. 그 과정에서 라이브러리의 전체 동작 과정을 잘 파악할 정도는 아니었기에 동작하지 않는 코드들을 계속 만들어 냈고.
매우 흥미로운 경험이었다. LLM은 인간과는 전혀 다른 학습, 구성 과정을 통해 코딩한다. 요구-설계-개념-문서-코드 라는 단계는 LLM에게는 의미가 없다. 프로그래머들은 이제 이세돌 이후 바둑 기사들이 겪었던 충격과 비슷한 변화를 나름? 받게 된 듯 하다.
드디어 Claude Code를 굴리고 손을 좀 많이 봐서(...) Solid Relay 문서를 좀 볼만하게 적어보았다
근데 내용 검수 제대로 안 한 부분도 있는데 대충 잘 되었겠거니 하고 있다....... 😇
오픈소스 처음 했을 때는 문서 기여를 해도 되는건지 긴가민가 했었는데, 시간이 지나서 생각해보니
- 방심하면 순식간에 outdated 됨
- 아무튼 결국 누군가는 해야 함
같은 이유 때문에 아주 중요한 기여인거 같음
드디어 Claude Code를 굴리고 손을 좀 많이 봐서(...) Solid Relay 문서를 좀 볼만하게 적어보았다
근데 내용 검수 제대로 안 한 부분도 있는데 대충 잘 되었겠거니 하고 있다....... 😇
이제 VitePress로 문서를 뽑아볼까...
그동안 Conal이란걸 만들고 있었습니다. Classic FRP 라이브러리입니다.
또, 소개글 쓰려니까 머리 아파서, 클로드랑 즉석 팟캐스트를 열었습니다. 술술 읽혔으면 좋겠네요.
당장 프로덕션에 쓰려면 개선할 부분이 많습니다. 피드백과 기여 환영합니다.
그동안 Conal이란걸 만들고 있었습니다. Classic FRP 라이브러리입니다.
또, 소개글 쓰려니까 머리 아파서, 클로드랑 즉석 팟캐스트를 열었습니다. 술술 읽혔으면 좋겠네요.
당장 프로덕션에 쓰려면 개선할 부분이 많습니다. 피드백과 기여 환영합니다.
Zig의 좋은 아이디어라고 생각하는 것 중 하나: 여러줄 문자열을 나타낼 때 앞에 \\를 붙여서 표현한다. Rust나 JS에선 여러줄 문자열에 들여쓰기를 해버리면 그 공백문자가 그대로 들어가버리지만 Zig는 그런 문제를 피하게끔 설계했다.
Zig’s Lovely Syntax - https://matklad.github.io/2025/08/09/zigs-lovely-syntax.html
매일마다 튜사(
@TuringAppleDev튜링의 사과 )로 출퇴근하는 사람으로서 혼밥하기 좋은 맛집 아카이브 중...... 태국음식점 마하차이 팟타이 괜찮군
기승전 해커스펍 홍보 끝~
‘앞/전’과 ‘뒤/후’의 비대칭성은 한국어 학습자들에게 지옥을 선사할 것이다.
참고로 이거 다 국립국어원의 잘못이 아니라 한국어의 잘못임. 이건 표준국어대사전이 그냥 현실을 반영했을 뿐이다. 즉 이 글을 읽고 있는 당신도 0.000001% 정도 잘못이 있다.
- ‘앞일’은 미래인데(예: 앞일을 예측하다), ‘뒷일’도 미래다(예: 뒷일을 부탁하네). 맞죠?
- 마찬가지로, ‘앞길’은 미래다(예: 앞길이 창창한 젊은이). 그런데 ‘뒷길’도 미래다(예: 자식의 뒷길을 생각하면 걱정이 앞선다).
- ‘뒷날’도 미래고(예: 우리는 뒷날 또 만나게 되었다), ‘훗날’도 미래다(예: 훗날을 기약하다). 그런데 ‘앞날’도 미래다(예: 앞날이 창창하다). 희한하게 ‘전날’만 과거이다.
- 그런데 ‘앞날’은 간혹 과거를 가리킬 수도 있다(예: 일찍이 앞날의 폭군은 있었고…).
- 관형사형에 ‘뒤’나 ‘후’를 붙여서 시점을 나타낼 수 있다(예: “고친 뒤의 모습” 또는 “고친 후의 모습”). 그런데 반대로 하려면 관형사형이 아니라 명사형을 써야 한다(예: “고치기 전의 모습”). 그리고, ‘전’만 쓸 수 있다. ‘앞’은 여기서 아예 쓸 수 없다.
- ‘후일’은 미래의 아무 날이나 다 가리키며, 특정한 날을 가리킬 수 없다. 반면 ‘전일’은 직전, 즉 인접한 과거의 1일만 가리킨다.
- 그런데 또 ‘전날’은 인접한 과거의 1일을 가리킬 수도 있고, 과거의 아무 날을 가리킬 수도 있다.
- 그런데 또 ‘훗날’은 미래의 아무 날을 뜻하며, 인접한 미래의 1일을 가리킬 수 없다.
- ‘전년’과 ‘후년’은 각각 과거의 아무 해, 또는 미래의 아무 해를 가리킬 수 있다. 대, 대칭인가?!
- 하지만 특정한 해를 가리키는 경우, ‘전년’은 인접한 과거의 해를 가리킨다. 반면 ‘후년’은 ‘올해의 다음다음 해’이다.
- …뭐라고? 왜냐하면 미래의 해들은 순서대로 ‘내년’-‘후년’-‘내후년’이기 때문이다. 책상 엎어버리고 싶죠?
- 참고로 ‘내후년’은 동음이의어이다. 올해가 2025년이라면 내후년은 2027년을 가리킬 수도 있고 2028년을 가리킬 수도 있다. (이게 언어냐?)
- ‘후년’이 ‘올해의 다음다음 해’가 되는 이 원리는 오직 ‘년’에만 적용된다. 예를 들어 ‘후일’, ‘후주’, ‘후월’ 등에는 그런 의미가 없다.
- ‘후일’은 미래의 아무 날이다. 하지만 ‘후주’와 ‘후월’은 인접한 미래의 것 하나만 가리킨다.
- ‘전년’은 인접한 과거의 해이지만, 과거의 모든 해를 다 가리킬 수도 있다(예: 우리는 전년의 기록들을 검토하여 그 사람의 행적을 조사해 보기로 했다).
- 반면 ‘전일’, ‘전주’, ‘전월’은 오직 인접한 과거의 하나만 가리킬 수 있다.
- ‘전달’과 ‘훗달’도 비대칭이다.
도대체 이걸 어떻게 배워서 쓰라는 것인지. 생각해 보면 나도 실제로 이렇게 쓰고 있다는 것도 기가 찬다.
그밖에:
- ‘지난날’에는 특정한 날을 가리키는 뜻이 전혀 없다. 반면 ‘지난주’, ‘지난달’, ‘지난해’는 모두 과거의 인접한 하나만 가리킨다.
- ‘다음 날’과 ‘다음날’은 의미가 완전히 다르다. ‘다음날’은 ‘정하여지지 아니한 미래의 어떤 날’이다. 따라서 인접한 미래의 1일을 가리킬 때에는 ‘다음 날’만 쓸 수 있다. (도저히 못 외우시겠으면 그냥 ‘이튿날’로 피신하시라…)
OSTEP 공부하는 타래
이번에 FFmpeg의 어셈블리 학습 자료를 번역 중인데 이제 1강 끝냈다. 마음 같아선 인공지능에 모든걸 맡기고 싶지만 번역된 문장이 너무 어색해서 쓸 수가 없었음. https://github.com/FFmpeg/asm-lessons/pull/24
I just sponsored dahlia. Go sponsor your open source dependencies! https://github.com/sponsors/dahlia?o=sp&sc=t&sp=limeburst
이번에 다익스트라보다 빠른 최단 경로 알고리즘이 나왔다고 해서 논문을 읽어봤는데 역시 어려워서 나가떨어졌다 arxiv.org/abs/2504.17033
Breaking the Sorting Barrier f...
요즘 아이디어를 긴 글로 옮기는게 힘들다. AI와 비교해 최대 10토큰/분이란 저열한 속도에 자괴감이 들고, 그렇다고 AI랑 같이 쓰자니 이것도 합을 맞춰서 같이 쓰는게 어렵단 말이지. 그래서 시도해보려는 방법은 AI한테 인터뷰어 역할을 맡기고 내가 인터뷰이가 되는거다. 주제만 내가 정해주고 세부 사항에 대한 비판이나 질문은 AI한테 맡긴다. 그리고 대화가 끝나고 스크립트를 그대로 공유한다.
정보 리터러시 관련 의견을 보존하러 왔다. 우리는 흔히 영어 자료가 한국어 자료보다 낫다는 문화사대주의적 의견에 공감하곤 한다. 하지만 여기엔 숨은 의견이 여럿 있다. 하나씩 까보며 음미해보자.
영어 자료는 한국어 자료보다 낫다. => 왜 나을까? 도움이 되기 때문에. 왜 도움이 될까? => (진실에 가깝기 때문에, 다양한 경험이 전시되어 있기 때문에). 왜 진실에 가까울까? => 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:
readme: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냐고해서 맞다고 했는데 좀 자존심 상한다...