수단(도구) 보다 목적이 중요하다 목적: 협업을 잘 하기 위해서!

단순히 commit, push 하는 방법을 배우는 것이 아닌, 왜 이것이 필요한지, 어떤 상황에서 사용할 수 있는지 컨셉을 정하고 상황을 시뮬레이션하면서 진행되었다. 실제로 알고 있던 명령어도 상황을 예시로 진행하려고보니 막막한 부분이 있었고, 터미널만을 이용해서 git을 관리했던 적이 없다보니 낯선 명령어도 많았다. 여러번 해보면서 익혀야할 것 같다.

📍 기본실습

기본 과정에서는 Groom IDE를 이용해서 웹으로 터미널을 조작하며 실습이 진행됐다.

필수로 알고 있어야 한다고 말씀해주신 기본명령어들

ls: 폴더 내용을 확인 mv: 파일명 변경, 혹은 파일 이동 cd: (change directory)폴더 이동 pwd: (print working directory)현재 경로를 출력

🚩 오픈소스 프로젝트 pytorch에 개발참여를 한다는 컨셉으로 진행(샘플 디렉토리 이용)

** 🔥 오픈소스 기여 순서 **

1. 개발환경 구축(구름 IDE 컨테이너 생성)
2. fork (github 프로젝트 복사)
3. clone (로컬에 소스 다운로드)
4. 프로젝트 개발 현황 파악/분석 (Reading Skill)
5. 소스 수정한 뒤 commit 히스토리 저장
6. 수정내용 제출 (Pull-Request(PR))

4) Reading Skill -> 오픈소스 Git 프로젝트 읽는법: 누가 제일 많이 개발에 참여했는지 확인하기 (협업하고 소통하기 위해서 확인해야 함, 누구한테 리뷰받고 조언을 얻을 수 있는지 판단)

** git log --oneline | wc -l ** : 전체 커밋 갯수 한 줄 조회 ** git shortlog | -sn ** : 커밋 갯수 많은 사람부터 오름차순 조회 -> 커밋 갯수 많은 사람이 개발에 많이 참여한 사람

git log ** : 커밋 내역 조회 **--oneline : 한 줄로 조회 | : 하이픈으로 구분 시 왼쪽 영역에 우선순위 wc : (word count) 전체 커밋 갯수 확인(수정된 횟수) -l : (line) -- 'mnist/' : 특정 폴더(mnist)내에서 조회 --after=2020-01-01 --before=2020-01-31 : 특정 날짜 내에서 조회 --reverse : 순서 반대로 조회 -p : 히스토리 내역 세부적으로 조회

git shortlog : 커밋 갯수 + 작성자 조회 -sn : (summary, number) 요약, 오름차순 조회

git show '커밋아이디' : 수정사항 확인 grep "diff --git" : ""를 포함하는 내용 조회 git diff : 수정된 내용 조회

👉 커밋 메세지 : 소스 수정의 '이유'를 작성하는 것

Fix : 잘못된 것을 고친 것 Improve : 원래는 잘 되던 것을 개선한 것(예: 10초 -> 5초) Add : 없는 기능, 옵션 추가할 때 Implement : 설계를 구현하는 것(미리 commision된 부분을 구현) Support : 윈도우에서만 가능하던 것 -> 리눅스에서도 가능하게(ARM => x86)

🔥 오픈소스 개발참여 준비

👉 Git 설정하기

git config --global user.name "본인이름" : 이름 등록 git config --global user.email "본인메일" : 메일 등록 git config --global core.editor nano sudo apt install -y nano

git config --list : 등록된 정보 확인 (잘못 입력했을경우 다시 입력하면 덮어쓰기 됨)

👉 Branch 생성하기

git checkout -b '브랜치명' : 브랜치 생성 및 해당 브랜치로 이동 git branch -D '브랜치명' : 브랜치 삭제 rm '폴더명/': 폴더 삭제

👉 토큰 생성하기(push할때 ID/PW 대신 사용)

https://github.com/settings/tokens

1. Generate token 버튼 클릭
2. 토큰명 적기 (예:test)
3. workflow 체크하기
4. 하단 Generate token 버튼 클릭
5. 생성된 토큰 복사하기
6. git push origin '폴더명'
7. username 대신 토큰 붙여넣기
8. password는 그냥 enter 키
9. fork 프로젝트 github 사이트 들어가기
10. 수정한 브랜치 선택하기
11. contribute 버튼으로 PR

❓ git을 통해서 파일을 다루는 방법이 왜 필요한가?

• commit 생성하기 전, 내가 수정한 사항을 체크하고 싶을 때 'git diff'로 조회가능
• 수정한 파일을 복구하고 싶을 때 'git checkout -- 폴더명'를 입력하면 복구 가능

checkout : 히스토리 창고(.git)에서 가져온다는 뜻 (도서관 책을 대출받을 때 사용하는 의미와 비슷하다), 단순히 브랜치 이동하는 명령어가 아님

git commit --amend : 최신 commit에 흡수 소스 수정 -> git add -> commit 생성 -> 놓친 수정사항 발견 -> 기존의 commit을 수정하려면? -> --amend 옵션으로 최신 commit을 수정할 수 있다.

📍 고급실습(rebase/blame)

