하리하링웹

지도 타일우리가 흔히 보는 지도는, 사용자가 어떤 줌 레벨에서 지도를 보고 있느냐에 따라 표시해야 하는 정보의 양이 달라진다. 예를 들어,줌 레벨 0에서는 전 세계 지도를 단 1×1, 즉 한 개의 타일로 표현한다.줌 레벨 1에서는 2×2, 즉 4개의 타일로 표현한다.줌 레벨 15인 경우에는 2^15 × 2^15라는 방대한 수의 타일을 갖게 된다. 또한 줌 레벨에 따라 동일한 좌표의 타일이라 하더라도, 실제로 표시해야 하는 정보의 종류나 양이 달라질 수 있다. 예를 들어, 줌 레벨 5에서는 지하철 노선도를 표시하지 않다가, 줌 레벨 6부터는 해당 지하철 정보를 포함하도록 구성할 수 있다. 이는 지도 타일을 어떻게 제작하느냐에 따라 각각 달라진다. 지도 라이브러리의 동작 방식 사용자가 특정 지역을 보고 있을..

개요 VSCode의 GUI를 통한 Git 명령어는 기본적으로 속도가 느린 편이다. 레포지토리 크기가 커질수록 이 문제는 더욱 심해지는데, 이는 모노레포가 갖는 단점 중 하나이다.현재 회사의 코드는 25년 이상 유지되고 있고, 메인 레포지토리는 10GB 이상의 용량과 약 29만 개의 파일로 구성되어 있다. 이렇게 많은 파일이 존재하다 보니 PC 성능에 따라 VSCode GUI를 통한 Git 명령어 실행 시간이 크게 지연되는 문제가 발생하게 되었다.내가 사용하는 PC는 회사에서 가장 성능이 낮은 편이라, 전체 빌드시 생성되는 수만 개의 파일을 UI를 통해 git reset하는 데에만 약 3분이 걸렸으며 GUI명령을 통해 git reset을 실행시에 최대 9999개의 파일만 reset 가능하기에 여러번 실행해..

당근 면접 후기지난해 당근에 지원했던 경험을 공유해보고자 한다. 처음에는 지원 동기가 당근에서 꼭 일해야한다 라는 느낌의 이유보다는 좋은 환경에서 좋은 사람들과 일하며, 개발자로서 어느 정도까지 성장할 수 있을지 시험해보고 싶었고, 또한 '당근'이라는 간판을 통해 훌륭한 개발자로 인정받고 싶은 마음으로 지원하게 되었다. 1차·2차 기술 면접당근의 면접은 총 3차로 진행됐는데, 1·2차는 기술 면접, 3차는 인성(컬쳐 핏) 면접이다. 여러 곳에서 기술 면접을 봐왔지만, 널리 알려져 있는 대로 당근의 기술 면접은 다른 회사들과 확실히 결이 다르다는 느낌을 받았다. 시간 구성 1차 면접: 약 1시간 30분 2차 면접: 약 2시간 일반적인 기술 면접에서는 주로 '이미 갖고 있는 지식을 ..

개요현재 직장에서 puppeteer기반 cypress 문법을 사용하는 e2e 테스트 프레임워크를 개발하고 있는데 알고리즘의 선택인지 우연인지는 모르겠지만 토스에서 비슷한 것을 만들고 발표한 영상이 눈에 들어오게 되었고 관심이 생겨 해당 영상을 꼼꼼히 보고 요약한 내용이다. 테스트 자동화 플랫폼을 만드는 목적이 다 같아서 그런건지 사람 생각이 다 거기서 거기라서 그런건지 cypress, playwright와 같은 타 테스트 프레임워크를 사용하지 않고 puppeteer 기반으로 테스트 프레임워크를 직접 만든다는 큰 차이를 제외하고는 많은 부분의 플랫폼 설계가 비슷하여 좀 신기했다.  e2e 플랫폼을 만든다는 큰 목적을 가지고 구조와 흐름을 설계하게 되면 결국 누가 만들던간에 이런 느낌으로 완성이 되지 않을까..

