Today, I Learned

1. Javascript Runtime에 대해서 ( 참고 사이트 )
• Javascript Engine : Javascript 런타임의 구성요소 중에 하나로 자바스크립트 엔진이 있는데(구글의 v8같은), 이러한 자바스크립트 엔진은 또 다시, 메모리 힙(Memory Heap), 콜 스택(Call stack)으로 이루어져있다. 프로그래머가 짜놓은 코드를 실행하면 interpreter가 해석하고, call stack에 쌓고(실행 컨텍스트로 쌓임), 변수 등은 메모리 힙에서 관리한다. 이 때, 자바스크립트는 비동기 프로그래밍 언어인데, 이러한 비동기적 프로그래밍이 가능하도록 동기적 프로그래밍 문법을 쓴다(예를 들어, 콜백함수, promise 등)
• Web APIs : 자바스크립트 엔진에 예를 들어, setTimeout과 같은 비동기적 처리가 필요한 실행 컨텍스트가 쌓였다면, 이것은 예를 들어, 3초뒤에 콜백함수를 실행하라는 명령이라 했을 때, 3초동안 '블록킹(blocking)'을 하게된다(동기적 프로그래밍). 이는 전화를 받으면, 그 동안 다른 전화를 못받는 것과 같은 원리인데, 앞서 말했듯이 자바스크립트는 비동기적 프로그래밍 언어이기 때문에 이를 위해서, Event Loop가 존재하며, 이벤트 루프는 이러한 비동기적 명령을 Background(Web APIs)에 수행을 요청해준다.
• 본래 싱글 스레드(Single Thread)인 자바스크립트 엔진과 달리, background는 사실상 멀티 스레드(Multi thread)이기 때문에, 비동기적 처리를 할 수 있다. 그렇게 비동기적 처리를 하고, 난 뒤에 Callback queue에 setTimeout에서 매개변수로 받은 콜백함수를 쌓아둔다(큐이기 때문에 FIFO 구조).
• 그러면 다시, 콜백 큐의 상황과 콜 스택의 상황을 계속해서 곁눈질(?)하며 체크하는 중간자 이벤트 루프(Event Loop)가 콜 스택의 실행 컨텍스트가 모두 실행되고, 틈이 보이면 callback queue에 있는 콜백을 콜 스택에 추가해준다.
• 이런 식으로 본래 동기적으로 움직이는 자바스크립트 엔진을 이벤트 루프, 백그라운드, 콜백 큐라는 다른 요소들을 통해서 비동기적으로 동작하도록 해준다.
• 마지막으로, 이러한 구성요소를 가진 것이 자바스크립트 runtime이고, 자바스크립트 런타임은 쉽게 말해, 자바스크립트 언어가 동작할 수 있는 환경, 프로그램을 말한다. 예로는 웹 브라우저, node.js가 있다(Java로 치면 JVM같은 것)
2. Git Workflow : 깃을 쓰면서 항상 궁금했던 부분! conflict(충돌)이 발생했을 때는 어떻게 해야하는지, 그리고, 왜 충돌이 발생하는지!에 대해서
   • 먼저, 협업을 하는 상황을 가정해보면, 각자의 브랜치를 만들어놓고 작업을 할 것이라고 생각해보자. 즉, 최종 master 브랜치가 따로 있고, 각자 그것을 fork하고, clone 한 뒤에 각자 맡은 부분의 코드를 작성하고 나중에 merge할 계획이라고 생각해보자
   • 이 경우, 팀원의 코드를 pull하고 싶을 때는 팀원의 브랜치를 remote add 한 뒤에 (git remote add pair <팀원의 브랜치 URL>) pull pair master 해주면 된다(팀원의 경우도 마찬가지). 그러나, 협업 과정에서 내가 고친 부분과 팀원이 고친 부분이 같은 부분일 때, 즉, 둘 다 6번째 줄을 고치고 커밋 및 푸시를 한 상태에서 서로의 브랜치를 풀(pull)하려하면, conflict(충돌)이 발생하게 되고, 이 경우 내 코드와 팀원의 코드 중에 선택을 하도록 vsCode가 도와주게 된다. 그러면, 그 부분을 고쳐서 다시 push하면 된다(만약 고치지 않을거라면 푸시할 필요 없음)
   • git workflow는 up-stream 레포지토리를 fork해서 origin 레포지토리를 만든 다음에, clone하여 로컬 레포지토리를 생성해놓고, 수시로 up-stream의 레포지토리(dev 브랜치)와 나의 로컬 레포지토리(dev)의 sync를 맞춰준다(pull 해준다). 이 때, 내가 맡은 기능을 구현하려면, master 브랜치가 아닌 따로 브랜치를 생성해서 작업을 하고, 작업을 한 뒤에 해당 브랜치에 푸시한다(master가 아닌). 그 다음에 해당 브랜치를 up-stream 레포지토리의 dev가 아닌 master 브랜치에 pull request해준다(기능 구현 메커니즘).