고급실습에서는 git bash를 이용해 터미널 환경을 구축한 뒤 실습을 진행했다.

👉 rebase가 필요한 상황

여러명이 협업할 때 base commit이 변경될 수 있음 -> base commit이 다를경우 충돌이 발생할 수 있음 -> rebase를 통해 base commit을 최신화 가능

🔥 rebase 사용방법

1. 오픈소스 프로젝트에 commit 추가된 상황
2. 추가된 최신 commit 들을 로컬로 가져온다 git fetch upstream master (pull = fetch + merge) fetch만 하면 .git 히스토리 창고에만 저장
3. 'upstream/master' 브랜치가 자동 생성됨
4. 현재 Base를 최신으로 갱신한다 git rebase upstream/master

👉 2개 commit 있었던 과거로 rewind한 뒤 파일 3개 추가하기

1. git rebase -i --root (i: interactive, root: 최초커밋부터 조회)
2. 두번째 commit 위치에 pick -> edit 으로 수정
3. touch hello_1.c && git add hello_1.c && git commit -m 'test: add hello_1.c'
4. git rebase --continue : 되돌렸던 로그 복원

👉 ** 위에서 추가한 3개의 커밋 1개로 합치기(최초 1개 커밋만 남기기)**

1. git rebase -i --root (i: interactive, root: 최초커밋부터 조회)
2. 세 번째 파일 commit 위치에 pick -> edit 으로 수정
3. git reset --soft HEAD~1 : 최신 커밋 삭제, 내용은 보존
4. git commit --amend : 최신커밋 덮어쓰기 (수정파일에 3번째 파일 추가됨, 커밋메세지 수정)
5. git rebase --continue : 되돌렸던 로그 복원
6. (1~5)반복해서 두 번째 커밋, 첫 번째 커밋과 합치기
7. git status로 상태 확인

reset --soft HEAD~1 : --hard와는 다르게 commit 정보만 삭제하고 파일 변경분은 남겨둔다. git rebase --abort : rebase 작업을 취소하고 원래 상태로 되돌아감 git reset --hard origin/master : 히스토리 전체 원상 복구 하는 방법

❓ blame 기능을 사용하는 이유

1. 특정 소스 라인을 수정해야하는 상황 760번째 라인이 문제가 있다고 판단 => 760번째 라인을 만든 commit을 찾아내서 이해한 다음 => Bug fix commit 생성해서 수정한 뒤 제출
2. 소스 분석 / 리딩
3. 클래스, 함수 추가 => 역추적

👉 충돌상황 해결하는 방법 실습

1. git remote add upstream '클론할 프로젝트 주소' : 포크한 본래 프로젝트 주소 추가하기
2. git fetch upstream master : 새로 추가된 사항 가져오기
3. git rebase upstream/master : 새로 추가된 사항으로 rebase 진행
4. git status : 충돌 상황 확인하기
5. git diff : 수정사항 확인
6. nano README.md : 에디터 이용해서 충돌 부분 수동으로 수정 및 정리하기
7. git add README.md : 수정 파일 올리기
8. git rebase --continue : rebase 돌아가기
9. git push origin master -f : 마스터로 변경사항 강제 푸쉬

기본 ppt / 고급 ppt

안드로이드에서만 슬라이드 클릭시 해당 슬라이드가 활성화되는 오류가 발생 SlideToClickedSlide: true 속성을 넣었을때 실행되는 이벤트인데 SlideToClickedSlide: false 로 속성지정을 해주어도 계속 발생했다..

결론

최신버전이라 안정화가 덜 되어있어 발생했던 버그.. 8버전을 7버전으로 바꾸어주니 사라졌다!

그리고 슬라이드 바깥으로 버튼을 내보내고 싶을 때 슬라이드를 감싸는 부모태그를 하나 더 만들어 슬라이드 바깥으로 버튼을 빼주었었는데 이렇게 하지 않아도 swiper 속성을 static으로 바꾸어주면 가능했다! 하지만 위치를 잡아주기위해 부모태그로 한번 더 감싸고 부모태그에 position:relative값을 줘야 한다.

화면을 가득채우는 팝업페이지를 구현해야해서 높이값으로 100vh를 설정해주었다. PC에서는 문제가 없었지만 모바일에서 확인해보니 스크롤이 생기는 문제가 발생했다.

이유는 모바일 브라우저에서 100vh는 상단 주소창 영역과 하단 네비게이션바 영역을 포함하기 때문이었다.

해결 방법

1. 스크립트를 이용해 스크린 높이값을 구해준 뒤 css에 넣어주는 방식을 이용했다.

//script
funciton setScreenSize() {
  let vh = window.innerHeight * 0.01;

  document.documentElement.style.setProperty('--vh', `${vh}px`);
}

setScreenSize();

//css
height: calc(var(--vh, 1vh) * 100);

또다른 오류

문제가 해결된 줄 알았지만 테스트과정에서 갤럭시탭 가로모드 -> 세로모드 변환시 높이가 정상적으로 돌아오지 않는 문제가 발생했다.

해결방법

2. html, body, body 내부의 가장 상위 태그 에 'height: 100%' 속성을 넣어주었다.

//css
html,body{
    height: 100%;
}
wrapper{
    height: 100%;
}

