이번 프로젝트에서 merge 방식을 바꿔보기로 했다. SJ 님의 의견이었는데, back 레파지토리에서 하는 대로 front 레파지토리에도 적용해보기로 했다. 기존 merge 방식과 다른 두가지 merge 방식인 reabse, squash merge방식을 사용해보고 싶었기 때문이다. 세가지 merge 방식의 차이는 -> 3-way merge 이 블로그에 잘 정리되어 있다.

우리가 정한 merge 룰은 다음과 같았다.

1. deploy는 main 브랜치 작업물로 하고,
2. dev브랜치에서 main브랜치로의 merge는 rebase방식을 사용하고,
3. 그 외 다른 브랜치에서 dev브랜치로의 merge는 squash방식을 사용하기로 했다. 간단한 git-flow를 따르기로 한 것이다.

사건의 전개 - PR commit log 폭탄

깃헙에 KS 님의 PR이 올라와서 리뷰를 하러갔더니 commit log 폭탄이 있었다. 알고보니 브랜치 구분을 안하고 올리셨던 것..! 이때는 초반 PR이어서 내용에 대한 comment만 남기고 Approve를 드렸다.
이 결정을 아주 후회 했다ㅎ

그리고 이 커밋들은 feature -> dev로의 PR이라 하나의 커밋으로 squash 되어 merge되었다.

사건의 위기 - 또 다시 나타난 폭탄

다른 기능을 위한 KS님의 PR이 다시 올라왔다. 그런데 그 PR의 commit log가 뭔가 이상했다.

몇가지 commit이 추가된것 말고는 거의 모든 커밋이 다시 올라온 것이다. 그래서 나는 해당 이슈에 대해서 피드백을 남겼다.

풀리퀘 커밋 로그와 file changed가 맞지 않습니다. 확인 한번만 부탁드려요!

그리고 KS님의 답변이 달렸다.

파일 자체는 문제가 없는데 로그가 이상하네요. 수정해서 올리겠습니다!

그리고 다음 날 회의에서 우리는 1시간 30분동안 이 커밋로그가 왜 그런것인지 토의했다. 회의 좋잖아 한잔해

KS님이 작업하신 branch graph는 위와 같았다. Feature 1 에서 작업한 A, B, C 커밋이 squash merge 된 이후 인데, 분기된 Feature 2 브랜치에서 PR할 때 A, B, C, D, E, F가 모두 올라간 것이다.

해결 방법

회의에 참석한 SJ님이 rebase를 하면 해결할 수 있다고 하셨다.

git checkout [pr branch]
git pull origin dev
git reset --hard HEAD^
git rebase dev

이 방식으로 진행했더니 dev브랜치에서 갈라져 나온 순간부터의 모든 commit에 대해서 commit 한개마다의 conflict를 해결하라는 경고 문구가 떴다.

왜 그랬을까?

현재 local은 git pull origin dev로 인해서 origin dev의 상태를 갖고 있었다. 그런데 rebase가 진행되면서 feature2의 첫 커밋과 현재 dev 브랜치(= origin dev)가 가지고 있는 파일의 변경 사항이 충돌을 일으킨 거였다.

rebase과정의 실수...!

중복된 커밋을 제거하고 싶은 경우, conflict 해결 과정에서 중복된 내용이 들어간 커밋에 대해서는 incoming(dev)을 선택했어야 한다. 하지만 KS님은 rebase conflict 해결 과정에서 계속 incoming이 아닌 current를 선택했다. 왜냐하면 결론적으로 dev상태의 코드를 만들고 싶었기 때문이다. 하지만, 커밋의 incoming을 쭉 따라가면 현재 dev상태가 되는거였기 때문에 incoming을 누르는게 우리의 의도와 맞는 rebase conflict 해결과정이었다.

그래서 우리는 결론적으로, 약 커밋이 4개 정도 줄어든 commit log를 force push 하게 되었다. ㅎㅎㅎㅎㅎ

의문 1. 왜 dev에 merge를 했는데 중복된 log를 탐지하지 못하는걸까?

왜냐하면, squash merge과정에서 commit log와 무관한 새로운 commit id가 만들어졌기 때문에, dev브랜치 입장에서는 전혀 다른 commit이라고 인식하는 것.

의문 2. 그렇다면 rebase과정을 통하면 중복된 log가 사라지는데, 그건 어떻게 가능한걸까?

그건 사람이 수동으로 각 커밋마다의 변경점을 보고 확인해서 중복된 내용이라는 것을 확인해주니까 가능한거! git이 자동으로 해줄 수는 없다 ㅠㅠ

의문 3. squash merge가 아닌 merge를 사용했다면 이런 일이 발생하지 않았을까?

YES!! merge를 했을 경우 dev브랜치에 merge를 위한 커밋이 하나 추가될 뿐, 내가 올린 PR의 모든 commit log 가 dev에 포함되게 된다. dev브랜치 입장에서는 똑같은 commit id에 대해서 다시 반영해달라고 하는 것이므로, 중복된 commit id를 제외하고 PR에 보여졌을 것이다.

의문 4. PR에서 보여주는 commit log는 결국 dev branch와 변경점이 있으니까 보이는거 아닌가? 근데 왜 file changed와 일치하지 않을까?

이건 우리가 rebase과정에서 실수를 범했기 때문이다. 결론적으로는 dev branch와 같은 코드를 갖게 되기 때문에 file changed에는 보이지 않지만, 각 commit 마다는 변경점이 있다고 판단하기 때문에 PR에서 해당 commit을 보여주는것!

사건의 결론 - cherry pick 으로 해결해보자

이 풀리퀘에 남은 commit log 가 약 30개에 달했기 때문에 우리는 조금 더 쉬운 방식을 다시 시도해보기로 했다. 새로운 브랜치를 만들고, PR 에 올라가야하는 5개의 커밋에 대해서 cherry-pick명령을 통해 새로운 브랜치로 옮기는 것이다.

cherry pick 명령어 - 블로그 참고

이 사건에서 배운것

1. PR이 올라간 후에는 꼭 dev 브랜치를 rebase하거나 merge하고 작업을 이어가자.
2. commit log는 죄가 없다. 대부분은 HUMAN ERROR다.
3. 이런 문제를 방지하려면 그냥 dev브랜치에서 다시 분기를 하자.
4. rebase와 squash merge가 동작하는 방식을 제대로 이해하게 된것 같다.
5. 모르는 것을 서로 나누는 회의는 즐겁다.하핳

그리고 당신은 지금 DisContinued 될 것이라는 글을 보았을 것이다. 2021년 출시되어 스포티파이 고객들이 구매했던 CarThing은 2022년 대폭 할인과 함께 단종되었다. 그리고 2024년 5월, 앞으로의 지원도 없고 2024년 12월 9일 부로 더 이상 기계를 쓸 수 없게 될 것이라는 기사가 올라왔다. 아니 서비스 지원 안하는 것 까지는 그렇다치고 아예 기계를 벽돌을 만들겠다고..? 너무하잖아ㅜㅜ 사람들도 다들 분노중이다 e-waste를 만든거나 다름 없다면서, 환불요청이 쇄도했다

한 2022년 12월쯤 내가 처음으로 알게되었던 카씽은 당시 단종된 상태여서 중고나라/ 번개장터 등에는 약 30만원 가까운 금액으로 올라오고, ebay에서는 200불 이상의 가격대를 형성하고 있었다. 당시 나의 의문은 이러했다. 이렇게 높은 가격을 형성할 만큼 사람들에게 인정받는 기계를 왜 단종했을까..? 아무튼 그때는 가격이 너무 비싸서 구매를 못하고 가끔가다가 한번 찾아보곤 했다.

그리고 어제 그냥 한번 검색해봤다가 2024년 6월 단종을 넘어 기계 벽돌 예정 소식을 들은 순간 호기심의 정점을 찍었다.

첫번째 궁금증

왜? 어차피 지금까지 펌웨어 업데이트도 없었고, 단순히 노래 재생을 돕는 기계였을 뿐인데 이게 스포티파이에 어떤 해를 끼치길래 이걸 서비스 종료까지 하는거람?

그래서 해외 기사까지 찾아보기 시작했다. (스포티파이가 미국이 본사라 얼마나 다행인지 ㅋㅋㅋㅋ)

이것 저것 찾아보다가 레딧을 흘러들어가고 그러다가 카씽 해킹을 위한 디스코드까지 흘러간 나 ㅋㅋㅋㅋ

사람들이 내린 결론은 크게 두가지였다.

1. 카씽은 음성을 기반으로 검색해주는, 그리고 기계를 조작해주는 서비스가 있었는데, 이걸 유지하는 서버 비용이 너무 커서 서비스를 종료하는 것
2. 카씽은 기본적으로 스포티파이의 음악을 재생하기 위한 기계로 스포티파이에서 만들어졌기 때문에 스포티파이의 음악을 재생이 잘 되지 않는 순간 브랜드 이미지가 안좋아진다는 것

두가지 다 합리적인 이유였다. 이해가 되었다. 스포티파이가 서비스를 종료할 수 밖에 없다고도 생각했다.

두번째 궁금증

그러면, 나는 이제 궁금해졌다. 스포티파이에서 제공한 펌웨어를 조금 변경해서 계속 사용할 수는 없을까?

기사를 찾다가 또 흘러들어간 스포티파이 디벨로퍼 사이트에 car thing의 sdk를 제공해달라는 글에 약 1800명이 추천을 눌렀는데, 그것에 대해 스포티파이는 어떤 답도 없었다. 심지어 어떤 사람의 추측으로는 spotify가 코드를 너무 얼레벌레 짜서 open source로 제공할 수 없는 것이라는 글도 있었다.ㅋㅋㅋ

해결은 안됬지만,

그래서 지금 카씽을 해킹하기 위한 디스코드에서는 carthing의 포맷하고 새로운 ui와 backend 서버를 구성해서 carthing을 어떻게든 유지하려고 하는 노력을 하고 있다. 포맷하거나 새로운 UI로 변경하는 youtube영상들도 있는데, 보다보니 음... 아직은 위험을 감수하고 따라할 만큼 안정적이지는 않아 보인다. 또 일반인은 따라하기가 어려워보인다.

이건 번외지만, 디스코드 채널 내부에서는 carthing에 wifi모듈이 없다는거에 놀라기도 했더라ㅋㅋㅋ 생각보다 기기가 작아서 RAM도 4GB밖에 안되고, 메모리도 512MB라고 하던데, 그래도 외국인들도 다들 구형 차에서 터치형식이 아니라 버튼 형식이어서 운전에 안정성이 보장되는 카씽을 사랑하는거 같던데 계속 어떻게든 카씽을 쓸 수 있는 방법이 나오면 좋겠다..🙏

그래서 나는,

내가 처음 carthing을 접했을 때는 나와 고작 10살 차이나는 07년산 우리 구형차에게 없는 블루투스 오디오랄까 내비게이션이랄까 이런게 있는 건줄 알았는데, 이제는 보다보니 정들어서 그렇게까진 필요없는데도 갖고싶달까ㅋㅋㅋ 처음엔 카씽의 앞의 디스플레이나, 디자인, 우측의 버튼은 굉장히 맘에 들어서 뽐뿌가 왔었다.

사실 카씽이 내가 원하는 스펙이 되려면 앞판은 남겨두고 뒷판에 와이파이 모듈도 달고 내비나 다른 앱도 실행할 수 있도록 OS도 갈아야되고, 심지어 그러다가 메모리나 CPU가 부족하면 바꿔야되고...ㅎㅎㅎㅎㅎㅎ 그렇게 된거 누가 출시해주면 좋겟다....

아 그래서 어제 검색했을 때는 carthing이 약 7만원-20만원 정도 예전보다 반값에 중고가가 형성되어있던데 진짜 하나같이 서비스 종료라는거는 안써놨더라... 이제 고작해야 6개월 사용하고 벽돌될 기기를 20만원...? 판매자도 모르고 파는 걸 수도 있지만 알고 그가격에 파는거면 진짜 양애취~ㅋ

아무튼, 해킹에 성공해서 카씽을 계속 쓸 수 있게 되기를, 그리고 아무도 카씽 중고사기를 당하지 않기를 바라면서~ 나의 carthing 탐방기는 여기까지!

참고 문헌 https://community.spotify.com/t5/Live-Ideas/Car-Thing-Developer-SDK-for-Spotify-Car-Thing/idi-p/5437643

https://www.notebookcheck.net/Hacking-community-saves-Spotify-Car-Thing-from-becoming-an-e-waste.845472.0.html

https://www.reddit.com/r/carthinghax/

https://www.reddit.com/r/carthinghax/comments/10i1ohg/my_windows_hacking_tutorial/?embed_host_url=https://publish.reddit.com/embed

사실, 포트폴리오의 필요성을 느낀지는 꽤 오래되었다. 원티드, 프로그래머스 등의 채용사이트에서 제공하는 이력서 템플릿에는 사진을 넣을 곳이 없고, 개발은 했지만 현재 운영중이지 않은 프로젝트도 있어서 이력서만으로는 불충분하다고 느꼈다. 그래서 내가 이만큼 할 줄 아는 사람이다고 자기소개라고 쓰고 자랑이라고 읽는다 를 하려면 사진과 함께 내가 구현한 부분을 명확히 쓴 포트폴리오가 필요하다고 생각했다.

하지만 사람은 늘 그렇듯이, 게으르니까...ㅎㅎ 미루고 미루어보았는데, 이제 정말 미루면 안될 때가 온 것 같다.

제작방식

포트폴리오를 만드는 방식은 2가지를 생각했는데, 역시 프론트엔드 개발자니까 웹사이트로 전달하는 방식이 있는게 더 매력적일것이라고 생각했다. 물론, 종이로 뽑아 보는 게 익숙한 사람들을 위해 ppt형식의 포트폴리오도 만들어야겠지..

Let's go~

그래서 시작해봅니다. 나도 만든다 포트폴리오.

*포트폴리오 제작기 Part.1 *

이번장에서 꼭 알아야 하는 것!

1. 다양한 객체 생성 방식 중에 생성자 함수를 사용해 객체를 생성하는 방식
2. 객체 리터럴을 사용해 객체를 생성하는 방식 vs 생성자 함수를 사용해 객체를 생성하는 방식 (장단점, 차이)

17.1 Object 생성자 함수

new 연산자와 함께 Object 생성자 함수를 호출하면, 빈객체 {}를 생성해서 반환한다.

const person = new Object();
console.log(person); // {}

하지만, 반드시 Object 생성자 함수를 이용해서 빈 객체를 생성해야하는 것은 아니다. 오히려 객체 리터럴이 더 간편하므로, 특별한 이유가 없다면 Object 생성자 함수를 이용하지 않는 것을 권장한다.

Q. 그렇다면, 특별한 이유는 어떨때??

아래에서 알려주겠음~~

생성자 함수 constructor 란 ?

new 연산자와 함께 호출하여 객체 (인스턴스 instance)를 생성하는 함수.

자바스크립트는 기본적으로 Object, String, Number, Boolean, Function, Array, Date, RegExp, Promise등의 빌트인 생성자 함수를 제공한다.

const strObj = new String('Lee');
console.log(typeof strObj); //object
console.log(strObj); //String {'Lee'}

이처럼, 생성자 함수에 의해 생성하면 결과로 반환되는 건 원시값이 아닌 객체이다. 왜?? 객체를 생성하는 함수를 호출했으니까!

17.2 생성자 함수

객체 리터럴에 의한 객체 생성방식의 문제점 : 한번에 한 객체만 만드는 것

객체 리터럴에 의한 객체 생성 방식은 직관적이고, 간편하지만 단 하나의 객체만 생성한다.그래서 동일한 프로퍼티 구조를 갖는 여러개의 객체를 만들 때는 매번 같은 프로퍼티와 메서드를 기술해야 하므로 중복적인 코드를 쓰게되고, 비효율적이다.

const circle1 =  {
  radius : 5, 
  getDiameter() {
    return 2 * this.radius;
  }};
const circle2 = {
  radius : 10,
  getDiameter() {
    return 2 * this.radius;
  }};

위의 예제처럼, 프로퍼티 구조가 동일한 두개의 객체를 만들때, 생성자 함수를 써준다!

