Hong Segi (aka khris)

환경 보호를 위해 electron등을 사용한 webview기반 애플리케이션을 더 이상 만들지 못하게 해야합니다

어지간해선 적절한 키보드 높이에 맞는 책상을 찾기 어려운데, 키보드 전용 움직이는 책상 같은거라도 찾아봐야 할 듯.

역시 코딩의 재미는 차력쑈에 있다. 코드 골프, Reactive Programming, TypeScript같은 언어에서 타입으로 이상한짓 하기 등...

안녕하세요, 백엔드 경력직 프로그래머 뽑고 있습니다. 로그를 모니터링하고 저장하는 시스템을 개발하는 포지션입니다. 기존 오픈소스 솔루션을 사용하긴 하지만 단순히 구축하고 운영하는 것은 아닙니다. 운영도 하지만 개발이 주된 업무 입니다. (오픈소스 솔루션 운영 포지션으로 착각하고 지원하시는 분들이 계셔서 사족을 넣었습니다) https://careers.linecorp.com/ko/jobs/2845/

Github merge queue 이제야 보는데 이걸로 Stacked PR(or Diff) 할수있다고 한 사람 누구야? 관계없잖아...

LLM을 적절하게 팀에 도입하는 방법을 모르겠다. (특히 주니어의) 학습과 단련을 위해 LLM을 의도적으로 배제해야 할 필요도 있을텐데... 하지만 LLM 도구를 사용하는 것도 추구해야 할 학습과 단련의 범주에 포함됨.

한편 새로 도입된 QuickJS라는 경량 JS 엔진은... ffmpeg과 qemu로 유명한 Fabrice Bellard 씨 작품… 진짜 뭐 이런 사람이 다 있지???

Nginx의 njs에 QuickJS 엔진 추가되니 기능이나 문법 제약도 거의 없어서 출근해서 해볼 성능 테스트만 제대로 되면 좀 복잡한 로직 필요한 리버스 프록시는 이걸로만 짤거같음. JS모듈들 대충 번들로 만들고 import해서 다 쓸수 있어서...

AI에 대한 SW 엔지니어들의 자신감은 "어쨌거나 업계 내에서 만드는거라서-" 인거 같다. 손바닥 위에 있다는 감각(얼추 맞긴 하다).

타 직업군은 AI나 LLM 솔루션 자체를 다루는데도 한계가 있거니와(아무래도 fork떠서 고친다거나 할순 없으니까) 결과물도 자기 의사와 관계 없이 학습당하고 있기 때문에…

아예 거스를 수 없는 것이기 때문에, 타 분야에서는 오히려 공격적으로 자기 분야에 특화된 모델을 만들고, 기존 저작물들을 학습으로 부터 보호해서 우선권을 선점 하는게 그나마 좀 더 낫지 않을까?

근데 후자는… 테크기업이 양아치라서 잘 안될거같다.

아무래도 Github Copilot 잘 안쓰게 되는게 사람말이 가장 어려워서인거 같다

개인적으로는 k8s쓰는 가장 큰 이유는 개발자 복지라고 생각한다. 적정기술만 쓰면 대부분의 사람들은 뭔가를 실 서비스에서 경험할 기회를 잃어버린다. 아니 이건 됐고…

온프레미스 클러스터 오퍼레이션 부담이나 EKS같은 서비스의 사용료 걱정만 없다면 쓰는게 무조건 낫다고 생각한다.

일단 k8s뿐만 아니라 컨테이너/머신 오케스트레이션의 세계에서 앱과 머신은 좀 더 잘 죽어도되는 존재가 된다. (물론 stateful한 호스트와 앱을 최대한 stateless하게 하거나, 상태를 분리하여 격리시켜야 하긴 한다)

그러면 docker-compose로 충분하지 않느냐 말할 사람도 있겠지만 처음에야 docker-compose 쓰는거나 k8s 쓰는거나 그게 그거지만(오히려 k8s가 성가실것이다) 마이그레이션의 때가 오면 난 그걸 감당할 자신이 없다.

물론 자신만의 가볍고 쏙 맘에드는 솔루션을 고집할 사람도 있을텐데… 난 남들이 다 쓰는거 쓰는게 편하다.

v1의 구현방식이 매력적이었는데 한계로 인해 결국 v2의 방식을 택하게된게 참 아쉬웠다…

RE: https://hl.pkgu.net/@pkgupdt/019627a1-2be1-763a-90e2-1e10ce1df445

AI한테 코딩을 왜 시킵니까? 팀원들한테 JIRA 이슈 배분하면 되는데... ㅠㅠ