굳이 스크립트를 사용하지않아도 css만으로 간단히 해결이 가능한 문제였다. 오히려 스크립트를 사용했을 때 오류가 있었던 반면, 스크립트 대신 css를 사용했을땐 다른 오류가 발견되지 않았다. html, css에 대해 쉽게 생각했었는데 일을 하다보니 기본적인 것들이 얼마나 중요한지 깨달아가고 있다.

** 모든 파라미터 가져오는 방법**

const locationSearch = '?name=user&age=20';
const searchParams = new URLSearchParams(locationSearch);

for (const param of searchParams) {
  console.log(param);
}
// 결과
['name', 'user']
['age', '20']

** 전체 URL에서 특정 파라미터만 가져오는 방법 **

const urlParams = new URL(location.href).searchParams;
const name = urlParams.get('name');

console.log(name)

viewport 부분에 'user-scalable=no' 추가하기

• width : 가로 크기 숫자로도 크기 지정 가능함 device-width 로 값을 지정할 경우 기기의 화면 크기에 맞춰짐 height=device-height 값으로 세로크기의 비율도 지정할 수 있음

• initial-scale : 로드되었을 때 줌 레벨

1.0 (= 100%)

• maximum-scale : 최대 줌 레벨 지정 기본값 0.25

• minimum-scale : 최소 줌 레벨 지정 기본값 1.6

• user-scalable : 확대축소 가능한지 yes, no 값으로 지정 기본값은 yes no 값으로 설정할경우 input영역 선택시 확대되는 것을 막고, 사용자가 화면을 확대, 축소하는 것을 방지함

📋 구현내용

✔ 플레이버튼 클릭시 게임 시작 ✔ 당근 클릭 시 카운트 -1, 카운트 0 되면 게임 종료 ✔ 벌레 클릭 시 게임 종료 ✔ 타이머 0초 되면 게임 종료 ✔ 게임 종료시 팝업창 노출, 게임 재시작 가능

새롭게 알게 된 내용

.getBoundingClientRect() 컨텐츠의 x, y, width, height 값을 반환하는 함수 게임필드 영역을 확인하기 위해 width, height 값을 활용했다.

element.matches('selector') element와 selector가 같은지 아닌지 확인해주는 메소드, true, false 반환 이벤트 버블링을 활용해 게임필드영역에 클릭이벤트를 적용하고 클릭된 타겟이 당근, 벌레인지 구별할 때 사용했다.

이전엔 항상 classList.contains()를 사용했었는데 matches로도 같은 기능을 사용할 수 있다는걸 알게됐다.

sound.currenTime = 0; 음악재생 초기화

각 기능별로 클래스 함수를 만들어 모듈화 시켰다. 클래스 함수를 이용하다보니 자연스럽게 this를 이용하고 this의 속성을 경험할 수 있었다. 이론으로만 외우고 있던 this 바인딩.. 클릭이벤트에 함수를 적용하기위해서는 this바인딩이 필요하다. 해당 함수 안에서의 this값이 필요하기 때문! 화살표 함수를 이용하면 따로 바인딩 처리를 해주지않아도 되서 화살표함수를 사용했다.

자바스크립트로 타입 보장하기 Object.freeze() 를 이용해 문자열을 고정문자열로 만들어 주었다. 객체를 동결시키는 메소드로, 내부 속성을 변경할 수 없다는 특징을 갖고 있다. 게임종료시 게임 결과를 win, lose, cancle 문자열로 받아서 각기 다른 메세지를 제공한다. Reason변수에 할당된 속성이기때문에 Reason 입력시 포함하고있는 3가지 속성을 확인가능해 오타를 방지할 수 있고, 자동입력이 가능하다는 장점이 있다.

클라이언트 사이드 렌더링 이란 사용자의 요청에 따라 필요한 부분만 응답 받아 렌더링 하는 방식

• 변경된 부분과 관련된 데이터만 가져오므로 SSR보다 빠른 속도
• 변경된 부분만 요청함으로써 서버의 부담을 줄임
• 첫 화면을 볼 때까지 시간이 오래걸림, 처음에 접속하면 빈 화면만 보임
• app.js가 모든 정보를 담고있음
• SEO 검색엔진에 노출되지않음

장점 : 빠른 속도(초기화면 렌더링시x), 서버 부하 감소, 사용자 친화적 단점 : 느린 초기로딩, SEO에 불리

SSR

서버사이드 렌더링의 약자로, 서버로부터 완전하게 만들어진 html파일을 받아와 페이지 전체를 렌더링 하는 방식

• 모든 데이터가 이미 HTML에 담겨진 채로 브라우저에 전달되기 때문에 검색엔진 최적화에 유리, 빠른 초기 로딩속도
• TTV(Time To View)와 TTI(Time To Interact) 간에 시간 간격이 존재한다. (사용자가 버튼을 클릭하거나 이동하려고 해도 아무런 반응이 없을 수 있음)
• 페이지를 요청할 때마다 새로 고침 되기 때문에 사용자 경험이 떨어짐
• 페이지를 구성하는 모든 리소스를 준비해서 응답하므로 서버 부담 증가

장점 : 검색엔진최적화에 유리, 빠른 초기로딩 단점 : 사용자 친화적이지 않음, 요청응답시 화면 깜빡임, 서버 부하

❓ 렌더링 방식 선택기준