왜 ? 생성자 함수에 의한 객체 생성 방식의 장점이 있으니까!

마치 객체(인스턴스)를 생성하기 위한 클래스(템플릿)처럼 생성자 함수를 사용하여 프로퍼티 구조가 동일한 객체 여러개를 간편하게 생성할 수 있다. 실제로 클래스처럼 동작한다는 건 아니다!

function Circle(radius){
  // 생성자 함수 내부의 this는 생성자 함수가 생성할 인스턴스를 가리킴.
  this.radius = radius;
  this.getDiameter = function (){
    return 2 * this.radius;
  };
}

const circle1 = new Circle(5);
const circle2 = new Circle(10);

Q. return이 없는데, 객체가 반환된다..?

Q. new가 없으면 어떻게 될까..? 에러가 날까?

짜잔! 한번에 두개나 생성이 가능하다구~~ 멋지지! 하지만 단점없는 기술은 없는법

생성자 함수의 작동방식

자바와 같은 클래스 기반 객체지향 언어의 생성자와 다르게, 형식이 정해져있지 않고, 일반 함수와 동일한 방법으로 함수를 정의하고 new 연산자와 함께 호출하면 해당 함수는 생성자 함수로 동작한다.

이게 무슨 뜻이냐면, 놀랍게도

const circle3 = Circle(15);
// 이렇게 new없이 호출하면 생성자함수가 아닌 일반 함수로서 호출이 된다는 것이다. 미쳤다. 
console.log(circle3); //undefined
// 하지만 반환문이 없으니, 암묵적으로 undefined를 반환한다.

그리고, this가 가리키는 객체가 반환할 인스턴스가 아닌 전역객체가 되어, radius가 전역객체의 프로퍼티가 되는 일이 발생한다! 미친거같아~

Q. 그러면, 어떻게해야해? 아예 쓰지 말아야하나? 그럴수는 없잖슴!

이건 밑에서 알려줌~~

생성자 함수의 인스턴스 생성 과정

생성자 함수는 프로퍼티 구조가 동일한 인스턴스를 생성하기 위한 템플릿(클래스)로서 동작해야하므로, 함수 몸체 내에서

1. 인스턴스를 생성하고
2. 생성된 인스턴스를 초기화 (프로퍼티 추가 및 프로퍼티 초기값 할당) 을 해야한다.

다시 위의 Circle 생성자 함수를 보면, 프로퍼티 초기화 및 초기값 할당 부분을 보이지만, 인스턴스를 생성하고 반환하는 코드는 보이지 않는다.

function Circle(radius){
  //인스턴스 초기화 및 초기값 할당
  this.radius = radius;
  this.getDiameter = function (){
    return 2 * this.radius;
  };
}

//생성자 함수 호출
const circle4 = Circle(100);

보이지않으면 뭐다? 암묵적으로 생성한거다. 여기서 자바스크립트 엔진의 도움이 들어가게 된다. new 연산자와 함께 생성자 함수를 호출하면, 자바스크립트 엔진은 암묵적인 처리를 통해 암묵적으로 인스턴스를 생성하고 인스턴스를 초기화하고 암묵적으로 인스턴스를 반환한다.

1. 암묵적 인스턴스 생성과 this 바인딩 (자바스크립트 엔진) new 연산자와 함께 생성자 함수를 호출하는 순간, 암묵적으로 빈객체 {}를 만든다. 그리고, 이 빈 객체를 this에 바인딩한다. (생성자 함수 내부의 this가 생성자 함수가 생성할 인스턴스를 가리키는 이유)

2. 인스턴스 초기화 (개발자)

함수 몸체 내부에 기술된 코드가 실행되어, this에 바인딩 되어있는 인스턴스를 초기화한다. 프로퍼티나 메서드를 추가하고, 생성자 함수가 인수로 전달받은 초기값을 인스턴스 프로퍼티에 할당하여 초기화하거나 고정값을 할당한다.

3. 인스턴스 반환 (자바스크립트 엔진 / 개발자) 생성자 함수 내부의 모든 처리가 끝나면, 완성된 인스턴스가 바인딩된 this가 암묵적으로 반환된다. (이게 아까 질문의 대답! return이 없는데, 객체가 반환되는 이유!)

function Circle(radius){
  // 1. 암묵적으로 빈객체 생성, this에 바인딩.
  console.log(this); // Circle {}

  // 2. this에 바인딩 된 인스턴스 초기화
  this.radius = radius;
  this.getDiameter = function(){
    return 2 * this.radius;
  };

  // 3. 인스턴스 반환
  // 1. 완성된 인스턴스가 바인딩된 this가 암묵적으로 반환.
  // return {}; -> 2. 명시적으로 빈객체 반환
  // return 1; -> 3. 명시적으로 원시값 반환 => this 반환
}

const circle = new Circle(1);
console.log(circle); 
// Circle {radius: 1, getDiameter: f} -> 1, 3
// {} -> 2. 명시적으로 빈객체를 반환한 경우

반환되는 값은 무조건 2개 중 하나! 1. return문을 명시하지 않은 경우 -> 바인딩 된 this 객체 2. 명시적으로 다른 객체를 반환한 경우 -> 다른 객체 3. 명시적으로 원시값을 반환한 경우 -> 바인딩 된 this 객체 명시적으로 this가 아닌 다른 값을 반환하면, 생성자 함수의 기본 동작을 훼손하기 때문에, 생성자 함수 내에서는 무조건 return문을 생략해야한다!!

17.2.4 내부 메서드 [[Call]] 과 [[Construct]]

함수 선언문 / 함수 표현식으로 정의한 함수는 일반적인 함수로서 호출 + 생성자 함수로서 호출이 둘 다 가능하다

• 함수는 객체이므로 일반 객체와 동일하게 동작할 수 있다. -> 일반 객체의 내부 슬롯, 내부 메서드를 가지고 있다.
• 일반 객체는 호출할 수 없지만 함수 객체는 호출 할 수 있다. -> 함수로 동작하기 위해 [[Environment]], [[FormalParameters]]등의 내부 슬롯과, [[Call]], [[Construct]]같은 내부 메서드를 추가로 가지고 있다.

함수는 호출되는 방식에 따라 호출되는 내부 메서드가 다르다. 일반함수로서 호출되면 [[Call]]이 호출되고, 생성자 함수로서 호출되면 [[Construct]]가 호출된다.

function foo(){} // 함수 선언문으로 생성한 함수
foo(); // 일반 함수 호출 -> Call
new foo(); // 생성자 함수 호출 -> Constructor

• 내부 메서드 [[Call]]은 호출할 수 있는 객체를 뜻하며, 모든 함수가 가지고 있고, [[Call]]메서드를 가지면 Callable이라고 한다.

• 내부 메서드 [[Construct]]는 생성자함수로서 호출할 수 있는 함수만 가지고 있다.

• *[[Construct]]를 가진 함수객체**는 일반함수, 생성자 함수로서 호출할 수 있는 함수객체이고 constructor라고 하며,

• *[[Construct]]를 갖지 않는 함수객체**는 일반 함수로서만 호출할 수 있는 함수객체로, non-constructor라고 한다.

결론적으로 함수 = callable이고, 함수 중 일부는 constructor, 나머지는 모두 non-constructor이다.

constructor와 non-constructor는 함수 정의방식에 따라 구분된다. *함수 선언문, 함수 표현식, 클래스 = constructor 메서드 (ES6메서드 축약표현), 화살표 함수 = non-constructor *

👀 주의할 점 ES6의 메서드 축약 표현만이 메서드로 인정된다. 함수가 어디 할당되어있는지가 아니라 함수 정의방식에 따라 구분하기 때문

function foo(){} // constructor
const bar = function (){}; // constructor
const baz = {
  x : function (){}, // (주의!!) constructor
  //-> 이건 일반함수로 정의되었다고 판단 -> 메서드 인정 xx
  y() {}, // non-constructor
};
const arrow = () => {}; // non-constructor
new foo(); // foo {}
new bar(); // bar {}
new baz.x(); // x {}
new arrow(); // TypeError
new obj.x(); // TypeError

non-constructor인 함수 객체는 내부 메서드 [[Construct]]를 갖지 않기 때문에 에러가 발생함.

주의 !!!! 따라서, 생성자 함수가 아닌 일반함수를 기대하고 생성한 함수가 생성자 함수처럼 호출될 경우 생성자 함수처럼 동작할 수 있음을 알고 있어야함!!

// 함수를 정의할 때 의도는 생성자 함수가 아니었지만,
function add(x, y){
  return x + y;
}
// 함수 선언문으로 생성했기 때문에 생성자 함수처럼 호출이 가능
let inst = new add();
// 반환문이 원시값이므로 무시되고 암묵적으로 빈객체가 생성되어 반환됨.
console.log(inst); // {}

이런 상황이 발생할 수도 있다.

반대로, 생성자 함수로 기대하고 만든 함수가 일반함수처럼 불렸을 때도 동작할 수 있음을 알고 있어야함!!

// 위에서 생성한 Circle 생성자 함수가 있다고 해보자.
function Circle(radius){
  ...
}
// new 없이 호출했을 경우, 생성자함수가 아닌 일반함수처럼 호출이 된다.
const circle = Circle(5);
console.log(circle); // 반환값이 없으므로 undefined가 암묵적으로 반환된다.
console.log(radius) // 5
console.log(getDiameter()); // 10
console.log(circle.getDiameter()); // TypeError

전혀 예측하지 않은대로 동작하게 된다. 인스턴스의 프로퍼티가 되길 바랐던 radius, getDiameter는 전역객체의 프로퍼티가 되는것.

따라서, 생성자함수는 일반적으로 첫 문자를 대문자로 기술하는 파스칼 케이스로 명명해 일반 함수와 구별할 수 있도록 하자.

하지만, 모든걸 사람에게 맡기면 난리가 나니까. -> ES6에서는 new.target을 지원한다. new.target은 this와 유사하게 constructor인 모든 함수 내부에서 암묵적인 지역 변수와 같이 사용된다.

new.target을 사용할 경우 new연산자와 함께 호출되었는지를 판별할 수 있다.

• new 연산자와 함께 호출되었을 경우 (생성자 함수로서의 호출) => new.target = 함수 자신을 가리킴
• new 연산자 없이 호출되었을 경우 (일반 함수로서의 호출) => new.target = undefined

function Circle(radius){
  if (!new.target){
    return new Circle(radius)}
  .....
}

이처럼 new 연산자와 함께 호출되지 않았을 경우 생성자함수를 재귀 호출하는 방식을 선택하면, 생성자함수는 늘 일반함수로서의 호출이 아닌 생성자함수로서의 호출을 보장할 수 잇다.

ES6이전에는 스코프 세이프 생성자 패턴이라는걸 썼음

function Circle(radius){
  if (!this instanceof Circle){
    return new Circle(radius)}
  ....
}

this가 전역객체인지, Circle의 인스턴스인지를 판별해서 재귀적으로 호출하는것

그래서, 이런 문제가 있는 생성자 함수지만, 대부분의 빌트인 생성자함수는 new연산자와 함께 호출되었는지를 확인한 뒤에 적절한 값을 반환하지만,

String, Number, Boolean생성자함수의 경우 new 연산자 없이 호출하면 원시값을 반환한다.

const str = String(123);
console.log(str, typeof str); //123 string

각각의 래퍼 객체 별로 생성자 함수로서 호출되지 않았을 경우에 대한 처리가 다르므로 가급적 사용하지 않는것을 권장한다.

16.1 내부 슬롯과 내부 메서드

내부 슬롯(internal slot)과 내부 메서드(internal method)는 자바스크립트 엔진의 구현 알고리즘을 설명하기 위해 ECMAScript 사양에서 사용하는 이중 대괄호([[...]])로 감싼 이름들인 의사 프로퍼트 (pseudo property)와 의사 메서드(pseudo method)이다.

내부 슬롯, 내부 메서드는 자바스크립트 엔진 내부 로직으로, 직접 접근할 수 있도록 외부로 공개된 객체의 프로퍼티가 아니다. 하지만 일부 내부 슬롯과 내부 메서드에 한해서 간접적으로 접근할 수 있는 수단을 제공한다.

그 중 하나가 [[Prototype]] 이라는 내부 슬롯인데, __proto__ 라는 프로퍼티를 통해 간접적인 접근을 허용한다.

👇 아래는 [[Prototype]]에 대한 접근을 허용하지 않는 예시👇

👇 아래는 __proto__에 대한 접근 허용예시👇

Q. 왜 안보이는데 가능하지?

ES6에서 표준화 되어있기 때문. 근데 mdn에서는 deprecated라고 표시함. 두둥.

Q. 왜 표준이라는데 deprecated지??

ES6가 도입되기 이전에 브라우저들이 자의적으로 만든 프로퍼티 접근방식인데, 비표준인데도 너무 많이 퍼져있다보니 ES6에서 일단 허용해줬다고 함. 그래서 일단 표준이긴한데, 없앨 예정이고, 없애려고 하는 중. 그래서 Object.getPrototypeOf라는 새로운 메서드를 제공해줌. 가급적 이걸 사용하는게 좋음!

16.2 프로퍼티 어트리뷰트와 프로퍼티 디스크립터 객체

자바스크립트 엔진을 프로퍼티를 생성할 때, 프로퍼티 상태를 나타내는 프로퍼티 어트리뷰트를 기본값으로 자동 정의한다. 프로퍼티 어트리뷰트에는 자바스크립트 엔진이 관리하는 내부 상태 값(meta-property)인 내부슬롯들로,

1. 프로퍼티의 값 ( [[Value]])
2. 갱신 가능 여부 ( [[Writable]])
3. 열거 가능 여부( [[Enumerable]])
4. 재정의 가능 여부( [[Configurable]]) 을 포함한다.

아래 사진과 같이, 내부 상태 값들이므로 직접 접근은 불가능하지만, Object.getOwnPropertyDescriptor 메서드를 사용해 간접적으로 확인할수는 있다. 메서드의 첫번째 매개변수에 객체의 참조를 전달하고, 두번째 매개변수에 프로퍼티 키를 문자열로 전달하면, 프로퍼티 어트리뷰트 정보를 제공하는 프로퍼티 디스크립터 (Property Descriptor)객체를 반환한다.

👇 아래는 getOwnPropertyDescriptor 예시👇

💛 더하기 정보 1 )

만약 존재하지 않는 프로퍼티나 상속받은 프로퍼티에 대한 프로퍼티 디스크립터를 요구하면, undefined가 반환된다.

💛 더하기 정보 2)

Object.getOwnPropertyDescriptor : 1개의 프로퍼티에 대해 프로퍼티 디스크립터 객체 반환 ES8 : Object.getOwnPropertyDescriptors : 모든 프로퍼티에 대해 프로퍼티 디스크립터 객체들을 반환

16.3 데이터 프로퍼티와 접근자 프로퍼티

프로퍼티는 위와 같이 두개로 구분할 수 있다.

16.3.1 데이터 프로퍼티

데이터 프로퍼티는 4개의 프로퍼티 어트리뷰트를 갖는다. (프로퍼티 어트리뷰트 - 프로퍼티 디스크립터 객체의 프로퍼티 순서로 기재)

1. [[Value]] - value

• 프로퍼티 키를 통해 프로퍼티 값에 접근하면 반환되는 값.
• 프로퍼티 키를 통해 프로퍼티 값을 변경하면 [[Value]]에 값을 재할당. 이때 프로퍼티가 없으면, 프로퍼티를 동적생성하고 [[Value]]에 값을 저장

2. [[Writable]] - writable

• 프로퍼티의 값의 변경 가능 여부를 나타내고, 불리언 값을 가짐.
• [[Writable]]값이 false인 경우, 해당 프로퍼티의 [[Value]]의 값을 변경할 수 없는 읽기 전용 프로퍼티가 됨.

3. [[Enumerable]] - enumerable

• 프로퍼티의 열거 가능 여부를 나타내고, 불리언 값을 가짐.
• [[Enumerable]]값이 false인 경우, 해당 프로퍼티는 for..in문이나, Object.keys메서드 등으로 열거 불가능.

4. [[Configurable]] - configurable

