Profile img

Jaeyeol Lee

@kodingwarrior@hackers.pub · 691 following · 504 followers

Neovim Super villain. 풀스택 엔지니어 내지는 프로덕트 엔지니어라고 스스로를 소개하지만 사실상 잡부를 담당하는 사람. CLI 도구를 만드는 것에 관심이 많습니다.

Hackers' Pub에서는 자발적으로 바이럴을 담당하고 있는 사람. Hackers' Pub의 무궁무진한 발전 가능성을 믿습니다.

그 외에도 개발자 커뮤니티 생태계에 다양한 시도들을 합니다. 지금은 https://vim.kr / https://fedidev.kr 디스코드 운영 중

Github
@malkoG
Blog
kodingwarrior.github.io
mastodon
@kodingwarrior@silicon.moe

이 .. 이건 대체 무슨..... funnel이야 뭐 리스프계열이긴 하니까 emacs 리스프로 변환하는거야 어렵지는 않긴 한데... 굳이...? 근데 neovim 플러그인 만들때도 굳이 싶긴 했음 ㅋㅋ!!!

1

iOS 에서 손수 crash reporter 구현하는데에 제약이 많은건 알고 있었지만 애플 엔지니어가 포럼에서 도시락 싸들고 다니면서까지 뜯어 말리는 줄은 몰랐다. ㅎㄷㄷ

이렇게 말리는데에는 몇 가지 이유가 있는데

  1. 크래시 시점에 시그널을 외부 프로세스로 전달할 수 없기 때문에 스택이 정리되는 상태에서 덤프까지 써야 한다.
  2. macOS 특성상 mach Exception 이 signal handling 보다 유리한데, 1의 이유로 제대로 exception 처리를 하기 곤란하고, 그래서 대부분 3rd party들은 signal handler를 등록해서 덤프를 처리한다. 필연적으로 누락되거나 제대로 처리되지 않는 경우가 발생한다.
  3. async signal safe 함수만 써서 구현해야 한다. 안그러면 동작을 보장할 수 없다.

이 외에도 크고 작은 문제들이 생각보다 많고, 암튼 그래서 3rd party iOS 크래시는 수집이 쉽지가 않다.

https://developer.apple.com/forums/thread/113742

2
3
4

TDD 실습으로 TDD의 한계점만 느끼고 있다. std::cin buffer를 바꿔치기해서 thread를 띄우고 gmock에 시간차를 두고 표준 입력을 전달하려니 이게 프로그램 테스트인지 C++ 지식 테스트인지 모르겠다. 테스트 코드가 테스트할 코드보다 어려운 현상은 매우 흔하며, 대개 src 폴더에 있는 코드보다 더욱 빠르게 레거시 코드로 상해버린다. 테스팅은 소프트웨어 개발 주기에서 필수적인 역할을 지니고 있으나 TDD가 프로그램의 명확함을 보장하는 방향으로 굴러가긴 어렵다. 명확한 프로그램은 선행되는 테스트가 아니라 명확한 설계에서 나오기 때문이다.

2
0
1

현재 지식과 두뇌 수준으로 감당하기 힘든 나날들의 연속 😱😱😱😱

3
3
0
0
1
1

해커스펍에 신규로 들어오는 분들을 보는데, 대부분의 경우가 1-2팔로잉으로 끝나는 것 같다. 그러면 초대한 사람의 글만 볼 수 있게 되는 것일텐데, 시작할때 3-6명 더 팔로하면서 타임라인이 풍성해지게 해줄 수 있는 그런 UX가 있으려나

2

해커스펍에 신규로 들어오는 분들을 보는데, 대부분의 경우가 1-2팔로잉으로 끝나는 것 같다. 그러면 초대한 사람의 글만 볼 수 있게 되는 것일텐데, 시작할때 3-6명 더 팔로하면서 타임라인이 풍성해지게 해줄 수 있는 그런 UX가 있으려나

2
3
1
0
4
1
0
2
4
1
2
4
0

레드프린팅으로 굿즈 주문을 처음하는데 한국연합우주개발자 모임 스티커가 잘 뽑혀있을지... 모르겠네... 시간 넉넉한줄 모르고 800개씩이나 주문했는데 불량품이 아니었으면 좋겠다 🥹🥹🥹

1

레드프린팅으로 굿즈 주문을 처음하는데 한국연합우주개발자 모임 스티커가 잘 뽑혀있을지... 모르겠네... 시간 넉넉한줄 모르고 800개씩이나 주문했는데 불량품이 아니었으면 좋겠다 🥹🥹🥹

3
3
5

I’m honored to be giving a keynote at their first charity event. 🎤 at a very special event supporting the newly formed @pyconasiaPython Asia (PAO) created by leaders @iqbalabdIqbal Abdullah 🇯🇵🇲🇾, @kwonhanKwonHan Bae, Manabu Terada and Freilla Mae Espinola.
🎟️ Support their mission by joining the online event on July 26.
Tickets: €7 → events.pythonasia.org/charity-

