Why is modern web development so complicated? A long yet hasty explanation: Part 1! : 현대 웹 개발도구가 상당히 복잡한데 왜 이렇게 복잡해졌는지의 과정을 설명하는 글이다. 모든 도구는 해결하는 문제가 있어서 그 문제점을 이해해야 도구를 이해하고 있다고 설명하면서 지금과 달리 과거에는 JavaScript의 한계가 명확했고 웹 API와의 차이점이 있었기 때문에 jQuery가 오랫동안 이 문제를 해결하였고 그사이에 ECMAScript가 발전했지만 모든 브라우저에서 같은 JavaScript 기능을 지원하지 않았기 때문에 모던 자바스크립트로 코딩하고 싶은 개발자를 위해서 Babel이 등장한 과정까지 설명하고 있다. 이미 복잡한 도구들만 접해서 사용해본 개발자들에게도 많은 도움이 될 것 같다.(영어)
2019년과 이후 JavaScript의 동향 - 라이브러리와 프레임워크 1, 2 : Angular, React, Vue,js, Web Component, TypeScript, Svelte, Preact 등 대표적인 프레임워크와 라이브러리의 프로젝트 진행 상황과 최근에 추가된 기능 및 향후 계획 등을 정리한 글이다. 모든 프로젝트를 살펴보기가 어려운데 꽤 자세하게 정리되어 있어서 각 프로젝트의 상황을 살펴볼 수 있다.(한국어)
How I side project : 사이드 프로젝트를 어떻게 진행하는지 설명하는 글이다. 작업하면서 생각난 아이디어 중 일부만 실제로 작업을 하게 되는데 아이디어가 생겼을 때가 가장 동기부여가 높을 때가 바로 작업을 시작해서 간단한 프로토타입을 만든다고 한다. 작업 흐름에 방해되는 걸 막기 위해서 익숙한 도구를 항상 반복해서 쓰고 작업하는 내용을 계속해서 공유하면서 작업한다고 한다.(영어)
When a rewrite isn’t: rebuilding Slack on the desktop : Slack이 오래된 데스크톱 앱을 새로운 코드 베이스로 바꾸는 과정을 설명한 글이다. 2012년과는 많이 달라졌으므로 레거시 앱은 DOM을 직접 조작하고 데이터 로딩을 초기에 많이 하면서 워크스페이스마다 프로세스를 띄웠는데 앞의 두 문제는 계속 개선하고 있었지만 워크스페이스 문제는 설계부터 바꿔야 하므로 쉽지 않은 문제였다. 오래된 코드 안에서 새로운 코드를 바꿔가면서 둘을 연결하는 방식으로 개선해 가면서 새로운 코드는 모두 React로 작성하고 데이터는 지연 로딩하면서 한 프로세스에서 여러 워크스페이스를 개선하도록 바꾸기 위해 Redux를 사용했다고 한다. 완전히 새 코드로 전환하려고 몇 가지 규칙을 정해서 개발했으면 완전히 바꾼 뒤에는 워크스페이스가 많아져도 메모리가 많이 늘지 않는 것을 볼 수 있다.(영어)
갈피: 나의 첫 모바일 앱 개발기 : Flutter로 첫 모바일 앱을 올려서 배포한 사이드 프로젝트 경험을 정리한 글이다. 본인이 필요로 하던 독후감 앱을 만들기로 하고 React Native로 앱을 만드는 데 불편을 느껴 처음 써보는 Flutter로 앱을 만들어서 앱스토어에 배포까지 했다. 처음 Dart 언어와 Flutter를 쓰면서 느낀 장단점도 정리되어 있다.(한국어)
로우 레벨로 살펴보는 Node.js 이벤트 루프 : Node.js event loop workflow & lifecycle in low level의 번역 글로 Node.js의 이벤트 루프가 어떻게 동작하는지 설명하고 있다. 이벤트 루프의 구조를 간략하게 설명한 글 때문에 오히려 오해가 많이 쌓였기 때문에 이 글에서 이벤트 루프가 어떤 식으로 동작하는지를 설명하고 진행되는 각 단계를 자세히 설명한 뒤 setTimeout, setImmediate, process.nextTick을 이용한 예제의 동작을 보여주면서 앞에서 설명한 단계에 따라 어떻게 동작하는지를 보여주는데 잘 나와 있다.(한국어)
더 작은 APK를 위한 Android App Bundle에 대해서 : Android에 새로 추가된 앱 번들을 통해 패키지를 동적으로 나누어 받을 수 있게 됨으로써 안드로이드 앱의 용량을 줄인 과정을 설명하고 있다. 실제로 당근마켓 앱의 용량은 36%가 줄었고 설치된 앱의 크기도 21%가 줄었다고 한다.(한국어)
리젝 없이 iOS 구독앱, 한방에 출시하기 : 앱스토어에서 구독 모델이 포함된 앱을 준비할 때 리젝되지 않도록 구독 상품을 만드는 방법부터 구독에 대한 안내에서 리젝사유가 될 수 있어서 조심해야 할 부분을 정리한 글이다. 이런 내용은 처음 해볼 때는 고생을 많이 해볼 수밖에 없어서 미리 해본 분의 정리된 글은 도움이 많이 된다.(한국어)
대규모 Kubernetes 클러스터 구축기 : Line에서 4,000개의 팟을 Kuberntes로 운영하면서 점점 늘어나는 앱에 대응하기 위해서 대규모 클러스터를 구성한 과정을 설명한 글이다. Caravan이라는 Kuberntes 클러스터 프로비저닝 서비스를 만들기 위해서 처음에는 Rancher를 사용하다가 한계를 느끼고 kuberadm, ansible, CRD를 조합해서 구성했으면 테스틑 위해서 마스터 노드 20개와 워커노트 999개로 테스트를 하였고 여기서 발견된 etcd 등의 문제를 개선했다고 한다. 이정도 규모를 구성할 조직이 많지는 않겠지만 내용만으로도 흥미롭다.(한국어)
볼만한 링크
하지만, 야크 털 깎기는 재미있다 : 자신의 블로그를 직접 만든 경험을 얘기하면서 개발자들 사이에서 야크 털 깎기(Yak shaving)이 어떻게 유래되었고 야크 털 깎기로 TeX가 어떻게 탄생했는지를 설명하고 있다. 적절함이 필요하지만 야크 털 깎기가 재밌고 의미 있다는데 동의한다.(한국어)
한국 해커톤의 한 걸음 정도의 발전을 위한 제언 1/3 : 해외에서 일하시다가 한국에서 해커톤에 멘토로 참여해 보시고 해커톤을 어떻게 하면 더 나은 행사로 만들 수 있을지에 대한 연재글의 첫 글이다. 이 글에서는 단기간에 제품을 만드는 해커톤에서 PM의 역할이 아주 중요하기 때문에 목적을 이해하고 시장 요구사항을 이해하고 상호 간의 경계선과 협력선을 설정하고 MVP 스코프를 결정하고 팀원의 커뮤니케이션을 향상시키고 초기 테스트에 참여하고 우선순위를 갱신하며 팀원을 응원하는 7가지 PM의 기술을 활용하라고 하고 있다. 실제로 이렇게 되면 꽤 의미 있을 것 같고 여기에서 PM의 기술은 확대해서 회사에서도 충분히 의미가 있을 것 같다.(한국어)
테크니컬 라이팅 컨퍼런스: API the Docs Chicago 2019 방문기 : API The Docs 2019에 참여하고 주요 2개의 세션의 내용을 정리한 글이다. 문서화에 관심은 있지만, 항상 맘에 들게는 못 만들곤 하는데 문서화 쪽을 주 업무로 하는 테크니컬 라이터들이 API 문서를 어떻게 생각하는지 볼 수 있고 Ford에서 DocOps로 사내에 API 문서를 개발자들에게 잘 제공하기 위해 노력한 과정이 잘 나와 있다. "많은 회사가 서드파티 개발자 대상 문서에는 집중하고 노력하는 반면, 내부 개발자용 문서에는 그만큼의 노력을 기울이지 않으리라 추측"한다는 부분에 공감이 간다.(한국어)
[플랫폼의 생각법] 우버가 수익을 내기 힘든 몇 가지 이유 : 플랫폼 사업은 안정성을 높고 규모가 커질수록 독점에 이르게 되는 특성이 있지만 우버의 플랫폼은 다른 프로랫폼과는 달리 기사나 승객이 락인될 요소가 없고 네트워크의 규모도 지역적으로 분리되어 규모의 이점을 누리기 어려우며 자율주행도 현재의 핵심인 기사를 퇴출하는 방법인 데다가 연구 결과도 긍정적으로 보기 어렵다고 얘기하고 있다. 이렇게 깊게 생각해 본 적이 없어서 흥미로운 분석이었다.(한국어)
2019년 상반기 회고 : 개발도 잘하시면서 공부랑 공유도 열심히 하시는 이동욱 님의 상반기 회고 글인데 회사와 개인적인 학습, 활동을 너무 열심히 하셔서 글만 봐도 자극될 정도이다.(한국어)
Comments