• 프로퍼티의 재정의 가능 여부를 나타내고, 불리언 값을 가짐.
• [[Configurable]]값이 false인 경우, 해당 프로퍼티의 삭제, 프로퍼티 어트리뷰트 값의 변경이 금지됨.
• *But, [[Writable]]이 true인경우, [[Value]]의 변경과 [[Writable]]을 false로 변경하는 것이 허용된다. *

프로퍼티가 생성될 때 (동적생성을 포함) [[Value]]의 값은 프로퍼티의 값으로 초기화되고, [[Writable]], [[Enumerable]], [[Configurable]]의 값은 true로 초기화된다.

16.3.2 접근자 프로퍼티

접근자 프로퍼티도 4개의 프로퍼티 어트리뷰트를 갖는다. 데이터 프로퍼티와는 다른게 2개 있다.

1. [[Get]] - get

• 접근자 프로퍼티를 통해 데이터 프로퍼티의 값을 읽을 때 호출되는 접근자함수.
• 접근자 프로퍼티 키로 프로퍼티 값에 접근하면, 프로퍼티 어트리뷰터 [[Get]]의 값인 getter 함수가 호출되고, 그 결과가 프로퍼티 값으로 반환됨.

2. [[Set]] - set

• 접근자 프로퍼티를 통해 데이터 프로퍼티의 값을 저장할 때 호출되는 접근자함수.
• 접근자 프로퍼티 키로 프로퍼티 값에 접근하면, 프로퍼티 어트리뷰터 [[Set]]의 값인 setter함수가 호출되고, 그 결과가 프로퍼티 값으로 저장됨.

3. [[Enumerable]] - enumerable

• 데이터 프로퍼티의 프로퍼티 어트리뷰트와 동일

4. [[Configurable]] - configurable

• 데이터 프로퍼티의 프로퍼티 어트리뷰트와 동일

접근자 함수는 getter/setter라고도 부르는데, 접근자 프로퍼티는 getter, setter를 두개 다 정의할 수도 있고, 하나만 정의할 수도 있다.

👇 아래는 접근자 프로퍼티 예시👇

person객체 생성

person 객체의 fullName setter, getter 호출

person 객체의 데이터 프로퍼티, 접근자 프로퍼티의 프로퍼티 어트리뷰트 확인

Q. 접근자 프로퍼티는 객체당 하나만 할 수 있을까? -> XXX 여러개 가능!

Q. 접근자 프로퍼티의 이름은 getter, setter가 꼭 동일하게 설정해야할까? -> XXX 다르게도 할수 있음!

내부 슬롯/ 내부 메서드 관점에서 보는 접근자 프로퍼티 fullName으로 프로퍼티 값에 접근했을 때 내부적으로 [[Get]]내부 메서드가 호출되고 동작하는 방식은 ?

1. 프로퍼티 키가 문자열 / 심벌인지 확인한다. (유효성 확인)
   • 'fullName'은 문자열이므로 유효.
2. 유효하다면, 프로토타입 체인에서 프로퍼티를 검색한다.
   • person 객체에 fullName 프로퍼티가 존재하는지.
3. 존재한다면, 검색된 프로퍼티가 데이터 프로퍼티인지 접근자 프로퍼티인지 확인한다.
   • fullName 프로퍼티는 접근자 프로퍼티.
4. 접근자 프로퍼티라면, 프로퍼티 어트리뷰트 [[Get]]의 값인 getter함수를 호출한다.

3번의 데이터 프로퍼티/ 접근자 프로퍼티를 구별하는 방법은 프로퍼티 어트리뷰트를 객체로 표현한 프로퍼티 디스크립터 객체의 프로퍼티가 다른것을 보고 알 수 있다. = 즉, value, writable을 가지고 있는 객체인지, get, set을 가지고 있는 객체인지 확인하면 됨.

16.4 프로퍼티 정의

프로퍼티 정의 = 새로운 프로퍼티를 추가하면서, 프로퍼티 어트리뷰트를 명시적으로 정의하거나 / 기존 프로퍼티의 프로퍼티 어트리뷰트를 재정의하는 것. = writable, enumerable, configurable의 불리언 값을 정의 / 재정의하는것

방법 : Object.defineProperty 메서드

메서드의 첫번째 매개변수로 객체의 참조를 전달하고, 두번째 매개변수로 데이터 프로퍼티의 키인 문자열을 전달하고, 세번째 매개변수로 프로퍼티 디스크립터 객체를 전달한다.

const person = {};
Object.defineProperty(
  person, 
  'firstName',
  { value : 'Ungmo', writable : true, enumerable : true, configurable : true }
  ); // 1번 방식
Object.defineProperty(
  person,
  'lastName',
  { value : 'lee' }
  ); // 2번 방식

Object.defineProperty 메서드로 프로퍼티를 정의할 때, 2번 방식 처럼 프로퍼티 디스크립터 객체의 프로퍼티를 일부 생략할 수 있다. 이 경우에는 ** value, get, set 은 undefined, writable, enumerable, configurable 은 false ** 의 기본값이 적용된다.

enumerable, writable, configurable이 false인 lastName프로퍼티에 대한 변경을 시도했을 경우 모두 무시됨.

configurable 속성이 false이므로, 프로퍼티 어트리뷰트에 대한 재정의는 에러가 발생한다.

fullName 접근자 함수로 변경을 시도해도, lastName은 변경이 되지 않음!

Q. enumerable 과 iterable은 다른건가?

💛 더하기 정보 1)

Object.defineProperty : 한번에 1개의 프로퍼티를 정의 Object.defineProperties : 여러개의 프로퍼티를 한번에 정의가능

16.5 객체 변경 방지

객체는 변경 가능한 값이므로 재할당 없이 직접 변경가능하다. 프로퍼티 값 갱신뿐만 아니라, 프로퍼티 어트리뷰터를 재정의할 수도 있다.

객체에서 변경가능한 부분은 5가지로 정리로, 프로퍼티 추가, 프로퍼티 삭제, 프로퍼티 값 읽기, 프로퍼티 값 쓰기, 프로퍼티 어트리뷰터 재정의가 있다.

따라서, 자바스크립트는 객체의 변경을 방지하는

1. Object.preventExtensions
2. Object.seal
3. Object.freeze 3 개의 메소드를 제공하며, 각각 객체의 변경을 금지하는 강도가 다르다.

💛 더하기 정보 1 )

객체 변경 방지 메서드를 사용하더라도 중첩 객체에 대해서는 동결되지 않는다. 얕은 변경 방지로 동작하기 때문에 직속 프로퍼티에 대해서만 변경이 방지되기 때문이다. 따라서, 변경이 불가능한 읽기전용의 불변객체를 구현하기 위해 중첩객체에 대해서도 변경방지를 원할경우 (깊은 변경 방지) 객체를 값으로 갖는 모든 프로퍼티에 대해 재귀적으로 메서드를 호출해야한다. (불변객체는 일반적으로 자바스크립트에서 객체를 다루는 기법인데, 책에서는 바꿀수 없는 객체를 일컫고 있음.)

이런 당연한 이야기를 왜 하나 싶겠지만, 충격적이게도 나의 첫 회사는 코드리뷰가 없는 회사였다.

커밋을 하면 단번에 푸시가 되고, 테스트용 서버에 올려서 테스트를 해보다가, 안되면 피드백을 받고 다시 커밋하고...와웅

코드리뷰가 없으면 무섭다.

Q. 온보딩 없이 받은 업무에서 처음 써보는 svn에 코드리뷰없이 40페이지 짜리 코드 컨벤션을 읽고 커밋을 해야되는 주니어의 심정은..? A. 아주 ...아주 무서웠다. 내 코드 한줄로 서버가 터질수도, 페이지 접속이 안될 수도 있는거니까.

이런 상황을 방지하기 위해 코드리뷰는 필요하다.

42서울을 다니면서 나는 코드리뷰에 익숙해져 있었고, 리뷰 과정에서 받게 되는 피드백을 통해 코드 품질이 향상되는 것도 알고 있었다. 코드리뷰가 있다는 것만으로도 코드 작성자는 내 코드의 가독성을 고민하고, 자연스럽게 컨벤션 문화에 익숙해진다.

** 좋은 코드리뷰 태도 ** 란 아직도 어려운 주제라고 생각하지만, 이제 어느정도 기준이 잡힌 것도 같다. 내 기준은 다음과 같다.

** 1. 개발자와 개발자의 코드를 동일선상에 두지 말자. ** 내 코드가 지적받았다고, 수정사항이 생겼다고 내가 지적받거나 수정해야되는 것이 아니다. 나는 주니어고, 모르는게 당연하고, 수정사항이 안 생기면 이상한거다. 오히려 다른 사람의 눈에 내 코드가 괜찮아 보였다면 나는 무서워한다. 내가 생각지도 못한 곳에서 에러가 발생할 가능성이 높아진거니까...!

** 2. 개선이 필요한 이유를 명확하게 전달하자.** 단순히 A을 개선하면 어떨까요? (q1) 보다는 저는 B가 걱정되니 A을 개선하면 어떨까요? (q2) 라는 피드백을 남기면 코드 작성자는 혼자서 B에 대한 충분한 고민을 진행한 후 A를 개선할지 말지를 결정할 수 있다. 내가 q1처럼 질문했다면, 코드작성자는 왜?라는 의문을 갖게 되고, 그에 대해서 나와 한번 더 대화를 나누어야 하지만 q2처럼 질문한다면 그 과정이 없어질 수 있다. 프로세스가 단축되는거다!

** 3. 긍정적인 피드백을 꼭 남기기 ** 사람이라는 동물은 늘 칭찬을 갈구하고, 인정받고 싶어한다. 아무것도 아닌 긍정적인 한마디, 칭찬이 오히려 성장에 대한 욕구를 불러 일으킨다는 것을 나는 개인적으로 경험했기 때문에 꼭 처음이든 마지막이든 수고했다거나 이전보다 성장했다거나, 코드가 깔끔하다거나 가독성이 좋다는 등의 칭찬을 포함하려고 노력한다.

** 4. 이건 정말 중요한데, 물어보자 ** 모르는게 있다? 축하한다. 당신에게 축복인 사람을 만난거다. 코드나, 리뷰에서 모르는 걸 발견했다면 수줍어말고 물어보자. 그건 주니어의 특권이나 마찬가지니까. 언제나 아낌없이 물음표를 날려보자. 얍????얍???

** 5. 코드 그 너머의 사람을 보자 ** 아무리 코드가 거지같다고 해도, 가독성이 떨어진다고 해도, 왜 이런방식으로 구현했는지 모르겠다고 해도, 리뷰는 부드럽게 작성하자. 내가 코드와 나를 분리한다고 해서, 상대방도 그럴 거라는 보장은 없다. 내가 리뷰하는 대상이 코드라고 해서 그 글을 읽는 것도 코드는 아니니까. 늘 사람의 기분을 신경쓰고 리뷰를 하자. 문자로 전달되는 글은 그 글을 쓰는 사람의 감정을 100% 전달해주지 못하니까 잘못 전달될 수도 있다는 걸 잊지말자.

** 6. 문제 해결 방식과, 리소스를 전달하자 ** 이건 사소하다고 생각할 수 있지만 생각보다 코드 작성자에게 도움이 되는 정보다. 내가 알고 있다고 상대도 알고 있는건 아니니까. 상대가 충분히 고민을 해서 이 방식을 선택했다고 해도 나는 그걸 아는 건 아니니까. 내가 아는 방식, 그 방식에 대한 리소스를 전달하면 그에 대한 피드백으로 내가 알고 있었는데 이 방식을 선택한 이유라던가, 아니면 몰랐는데 이런걸 시도해보겠다는 피드백이 돌아올거다. 그러니까 일단 말해보자. 이게 지식공유의 아주 작은 시작이 될거다.

** 마지막으로 당연하겠지만, 이건 나의 기준이므로, 절대적으로 적용하려 하지 않으면 좋겠다..( by. 쭈구리 주니어)**

앞으로 모든 회사들이 코드 리뷰에 진심이 되기를 바라며 🙏 짧은 제 견해를 읽어주셔서 감사합니다. :)

14.1 변수의 생명주기

변수는 선언에 의해 생성되고, 할당을 통해 값을 가짐. => 생명주기가 있음 (life cycle)

Q. 만약 변수에 생명주기가 없다면?

한번 선언된 변수가 프로그램이 끝날 때까찌 영원히 메모리 공간을 점유함-> 와.. 컴퓨터 터질듯

지역변수

지역변수는 함수가 호출되면 생성되고, 함수가 종료되면 소멸함. = 지역변수의 생명주기는 함수의 생명주기와 일치

Q. 지역 변수가 함수보다 오래 생존하는 경우? 변수의 생명주기 : 메모리 공간이 확보된 시점 ~ 메모리 공간이 해제되어 가용 메모리 풀에 반환 되는 시점 but, 만약 누군가 스코프를 참조하고 있으면 스코프는 소멸하지 않고 생존함

호이스팅은 스코프 단위로 동작함. 지역변수의 호이스팅은 지역 변수의 선언이 지역 스코프의 선두로 끌어 올려진 것처럼 동작함.

전역변수 전역코드는 코드가 로드되지마자 곧바로 해석되고 실행되고, 더이상 실행될 문이 없을 때 종료함 var키워드로 선언한 전역 변수는 전역객체의 프로퍼티가 됨. 브라우저 환경에서 전역객체는 window이고, 전역객체 window는 웹페이지를 닫기 전까지 유효함. -> 전역 변수의 생명주기는 전역객체의 생명주기와 일치

14.2 전역변수의 문제점

1. 암묵적 결합 : 모든 코드가 전역변수를 참조, 변경가능 -> 가독성 나빠짐, 상태 변경의 위험이 큼
2. 긴 생명주기 : 생명주기가 길어서, 메모리 리소스를 오랜기간 소비함, 상태 변경 가능 시간이 길고, 기회가 많음. -> 의도하지 않은 코드 생성가능
3. 스코프 체인 상에서 종점에 존재 : 전역 변수를 검색할 때 가장 마지막에 검색 -> 검색속도가 제일 느림
4. 네임 스페이스 오염 : 파일이 분리되어있어도 스코프를 공유하기 때문에 동일한 이름으로 명명된 다른 식별자가 있을 경우 예상치 못한 문제 발생가능

14.3 전역 변수의 사용을 억제하는 방법

전역변수 사용을 가급적 금지하고, 변수의 스코프가 좁은 지역변수 사용을 권장.

1. 즉시실행함수
2. 네임스페이스 객체
3. 모듈패턴
4. ES6 모듈

15장 let, const 키워드와 블록레벨 스코프

15.1 var 키워드로 선언한 변수의 문제점

1. 변수 중복 선언 허용
2. 함수레벨 스코프
3. 변수 호이스팅

15.2. let 키워드

1. 변수 중복 선언 금지 같은 이름의 변수를 선언시 문법 에러 (Syntax Error)발생
2. 블록 레벨 스코프 모든 코드 블록을 지역 스코프로 인정하는 블록레벨 스코프를 따름

   -> Q.이건 지역 스코프라는데..?

3. 변수 호이스팅 변수 호이스팅이 발생하지 않는 것처럼 동작함-> 일시적 사각지대 (Temporal Dead Zone)발생가능. 변수 선언 시점에 초기화 발생 -> 선언 단계 / 초기화 단계 가 분리되어 진행되기 때문 -> 스코프 시작 지점부터 초기화 시작 지점까지 변수를 참조할 수 없는 구간 발생 => ReferenceError
4. 전역객체와 let let은 전역객체의 프로퍼티가 아님 -> 개념적인 블록 내에 존재하게 됨 전역으로 선언해도 블록이 따로 만들어지고, 전역객체의 프로퍼티에 속하지 않게됨!

15.3 const 키워드

1. 선언과 초기화 선언과 초기화를 동시에 진행해야함. 아닐경우 -> Syntax Error발생
2. 재할당 금지 당연함. 상수변수니까
3. 상수 원시값을 할당한 경우 변수값을 변경할 수 없음. 보통 상수를 의미하는 변수의 경우 대문자 + snake_case로 표기 ex ) const TAX_RATE = 0.1;
4. const 키워드와 객체 객체를 할당한 경우 값을 변경할 수 있음.

15.4 "var" vs "let" vs "const"

