상시 #블친소 #개발자_블친소 (개발자/프로그래머 버전) 대학교 탈출을 꿈꾸고 있는 학부생입니다. 아직은 취미(🥲)로 게임/웹 개발을 하고 있고 간단한 SVG를 다룰 수 있습니다(갑자기??). 🌐 eatch.dev 🐱 github.com/EatChangmyeong 📝 @blog.eatch.dev (이전 중) 🎈 solved.ac/profile/dlau... (💙₅ 2294, CLASS 6)

bgl gwyng
@bgl@hackers.pub · 82 following · 94 followers
슈티를 함께 만들 팀을 만들고 있습니다. 관심 있으신 분, 또는 잘 모르겠지만 이야기를 나눠보고 싶은 분도 bgl@gwyng.com으로 편하게 연락주세요.
GitHub
- @bglgwyng
shootee
- www.shootee.io
@bglbgl gwyng 7월 2일에 만나고자 하셨는데 장소 협의에 대한 메일 회신이 없으셔서 멘션 남깁니다~
@iamuhun김무훈 앗 죄송합니다! 바로 회신하겠습니다.
이제 2025년인데 에반게리온 CLI 프레임워크도 나올때 되지 않았음?
해킹 및 온라인 스토킹을 겪어보니, 자유롭게 글을 작성하는 것이 어렵습니다. 사적인 연락은 메일로 부탁드립니다! mail@leetekwoo.com 덧붙여 말씀드리자면, 저는 여러분의 프라이버시를 존중합니다. 건전한 교류에는 항상 열려있습니다. 감사합니다~
와하하 이거 다!!!!
와하하 이거 다!!!!
함수는 파란색, 변수는 빨간색 같은 의미없는 알록 달록 말고, 함수들이 소속된 모듈 별로 색이 다르다든지, 로컬 변수, 글로벌 변수, 매개 변수를 구별한다든지.. 누가 안 만드나...
@lionhairdino VS Code위에서 퀴어 퍼레이드가 펼쳐질거 같군요
React Native 및 앱 개발 생태계에 대해 욕하고 싶은 사람들이 모이는 연합우주 인스턴스가 있었으면 좋겠다...
어제 튜링의 사과를 처음 구경했습니다. 귀인들 만나느라 이용은 안하고 구경만. 조금 과장해서 얘기하면, 다른 공유 오피스와는 다르게 PC방에 개발자 모인 것 같은 느낌이었습니다. 다른 오피스들처럼 조용하고, 조금은 생기 없는 풍경이 아니라, 상대적으로 소음도 좀 있고, 활기가 있어 보여 의외였습니다. 장소 오너분들도 개발자로 알고 있는데, 개발자 이해도가 높은 게, 영향이 있는 것 아닐까요?
(삶에 찌든 사람들 모인 PC방 말고, 젊은이들이 즐겁게 노는 모습의 PC방입니다.)
@bglbgl gwyng 기능면에서 대단히 훌륭합니다. 한동안 잘 썼었어요. 다만 다소 무거운 감이 있어서 저는 순정으로 돌아왔습니다 ㅡㅠ.
@hyaline 제게 유용한 모든 정보가 저 UX위에서 하루종일 아래로 흘렀으면 좋겠습니다.
안녕하세요, SNS 프로젝트로 Jeju.social을 만들었습니다. 제주도의 친구, 가족, 기업들이 안전하게 사진과 정보를 공유할 수 있는 온라인 커뮤니티입니다. 외국인들과도 함께요. 즐거운 시간 보내세요.
Hello, I created Jeju.social as a social media project. It is an online community where friends, family, and businesses on Jeju Island can share photos and information safely. Even for foreigners. Please enjoy.
요즘 트위터에 하스켈 관련 계정들보면 Go를 가장 싫어하는 언어로 꼽는 경우를 자주 본다. C/C++/Java 등은 역사적인 맥락을 고려해 예우해주고, Python/JS 등등의 이상한 기능은 뭘 몰라서 잘못 만들었다고 이해해주는 반면, Go는 하스켈러들이 중요하게 여기는 가치들을 일부러 다 무시하고 만들기 때문에 괘씸가중치 x10 정도를 적용받는 듯하다.
내일(7월 1일) 개인 용무로 잠시 제주를 벗어나 서울에 이틀간 머물 예정인데요, 이날 5시 이후부터 여유 시간이 많아 만나서 이야기 나눌 분을 찾습니다.
자기소개 - 블로그 소개 및 Gravatar 프로필 참고
- 10여 년 전부터 웹 프로그래밍을 생산성과 취미로 즐겨하고 있는 컴퓨터 전공 4학년 학부생입니다.
- 이번 1학기에 졸업 요건을 대부분 만족하여 프런트엔드 개발 직군으로 구직 활동을 시작했습니다.
I'm currently experimenting with a poll creation feature for @botkitBotKit by Fedify
. If this experiment pans out, the feature will likely be included in the next release, BotKit 0.3.0. So far, so good. Each vote will trigger a
Bot.onVote
event in real-time. This could open up a lot of interesting possibilities, like a bot that uses emoji selection for one-time authentication.
I think the @fedifyFedify: an ActivityPub server framework project has now reached full maturity. What this means is that all the low-hanging fruit has been addressed, and only the difficult problems remain. 😂
잘 못만든 선언형 인터페이스보다는 잘 못만든 명령형 인터페이스가 낫다. 후자는 피똥싸면서 뭔가를 어찌저찌 해낼순 있는데, 전자는 아예 뭔가를 하는게 불가능한 경우가 많다.
내일 모각코가 매우 기대되는구만요
@bgl@hackers.pubbgl gwyng
@hongminhee@hackers.pub洪 民憙 (Hong Minhee) 그 상황에도 저는 개인적으로는 그게 맞지 않은가 싶어요. TS가 잘못되었을 것을 가정하는것 보다는 TS를 믿고 불필요한 에러 처리를 없애는게 가독성과 성능과 유지보수성 측면에서 낫지 않을지...
@pbzweihander쯔방
@hongminhee洪 民憙 (Hong Minhee) Prisma가 실제로 사용되는 방식을 볼때 선택할만한 옵션이라고는 생각합니다.
방금 또 빌드 캐시 삭제를 일찌감치 시도해보지 않는 오만함 때문에 1시간을 허비했다ㅠㅠ
Javascript Weekly 뉴스레터에 @hongminhee洪 民憙 (Hong Minhee) 님의 Logtape가 소개되었습니다
드디어 스레드에서 연합우주 계정 팔로우가 된다... @alternative00__alternative 님 덕분에 알게된 사실...
@hongminhee@hackers.pub洪 民憙 (Hong Minhee)
@bgl@hackers.pubbgl gwyng 그건 버그인거죠.. 어쩔 수 없죠.....
프리즈마는 라이브러리의 개념이라 살짝 결이 다를 수는 있는데 저는 어플리케이션이 실행 도중에 크리티컬한 문제를 만났을 경우 graceful한 에러 처리를 하는 것 보다는 그냥 패닉을 내는게 나은 상황도 많이 보는 것 같아요
예를들면 GPU를 사용하고 HTTP 엔드포인트가 있는 프로그램인데 요청했더니 GPU에 연결을 못하는 경우 500을 돌려주는게 아니라 그냥 패닉을 내는게 쿠버 사용할 때 입장에선 편하더라구요
아무튼 Option이나 unwrap이 잘못된 건 아니고, 프리즈마 개발자가 잘못한 겁니다! 프리즈마를 욕합시다!
@pbzweihander쯔방
@hongminhee洪 民憙 (Hong Minhee) 제가 방금 Prisma에서 겪은건 JS 단에서 null이 아니어야 하는 값에 null을 준 경우인데요. 상식적으로는 panic 대신에 올바른 에러메시지를 주는게 맞죠. 상황이 특이한게 이 경우엔 사용자로부터 올바른 입력이 들어올것을 보장하는것이 TS 타입입니다ㅋㅋ 그래서 Prisma의 입장은 TS단에서 타입체크를 통과하지 못하는 요청엔 panic을 띄울수있다는 건데 좀 황당하네요.
@bgl@hackers.pubbgl gwyng
@hongminhee@hackers.pub洪 民憙 (Hong Minhee) unwrap을 쓰는 것은 null pointer의 다른 이름으로써 null이면 panic이게 하는 것이 의도가 맞습니다..?
@pbzweihander쯔방
@hongminhee洪 民憙 (Hong Minhee)
Option
이란 이름을 붙인거 치고는 unwrap
을 큰 죄책감없이 쓰는거 같다는 이야기였습니다.
요즘 함수 적용Apply에 꽂혀서, 처음 보는 프레임워크 코드들을 Apply 위주로 읽으니 그럴싸합니다. 그래서, Apply 생각 일부를 정리했습니다. 함수형 프로그래밍 언어도 익숙하지 않은 외국어와 비슷한 느낌이라, 코드들을 정확히는 몰라도 일단 통밥으로 읽는 방법을 계속 훈련 중입니다.
Apply - 이펙트가 있는 함수들을 연이어 적용하고 싶어
Apply - Price와 (exRate -> Price)를 다루는 프로그램의 골격을 똑같이 하고 싶어
해커스펍에 바로 올릴까 했는데, 읽어보니 조금 더 정돈하고 올리고 싶다는 생각이 들어, 개인 블로그에 먼저 올립니다.
@bglbgl gwyng Haskell 쓰던 사람으로서
Option::unwrap()
같은 걸 쓸 거면 어째서 Option
타입을 만들어서 쓰는 걸까 싶은 생각이 들 때가 있습니다…
@hongminhee洪 民憙 (Hong Minhee) 최선을 다하고나서 결국 임시 땜빵으로
Option::unwarp
쓰고 FIXME 달아 놓으면 이해는 갑니다만... 예전에본 러스트 튜토리얼에선 unwrap을 막 쓰더라고요? 단지 null 포인터의 다른 이름이고 Option::unwarp
은 if ptr == null then panic
느낌으로요.
하다하다 Prisma의 Rust PANIC도 다 보는구나
PANIC: called `Option::unwrap()` on a `None` value
억까 그만해!!!
...는 TS 단에서 nullability 못잡고 요청보내면 이럴수가 있군요
하다하다 Prisma의 Rust PANIC도 다 보는구나
PANIC: called `Option::unwrap()` on a `None` value
억까 그만해!!!
@bglbgl gwyng 근데 암묵지는 암묵지라서 스스로 인식하기 어렵다고 하더라고요. 암묵지를 이끌어내는 전문가들이 따로 있다고 들었어요.
@hongminhee洪 民憙 (Hong Minhee)
@bglbgl gwyng 지나가다 관심 있는 주제가 보여 의견을 드려보아요. 사실 전문가가 전문성을 발휘하는 데에는 암묵지가 많아도 문제가 없는데, 전문성을 남에게 설명하거나 교육해야 할 때에는 어려움을 크게 높이는 요소가 됩니다. 그래서 홍님이 말씀하신 암묵지를 이끌어내는 전문가들은 인지 작업 분석(CTA) 같은 기법을 사용하기도 하는데요. bgl 님이 멘토링을 하고 계신다는 걸 보면 이미 어떤 식으로든 교육을 위해 암묵지를 많은 부분 명시지화 하셨을 것 같기도 해요. 물론 홍님 말대로 암묵지는 암묵지인 것일 수도 있겠지만요. 😅
@bglbgl gwyng 근데 암묵지는 암묵지라서 스스로 인식하기 어렵다고 하더라고요. 암묵지를 이끌어내는 전문가들이 따로 있다고 들었어요.
@hongminhee洪 民憙 (Hong Minhee) 저도 처음엔 제 스스로 인식못하는 암묵지들이 꽤 많을거라 막연히 기대했었는데요. 멘토링하면서 제가 아는걸 최대한 덤프떠서 전달하려고 노력하는 와중에, 대충 '하스켈 최고! 응애~' 정도로 요약이 되는걸 깨달아버려서 약간 허탈합니다.
Claude야. 오류나면 일단 주석 쳐서 지워버리고, 상수 그냥 다시 정의하는건 어디서 배워왔니
@perlmint 어디겠습니까... (뜨끔)
그동안 멘토링하면서 느낀게, 나한테 암묵지가 별로 없다는 것이다. 전문가는 암묵지가 많다는데, 나는 내 스스로가 매우 간단한 휴리스틱으로 동작한다고 느낀다. 난 전문가가 아닌건가? 내가 그동안 쌓아온 것은 암묵지라기보단 어떤 특정한 사안에 대한 강한 믿음들인거 같다.
bgl gwyng shared the below article:
OX 테스트 당신은 책중독자인가?

