hmk run dev

무분별한 lint 정렬로 인한 헤맴... lint 오류 무시...(lint에러 좀 해결하자 ^^ 구글링하면 다 나온다) 편견에 덮인 오류 찾기 애초에부터 개발자 도구로 번들링 된 파일에 CSS가 script가 빠져있다는 것을 확인하지 않은 것에 대해 자괴감이 들었다...! 그것도 모르고 노드 버전이니 npm 캐시 문제니 getSiteControl 문제이니... 앞으로 문제가 생기면 문제가 생긴 지점부터 그 아래 구동원리를 파악 하자..! 해결방법을 지엽적으로 생각하지 말자 빠르게 하지 말고 그 밑에 돌아가고 있는 구조부터 파악하자..! 그리고 모르는 것은 물어봐도 된다. 사냥개 같이 집요하게 문제를 자발적으로 해결하려는 것도 중요하지만 조직 전체로 봤을 때 리소스 낭비이다. 그러니 오늘 깨달은 점을 실천..

개발 작업은 개발자의 컴퓨터에서 코딩하고 테스트 후에 문제가 없으면 서버에 배포한다. 서버에서 프로그램을 구동시키기 위해선 개발자의 컴퓨터 환경과 호환이 되는 실행환경(버전)이 세팅이 되어있어야 한다. ex) 노드, 파이썬, mysql 등의 버전 이러한 호환을 맞추기 위해 여러 공수가 들어갈 수가 있다..! 이를 해결하기 위한 방법은 여러 가지 방법이 있지만 현재 가장 보편적으로 많이 쓰이는 것이 바로 도커이다! 도커의 컨테이너는 개발자가 코딩을 하고 서버에 배포할 때 코드와 설계도를 같이 서버에 보내면 서버는 그 설계대로 컨테이너들을 설치해 서비스를 실행할 수 있게 해 준다. 1. 매번 환경을 세팅할 공수를 해결해준다. 2. 도커 허브에선 세팅해 놓은 환경을 가져올 수 있다! 3. 이렇게 세팅해놓은 환..

ESM(ES Modules)가 등장하기 전까진 Javascript 모듈화를 네이티브 레벨에서 진행할 수 가 없었습니다. 따라서 개발자들은 번들링(bundling)이라는 우회적인 방법을 사용할 수 밖에 없었습니다. (번들링: 모듈화된 소스 코드를 브라우저에서 실행할 수 있는 파일로 한데 묶어 연결해주는 작업) 이 같은 상황에서 webpack, rollip 같은 도구로 번들링 작업을 하며 프론트엔드 개발자의 생산성을 향상 시켰습니다. 하지만, 1000개가 넘는 JavaScript 모듈이 있는 거대한 프로젝트라면 어떨까요? 실제로 이러한 상황을 어렵지 않게 마주할 수 있으며, 이 경우 Webpack과 같은 JavaScript 기반의 도구는 병목 현상이 발생하곤 합니다. (개발 서버를 실행하는 데 있어 비합리적..