와 진짜 기묘하네 동작에 영향 받을리가 없는데?
notJoon
@joonnot@hackers.pub · 64 following · 79 followers
Uncertified Quasi-pseudo dev
아 찾았다. 실행 직전에 AST에 노드를 삽입하니까 필터링 조건에 걸리는 거였다.
와 진짜 기묘하네 동작에 영향 받을리가 없는데?
VM 내부 로직이 변경됐는데 변경된 동작이 잘 안읽힌다
딴짓을 건설적으로 하기 위해 RFC 문서들 읽어보는 중
https://github.com/bglgwyng/deferred-cleanup-resource-map 이런 라이브러리를 만들었다. ref counting 해서 GC 해주는 map인데, 해제를 임의로 늦출수 있다. LRU 캐시같은걸 일반화한 형태라고 보면 된다.
이름이 참 저질인데, 나도 upyo같은 센스있는 이름을 붙이고 싶었지만, 이게 클로드랑 머리맞대서 나온 최선이다;;
야근 했더니 집에서 코드 볼 체력이 안남았다
역시 기여만큼 재밌는 것도 없다. 오늘한거 https://github.com/faiface/par-lang/pull/59#pullrequestreview-3015078440
ripgrep, comby 조합으로 코드베이스 검사/수정하고 있는데 아주 편하다
@joonnotnotJoon 디버깅 도구 주고 시키면 하긴 하던데요… ㅋㅋㅋ
@hongminhee洪 民憙 (Hong Minhee) 오.. 한번 시켜봐야겠네요
왜 바이브 디버깅은 없는 것이지?
내일은 진짜 mock 작업하던거 끝낸다
이제 발대식도 했으니까 빡겜모드다
@tedpool테드풀
@kodingwarriorJaeyeol Lee
@gaebalgom개발곰
@nyeongAn Nyeong (安寧) @joonnotnotJoon
@crohasang크롸상
@z9mb1wwj @r4bb1t톡기
@2chanhaeng초무
@cosmic_elevatorSooji Choi @ooheunda @woaol벨
@meneleHanal Ae
@devomdv @eottabom
@hjleee93hyeonjeong lee 오늘 발대식에서 만나 뵈어서 반가웠습니다! 다시 한 번 앞으로 잘 부탁드립니다! 화이팅!
OSSCA 발대식 옴
여성향 커미션 중개 플랫폼 크레페를 운영하는 쿠키플레이스에서 시니어 백엔드 엔지니어 채용을 진행중입니다. 채용공고에 해당 직무 소개, 복지, 연봉, 회사문화의 내용이 포함돼 있습니다. 많은 관심 부탁드립니다. Node.js, TypeScript, GraphQL에 대한 높은 숙련도 및 지식으로 팀에 기여해주실 분을 쿠키플레이스에서 극진히 기대하고 있습니다.
크레페에서는 이런 기술스택을 사용합니다
- Node.js, TypeScript, Vitest, Fastify
- GraphQL - Yoga, Relay, Pothos, Prisma
- ElasticSearch, MongoDB, FCM
- Docker, Github Actions
- AWS - ElasticBeanstalk, CloudWatch, Aurora PostgreSQL, Lambda, SES, S3, ElastiCache (Redis)
- Grafana, Sentry
구성원의 성장과 덕질을 지원해요
- 희망 도서 구매 (만화책 및 TRPG 룰북 포함)
- 워크샵 및 교육 프로그램 지원
- 전시, 공연 및 각종 행사 티켓 지원
- 월 5만 크레페 포인트
- 전동작탁 AMOS JP-EX COLOR
- 6인용 TRPG/보드게임 테이블
지원자님이 예상하실 수 있는 처우는 이래요
- 연봉: 최소 8000만원 ~ 최대 2억원 (주 40시간)
- 스톡옵션 부여에 열려있는 포지션
(회사일 얘기) 기존에 작성한 모듈이 상태관리가 이상해서 안에만 뜯어고치고 갈아끼웠는데 바로 테스트가 다 통과한다
@joonnotnotJoon 버스 태워주시는거죠?
@kodingwarriorJaeyeol Lee 헉 비행기 태워주신다고요?
이슈 적당히 어려워보이면서 할만해보이는걸로 고르니까 코드베이스가 더 잘 익혀진다
🎉 Huge shoutout to two amazing contributors from Korea's #OSSCA program who've made excellent contributions to #Fedify!
👏
@gaebalgom개발곰 tackled a tricky terminal compatibility issue in PR #282, fixing the fedify node command's favicon display on terminal emulators without truecolor support (#168). His solution elegantly detects terminal capabilities and falls back to 256-color mode when needed—ensuring a great experience across different environments.
🌟 @joonnotnotJoon enhanced Fedify's #WebFinger functionality in PR #281 by adding a configurable
maxRedirection option to the lookupWebFinger() function (#248). He transformed a hardcoded limitation into a flexible, user-customizable parameter while maintaining perfect backward compatibility.
Both delivered thoughtful, well-implemented solutions that showcase the quality of contributions coming from the OSSCA program. Welcome to the Fedify community! 
어제의 나는 제정신이 아니였군 as any를 이렇게 남발하다니
@joonnotnotJoon 라고 버스 운전기사께서 말씀하시면....
@kodingwarriorJaeyeol Lee 미리 감사합니다 😊
@joonnotnotJoon 그렇군요. 지금 이순간 '과거의 미래의 나'로써, 다시 한번 미래의 나에게 위임하겠습니다.
@bglbgl gwyng 좋은 마음가짐입니다
@joonnotnotJoon .o0(정신 빠짝 차려야겠다)
@kodingwarriorJaeyeol Lee 버스 좀 태워주세요
뭔가 any를 떡칠한거 같지만 미래의 내가 알아서 잘 없애주겠지?
@joonnotnotJoon 궁금해서 제 레포를 검색해보니 3년된
// FIXME: remove any가 있군요
@joonnotnotJoon 궁금해서 제 레포를 검색해보니 3년된
// FIXME: remove any가 있군요
@bglbgl gwyng 더 미래의 자신이 처리해줄거라 믿습니다
OSSCA 본격적으로 시작하면 더 재밌겠지?
뭔가 any를 떡칠한거 같지만 미래의 내가 알아서 잘 없애주겠지?
notJoon shared the below article:
힙스택 보존 법칙
RanolP @ranolp@hackers.pub
이 글에서는 프로젝트 진행 시 기술 스택 선정에 대한 경험적 법칙인 "힙스택 보존 법칙"을 소개하며, 힙한 기술 스택을 과도하게 선택할 경우 프로젝트가 산으로 갈 수 있음을 경고합니다. 저자는 신기술 도입 시 발생하는 호환성 문제와 그로 인한 추가 작업의 부담을 설명하며, 커뮤니티가 크고 성숙한 기술의 중요성을 강조합니다. 힙한 기술을 사용하더라도 프로젝트를 성공적으로 이끌 수 있는 두 가지 조건, 즉 기술의 안정성과 개발자의 숙련도를 제시하며, 힙스택을 사용하기 전에 충분한 학습과 경험을 통해 기술적 내성을 길러야 함을 역설합니다. 이 글은 기술 스택 선택의 중요성과 개발자의 역량 강화 필요성을 동시에 강조하며, 균형 잡힌 기술 스택 선택이 프로젝트 성공에 미치는 영향을 시사합니다.
Read more →@joonnotnotJoon
@kodingwarriorJaeyeol Lee @2chanhaeng초무 어려운 이슈들 가져가시는 건 좋은데, 쉬운 이슈들은 남겨 주세요… ㅋㅋㅋ
@hongminhee洪 民憙 (Hong Minhee)
@kodingwarriorJaeyeol Lee @2chanhaeng초무 쉬운 이슈 처리는 오늘 머지된거 이후로 없을거에요 걱정하지 마세요 ㅋㅋㅋ
@2chanhaeng초무
@joonnotnotJoon 그러면 이분이 냅다 Fedify 일감 가져가버린다니까요!!!
@kodingwarriorJaeyeol Lee @2chanhaeng초무 저 티켓 다 가져갑니다?
오늘따라 키보드 키압이 너무 높은걸?
이슈들 확인해보면서 어떤 것들이 있는지 파악하니까 꽤 해볼만한거 같군
아침에 코드 읽다가 TODO를 봐서 고쳐봤다. 다듬는건 회사가서 해야지
역시 프로젝트를 빨리 이해하려면 직접 써보는게 가장 확실한거 같다
@joonnotnotJoon 끝을 내버렸군요 ㄷㄷ
@kodingwarriorJaeyeol Lee 끝장내고 왔습니다
notJoon shared the below article:
2020년의 하스켈에 대한 내 생각
박준규 @curry@hackers.pub
이 글은 하스켈이 30주년을 맞이한 2020년, 하스켈의 발전 방향에 대한 개인적인 생각을 담고 있습니다. 저자는 하스켈이 프로그래밍 언어 연구와 실제 애플리케이션 개발이라는 두 가지 목표를 동시에 추구해왔지만, 이제는 소프트웨어 개발자에게 유용한 기능에 집중해야 한다고 주장합니다. 특히 복잡한 타입 시스템보다는 사용자 편의성을 높이는 방향으로 개선되어야 한다고 강조하며, 제네릭스 활용과 유용한 확장 기능 활성화를 예시로 제시합니다. 또한, 애플리케이션 아키텍처 측면에서 의존성 주입 컨테이너를 활용한 단순한 구조를 제안하며, 타입 안정성을 약간 희생하더라도 테스트를 통해 충분히 보완할 수 있다고 말합니다. 결국, 저자는 "심플 하스켈" 또는 "지루한 하스켈"을 통해 얻을 수 있는 코드의 명확성과 개발의 즐거움을 강조하며, 하스켈 커뮤니티가 초보자에게 더 쉽게 다가갈 수 있도록 노력해야 한다고 역설합니다. 이 글은 복잡한 이론적 탐구보다는 실용적인 개발에 초점을 맞춘 하스켈의 미래를 제시하며, 독자에게 균형 잡힌 시각을 제공합니다.
Read more →오늘 커피챗은 끝내줬다
이전에도 여러번 추천한 책이지만 저 같은 경우엔 "밑바닥부터 만드는 인터프리터 in Go"로 Go에 입문했습니다. 책의 목적은 인터프리터의 동작, 구현에 대한 것이지만 따라하면서 Go의 코드 스타일이나 테스트 작성 방법도 자연스럽게 익히게 되었습니다. 아니면 "Must Have Tucker의 Go 언어 프로그래밍"도 좋습니다.
내 블로그 글이 기상청 API 피해자 모임이래 ㅋ
CLI 테스트 하고 QA는 클로드 코드를 사용했는데 아주 좋은 개발 경험이였음
얼마전에 구현한 debugger adapter protocol이 실제로 사용 가능한 레벨까지 구현되었다. 한참 걸리겠지만 머지 이후에 외부 IDE에 익스텐션을 만들기만 하면 될듯
@joonnotnotJoon 자신의 임무가 토큰을 파는것이란걸 잘 인지하고 있군요
@bglbgl gwyng AGI가 멀지 않았습니다
기존에 구현된 코드가 아무리봐도 어떻게 수정해야 할지 감이 안잡혀서 뭐가 더 좋을지 분석해달라고 함.
오늘의 Zed 싱글벙글: Inlay Hint에 non-ASCII 텍스트가 있을 경우 Go to Definition하려고 커맨드 누른 채로 커서 올리면 에디터 전체 패닉 남
역시 코드는 추가할 때보다 삭제할 때가 더 타격감이 좋다
아는 친구한테 들은 얘기인데, 최근 이직한 회사에서 Python을 쓰는데 린트나 포매터 같은 것도 전혀 설정을 안 해놓고 살고 있기에 도입하자고 했더니 “그런 거 쓸 거면 Python 안 쓰죠”라는 말과 함께 제안을 거절 당했다고 한다. Python에서도 린트나 포매터는 물론이고 타입 체커까지 붙여서 살려면 살 수 있지만, 어쩐지 그런 거 신경 쓸 사람들은 최근 10년 사이에 다들 다른 언어로 넘어가 버리고 그런 거 신경 안 쓰는 사람들만 Python을 계속 쓰게 된 게 아닌가 싶은 생각이 들었다.
그런 거 쓸 거면 Python 안 쓰죠
프로그래밍 언어의 언권?투사가 되게 만드는 발언이군요. 어떤 프로그래밍 언어든 저런 취급을 받아선 안됩니다. 설령 PHP, 아니 Brainfuck이라고 하더라도 린터와 포매터는 갖추고 살아야합니다.
notJoon shared the below article:
청개구리 스택 찬가
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
이 글은 저자가 기술 스택을 선택할 때 주류를 따르지 않고 대안적인 기술을 선택하는 경향, 즉 "청개구리 스택"을 추구하는 경험을 공유합니다. 청개구리 스택은 사용자가 적어 문제 해결에 어려움이 있을 수 있지만, 기술에 대한 깊이 있는 이해와 오픈 소스 기여 기회를 제공합니다. 또한, 후발주자로서 대안적인 설계를 통해 정석 스택보다 나은 이해를 제공할 수 있습니다. 여러 부품을 직접 조립하는 과정은 번거롭지만 각 기술에 대한 깊은 이해를 얻을 수 있게 합니다. 저자는 오늘의 정석 스택도 과거에는 청개구리 스택이었을 수 있음을 지적하며, LLM 시대에도 청개구리 스택이 주는 배움의 기회는 여전할 것이라고 주장합니다. Stack Overflow에 답이 없는 길을 걸으며 얻는 깨달음은 온전히 자신의 것이 될 것이라는 메시지를 전달하며, 독자들에게도 주체적인 기술 선택과 도전을 권장합니다.
Read more →코드 수정 없이 이슈를 닫았다. 만족스럽군
이제 진짜 코드베이스를 파악해야 한다










