2023.12.18
- 그 피드백과 프레셔 덕분에 정신 차리고 개발 공부를 열심히 하게 되었다는 이야기를 들은적이 없다... 혹독한 조언, 절벽으로 몰아세우는 듯한 강한 프레셔에 그동안 굉장히 환상을 갖고 있던게 아닐까 하는 것이였다.
- 코칭을 하면서 이런 환상을 갖고 있는 사람을 종종 보게 됩니다. 뭔가 자신의 잘못된 점을 공격 받아야 나에게 실제로 도움되는 걸 했다는 느낌을 받는 것.
- 쓰다고 꼭 몸에 좋은 것은 아니라는 것, 또 그걸 통한 폭력성을 정당화하는 것을 경계해야 한다.
- 물론 이 글이, 동료들이 잘못된 방향으로 가는 것에 대해 전혀 피드백을 하지 말라는 것은 아니다.
피드백과 조언을 할 때 진짜 그 사람을 변화시키고 싶은 것인지, 단순히 내 화를 못이겨서 상대에 대한 존중없이 그냥 내뱉기만 하는 것인지 구분할 필요가 있다는 것이다. - 진짜 그 사람을 변화시키고 싶다면, 본인이 할 수 있는 가장 혹독한 조언을 하기 보다는 피드백, 변화 등에 대한 제대로 된 학습을 하고 이를 기반으로 피드백 해야한다. 피드백도 공부가 필요하다.(이너게임)
- 그리고 내 경험상 가장 동료들을 변화시키는데 큰 효과가 있던 것은 모범을 보이는 것이다.
- 동료들이 닮고 싶은 롤모델이 되어 보자.
2023.12.16
초기 제품 개발에 MVP가 아닌 MVT를 먼저 해야하는 이유
- MVP와 MVT를 비교하여 설명하고 있다.
- MVT: Minimum Viable Test - 최소 실행 가능 테스트
2023.12.13
- Toss에서 킥보드 빌리기 서비스를 런칭하면서 했던 고민과 선택에 대해 설명한 글입니다.
- 개발자 입장에선 없애도 괜찮을까(여기 없어요, 고장 신고 등)? 싶은 기능들을 과감히 제거하는 것을 보며, 심지어 사용자는 없어진지도 모른다는 게 신기하고 약간 우려되기도 합니다.
- 항상 고객이 원하는 것을, 고객 이상으로 파악해야한다는게 중요한 것 같습니다.
- 기능에 대한 설명 Label이 아닌, 기대 동작에 대한 설명 Label이 인상 깊었습니다.
- 처음 리더 Role을 수행할 때, 위임하는 것에 대해 얘기하고 있습니다.
- 언제나와같이 하는 것보다 잘 하는게 중요하다
- 성장을 위한 목표치: 100% ~ 130%
- 적절한 비율: 70% ~ 100% 업무와 100% ~ 130%
- 개인별로 130%라는 수치는 유동적으로 변화하기 때문에 지속적으로 관찰/분석해야한다.
모니터링은 마틴 파울러처럼: Domain-Oriented Observability 도입기
- 우선은 모니터링에 방법론이 있다는걸 인지하는 정도로만 생각
2023.12.11
- DI에 대한 간단한 설명
- 객체가 잃는 것
- 객체
- 객체 생애 관리
- 개발자가 얻는 것
- 객체 합성
- 객체 생애 관리
- 가로채기
- 객체가 잃는 것
- 목표를 위해 분석하고 시도한 내용을 잘 풀어 설명하였습니다.
- Redis Cache, Kotlin CacheManager etc
2023.12.10
처음 리더가 된 사람들을 위한 조언 by 전 메타(META) 수석팀장
- 팀장과 시니어의 길
- 팀원들이 더 쉽게 다가올 수 있도록, 부족함을 보여주기
2023.12.04
- 여러 디자인 시스템을 모아놓은 사이트입니다.
- 특정 컴포넌트에 대한 여러 라이브러리의 예시를 모아놓은 사이트입니다.
기획자/디자이너와 개발자: 왜 우리는 사이 좋게 지낼 수 없는 건가요?
- 기획자/디자이너 사이에 소통에 대한 관점을 설명하고 있다.
- 여러 멘토링을 경험한 화자의 2023년 회고록
- 열심히 사시는 분들이 많구나 하는 생각
- 객체로 전달될 수 있는 인자에서, 1차원으로 인자가 너무 많은 경우 발생하는 케이스에 대한 개선 방향 제시
언행일치하는 VC를 만나 흑자 전환에 성공한 패피스 이야기
- 첫 스타트업을 진행하면서 이태양 그로스 파트너 라는 분을 만나 어떤 점들을 고민하고 개선해나갔는지 소개
- 마케팅을 중단하니 처음으로 지표가 처음으로 돌아왔다는게 충격적이었다.
[번역] 새로운 리액트 문서에서 제시하는 9가지 권장 사항
- 재밌는 가이드들이 있습니다.
2023.11.25
집 oneTab에 너무 오래 묵혔던 문서를 꺼내 보았다.
How to handle emojis in Nodejs
- emoji에 대한 처리를 재밌게 설명해주었다.
Conditional CSS with :has and :nth-last-child
- 생각보다 많은 걸 해줄 수 있는 우리의 CSS
- has와 nth-last-child 그리고 grid를 활용한 여러가지 사용예를 설명하고 있다.
Messenger Desktop: Faster and Smaller by moving to React Native from Electron
- meta에서 RN과 Electron을 비교한 글
Shared autofill across iframes: an initial proposal
- chrome for developer는 처음 본것 같은데 재밌는 proposal이 오고 가는 것 같다.
2023.11.24
집 oneTab에 너무 오래 묵혔던 문서를 꺼내 보았다.
- 탐구하는 사람에 대해 좀 더 고민해본 글
- 글쓰기 위한 좋은 가이드
- TDD에 대해서 단순한 테스트를 먼저 작성하는 것이 아닌 실제로 주도하려면 어떻게 진행해야하는지 설명하고 있다.
2023.11.21
[Korean FE Article] 리액트, 널 사랑하지만 넌 나를 슬프게 해
- 리액트에서 아쉬웠던 점을 속 시원하게 얘기해주는 문서이다!
- 그럼에도 불구하고 아직 고쳐지지 않는 데에는 의도된 설계이거나, 구조적 제약이 있는 것일까 생각된다.
2023.11.02
- 캐시에 대한 너무나 좋은 문서다
2023.10.30
API 문서화, TS 타입만 있으면 해결! – Tspec
- TypeScript Type을 활용한 OPEN API Spec
2023.09.10
- MSA 환경에서 일어나는 일부 API 실패 시 정책에 대해 사고한 글
마이크로서비스 아키텍처를 구성하는 핵심 요소 8가지 | 무조건 MSA가 정답일까?
- MSA 도입 시 고려해야할 8가지 요소
Distributed transaction patterns for microservices compared
- MSA에서 데이터를 저장하기 위한 여러 패턴
- 테스팅에 대한 여러 개의 글을 소개하는 포스트
2023.08.27
four-eras-of-javascript-frameworks
- Web Client 개발의 기나긴 역사를 4 시기로 나누어 살펴보기
- JS를 더 빠르게 실행시키기 위한 V8의 노력!
Understanding React Concurrency
2023.07.04
2023.07.03
- focus-visible 등 관련된 다양한 예제들
- label과 input의 관계는 형제가 더 접근성에 맞다고 하지만, 자식 관계의 편리성은 참지 못합니다.
- Prevent validation in the middle of user input
- 좀 더 똑똑해진 invalid 계열 속성
2023.06.11
RSC From Scratch. Part 1: Server Components
- RSC를 설명하기 위해, 간단하지만 명료한 코드와 함께 컴포넌트 렌더링부터 차근차근 설명해주는 훌륭한 글
2023.05.10
- 오래전에 갈무리해뒀다가, 늦게 다시 보았습니다만, 현재 FE 개발자들, 또는 JavaScript 개발자들이 처한 상황에 고민을 잘 얘기한 것 같습니다.
2023.04.10
- node project의 dependency를 시각화할 수 있는 라이브러리 입니다.
- 사용 전입니다.
2023.01.31
2023.01.29
2023.01.15
- class-free 프로토타입 기반 OOP
2023.01.12
- JavaScript란...
2023.01.10
(번역) 블로그 답변: React 렌더링 동작에 대한 (거의) 완벽한 가이드
- 리액트팀은 최근 몇 년간 "가상 DOM"이라는 용어를 멀리했습니다. Dan Abramov는 다음과 같이 말했습니다. ... 리액트는 "값 UI"입니다. 그것의 핵심 원칙은 UI가 문자열이나 배열과 마찬가지로 값이라는 것입니다. 변수에 저장하고, 전달하고, 자바스크립트 제어 흐름에서 사용할 수 있습니다. 그 표현가능함이 요점입니다.
- 새로운 리액트 문서는 "전부 메모해야하나요?"라는 질문에 대해 다루고 있습니다.
memo로 최적화하는 것은 컴포넌트가 동일한 props으로 리렌더링 하는 경우가 많고 리렌더링 로직의 비용이 큰 경우에만 가치가 있습니다. 컴포넌트가 리렌더링될 때 지각할 수 있는 지연이 없다면 memo가 필요하지 않습니다. 렌더링중 정의된 객체나 일반 함수를 전달하는 경우와 같이 컴포넌트에 전달하는 props가 항상 다른 경우 memo는 전혀 소용이 없습니다. 따라서 useMemo와 useCallback을 memo와 함께 사용해야하는 경우가 많습니다.
이외의 경우는 컴포넌트를 memo로 래핑해도 아무런 이점이 없습니다. 하지만 그렇게 해도 크게 문제는 되지 않기 때문에 어떤 팀들은 개별적으로 생각하지 않고 가능한 한 많이 메모이제이션하는 것을 선택하기도 합니다. 이 접근 방식의 단점은 코드를 읽기 어려워진다는 것입니다. 또한 모든 메모이제이션이 효과적이지도 않습니다. "항상 새로운" 단일 값은 전체 컴포넌트에 대한 메모이제이션을 무너뜨리기에 충분합니다. - Sophie Alpert는 다음과 같이 말했습니다.
컨텍스트 공급자 바로 아래에 있는 리액트 컴포넌트는 React.memo를 사용해야합니다.
2023.01.01
- 차마 공식문서는 안 읽었는데, 잘 정리된 글이 있어 살펴보았다.
- 댓글에 한글 폰트 로딩을 위한 자신의 포스트를 소개하는 댓글이 있어 살펴보았다. 이 정도 노력을 하는구나 싶다.