ES6을 사용한다면, 변수 선언시 기본적으로 const를 사용, 재할당이 필요한 경우 let을 한정적으로 사용한다. let사용시 변수의 스코프는 최대한 좁게 사용하기

스코프 (scope) 란 모든 식별자(변수이름, 함수이름, 클래스 이름 ,...)가 자신이 선언된 위치에 의해 결정된 다른 코드가 식별자 자신을 참조할 수 있는 유효범위

자바스크립트 엔진이 이름이 같은 두개의 변수 중에서 어떤 변수를 찹조해야 할 것인지를 결정하는 것 = 식별자 결정 (identifier resolution) 이때 자바스크립트 엔진이 식별자를 검색할 때 어떤 규칙을 갖고 찾는데, 이 규칙을 스코프라고 볼 수도 있음

자바스크립트 엔진은 언제나 코드의 문맥에 따라서 코드를 실행함. -> 이 코드의 문맥 : 23장에서 설명하는 렉시컬 환경

Q. 만약 스코프가 없다면?

같은 이름을 갖는 변수는 충돌을 일으킴. -> 프로그램을 통틀어 전체에서 하나의 이름을 한번만 사용할 수 있음. 예를들어, 컴퓨터에서 똑같은 파일 이름을 쓸 수 없다면? 오우....쉣... 그래서 쓰는데 디렉토리 ! 디렉토리 내에서는 똑같은 이름을 쓸 수 없지만, 다른 디렉토리에서는 쓸 수 잇음 -> 이게 바로 네임스페이스이고, js에서는 스코프.

13.2 스코프의 종류

1. 전역

   • 코드의 가장 바깥 영역
   • 전역 스코프 (global scope)
   • 변수 선언시 전역 변수 (global variable)이 됨
   • *전역변수는 어디서든지 참조 가능 *

2. 지역

   • 함수의 몸체 내부
   • 지역 스코프 (local scope)
   • 변수 선언시 지역 변수 (local variable)이 됨
   • 지역 변수는 자신의 지역 스코프 + 하위 지역 스코프에서 유효

   Q. 그럼 코드 블록 내부는 지역인가?

13.3 스코프 체인

함수는 충첩될 수 있으므로 함수의 지역 스코프도 중첩될 수 있다. => 함수의 중첩에 의해 스코프가 계층적 구조를 갖게 됨 !!

전역스코프 <- outer 지역 스코프 <- inner 지역 스코프

이것 처럼 모든 스코프는 하나의 계층적 구조로 연결되고, 모든 지역 스코프의 최상위 스코프는 전역 스코프이다. 스코프가 계층적으로 연결된 것 = 스코프 체인 (scope chain)

식별자를 참조할 때 자바스크립트 엔진은 스코프 체인을 통해 식별자를 참조하는 코드의 스코프에서 시작해,상위 스코프 (->)방향으로 이동하며 식별자를 검색한다. 따라서, 방향(단방향)으로 연결되어있기 때문에 상위스코프에서 유효한 식별자는 하위스코프에서 자유롭게 참조할 수 있지만, 하위 스코프에서 유효한 식별자를 상위 스코프에서 참조할 수는 없다.

만약 전역 스코프에서도 식별자를 찾지 못했다면 ReferenceError가 발생한다.

13.4 함수레벨 스코프

지역은 함수 몸체 내부를 말한다. 이는, 코드 블록이 아닌 함수에 의해서만 지역 스코프가 생성된다는 의미이다. var키워드로 선언된 변수는 함수 레벨 스코프를 갖는다.(function level scope)

Q. 그렇다면 코드 블록 내부는 어떤 스코프..?

13.5. 렉시컬 스코프

동적 스코프 : dynamic Scope

• 함수를 어디서 호출했는지에 따라 함수의 상위 스코프를 결정함.
• 함수를 정의하는 시점에는 함수가 어디서 호출될지 알 수 없음 -> 호출 시점에 동적으로 상위 스코프 결정

렉시컬 스코프 / 정적 스코프 : lexical scope / static scope

• 함수를 어디서 정의했는지에 따라 함수의 상위 스코프를 결정함.
• 대부분의 프로그래밍 언어는 렉시컬 스코프
• 함수가 호출된 위치는 상위 스코프 결정에 영향이 x

실행컨텍스트 execution context

실행컨텍스트를 이해하면 자바스크립트의 동작원리를 이해할 수 있다. 키야

1. 스코프를 기반으로 식별자와 식별자에 바인딩된 값 (식별자 바인딩)을 관리하는 방식
2. 호이스팅이 발생하는 이유
3. 클로저의 동작방식
4. 태스크큐와 함께 동작하는 이벤트 핸들러
5. 비동기 처리의 동작방식 을 모두 이해할 수 있다~ 이 장에 대한 이해를 끝낸 뒤에 다시 생각해보자

23.1 소스코드의 타입

ECMAScript사양은 소스코드를 4가지 타입으로 구분

1. 전역코드 (global code)

• 전역에 존재하는 소스코드.
• 전역에 정의된 함수, 클래스등의 내부 코드는 포함 x

2. 함수코드 (function code)
   • 함수 내부에 존재하는 소스코드
   • 함수내부에 중첩된 함수, 클래스등의 내부 코드는 포함 x
3. eval 코드 (eval code)
   • 빌트인 전역함수인 eval함수에 인수로 전달되어 실행되는 소스코드
4. 모듈 코드 (module code)
   • 모듈 내부에 존재하는 소스코드
   • 모듈 내부의 함수, 클래스등의 내부 코드는 포함 x

각 타입에 따라 실행 컨텍스트를 생성하는 과정과 관리 내용이 다름

1. 전역 코드 -> 전역 실행 컨텍스트

• 최상위 스코프인 전역 스코프를 생성.
• var 키워드로 선언된 전역 변수와 함수선언문으로 정의된 전역함수를 전역객체의 프로퍼티와 메서드로 바인딩하고 참조하기 위해 전역객체와 연결

2. 함수 코드 -> 함수 실행 컨텍스트

• 지역 변수, 매개변수, arguments 객체를 관리
• 생성한 지역 스코프를 스코프 체인에 연결

3. eval 코드 -> eval 실행 컨텍스트

• strict mode에서 자신만의 독자적인 스코프를 생성

4. 모듈 코드 -> 모듈 실행 컨텍스트

• module별로 독립적인 모듈 스코프를 생성

-> 여기서 eval과 module은 다음에 다루기로. 전역 실행 컨텍스트, 함수 실행 컨텍스트를 위주로 진행함.

23.2 소스코드의 평가와 실행

소스코드 평가과정 :

• 실행컨텍스트 생성
• 선언문 실행
• 식별자를 기로 실행 컨텍스트가 관리하는 스코프에 등록

소스코드 실행과정 :

• 실행에 필요한 정보 (변수, 함수의 참조)를 실행 컨텍스트가 관리하는 스코프에서 검색해서 취득
• 변수값의 변경등 실행의 결과를 실행 컨텍스트가 관리하는 스코프에 등록

var x = 1;

평가하는 과정 : 실행컨텍스트가 관리하는 스코프에 등록, undefined로 초기화 x : undefined

실행하는 과정 : x 변수의 등록 확인, 실행 결과 값 등록 x : 1

23.3 실행 컨텍스트의 역할

전역코드와 함수코드로 구성된 예제 >

// 전역 변수 x, y 선언 
const x = 1;
const x = 2;

function foo(a){
  // 지역변수 x, y 선언
  const x = 10;
  const y = 20;

  console.log(a + x + y);
}
foo(100); // foo의 호출 순간 ①

console.log(x + y); // 3

Q. 이 코드의 평가 및 실행 순서는 어떻게 될까?

내 생각 :

1. foo , local x, local y, global x, global y 가 실행 컨텍스트에 등록
2. x = 1, y = 2 전역 변수를 각각 실행해서 찾아서 값을 변경
3. foo(100)호출
4. x = 10, y = 20 지역변수를 각각 실행해서 찾아서 값을 변경
5. console.log(a + x + y)실행
6. console.log(x + y)실행

이렇게 되지 않을까 생각했다. 책을 읽어보니, 함수 호출의 순간, 함수의 실행 컨텍스트가 만들어진다고 한다. 내가 1번으로 진행될 것이라고 생각한 local x, local y 가 3번 foo(100)호출 이후에 진행된다는 것이다.

그래서 실행 순서는 다음과 같다.

1. 전역 코드 평가
2. 전역 코드 실행
3. 함수 코드 평가
4. 함수 코드 실행
5. 함수 코드가 끝나면 다시 전역 코드 실행

이처럼 코드가 실행되려면 스코프, 식별자, 코드 실행 순서등의 관리가 필요하다. 이걸 해주는건 실행컨텍스트~ 실행 컨텍스트는 소스코드를 실행하는 데 필요한 환경을 제공하고 코드의 실행 결과를 실제로 관리하는 영역이다. 식별자와 스코프는 렉시컬 환경으로 관리하고, 코드 실행 순서는 실행컨텍스트 스택으로 관리한다.

23.4 실행 컨텍스트 스택

제목에서 스포를 당했지만, 실행 컨텍스트는 스택 자료구조로 관리된다. 코드가 실행되는 시간의 흐름에 따라 실행 컨텍스트가 추가되고, 제거 된다.

함수의 실행시점에 함수의 실행 컨텍스트가 생성되고 실행 컨텍스트 스택에 추가되고, 함수의 종료 시점에 함수의 실행 컨텍스트를 제거하고(pop), 이전 실행 컨텍스트를 실행한다. 말로 설명하면 어려움 (그림을 보자 23-5)

23.5 렉시컬 환경

Lexical Environment는 식별자와 식별자에 바인딩된 값, 상위 스코프에 대한 참조를 기록하는 자료구조이다.

사실, lexical Environtment 컴포넌트와 variable Environment 컴포넌트로 구성되는데, 하나의 동일한 렉시컬 환경을 참조한다.

Q. 그렇다면 variable Environment 컴포넌트가 필요한 이유는 뭘까?

아무튼, 렉시컬 환경은

1. 환경 레코드 (Environment Record) 스코프에 포함된 식별자를 등록 등록된 식별자에 바인딩된 값을 관리하는 저장소
2. 외부 렉시컬 환경에 대한 참조 (Outer Lexical Environment Reference) 상위 스코프를 가리킴 = 상위 코드의 렉시컬 환경 단방향 링크드 리스트인 스코프 체인을 구현함

이렇게 두개로 구성된다.

23.6 실행 컨텍스트의 생성과 식별자 검색 과정

이 단원에서는 이거 두개만 알면 된다.

1. 실행 컨텍스트가 생성되고 코드 실행 결과가 관리되는 방법
2. 실행 컨텍스트를 통해 식별자를 검색하는 방법

var x =1 ;
const y = 2; 

function foo (a){
  var x = 3;
  const y = 4;

  function bar (b){
      const z = 5;
    console.log(a+b+x+y+z);
  }
  bar(10);
}
foo(20);

이 코드를 실행하기 위한 전체적인 순서는 다음과 같다.

1. 전역 객체의 생성

2. 전역 코드의 평가

   전역 코드의 평가는 다음과 같은 순서로 진행된다.

   1. 전역 실행 컨텍스트 생성
   2. 전역 렉시컬 환경 생성
   3. 1. 전역 환경 레코드 생성 ㄴ2.1.1. 객체 환경 레코드 생성 ㄴ2.1.2. 선언적 환경 레코드 생성
   4. 2. this 바인딩
   5. 3. 외부적 렉시컬 환경에 대한 참조 결정

3. 전역 코드의 실행

4. foo 함수 코드 평가

   함수 코드 평가는 다음과 같은 순서로 진행된다.

   1. 함수 실행 컨텍스트 생성
   2. 함수 렉시컬 환경 생성

5. 1. 함수 환경 레코드 생성
6. 2. this 바인딩
7. 3. 외부 렉시컬 황경에 대한 참조 결정

8. foo 함수 코드 실행

9. bar 함수 코드 평가

10. bar 함수 코드 실행

    console.log(a+ b+x+y+z)실행

    1. console 식별자 검색
    2. log 메소드 검색
    3. 표현식 a+b+x+y+z의 평가

11. bar 함수 코드 실행 종료

12. foo 함수 코드 실행 종료

13. 전역 코드 실행 종료

이렇게 10단계의 순서가 끝나면 실행 컨텍스트에 아무것도 남아있지 않게 된다.

23.7 실행 컨텍스트와 블록 레벨 스코프

var 로 선언한 변수 : 함수레벨 스코프 let, const 변수 : 블록레벨 스코프

이때, 블록레벨 스코프를 생성하기 위해 선언적 환경 레코드를 갖는 렉시컬 환경을 새롭게 생성하여 기존의 렉시컬 환경을 교체한다. 새롭게 생성된 코드 블럭을 위한 렉시컬 환경의 외부 렉시컬 환경에 대한 참조는 교체하기 이전의 렉시컬 환경을 가리킨다. -> 따라서 스코프 체인이 끊기지 않고 이어짐!

for (let i = 0; i < 5; i++){} 와 같이 for 문의 변수 선언문에 let키워드를 사용하면, 코드블록이 반복해서 실행될 때마다 코드블록을 위한 새로운 렉시컬 환경을 생성하고, for문이 포함된 상위 스코프와 독립적인 렉시컬 환경을 생성해 식별자의 값을 유지한다.

아니나 다를까, public으로 돌리자마자 이메일이 도착했다. 내용은 시크릿키 누출이 의심된다는 경고메일이었다.

맞다. GitGuardian은 똑똑했다. 나는 웹에서 인증용 메일을 전송하기 위해 gmail 을 이용해 smtp 메일 발송을 하는 코드를 만들었는데, 이 과정에서 gmail의 client secret이 .env에 포함되었고, 그게 누출이 된거다.

그래서 .env를 삭제해야했다. 만약 commit history에서는 삭제하지 않아도 되거나, 혹은 로컬에서 삭제하면 된다면 이 방법을 쓰자. 이건 그렇게 어렵지 않았다. 이과정은 알고 있었고, 익숙했다.

1. 혹시 원격 저장소에 저장되어있다면 git rm --cached [File Name] 명령어로 원격 저장소에 저장된 file을 삭제하고,
2. 로컬에 저장된 파일을 다른 곳으로 옮기거나, 삭제하고,
3. gitignore파일에 삭제해야하는 파일에 대해 추가해주고,
4. gitignore를 add, commit, push 해주면 되었다.

근데 문제는 이거였다.

Q. 이전에 커밋한 기록들에 포함된 .env는 어떻게 하지?

커밋 히스토리에서도 파일을 삭제할 수 있나??

찾아보니, git filter-branch 명령어가 있었다. git에서 히스토리를 변경하는데 사용하는 명령어인데, 특정 디렉토리나 파일을 히스토리에서 제거하는데도 유용하게 사용할 수 있었다.

로컬 레파지토리 root level에서 git filter-branch -f --index-filter "git rm --cached --ignore-unmatch backend/.env" --prune-empty -- --all 를 입력했다.

명령어의 의미는 이렇다고한다. -f로 강제로 덮어쓰고, --index-filter로 각 커밋에서 특정 파일을 필터링해서 제거하고, --prune-empty 파일이 제거된 뒤에 커밋이 빈커밋이면 커밋을 제거하고, --all 모든 브랜치와 태그에 대해서 작업을 수행하는 것.

순식간에 엄청나게 많은 로그들이 지나가고~~ 나는 불안해졌다. 혹시 모든 커밋들이 다 지워졌으면 어떻게하지? 그래서 git log로 확인했다. 다행히 지워지진 않았더라. 휴...

끝으로 git push --force --all명령어로 main브랜치에 강제로 푸시를 했다.

이렇게 올라가면 안되는 파일을 삭제하는 작업도 완료~~

이후 여러개의 프로젝트를 진행하다보니 백엔드와 프론트의 레파지토리가 분리되어있는 게 훨씬 작업하기도 다른 사람들이 코드를 읽기도 편하다는 것을 알게 되었다.

늦었지만 지금이라도 분리해보려고 한다.

목표는 다음과 같다. where42 레파지토리의 src/main/where42에 담겨있는 모든 프론트엔드 파일을 새로운 레파지토리인 where42_front_v1레파지토리에 옮기는 것이다.