서비스, 프로젝트, 콘텐츠의 성격에 따라 달라진다.

1. SSR

• 상위노출 필요
• 페이지마다 데이터가 자주 바뀌는 경우
• 누구에게나 동일한 내용을 노출

2. CSR

• 개인정보 데이터를 기준으로 노출
• 보다 나은 사용자 경험 제공
• 상위노출보다 고객의 데이터 보호가 더 중요한 경우

Web Storage

key:value 쌍으로 데이터를 저장하고 key를 기반으로 데이터를 조회하는 패턴이다. 영구저장소(LocalStorage)와 임시저장소(SessionStorage)를 따로 두어 데이터의 지속성을 구분하여 응용 환경에 맞는 선택이 가능하다. Web Storage는 기본 웹 환경의 Cookie와 매우 유사한 개념이다.

특징

• 서버 전송이 없다. 저장된 데이터가 클라이언트에 존재할 뿐 서버로 전송은 이루어 지지 않는다.

• 네트워크 트래픽 비용을 줄여준다.

• 단순 문자열을 넘어 객체정보를 저장할수 있다. 문자열 기반 데이터 이외에 체계적으로 구조화된 객체를 저장할 수 있는 점은 개발편의성을 제공해주는 주요한 장점이다. 단, 브라우저의 지원 여부를 확인해 봐야 하는 항목이다.

• 용량의 제한이 없다.

• 영구 데이터 저장이 가능하다.

• 만료 기간의 설정이 없다. 즉, 한번 저장한 데이터는 영구적으로 존재한다.

• Cookie와 마찬가지로 사이트의 도메인 단위로 접근이 제한된다.

localStorage

• 저장한 데이터를 영구적으로 보관할 수 있다. (브라우저를 종료하더라도 다음번에 접속했을 때 그 데이터를 사용할수 있다.)

• 도메인 마다 별도의 localStorage가 생성된다. Windows 전역 객체의 LocalStorage라는 컬렉션을 통해 저장과 조회가 이루어 진다. 도메인만 같으면 전역으로 공유가 가능하다.

sessionStorage

• 데이터가 지속적으로 보관되지 않는다. 현재 페이지가 브라우징 되고 있는 브라우저 컨텍스트 내에서만 데이터가 유지된다.

• Windows 전역 객체의 sessionStorage 라는 컬렉션을 통해 저장과 조회가 이루어진다. 브라우저가 종료되면 데이터도 같이 지워진다. (브라우저가 종료되면 SssionStorage도 삭제)

• 브라우저마다 별도의 sessionStorage가 생성된다. 같은사이트 같은 도메인이라 할지라도 브라우저가 다르면 서로 다른 영역이된다. (브라우저 컨텍스트가 다르기 때문) 브라우저를 하나 더 실행해서 같은 페이지를 실행 했을때, 이 두페이지의 sessionStorage는 각각 별개의 영역으로 침범하지 못한다.

• 자동 임시저장 기능

Cookie

Cookie란 웹사이트에 의해 유저의 컴퓨터에 놓여지는 작은 텍스트 파일들이다. Cookie는 사이트에서 방문한 페이지를 저장하거나 유저의 로그인 정보를 저장하는 등 다양한 방법으로 사용된다. 그리고 문자열만 저장할 수 있다는 제한이 있다.

특징

• 매번 서버로 전송된다. (서버 데이터를 공유) 웹사이트에서 쿠키를 설정하면 이후 모든 웹 요청은 쿠키 정보를 포함하여 서버로 전송된다.

• 제한적인 용량 쿠키는 개수와 용량에 제한이 있는데, 하나의 사이트에서 저장할수 있는 최대 쿠키수와 용량은 20개, 4KB로 제한되어있다. 그러나 쿠키도 하위키를 이용하면 이러한 제한을 일부 해소할수 있지만, 대부분 쿠키의 제한으로 까지 데이터를 저장할 일이 없다.

• 반 영구적으로 데이터 저장이 가능하다 쿠키는 만료일자를 지정하게 되어 있어 만료일자로 지정된 날짜에 쿠키는 제거된다. 만약 만료일자를 지정하지 않으면 Session cookies 된다. 만일 영구 쿠키를 원한다면 만료일자를 굉장히 멀게 설정하여 해결할 수 있다.

💡 서버에 쿠키가 전송되는 이유

서버는 요청 자체만으로 그 요청이 누구에게서 오는지 알수 없기 때문에 응답을 보낼수 없다. 이때 쿠키에 나에 대한 정보를 담아 서버로 보내면, 서버는 쿠키를 읽어서 내가 누군지 파악한다. 쿠키는 서버와 클라이언트 간의 지속적인 데이터 교환을 위해 만들어 졌기 때문에 서버로 계속 전송된다.

persistent cookies

• 만료일을 포함하지 않는다.
• 브라우저 탭이 열려있는 동안에만 저장된다.
• 은행 웹사이트에서 사용한다.

session cookies

• 만료일을 가진다.
• 만료일 까지 유저의 저장소에 저장되고 만료일이 지나면 삭제된다.

데이터 범위 및 보안