Let’s help the future of Python in Asia together!

mtd.pythonasia.org/@pyconasia@

Posters of keynote Donghee Na and Georgi Ker
0
0
0
1
0

오늘 서초 OpenUp에서 진행된 OSSCA Fedify팀 모각코에 참여하였습니다.

튜토리얼 완주가 목표였는데 node 버전 이슈가 있었고, 다행히도? 디코에 같은 문제를 겪었던 분이 계셔서 덕분에 어찌저찌 해결하였습니다.
그러나 해당 이슈인지 파악하는데 좀 걸려서 완주는 실패 😞

이슈 내용은: Fedify는 node 22+가 필요한데 내 global node version은 20이었고, 초반에 22 설치는 했으나 터미널에서 적용해야 한다는 개념이 없었음.

그동안 애플리케이션단 구현에만 신경썼지, 의존성 이슈를 겪거나 환경 설정쪽에 큰 관심을 둔 적이 없었는데요. 좋은 경험을 했다는 생각이 듭니다.
다른 분들께서 뭔가 어려운 걸 뚝딱뚝딱 하시는 걸 보고 엄청난 동기부여를 받았습니다. 모각코 좋아용

@ssuminii@hackers.pub 님께서 나눠주신, 제주에서 온 맛있는 과자와 귀여운 Fedify 스티커
9
0
0

Terence Tao: A human metaphor for evaluating AI capability

Link: mathstodon.xyz/@tao/1148814182
Discussion: news.ycombinator.com/item?id=4

Terence Tao (@tao@mathstodon.xyz)

It is tempting to view the capability of current AI technology as a singular quantity: either a given task X is within the ability of current tools, or it is not. However, there is in fact a very wide spread in capability (several orders of magnitude) depending on what resources and assistance gives the tool, and how one reports their results. One can illustrate this with a human metaphor. I will use the recently concluded International Mathematical Olympiad (IMO) as an example. Here, the format is that each country fields a team of six human contestants (high school students), led by a team leader (often a professional mathematician). Over the course of two days, each contestant is given four and a half hours on each day to solve three difficult mathematical problems, given only pen and paper. No communication between contestants (or with the team leader) during this period is permitted, although the contestants can ask the invigilators for clarification on the wording of the problems. The team leader advocates for the students in front of the IMO jury during the grading process, but is not involved in the IMO examination directly. The IMO is widely regarded as a highly selective measure of mathematical achievement for a high school student to be able to score well enough to receive a medal, particularly a gold medal or a perfect score; this year the threshold for the gold was 35/42, which corresponds to answering five of the six questions perfectly. Even answering one question perfectly merits an "honorable mention". (1/3)

mathstodon.xyz · Mathstodon

0
6
0
6

현재 시각은 23시 58분. Fedify에 NestJS를 지원한다고 온갖 삽질을 하다가 마지막을 보고 있는 시점에서 뭘할까 고민하다 가만히 있기는 좀 그래서 끄적이는 의식의 흐름대로 쓰는 글....

맥락이 싹다 휘발되기전에 내가 어떻게 우여곡절을 겪었는지를 좀 러프하게 요약해보자....

  • Fedify 프로젝트를 NestJS 에서도 쓸 수 있도록 Fedify 모듈을 만들려고 했던 것에서부터 불행이 시작됨.

  • 애초에 NestJS는 CommonJS 기반이고 Fedify는 ESM 모듈만 지원했어서, 이걸로 사용할 수 있녜마녜 하는 얘기가 오가는 중에 Node 22 버전에서 NODE_OPTIONS=--experimental-require-module 환경변수 걸면 esm 모듈을 가져올 수 있다는 사실을 알게됨.

  • Fedify 프로젝트에 포함된 라이브러리로 넣기 이전에, 가설검증은 해봐야겠어서 기존에 NestJS 기반으로 만들려고 벼르고 있던 프로젝트에서 가설검증을 시도함

  • 가설 검증 자체는 성공적이고 스무스했음. Fedify microblogging 예제를 돌릴 정도는 돌아갔던 것 같음.

  • 하지만........ Fedify로 통합하는 과정이 문제가 있었는데... Fedify에 돌아가는 코드를 옮겨놓고, 그 코드가 의도하는대로 잘 뽑히는지가 문제였던 것이다.

  • 예를 들면, NestJS는 Typescript 생태계에서는 거의 deprecated된 것으로 취급하는 Decorator 문법을 쓰고 있는데, deno 런타임에서는 지원안하는것은 물론이고, 패키징을 하는 것 자체는 성공했으나 npm 패키지를 가져다 쓰는 입장에선 계속해서 런타임 에러가 뜨는 것. 데코레이터 문법의 경우엔 tsconfig 파일을 또 별도로 수정해서 어떻게든 코드가 뽑히게 했음.

  • 그래서 node_modules 를 직접 까보면서 코드가 어떻게 뽑히는지 직접 두눈으로 확인해보기도 하고, 민희님 도움 받아서 pnpm prepack 커맨드로 tgz 파일 만들어서 그걸 package.json에서 가져다 쓰는 것도 어쩌다보니 하게 되고... 패키징은 제대로 되었는데 왜 import 오류가 다시 뜨는가 하고 봤더니, 처음으로 돌아가서 NODE_OPTIONS 환경변수 문제였고. commonjs/esm 둘다 js 아웃풋이 나오도록 세팅하는 것도 해보고, 패키지 퍼블리시까지 겨우 성공

  • 그러다가, 다시 왜 안 돌아가지하고 봤는데... 처음에 돌아가던 코드에서 좀 정리를 하다보니 안 돌아가게 된 케이스도 있었고, 어떤 부분은 NestJS 내부 구현(Express)을 몰라서 계속 똥볼을 찬 케이스도 있었고, 몇시간을 심연을 들여다 봤던 것 같다...