그래서 다음과 같이 진행했다.

1. 우선 새로운 레파지토리인 where42_front_v1을 생성한다.

2. where42 와 where42_front_v1레파지토리를 각각 로컬에 clone해준다.

(나는 이때 혹시 몰라서 예전에 클론해둔 디렉토리가 아닌 새로운 디렉토리를 생성해서 작업했다.)

3. 작업물이 들어있는 where42디렉토리로 이동해서, subtree를 생성해준다.

subtree를 생성하면 작업 했던 커밋 내역도 함께 분리된다. 이때 명령어는 $ git subtree split -P <옮길 폴더 명> -b <브랜치 이름> 이다.

4. subtree 생성이 끝나면 작업물을 복사할 디렉토리로 이동한뒤, 생성한 subtree를 pull 받는다.

이때 명령어는 git pull <기존 레파지토리> <브랜치명>이다.

5. git remote -v 명령어로 옮겨 갈 레파지토리가 잘 연결 되었는지 확인 후 git push를 진행한다.

6. git log 명령어로 commit history도 잘 복사되었는지 확인한다.

복사끄읕~

이제 이전 레파지토리에 남아있는 디렉토리가 필요가 없다면 rm-rf로 삭제하고, git commit도 진행해주면 된다.

나는 이전 레파지토리에 남아있는 디렉토리의 내용은 삭제하고 새로 만든 레파지토리의 서브모듈을 연결해주려고 한다.

삭제를 위해 브랜치를 생성하고, 삭제를 진행하고, 커밋을 하고, 풀리퀘를 올리고, 머지까지 진행했다.

이제, 서브모듈을 연결한다.

git submodule add <연동할 깃 저장소 주소.git> <연동할 메인 저장소의 경로> 이게 서브모듈의 기본 명령어인데, 나의 경우엔 where42/src/main/where42에 where42_front_v1을 연결해주려고 하므로, git submodule add <where42_front_v1 레파지토리 주소> src/main/where42 를 where42 디렉토리의 루트레벨에서 진행해준다.

마지막으로, 서브모듈 업데이트를 해준다.

서브모듈이 추가되면 git submodule update --init --recursive 서브모듈을 초기화하고 업데이트해주는 명령어로 서브모듈을 업데이트한다.

서브모듈이 업데이트 되면 .gitmodules 파일에 서브모듈 관련 정보가 추가된다. 이 파일을 다시 브랜치에서 commit하고 풀리퀘하고, 머지까지 해주면..?

서브모듈까지 완성~

Top Interview 150 중 383. Ransom Note

🍿 난이도 : 리트코드 기준 Easy 🚧 알고리즘 : hash table

🚦 풀이1 🚦

class Solution:
    def canConstruct(self, ransomNote: str, magazine: str) -> bool:
        for alpha in ransomNote:
            if alpha in magazine:
                i = magazine.find(alpha)
                magazine = magazine[:i] + magazine[i+1:]
            else:
                return False
        return True

🚧 우선 생각나는대로, ransomnote에 있는 알파벳이 magazine에 있는지 확인했다.

🚧 만약 있는 알파벳이라면 magazine을 해당 알파벳을 뺀 값으로 변경했고, 없는 알파벳이라면 바로 false를 돌려줬다.

풀이 결과

나름 괜찮은 런타임과 메모리사용량을 보여줬고, 바로 풀었기 때문에 나쁘지 않았지만, 이 문제가 해쉬를 이용하는 문제로 출제되었음을 알고 있었기 때문에, 다시 풀어야겠다고 생각했다.

🚦 풀이2 🚦

class Solution:
    def canConstruct(self, ransomNote: str, magazine: str) -> bool:
        notecnt = Counter(ransomNote)
        magcnt = Counter(magazine)
        for i in notecnt :
            if (magcnt[i] < notecnt[i]):
                return False
        return True

🚧 다른 사람이 풀어낸 문제를 풀어내면 좋은 순서를 읽다가, Counter를 이용할 수 있다는 것을 알았다.

🚧 두 string을 각각 counter객체로 만들어줬다.

"a"   => Counter({'a': 1})
"aab" => Counter({'a': 2},{'b': 1})

🚧 notecnt에 있는 하나의 dict마다, 동일한 키값을 갖고 있는 dict를 magcnt에서 찾아서, value값을 비교해줬다. value값이 notecnt의 value값보다 작으면, 사용할 수 있는 알파벳이 충분하지 않다는 의미이므로 false를 리턴했다.

풀이 결과

런타임 속도가 조금 느려졌지만, 메모리 사용량이 줄어들었다. 📌 hash를 위해서 counter객체를 사용한다는 사실을 알게되었다.

타인의 코드

notecnt = Counter(ransomNote)
magcnt = Counter(magazine)
return (notecnt & magcnt == notecnt)

Counter() 함수는 collections module에 포함되어있다. 카운터 객체의 사용방법을 더 다양하게 알게되었다. counter객체 & counter객체를 하면, 결과값은 counter객체인데, dict의 값에 key는 동일하고, value중에서 중복값만 저장된다. & 연산이 조금 시간이 오래걸리겠지만, 코드가 간결해지고, 의미가 바로 전달된다는 점에서 좋다고 생각했다.

추가적으로, counter객체에 저장할 수 있는 예제를 공부해보자

Top Interview 150 중 71. Simplify Path

🍿 난이도 : 리트코드 기준 Medium 🚧 알고리즘 : stack

🚦 풀이1 🚦

class Solution:
    def simplifyPath(self, path: str) -> str:
        stack = []
        paths = path.split('/')
        for dir in paths:
            if (dir == ''):
                if (stack and stack[-1] == '/'):
                    continue
                else:
                    stack.append('/')
            else:
                if (dir == '.' or dir == '..'):
                    continue
                if (stack and stack[-1] == '/'):
                    stack.append(dir)
        if (len(stack) > 1 and stack[-1] == '/'):
            stack.pop()
        return "".join(stack)

🚧 python의 stack을 위해 list 자료구조를 사용했다.

🏗 paths : 입력값 path가 "/"를 기준으로 나누어진 리스트

🚧 "/"를 기준으로 나누게 되면서, path의 기준이 되는 "/"값이 사라졌다. 세번째 예시인 "/home//foo/"입력값을 기준으로, paths에 들어가는 값은 ['', 'home', '', 'foo', '']이다. 그래서 ""로 들어간 값에 대해서 "/"라고 생각하고 진행했다. 중복 값을 제거해주기 위해 "/"가 stack의 top에 있고, 지금 디렉토리가 "/"일 경우에는 continue로 지나쳤다.

🚧 처음에는 문제를 읽을 때, ".", ".."은 각각 현재 디렉토리, 부모디렉토리를 가리키는 값이고, 이 값들에 대해서는 제외하고 파싱하라는 것으로 이해했다. 그래서, if (dir == '.' or dir == '..'): continue와 같이 ".", ".."에 대해서는 무시하도록 했다.

풀이 결과 : 실패

🥲 테스트케이스 "/a/./b/../../c/"에서 실패했다.

위의 테스트케이스를 통해서 ".", ".."에 대해서도 생각해줘야 한다는 것을 알게되었다. 이미 위치가 루트인 경우를 제외하고는 모두 적용해줘야 하는 문제였다. 테스트케이스에서 "/"에 대한 처리만 하고 난 이후의 path값은 "/a/b/../../c"가 된다. 풀어보면, a디렉토리 하위에 b디렉토리가 있고, 그 부모의 부모의 디렉토리에서 다시 c디렉토리로 이동해야한다. 그래서 b 디렉토리의 부모인 a, a의 부모인 root까지 가서, 다시 c디렉토리로 이동했기 때문에 이 테스트케이스의 답은 "/c"가 된다. 아래와 같은 폴더 구조를 가지고 있다고 생각하면 쉽다.

root ├ a/ ├├ b/ ├├ c/

🚦 풀이2 🚦

class Solution:
    def simplifyPath(self, path: str) -> str:
        stack = []
        paths = path.split('/')
        for dir in paths:
            if (dir == ''):
                if not stack:
                    stack.append(dir)
            else:
                if (dir == '.'):
                    continue
                if (dir == ".."):
                    if (len(stack) > 1):
                        stack.pop()
                    continue
                stack.append(dir)
        if (len(stack) == 1):
            return "/"
        return "/".join(stack)

🚧 join할 때 '/'를 기준으로 다시 넣어줄 수 있다는 것을 떠올리고, 이전에 풀때 리스트의 ''값을 스택에 '/'로 넣어주는 부분을 삭제했다. 첫 '/'를 제외하고는 '//'값이 있을 때만 ''값이 생긴다는 것을 알게 되어, '/'값은 처음빼고 모두 무시했다.

🚧 단독으로 stack에 들어있는 ''값은 '/'와 join될 때 결과가 ''로 나왔기 때문에, 마지막에 stack에 1개의 값만 있을 때는 '/'을 리턴해주었다.

🚧 이번에 작성할 때는 위의 테스트 케이스를 참고해서 만들었다. 사실 현재 디렉토리를 의미하는 '.'은 이 문제에서는 의미가 없기 때문에, continue를 이용해서 무시했다.

🚧 '..'은 stack에 값이 있을 경우 stack에 쌓인 원소를 하나 삭제했다. 앞의 디렉토리가 사라졌으므로, 부모디렉토리 단계로 올라간다는 의미다. stack에 값이 없을 경우엔, 이미 root디렉토리에 있다는 의미이므로 continue를 통해 무시했다.

🚧 마지막으로 '.', '..', ''이 아닌 리스트의 원소들은 stack에 쌓아주었다.

풀이 결과

나쁘지 않은 결과였지만, 통과하고도 논리적으로 중복되는 것 같은 부분이 있다고 느꼈다.

🚦 풀이3 🚦

class Solution:
    def simplifyPath(self, path: str) -> str:
        stack = []
        paths = path.split('/')
        for dir in paths:
            if (dir == '.' or dir == ''):
                continue
            if (dir == ".."):
                if stack:
                    stack.pop()
                continue
            stack.append(dir)
        return "/" + "/".join(stack)

🚧 훨씬 훨씬 간결해졌다.

🚧 첫 번째 ''를 처리하는 부분과, 맨 마지막에 스택에 하나남은 ''를 처리하는 부분을 다듬었다. 리스트에 존재하는 모든 ''를 무시하고, 마지막에 join한 result string에 '/'를 맨 앞에 더해서 정답문자열을 만들었다.

🚧 이전풀이와 같이 '.'은 무시했고, '..'의 경우 stack에 있을 때만 pop하고 나머지의 경우 무시했다.

풀이 결과

이정도로 좋아질 거라고 기대하진 않았는데, '/'처리 부분만 수정했을 뿐인데 런타임 속도와 메모리부분에서 개선이 엄청 많이 되었다.

🥷 Solution Cheat

class Solution:
    def simplifyPath(self, path: str) -> str:
        return __import__('os').path.abspath(path)

타인의 코드. os.path.abspath() 함수는 Python의 내장 모듈인 os 모듈에 있는 함수이고, 주어진 경로를 절대 경로로 변환해주는 기능을 제공한다. 주어진 path를 절대 경로로 변환한 후 그 결과를 반환하는 아주아주 짧고 충격적인 코드였다. 별거아닌데, 나도 os모듈을 알고 있었는데. 전혀 생각지도 못했다. 이런 코드를 망설임없이 내뱉을 수 있어야 파이썬 마스터라고 할 수 있는걸까?

Top Interview 150 중 17. Letter Combinations of a Phone Number

🍿 난이도 : 리트코드 기준 Medium 🚧 알고리즘 : 백트랙킹 (backtracking)

🚦 풀이1 🚦

class Solution:
    def letterCombinations(self, digits: str) -> List[str]:
        letter = {"2": ["a","b","c"], "3": ["d","e","f"], "4":["g","h","i"], "5":["j","k","l"], \
                "6":["m","n","o"], "7":["p","q","r","s"], "8":["t","u","v"], "9":["w","x","y","z"]}
        zipping = []
        for num in digits:
            # print(letter[num])
            if len(zipping):
                newzip = []
                for i in zipping:
                    for j in letter[num]:
                        newzip.append(i + j)
                zipping = newzip
            else:
                zipping = letter[num]
        return (zipping)

🚧 python의 list, dictionary 자료구조를 사용했다.

🚧 백트랙킹 문제인걸 알았지만 바로 어떻게 구현할 지 생각이 나지 않아서 우선 brute force로 풀어봤다.

🏗 letter : 문제에서 제시한 번호판대로 만들어 둔 dictionary. 🏗 zipping : 최종 결과값을 담는 배열 🏗 new zip : 한번 순환할 때 임시로 값을 저장하는 배열

🚧 digits에 들어있는 번호와 같은 번호를 letter에서 찾아서 해당하는 알파벳 리스트를 하나씩 돌아가면서 진행한다.

🚧 만약, zipping에 담겨있는 값이 없다면, 1번째 순회이므로, letter에서 digits[0]에 해당하는 알파벳 리스트를 찾아서 zipping에 넣어준다.

🚧 만약, zipping에 담겨있는 값이 있다면, 2번째 순회이므로, 앞서 넣어둔 zipping의 값들과 현재 digits에 해당하는 알파벳 리스트를 1:1로 매칭해서 newzip 리스트에 담는다. 한번의 순회가 끝나면 새로 만든 newzip의 값으로 zipping의 값들을 대체한다.

풀이 결과

나쁘지 않은 결과였지만, 백트랙킹 방식으로도 풀어보고 싶어서 다시 문제를 풀었다.

🚦 풀이2 🚦

class Solution:
    def letterCombinations(self, digits: str) -> List[str]:
        if (digits == ""):
            return []
        letter = {"2": ["a","b","c"], "3": ["d","e","f"], "4":["g","h","i"], "5":["j","k","l"], \
                "6":["m","n","o"], "7":["p","q","r","s"], "8":["t","u","v"], "9":["w","x","y","z"]}
        if (len(digits) == 1):
            return letter[digits]
        beforelist = self.letterCombinations(digits[:-1])
        newlist = [i+j for i in beforelist for j in letter[digits[-1]]]
        return newlist

🚧 이번에는 재귀방식으로 풀었다. 백트랙킹 알고리즘은 경우의 수를 나무가지처럼 뻗어나가다가 조건에 맞지 않으면 거기서 다시 나무가지의 분기점으로 돌아와서 다른방향으로 진행하는 방식이라고 알고 있었는데, 문득 재귀로 했던 것 같은 생각이 스쳤다. 재귀를 도입해보기로 했다.

🏗 letter : 문제에서 제시한 번호판대로 만들어 둔 dictionary. 🏗 beforelist : 재귀함수에서 돌려받은 리스트 🏗 newlist : return할 리스트

🚧 digits기준으로 뒤에 있는 알파벳부터 하나씩 보면서 재귀를 진행한다. 가장 깊은 단계의 재귀에서는 맨 앞의 1개의 digit을 보고, 해당하는 알파벳 리스트를 담아서 돌려준다. 중간 단계들에서는 앞서 받은 beforelist와 현재 digit에 맞는 알파벳리스트를 1:1매칭해서 새로운 newlist에 담아준다. 이때는 2중 for문 대신 list comprehension을 사용해봤다.

🚧 leetcode에서 제공해주는 solution class 안에 있는 함수를 사용할 때는 self.letterCombinations(digits[:-1]) 이런 식으로 작성해줘야한다는 것을 처음알았다. 두둥탁. 이와 관련해서 찾아본 참고질문 -> leetcode general discussion

풀이 결과

와 메모리 기준에서 90퍼 달성해본 건 처음이다. 백트랙킹 방식에 가까워진듯하지만 여전히 백트랙킹 방식은 아닌 것 같다고 느꼈다. 어디서? 가지치기가 없다는 점에서.

가지치기는 효율을 위해 도입한 백트랙킹 알고리즘의 핵심개념이다. 앞서 말했던 백트랙킹 알고리즘에 대한 설명 백트랙킹 알고리즘은 경우의 수를 나무가지처럼 뻗어나가다가 조건에 맞지 않으면 거기서 다시 나무가지의 분기점으로 돌아와서 다른방향으로 진행하는 방식 중에서 "조건에 맞지 않으면"에 해당한다.