WebStorage의 보안은 서로 다른 도메인의 데이터 침범을 막고는 있지만 클라이언트, 즉 사용자를 막고 있지는 않다. 클라이언트는 얼마든지 저장된 값을 임의로 수정이 가능하다. 이것은 쿠키와 동일한 개념이다. 그렇다고 쿠키에 비해 별다른 보안 취약점을 더 가진 것은 아니다. 따라서 개발자는 사용자에 의한 이러한 임의 변경에 항상 예의 주시하고 방어 코드의 작성을 잊지 말아야 한다.

Event Loop는 Call Stack과 Callback Queue의 상태를 체크하여, Call Stack이 빈 상태가 되면, Callback Queue의 첫번째 콜백을 Call Stack으로 밀어넣는 역할을 한다.

• V8 엔진에서 함수가 호출되면 Call Stack에 쌓인다.
• Stack의 선입후출의 룰에 따라 제일 마지막에 들어온 함수가 먼저 실행되며, Stack에 쌓여진 함수는 실행이 완료되면 Call Stack에서 빠져나간다.
• 비동기함수가 실행될 경우 Web API가 호출된다.
• Web API는 비동기함수의 콜백함수를 Callback Queue에 밀어넣는다.
• Event Loop는 Call Stack이 빈 상태가 되면 Callback Queue에 있는 첫번째 콜백을 Call Stack으로 이동시킨다. (이러한 반복적인 행동을 틱(tick)이라 한다.)

JS Engine

자바스크립트 엔진은 Memory Heap과 Call Stack으로 구성되어 있다. 가장 유명한 것이 구글의 V8 engine이다. 자바스크립트는 단일 스레드 프로그래밍 언어이며, 이것은 Call Stack이 한 개라는 이야기다. (한 번에 한 가지씩 일을 처리하는 것을 의미)

• Memory Heap: 메모리 할당이 일어나는 곳
• Call Stack: 코드가 실행될 때 쌓이는곳, stack 형태로 쌓인다.
• stack: 자료구조 중 하나로 선입후출의 룰을 따른다.

Web API

web api는 자바스크립트 엔진이 아닌 브라우저에서 제공하는 API로, 대표적으로 DOM, Ajax, Timeout 등이 있다. 콜스택에서 실행된 비동기 함수는 Web API를 호출하고, Web API는 콜백함수를 콜백큐에 밀어넣는다.

Callback Queue

비동기적으로 실행된 콜백함수(Web API에서 넘어오는 함수)가 보관되는 영역이다.

• Queue(큐): 자료구조 중 하나로, 선입선출의 룰을 따른다.

💡 자바스크립트는 단일 스레드 프로그래밍 언어라 한번에 하나씩 밖에 실행할 수 없지만 Web API, Callback Queue, Event Loop 덕분에 멀티 스레드 처럼 보여진다.

GET 방식은 이름 그대로 무언가를 가져오는 것 POST 방식은 포스트를 붙이듯이 무언가를 만들거나 수정하는 것

• Get은 서버에서 어떤 데이터를 가져와서 보여줄때 사용

• 어떤 값이나 내용, 상태등을 바꾸지 않는 경우에 사용

• 글의 내용에 대한 목록을 보여주는 경우나, 글의 내용을 보는 경우

• Post는 서버상의 데이터 값이나 상태를 바꾸기 위해서 사용

• 글의 내용을 저장하고, 수정하는 경우

📍 GET 방식

• 클라이언트가 서버로 데이터를 요청하기 위해 사용되는 Method
• GET 요청을 할 때 Body 부분은 비어있고 헤더에 Body의 콘텐츠 타입을 명시하는 Content-Type 헤더 필드도 적지 않는다.
• URL뒤에 쿼리 스트링(Key와 Value)을 붙이고 HTTP 패킷의 헤더에 포함해서 서버에 데이터를 요청한다.

특징

• URL에 쿼리 스트링(데이터)을 붙여서 서버에 전송
• 데이터를 Header(헤더)에 포함하여 전송
• URL에 정보들이 그대로 노출되기 때문에 POST 방식보다 상대적으로 보안에 취약
• 캐싱이 가능
• POST 방식보다 상대적으로 전송 속도가 빠름
• 전송하는 데이터양에 한계가 있음 (브라우저마다 GET 요청 길이 제한 존재)
• 브라우저 히스토리에 기록이 남음
• 브라우저마다 글자 수 제한이 있기 때문에 게시판의 게시물, 목록 조회와 같은 간단한 데이터 요청할 때 적합

💡 캐싱이란 한번 접근 후 또 요청할 시 빠르게 접근하기 위해 레지스터에 데이터를 저장시켜 놓는 것

📍 POST 방식

• 클라이언트가 서버로 데이터를 전송해 리소스를 추가하거나 생성하기 위해 사용되는 Method
• POST 요청 시 HTTP 패킷의 헤더에 Body의 콘텐츠 타입을 명시하는 Content-Type 헤더 필드를 포함하고 HTTP 패킷의 Body에는 데이터를 담아서 서버로 전송한다.

특징

