블로깅의 쇠퇴, AI의 끝없는 학습, 비공개 플랫폼(Discord 등)으로의 이주, 짧고 중독성만을 강조하는 피드와 BM, 한 번 보면 다시 찾기도 힘든 SNS 포스트, 범람하는 가짜뉴스와 개소리와 혐오... 웹은 정보의 망망대해도 아닌 소행성대로 변해가고 있다.
이찬행
@2chanhaeng@hackers.pub · 30 following · 33 followers
(일단 벌려놓고 생각해보기)
@kodingwarriorJaeyeol Lee 아닠ㅋㅋ 이거 민희님 컨펌 받은건가요ㅋㅋㅋ
@kodingwarriorJaeyeol Lee (a.k.a. kodingwarrior) 
챗GPT 에게 이 영광을 돌리겠습니다
15개의 다른 헛소리를 제외한다면요
Hackers’ Public 어때요
해커스펍 오프라인 모임 겸? 프로모션 행사가 9월 14일로 픽스된 상황인데, 공지하기전에 모임의 공식 이름을 어떻게 지을지가 고민임.
큰 틀에서 보면 뉴욕에 거점을 두고 있는 NYC Systems(https://nycsystems.xyz/2024.html) 에서 모임여는 방식 따라갈 것 같음.
---
**해커스펍 모임** 이라고 하기엔 해커스펍이 너무 한국에 국한된 느낌(어차피 당장은 한국어권 사용자의 모임이긴 하지만). 지역에 기반한 커뮤니티라는 느낌으로 스코프를 좁힘.
당근마켓을 중심으로 루비개발자 모임을 서초에서 모인다고 해서 seocho.rb 라는 이름의 밋업이 열리곤 했었는데, 이걸 참고삼았던게 두번째 스텝.
높은 확률로 성수에서 모일 것 같으니까 Hackers' Pub @ 성수 라고 짓자니... 장소대관 문제로 강남에서 열 수도 있지 않나 싶은 생각이 먼저 들어서 좀 더 범위를 넓혀서 Hackers' Pub @ Seoul <- 이 쯤에 도달했는데 더 좋은 이름 있으려나
@hongminhee洪 民憙 (Hong Minhee) 들고다니기가 번거로워서 그냥 두고 쓸까 생각 중이에요
@hongminhee洪 民憙 (Hong Minhee) 리모트 나쁘지 않아요
확실히 any를 방치하면 순식간에 코드베이스 전체로 번져나간다
@kodingwarriorJaeyeol Lee (a.k.a. kodingwarrior) 패키지 꼬여서 그런 것 같아요ㅠ 맨날 쓰던 것만 쓰다보니...ㅠㅠ
@kodingwarriorJaeyeol Lee (a.k.a. kodingwarrior) 그런건 따로 없어서 안 했어요 그냥 망함ㅋㅋㅋ...ㅠㅠ
돌겟네 과제 제출 40분 남았는데 서버가 실행이 안 됨
글 좀 올려주세요
오늘 파이콘에서 모니터에서만 보던 네임드 개발자 분들을 많이 발견하였다. 조용히 아 저분이 그분이군 하고 지나갔다.
오늘도 PyCon KR 해커스펍 부스 정상 영업합니다~
조만간 Hackers' Pub 티셔츠를 제작하려고 합니다. 가격이 얼마가 될 지는 모르겠는데 마플 기준으로는 1만원–2만원 사이 정도 될 것 같군요. 관심 있으신 분 계신가요?
@hongminhee洪 民憙 (Hong Minhee) XXL 하나 예약 부탁드립니다🙏
개방형 오피스가 코딩의 생산성을 저하시키는 일종의 또 다른 ADHD 상태를 만든다는 글이 올라왔다. 이에 대해 어느 정도는 그럴 수 있지 하고 생각하면서도 많은 부분에 대해 동의하지 않는데... 사무실 내의 소리나 환경적 문제를 제외하면 Slack 등의 업무용 메신저나 메일 등의 알림은 집에서도 사무실에서도 똑같이 발생한다. 내가 업무 시간 중 일정 시간 안에 답하면 되는 것이기 때문에 알림 설정을 미리 해두지 않으면 결국 어디서 일하던간에 알림으로 인한 스트레스나 방해는 똑같이 받게 된다는 점이다. 또한 사무실 내의 다른 소리나 시각적 문제로 집중력을 떨어트릴 수 있다. 근데 이것도 잘 생각해보면 집에서도 가족이나 동거인, 키우는 동물 등이 있다면 똑같이 발생할 수 있는 문제가 아닐까.
결국은 어디에서 일하던간에 본인이 편안한 환경을 만들고 생산성을 유지하기 위한 환경을 조성하고 관리할 필요가 있다. 다만 이 글은 본인의 생산성을 환경에 따라 측정해서 자신만의 데이터를 뽑아낸게 굉장히 의미있다. 아마 제품의 홍보 목적도 겸하는 것이 되겠지만 말이다.
파이콘 양일 출석하니 어제는 강연하시던 분이 오늘 오니 스태프 하고 계심 진짜 동네잔치...ㅋㅋㅋㅋ
어제 튜링의 사과에서 @hongminhee洪 民憙 (Hong Minhee) 님과 모각코 하며 건진 것:
- Zed 에디터
- Zed + Rust 디버거
- Zed + GitHub Copilot
제드만세
파이썬 로고 잘 조절하면 태극 문양처럼 만들 수 있을 것 같은데 이걸로 PyCon Kr 로고를 만들면 어떨까
개발자 굿즈 교류회 잘 다녀왔습니다~
발표자를 위한 교훈 하나: 프리젠테이션에 코드 예제를 보여줄 땐 좀 과하다 싶을 정도로 간단하게 한다. 안 그러면 발표 환경/청중의 위치에 따라 코드가 안보이는 불상사가 생길 수 있다. 😂
내일 오후 1시에서 2시 사이에 제가 아래 링크한 파이콘 코리아 2025 발표를 들으러 간다는 소식입니다. 올해는 체력이 부족하여 딱 1개 발표만 듣고 바로 철수할 예정...
장안의 화제 〈파이썬토룡신점〉, 나도 쳐봤다!
이제 AI가 손금을 보고 점도 봐주는 시대가 왔다!
다들 좋은 파이콘을 보냈나보군요... 그래... 그러면 된 거야...
해커스펍 고양이가 귀여워
<파이썬토룡신점> 아주 용하더군요
오늘과 내일 PyCon KR 2025에서 해커스펍 부스 도우미로 나와있습니다! 파이콘 오신 분들 많이 들러주세요 :)
점심시간 한정!!!! 부스 지킴이 용병하고 있습니다
파이콘 와서 더위에 시달리다 정신차려보니 왠지 부스에 앉아있었다
근데 확실히 사람의 언어든 프로그래밍 언어든 언어를 새로 배울 때마다 해당 언어의 방식으로 생각해보면서 사고 방식의 확장이 이루어지는 것 같음
이 글에서 "switch network 쓰지 말고 hash map 쓰세요 그쪽이 더 빠릅니다" 해서 정말 그런가? 했는데 그런듯 하다.
지금 진행하던 개인 프로젝트의 디버깅을 찍어보는데 특정 토큰/명령어에 대해서 한 조각씩 들어오는 것에 대해 분기 네트워크를 타면 CPU의 분기예측 캐시가 제대로 쌓이질 않아서 case문 내의 모든 case를 중구난방으로 분기하면서 모두 체크하고 있다. (예를 들어 TOKEN_DEFINE을 찾기 위해서 ase TOKEN_BRACKET_OPEN.. case TOKEN_ALLOCATE... case TOKEN_EQUAL.... 같이 전부 중구난방으로 점프해가며 하나씩 체크한다. O(n)과 같은 최악의 케이스는 아니지만 10개의 케이스가 있으면 적어도 5개는 검색해버리는 짓을 벌임)
후반부로 갈수록 캐시가 쌓여서 바로 점프하는 모습은 보이지만 O(1)으로 바로 분기 없이 점프할수 있는 해시맵이 엄청나게 빠른건 사실인듯하다.
재귀하향식 파서로 구현했기 때문에 파서는 어쩔수 없이 switch network를 타버리긴 하지만 case가 극히 적어 분기 점프에 있어 큰 문제는 아니고 최대한 해시 맵 기반으로 짜는 것이 빠르다는 교훈은 얻은듯 하다.
😂
제가 좋아하는 문제 풀어보실 분
동명의 문제도 좋아함
제가 좋아하는 문제 풀어보실 분
헐... 파이썬 range 당연히 Iterator 인 줄 알았는데 Iterable 에다가 Sequence 였어...
어떻게 커밋해시가 0800804
@kodingwarriorJaeyeol Lee (a.k.a. kodingwarrior) 이 정도면 오늘 복권 하나 사셔야
We'd like to recognize the valuable contributions from two developers who participated in Korea's #OSSCA (Open Source Contribution Academy) program. Both contributors identified important gaps in #Fedify's functionality and documentation, providing thoughtful solutions that benefit the broader #ActivityPub ecosystem.
@gaebalgom개발곰 contributed PR #365, addressing issue #353 regarding NodeInfo parser compatibility, originally reported by 
@andypiper. The issue arose when Fedify incorrectly rejected #NodeInfo documents from snac instances due to overly strict version string parsing that required semantic versioning compliance. Their solution improves the fallback behavior in the parseSoftware() function to handle non-SemVer version strings by parsing dot-separated numbers and defaulting to zero for missing components. The implementation includes thorough test coverage for various edge cases, including single numbers (3), two-part versions (2.81), and malformed version strings. This fix provides immediate compatibility improvements across the fediverse while maintaining backward compatibility, and will be included in Fedify 1.9. The contribution serves as an interim solution, with a more comprehensive fix planned for Fedify 2.0 (issue #366), where the NodeInfo software.version field will be changed from the SemVer type to a plain string to fully comply with the NodeInfo specification.
@z9mb1wwj contributed PR #364, resolving issue #337 by adding practical examples for Fedify's custom collection dispatchers feature. Custom collections were introduced in Fedify 1.8 but lacked clear documentation for developers seeking to implement them. Their contribution provides a comprehensive example demonstrating how to set up custom collections for tagged posts, including proper routing patterns, pagination handling, and counter functionality. The example includes mock data structures, shows how to configure collection dispatchers with URL patterns like /users/{userId}/tags/{tag}, and demonstrates the complete request/response cycle using federation.fetch(). This work provides developers with a clear, runnable reference that reduces the complexity of implementing custom collections in ActivityPub applications.
We appreciate these meaningful contributions that help make Fedify more accessible and robust for the entire ActivityPub community.
아 그러고 보니 이것도 비-토스체네
오예~
문제는 파이콘이랑 겹침ㅠㅠ 파이콘에서 제가 미친듯이 코딩만 하고 있더라도 양해 부탁드립니다...
오예~
es툴킷 문서에서 비-토스체 문장 발견
그것도 두 개나!
이런 것도 수정 PR 올리면 받아주나
Hackers' Pub의 로고 디자인이 완료되었습니다! 디자인은 박은지 님(
연합우주라는 콘셉트에 맞게 고양이의 입 주변을 별 모양으로, 목 아래에도 고리(orbital ring) 모양으로 디자인했습니다. 고양이를 고른 이유는 소프트웨어 프로그래머 커뮤니티에서 다른 동물보다 유독 고양이가 사랑 받기 때문이기도 하고, 고양이가 호기심이 강하기 때문이기도 합니다.
로고 디자인은 CC-BY-SA 4.0 라이선스로 배포됩니다.
홈서버 개발이 개꿀잼인 이유:
잊을만 하면 어디 공개한 적도 없는 도메인에 어드민 페이지나 그에 준하는 리소스 관련 요청이 들어옴
@kodingwarriorJaeyeol Lee 나름 싸피랑 네이버 부스트캠프도 했는데 그런 스펙 싹 지우고 걍 취준생1 돼버린...ㅋㅋㅋ
혹시 AI 자격증 같이 스터디 하실 분 사실 말이 AI 지 사실상 파이썬 + 데이터 관련 라이브러리들(pandas 등) 쓸 줄만 알면 된다고 합니다 https://aice.study
혹시 AI 자격증 같이 스터디 하실 분 사실 말이 AI 지 사실상 파이썬 + 데이터 관련 라이브러리들(pandas 등) 쓸 줄만 알면 된다고 합니다 https://aice.study
기승전 해커스펍 홍보 끝~
함수형 부흥회 ㅋㅋ
원래 한국어는 '뜻 펼쳣잔아~ 한 잖 해~' 하는 느낌으로 쓰는 언어라구욨
‘앞/전’과 ‘뒤/후’의 비대칭성은 한국어 학습자들에게 지옥을 선사할 것이다.
참고로 이거 다 국립국어원의 잘못이 아니라 한국어의 잘못임. 이건 표준국어대사전이 그냥 현실을 반영했을 뿐이다. 즉 이 글을 읽고 있는 당신도 0.000001% 정도 잘못이 있다.
- ‘앞일’은 미래인데(예: 앞일을 예측하다), ‘뒷일’도 미래다(예: 뒷일을 부탁하네). 맞죠?
- 마찬가지로, ‘앞길’은 미래다(예: 앞길이 창창한 젊은이). 그런데 ‘뒷길’도 미래다(예: 자식의 뒷길을 생각하면 걱정이 앞선다).
- ‘뒷날’도 미래고(예: 우리는 뒷날 또 만나게 되었다), ‘훗날’도 미래다(예: 훗날을 기약하다). 그런데 ‘앞날’도 미래다(예: 앞날이 창창하다). 희한하게 ‘전날’만 과거이다.
- 그런데 ‘앞날’은 간혹 과거를 가리킬 수도 있다(예: 일찍이 앞날의 폭군은 있었고…).
- 관형사형에 ‘뒤’나 ‘후’를 붙여서 시점을 나타낼 수 있다(예: “고친 뒤의 모습” 또는 “고친 후의 모습”). 그런데 반대로 하려면 관형사형이 아니라 명사형을 써야 한다(예: “고치기 전의 모습”). 그리고, ‘전’만 쓸 수 있다. ‘앞’은 여기서 아예 쓸 수 없다.
- ‘후일’은 미래의 아무 날이나 다 가리키며, 특정한 날을 가리킬 수 없다. 반면 ‘전일’은 직전, 즉 인접한 과거의 1일만 가리킨다.
- 그런데 또 ‘전날’은 인접한 과거의 1일을 가리킬 수도 있고, 과거의 아무 날을 가리킬 수도 있다.
- 그런데 또 ‘훗날’은 미래의 아무 날을 뜻하며, 인접한 미래의 1일을 가리킬 수 없다.
- ‘전년’과 ‘후년’은 각각 과거의 아무 해, 또는 미래의 아무 해를 가리킬 수 있다. 대, 대칭인가?!
- 하지만 특정한 해를 가리키는 경우, ‘전년’은 인접한 과거의 해를 가리킨다. 반면 ‘후년’은 ‘올해의 다음다음 해’이다.
- …뭐라고? 왜냐하면 미래의 해들은 순서대로 ‘내년’-‘후년’-‘내후년’이기 때문이다. 책상 엎어버리고 싶죠?
- 참고로 ‘내후년’은 동음이의어이다. 올해가 2025년이라면 내후년은 2027년을 가리킬 수도 있고 2028년을 가리킬 수도 있다. (이게 언어냐?)
- ‘후년’이 ‘올해의 다음다음 해’가 되는 이 원리는 오직 ‘년’에만 적용된다. 예를 들어 ‘후일’, ‘후주’, ‘후월’ 등에는 그런 의미가 없다.
- ‘후일’은 미래의 아무 날이다. 하지만 ‘후주’와 ‘후월’은 인접한 미래의 것 하나만 가리킨다.
- ‘전년’은 인접한 과거의 해이지만, 과거의 모든 해를 다 가리킬 수도 있다(예: 우리는 전년의 기록들을 검토하여 그 사람의 행적을 조사해 보기로 했다).
- 반면 ‘전일’, ‘전주’, ‘전월’은 오직 인접한 과거의 하나만 가리킬 수 있다.
- ‘전달’과 ‘훗달’도 비대칭이다.
도대체 이걸 어떻게 배워서 쓰라는 것인지. 생각해 보면 나도 실제로 이렇게 쓰고 있다는 것도 기가 찬다.
그밖에:
- ‘지난날’에는 특정한 날을 가리키는 뜻이 전혀 없다. 반면 ‘지난주’, ‘지난달’, ‘지난해’는 모두 과거의 인접한 하나만 가리킨다.
- ‘다음 날’과 ‘다음날’은 의미가 완전히 다르다. ‘다음날’은 ‘정하여지지 아니한 미래의 어떤 날’이다. 따라서 인접한 미래의 1일을 가리킬 때에는 ‘다음 날’만 쓸 수 있다. (도저히 못 외우시겠으면 그냥 ‘이튿날’로 피신하시라…)