https://jjongsk.tistory.com/entry/Cypress%EC%9D%98-%EB%8B%A8%EC%A0%90%EC%9D%84-%EA%B7%B9%EB%B3%B5%ED%95%98%EA%B8%B0-%EC%9C%84%ED%95%9C-Puppeteer-%EA%B8%B0%EB%B0%98-%EC%95%84%ED%82%A4%ED%85%8D%EC%B3%90-%EA%B5%AC%ED%98%841 Cypress의 단점을 극복하기 위한 puppeteer 기반의 e2e 테스트 모듈 구현(1)개요 e2e 테스트 라이브러리가 필요하여 cypress에 대해 분석하다가 이를 사용하는 것은 현재 구조에서 불가능하다고 판단하여 puppeteer를 사용하여 e2e 테스트 아키텍쳐를 직접 구현하기로 결정하jjongsk.tist..

개요 e2e 테스트 라이브러리가 필요하여 cypress에 대해 분석하다가 이를 사용하는 것은 현재 구조에서 불가능하다고 판단하여 puppeteer를 사용하여 e2e 테스트 아키텍쳐를 직접 구현하기로 결정하였다. cypress를 사용하는 것이 불가능한 이유는 아래와 같다.cypress의 너무 느린 속도불가능한 유지보수불가능한 병렬처리쉽지않은 커스텀특히 1번 속도 문제가 너무 심각하였다. 하지만 cypress에서 제공하는 테스트 코드 문법, 여러가지 e2e 기능은 충분한 가치가 있었기에 cypress의 특정 기능을 비개발자(qa,qc 등)가 사용할 수 있도록 cypress 인터페이스를 유지하면서 테스트를 실행할 수 있는 솔루션을 만드는게 이번 프로젝트의 핵심 목표이다. cypress의 테스트 코드는 문법은 ..

1편 보러가기https://jjongsk.tistory.com/entry/Bun%EC%9D%84-%EC%82%AC%EC%9A%A9%ED%95%9C-%ED%81%AC%EB%A1%A4%EB%A7%81-%EB%B0%A9%EC%A7%80-%EC%9A%B0%ED%9A%8C (언제 막힐지 모르는)Bun을 사용한 크롤링 방지 우회 방법과 원리(1)Node의 기본 fetch를 사용하여 크롤링을 시도할 경우 요청이 차단되는 경우가 있다. 대표적으로 네이버의 검색이나 리뷰에 대한 크롤링을 시도할 때 이를 확인할 수 있다. 아래는 크롤링 요청 예jjongsk.tistory.com   방법을 딱히 찾지 못해서 좀 오랫동안 작업이 멈춰있었는데 아이디어가 떠올라서 해당 아이디어로 테스트를 진행해보았다. 일단 직접적인 원인은 Co..

Node의 기본 fetch를 사용하여 크롤링을 시도할 경우 요청이 차단되는 경우가 있다. 대표적으로 네이버의 검색이나 리뷰에 대한 크롤링을 시도할 때 이를 확인할 수 있다. 아래는 크롤링 요청 예시 코드이다.import fs from "fs";fetch("", { headers: { accept: "text/html", "accept-language": "ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7", "sec-ch-ua": '"Chromium";v="128", "Not;A=Brand";v="24", "Google Chrome";v="128"', "user-agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_..

docker-compose 파일 생성# docker-compose.yamlversion: '3.8'services: mongodb: image: mongo:latest container_name: mongodb restart: always ports: - '27017:27017' volumes: - ./data/db:/data/db environment: MONGO_INITDB_ROOT_USERNAME: root MONGO_INITDB_ROOT_PASSWORD: examplepackage.json에 실행 명령어 등록, 테스트"scripts": { "dev": "next dev", "build": "next build", ..

개요React 디버깅을 돕는 Chrome 확장 프로그램 React Developer Tools는 분명히 편리한 도구이다. 이 확장 프로그램을 사용하면 어떤 부분에서 re-rendering이 발생하는지, 어떤 컴포넌트의 렌더링에 얼마나 시간이 걸리는지를 쉽게 파악할 수 있다. 하지만, React Developer Tools는 정확한 성능 측정에는 오히려 문제가 될 수 있다는 사실을 발견하였다. 최근, 매우 큰 테이블을 다루는 작업 중 최악의 성능 환경에서 성능 최적화를 진행한 적이 있다. DOM 크기가 매우 커진 상황에서 element.focus() 요청 시, 예상보다 훨씬 속도가 느려지는 현상을 발견했다. memoization 적용, 렌더링 관리, 상태 분리, 알고리즘 최적화 등 성능 향상을 위한 다양한..