• 데이터들을 URL뒤에 붙여서 서버로 보내는 것이 아닌 Body에 담아서 전송
• 요청 헤더의 Content-Type에 콘텐츠 타입을 명시
• 데이터들이 URL에 노출되지 않기 때문에 GET 방식보다 상대적으로 보안적
• 데이터들을 Body에 담기 때문에 서버로 보내는 데이터의 양은 제한 없음
• URL에 데이터가 노출되지 않으므로 캐싱 불가
• 클라이언트에서 인코딩, 서버에서 디코딩
• 요청받는 시간제한 존재
• 브라우저 히스토리에 기록이 남지 않음
• 보통 서버의 값이나 상태를 변경하기 위해 사용되므로 글쓰기, 글 수정과 같은 작업에 적합하다.

👁‍🗨 비교표

💡 멱등성은 연산을 여러 번 하더라도 결과가 달라지지 않는 성질을 의미하며, get 요청의 경우 여러 번 요청해도 응답이 같지만 post 요청의 경우엔 리소스를 새로 생성하거나 업데이트하므로 서버에게 동일한 요청을 여러 번 전송해도 응답은 항상 다를 수 있다.

📍 POST vs PUT

• POST는 INSERT, PUT은 UPDATE
• POST는 멱등하지 않고 PUT은 멱등하다.
• POST는 새로운 데이터를 계속 생성하기 때문에 요청시마다 데이터를 생성하지만, PUT은 사용자가 데이터를 지정하고 수정하는 것이기 때문에 같은 요청을 계속하더라도 데이터가 계속 생성되지 않는다.

📍 PUT vs PATCH

• PUT은 해당 자원의 전체를 교체, PATCH는 일부를 변경
• PUT은 멱등하지만, PATCH는 멱등하지 않다.
• PUT은 전체 자원을 업데이트 하기 때문에 동일 자원에 대해서 동일하게 PUT을 처리하는 경우 멱등하게 처리되는 반면 PATCH로 처리되는 경우 자원의 일부가 변경되기 때문에 멱등성을 보장할 수 없다.

this는 함수를 호출할 때 결정된다. this는 this가 바라보고 있는 객체를 말하며, this의 값은 함수를 호출하는 방법에 의해 결정된다. 누가 호출했나? 누가 = this

전역 공간에서 this가 바라보는 대상

• client(브라우저)에서는 window
• Node.js에서는 global

원하는 대상으로 this binding

• call : 함수를 호출할 때, 원하는 대상의 객체를 인자로 넘겨준다.
• apply : call 메서드와 완전히 같은 기능이나, 호출할 함수에 인자를 배열로 넘겨준다.
• bind : call과 비슷하지만, 바로 호출하는 것이 아니라 대상을 묶어놓기(binding)만 하는 것

arrow function

• this의 대상이 어떤 객체가 호출했느냐로 결정되지 않는다.
• 함수 내부에 this는 없으며, scope chain의 가장 가까운 this로 대상이 결정된다.

처음 코드를 실행(브라우저가 스크립트를 로딩해서 실행하는 것)하는 순간 모든 것을 포함하는 전역 컨텍스트가 생긴다. 전역 컨텍스트는 모든 것을 관리하는 환경으로, 페이지가 종료될 때까지 유지된다.

컨텍스트의 원칙

• 전역 컨텍스트 하나 생성 후, 함수를 호출할 때마다 함수 컨텍스트가 생긴다.
• 컨텍스트 생성 시 컨텍스트 안에 변수객체(arguments, variable), scope chain, this가 생성된다.
• 컨텍스트 생성 후 함수가 실행되면서 사용되는 변수들은 변수 객체 안에서 값을 찾고, 없다면 스코프 체인을 따라 올라가며 찾는다.
• 함수 실행이 마무리되면 해당 컨텍스트는 사라진다. (클로저 제외)
• 페이지가 종료되면 전역 컨텍스트가 사라진다.

클로저

• 함수를 선언할 때 만들어진 scope가 사라진 후에도 scope에 저장되었던 변수를 사용할 수 있는 함수

• 어떤 함수 A에서 선언한 변수 a를 참조하는 내부함수 B를 외부로 전달할 경우, A의 실행 컨텍스트가 종료된 이후에도 변수 a가 사라지지 않는 현상

• 클로저를 통한 은닉화

• 클로저를 사용하여 외부에서 변수에 직접 접근하는 것을 제한할 때 사용한다.

스코프

• 변수가 유효한(살아있는) 범위

• Global Scope

  • 코드 어디에서든지 참조 가능
  • var로 선언한 변수는 전역 객체에 속하게 된다.

• Local Scope

  • scope의 범위는 함수 블록 내이다. ({} 블록과 상관이 없다) = 함수에 의해서만 scope가 생성된다.
  • let, const로 변수를 선언할 때의 scope의 범위는 블록({}) 단위이다.

• 스코프 체인

  • 변수가 해당 scope에서 유효하지 않을 때, 안에서부터 바깥으로만 차례로 검색해 나가는 것

코드가 실행하기 전 변수선언/함수선언이 먼저 메모리에 저장되었다는 것을 의미하며, 곧 해당 스코프의 최상단으로 끌어 올려진 것 같은 현상을 말한다.

• 자바스크립트 엔진은 코드를 실행하기 전 실행 컨텍스트를 위한 과정에서 모든 선언(var, let, const, function, class)을 스코프에 등록한다.

• 코드 실행 전 이미 변수선언/함수선언이 저장되어 있기 때문에 선언문보다 참조/호출이 먼저 나와도 오류 없이 동작한다. (var 변수 선언, 함수선언문일 경우에만 해당)