패키징하면서도 오류 터져서 빌드깨지는거만 체감상 한 10~15번 정도한 것 같은데 머리에 스팀 나는 줄 알았음...

이젠 된다... 진짜 험난한 여정이었다...

현재 시각은 23시 58분. Fedify에 NestJS를 지원한다고 온갖 삽질을 하다가 마지막을 보고 있는 시점에서 뭘할까 고민하다 가만히 있기는 좀 그래서 끄적이는 의식의 흐름대로 쓰는 글....

맥락이 싹다 휘발되기전에 내가 어떻게 우여곡절을 겪었는지를 좀 러프하게 요약해보자....

  • Fedify 프로젝트를 NestJS 에서도 쓸 수 있도록 Fedify 모듈을 만들려고 했던 것에서부터 불행이 시작됨.

  • 애초에 NestJS는 CommonJS 기반이고 Fedify는 ESM 모듈만 지원했어서, 이걸로 사용할 수 있녜마녜 하는 얘기가 오가는 중에 Node 22 버전에서 NODE_OPTIONS=--experimental-require-module 환경변수 걸면 esm 모듈을 가져올 수 있다는 사실을 알게됨.

  • Fedify 프로젝트에 포함된 라이브러리로 넣기 이전에, 가설검증은 해봐야겠어서 기존에 NestJS 기반으로 만들려고 벼르고 있던 프로젝트에서 가설검증을 시도함

  • 가설 검증 자체는 성공적이고 스무스했음. Fedify microblogging 예제를 돌릴 정도는 돌아갔던 것 같음.

  • 하지만........ Fedify로 통합하는 과정이 문제가 있었는데... Fedify에 돌아가는 코드를 옮겨놓고, 그 코드가 의도하는대로 잘 뽑히는지가 문제였던 것이다.

  • 예를 들면, NestJS는 Typescript 생태계에서는 거의 deprecated된 것으로 취급하는 Decorator 문법을 쓰고 있는데, deno 런타임에서는 지원안하는것은 물론이고, 패키징을 하는 것 자체는 성공했으나 npm 패키지를 가져다 쓰는 입장에선 계속해서 런타임 에러가 뜨는 것. 데코레이터 문법의 경우엔 tsconfig 파일을 또 별도로 수정해서 어떻게든 코드가 뽑히게 했음.

  • 그래서 node_modules 를 직접 까보면서 코드가 어떻게 뽑히는지 직접 두눈으로 확인해보기도 하고, 민희님 도움 받아서 pnpm prepack 커맨드로 tgz 파일 만들어서 그걸 package.json에서 가져다 쓰는 것도 어쩌다보니 하게 되고... 패키징은 제대로 되었는데 왜 import 오류가 다시 뜨는가 하고 봤더니, 처음으로 돌아가서 NODE_OPTIONS 환경변수 문제였고. commonjs/esm 둘다 js 아웃풋이 나오도록 세팅하는 것도 해보고, 패키지 퍼블리시까지 겨우 성공

  • 그러다가, 다시 왜 안 돌아가지하고 봤는데... 처음에 돌아가던 코드에서 좀 정리를 하다보니 안 돌아가게 된 케이스도 있었고, 어떤 부분은 NestJS 내부 구현(Express)을 몰라서 계속 똥볼을 찬 케이스도 있었고, 몇시간을 심연을 들여다 봤던 것 같다...

패키징하면서도 오류 터져서 빌드깨지는거만 체감상 한 10~15번 정도한 것 같은데 머리에 스팀 나는 줄 알았음...

이젠 된다... 진짜 험난한 여정이었다...

13