그래서 가지치기에 대한 힌트를 얻었다. : 앞에부터 digit을 보세요 :

🚦 풀이3 🚦

class Solution:
    def letterCombinations(self, digits: str) -> List[str]:
        if (digits == ""):
            return []
        letter = {"2": ["a","b","c"], "3": ["d","e","f"], "4":["g","h","i"], "5":["j","k","l"], "6":["m","n","o"], "7":["p","q","r","s"], "8":["t","u","v"], "9":["w","x","y","z"]}
        if (len(digits) == 1):
            return letter[digits]
        result = []
        def backtracking(res : string):
            if (len(res) == len(digits)):
                result.append(res)
                return
            for i in letter[digits[len(res)]]:
                backtracking(res + i)
        backtracking("")
        return result

🚧 드디어 백트랙킹 방식의 약 90퍼쯤 온 것 같다. 주로 백트랙킹 알고리즘을 dfs, bfs등 트리에 대한 알고리즘으로 선택을 했었기에 string에 대한 순회방식과 함께 사용하는 게 어색했다.

🚧 비어있는 digits와 하나의 number에 대한 리스트를 리턴하는 방식은 이전 풀이와 같다.

🏗 result : 결과를 return해줄 리스트 🏗 res : 백트랙킹 함수에서 사용하는 하나의 문자열.

🚧 이번에는 힌트에 따라서 뒤부터가 아닌 앞부터 뜯어보기로 했다.

🚧 그리고 이전의 재귀함수에서는 리스트 자체를 리턴해줬는데, 백트랙킹함수에서는 함수 바깥에 리턴해줄 리스트 하나를 만들어두고, 함수 내부에서는 하나의 string에 대해서만 추적했다. 그래서 이전 풀이의 재귀함수에서는 digit 1개당 1번의 재귀를 호출했지만, backtracking함수에서는 string마다 1개의 char에 대해서 1번의 재귀함수를 호출했기 때문에, depth는 비슷하지만 재귀함수를 호출하는 횟수자체가 달라진다. 그림으로 표현하면 이렇다.

그래서 풀이과정에서, backtracking("") backtracking("ad") 이런식으로 전달한다.

🚧 하나의 string이 완성되었는지, 아닌지를 판단하는 기준은 digits의 길이와 같은지 아닌지이다. 재귀를 들어가기전에 맨 앞의 digit에 대해서 문자열을 세팅하고, 재귀에 들어가서 두번째 digit에 대해서 세팅하고, 알파벳 리스트의 길이만큼 다시 backtracking을 호출한다.

풀이 결과

결과적으로 런타임 실행속도에서 많이 좋아졌다. 그리고, 스트링을 재귀하는 방식과 리스트를 재귀하는 방식을 비교하는 그림을 그리다보니 사실상 리스트를 재귀하는 방식은 재귀함수를 썼을 뿐이고 brute force라는 걸 깨달아버렸다. 크흡... 아무튼 오늘도 이렇게 알고리즘 하나 풀기 완료 ⭐️

Top Interview 150 중 36. Valid Sudoku

🍿 난이도 : 리트코드 기준 Medium 🚧 알고리즘 : 행렬(matrix)

🚦 풀이1 🚦

class Solution:
    def isValidSudoku(self, board: List[List[str]]) -> bool:
        def checkRow(row):
            checklist = []
            for i in range(9):
                if (row[i] != "." and row[i] in checklist):
                    return False
                checklist.append(row[i])
            return True
        def checkCol(board, col):
            checklist = []
            for i in range(9):
                if board[i][col] != "." and board[i][col] in checklist:
                    return False
                checklist.append(board[i][col])
            return True

        # row checking
        for i in range(9):
            if (checkRow(board[i]) == False):
                return False

        # column checking
        for j in range(9):
            if (checkCol(board, j) == False):
                return False

        # box checking
        for k in range(0,9,3):
            for m in range(0,9,3):
                if (checkRow(board[k][m:m+3] + board[k+1][m:m+3] + board[k+2][m:m+3]) == False):
                    return False

        return True

🚧 python의 list 자료구조를 사용했다.

🚧 하나의 list를 체크할 때는 checkRow를 사용했고, column checking과정에서는 각각 하나의 원소씩 체크했다. checklist라는 새로운 list를 만들어서 원소를 삽입했고, 만약 삽입과정에서 중복이 발생했을 경우에는 바로 false를 리턴했다.

🚧 이중배열로 구성된 board가 valid한지 확인하기 위해서 row, column, box 형태 순서로 체크했고, 체크 과정에서 문제가 발생하지 않았다면 True를, 한번이라도 False가 발생했다면 즉시 False를 리턴했다.

풀이 결과

생각보다 메모리 사용량도 많았고, 런타임시간도 오래걸려서, 다른 사람들의 솔루션을 보고 바꿔봤다.

🚦 풀이2 🚦

class Solution:
    def isValidSudoku(self, board: List[List[str]]) -> bool:
        def checkRow(row):
            if (len(set(row)) != len(row)):
                return False
            return True
        def checkCol(board, col):
            column = []
            for i in range(9):
                column.append(board[i][col])
            return checkRow([i for i in column if i != '.'])

        # row checking
        for row in board:
            if (checkRow([i for i in row if i != '.']) == False):
                return False

        # column checking
        for j in range(9):
            if (checkCol(board, j) == False):
                return False

        # box checking
        for k in range(0,9,3):
            for m in range(0,9,3):
                box = board[k][m:m+3] + board[k+1][m:m+3] + board[k+2][m:m+3]
                if (checkRow([i for i in box if i != '.']) == False):
                    return False
        return True

🚧 위의 풀이와 비슷하게 python의 list 자료구조를 사용했다. 이번에는 checklist라는 새로운 배열을 사용하지 않고 [i for i in column if i != '.']와 같은 list comprehension으로 함수를 호출했다.

🚧 중복값이 있는지 확인하는 과정에서도 if (len(set(row)) != len(row)): 와 같이 set을 사용한 뒤 두 값의 길이를 비교했다. set이 중복값을 삭제시키므로, 두 값의 길이가 같지 않으면 중복값이 있었다는 뜻이 된다.

풀이 결과

런타임 기준에서 약 15프로 개선되었지만 메모리 사용량에서는 25프로정도 감소했음을 볼 수 있다. 한번 더 다른 사람의 코드를 보고 개선했다.

🚦 풀이3 🚦

