ziglog

    Search by
    • Home
    • 5월 4주차 기록

    5월 4주차 기록

    May 25, 2024 • ☕️ 7 min read

    배워가기

    맥 로제타

    • 애플 M1 칩셋을 사용하는 맥 컴퓨터에서 x86 아키텍처의 소프트웨어를 실행하기 위한 호환성 도구
    • 즉 M1 맥북에 아직 지원하지 않는 소프트웨어를 사용할 수 있게 해주는 도구

    Ref https://support.apple.com/ko-kr/102527

    dlopen 서브루틴

    • 호출 프로세스에 모듈을 동적으로 로드한다.
    • 공유 라이브러리를 동적으로 로드하는 휴대용 방법이다.

    Ref https://www.ibm.com/docs/ko/aix/7.3?topic=d-dlopen-subroutine

    prettier embeddedLanguageFormatting

    하나의 언어로 쓰인 파일 안에서 다른 언어의 코드가 감지되었을 때 그 코드도 함께 자동으로 포맷팅시켜줄 것인지를 정하는 속성이다. .tsx 파일 안에서 TypeScript와 HTML 태그를 함께 포맷팅할 때 필요한 옵션이다. auto와 off로만 설정 가능하고, 기본값은 auto다.

    Ref https://prettier.io/docs/en/options.html#embedded-language-formatting

    module federation에서 eager consumption

    Module Federation에서 eager consumption은 모듈이 애플리케이션이 시작될 때 미리 로드되는 방식을 의미한다. 이는 런타임 시 동적으로 로드되는 기본 방식과 다르다. 구체적으로 설명하면,

    1. 기본 방식 (Lazy Loading):
    • 기본적으로 Module Federation은 필요한 시점에 모듈을 동적으로 로드한다. 즉, 실제로 모듈이 사용되기 전까지 로드되지 않는다. 이렇게 하면 초기 로딩 시간이 짧아지고, 필요 없는 모듈은 로드되지 않아서 리소스 절약이 가능하다.
    1. Eager Loading (Eager Consumption):
    • eager: true로 설정된 모듈은 애플리케이션 시작 시 바로 로드된다. 이 방식은 초기 로딩 시간이 길어질 수 있지만, 모듈 로드 지연 시간을 없앨 수 있다. 주로 항상 필요한 모듈이나, 초기 로딩 시간에 로드 지연이 문제가 되는 경우에 사용된다.

    출처: ChatGPT

    html <output> 태그

    웹 사이트나 앱에서 계산이나 사용자 행동의 결과를 삽입할 수 있는 컨테이너 요소

    ex) role="spinner" 등을 대체하여 사용된다.

    Ref https://developer.mozilla.org/ko/docs/Web/HTML/Element/output

    jest 리포팅 결과 공유하기

    • jest-html-reporters 을 이용하여 리포팅 결과를 도출하여 public한 환경에 업로드할 수 있다.
    • jest.config 에서 collectCoverage: true로 커버리지율도 확인할 수 있다.
    • 이제 누구나 URL에 접근하여 테스트 현황(리포팅/ 커버리지 결과)을 볼수 있다.

    Resourceful Engineering && Big ball of mud

    Resourceful Engineering은 제한된 자원과 예산 내에서 창의적이고 효율적으로 문제를 해결하는 기술적 접근 방식을 의미한다. 이는 엔지니어들이 가용 자원을 최대한 활용하여 최적의 결과를 도출하는 능력을 강조한다. 자원의 효율적 관리, 혁신적인 문제 해결 방법, 비용 절감 전략 등이 포함된다.

    Resourceful Engineering이라는 용어는 특정 시점이나 인물에 의해 처음 사용되었다고 명확하게 기록된 바는 없다. 그러나 이 개념은 공학 및 IT 분야에서 오랜 기간 동안 널리 적용되어 온 원칙이다. 특히 스타트업 환경이나 제한된 자원 내에서의 프로젝트 관리에서 중요한 역할을 해왔다.

    Big Ball of Mud는 소프트웨어 아키텍처 패턴 중 하나로, 구조화되지 않고 조직적인 원칙이 부족한 코드를 의미한다. 이러한 코드는 시간이 지남에 따라 유지보수와 확장이 어려워지며, 일관성 없이 패치되고 추가된 기능들로 인해 복잡도가 증가한다. 이 패턴은 코드의 악취(Code Smell)로 간주되며, 종종 기술 부채(Technical Debt)를 낳는다.

    Big Ball of Mud라는 용어는 1997년 브라이언 풋(Brian Foote)와 조셉 여더(John Yoder)의 논문 “Big Ball of Mud”에서 처음 제안되었다. 이 논문은 소프트웨어 시스템의 일반적인 문제점을 설명하면서, 그러한 시스템이 어떻게 형성되고 진화하는지, 그리고 왜 많은 소프트웨어 프로젝트가 이러한 비구조적 상태로 변하는지를 다룬다. 논문에서는 Big Ball of Mud가 발생하는 원인과 그로 인한 문제점들을 분석하며, 이러한 상황을 피하기 위한 전략들을 제시한다.

    크롬 브라우저의 prerender

    크롬 검색창에서 자주 들어가는 사이트의 검색어를 타이핑한 후 5초 정도 기다려보자.

    엔터를 누르면 로딩없이 바로 화면이 렌더링될 것이다.

    다시 검색창에서 같은 사이트의 주소를 최대한 빠르게 타이핑한 후 엔터를 눌러보자. 로딩이 있을 것이다.

    이는 크롬브라우저가 자체적으로 prerender해주기때문이다.

    모든 url에 대해서 해주는 것은 아니고 자주 접속하는 사이트에 대해서만 그렇다.

    CF function에서 사용자 IP 확인하기

    cloudfront function에서는 event.viewer.ip를 통해 클라이언트 ip를 확인할 수 있다.

    이를 활용하여 특정 url을 사내에서만 접근 가능하도록 구성할 수 있었다.

    Ref https://us-east-1.console.aws.amazon.com/cloudfront/v3/home?region=us-east-1#/functions/food-order-cdn-redirect?tab=build

    테스팅 피라미드와 테스팅 트로피

    전통적인 테스트 접근법에서는 테스팅 피라미드 모델 단위테스트 > 통합테스트 > E2E테스트의 순서로 우선순위를 정의한다.

    현대 FE 개발에서 테스팅 피라미드 모델은 유효하지 않다. 목적에 따라 서로 다른 테스트 전략을 취하되, 가장 FE 개발 사이클과 유사한 E2E 테스트를 최종 목적으로 삼는 테스팅 트로피 모델을 제안한다.

    Ref https://semaphoreci.com/blog/testing-pyramid

    이것저것 모음집

    • npkill - 프로젝트에 있는 모든 node_modules를 찾아서 삭제해준다.
    • String.prototype.startsWith(), String.prototype.endsWith() - 이라는 좋은 빌트인 메서드가 생겼다.

    기타공유

    ink

    CLI 툴을 React 기반으로 말아내는 프레임워크.

    CLI의 상호작용과 디테일이 어느 수준 이상 깊어지면 생산성이 매우 우수할 것 같다.

    이미 활약하고 있는 도구를 잘 참고한 것을 넘어서, 시스템 인터페이스와 몇가지 기반요소만 싹 바꿔서 완전히 동일한 개발경험을 준다.

    Ref https://github.com/vadimdemedes/ink

    vercel ship

    vercel에서 개최하는, 프론트엔드 개발, 인프라, 에코시스템 등을 다루는 컨퍼런스

    Ref https://vercel.com/ship

    Google Gemini for Workspace

    하이라이트: 프롬프트 최적 길이는 21개 단어(영어)지만 대부분 너무 짧게 (9단어) 씀, 페르소나/태스크/컨텍스트/포맷 네 개 요소 사용 권장

    Ref https://inthecloud.withgoogle.com/gemini-for-google-workspace-prompt-guide/dl-cd.html

    패키지 매니저의 과거, 그리고 미래

    (+ 토스의 선택)

    패키지 매니저가 어떻게 동작하는지는 생각해본 적이 없는 것 같다.

    ex) yarn의 패키지 매니저 설치 과정

    1. Resolution
    • 라이브러리 버전 고정
    • 라이브러리의 다른 의존성 확인
    • 라이브러리의 다른 의존성 버전 고정
    1. Fetch
    • 결정된 버전의 파일을 다운로드 하는 과정
    1. Link
    • Resolution/Fetch 된 라이브러리를 소스 코드에서 사용할 수 있는 환경을 제공하는 과정

    마지막 Link 단계에서, npm/pnpm/PnP의 사례가 각각 다르다.

    • npm Linker

      • package.json에서 명시하는 모든 의존성을 그냥 node_modules 디렉토리 밑에다가 하나하나씩 작성
      • 파일 탐색 시 node_modules를 타고 올라가면서 파일을 읽기 때문에 느리고, 디렉토리 크기가 너무 커지낟.

    • pnpm Linker

      • 기존의 node_modules 디렉토리를 그대로 사용하지만, Hard link 방식을 사용하여 의존성이 디스크에 하나만 설치된다.
      • npm에 비해 속도가 빠르고, node_modules 디렉토리 크기도 작아진다.

    • PnP Linker

      • node_modules가 아닌 JavaScript 객체로 의존성을 처리한다.
      • Node.js 프로세스가 PnP Map을 메모리에 전부 로드하고 import와 require 문에서 이 Map을 참조하여 로딩시킨다.
      • 설치 속도가 빠르고, 패키지를 로드하는 속도도 빠르다.

    원문을 통해 PnP와 zero-install의 차이에 대해서도 짚고 넘어가보자!

    Ref https://toss.tech/article/lightning-talks-package-manager

    마무리

    늘어~~지는게 제일 좋은 이번주.

    아직도 5월의 마지막 주가 아니라니?

    5월 길다 길어 🫠

    Relative Posts:

    5월 5주차 기록

    June 1, 2024

    5월 3주차 기록

    May 18, 2024
    zigsong

    지그의 개발 블로그

    RotateLinkImg-iconRotateLinkImg-iconRotateLinkImg-icon