This month I Learned - 2020년 9월
General
- MS에서 제공하는 인체공학 백서
- 나는 자세가 좀 불편하면 오래 일하기 어렵다 보니, 인체공학에 대한 관심이 조금 있는 편이다.
- 책상 높이라던가, 키보드 자세 등 다양한 요스를 신경 씀에도 불구하고 최근에 왼쪽 손목이 시큰거리길래, 더 개선할만한 부분이 없나 검색을 하다가 우연히 이 문서를 발견하게 되었다.
- 영어라는게 좀 아쉽다만, 대체로 알고 있는 지식도 있었고, 참고하기 좋은 지식도 있었다. 키보드를 놓을 떄의 각도라던가. 보통 키보드가 윗부분 방향이 더 높게 되어있는데, 오히려 손목쪽 부분이 높이가 더 높아지도록 만드는 것도 작업하는데 큰 도움이 된다는 것을 알았다.
- 지금 주력으로 사용하는 해피해킹 외에 마소 인체공학 키보드를 써보고자 하는 욕심도 나긴 했는데, 다음 기회에.
- 하루 25분 실행하기: 하루를 대하는 14년차 개발자의 자세
- 글을 읽어나간 뒤 머리를 한대 맞은 기분이었는데, 작성자분의 전반적인 루틴이 내가 했었던, 그리고 다시 회복하고자 하는 루틴과 아주 비슷했었기 때문이다. 그런데 이 분은 아이까지 키우면서 꾸준히 무언가를 하고 있다.
- ‘가용한 여가시간’ 이라는 것이 나는 분명 이 분보다 훨씬 많을 것이다. 그럼에도 불구하고 무언가 제대로 하루를 보내지 못한 기분을 끌어안고 하루하루를 보내는 이유는 무엇인가? 바로 습관이라는 것이 모두 박살났기 때문이다.
- 하지만 카테고리별(운동, 독서, 개발 등)로 하루 25분이라는 최소한의 시간을 설정하고, 우선순위에 따라 1주일에 몇 번씩 해당 카테고리의 회차를 채우는 방식으로 꾸준히 작은 것부터 실천해나가는 모습을 보면서 많은 영감을 얻었다.
- 개발도 그렇고, 삶을 살아가는 방식도 그렇고, 작은 것 부터 조금씩 쌓아올리는게 아닐까? 어디서부터 어떻게 쌓아올려야할지 차근차근 다시 처음부터 생각해보고자 마음먹었다.
- The Fu Master Productivity Checklist using Things3 - Productive with a Purpose
- 나는 할일 관리 프로그램으로
‘Things 3’ 를 쓰고 있다. 하지만 나에게는 할일 목록으로 등록하여 쓸 만큼 다채로운 할 일이 많다고 생각하지 않았다. 업무는 Jira 태스크 위주로 처리하고 나면 개인의 할 일이라는게 별게 없어 보였기 때문이다. 하지만 아니었다.
- 하루동안 뭘 하긴 한 것 같은데 그닥 남은게 없거나 생산적으로 보내지 못했다고 느낄 때가 많았다. 단순히 할일 관리 프로그램을 쓰는 방법이 문제가 아니고 나 자신의 생산성을 관리하는 체계 자체가 무너졌던 것이다. (아니면 그런 체계가 아예 없었을지도 모른다)
- 그래서 다른 사람들은 이 프로그램을 어떻게 쓰는지 살펴보고, 여기서 힌트를 얻어보자는 생각을 했다. 그러다가 꽤 괜찮은 글을 발견했다. 자신을 믿고 “목적에 따른 생산성 확보” 를 기반으로 하여 어떻게 생산성을 관리하는 ‘프레임워크’ 를 형성해나가는지 안내하는 글이었다. 제목과 같이 사용하는 도구가 Things이긴 하지만, 실제로 어떤 도구라도 이 글에서 제시된 대로 활용할 수 있다고 보기 때문에 좋은 글이라고 생각하고 있다.
- 아래의 항목들이 주요 내용이었고, 글이 조금 길긴 하지만 최대한 핵심적인 부분만 읽어나가면 자신만의 생산성 관리 프레임워크를 형성하는데 도움이 되리라 생각한다.
- Inbox의 중요성
- 하루의 리뷰를 시작하는 모닝 루틴
- 데일리/위클리 리뷰
- 할 일에 불필요하게 기한을 지정하는 것을 피할 것
- 정말 중요하다고 생각하는 것에 집중하게 만드는 체계를 형성하는 것
- Design notes
- 제품 디자이너들을 위한 리소스 모음 사이트
- Pinterest 정도만 알고 있었는데, 리소스를 찾기 위해 이용할 수 있는 사이트가 정말로 다양하게 있다는 것을 알게되어 좋았다.
- 몇 개 살펴보니까 일부 유료인 사이트들도 있다.
Developer
- 수학과 함께하는 AI 기초
- 김지현님의 추천 트윗을 보고 눈여겨보게 되었다. 지난달에도 언급했지만 아직 ML은 관심 밖의 영역이었는데, 조금이라도 이렇게 진입 장벽을 낮추어주고 친숙하게 기본 개념을 익힐 수 있는 자료는 우선적으로 읽고 싶어진다.
(하지만 9월이 끝나가는 지금도 손도 대지 못했다는게 함정)
- 여러분의 CS 교육에서 누락된 학기 · the missing semester of your cs education
- MIT에서 제공하는 자료이며 CS의 고급스런 주제를 학부에서 배울 수 있지만, 실제로 실무 개발을 하는데 유용한 내용을 가르쳐주는 것으로 보인다.
- ”우리는 이 수업을 통해 여러분들 들어봤을 법한 도구를 활용하는 방법을 가르치고, 쓸만한 도구들을 소개하고, 당신이 스스로 더 많은 도구를 탐구하고(무언가를 만들거나!) 관심을 가지길 바랍니다. 이 지식들은 통상적인 컴퓨터 공학 수업에서는 다루지 않을 내용일 것입니다.”
- Bash shell script 가이드
- NAS의 파일 정리를 어느정도 자동화하려고 쉘 스크립트를 작성해보려 하니 더듬더듬 찾아보아야 할 것이 너무 많았다. 하지만 여기에 내가 필요한 정보가 다 있었다.
- 근데 막상 이 가이드를 읽어가며 더듬더듬 하려고 하는 것 보다 파이썬 스크립트를 짜서 훨씬 쉽게 원하는 자동화를 할 수 있었다는게 씁쓸했다.
- 개앞맵시 기본기 레벨업 | MindMeister
- 본질적으로는 일부 책 홍보이긴 하지만, 개발자로서 읽으면 좋다고 생각하는 책들이 잘 망라되어 있는 마인드 맵이었다.
- 이 링크는 ‘기본기 레벨업’ 을 위해 추천해줄만한 책이고, 마인드맵 줄기에는 각자 세부 분야에 따른 책을 추천하는 마인드 맵이 각각 따로 있다. 예를 들어 웹 개발자를 위한 책 추천 마인드 맵이라던가.
- 몇몇 책은 보는 나나 보는 분들에 따라 안맞는 책들도 있겠지만 읽어봤거나 이름을 들어본 책이 꽤 되는 것으로 보여 꽤 괜찮은 모음이라 생각한다.
- 유용한 테스트 케이스를 위한 개발자의 자세 : TOAST Meetup
- ”(테스트를 하는데) 무엇이 중헌디” 가 결국 이 글에서 이야기하고자 하는 내용이라 생각한다. 내부 구현을 직접적으로 테스트하는 것을 피해야 하고 왜 그렇게 해야하는지 설명한다.
- TC(테스트 케이스)는 바뀔 수 있는 모듈의 구체적인 것에 의존하면 안된다. 추상화된 것에 의존해야 한다.
- 그럼에도 불구하고 내부 구현이 테스트되어야 한다고 생각되는 모듈이 있다면, 해당 내부 구현이 독립된 책임을 갖는 별도의 모듈로 추출되어야 할 수도 있다는 뜻이다.
- 유용한(비용 효율적인) TC는 현재를 위해 TC를 작성하되 개발이 진행되면서 미래를 위한 TC로 바뀔 수 있는 것들이다.
- 테스트 자동화를 도입했다면 모듈과 마찬가지로 TC도 지속적으로 개선하고 리팩토링해야 한다. TC는 모듈을 테스트하는 모듈이다. 우리가 구현한 모듈과 아주 큰 차이는 없다.
- 내부 구현을 TC가 직접적으로 테스트하기보다 공개된 인터페이스를 이용하여 테스트하는 것을 권장한다. 물론 내부 구현을 직접 테스트하는게 더 쉬울 수 있지만, 정말 내부 구현을 테스트하여 커버리지를 올리는게 우리가 달성하고자 하는 목표인가? 아니면 공개된 인터페이스가 정상적으로 잘 동작하여 사용자가 사용을 하는데 이상이 없게 하는게 목표인가?
- 정말 ‘도움이 되는 테스트’여야만 도움이 되는 것이다. ‘도움이 될 것 같은’ 테스트는 오히려 독이 될 수도 있다.
JS / TS
Frontend
- 모두를 위한 디자인 - 항공사 ARIA 적용사례
- 내가 주로 작업하는 내용이 ‘당장 접근성이 치명적으로 적용되지 않아도 되니까’ 라고 안일하게 생각하고 있기엔, 언제든지 접근성에 대해 일정 수준 이상의 지식을 쌓아두고 새로운 UI를 개발할 때 접근성을 항상 염두에 두어야 한다고 생각하고 있다.
- 스크랩 해놓은 영상들이 몇 있긴 하지만, 역시 글로 정리되어있는 것이 접근하기 훨씬 쉽게 느껴진다. 웹북은 항공사의 적용 사례를 통해 웹 애플리케이션에 어떤 방식으로 접근성을 준수하게 만들 수 있는지 알 수 있다.
- 시간이 없다면 ‘접근성 주요 개선 항목’ 부분을 읽어보면 될 것이다. W3C의 ARIA 쪽 문서를 읽는 것 보다 훨씬 쉽게 접근이 가능해서 좋았다.
- 물론 이 책의 내용은 항공사를 예로 들고 있기 때문에 접근성 측면에서 개발하고 있는 도메인에 더 신경써주어야 하는 부분이 있다면 추가로 더 공부를 하고 적용해야 할 것이다.
- 모달 라우팅 예시
- 김혜성님의 트윗을 보다가 모달과 라우팅이 어떻게 엮여야 하는지 전혀 생각을 해본 적이 없다는 것을 꺠달았다.
- 특히 링크의 예제처럼 모달 안에서 네비게이션을 할 수 있는데도 불구하고, 만약 실수로 뒤로가기를 하면 모달이 없는 상태로 이전 페이지가 뜨는 형태가 그닥 아름답진 않다고 생각하고 있었다. 물론 상황에 따라서는 모달이 닫혀야 하는게 옳을 수도 있겠지만.
- 예시 사이트는 꽤 예전에 만들어진 것이라 그런지 Case Study 글에서는 모달 라우팅에 대해 깊게 알아보기는 어려웠지만, 현재도 잘 유지되고 있는 gatsby-plugin-modal-routing 플러그인에서 약간의 힌트를 얻을 수는 있었다.
- History API에서 state 객체도 활용해가며 해야 브라우저 히스토리가 변경되어도 모달이 표시되는 상태를 유지할 수 있을 것 같다.
React
OSS
- Stitches
styled-components, emotion 같은 CSS-in-JS 라이브러리부터 시작하여 이젠 zero runtime을 표방하는 CSS-in-JS 라이브러리들이 많이 등장했다. 예를 들면 linaria 같은 것 말이다.- 이 라이브러리도 가볍고 빠른 스타일링 라이브러리를 표방하였고 여기에 더해 더 나은 개발자 경험까지 제공한다고 말하고 있다.
- 흥미로운 것은 컴포넌트의 재사용성 강화를 위해 variant, token 등의 API를 제공하고 있는데, 이 요소들이 타입스크립트와 잘 맞아떨어져서 별로 문제 없이 자동완성의 혜택을 받을 수 있다는 점이다.