(번역) 데이터 구조를 개선하여 코드 43% 줄이기 : 43% Less Code With A Better Data Structure의 번역 글이다. 주니어 개발자가 React 코드의 코드 리뷰를 요청해서 이를 개선하는 과정이 나와 있다. 체크 리스트에서 전체 선택과 해제를 할 수 있는 코드인데 잘 동작하지만 데이터 구조의 문제와 다른 상태에서 생성할 수 있는 값을 저장해 두는 문제, DOM에 직접 접근하는 문제를 짚어내고 하나씩 개선해나가면서 이전 코드와 개선된 코드를 비교해서 설명해 주고 있다. 어떤 식으로 React 코드를 개선할 수 있는지 명확하게 보여주고 있어서 도움이 되는 글이다.(한국어)
State of CSS 2022 : 매년 실행하는 CSS 생태계를 설문 조사한 결과이다. CSS 프레임워크와 CSS-in-JS 라이브러리의 만족도, 관심도, 사용량, 인지도의 변화를 볼 수 있고 CSS 기능의 비호환성이나 필요한 기능의 통계를 볼 수 있다. 완벽하진 않지만, 한국어로 번역되어 있어서 더 쉽게 볼 수 있다.(한국어)
그 밖의 개발 관련
검증하지 말고 파싱하라 : Alexis King의 Parse, don’t validate의 번역 글로 평소 타입 주도 설계를 설명하는데 고생하다가 "검증하지 말고 파싱하라"는 것을 깨닫고 이를 설명하는 글이다. 함수를 작성할 때 입력의 어떤 조건을 검증하는 경우 잘못하면 호출자에게 검증의 책임을 떠넘기게 되어 코드가 복잡해질 수 있는데 이를 인자 타입을 강화시켜서 훨씬 간결하게 구현하는 방법을 설명한다. 이를 탕해 타입 시스템을 충분히 활용해서 검증으로 인한 샷건 파싱 문제를 피할 수 있다고 하고 있다. 예제 코드가 전부 Haskell이라서 Haskell을 알지 못하고 이해가 어려운데 다행히 급하게 배우는 Haskell ("검증하지 말고 파싱하라" 보충)에 글을 읽는 데 도움이 되는 간단한 문법 설명이 있으므로 이를 먼저 읽어보면 좋다.(한국어)
AI assisted learning: Learning Rust with ChatGPT, Copilot and Advent of Code : Rust를 공부하려고 Advent of Code의 문제를 풀면서 GitHub Copilot과 ChatGPT의 도움을 받아서 Rust를 공부하는 과정을 정리한 글이다. ChatGPT를 이용해서 모든 라인을 설명하는 주석을 추가하고 Rust 컴파일러 오류를 설명하고 수정하게 하고 ChatGPT에게 Rust의 사용 방법을 물어보면서 Rust를 배웠다고 한다. 물론 꽤 잘 동작했지만 두 AI가 잘못된 부분을 알려주기도 해서 디버깅하느라고 시간을 쓰기도 했지만, 지금까지는 Rust를 배우는 데 도움이 되고 있다고 한다.(영어)
피쳐 토글 - 빠르고 안정적인 릴리즈를 향한 도약 : 맘시터에서 Unleash라는 서비스를 이용해서 피처 토클을 사용한 경험을 공유한 글이다. 피처 토글을 이용하면 배포와 릴리즈를 분리해서 코드는 배포하더라도 사용자에게 기능을 오픈하는 시기를 별도로 제어할 수 있어서 릴리스를 세밀하게 제어할 수 있다. 또한 큰 변경 작업을 메인 브랜치에 계속 통합하면서도 기능 오픈은 안 하도록 제어할 수 있다. 맘시터에서는 Unleash 서비스를 이용해서 오픈후 문제 있을 때 바로 해당 기능을 끈다거나 원하는 타이밍에 오픈한다거나 테스트 하는 등 실제로 사용하는 사례가 정리되어 있다.(한국어)
GitHub Actions workflow notifications in Slack and Microsoft Teams : Slack과 Microsoft Teams의 GitHub 앱을 통해 GitHub Actions의 워크플로우의 알림도 받을 수 있게 되었다. /github subscribe owner/repo workflows 명령어로 알림을 구독할 수 있고 /github subscribe owner/repo workflows:{name:"your workflow name" event:"workflow event" branch:"branch name" actor:"actor name"}같은 식으로 워크플로를 필터링해서 구독할 수 있다.(영어)
인프라 관련
A complete guide to managing Grafana as code: tools, tips, and tricks : Grafana 대시보드를 코드로 관리하는 다양한 도구를 소개한다. Grafana Terraform 프로바이더나 Ansible 컬렉션은 Terraform이나 Ansible에는 익숙하지만 Grafana에는 아직 익숙지 않은 사람에게 권한다. Grizzly은 Grafana 리소스를 YAML로 정의해서 관리할 수 있는 CLI로 Grafonnet을 사용한 Jsonnet도 사용할 수 있고 Grafana Crossplane 프로바이더나 Kuberentes Grafana 오퍼레이터를 이용해서 Kubernetes에서 Grafana 대시보드를 관리할 수도 있다.(영어)
Experiment: The hidden costs of waiting on slow build times : 개발자에게 더 강력한 하드웨어를 물으면 항상 그렇다고 대답하는데 GitHub에서 실제 더 강력한 하드웨어를 사용했을 때 비용이 어느 정도인지 알기 위한 실험을 했다. Linux 커널을 컴파일하는 프로젝트를 대상으로 2 코어에서 64코어로 빌드해서 얼마나 많은 시간이 절약되었는지 살펴보고 이 시간이 비즈니스 비용이 얼마나 되는지를 찾았다. 미국 개발자의 평균 비용으로 시간당 75달러를 기준으로 빌드 중에 다른 일은 하지 않는다고 계산하면 코어가 늘어나면 빌드 시간이 많이 감소하므로 개발자 비용도 많이 감소하게 된다. 두 번째 실험에서는 빌드 동안 기다리는 대신 다른 작업을 한다고 가정하면 결국 컨텍스트 스위칭이 일어나는데 컨텍스트 스위칭에 1시간이 걸린다고 가정하면 빌드 시간이 큰 의미 없어지지만 15분, 30분이라고 생각하면 빌드시간을 줄이는 데 드는 비용이 개발자 비용보다 훨씬 적기 때문에 강력한 하드웨어를 쓰는 게 타당함을 보여준다.(영어)
Comments