class Solution:
    def isValidSudoku(self, board: List[List[str]]) -> bool:
        sudoku = []
        for i, row in enumerate(board):
             for j, num in enumerate(row):
                if num != '.':
                    sudoku += [(i, num), (num, j), (i // 3, j // 3, num)]
        # print(sudoku)
        return len(sudoku) == len(set(sudoku))

🚧 python의 list, tuple을 사용했다.

🚧 enumerate(board)같은 파이썬 내장함수 enumerate를 사용했다. enumerate() 함수는 인덱스와 원소로 이루어진 튜플(tuple)을 만든다. 문제에서 제시한 첫 번째 예제라고 했을 때 enumerate(board)의 첫 번째 결과는 (0, ['5', '3', '.', '.', '7', '.', '.', '.', '.'])가 될 것이다.

🚧 row, column, box일 때의 튜플을 각각 sudoku list에 저장한 뒤 set했을 때의 길이와 실제 길이를 비교해서 return했다. box일때는 9칸을 1칸으로 보고 거대한 3*3 array라고 생각하고 첫번재 칸을 (0, 1)인덱스로 지정해서 튜플을 생성했다.

풀이 결과

일단 코드 길이가 어마어마하게 짧아졌다... 와우 결과적으로도 런타임 실행속도에서 많은 개선이 일어났다.

Top Interview 150 중 20. Valid Parentheses!

🍿 난이도 : 리트코드 기준 Easy

🚦 풀이1 🚦

class Solution:
    def isValid(self, s: str) -> bool:
        stack = []
        for i in s:
            if (i == "(" or i == "{" or i == "[") : 
                stack.append(i)
                continue
            if (len(stack) and i == ")" and stack[-1] == "("):
                stack.pop()
                continue
            if (len(stack) and i == "}" and stack[-1] == "{"):
                stack.pop()
                continue
            if (len(stack) and i == "]" and stack[-1] == "["):
                stack.pop()
                continue
            stack.append(i)
        if (len(stack)):
            return False
        return True

🚧 알고리즘 : 구현

🚧 stack구현을 위해서 python의 list 자료구조를 사용했다. 🚧 여는괄호인 (, {, [일경우 stack에 추가해주고, 닫는 괄호일경우 stack에 마지막으로 들어간 괄호와 비교해서 삭제해주거나, 맞지 않을 경우 stack에 추가해주었다. 🚧 마지막에 stack의 길이를 체크해서 만약 stack에 남은 값이 있을 경우 false를, stack이 비었을 경우 true를 리턴해주었다.

풀이 결과

🚦 풀이2 🚦

class Solution:
    def isValid(self, s: str) -> bool:
        stack = []
        check = dict({'()','{}','[]'})
        for i in s:
            if i in '({[' :
                stack.append(i)
                continue
            if not stack: #empty list is fals in if not :
                return False
            if (i == check[stack[-1]]):
                stack.pop()
                continue
            else : 
                return False
        return not stack

🚧 알고리즘 : 구현

🚧 위의 풀이와 비슷하게 stack을 사용했지만 추가로 python의 dict 구조도 사용했다.

🚧 dict({'()','{}','[]'}) 의 결과가 {'(': ')', '[': ']', '{': '}'} 이렇게 생긴 dictionary를 만든다는 것을 처음 알았다. 딱 2글자의 string들로 이루어진 tuple에 대해서만 변환이 된다.

🚧 if문들이 체크하는 공통적인 조건인 stack에 남은 값이 있는지 없는지를 빼서 하나의 조건문으로 만들었다. if not stack: 이 조건문은 list에 대해서 체크하는데, list가 비어있을 경우 True가 되어 최종적으로 함수에서 False를 리턴한다.

풀이 결과

런타임에서 10%정도 개선되었지만 보다 메모리 사용량에서 상당부분 사용했음을 알 수 있다. 아무래도 자료구조를 1개의 리스트만 사용하던 1번 풀이법보다 2번 풀이법이 자료구조 개수가 증가해 더 많은 메모리를 사용한 것 같다.

image를 pull받아서 container run시키기 근데 나의 이미지로 container를 만들 수는 없을까?

나의 도커 이미지 만들기

방법은 2개

1. container를 수정하고, commit하기

2. 원하는 방식으로 dockerfile을 작성하고 build하기

Q. commit과 build의 차이는? 둘다 결과적으로 이미지를 만드는 명령어이다. commit : 이미 사용하고 있는 컨테이너가 있을 때 이미지로 만드는 것 ( 백업 느낌) build : 도커 파일을 바탕으로 구체적으로 시간순서에 따라서 새로 이미지를 생성하는 것

도커파일을 이용하면 어떤 과정을 통해서 이미지가 만들어졌는지 분명하게 이해할 수 있다. 나뿐만 아니라 남들도 마찬가지!

이번 수업은 빌드가 위주이지만, commit도 보긴해야지

웹서버 이미지를 만들고 싶다.

진짜요? 그래요.그럼 만듭시다.
같은 이미지를 commit 방식과 build방식 두가지로 만들어보아요

vscode기능중에 docker확장기능 추천

commit 방식

• ubuntu 20.04 이미지 다운로드 후 컨테이너 생성 docker run -p 8888:8000 --name web-server -it ubuntu:20.04
• web-server컨테이너를 web-server-commit 이름으로 이미지 생성 docker commit web-server web-server-commit
• 이미지 생성확인 docker images
• 컨테이너 안으로 이동
• 파이썬3 다운로드 apt update apt install python3
• 이순간에 커밋하면 이미지 생성가능
• 사용자 요청을 저장할 디렉토리 생성하기 mkdir -p /var/www/html cd /var/www/html
• index.html 파일 생성 echo "Hello, <strong>Docker</strong>" > index.html ls
• python3에 내장된 웹서버를 실행하고, 8000번 포트를 리스닝 python3 -m http.server
• http://0.0.0.0:8888 로 접속하면 작성한 index.html이 보인다.

build 방식

• ** docker file 생성 **

  FROM ubuntu:20.04 //기본 이미지를 ubuntu로 설정
  RUN apt update && apt install -y python3 //파이썬 3 다운로드
  WORKDIR /var/www/html //directory가 없다면 만들고, 그 위치로 이동시킴
  //이제부터 실행하는 run, entrypoint, cmd같은 명령어가 실행될때는 저 디렉토리 위치에서 실행됨.
  COPY ["index.html", "."] //host에 있는 index.html을 WORKDIR로 복사하기
  ==== 이미지 생성 끝
  CMD ["python3", "-u", "-m", "http.server"] //-u 옵션을 포함시켜야만 실행중인 현재 상태의 로그가 화면으로 출력됨
  ==== 컨테이너 실행 후 실행

  
  

• 이미지의 이름을 -t(tag)로 설정후 pwd에 위치시키기 docker build -t web-server-build .

• build 후 container 실행 docker rm --force web-server; docker run -p 8888:8000 --name web-server web-server-build;

• http://0.0.0.0:8888 로 접속하면 host디렉토리에 작성한 index.html이 보인다.

• 컨테이너 실행시 CMD를 실행하고 싶지 않다면 pwd를 쓰기 pwd가 cmd대신에 실행되어서, 시작명령을 변경할 수 있음 (overriding) docker run -p 8888:8000 --name web-server web-server-build pwd;

RUN 명령어는 실행될 때마다 layer가 생성된다. 따라서 가급적 하나의 명령어로 연결실행하는게 유리하다. RUN apt update; RUN apt install python3;보다 RUN apt update && apt install python3으로 실행시키는 걸 추천

index.html을 생성하는, 다른 방법이 있다. (commit과 유사) RUN echo "Hello, <strong>Docker</strong>" > index.html 이렇게 작성하면 WORKDIR로 설정한 디렉토리 아래에 생성이 된다. 하지만, dockerfile이 있는 같은 디렉토리에 index.html 파일을 만들어서, 도커파일이 build될 때 index.html파일을 host에서 image로 복사할 수 있으면 더 좋겠죠? 왜죠? 이전에 도커 볼륨에서 학습했음

dockerfile에 의해서 만들어진 image를 container로 생성할 때 명령어를 실행해서 바로 웹서버를 사용할 수 있는 상태가 되길 바란다면, 도커파일에 CMD명령어를 이용

이제 도커 이미지를 생산하는 생산자가 되었음 와우아

🤦‍♂️찾아봅시다

Q. python3 -u -m http.server 명령어의 뜻은? 원래 http.server는 파이썬이 일반적으로 제공하는 모듈중 하나인데, -m 옵션과 함께 실행하면, 직접실행이 가능하다. 평소엔 확장자가 py인 파일에 import해서 사용해야함. python3 -m http.server 의 기본 포트는 8000 이고, 만약 변경하고 싶으면 뒤에 포트번호를 써주면 된다. ex) python3 -m http.server 9000

Q. 포트포워딩을 하지 않고 run 했을 때 http://0.0.0.0:8000은 왜 접속이 안되는지? 왜냐면 컨테이너의 포트와 호스트의 포트가 연결되지 않았기 때문! 이해가 되지 않는다면 도커 입문으로 가시죠

Q. 왜 run명령어 뒤에 pwd를 붙이면 CMD명령이 있는데도 일회성으로 실행이 되는지? Q. CMD명령을 여러개를 쓸수 있나? Q. 만약 CMD명령이 여러개였다면 모두 실행이 안되고 pwd가 실행이 되는걸까? 세 개의 질문을 묶어서 설명해보자. CMD명령은 컨테이너가 생성될 때 단 하나의 유효한 값을 갖는다. 그래서 이미 CMD명령이 있었더라도, 이후에 다른 CMD명령어가 입력된다면 이전의 값 대신에 실행된다. 따라서 가장 마지막에 입력된 CMD명령인 pwd가 실행되는 것이다. 원한다면, dockerfile내부에 CMD명령을 여러 개 쓸 수 있다! 그러나 여러 줄을 쓸 경우, 가장 마지막 명령만 유효하게 실행된다. 어떻게든 여러개를 한번에 실행하고 싶다면 > 여기를 참고하자. CMD명령에 대한 doc페이지

• 추가로 알게 된 지식 : CMD echo "This is a test." | wc - 이렇게 명령어 형식으로도 쓸 수 있다. 명령어 형식으로 쓸 경우 /bin/sh -c 상황에서 실행되게 된다. json array형식으로 작성하면 shell없이 실행된다.

Q. build로 생성한 이미지로 실행중인 컨테이너도 commit이 가능한지? 논리적으로 생각해보면, build로 생성한 이미지나 commit으로 생성한 이미지나 같은 이미지 타입일 것 같다. 따라서 가능하지 않을까? => 가능합니다! 빌드된 이미지 파일로 실행한 컨테이너 파일시스템에서 새로운 파일을 생성하고 commit하니, 이미지 레이어가 하나 더 생기고, 새로운 이미지로 commit됩니다 :)

Q. mkdir -p /var/www/html에서 -p옵션의 의미는? 필요하다면 경로 중간의 디렉토리를 rwxrwxrwx 권한으로 생성한다. 만약 -p 옵션이 주어지지 않았을 때는 경로에 쓰여진 모든 디렉토리가 존재해야만 에러가 발생하지 않는다.

Q. commit 은 어느범위까지 저장(백업)이 되는지? 파일? 실행중인 프로세스? 변경된 컨테이너의 file 혹은 settings 에 대해서 저장된다.

Q. 이미지는 어떤 위치에 주로 저장하는지? (docker build시) docker가 설치된 가상환경에서, 기본 Docker 경로 /var/lib/docker에 저장된다.

Q. ENTRYPOINT는 무엇인가? CMD명령문과 같이 컨테이너가 실행하게 될때 수행하게 되는 명령을 정의하는 명령문이다. CMD와 다르게, 컨테이너 시작시 실행명령에 대한 Default값을 지정하게 되는데, 그래서 변경이 CMD보다 어렵고, 해당 컨테이너가 실행될 때 반드시 ENTRYPOINT에서 지정한 명령을 수행한다. 만약 ENTRYPOINT가 지정되었다면, CMD는 추가 인자값으로 활용된다. 예를 들어, df -h가 entrypoint로 지정되고, ps -aef가 CMD값으로 지정되었다면, 컨테이너가 실행될 때 df -h ps -aef로 실행된다. 따라서, 메인 프로세스인 ENTRYPOINT에서 실행한 명령어에 대한 옵션값을 CMD로 정의해주면 좋다. > 참고

Q. RUN명령어 실행시에 만들어진다는 layer는 무엇일까? 이미지는 레이어로 구성되어있고, 파일이 추가되거나 수정되면 새로운 레이어가 생성된다. 그래서 pull받을 때 여러줄로 분리된 것처럼 받아지는데, 여기서 한 줄씩 분리된 데이터를 Layer라고 한다. layer는 이미지에 따라 구성이 다른데, 예를 들어 ubuntu 이미지는 1개의 레이어가 있고, nginx 이미지는 5개의 레이어가 있다
Dockerfile에 정의된 명령문 중에 (RUN, ADD, COPY) 3가지 단계만이 레이어로 저장된다. (CMD, LABEL, ENV, EXPOSE) 등 메타정보를 다루는 명령문은 임시레이어로 생성은 되지만 저장되지 않아서 도커 이미지 사이즈에 영향을 주지 않는다. 레이어를 pull 이후에 확인해보고 싶다면 docker inspect [image 이름]을 실행하면 layer, env등의 정보를 볼 수 있고 docker history [image 이름]을 실행하면 이미지에 포함된 layer들에 대해서 자세히 보여준다. 이미지를 생성할 때 Layer가 쌓이게 되면 파일을 삭제해도 이미지 사이즈는 줄어들지 않는다. 따라서 layer수를 줄이는 것은 이미지를 가볍게 만들 수 있는 가장 핵심적인 방법중 하나다.

• 컨테이너를 생성할 때도 기존의 이미지 레이어 위에 쓰기가 가능한 레이어를 추가 하는데, 이부분에 대한 추가 설명이 필요하다면 > 여기

Q. ubuntu:20.04 에서 20.04는 태그다. 태그는 무엇일까? 도커에서 이미지의 버전을 관리하기 위해서 사용하는 이미지에 부여되는 별칭이다. 일반적으로 버전 관리를 위해 latest태그보다는 patch number나 git commit을 활용한다. 따라서, 여기서 20.04는 우분투 이미지의 버전을 의미한다. image생성시 tag명 지정을 생략하면 default값으로 마지막에 build/tag된 이미지라는 뜻의 latest태그가 붙는다.

• 주의사항 latest 태그가 언제나 가장 최신 버전을 의미하지는 않는다. (tag가 없는 image에 디폴트로 주어진 값일 수도 있으므로)

push

원하는 이미지를 바탕으로 컨테이너가 잘 생성된다면, docker hub 에 push 명령어를 통해서 이미지를 레지스트리에 공유해봅시다.

• 주의사항 : docker hub는 github와 유사합니다. 미리 가입을 해야합니다.

참조

생활코딩 도커파일 생활코딩 도커 commit 읽어볼거리

vmware, virtualbox와 같은 가상 머신처럼 독립된 실행환경을 제공하면서도, 컴퓨터에 직접 애플리케이션을 설치한 것과 같이 빠르고, apt, npm, pip 처럼 명령어 한줄로 원하는 앱이 포함된 실행환경을 손쉽게 설치할 수 있는 환상적인 개발환경을 제공하는 툴.

웹서버를 구동해보기

1. 세개의 컴퓨터에 운영체제부터 설치 -> 잘 안됨
2. 하나의 컴퓨터에 가상으로 컴퓨터를 만들고, 운영체제를 만든후에 웹서버를 설치하기-> 이게 가상머신 (vmware, virtualbox) 웹서버를 위해서 가상머신을 설치한다면? 굉장히 느려진다!!
3. 한대의 컴퓨터 안에서 각각의 앱을 격리된 환경에서 실행시키기 호스트에서 실행되는 격리된 각각의 실행환경 = 컨테이너 각각의 컨테이너에는 운영체제 전체가 아닌 앱을 실행하는데 필요한 라이브러리/ 실행파일만 포함된다. 그래서 무척 가벼워짐!! 운영체제가 하나니까 속도도 빨라지고, 저장장치의 용량도 아낄수 있다. 이런 컨테이너를 제공하는 툴중에 하나가 도커.

🤦‍♂️** 찾아봅시다**

Q. 도커와 가상머신의 차이점, 공통점은 뭔가요?

• 공통점 : 하나의 물리적 공간에서 여러가지 서비스를 사용할 수 있게 하기 위해서 독립적인 공간을 생성한다.
• 차이점 :

  가상머신 VM	도커 Docker
  호스트 운영체제를 공유 x	호스트 운영체제를 공유 O
  보안적 측면에서 유리	보안위험, 취약점 많음
  여러 운영체제 환경에 유리	단일 운영체제 환경에 유리
  가상머신은 하나의 독립된 컴퓨터를 컴퓨터 안에 생성하는 것이라서, OS, binary, Library등 여러가지 필수로 들어가야 할 정보들의 있기 때문에 무겁다. 도커 엔진 위에서 도커 image를 실행시켜서 독립된 App을 실행시키는 원리이기 때문에 훨씬 가볍다.
  보안적 측면에서 보면, VM은 운영체제를 공유하지 않기 때문에 호스트 커널에서 분리가 되므로 도커에 비해서 안전하다. 반대로 도커는 호스트 커널을 공유하고, 리소스도 공유되기 때문에 하나의 컨테이너에 접근가능하면 클러스터에 속한 모든 컨테이너에 접근이 가능해지므로, 보안 위험과 취약점이 많다.
  도커의 경우에는 이식성이 뛰어나고, 영구적으로 리소스를 할당할 필요가 없고, 심지어 운영체제도 설치할 필요가 없기 때문에, 컨테이너를 확장하고, 복제하는것도 가상시스템에 비해 간단하다.

• 따라서, 도커는 단일 운영체제에서 여러 응용프로그램을 실행하려는 경우에 더 적합하고, 서로 다른 운영체제환경에서 실행해야하는 어플리케이션이나 서버가 있는 경우에는 VM이 더 적합할 수 있다.

Anyway, 도커를 쓰십시요.

도커 설치

도커를 이용하기 위해 알아야할 것

컨테이너 기술은 리눅스 운영체제 기술이다.

1. 그러므로, 컨테이너와, 컨테이너에서 동작하는 앱들은 모두 리눅스 운영체제에서 동작한다는 뜻.
2. 만약 내 컴퓨터가 리눅스 운영체제가 아니라면? 그래도 괜찮다! 윈도우, 맥 OS위에 가상머신을 깔고 가상머신에 linux를 깔면 되니까 ** 도커는 리눅스 운영체제 기반으로 만들어졌으므로, 리눅스 운영체제상에서는 괜찮지만, **다른 운영체제에서는 가상머신을 이용해야하므로, 속도저하가 발생한다. But, 그걸 감수하고서라도 도커를 설치해서 사용하는게 엄청난 성능향상을 가져온다.

도커는 윈도우 /맥 OS에서 그래픽환경을 지원하는 데스크탑 앱을 제공하지만, 명령어를 이용하는 cli환경에서 docker를 사용하는게 도커를 100% 사용하는 방법이다. 리눅스 OS에서 docker를 쓸 경우 "sudo"를 붙여서 실행해야함. terminal에서 docker images 명령어가 에러없이 작동되면 docker설치가 정상적으로 종료되었다는 뜻이다.

이미지 설치

도커에서는 dockerhub에서 image를 다운로드해서 실행하면 container가 됨.

• docker hub 에서 image를 다운로드 받는것 : pull
• image를 실행시키는것 : run.

Docker Hub apache 웹서버 프로그램 : httpd라는 이미지로 등록되어 있음. docker official image : 도커에서 공식적으로 관리하는 이미지들 태그. Docker Docs : 도커 사용설명서 매뉴얼을 참고해서 명령어를 사용하면 됨.

• dockr hub 에서 httpd 이미지를 pull받기 ( 다운로드 받기 ) docker pull httpd
• image 현황 확인하기 docker images

이제 수많은 도커 이미지들을 다운로드받을 수 있게 됨!

컨테이너 실행

run : 이미지를 기반으로 컨테이너를 실행시키는 명령어. run 명령을 실행할 때는 컨테이너들의 이름을 서로 헷갈리지 않게 지정하는게 중요함! 실행중인 컨테이너가 컴퓨터의 자원을 이용하는 중이다 -> 자원의 사용률을 줄이고 싶다면, 컨테이너를 중지시키면 된다. 만약 컨테이너를 아예 삭제하고 싶다면 rm명령어를 이용하기.

컨테이너를 만들고 삭제해보기

명령어 정리

• httpd 기반으로 컨테이너를 만들고, 실행하기 docker run httpd
• 실행중인 컨테이너의 상황을 보기 docker ps
• 실행중이지 않은 컨테이너까지 모두 현재상황 보기 docker ps -a
• 새로운 컨테이너 이름을 ws2로 설정해서 생성하기 docker run --name ws2 httpd
• 실행중인 컨테이너를 중지하기 docker stop ws2
• 중지시켰던 컨테이너를 다시 실행하기 docker start ws2
• 컨테이너의 로그를 한번만 출력하기 docker logs ws2
• 컨테이너의 로그를 실시간으로 출력하기 docker logs -f ws2
• 컨테이너를 삭제하기 docker rm ws2

컨테이너 실행과정 실습

docker run httpd 
docker ps 
docker run --name ws2 httpd 
docker stop ws2 
docker ps// 꺼졌는지 확인
docker ps -a
docker start ws2 //이때 로그가 안보임 
docker logs ws2 
docker logs -f ws2
docker rm ws2 //현재 실행중인 컨테이너는 바로 삭제 불가능 -> 에러발생 
//방법 1. 실행중지 후 삭제
docker stop ws2 
docker rm ws2
//방법 2. 강제 삭제
docker rm --force ws2

image를 command line에서 삭제하고 싶을 때 : docker rmi httpd

네트워크 설정

서버 클라이언트, 포트, 네트워크에 대한 기본지식 필요.

도커 없이 웹서버 만들기 :

1. 2개의 컴퓨터 필요 ( 웹브라우저/ 웹서버 용)
2. 웹페이지를 파일로 만들어서 특정 디렉토리에 위치 시키기.
3. index.html파일을 /usr/local/apache2/httdocs/에 위치시킴.
4. 0-65535 포트중에 하나로 들어와야함. (80번 포트를 사용)
5. 웹서버의 주소는 example.com로 가정했을 때,
6. http://example.com:80/index.html 로 접속
7. 80번 포트에서 대기중엔 웹서버에 요청 전달
8. index.html파일을 찾고, 코드를 전달.

도커를 사용해서 웹서버 만들기 :

웹서버를 컨테이너에 설치하기

• docker run httpd host의 80번 포트가 container의 80번 포트와 연결되지 않았기 때문에 http://example.com:80/index.html 로 접속해도 연결되지 않음
• docker run -p 80:80 httpd
• p 80:80은 포트포워딩을 위한 명령어로, 첫 80은 host의 80 포트, 두번째 80은 container의 80포트로, host의 80포트로 들어오는 신호를 container의 80포트로 전송한다는 의미이다.
• docker run -p 8000:80 httpd 호스트의 8000번 포트를 container의 80번 포트로 전송

연결 과정 실습

• docker pull httpd
• docker ps
• docker run --name ws3 --publish 8081:80 httpd 이미지를 만든 사람이 80포트를 기본으로 설정함.
• docker ps 포트포워딩 확인
• http://localhost:8081/index.html 로 접속
• container 로그 확인하기

이제 http라는 어플리케이션을 실행할 수 있는 상태가 됨.

컨테이너 내부에 접근하기

index.html을 편집해서 web app을 만들기 위해서는, container안으로 들어가서 파일을 수정할 수 있어야 한다.

host에서 container안으로 들어가는 방법

1. docker desktop에서 해당 container 의 cli버튼 클릭 시 terminal이 실행되는데, 이때 여기서 입력하는 명령어는 host가 아닌 container내부에서 실행되는 명령어이다.

   pwd host에서 pwd가 아니라 container안에서 pwd실행한거 ls -a container안에 있는 파일을 보여줌

2. terminal에서 접근 sh대신 bash를 쓰고 싶을 경우 : /bin/bash로 실행 (container에 따라서 bash실행이 안되는 경우 sh로 실행하기)
   docker ps docker exec ws3 pwd pwd명령을 컨테이너 대상으로 커맨드 1회 실행 docker exec ws3 -it /bin/sh 이때부터 내리는 명령은 모두 컨테이너 안에서 실행됨.

-it옵션 없이 실행하면, shell프로그램이 실행되자마자 바로 종료된다. exit container에서 host로 나가기

** 🤦‍♂️찾아봅시다 **

Q. -it 옵션의 의미? -i --interactive : 명령어를 입력받을 수 있도록 상호 입출력가능하게 세션을 열어두도록 변경 -t --tty : tty를 활성화해서 셸(shell)을 사용하도록 활성화 (터미널과 유사한 환경을 제공)

web server의 index.html 파일 수정해보기

httpd manual

index.html파일의 경로는 매뉴얼페이지에 적혀있다.

• /user/local/apache2/htdocs/ 폴더로 이동한다.
• 경로에 존재하는 index.html을 읽으려고 하면, vim / nano등의 텍스트 에디터가 설치되어있지 않아서 에러가 난다.
• 원하는 에디터를 설치해서 index.html을 읽고, 내용을 It, workts 에서 Hello, Docker! 로 변경 후 저장한다.
• 웹 브라우저에서 리로드를 해보면, 내용이 변경된 페이지를 확인할 수 있다.

컨테이너안에 있는 index.html파일을 직접 수정할 수 있게 되었습니다. ㄱ와우ㄴ

볼륨

위의 사진처럼, 컨테이너 안의 index.html파일만 수정해서 웹페이지를 변경했는데, 만약 컨테이너가 삭제된다면, 수정된 index.html파일도 삭제된다. 흑흑

• 컨테이너를 사용하는 이유는, 필요할 때 언제든지 생성/ 삭제 가능하기 때문인데, 파일이 컨테이너에 종속되면 그 의의가 사라진다고도 할 수 있다.

만약, host에 있는 특정 폴더와 container의 특정 폴더를 연결하고, host에서 수정했을 때 container에 연동될 수 있다면?

• 너무너무 좋겠다! 버전 관리도 훨씬 쉽고, 실행환경과 파일 수정환경을 분리할 수 있고, 백업 정책 수립도 가능하고, 원하는 ide로 편집도 가능하다.

볼륨 설정 실습

• mkdir ~/Desktop/htdocs && cd ~/Desktop/htdocs
• vi index.html index.html을 원하는 소스로 수정하기 (ex)hello, docker?)
• docker run -p 8080:80 -v ~/Desktop/htdocs:/usr/local/apache2/htdocs/ httpd 파일시스템 연결
• vi index.html index.html 수정하기
• 웹페이지 리로드시 수정된 파일이 보인다.

*🤦‍♂️찾아봅시다 *

Q. 도커 볼륨과 바인드마운트의 차이점이 무엇인가요? 둘의 가장 큰 차이점은, docker가 mount point를 관리해 주느냐의 여부로 나뉜다. 컨테이너화된 개발 환경을 구축하고 싶을 때는 bind-mount가 더 유리하기 때문에 로컬에서 개발할 때는 바인드 마운트 방식이 적합하다.

Q. 지금은 바인드마운트를 사용한것 같은데 과제에서는 볼륨을 써야하나요? subject에 volume2개를 사용하라고 명시되어있어서 yes로 추정 근데 docker-compose 보다보니 아닌거같기도해요..

Q. 컨테이너를 run한 뒤에 나중에 volume 을 설정해줄 수는 없나요? 가능하기는 하다 하지만 권장하지 않음. 컨테이너는 시작시에 볼륨설정을 끝내야하므로, 볼륨을 추가하려면 재시작을 권고한다.

참고

생활코딩 도커입문수업

JAYOON님 의견

<웹서버 구동해보기 파트 첨언> 세 개의 컴퓨터에 운영체제부터 설치하는 게 잘 안 되는 게 아니라 웹 서비스 하나를 위해 컴퓨터 세 개나 필요한 게 문제입니다! 겨우 웹서버를 위해 가상 머신을 설치하는 것 때문에 굉장히 느려지는 게 아니라 host 운영체제 위에 다른 OS 를 설치하니까 느려집니다. 웹 브라우저와 웹 서버는 저수준 언어로 만들어져 있는데 이런 저수준 언어 프로그램을 사용하기 위해 OS 위에 또다른 OS 설치하는 것이 오버헤드가 너무 큽니다.

오늘의 깨달음 (4/5)

1. 웹브라우저와 웹 서버는 저수준이다.
2. Q. exec과 run의 차이점은?
3. 왜 공부할수록 질문만 늘어나는 것 같을까요?

Socket Programming

컴퓨터 네트워크를 대상으로 하는 입출력 행위를 다루는 프로그래밍 socket : 전화기 전화기에 연결되는 번호 : 포트번호 전화기에 번호를 연결 : bind 각 전화기가 전화를 기다리는 상태 : listen 전화기에 전화가 오는 상태 : accept 수화기를 들어서 전화를 연결 : read

1.Socket

프로그램이 네트워크에서 데이터를 송수신할 수 있도록, "네트워크 환경에 연결할 수 있게 만들어진 연결부"가 바로 네트워크 소켓(Socket) 네트워크에 연결하기 위한 소켓 또한 정해진 규약, 즉, 통신을 위한 프로토콜(Protocol)에 맞게 만들져야 함. 보통 OSI 7 Layer(Open System Interconnection 7 Layer)의 네 번째 계층인 TCP(Transport Control Protocol) 상에서 동작하는 소켓을 주로 사용하는데, "TCP 소켓" 또는 "TCP/IP 소켓"이라고 함. (UDP에서 동작하는 소켓은 "UDP 소켓")

2.CLIENT SOCKET & SERVER SOCKET

클라이언트 소켓(Client Socket)과 서버 소켓(Server Socket)의 역할. 데이터를 주고받기 위해서는 먼저 소켓의 연결 과정이 선행되어야 하고, 그 과정에서의 연결 요청과 수신이 각각 클라이언트 소켓과 서버 소켓의 역할. 마치 클라이언트 소켓(Client Socket)과 서버 소켓(Server Socket)이 태생적으로 구조가 다른, 전혀 별개의 소켓(Socket)인 것처럼 보일 수 있지만, 두 소켓(Socket)은 태생적으로 동일함. 소켓의 역할과 역할에 따라 처리되는 흐름, 즉, 호출되는 API 함수의 종류와 순서들이 달라서 다르게 부르는 것이고, 전혀 다른 형태의 소켓이 아님.

3.연결 순서

두 개의 시스템(또는 프로세스)이 소켓을 통해 네트워크 연결(Connection)을 만들기 위해서는, 최초 어느 한 곳에서 그 대상이 되는 곳으로 연결요청이 선행. IP 주소와 포트 번호로 식별되는 대상에게, 자신이 데이터 송수신을 위한 네트워크 연결을 수립할 의사가 있음을 알리는 것.

한 곳에서 연결 요청을 보낸다고 하더라도 그 대상 시스템이 그 요청을 받아들일 준비가 되어 있지 않다면, 해당 요청은 무시되고 연결은 만들어지지 않음.

4.클라이언트 소켓의 실행흐름

클라이언트 소켓(Client Socket)은 처음 소켓(Socket)을 1.생성(create)한 다음, 서버 측에 2.연결(connect)을 요청. 그리고 서버 소켓에서 연결이 받아들여지면 데이터를 3.송수신(send/recv)하고, 모든 처리가 완료되면 소켓(Socket)을 4.닫는다(close).

5.서버 소켓의 실행흐름

소켓(Socket)을 1.생성(create)하고 서버가 사용할 IP 주소와 포트 번호를 생성한 소켓에 2. 결합(bind). 그런 다음 클라이언트로부터 연결 요청이 수신되는지 3.주시(listen)하고, 요청이 수신되면 요청을 4.받아들여(accept) 데이터 통신을 위한 소켓을 생성. 일단 새로운 소켓을 통해 연결이 수립(ESTABLISHED)되면, 클라이언트와 마찬가지로 데이터를 5.송수신(send/recv)할 수 있습니다. 마지막으로 데이터 송수신이 완료되면, 소켓(Socket)을 6.닫는다(close).

6.서버소켓 프로그래밍

BIND

각 소켓은 시스템이 관리하는 포트번호들 중 하나의 포트 번호를 사용하게 되는데, 이 번호가 중복될 경우 어떤 포트로 수신된 데이터가 어떤 소켓을 위한건지 알수 없게됨. 소트가 중복된 포트 번호를 사용하지 않도록, 내부적으로 포트번호와 소켓연결 번호를 관리 -> 만약 다른 소켓이 해당 번호를 사용하고 있다면 에러를 리턴함. 일반적으로 서버소켓이 고정된 포트번호를 사용. => 이제 클라이언트의 연결요청을 수신할 준비가 됨.

LISTEN

클라이언트의 연결요청이 수신되기를 기다리는 곳. 서버 소켓에 바인딩된 포트번호롤 클라이언트의 연결 요청이 있는지 확인하면서 대기상태에 머무름. 요청이 수신되면, 대기상태를 종료하고 리턴함. listen이 대기상태에서 빠져나오는 경우는 2가지 1. 클라이언트의 요청이 수신된 경우, 2. 에러가 발생한 경우 (소켓이 close됨) 리턴되는 값으로 클라이언트 요청이 수신되었는지, error로 인한건지 확인 가능 (client에 대한 정보는 포함 x)

ACCEPT

소켓 연결을 실질적으로 수행하는 절차. 데이터통신을 위해 연결되는 소켓이 bind, listen에서 쓰는 소켓이 아님에 주의해야함. accept내부에서 연결을 위해서 새로 만들어지는 소켓에 연결됨.

POLL

동시에 여러개의 I/O를 대기할 경우에 특정한 fd에 blocking되지 않고 I/O를 할 수 있는 상태인 지를 모니터링하여 I/O 가능한 상태의 fd인지를 검사하는 함수. 대기하고싶은 특정fd에 대해서 저장하고있는 pollfd라는 구조를 인자로 넘긴다.

int poll(struct pollfd *fds, nfds_t nfds, int timeout);

poll 함수 reference

FCNTL

파일 컨트롤 함수로, 열려 있는 파일의 특성을 변경하기 위해 사용하는 함수. F_SETFL : arg 에 지정된 값으로 파일지정자 fd 의 플래그를 재 설정한다. 리눅스에서 이 명령은 O_APPEND, O_ASYNC, O_DIRECT, O_NOATIME, O_NONBLOCK 플래그만 바꿀 수 있다. O_NONBLOCK : read/ recieve시에 기다리지 않고 바로 리턴하게하는 플래그.

int fcntl(int fd, int cmd, int arg); 

한국어로는 기수정렬로 bucket sort의 일종으로, 기수별로 비교없이 수행하는 정렬 알고리즘이다. 끝자리부터 각 자릿수를 비교하여 정렬해나가는 방식으로 비교가 없다는 것이 특징이다. 유효숫자가 두개 이상인 경우, 모든 숫자요소에 대해서 수행될 때까지 각 자릿수에 대해서 반복된다. => 따라서, 전체 시간복잡도 : O(nw)(n은 숫자의 개수, w는 기수의 크기) 이다

기수란 기수법에서 말하는 수학적 용어로, 기수법(記數法, numeral system)은 수를 시각적으로 나타내는 방법인데, 기수법을 통해서 나타나는 각각의 숫자는 다른 수들과 구별되는 표기 방식을 가진다. 고대에는 각 나라별로 로마숫자, 그리스 숫자, 한자, 아라비아 숫자등이 사용되었지만 현대에 이르러서는 2진법, 10진법, 60진법등을 주로 사용하며, 대부분의 숫자는 10진법으로 표기된다. 따라서, 기수법은 쉽게 진법이라고 생각할 수 있다.

EX) 10진법의 숫자 10개

87, 487, 781, 100, 101, 0, 1, 512, 66, 24의 숫자들을 정렬한다고 생각해보자. 우선 기수정렬에는 기수 테이블의 크기만한 메모리가 더 필요하다. 기수테이블에는 각 진법에서 필요한 수들의 바구니가 있다고 생각하면 되는데, 지금의 예제에서는 10진법의 숫자들이므로 10진법에서 필요한 수인 0,1,2,3,4,5,6,7,8,9에 해당하는 바구니가 있다.

그림으로 보면, 이런식으로 진행된다.

이제 끝자리인 1의 자리부터 정렬을 해보자. 그러면, 각자 순서대로 1의 자리에 위치한 수와 동일한 바구니를 찾아가게 된다. 1의자리의 정렬이 완료되면, 0-9의 순서대로 다시 하나의 배열로 합친다.

다음으로는, 10의 자리수 정렬이 시작된다. 0, 1같은 경우에는 10의 자리수가 0이라고 생각하고 진행된다. 아 그림 하나씩 캡쳐해서 올리기 귀찮으.....

정렬이 되고난 후에는 다시 하나의 배열을 갖게 되고, 이후 100의 자리수 정렬이 시작되고, 100미만의 수들에 대해서는 100의 자리수가 0이라고 생각하고 진행된다.

마지막으로 100의 자리수에대해서도 0-9 순서로 하나의 배열로 합쳐주면, 짜잔- 정렬이 완료된다.

지금은 수의 최대값이 100의자리기 때문에 100의자리까지만 비교를 했지만, 만약 10억자리의 수가 포함된 10진법 10개라면, 최대 10억자리까지 비교를 해야 할 수도 있다.

EX) 2진법의 숫자 5개