변수의 호이스팅

• 자바스크립트의 모든 선언에는 호이스팅이 일어난다.

• let, const, class를 이용한 선언문은 호이스팅이 발생하지 않는 것처럼 동작하는 이유

• var 키워드는 선언 단계와 초기화 단계가 한번에 진행되어 메모리에 저장,

• let과 const는 선언 단계와 초기화 단계가 분리되어 진행되며, 초기화되지 않은 상태로 선언만 메모리에 저장되기 때문에 일시적 사각지대에 빠져 호이스팅이 일어나지 않는 것처럼 보인다.

변수 생성 단계

• 1단계: 선언 단계(Declaration phase) 변수를 실행 컨텍스트의 변수 객체에 등록한다. 이 변수 객체는 스코프가 참조하는 대상이 된다.

• 2단계: 초기화 단계(Initialization phase) 변수 객체에 등록된 변수를 위한 공간을 메모리에 확보한다. 이 단계에서 변수는 undefined로 초기화 된다.

• 3단계: 할당 단계(Assignment phase) undefined로 초기화된 변수에 실제 값을 할당한다.

함수선언문과 함수표현식에서의 호이스팅

• 함수선언문은 호이스팅에 영향을 받지만, 함수표현식은 호이스팅에 영향을 받지 않는다.

• 함수선언문은 코드를 구현한 위치와 관계없이 자바스크립트의 특징인 호이스팅에 따라 브라우저가 자바스크립트를 해석할 때 맨 위로 끌어 올려진다.

• 함수표현식은 함수선언문과 달리 선언과 호출 순서에 따라서 정상적으로 함수가 실행되지 않을 수 있다.

  • 함수표현식에서는 선언과 할당의 분리가 발생한다.
    
  • 함수표현식의 선언이 호출보다 위에 있는 경우 - 정상 출력
    
  • 함수표현식의 선언이 호출보다 아래에 있는 경우 (var 변수에 할당) - TypeError : not a function
  • -> 호이스팅에 의해 undefined으로 지정되고, undefined은 함수로 인식되지않은 상태이기때문에 not a function 이라는 오류 발생
    
  • 함수표현식의 선언이 호출보다 아래에 있는 경우 (const/let 변수에 할당) - ReferenceError : not defined
  • -> 호이스팅이 이루어지지않아 선언이 되지 않은 상태이기때문에 not defined 라는 오류 발생

호이스팅 우선순위(동일한 변수명을 사용할 때)

• 변수 선언 > 함수 선언문
• 값이 할당되어 있지 않은 변수의 경우, 함수선언문이 변수를 덮어쓴다.
• 값이 할당되어 있는 변수의 경우, 변수가 함수선언문을 덮어쓴다.

호이스팅 사용 시 주의할 점

• 코드의 가독성과 유지보수를 위해 호이스팅이 일어나지 않도록 한다. (var 대신 let, const 사용하기)
• 호이스팅을 제대로 모르더라도 함수와 변수를 가급적 코드 상단부에서 선언하면, 호이스팅으로 인한 스코프 꼬임 현상은 방지할 수 있다.

Heroku는 한 계정당 5개의 앱을 무료로 호스팅 할 수 있지만 해당 도메인에 몇 시간 동안 접속 요청이 없는 경우에는 앱이 수면 상태로 전환되어, 초기 접속이 느려진다는 단점이 있다. 이런 단점을 보완해주기 위해 일정 시간마다 request를 보내주는 사이트를 이용했다.

전공자도, 관련업계 경험도 전혀 없는 내가 개발자가 되려는 이유

1. 개발을 시작한 계기

2020년 워홀에서 돌아온 뒤 창업을 한 지인을 잠시 도와준 적이 있다. 청년정보를 모두 모아 보여주는 사이트를 만드는게 목표였는데 정말 아무것도 없는 상태에서 막 시작한 상태라 이것저것 함께 의논하는 시간이 많았다. 이때 처음 개발자가 무슨 일을 하는지 조금이나마 경험할 수 있었지만 개발자를 꿈꾸진 않았다. 나에게 개발자란 넘사벽 직업이었기에.. 대신 웹디자이너에 관심이 생겼는데 외주로 맡겼던 디자인시안이 뭣모르고 보니 쉽고 만만해 보였기 때문이다. (배워보니 디자인은 진짜 타고난 센스가 있어야 할 수 있는 것 같다..)

이 회사는 아쉽게도 얼마 안가 폐업하게 되었다. 내가 합류하고 얼마 안 지나 이미 몇 년 전 같은 아이템으로 사업을 시작한 경쟁업체가 있다는걸 발견했기 때문이다. 해당 업체에서는 우리가 하려던 모든 아이템들을 포함해 매우 잘 구성된 사이트를 국가지원을 받으며 운영중이었다. 큰 수익이 있는 모델도 아니었기에 회사는 빠르게 정리되었다.

이후로 나는 기술교육원에서 디자인 관련 툴과 마크업 기술을 배웠다. 코로나로 인해 수업진행에 어려움이 많았지만 이 교육을 통해 나에겐 디자인감각이 없다는 사실을 알 수 있었고, 오히려 코딩에 흥미를 가지게 되어 코딩 공부를 시작하게 되었다.