3. Git Branch 관련 :
   • 브랜치는 왜 만들까? => 하나의 브랜치(Master)로 팀 단위 작업을 하면, 분업을 하는 데에 있어서, 위험요소가 많음. 따라서, 각자 기능 단위 혹은 원하는 단위로 나눠서 원본을 냅두고, 브랜치를 만들어서 일한 뒤에 최종적으로 merge해주는 것이 위험을 낮출 수 있게 됨.
   • git checkout <브랜치이름> : 브랜치를 옮겨갈 때 쓰는 명령어
   • 브랜치를 새로 만들 때 : git checkout -b <브랜치 이름> : 새로운 브랜치를 만들면서 + 그 브랜치로 이동함
   • 브랜치 이름 변경 : git branch -m <기존 브랜치 이름> <바꿀 브랜치 이름>
     그 다음에, 이전 브랜치를 삭제해줘야함(결론적으로, 이름 변경이 아니라 이름을 변경한 상태로 복사한 뒤에 이전 것을 지우는 방법)
     git push origin :old_branch_name (참고사이트)
4. NVM : Node Version Manager => node.js에도 여러 버전이 있는데, 버전에 따라 자바스크립트로 작성한 코드가 실행되기도하고, 안되기도 한다. 따라서, 버전마다 테스트가 필요한데, 버전을 업데이트 한 뒤에 다시 돌아가는 문제 등을 해결하기 위한 것이 NVM이다. 버전을 자유자재로 바꿔주며, node.js 설치 등도 도와준다(nvm도 하나의 프로그램).
   • 명령어 : nvm ls : 설치된 node의 버전 list 나열
     nvm install <버전명> : 설치하고자 하는 버전의 노드를 설치함
     nvm use <버전명> : 현재 이용하고 싶은 노드 버전으로 바꿔줌(그러나, 그 버전이 설치되어 있다는 전제)
   • nvm 설치 방법:
     $ touch ~/.bash_profile
$ curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.35.3/install.sh | bash
   • package.json 이란? : 여태까지 코드스테이츠 미션을 수행하면서, package.json을 많이 봐왔다. 이 package.json은 협업시에 필요한 파일인데, 이 파일에는 필요한 node package(노트 패키지 모듈)리스트를 써놓은 파일이다. 이 때, 실제 그 패키지 모듈이 들어있는 파일이 아닌 단지 이름을 나열한 파일이라는 점을 기억하기. 그러면 npm(node package manager)를 써서 실제로 install하면? node_modules 디렉터리가 생기고 거기에 실제로 모듈이 설치되어있는 것을 볼 수 있다!
     # 이 때, package.json 내에서의 구분 =>
     dependencies : 이 프로젝트가 돌아가기 위해 필수적 모듈을 나열해놓은 것
     devDependencies : 개발 환경을 위해 필수적인 모듈 나열
     scripts : npm 으로 실행시킬 수 있는 명령어를 정의해놓은 부분

Planning to Study

• git branch 종류 학습 (참고 사이트)
• node.js(javascript runtime)에 대해서 심화학습 및 실행 컨텍스트 부분 복습