다음으로는 컴퓨터가 주로 사용하는 진법인 2진법에 대해서 살펴보자. 5, 3, 4, 1, 2의 숫자들을 정렬한다고 생각해보자, 이 숫자들을 2진법으로 바꿔보면, 101, 011, 100, 001, 010가 된다. 이제 1의 자리수부터 바구니가 0과 1이 있다고 생각하고 진행하면 된다.

♠️ push_swap을 위한 radix sort를 구현

push_swap 과제에서는 우리는 스택A, 스택B만을 이용해야 하고, 명령어를 통해서 2번안에 접근가능한 인덱스는 top과 bottom 뿐이다. 그래서 독립적으로 생각하고 사용할 수 있는 메모리 공간이 A의 위, 아래 B의 위 아래 공간이 있다. 2진법으로 구현할 수도 있고, 3진법으로 구현할 수도 있었지만, 두 가지 방법 모두 계산해보니 2진법으로 구현했을 때의 방법이 명령어 사용개수의 최댓값이 적어서 2진법으로 정했다.

0바구니의 위치와 1바구니의 위치를 지정해준뒤 하나씩 돌려가며 해당 자리수가 0인지 1인지 확인하고, 옮겨주고, 모든 숫자에 대해서 확인이 끝나면 다시 A스택으로 옮기도록 했다.

이때, A의 위는 데이터를 빼내는 곳으로 사용하고, A의 아래는 1바구니를 저장하고, B의 위를 0바구니를 저장한다고 생각했다.

더 자세히 말하자면, 수를 shifting 연산과 bit연산을 이용해서,

for (All of stack_A)
{
    if ((A->stack[A->top] >> i) & 1)
        //ra command 
    else
        //pb command
}

i 번만큼 오른쪽으로 shift한 수가 1일 경우, ra를 하고, 0일 경우 pb를 하게 했다.

정리

요즘 대세는 push_swap을 퀵소트로 3개의 chunk씩 나눠서 푸는 것이지만 나는 스택이 2개면 2개의 메모리 공간을 이용하는 radix로 해야되지 않나? 에 꽂혀서 결국 여기까지 와버렸다... 열심히 명령어개수를 줄여보아도 100점받을 개수까지는 못줄여서 일단 평가를 진행할 예정이다.

이후에 기수정렬로 할 이 글을 읽고 있는 여러분들을 위해 최적화 아이디어 몇개를 써둔다. 이건 단지 아이디어일 뿐이므로, 원하는 정도의 효과를 내지 못할 수도 있다. 당연히...!

1. 3,4,5개에 대해서도 하나의 알고리즘을 가진채 구현했다면, 해당 알고리즘에서 쓰는 명령어 개수보다 작은 개수로 정렬할 수 있는 집합에 대해서 하드코딩을 진행한다. 예를 들어, 2 1 3 4는 알고리즘으로 진행할 경우 5개의 명령어를 사용한다고 하면, 사실 사람이 보면 딱 sa만 하면 된다는걸 아니까. 이런경우들에 대해서 하드코딩해주면 명령어개수가 줄어들지 않을까?

2. radix소트는 "기수"개수에 따라서 시간복잡도, 즉 push_swap에서 요구하는 명령어의 개수가 줄어들게 된다. 따라서, 큰 개수를 여러개의 작은 개수를 가진 chunk로 나눠서 각 chunk를 1-chunk개수로 세팅후 정렬한다. 500개를 정렬할 때 (1-500의 청크 * 1 개 -> 최대 9개의 기수(2^9 = 512) * 1)에 대해서 정렬하는대신 (1- 100의 청크 * 5개 -> 7개의 기수에 대해 정렬(2^7 = 128) * 5)로 을 줄일 수 있지 않을까??

-> 대신 이건 수를 변경하는 순간 원래의 수를 잃게 되므로 저장을 따로 해주던지..아니면 재귀를 이용해서 잘 스택 A에 순서대로 쌓는 방법을 고안하든 해야될듯.

3. 이건, @jibang님의 아이디어인데, radixsort를 하나의 기수에 대해서 진행하지 말고, 여러개의 기수를 묶어서 십진법을 비교해서 하면 어떨까하고 말씀해주셨다. 그러면 기수가 많을 경우 예를 들어 500 -> 기수가 9개 이면 3개/3개/3개로 나눠서 각각 3개짜리 기수에 대해서 radix sort를 진행한다. 각각 a의 바텀, b의 탑, b의 바텀으로 옮기고 거기서 다시 소팅을 해서 합치는 걸로 하면 어떨지...