박준규 @curry@hackers.pub
이 글은 톰 라비의 《어느 책중독자의 고백》을 인용하여 독자가 스스로를 "책중독자"로 진단해볼 수 있는 간단한 OX 테스트를 제공합니다. 모르고 같은 책을 두 번 산 적이 있는지, 표지 디자인만 보고 책을 구매한 적이 있는지 등 10가지 질문을 통해 독자 스스로가 책에 대한 애정을 어느 정도 가지고 있는지 되돌아보게 합니다. 이 테스트는 가벼운 마음으로 자신의 독서 습관을 재미있게 평가해보고, 책에 대한 애정을 다시 한번 확인하는 계기를 마련해줍니다.
Read more →gemini-cli 이것저것 만져보는 중인데, gemini-2.5-pro
의 코드 수정능력이 생각보다 괜찮아서 좀 더 써볼 것 같다. VSCode 의 Gemini Code Assist 보다는 만족감이 더 높다. 다만 이미지 분석 용도는 아닌 것 같고. 코딩 용도로 쓰면 괜찮을 것 같다.
@bglbgl gwyng 생각해보니 그런 것 같습니다. 역시 손발이 튼튼하면 머리가 고생을 안 한다!
@hongminhee洪 民憙 (Hong Minhee) 근데 저도 한 10년전에 파이썬 프로젝트할때 Django 대신 Flask 골랐었는데, 아마 홍민희님 글 읽고 그랬던거 같아요.
애초에 Deno 붙잡고 있는 것도 청개구리 같네…
@hongminhee洪 民憙 (Hong Minhee) 청개구리 스택을 골라놓고 피지컬로 돌파하고 계시는군요
새롭게 다시 태어난, 또 만들어버린 boilerplate. 이제는 진짜 monolithic 하고 Pocket Galaxy라는 이름에 걸맞는 boilerplate입니다.
Django + Vue(Vuetify) 조합이구요, nginx가 이것저것을 다 처리합니다.
백엔드는 /api
에서 서빙하고, 기타 기본적인 static 캐싱이나 로깅 등 전부 기초적인건 제공합니다.
간단한 웹사이트 하나 만들겠다는게 어쩌다 여기까지 왔는지.... 암튼 이제는 진짜 최소한의 웹사이트 만들때 뚝딱 하면 만들수 있을것 같습니다 제발...
내부용 툴 만들때 애용해보세요.
오픈소스 프로젝트에 여러분의 gemini cli(등등)의 무료 사용량을 기여하세요
오픈소스 소프트웨어라는 소프트웨어 개발 방법은 그동안 대성공을 거두어 오고 있습니다. 여기에는 여러 요인이 있지만, 중요한 요인 중 하나는 이것입니다. 상업 소프트웨어든 오픈소스 소프트웨어든 공평하게 프로그래머의 시간을 들인 만큼 개발된다는 것이지요. 능력 있는 소프트웨어 개발자가 시간을 기여하면 오픈소스 소프트웨어는 상업 소프트웨어만큼이나 빠르게 성장할 수 있었습니다.
하지만 AI 프로그래밍의 시대가 빠르게 다가오고 있습니다. 앞으로 소프트웨어 개발은 프로그래머의 시간만으로 개발되지 않습니다. 상업소프트웨어는 AI 프로그래밍을 적극적으로 사용하여 이전과 다른 생산성으로 개발되기 시작할 것입니다. 상업 소프트웨어와 달리 오픈소스 소프트웨어는 언제나 그럴 수는 없습니다. 프로젝트의 성장과 유지를 위해 훌륭한 프로그래머들의 시간을 들이는 것을 넘어서, 훌륭한 프로그래머들이 시간에 더해 비용까지 들여야 한다면요.
상업 소프트웨어와 오픈소스 소프트웨어 사이의 불균등한 생산성의 시대가 코앞까지 다가오고 있습니다.
새로운 기여자 확보의 문제
문제는 여기서 그치지 않습니다. 오픈소스 프로젝트는 새 기여자를 얻기 더 힘들어져가고 있습니다. 왜냐하면 이제 'good first issue'라는 것은 의미가 없기 때문입니다. 그 정도로 쉬운 일은 새로운 기여자 대신 로봇이 해결할 가능성이 높고, 그 로봇은 새로운 기여자의 로봇일 수도 있습니다. 결국 AI 프로그래밍으로 기여하는 새 기여자는 이 프로젝트에 대해 거의 배우지 못하게 됩니다.
전통적인 오픈소스 생태계에서 'good first issue'는 단순히 쉬운 문제를 해결하는 것이 아니었습니다. 새로운 기여자가 프로젝트의 코드베이스를 이해하고, 개발 프로세스를 익히며, 커뮤니티와 소통하는 법을 배우는 학습 과정이었습니다. 하지만 AI가 이런 단순한 작업들을 대신 처리하게 되면, 새로운 기여자들은 진입 기회를 잃게 됩니다.
AI 프로그래밍의 현재 위치
AI 프로그래밍은 완벽하지 않습니다. 숙련된 전문가가 숙련된 도메인에서 작업하는 것만큼 잘하지는 못합니다. 하지만 비숙련된 프로그래머가 처음 보는 프로젝트에서 작업하는 것보다는 잘할 때가 많습니다.
그러나 많은 오픈소스 소프트웨어는 바로 이런 비숙련 기여가 성장의 한 축을 차지합니다. 처음 프로젝트에 참여하는 개발자들의 작은 기여들이 모여 거대한 프로젝트가 됩니다. 그리고 이런 비숙련 기여의 일부는 손쉽게 AI가 대체할 수 있는 기여입니다.
다행히도 지금은 AI 프로그래밍의 초창기입니다. Gemini CLI가 무료 사용량을 제공하듯이, 앞으로 여러 회사들이 비슷한 기회를 제공할 것입니다. Claude, ChatGPT, Copilot 등 다양한 AI 도구들이 개인 사용자에게 무료 크레딧을 제공하고 있습니다.
이것은 오픈소스 프로젝트에 기여할 새로운 기회로 삼을 수 있을까요?
주의: 이 글은 아무 프로젝트에나 방문해서 AI로 적당한 코드를 생성한 다음 패치를 보내라는 뜻이 아닙니다.
AI 프로그래밍은 (아직은) 마법이 아닙니다. "이 프로젝트를 겁나 멋지게 만들 기능을 추가해주세요"라고 한다고 해서 그런 패치가 나오는 식으로는 동작하지 않습니다.
이상적인 경우: AI 친화적 프로젝트
가장 좋은 방법은 프로젝트가 AI 친화적으로 준비되는 것입니다. 바로 작업할 수 있을 만큼 잘 정의된 이슈들이 있는 프로젝트라면, "nnn 번 이슈에 대해 작업해 주세요"라는 요청만으로도 누구나 기여할 수 있을 것입니다.
하지만 (적어도 아직은) 그런 프로젝트가 많지는 않을 것입니다.
현실적인 접근: AI가 잘하는 일들에 집중
대신 AI는 인간과 비대칭적으로 잘하는 기능이 있습니다.
이를테면 이슈에 minimal reproducible case가 보고되어 있지만 아직 구체적으로 발생하는 원인이 밝혀져 있지 않은 경우를 생각해봅시다. 버그를 고치는 사람이 해야하는 지루한 작업 가운데 하나는, 이 문제를 어떻게 수정할지를 생각하기에 앞서 이 문제가 어디서 발생하는지 찾는 것입니다. 디버거를 써야 할 수도 있고, 코드에 많은 trace log를 남겨야 할 수도 있습니다.
하지만 AI 코딩 에이전트는 테스트가 재현 가능하기만 하다면, 문제를 발생시키는 정확한 줄을 찾아내는 데 탁월합니다. 지치지 않고 정석적인 지루한 방법으로 꾸준히 로그를 추가하고 테스트를 다시 실행하면서 문제를 찾아내거든요.
어쩌면 문제의 원인이 아주 단순해서, 문제를 바로 수정할 수 있을지도 모릅니다! 그렇다면 패치를 제출해도 좋겠지요. 하지만 바로 수정하기까지는 어렵더라도 괜찮습니다. 버그 리포트와 실제 코드의 문제를 매핑하는 것은 그 자체로 지루하고 시간이 걸리는 일입니다. 이것을 대신하는 것으로도 큰 작업을 대신하는 것입니다.
주의: 모든 프로젝트가 AI 기여를 환영할 리는 없습니다. 충분히 유용하게 다듬어지지 못한 유형의 AI 기여는 스팸처럼 느껴질 가능성이 있음을 유의해야 합니다.
미래
사실 누구나 자기 라이브러리를 뚝딱 만들어낼 수 있게 되었다는 점에서 오픈소스 프로젝트에 참여하는 사람들의 동기와 기여 방식 자체가 크게 뒤바뀔 가능성이 높습니다.
AI 프로그래밍을 누구나 거의 무료로 사용할 수 있는 시대가 올까요? 아마 어느 정도의 사용량까지는 그럴 것입니다. 그것이 얼마나 많은 양일지에 따라서 오픈소스 프로젝트의 미래는 크게 바뀌겠지요.
만일 정말로 AI 프로그래밍을 누구나 무제한적으로 사용할 수 있다면, 대규모가 아닌 대부분의 오픈소스 프로젝트에는 더이상 협력이 필요하지 않을 것입니다. 진정으로 '어떻게'보다 '무엇을'이 더 중요한 시대가 온다면, 프로젝트의 목표를 확고하게 가진 사람이 극한의 완성도까지 프로젝트를 밀어붙이는 편이 훨씬 좋은 결과를 만들겠지요.
그런 시대가 올지 오지 않을지 모르겠습니다. 하지만 그 전까지는, AI 프로그래밍이 누구에게나 주어지는 기회이지만 프로젝트를 단숨에 완성할만큼 주어지지는 않는 시대가 유지되는 동안에는, 다음 세대의 오픈소스 기여의 방법은 AI 프로그래밍 사용량을 기여하는 것이 하나의 큰 축이 될 것입니다.
bgl gwyng shared the below article:
불경하다! 어딜 데이터베이스를 깔려고 하느냐? ESENT (ESE) DB 활용기
고남현 @gnh1201@hackers.pub
이 글에서는 외부 개발 도구 사용이 제한된 환경에서 데이터베이스를 활용해야 하는 상황에 대한 해결책을 제시합니다. 필자는 Windows 운영체제에 기본 탑재된 ESENT (ESE) 데이터베이스를 활용하여 칼럼, 스키마, CRUD(생성, 읽기, 수정, 삭제) 기능을 추상화하는 API를 직접 구현했습니다. 이를 통해 개발자는 상용 데이터베이스 없이도 어플리케이션 개발에 필요한 데이터베이스 기능을 사용할 수 있게 되었습니다. 제시된 C# 코드 예제를 통해 ESENT 데이터베이스를 초기화하고, 데이터를 삽입하고, 조회하는 방법을 보여주며, 이를 통해 개발 생산성을 향상시킬 수 있음을 강조합니다.
Read more →나는 리액트에서 성능 자체가 떨어지는 부분보다(제대로 체감한적 없음), 성능을 고려해서 컴포넌트를 일부러 나눠야하는 점이 더 맘에 안든다.
클플 뭐 서비스 낼때마다 리전 맨날 Earth 요따구로 해두니까 우주진출 뒤의 클플을 상상하게 됨
아 9월부터 강의를 합니다 (교수가 되었습니다). 무슨 과목을 맡게될지는 모르겠지만 꿈에 그리던 기깔난... 마치 IoT로 도배된 집과도 같은 강의를 해보겠습니다 기대해주세요. 그리고 언젠가 이 경험들이 쌓여서 파이콘에서라도 발표하면 좋겠네요.
@theeluwin제이미 축하드립니다!!
리액트 작업하면 vs code 탭 두 개 한 화면에 브라우저 한 화면에 디자인 전달받아서 하면 figma나 시안 확인용 화면 하나에 모니터 세 개쯤은 있어야 하던데 노트북만 들고 카페에서 코딩하는 건 어떤 종류의 작업일까….
bgl gwyng shared the below article:
How to pass the invisible

洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
This post explores the enduring challenge in software programming of how to pass invisible contextual information, such as loggers or request contexts, through applications without cumbersome explicit parameter passing. It examines various approaches throughout history, including dynamic scoping, aspect-oriented programming (AOP), context variables, monads, and effect systems. Each method offers a unique solution, from the simplicity of dynamic scoping in early Lisp to the modularity of AOP and the type-safe encoding of effects in modern functional programming. The post highlights the trade-offs of each approach, such as the unpredictability of dynamic scoping or the complexity of monad transformers. It also touches on how context variables are used in modern asynchronous and parallel programming, as well as in UI frameworks like React. The author concludes by noting that the art of passing the invisible is an eternal theme in software programming, and this post provides valuable insights into the evolution and future directions of this critical aspect of software architecture.
Read more →해커스 펍은 아무래도 어텐션이 낮다 보니 채용 시장 이야기를 조금 해 보자면 (트위터는 왠지 채용 과정에서 아쉬운 경험을 하신 분들도 있을 것 같고, 해서) 새로운 프론트엔드 개발자분이 곧 합류하시는데 채용까지 이르는 데 까지 정말 많은 이력서 스크리닝을 해야 했다. 솔직히 말해 '옛날에 비하면' 뛰어난 개발자분들이 시장에 많은데 (공개적으로 이야기하기는 뭐한) 특정한 스타일의 비슷한 개발자분들이 아주 많다. 괜찮은 사람을 아무나 빨리 뽑는 채용 기조는 아니다 보니 정말 특출나게 뭔가 뛰어난 부분이 있는 분을 찾아야 한다는 압박감이 있었고, 이것때문에 좀 힘들었다.
블로그 글로도 적어봤습니다. 재현 환경 구성 하는거 너무 노가다인데 어떻게 잘 할까..