This month I Learned - 2020년 9월2020/09/30

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

• GitHub - type-challenges/type-challenges: Collection of TypeScript type challenges with online judge

  • 기초적인 것 부터 약간 난이도 있는 것 까지 다양한 타입스크립트 타입을 만들어보는 연습 문제 모음집.

Frontend

• 모두를 위한 디자인 - 항공사 ARIA 적용사례

  • 내가 주로 작업하는 내용이 ‘당장 접근성이 치명적으로 적용되지 않아도 되니까’ 라고 안일하게 생각하고 있기엔, 언제든지 접근성에 대해 일정 수준 이상의 지식을 쌓아두고 새로운 UI를 개발할 때 접근성을 항상 염두에 두어야 한다고 생각하고 있다.
  • 스크랩 해놓은 영상들이 몇 있긴 하지만, 역시 글로 정리되어있는 것이 접근하기 훨씬 쉽게 느껴진다. 웹북은 항공사의 적용 사례를 통해 웹 애플리케이션에 어떤 방식으로 접근성을 준수하게 만들 수 있는지 알 수 있다.
  • 시간이 없다면 ‘접근성 주요 개선 항목’ 부분을 읽어보면 될 것이다. W3C의 ARIA 쪽 문서를 읽는 것 보다 훨씬 쉽게 접근이 가능해서 좋았다.
  • 물론 이 책의 내용은 항공사를 예로 들고 있기 때문에 접근성 측면에서 개발하고 있는 도메인에 더 신경써주어야 하는 부분이 있다면 추가로 더 공부를 하고 적용해야 할 것이다.

• 모달 라우팅 예시

  • 김혜성님의 트윗을 보다가 모달과 라우팅이 어떻게 엮여야 하는지 전혀 생각을 해본 적이 없다는 것을 꺠달았다.
  • 특히 링크의 예제처럼 모달 안에서 네비게이션을 할 수 있는데도 불구하고, 만약 실수로 뒤로가기를 하면 모달이 없는 상태로 이전 페이지가 뜨는 형태가 그닥 아름답진 않다고 생각하고 있었다. 물론 상황에 따라서는 모달이 닫혀야 하는게 옳을 수도 있겠지만.
  • 예시 사이트는 꽤 예전에 만들어진 것이라 그런지 Case Study 글에서는 모달 라우팅에 대해 깊게 알아보기는 어려웠지만, 현재도 잘 유지되고 있는 gatsby-plugin-modal-routing 플러그인에서 약간의 힌트를 얻을 수는 있었다.
  • History API에서 state 객체도 활용해가며 해야 브라우저 히스토리가 변경되어도 모달이 표시되는 상태를 유지할 수 있을 것 같다.

React

• GitHub - kitten/use-editable: A small React hook to turn elements into fully renderable & editable content surfaces, like code editors, using contenteditable (and magic)

  • contenteditable 을 어떤 방식으로 활용하는것일까? 하고 궁금해서 살펴보았는데 생각보다 코드의 양이 아주 짧진 않아서 놀랐다. 리액트의 엘리먼트로서 랜더링 가능하게 컨트롤하도록 만드는것도 쉬운 것은 아닌가보다.

  • 저 코드를 통해 조금이나마 배우게 된 것은 대강 아래와 같다.

    • 하나의 재사용 가능한 훅을 만들 때 어떤 방식으로 라이브러리화 할 수 있는지
    • 어떻게 현재 선택된 것을 range로 잡아내고 컨트롤할 수 있을지
    • MutationObserver 를 여기서 어떻게 활용하였는지
    • 엘리먼트의 contenteditable 속성을 달고 필요한 이벤트들은 무엇이 있을지
    • 그리고 그 많은 이벤트를 어떻게 하나의 거대한 useLayoutEffect 안에서 선언하고 바인딩했는지

OSS

• Stitches

  • styled-components, emotion 같은 CSS-in-JS 라이브러리부터 시작하여 이젠 zero runtime을 표방하는 CSS-in-JS 라이브러리들이 많이 등장했다. 예를 들면 linaria 같은 것 말이다.
  • 이 라이브러리도 가볍고 빠른 스타일링 라이브러리를 표방하였고 여기에 더해 더 나은 개발자 경험까지 제공한다고 말하고 있다.
  • 흥미로운 것은 컴포넌트의 재사용성 강화를 위해 variant, token 등의 API를 제공하고 있는데, 이 요소들이 타입스크립트와 잘 맞아떨어져서 별로 문제 없이 자동완성의 혜택을 받을 수 있다는 점이다.

Tools

• Recordia | Sindre Sorhus

  • 맥의 메뉴바에서 빠르게 음성 녹음을 할 수 있게 만들어주는 유틸리티.

• 노션 심플 OKRs 템플릿 만들기

  • 지난 달에 소개한 적 있는 ‘노션으로 일잘러 되기 프로젝트’ 모음집의 일부이다.
  • OKR이라는 개념에 대해 ‘그러려니’ 하고 들어온 정도이지만 어떻게 작성할 수 있을까 드문드문 궁금해하던 차에 이 글을 참고하여 개인용 OKR을 작성해볼 수 있겠다는 생각이 들었다.

• RemNote - 공부하고 글쓰는 사람을 위한 강력한 노트 도구 : SEOULRAIN

  • Workflowy 전도사(?)로 인지하고 있는 서울비님이 공유해주신 RemNote 소개글.
  • 소개글이라지만 아주 긴 안내서나 다름없이 사용법과 장단점을 잘 분석해주셨다. 양방향 링크 등을 지원함에도 불구하고 RoamResearch 같은 유료 도구에 비해 계속 무료로 지원한다는 것이 매력적인 포인트 중 하나지만, 다루기 아주 어려워 보인다.

• GitHub - drgrib/alfred-bear: Streamlined note searching and creation for Bear using Alfred

  • 원래 Bear 앱용 알프레드 워크플로우가 있긴 한데, 그건 파이썬으로 작성되어있었다.
  • 성능 및 일부 기능에 아쉬움을 느낀 한 사용자가 Go로 작성하여 새로운 워크플로우를 만들었다. 태그 검색 및 추가 생성 등 여러모로 유용한 기능을 많이 제공한다. Bear + Alfred 사용자라면 두 번 추천.

• GitHub - jsumners/alfred-emoji: Alfred workflow for searching and copying emoji

  • 알프레드로 쉽게 이모지를 입력하기 위해 예전에는 Snippet 기능을 이용하여 입력하는 팩을 이용했다. 충분히 괜찮은 기능을 제공했지만, 뭔가 원하는걸 찾는데 자잘한 어려움이 있었다.
  • 그런데 이 워크플로우가 나에게는 원하는 이모지를 손쉽게 입력하는데 더 많은 도움이 되어서 마음 편히 갈아탈 수 있었다. 심지어 환경 변수 설정으로 이모지의 피부색까지 정할 수 있는 꺠알같은 기능까지 가지고 있다.