아직도 개발자라는 직업은 나에게 어렵고 도전적인 직업이다. 공부해보니 더더욱.. 그래서 내가 진짜 개발자가 될 수 있을까? 에 대한 의문도 항상 갖고 있지만 그저 재밌어서 시작하게 되었고 하다보니 계속 더 배우게 되고 지금까지 오게 되었다. 누구에게나 처음은 어렵고 힘들었을 것이다. 이렇게 차근차근 배워가다보면 미래의 나도 진짜 개발자로 성장해 있을거라 기대해 본다.

2. 개발하면서 좋은 점, 힘든 점

좋은점

1. 작업한 결과가 눈에 바로 보인다는 점이 가장 큰 장점인 것 같다. 화면을 통해 내가 작성한 코드가 제대로 작동할 때 큰 성취감을 느낀다.

2. 무료 정보시장 에러코드 검색해보면 해결법이 다 나온다. 잘 정리된 예제들이 많아 필요한 코드를 가져다 쓰기 좋다.

힘든점

1. 계속 앉아서 작업하다보니 체력이 약해지는 것 같다. 짧게라도 시간을 정해서 그 시간엔 무조건 운동을 해야겠다.

2. 문제를 해결할때까지 잠이 안 온다. 계속 봐도 모르겠을땐 잠깐 쉬었다 나중에 보면 해결되는 경우가 있다. 근데 그게 잘 안된다. 이상하게 자려고 누우면 자꾸 새로운 방법이 떠오른다.

3. 똑똑한 사람들이 너무 많다. 비교하고싶지않지만 자꾸 비교되는 대단한 사람들이 너무 많다. 내 길을 가자..

3. 기대하는 미래의 모습

배워서 남 주는 개발자

지금까지 내가 받아왔듯 나도 남들에게 도움이 되는 개발자가 되고 싶다. 블로그를 쓰는 것도 그 이유 중의 하나이다. 언젠가 누군가에게 필요한 정보가 될 수 있기에 최대한 정확하고 이해하기 쉽게 작성하려고 노력하고 있다. 아직은 남들이 주는 정보를 받는 역할이지만 내가 가진 정보들도 쌓이고 잘 정리되어서 누군가에겐 도움이 되었으면 좋겠다.

함께 하고 싶은 개발자

이번에 팀 프로젝트를 진행하면서 민폐만 끼친다는 생각이 많이 들었었는데 가장 큰 이유가 나의 부족한 실력때문이었다. 그래서 가장 먼저 실력이 뒷받침되는 개발자로 성장했으면 좋겠고, 그 다음으로는 함께 일하는 동료들의 상황을 잘 파악할 수 있는 세심함을 가졌으면 좋겠다. 내가 그랬듯 누군가는 힘들어하고 어려워할 수 있다는걸 생각하면서 다들 잘 이해하고 있는지, 모두가 함께 잘 할 수 있는 방법을 찾으려고 노력하는 그런 개발자로 성장하고 싶다.

객체의 밸류를 조회하는 방법

obj.key // 일반적인 방법
obj['key']
// 어떤 키값이 들어올지 모를때, props로 받아와서 진행해야하는 경우에 사용, key는 항상 string

객체의 키 값 가져오는 방법

for (key in object) {
    console.log(key)
}

객체 복사하는 방법, 배열을 객체로 바꾸는 방법

Object.assign(target, source: any[]) // source 값으로는 객체, 배열 둘 다 가능

const user2 = Object.assign({}, {name: 'bella', age: '20'})
// 주로 빈 객체를 target으로 두고 진행, 뒤에 오는 source가 taget을 덮어씌움

객체를 배열로 바꾸는 방법

Object.entries()

💡 배열, 인덱스를 기본으로 구성됨

배열 분리하는 방법

for (value of array){
    console.log(value)
}

배열에 값 추가, 제거하는 방법

.push() : 배열의 제일 끝에 값 추가
.pop() : 배열의 제일 끝의 값 제거

.unshift() : 배열의 제일 앞에 값 추가
.shift() : 배열의 제일 앞의 값 제거

// unshift, shift는 index값의 변경을 요구하기 때문에 push, pop에 비해 굉장히 느린 작업이다

배열에서 원하는 인덱스 위치의 값 추가, 제거, 수정하는 방법

array.splice(start:number, deleteCount?:number, new)
// deleteCount를 지정하지않으면 start인덱스 이후의 모든 값을 제거
// 3번째 이후로 오는 파라미터에 추가하는 값은 지워진 인덱스자리에 추가
// 원본배열을 변경, 삭제된 요소를 배열로 반환

array.slice(start, end)
// start: 추출 시작 인덱스 값, 음수를 지정할 경우 배열의 끝에서부터 추출 시작
// end: 추출 종료 인덱스, 지정하지 않을경우 배열 끝까지 추출
// 원본배열은 수정되지않고 수정된 배열을 반환

배열 병합하는 방법

array.concat(array2)

배열에 포함된 값인지 확인하는 방법, 인덱스값 조회

array.includes(value) //불리언 반환
array.indexOf(value) //숫자 반환

.lastIndexOf(value) 중복된 값이 있을때 사용, 뒤에서부터 조회

정규표현식 연습 사이트 https://regexr.com/
연습 퀴즈 사이트 https://regexone.com/