issue 템플릿을 써야하는 이유

커뮤니케이션 규칙 수립하기.

소통과 대화는 다르다. 소통과 대화의 가장 큰 차이는 합의점을 이끌어내는 것에 있다고 생각한다.

"소통"을 잘한다는 것은, "합의점"을 잘.찾.는.것 이라고 생각한다.

단순히 "어떤 기능을 해주세요."라고 채팅이나 말로 요청하면, 요청받는 개발자는 해당 요구사항에 대한 완벽한 이해가 어렵다. 동료들 마다 질문하는 스타일과 요청하는 방법이 다르므로, 여러명이 협업을 한다면 골치가 아플 수 있다.

이를 위해, Github에서 제공하는 issue 템플릿을 사용하면 일관성있게 요청을 받아서 프로젝트 생산성과 정신건강에 도움이 될 수 있다.

👏🏻 이슈 템플릿 강점

• comment, merge, issue 생성을 할 때, 알림 기능을 받을 수 있다.
• 중요한 업데이트나 변경 사항에 대해 팀 전체에게 알림을 보낼 수 있다.
• 타프로그램과 연동이 잘된다. ex) 마이크로소프트 팀즈

이를 통해, 버그 리포트에 대해 더 빠르고 효과적으로 대응할 수 있다. 효율적인 커뮤니케이션을 지원하고, 이슈 작성자들이 일관된 방식으로 이슈를 작성할 수 있도록 도와준다.

⚒️ 이슈(ISSUE) 템플릿 등록하는 방법

1. 해당 프로젝트 Repository를 들어간다.
2. Settings 들어간다.

3. Set up templates를 누른다.

4. Bug report, Feature request or Custom template을 이용해 규칙을 만든다.

5. 규칙 만들고, Propose Changes 누르면 템플릿이 완성된다.

6. 이제 issue를 들어가서, New issue를 생성하게 되면 본인이 만든 템플릿을 볼 수 있다.

마무리

소통을 잘하자 👏🏻

피그마(Figma) 장점

• Figma는 클라우드 기반으로 작동하고, 실시간 저장이 가능하다.
• Figma는 웹, 모바일, 데스크탑 등 다양한 플랫폼에서 작동하므로, 언제 어디서나 작업할 수 있다.
• 무료 버전에서도 많은 기능을 사용할 수 있다. 유료 버전에서는, 많은 라이브러리도 제공되는 듯 하다.
• 여러 사람이 동시에 작업하면서 코멘트나 리뷰를 남길 수 있고, 파일도 공유할 수 있다.
• 와이어프레임 작성이 가능하다.

궁긍적으로 배우고 싶은 이유

소통하기 위함이다.

디자이너, 기획자, 동료 개발자들과 이야기 할때, 두서 없이 이야기 하면 서로 머리가 아프다. 소통의 부재가 발생할 확률이 매우 높다.

예를 들어 A 동료가, "개발자, 디자이너, 퍼블리셔에게 그래프 컴포넌트를 양 옆으로 옮겨주세요." 라고 한다면 가장 무엇부터 생각할까? 나는... 어떤 컴포넌트를... 어디쪽 그래프에서... 어디 방향으로 옮기라는거지? 생각할것이다.

위에 말만 듣고....

• 프런트 개발에 수정이 필요하다면?
• 디자인의 수정작업이 필요하다면?
• 퍼블리싱 작업에서 수정작업이 필요하다면?

직관적인 디자인과 문서화를 이용하여, 요구사항을 정확하게 컨펌한 후, 작업하는것이 생산성과 정신 건강에 훨씬 좋을 것 같다. 피그마를 사용하여 엄청난 디자인이너가 되면 좋겠지만, 이것이 나의 목표는 아니다. 기본 툴의 사용과 친해지는 것이 1차 목표다. 2차 목표는, 피그마로 디자이너 및 동료들과 소통하기. 3차 목표 지식 공유하기.

A같은 동료가 되지 않기 위해 노력하고 있다.

호이스팅(Hoisting)이란?

구글 영어사전에 따르면 호이스팅이란 *밧줄과 도르래로 끌어올리다는 뜻. *

: raise (something) by means of ropes and pulleys. "high overhead great cranes hoisted girders"

Simple Korean으로 말하면, 이사짐 사다리를 사용해서 63빌딩 꼭대기 층으로 위로 올라가는 것.

aCatName("호랑이");

function aCatName(name) {
  console.log("고양이의 이름은 " + name + "입니다"); 
  // 고양이의 이름은 호랑이입니다
}

일반적으로 코드는 탑다운 방식으로 실행이 된다. 위의 예제를 보면 함수를 선언하기도 전에, 함수를 먼저 호출하는데도 문제가 없다. 콘솔이 잘 찍힌다.

debugger를 확인해보면, 실행도 전에 호이스팅을 하여 Global에 aCatName 함수가 담긴것을 볼 수 있다. 여기서 우리가 '아하'라고 생각돼야 하는 부분은, 함수가 실행도 전에 꼭대기 층으로 올라가서 어딘가에 저장된다는 것이다. 이게 호이스팅이다.

자연스럽게 우리에게 말도하지 않고, 63빌딩 꼭대기로 쭈욱 올라간다는 것.

그렇다. 호이스팅은 코드를 실행하기도 전에, 선언된 변수 및 함수를 해당 범위의 맨 위로 이동하는 JavaScript의 메커니즘이다.

함수 선언문이 아닌 함수 표현식과 화살표 함수는 호이스팅이 될까?

• 호이스팅을 시도하지만, 함수 표현식과 화살표 함수는 다른 방법으로 define을 한다.

"The context inside arrow functions is lexically or statically defined. " -

호이스팅 var, let, const

몇 블로그 글을 보면... 누군가는 var는 호이스팅이 되는데 let과 const는 호이스팅이 되지 않는다는... 얘기를 한다. 까짓거 그럼 debugger를 사용해서, 자바스크립트 엔진에게 물어보자.

• var 키워드

• let, const 키워드

** 결론: var, let, const 코드를 실행하기도 전에, 선언된 변수 및 함수를 위로 쭈욱~ **

스코프의 반란 let, const

스코프(scope): 변수에 접근할 수 있는 범위

함수 스코프

• 자바스크립트는 기본적으로 함수 스코프를 따르는 언어다.
• 함수스코프를 따른다? ===> 새로운 함수가 생성될때마다 새로운 스코프가 발생한다.
• 함수안에서 선언한 변수는 해당 함수 안에서만 접근할 수 있음. (함수스코프 -> 지역스코프)

function getPassword() {
    var secretKey = '12345';
}

getPassword();
console.log(secretKey); // ReferenceError - not defined

함수 외부는 Global scope이고, 함수 내부는 getPassword 함수의 scope이다. 부모 scope는 자식 scope에서 간섭할 수 없기 때문에 접근이 불가능하다.

그렇다면 var 키워드를 사용할 때, 블락{ } 에서는?

// ========= 블락 {} =========
var secretKey = "123456";

if (true) {
  var secretKey = "var changes inside block - Not safe";
}

console.log(secretKey); // var changes inside block - Not safe

• 위 코드에서는 함수가 선언되어 있지 않기 때문에 새로운 환경, 새로운 스코프가 형성되지 않는다. 두꺼운 벽을 세우지 않았다.
• 그렇기 때문에 어디에서나 secretKey에 접근이 가능하다.
• Simple Korean - var 키워드는 함수에서만 도둑을 조심하고, 벽은 타고 집안으로 들어온다.

대표적인 예로, for loop의 블락스코프다. 블락에서 보호를 제대로 받지 못하여, 다른 스코프(범위)에서 키워드를 남발할 수 있다.

for (var password = 0; password < 2; password++){
    console.log(password); // 0, 1
}
>
console.log(password); // 2 
// 블락스코프 밖에서... password를 선언하지도 않았는데, i에 접근해버렸다..

var 키워드를 남발한다면... 나도 모르게 변수를.. 재사용하여.. 이거저것 해본 후... 어디선가.. 버그를 찾고 있겠지...?

*Simple Korean: 도둑이 이집 저집 마음대로 넘나들면 안되니까 벽을 세워야함. * 이를 위해, 도둑이 넘나들지 못하게 벽을 세우자! ES6에서 블락스코프 let, const 키워드가 등장했다.

블락 스코프 let, const 키워드

• 원래 자바스크립트는 함수 스코프를 따르지만, let과 const 키워드의 등장으로 블락 스코프를 형성하는 것도 가능해졌다. (드디어 안전한 벽을 세울 수 있다.)
• 블락스코프는, 블락 {}이 생성될 때마다 새로운 스코프(범위)가 형성되는 것을 의미함.

let secretKey = "Let me hack your password";

if(true){
    let secretKey = "Go away";
    console.log(secretKey); // "Go away";

      const password = "*******"
      console.log(password); // "*******"
}

console.log(secretKey); // Let me hack your password
console.log(password); // ReferenceError - password is not defined

let과 const를 사용하여 도둑이 집을 넘나드는것을 안전한 벽(블락)을 세우며 침입을 막는다.

선언 & 초기화 & 값 할당 & 재할당

앞서, 호이스팅를 확인하고 중요한 함수스코프와 블락스코프의 차이를 확인했다. 그렇다면 var, let, const 쓰임새는 어떻게 될까?

• 변수는 선언 단계 -> 초기화 단계 -> 값 할당단계 3가지 단계로 나뉜다.

앞에서도 살펴봤지만, 다시 위의 사진을 보면, let과 const를 사용할때, 호이스팅이 돼서 메모리 어딘가에 undefined 로 먼저 들어가 있는 것을 확인할 수 있다. 이뿐만이 아니다, 개발자 도구에서 함수를 정의해도 undefined가 뜬다.

• let, const는 호이스팅 때 메모리 공간만 할당하여 undefined를 넣어두려고 시도한다.

Simple Korean으로 설명을 하자면,

1. 변수 선언. 2. 초기화라는건 => 메모리 공간을 미리 만들어 둔다는 것이다. 보통 암묵적으로 'undefined'을 넣으려고함. 3. 초기화 단계에서 만들어 놓은 메모리 공간을 활용하여 => 값을 할당 및 재할당 한다.

var

• var는 선언 & 초기화 & 값 할당을 동시에도 가능하고, 따로도 가능하다. 따로 하는 작업을 한다면, 메모리 공간을 만들어 undefined로 넣어두고 다음 테스크를 기다린다.

var whatever; // undefined
var whatever = '1' // 재선언 가능
var whatever = '2' // 재할당 가능

let

• 호이스팅 이후 코드가 실행되며, let은 undefined에서 나중에 재할당을 할 수 있다. 즉, 선언과 초기화 분리가 가능하다.
• 중복 선언이 안된다.

let laterPossible; // undefined
laterPossible = "changing the value"

let laterPossible = 'declared again'; // 중복선언 안됨.
// Identifier 'laterPossible' has already been declared

const

• 호이스팅이 되며, undefined가 담기려고 노력하지만, 선언 & 초기화 & 할당이 동시에 일어나야 한다.
• 중복선언 안됨.
• const 만에 유니크함: => 재할당이 불가함.(예외도 있음)
• *재할당의 경우, 원시 값은 불가능하지만, 객체는 가능하다. *
• const 키워드는 재할당을 금지할 뿐, '불변'을 의미하지 않는다.

const strictBetter; // Missing initializer in const declaration
// 1. 선언할때, 2. 초기화를 꼭 하고, 값도 할당해줘야한다.

const strictBetter = 'value in the memory' //  선언 & 초기화 & 값 할당

const strictBetter = 're-declare'; // 중복선언 안됨.
// Identifier 're-declare' has already been declared

strictBetter = 'new string'; //  Assignment to constant variable

• 재할당 예외

  const exceptionConst = {id:1, name: 'Frank'}
  

exceptionConst['name'] = 'Frank Kim' exceptionConst['job'] = 'JavaScript Developer'

console.log(exceptionConst); // {id: 1, name: 'Frank Kim', job: 'JavaScript Developer'}

<hr>

### TDZ란? 사각지대

> Temporal Dead Zone: => ReferenceError

(1) let

* let 키워드로 선언한 변수는, 선언 단계와 초기화 단계가 분리되어 진행된다. 즉, 런타임 이전에 자바스크립트 엔진에 의해 선언 단계가 먼저 실행되지만, 초기화 단계가 적절하게 실행되지 않았을 때(undefined) 해당 변수에 접근하려고 하면 참조 에러가 뜬다.

```js
console.log(name); // Uncaught ReferenceError: name is not defined
/*
......
...... T
...... D
...... Z
......
*/
let name = 'Frank'

• 따라서 let 키워드로 선언한 변수는 스코프의 시작 지점부터 초기화 단계 시작 지점까지 변수를 참조할 수 없는 일시적 사각지대(Temporal Dead Zone: TDZ) 구간에 존재한다.

(2) const

const 키워드는 선언 단계와 초기화 단계가 동시에 진행된다.

console.log(name) 
// Uncaught ReferenceError: Cannot access 'name' before initialization

const name = 'Frank'

• let 키워드로 선언한 경우, 런타임 이전에 선언이 되어 자바스크립트 엔진에 이미 존재하지만 초기화가 적절하게 되지 않았기 때문에, name is not defined라는 문구가 떴다.

• 하지만 const 키워드로 선언한 경우, 선언과 초기화가 동시에 이루어져야 하지만 런타임 이전에는 실행될 수 없다. 따라서 초기화가 진행되지 않은 상태이기 때문에 Cannot access 'name' before initialization 에러 문구가 뜬다.

마무리

기본적으로 변수의 스코프는 최대한 좁게 만드는 것을 권장한다. 따라서, var > let > const 키워드를 사용하자. 변경하지 않는 값(상수)이라면 let > const 키워드를 사용하는 것이 상대적으로 안전한다.

Reference:

• https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Statements/let#%EC%8B%9C%EA%B0%84%EC%83%81_%EC%82%AC%EA%B0%81%EC%A7%80%EB%8C%80
• https://www.geeksforgeeks.org/can-we-use-hoisting-with-arrow-function/?ref=rp
• https://www.howdy-mj.me/javascript/var-let-const

목표: 누군가를 위해 Simple Korean으로 설명할 수 있을만큼 학습하기.

자바스크립트 변수 타입

자바 스크립트의 변수 타입에는 크게 원시타입(Primitive Type)과 참조타입(Reference Type)으로 나누어져 있다.

• 원시타입(Primitive type)의 변수들은 데이터 복사가 일어날 때 메모리 공간을 새로 확보하여 독립적인 값을 저장한다.

• 참조 타입은 메모리에 직접 접근이 아닌 메모리의 공간(주소)에 대한 간접적인 참조를 통해 메모리에 접근하는 데이터 타입이다.

참조타입 (메모리 주소 값 접근 - Heap)

배열과 객체, 그리고 함수가 대표적이다.

• Object의 데이터 자체는 별도의 메모리 공간(heap)에 저장된다.
• 변수에 할당 시 데이터에 대한 주소(힙(Heap) 메모리의 주소값)가 저장된다.
• 따라서, 자바스크립트 엔진은 변수가 가지고 있는 메모리 주소를 이용해서 변수의 값에 접근한다.

Simple Korean으로 말하면,

• 배열이나 객체는 크기가 커질 수 있기 때문에 데이터를 큰 상자 공간(메모리 공간 - Heap)에 저장한다. 또한, 우리가 큰 상자안에 있는 데이터에 접근하려면 unique한 이름이(메모리 주소) 있으면 좋겠다. 마치 100세대가 사는 아파트에, 택배를 전달하려면 특정 주소(Heap)가 필요하다.

만약에,let myArray = [] 라는 배열을 생성하면 위와 같은 일이 일어난다. 그림에서 볼 수 있듯이, 원시타입(문자, 숫자)의 값들은 '값 - value'들이 직접적으로 저장되어 있다. (자세한 원시타입은 아래에 설명함.) BUT myArray (참조타입)는 ---> Heap 메모리의 주소값이 저장되어 있다.

let myArr = [];
let copyArr = myArr;

myArr.push("hello");

console.log(copyArr); // ["hello"]

위 예제를 보면 알 수 있듯이, 참조 타입의 변수는 실제 데이터가 저장된 주소를 참조하기에 참조(reference) 타입이라고 불리는 것이다.

원시타입 (새로운 메모리 공간 사용)

자바스크립트에서 원시 타입 (string, number, bigint, boolean, undefined, ES6 부터 추가된 symbol) 은 변수에 할당될 때, 메모리의 고정 크기로 원시 값을 저장하고 해당 저장된 값을 변수가 직접적으로 가리키는 형태를 띈다. 불변성을 가진다.

let a = 100;
a = 50;

a란 변수에 100이란 값을 할당하고, 2번째 라인에서 50으로 재할당을 해준 예시이다.

1. 첫 라인이 실행되면 메모리에 Number타입의 100이란 값이 생성되고, 식별자 a는 메모리에 생성된 100의 메모리 주소를 가리킨다. (a -> 100 메모리 주소)

2. 두번째 라인이 실행되면, 메모리에 생성된 100이란 값이 50으로 수정되는것이 아니다. 새로운 Number타입의 50이란 값을 새로운 메모리에 생성하고 a가 가리키던 메모리가 바뀌는것이다. (a -> 50의 새로운 메모리 주소)

쉽게 말하면, 땅부자들이 땅을 막 사드려도 문제 없는 듯 행동한다. 값이 바뀌면 그냥 새로운 빌딩을 사들여서, 새로운 빌딩에 물건을 넣어두면 된다. 이전 빌딩들은 어찌 못하고, 그대로 가지고 있는다. (불변성)

*원시타입은 (Primitive Type) *새로운 빌딩 공간을 확보한다. 그러면, 원시 타입의 값이 복사 될때는 어떻게 될까?

let a = 100;
let b = a;
a = 50;

console.log(b) // 100

땅부자들은 원시타입 값이 재할당 될 때마다, 새로운 빌딩(메모리 공간)을 확보하기 때문에, 개의치 않는다.

새로운 변수 b에 a를 할당 하게되면, 변수 b의 공간에는 a의 값을 값을 통째로 복사하여 변수의 메모리에 담게 된다. 그렇기에 변수 a가 50으로 재할당 되더라도 b는 전혀 영향을 받지 않는다.

원시타입(새로운 메모리 공간) vs 참조타입 정리 (메모리 주소 참조)

_원시타입(Primitive type)_의 변수들은 데이터 복사가 일어날 때, 메모리 공간을 새로 확보하여 독립적인 값을 저장한다.

• 땅부자들이 1인 빌딩을 새로 지으며 공간을 확보함.
• 불변성을 가지고 있음. 낙장불입.
• 불변성을 갖고있기 때문에, 재할당 시 기존 값이 변하는것 처럼 보일지 몰라도 사실 새로운 메모리에 재할당한 값이 저장됨. 변수가 가리키는 메모리가 달라졌을 뿐임.
• 엄청난 땅부자라도... 무한한 빌딩들을 계속 지으면... 언젠간.. 자리가 없거나 무슨일이 생기겠지? 그러니 메모리를 고려하자.

Simple Korean -> 땅부자들 새로운 공간 확보해서, 변수들이 새로운 빌딩에(메모리) 접근함.

참조 타입(Reference type)은 _메모리에 직접 접근이 아닌, _메모리의 주소에 대한 간접적인 참조를 통해 메모리에 접근하는 데이터 타입이다.

Simple Korean -> 아파트 새대 주소를 정확히 알아야지 택배 전달이 가능함. 사람이 너무 많음. 사람이 많기 때문에 주소를 이용(참조)함.

Reference:

• https://spoit.tistory.com/30
• https://velog.io/@younoah/call-by-value-call-by-reference
• https://www.geeksforgeeks.org/call-by-value-vs-call-by-reference-in-javascript/
• https://velog.io/@nomadhash/Java-Script-%EA%B9%8A%EC%9D%80-%EB%B3%B5%EC%82%AC%EC%99%80-%EC%96%95%EC%9D%80-%EB%B3%B5%EC%82%AC

🌐 HTTP란? 그리고 특징들

HTTP는 Hyper Text Transfer Protocol의 약자다.

인터넷에서 데이터를 주고 받을 수 있는 프로토콜이다. 즉 인터넷에서 데이터를 받을 때 규칙(약속)이라는 것. 모든 프로그램이 이 규칙에 맞춰 개발해서 서로 정보를 교환할 수 있게 된다.

HTTP는 상태를 가지고 있지 않는 Stateless 프로토콜이며 Method, Path, Version, Headers, Body 등으로 구성된다.

Connectionless(비연결성)

Connectionless(비연결성): 클라이언트와 서버가 연결되어 있지 않다는 것.

1. 그러면 연결되어 있지 않다면서... 어떻게 통신을 한다는거지?

• 클라이언트가 어떠한 데이터를 요청하면 서버는 응답을 하고 한번 맺었던 연결을 끊어버린다.

2. 클라이언트와 서버가 연결되어 있지 않은 이유는 무엇일까?

• **Why? -> 계속해서 리소스가 들어가기 때문이다. 리소스를 아낄 수 있기 때문에 더 많은 연결을 할 수 있는 장점이 있다. 그래서 서버는 연결을 끊어버린다.

• *

  이러한 특징 때문에 매번 어떠한 요청에 대해, 새로운 연결을 해야 하므로 "오버헤드"가 발생한다는 단점도 있다.

오버헤드(overhead): 어떤 처리를 하기 위해 들어가는 간접적인 처리 시간 · 메모리 등을 말한다.

Stateless(상태없음)

Stateful(상태유지): 상태를 가지고 있다는 의미. 즉, 서버가 클라이언트의 상태를 보존함. 상태를 기억함.

예를 들어서, Pub에 직원이 여러명이 있다고 가정하자.

Staff A: 필요하신거 있으실까요? 프랭크: 발렌타인 17년산 주세요.

Staff B: 필요하신거 있으실까요? 프랭크: 5분전에 시킨거 취소하고, 30년산으로 바꿔주세요. (기억하고 있음)

Staff C: 필요하신거 있으실까요? 프랭크: 10분전에 시킨거 취소할게요. 맥주 한잔 주세요. (기억하고 있음)

*(이렇게 상태를 기억하는 방식을 Stateful이라고 한다.) *

포스기를 사용하는 것처럼 정보 트래킹(Tracking) 가능하다.

• 이렇게 되면 직원들은 어떤 직원이 어떤 주문을 받았는지 모두 찾아다녀야 할 것이고, 이것은 비용이 많이 들게 된다.

Stateful(상태유지)

Stateless(상태없음): 상태를 가지고 있지 않는다는 의미이다. 좀 더 구체적으로 설명하면 서버가 클라이언트의 상태를 가지고 있지 않는 것이다.

Staff A: 필요하신거 있으실까요? 프랭크: 발렌타인 17년산 주세요.

Staff B: 필요하신거 있으실까요? 프랭크: 5분전에 A한테 발렌타인 17년산 시켰는데, 30년산으로 바꿔주세요.

Staff C: 필요하신거 있으실까요? 프랭크: 10분전에 A한테 발렌타인 17년산 시켰는데, 5분전에 30년산으로 바꿨어요. 그냥 취소하고 맥주 한잔 주세요.

• 상태를 저장하지 않는다면 요청을 할 때, 모든 정보를 준다.
• 이런 식으로 요청을 할 때 모든 정보를 담아서 요청하기 때문에, 직원들은 쉽게 주문을 파악할 수 있고, 비용을 최소화 할 수 있다.

🌐 Stateless vs Stateful

Stateless (상태없음) 장단점

• "비용(리소스)"를 줄인다.

• Stateless 방식은 요청을 할 때, 모든 정보를 각 서버에게 전달해야 하기 때문에 요청이 복잡해질 수 있는 단점이 있다.

• 반면에, 요청을 한번에 주기 때문에 많은 서버를 둬도 큰 부담이 안된다는 장점이 있다.

• 대량의 트래픽 발생 시에도 서버 확장을 통해 대처를 수월하게 할 수 있다는 장점도 있다. (stateful과 달리 서버가 바뀌어서도 정확한 응답에 문제가 없으니까). Stateless는 서버의 확장성에 용이하다.

• 이벤트 소개 페이지처럼 아무 정보를 담을 필요가 없는 페이지는 상태없음으로 만들면 좋다.

• 하지만 로그인처럼 유저가 로그인하고 있다는 상태를 유지해야 하는 서비스는 상태를 유지하지 않으면 로그인이 풀려버린다.

• 따라서 모든 것을 상태없음으로 설계할 수 없다. 어쩔 수 없는 경우에만 상태 유지를 최소한으로 사용하는 것이 베스트이다.

Stateful (상태유지) 장단점

• 클라이언트와 서버 간에 송수신을 하며 단계별 과정을 진행하는데 있어, 서버에서 클라이언트가 이전 단계에서 제공한 값을 저장하고 다음 단계에서도 저장한 상태이다.

• 대표적으로 홈페이지에서 한번 로그인을 하면 페이지를 이동해도 로그인이 풀리지않고 계속 유지되는 것이 바로 서버가 클라이언트의 상태를 유지(기억)하고 있으니까 가능한 것이다.

• 클라이언트의 정보를 기억한다라는 말은 어딘가에 정보를 저장하고 통신할때마다 읽는다는 뜻이다.

• 이러한 정보들은 일반적으로 브라우저의 쿠키(Cookie)에 저장되거나, 서버의 세션(Session) 메모리에 저장되어 상태를 유지하게 된다.

• stateful의 문제점은 해당 서버가 멈추거나 여러 이유로 해당 서버가 못쓰게 되어 다른 서버를 사용해야 할때 발생한다. 왜냐하면 새로운 서버에서는 이전 서버에서 가지고 있던 상태값들을 가지고 있지 않기 때문이다.

• 클라이언트 상태들을 들고 있으니 용량 한계가 존재한다.

  ---

🌐 Stateless 또 다른 특징들

Stateless 와 HTTP / REST

반면 REST는 프로토콜이라기 보단 구조(Architecture)에 가깝다. 즉, REST는 HTTP 프로토콜 상에 구현된 Resource Oriented Architecture (ROA) 설계 구조다. 따라서, HTTP와 REST 모두 Stateless한 성격을 가진다.

HTTP는 Statelss한 성격을 가진 '프로토콜' REST는 Stateless한 성격을 가진 '설계 구조'

Stateless 와 토큰(Token)

Stateless(상태없음) 특징으로, 클라이언트와 서버간의 통신에 필요한 모든 상태 정보들은 클라이언트에서 가지고 있다가 서버와 통신할때 데이터를 실어 보내는 것이다.

그래서 서버는 단순히 받아서 응답만 해주기 때문에 서버에 대한 부하가 현저히 줄어든다.

하지만 로그인 유지와 같은 상태는 싫으나 좋으나 stateful한 상태를 사용하여야 하는데, 그러면 서버에 부하가 생기고 좀 그렇다.

그래서 stateless 특징을 유지하면서도 로그인 상태 유지를 가능하게 하는 기술이 바로 JWT 토큰이다.

토큰은 클라이언트가 암호화된 로그인 정보들을 지니고 있다가 서버에 통신할때 넘겨줌으로써 내가 로그인 됐음을 인증하는 방식이다.

따라서 특별한 일이 없다면, Stateless - 무상태(상태없음)를 지향해야하며 정말 필요한 경우에만 상태 유지를 해야한다.

Reference

• https://mangkyu.tistory.com/98
• https://fomaios.tistory.com/entry/Network-HTTP%EC%9D%98-%ED%8A%B9%EC%A7%95%EC%97%90-%EB%8C%80%ED%95%B4-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0feat-%EB%B9%84%EC%97%B0%EA%B2%B0%EC%84%B1-%EB%AC%B4%EC%83%81%ED%83%9C
• https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-Stateful-Stateless-%EC%A0%95%EB%A6%AC
• https://stackoverflow.com/questions/56671582/whats-the-difference-between-stateless-and-connection-less

객체지향이란? (관계/조직에 초점)

그러면 객체지향 프로그래밍 언어란 뭘까? 객체지향 절차지향 등 어려운 용어가 상당히 많다. Simple Korean으로 풀어보면...

• 우리가 실생활에서 쓰는 모든 것, 상태와 행위를 객체라 한다. 이 객체들을 레고 블럭처럼 조립해서 하나의 프로그램을 만드는 것을 객체 지향 프로그래밍이라고 할 수 있다.

객체지향을 들으면서, 절자 지향 프로그래밍도 들어봤는데 차이점이 뭐지? ### 절차지향은 순차적으로 실행에 초점이 되어있고 ** **객체지향은 관계/조직에 초점을 맞추고 있다는 초점의 차이일 뿐이다. 절차적 프로그래밍이라고 해서 객체를 다루지 않는 것이 아니고, 객체지향 프로그래밍이라고해서 절차가 없는 것도 아니다.

프로토타입이란 (prototype)?

프로토타입 정의를 알아보기 전에, 그나마? 친근한 용어를 이용해 특징을 알아보는 것도 좋을 것 같다.

• 자바스크립트에서 단순 원시 타입(simple primitive)인 문자열, 숫자, 불리언, null, undefined를 제외한 모든 타입은 객체다. 그렇다. 자바스크립트에서는 배열, 객체, 함수도 객체다.

• JavaScript의 모든 객체(배열, 객체, 함수 등)는 상위 객체를 참조하며, 이 상위 객체를 프로토타입이라고 한다. 일단 상위 객체를 참조한다는 말만 기억해두자.

프로토타입 Prototype 정의

위키디피아 정의 - 프로토타입 기반 언어는 클래스 기반 언어에서 상속을 사용하는 것과는 다르게, 객체를 원형(프로토타입)으로 하는 복제 과정을 통해 객체의 동작 방식을 재사용 할 수 있게 한다.

프로토타입 기반 언어는 원형(원본) 객체를 복제하여 새로운 객체를 하는 생성하는 언어를 말한다. 그런데 자바스크립트도 복제를 할까? 자바스크립트는 약간 다르다. 복제가 아닌 프로토타입 링크를 통해 원형(원본)을 참조한다.

• 프로토타입 링크를 통해 -> 원형을 참조한다를 꼭!!!!!!!! 기억하자.
• 결국 객체지향 언어다. 이는, 관계와 조직에 초점을 둔다는 점도 기억하자.

적절한 비유일지는 모르겠지만...... 내가 이해한 프로토타입은 리액트와 어렴풋이 비슷하다.

1. 리액트로 생각해보면, 부모와 자식사이에서 props나 함수를 공유한다.

*-----> 프로토타입도 부모 자식 사이의 공유와 비슷하다. *

2. 리액트에서도 부모 컴포넌트가 최상위고, 자식 컴포넌트들은 부모가 던져준 props나 함수를 사용할 수 있다.

----->자식은 부모가 공유해주는 prototype 함수를 사용할 수 있다.

3. props drilling와 비슷하게 props를 위 아래로 넘겨줄 수 있는 체인 매커니즘을

*-----> 프로토타입 체인이라고 부른다. *

4. 리액트에서 map을 사용할 때 key 값이 필요하듯, 부모와 자식의 연결고리 key를

-----> _proto_ 라고 부른다. _proto_를 이용하여 상위를 참조한다.

예제 1

• 위에서 언급한 부모와 자식 사이의 공유를 염두해두자.

let arr = [1,2,3];
let add = function(x,y){
    return x + y; 
}

console.dir(add.prototype.constructor); // ƒ add(x,y)
console.log(add.prototype.constructor === add); // true

(위에 코드 & 아래 사진 참조)

add 함수를 만들면, 자동으로 add.prototype.constructor가 생긴다. 신기한 부분은 add === add.prototype.constructor 이곳이다. 코드를 console.dir로 까보면 prototype 프로퍼티와 _proto_ 용어가 나온다.

즉, add 함수를 생성할 때, (아래 사진 참조)

1. add 함수는 prototype 프로퍼티와 _proto_ 를 가지고 있다.
2. 자동으로 add prototype이 따로 생성 된다. 이 prototype 안에는 constructor가 있다.
3. add 함수에 prototype 프로퍼티는 -> 따로 생긴 add.prototype을 가르킨다.
4. add 함수 === add.prototype.constructor 연결이 된다.

• 여기서 헷갈릴 수 있는데, 함수가 가지고 있는 prototype 프로퍼티와, 따로 생긴 prototype은 다르다.

add.setLastName = function(){
    return 'Last: Kim';
}

add.prototype.setName = function(){
    return 'Name: Frank';
}

console.log(add.setLastName());
console.log(add.prototype.setName());

• 그러면!!! 우리는 자식과의 공유를 원한다. 만약 내가 add 함수에 다른 함수를 추가하고 싶다면?
• prototype에 추가하는 것과 일반 함수에 추가하는 것의 차이점이 뭘까?
• 어떻게 사용하면 다른 환경에서 공유를 할 수 있을까?

일반 메소드 vs Prototype

1. prototype에 추가하는 것과 일반 함수에 추가하는 것의 차이점이 뭘까?
2. 어떻게 사용하면 다른 환경에서 공유를 할 수 있을까?

ES5 이전에는 프로토타입 체인을 구현하려면 무조건 생성자 함수와 new 연산자를 사용해야 했다. 다행스럽게도 ES5부터는 Object.create라는 프로토타입 언어의 특징을 잘 살려 객체를 생성할 수 있는 새로운 방법을 제공한다. 함수면 체인 구현이 가능해보인다.

• 프로토타입에 메소드를 추가하면 해당 생성자로 생성된 모든 객체에서 사용 가능하다.

우리는 새로운 방법 Object.create를 사용해볼 것이다.

// ========= 프로토타입 체인 구현 =========
let copyCat1 = Object.create(add);

console.log(copyCat1); // Function {}

console.log(copyCat1.setLastName()); 
// 'Last: Kim'

console.log(copyCat1.prototype.setName()); 
// 'Name: Frank'

위와 같이 copyCat1은 setLastName, setName 함수를 따로 설정해주지 않아도 됐다. prototype의 특성 프로토타입 체인(체인 메커니즘)을 통해 상위를 참조해서 함수가 사용 가능해졌다.

프로토타입 기반이라는 의미는 위에서 언급한 것처럼, 상위 객체를 참조하며, 이 상위 객체를 프로토타입이라고 한다.

Prototype 응용

만약 99999999999개의 값을 바꾸라고...누군가..지시한다면...?

let PROTOTYPE = {
    type: 'employee',
    work: function() {},
}

function Company(name, position){
  let who = {
     name:name,     
     position: position,
  }

    who._proto_ = PROTOTYPE;

    return who;
}

var name1 = Company('kim', 'developer');
var name2 = Company('lee', 'designer');
// ..... x99999999997개......

앞서 말한바와 같이 _proto_는 key값 연결고리다. 저 연결고리 키값을 바꿔버리면... 값들이 한번에 바뀌는 현상을 볼 수 있다.

PROTOTYPE.type = 'Team'
console.log(name1._proto_.type); // 'Team'

name1._proto_.sleep = () => 'go to sleep';

console.log(PROTOTYPE); 
// {type: 'Team', work: ƒ, sleep: ƒ}


console.log(name2._proto_); 
// {type: 'Team', work: ƒ, sleep: ƒ}

프로토타입 Prototype 특징 정리

• JavaScript의 모든 객체의 프로토타입은 값을 할당하는 시점에 결정되며, 프로토타입은 변경될 수 있다.
• JavaScript는 배열, 문자열 심지어 함수도 객체로 간주한다.
• 프로토타입은 상위 객체를 의미한다.
• 직접 생성한 프로토타입은 새로운 프로퍼티나 메소드를 마음껏 추가하거나 삭제할 수 있다.
• 물론 자바스크립트 표준 객체의 프로토타입도 임의로 수정할 수 있으나, 심각한 오류가 발생할 가능성이 있다. 따라서 자바스크립트 표준 객체의 프로토타입은 수정해서는 안된다.
• 객체는 함수를 사용해서 만들어지고, 객체는 함수의 프로토타입 객체를 복제하여 생성된다.
• 모든 객체는 자신이 어떤 원본 객체를 복제하여 생성된 것인지에 대한 정보를 가지고 있다.
• 프로토타입에 메소드를 추가하면 해당 생성자로 생성된 모든 객체에서 사용 가능하다.
• 객체를 생성하면 생성한 만큼 함수가 등록된다. 그리고 함수를 여러 개 등록하면 메모리 공간을 많이 차지해 메모리 낭비가 된다. 프로토타입을 사용함으로 메모리 낭비를 줄일 수 있다.

hasOwnProperty vs Prototype

이 메소드는 객체가 특정 프로퍼티를 자기만의 직접적인 프로퍼티로서 소유하고 있는지를 판단하는데 사용된다. in 연산과는 다르게, 이 메소드는 객체의 프로토타입 체인을 확인하지는 않는다.

• 해당 객체에 특정 프로퍼티가 존재하면 true, 그렇지 않으면 false 를 반환한다.
• 프로토타입 체인 따위는 신경쓰지 않는 돌직구 녀석.

const obj = {
    ownProperty: 1
};
obj.hasOwnProperty("ownProperty"); // true
obj.hasOwnProperty("prototype"); // false

obj.newProperty = 1;
Object.prototype.fromProtoType = 'hey prototype';

console.log(obj.hasOwnProperty("newProperty")); // true
console.log(obj.hasOwnProperty("fromProtoType")); // false

console.log(obj); // {ownProperty: 1, newProperty: 1}
console.log(obj._proto_.fromProtoType); // 'hey prototype';

여기서 주의할 점!!! 자바스크립트는 프로퍼티 명칭으로서 hasOwnProperty()를 보호하지 않는다. hasOwnProperty 네이밍으로 장난치지 말라는 소리...

const messWithHasOwnProPerty = {
  hasOwnProperty: function() {
    return false;
  },
  careful: 'Be careful'
};

console.log(messWithHasOwnProPerty.hasOwnProperty('careful')); 
// false

그렇다면... 우리는 hasOwnProperty를 언제 사용하면 좋을까? prototype과 어떻게 다르게 써야할까? 왜 사용해야할까?

시간이 지나 코드를 변경해야할 수도 있고, 누군가 자신의 코드를 재사용할 수 도 있다. 하나의 예로 hasOwnProperty 를 사용하지 않은 채, 시간이 흘러 누군가 코드를 수정했다고 가정해보자.

const emptyObj = {};

console.log(emptyObj.getFirstName()); // 'Kim';
console.log(emptyObj.hasOwnProperty(getFirstName())); // false;

const who = {
  name: 'Frank',
  getName() {
    return this.name; 
  }
};

console.log(who.name); // 'Frank'
console.log(who.getName()); // 'Frank'

Object.prototype.getFirstName = function(){
    return 'Kim';
}


// Bad - 프로토타입 체인을 통해 Object 접근
if(who.getName){
    console.log(who.getName()); // 'Frank'
}

// Bad - 프로토타입 체인을 통해 Object 접근
if(who.getFirstName){
    console.log(who.getFirstName()); // 'Kim'
}

// Good - 고유의 프로퍼티인지 체크. 프로토타입 한번 거름.
if(who.hasOwnProperty("getName")){ 
    console.log(who.getName()); // 'Frank'
}

// Good - 고유의 프로퍼티인지 체크. 프로토타입 한번 거름.
if(who.hasOwnProperty("getFirstName")){
    console.log('Is it unique enough?'); 
} else {
    console.log("Doesn't have getFirstName() as property");
  // "Doesn't have getFirstName() as property"
}

• hasOwnPropety로 우리가 기대할 수 있는것은?
  1. 예기치 못한 상황에 따른 버그 대비
  2. 코드의 가독성 향상

흠... 우리가 잘 알고 있는 오브젝트를 루핑할 때 쓰는 for in. 과연 for in은 프로토타입 체인으로부터 안전할까?

const emptyObjAgain = {};

for(let key in emptyObjAgain){
    console.log(key); // undefined
}

Object.prototype.loopEmptyObj = function(){
    return 'accessing prototype!'
}

for(let key in emptyObjAgain){
    console.log(key); // loopEmptyObj
}

// ========== 방어로직을 세워볼까? ==========
for(let key in emptyObjAgain){
    if(emptyObjAgain.hasOwnProperty(key)){
        console.log(key); 
    } else {
        console.log('Accesing prototype'); 
    }
}

역시 자바스크립트는 유연한 언어다... ㅎㅎㅎ 조심 또 조심...

오호.. hasOwnProperty()와 비슷한 친구를 찾았다.

Object.hasOwn() Note: *Object.hasOwn() *is intended as a replacement for Object.prototype.hasOwnProperty(). 쓰임새: Object.hasOwn(obj, prop)

const friends = {
    friend1: 'kim',
      friend2: 'lee',
};

Object.prototype.makeNewFriends = function(){
    return `accessing prototype!`
}

for (const key in friends) {
  if (Object.hasOwn(friends, key)) {
    console.log(key); // 'friend1', 'friend2' 
  }else {
    console.log(key); // makeNewFriends
  }
}

클래스 vs Prototype

정확성, 안전성, 예측성의 관점에서 클래스는 대체로 타입과 비슷하므로 동적으로 프로퍼티를 변경할 수 있는 프로토타입에 비해 더 신뢰성 높은 코드를 작성할 수 있다고 하는 게 주요 의견이다.

"글이 길어진 관계로... 다음 챕터에서..."

마무리

재밌어서 시간 가는줄 모르고 학습했다. 배워도 끝이 없다...ㅋㅋㅋㅋ 아직 프로토타입과 클래스 차이점을 두고, 자바스크립트에서 어떻게 상속을 하는 것이 효율적인지 판단이 서지를 않는다.

Reference

• https://jongminfire.dev/%EA%B0%9D%EC%B2%B4%EC%A7%80%ED%96%A5-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D%EC%9D%B4%EB%9E%80
• http://www.tcpschool.com/javascript/js_object_prototype#:~:text=%ED%95%98%EC%A7%80%EB%A7%8C%20C%23%EC%9D%B4%EB%82%98%20C%2B%2B,%EC%96%B8%EC%96%B4%EC%99%80%EB%8A%94%20%EC%95%BD%EA%B0%84%20%EB%8B%A4%EB%A6%85%EB%8B%88%EB%8B%A4.
• https://www.youtube.com/watch?v=zbgKZVMzdfk
• https://pulpul8282.tistory.com/98
• https://developer.mozilla.org/ko/docs/Learn/JavaScript/Objects/Object_prototypes
• https://ui.toast.com/weekly-pick/ko_20160603
• https://tecoble.techcourse.co.kr/post/2021-06-14-prototype/
• https://ko.javascript.info/prototype-inheritance
• https://mygumi.tistory.com/330
• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/hasOwn

TL;DR: 개발자 성장기. 지금도 성장하고 있다.

{Q: 많은 이들이 묻는다. '왜 갑자기 개발자를 하고 싶으세요?'} ,

사람들의 질문은 타당했다. 나(프랭크)는 비전공자고, 남들이 쉽게 가지 않는 길을 걸어왔다. 나는 다양한 경험과 자기 성장에 집착한다. 좋게 말하면 자기성장이고, 현실적으로 말하면 무모한 도전으로 인한 성장이다. 자기성장(무모한 도전) 때문에 개발 공부를 시작했었음을 먼저 알리고 싶다.

• 대학교 1학년 겨울방학 3개월 동안, 필리핀 마닐라로 넘어가서 어학원 매니저로 일하며 수업 스케쥴 관리와 학생 관리를 했다.
• 군대에서 미국 J1 비자 무역회사 1년 인턴쉽을 준비했다.
• 미국 출국하기 전까지, 동두천 미군 부대 내부 외식업에서 매니저를 했다.
• 미래에셋 영업사관학교 수료.
• 미국 마케팅협회 Professional Certified Marketer 자격증 취득.
• 한국 문화 및 서비스를 글로벌하게 알리는 것을 즐겼고, 마케팅 업무 및 50개국 이상의 국가 VIP들 의전을 경험했다.
• 캐나다에서 북미 담당 Apple IT Support 일을 했다.
• 캐나다 영주권 취득.

위와 같은 다양한 경험에도 여전히 자기성장 갈증은 채워지지 않았다.

{A-0: '가치관'} ,

무모한 도전의 동력은 무엇일까도 생각해 봤다. 나의 가치관이었다.

• 새로운 도전을 해결하며 성장 추구.
• 누군가에게 도움을 줄 수 있는 선한 영향력 전파.
• 숲 전체를 보는 걸 좋아한다.
• 가능성을 믿고 중시한다.

{A-1: '개발 공부 시작 계기'} ,

어느 날, 지인의 초대를 받아 뉴욕에 있는 구글 오피스를 방문했다. 업무 환경을 보고, 처음으로 개발자가 멋있어 보였다. 초대해 준 개발자에게 개발을 왜 좋아하는지 물었다. "Why do you like coding?"

"We learn new things everyday. 우리는 매일 새로운 것을 배워." 라고 대답했다. 프로그래밍 언어는 세계인이 이해할 수 있다는 매력에 빠졌고, 성장에 집착하는 프랭크는, 개발에 겁도 없이 감히... 도전해 보고 싶었다. (이때까지는 몰랐다.. 개발자의 벽을....)

옆에 있는 한국인 개발자에게 공부를 어떻게 하셨는지 여쭤봤다. 본인이 경험한 '쌍용교육센터 국비지원'을 추천해 주셨다. 다른 개발자들의 견해도 듣고 싶어서 판교테크노밸리에서 진행된 이고잉님의 웹 개발 세미나를 참여했다. 성장을 즐기고 지식을 나누는 개발자 생태계 매력에 빠졌고, 쌍용교육센터 면접 일정을 잡았다.

(면접관) - "집이 센터와 상당히 머시군요. 교육과정도 쉽지 않아서 비전공자는 코딩 경험 없이 과정을 따라가기 힘들 수도 있어요."

면접자분의 말씀에 도전정신이 번쩍 들었고, "센터 근처에 있는 고시원부터 알아보겠습니다. 최선을 다해 포기하지 않고 노력하겠습니다."라고 말씀드렸다.

(면접관) - "약속할 수 있어요?" (프랭크) - "네, 책임감을 가지고 최선을 다하겠습니다." ("타이슨 - 누구나 그럴싸한 계획을 갖고 있다...")

이렇게 스펙타클한 개발 여행이 시작됐다.

{A-2: '험난한 여정의 시작'} ,

사우나 뜨거운 물에 깊게 들어갔다 나온 느낌. 정말 뜨거웠다. 그것도 아주 많이...... 🔥

* 교육과정 (880시간) 
1. Java (1~2주)
2. 팀 프로젝트 (2주) 
3. HTML, CSS, JavsScript (1주) 
4. JSP, DB (2주)
5. Spring (2주) 
6. React (1주)
6. 마지막 팀 프로젝트

면접관이 말씀해 주신 대로 교육과정을 따라가기 숨쉬기 힘들 정도로 어려웠다. 같은 반 교육생들 90% 이상이 전공자였고, 강사님은 중간 실력에 맞춰서 수업을 진행하셨다. 변수가 무엇인지, 어떻게 선언하는지, 왜 선언하는지 조차도 몰랐던 나는 큰 절망감을 느꼈다. 멘붕이었다.

시간이 지나면서 탈락자가 나오기 시작했다. 오기가 생겼던 것일까? 나는 어떻게 해서든 포기하고 싶지 않았다. 무엇보다 중간 탈락자가 되고 싶지 않았다. 프로젝트 팀원들에게 미안하지만 조금이라도 도움이 되고싶었고, 무엇보다 배우고 싶었다.

감사하게도 교육생 친구들은 간단한 질문들까지 성심성의껏 대답해 줬으며 방향성에 도움을 주었다. 강사님도 끝까지 격려를 해주셨다. 감사한 인물들이 많다.

과정이 순탄하지는 않았지만, 탈락하지 않고 수료했다. 백엔드와 프런트엔드의 차이를 정확히 배웠다.

이렇게 소중한 시간을 보냈고, 파란만장한 여정은 시작됐다.

{A-3: '프런트엔드'} ,

개발이 적성에 맞는지 생각해 본 적이 수 없이 많았다. 악성 바이러스 임포스터 신드롬도 매번 찾아온다. 그럼에도 내가 프런트엔드 개발을 하는 이유는 성격과 관련이 있다.

• 커뮤니케이션 프런트엔드 개발 직무의 경우 사용자/기획/디자이너/개발자 등과 중간 다리 역할을 수행하는 경우가 있다. 생각을 정중하게 전달하고 이를 설득하는 능력이 빛을 발할 때가 있다고 믿는다. 공감 능력이 중요하다.

  나는 사용자의 경험이 비지니스에서 1순위라고 생각한다. 프런트엔드는 사용자와 직접 피드백을 공유하는 1선에 있다. 사용자에게 좋은 영향력을 전달할 수 있는 포지션이라고 생각한다.

  *한마디로 생산적인 소통을 즐긴다. *

• 도전 끊임없는 학습은 프런트엔드 분야에만 국한되지는 않지만, 여타의 개발 분야보다 트렌드의 변화가 상대적으로 빠르다. 프런트엔드는 새로운 기술과 트렌드를 꾸준히 학습하고, 시도해 볼 수 있다는 점이 있다. 다양한 도전을 하는 내 모습이 보인다.

  성장을 위해 꾸준히 다양한 도전을 할 수 있다.

{A-4: '번아웃 _ 개발을 계속할 수 이유'} ,

번아웃이란, 일에 지나치게 몰두하던 사람이 어느 시점에서 갑자기 모두 불타버린 연료와 같이 극도의 피로감을 느끼며 무기력해지는 것을 의미하는 용어다.

번아웃은 육체적으로 힘들 때, 불확실성에 오는 불안함, 결과가 보이지 않을 때 찾아 온다고 한다.

• ** 가치관 (성장) ** 나는 임포스터 신드롬을 겪으면서, 미래에 대한 불확실성이 커지며 번아웃이 여러 번 다녀갔다. 불확실성을 완벽히 제거하기는 쉽지 않다. 하지만, 나의 가치관이 무엇인지 셀프 리마인드를 해주면서 회복한다.

• 운동 (작은 목표 => 작은 성취감 반복) 20kg 이상 감량하기! 물론 살을 빼고 싶었지만... 이렇게 큰 목표가 아니라 작은 단위로, 작은 결과를 스스로에게 자주 보여주려고 노력했다. 지금은 20kg 이상 감량했고 드디어 밴드 없이 턱걸이를 하나씩 할 수 있다. 누군가에게 턱걸이는 10개가 기본 운동일 수 있지만, 나는 내 속도에 맞춰가면 된다. 코딩으로 머릿속 안개가 낄 때, 운동은 절대적으로 도움이 된다. "코딩도 내 속도에 맞춰서 하면 된다." 라는 마인드 컨트롤도 배우고 있다. 체력도 좋아지는 걸 느낀다.

• *써포트 + 커뮤니티 + 봉사활동 * 코딩 공부를 시작하면서 도움을 주신 감사한 분들이 많다. 나이와 국적을 떠나서, 내가 개발자로서 진심으로 성장하길 응원해 주시는 분들이 많다. 개발자 커뮤니티에서 질문을 하면 답이 올 확률은 대부분 90% 이상이다. 개발자는 지식공유를 즐긴다. 앞서 말한 바와 같이 난 지식공유를 좋아한다. 나의 가치관을 감사하게 생각해 준 한 글로벌 커뮤니티에서 admin 제안을 했으며, 현재는 웹 개발을 처음으로 접하는 분들에게 최대한 도움을 줄 수 있는 선에서 선한 영력을 전달하고 있다.

• 영어 공부 나는 세계 많은 사람들과 소통 하기 위해서, 직접 부딪히며 수년간 영어를 배우고 있다. 프로그래밍 언어도 마찬가지로 세계인과 소통이 가능하다는 매력이 있다. 영어 공부도 할 수 있는 큰 장점이 있다.

나에게 개발이란, 겸손과 감사함을 바탕으로 성장을 도와주는 스승이다. 새로운 것을 매일 배우는게 재밌다.

개발자로 일하면서 문제를 해결하고, 새로운 기술과 도구를 배우며 성장할 수 있다는 것이 매우 매력적이다. 또한, 개발자로서 사용자의 문제를 해결하고, 그들의 삶을 편리하고 즐겁게 만들 수 있다는 점도 나에겐 큰 의미가 있다.

] ,

< 나를 표현할 수 있는 키워드 >

무모함 / 추진력 / 실행력 / 자기성장 / 긍정적인 영향력 / 스마일 / 사교성 / 커뮤니티 / 다양한 경험

데이터 바인딩이란?

• 데이터 바인딩은 화면에 보이는 데이터와 브라우저 메모리에 있는 데이터를 일치시키는 기법

자바스크립트 웹 애플리케이션의 복잡도가 증가하면서 브라우저의 메모리에 있는 여러 개의 자바스크립트 객체와 화면에 있는 데이터를 일치시키기가 매우 어려워졌다. 이러한 어려운 작업을 쉽게 해주는 해결책이 있다면 그건 데이터 바인딩일 것이다. 데이터 바인딩 이란 두 데이터 혹은 정보의 소스를 모두 일치시키는 기법이다. 즉 화면에 보이는 데이터와 브라우저 메모리에 있는 데이터를 일치시키는 기법이다. 많은 자바스크립트 프레임워크가 이러한 데이터 바인딩 기술을 제공하고 있다.

데이터 바인딩 (Stackoverflow)

Can anyone explain the difference between Reacts one-way data binding and Angular's two-way data binding

구글링을 하던 중 7년전 stackoverflow 유익한 정보를 찾았다.

*단반향 (1 way data binding) *

• 리액트는 부모가 자식으로 props를 전달하는 방법을 선택한다. 부모의 state를 바꾸려면 이벤트를 걸어서, state를 자식에게 전달하고 부모와 자식이 소통을 하게 된다. 여기서 데이터가 흘러가는 방향은 부모 -> 자식

*양반향 (2 ways data binding) *

• 리액트에서와 달리 앵귤러에서는 이벤트가 필요 없다는 얘기인건가..? 이게 가능하구나..

바인딩 코드로 접하기

앵귤러 뭐지..? html을 그냥 막 가져다 쓰는건가..?

*단반향 (1 way data binding) *

리액트는 HTML을 건드리지 않는다. 렌더링에 의존한다. 데이터를 바꾸려면 이벤트가 필요하다.

React doesn't have a mechanism to allow the HTML to change the component. The HTML can only raise events that the component responds to. The typical example is by using onChange.

//js
render() { 
    return <input value={this.state.value} onChange={this.handleChange} />
}

handleChange(e) {
    this.setState({value: e.target.value});
}

  /*
   The value of the `<input />` is controlled entirely by the render function.
   The only way to update this value is from the component itself, 
   which is done by attaching an onChange event to the `<input />` 
   which sets this.state.value to with the React component method setState. 
   The `<input />` does not have direct access to the components state, 
   and so it cannot make changes. This is one-way binding. 
  */

*양반향 (2 ways data binding) *

내가 느낀 엥귤러 양방향 데이터 바인딩은, 가상 DOM이 아닌 오리지널 DOM을 건드리는 것 같다. $scope.name 같은 변수를 직접적으로 건드려서 watcher 기능으로 변화가 있을 때마다 코드를 자동으로 바꿔주는 것 같다.

Changes to the <input /> are reflected in the $scope.name property automatically, since ng-model sets up watches the input and notifies $scope of the changes. Changes from the code and changes from the HTML are two-way binding. (Check out this fiddle)

//js
$scope.name = 'test';
$timeout(function()  { $scope.name = 'another' }, 1000);
$timeout(function()  { console.log($scope.name); }, 5000);

<!-- html --->
<input ng-model="name" />

 /* 
   The input will start out with test, then update to another in 1000ms. 
   Any changes to $scope.name, 
   either from controller code or by changing the input, 
   will be reflected in the console log 4000ms later. 
 */

장단점/특징

*** 단방향 **

장점 : 데이터 변화에 따른 성능 저하 없이 DOM 객체 갱신 가능, 데이터 흐름이 단방향(부모->하위 컴포넌트)이라, 코드를 이해하기 쉽고 데이터 추적과 디버깅이 쉬움 단점: 변화를 감지하고 화면을 업데이트 하는 코드를 매번 작성해야 함

• 컴포넌트 내에서 '단방향 데이터 바인딩'은 Javascript(Model)에서 HTML(View)로 한 방향으로만 데이터를 동기화하는 것을 의미함. [JS(Model) -> HTML(View)]

• 💡 단방향 데이터 바인딩이기에 역으로 HTML(View)에서 JS(Model)로의 직접적인 데이터 갱신은 불가능. 이벤트 함수(onClick, onChange,...)를 주고 함수를 호출한 뒤 Javascript에서 HTML로 데이터를 변경해야 함. [HTML(View) -> JS(Model)]

• 💡 컴포넌트 간에서 단방향 데이터 바인딩은 부모 컴포넌트에서 자식 컴포넌트로만 데이터가 전달되는 구조.

*** 양방향 **

장점 : 코드의 사용면에서 코드량을 크게 줄여줌 단점 : 변화에 따라 DOM 객체 전체를 렌더링해주거나 데이터를 바꿔주므로, 성능이 감소되는 경우가 있음

• 💡 컴포넌트 내에서 '양방향 데이터 바인딩'은 Javascript(Model)와 HTML(View) 사이에 ViewModel이 존재하여 하나로 묶여서(Binding) 되어서 둘 중 하나만 변경되어도 함께 변경되는 것을 의미. [HTML(View) <-> ViewModel <-> Javascript(Model)]
• 💡 컴포넌트 간에서는 부모 컴포넌트에서 자식 컴포넌트로는 Props를 통해 데이터를 전달하고, 자식 컴포넌트에서 부모 컴포넌트로는 Emit Event를 통해서 데이터를 전달하는 구조.

느낀점

솔직히.. 엥귤러를 직접 코드로 짜보지 않아서 아직까지는 100% 와닿지 않는다. 하지만, 컴포넌트 내부에서 혹은 컴포넌트 간에 데이터 바인딩을 이해한다면 보는 시야가 넓어지지 않을까

Reference

• https://stackoverflow.com/questions/34519889/can-anyone-explain-the-difference-between-reacts-one-way-data-binding-and-angula
• https://dzone.com/articles/explaining-data-binding-and-server-rendering-in-an-2
• https://poiemaweb.com/angular-component-data-binding
• https://authorkim0921.tistory.com/13

const t0 = performance.now()
console.time('test')
let num = 1000, arr = [];

for (let i = 0; i < 10000; i++) {

    arr[i] = num.toString();
  // arr[i] = num + '' 
  // arr[i] = String(1000);

}
const t1 = performance.now()
console.log(t1 - t0, 'milliseconds')
console.timeEnd('test')

Reference

• http://jindo.dev.naver.com/jsMatch/index.html
• https://velog.io/@zuyonze/%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8-%EC%84%B1%EB%8A%A5-%EC%B5%9C%EC%A0%81%ED%99%94%EC%97%90-%EB%8C%80%ED%95%9C-%EC%9D%98%EB%AC%B8-glk00t4bxk
• https://yceffort.kr/2020/12/measuring-performance-of-javascript-functions
• https://12bme.tistory.com/134
• https://mingggu.tistory.com/127

자바스크립트 so strange.. 10일만에 만들어져서 그런가...?

정의를 보면.. NaN는 'Not-a-Number'의 줄임말. 그러면 number가 아니라는건데...

NaN

• NaN is not a number.
• typeof(NaN) should not be a number.
• console.log(typeof NaN) - "number" 응.....? number 타입이라고..?

isNaN()

• isNaN() 함수는 값이 NaN(Not a Number)인지 판별한다.
• false 리턴 하면 숫자, true 리턴하면 숫자가 아니라는건가?
• MDN에서도 아주 혼란스럽고, 완전히 신뢰할 수 없다고 나온다. ㅋㅋㅋㅋ

Summary: Number() parsing 과정을 거친다.

• isNaN("") -> 거짓: 빈 문자열은 NaN이 아닌 0으로 변환된다.
• isNaN(" ") -> 거짓: 공백이 있는 문자열은 NaN이 아닌 0으로 변환된다.
• isNaN(null) -> 거짓
• isNaN("37") -> 거짓: "37"은 NaN이 아닌 숫자 37로 변환된다

x                    Number(x)    isNaN(x)
undefined                NaN          true
{}                        NaN          true
'foo'                    NaN          true
new Date('')            NaN          true
new Number(0/0)            NaN          true

console.log(isNaN(0)); // false 
console.log(isNaN(1)); // false 
console.log(isNaN('100')); // false 

isNaN(NaN);       // 참
isNaN(undefined); // 참
isNaN({});        // 참

isNaN(true);      // 거짓
isNaN(null);      // 거짓
isNaN(37);        // 거짓

// 문자열
isNaN("37.37");   // 거짓: "37.37"은 NaN이 아닌 숫자 37.37로 변환된다.
isNaN("123ABC");  // 참: parseInt("123ABC")는 123이지만 Number("123ABC")는 NaN.
isNaN("");        // 거짓: 빈 문자열은 NaN이 아닌 0으로 변환된다.
isNaN(" ");       // 거짓: 공백이 있는 문자열은 NaN이 아닌 0으로 변환된다.

// 이것이 허위 양성이고 isNaN이 완전히 신뢰할 수 없는 이유이다.
isNaN("blabla")   // 참: "blabla"는 숫자로 변환.
                  // 이것을 숫자롯 parsing 하는 것을 실패하고 NaN을 반환.

Number.isNaN()

잠깐만.. 정의부터 다시 읽어보자..

• 주어진 값의 유형이 Number이고, 값이 NaN이면 true, 아니면 false.
• Number 형에서만 사용가능하고 강제로 Number 변환을 시도하지 않는다.
• 기존부터 존재한 전역 isNaN() 함수의 더 엄격한 버전.
• NaN이 NaN인지 계산할 때, 두 동일 연산자 ==과 === 모두 false로 평가되므로 값의 NaN 여부를 알아내려면 Number.isNaN()이 필요함.

                |       Number.isNaN()       |        isNaN()
----------------+----------------------------+-----------------------
value           | value is a Number | result | Number(value) | result
----------------+-------------------+--------+---------------+-------
undefined       | false             | false  | NaN           | true
{}              | false             | false  | NaN           | true
"blabla"        | false             | false  | NaN           | true
new Date("!")   | false             | false  | NaN           | true
new Number(0/0) | false             | false  | NaN           | true

Number.isNaN({});
// <- false, {} is not NaN
Number.isNaN('ponyfoo')
// <- false, 'ponyfoo' is not NaN
Number.isNaN(NaN)
// <- true, NaN is NaN
Number.isNaN('pony'/'foo')
// <- true, 'pony'/'foo' is NaN, NaN is NaN

isNaN({});
// <- true, {} is not a number
isNaN('ponyfoo')
// <- true, 'ponyfoo' is not a number
isNaN(NaN)
// <- true, NaN is not a number
isNaN('pony'/'foo')
// <- true, 'pony'/'foo' is NaN, NaN is not a number

아직도 헷갈리는 부분...

Number.isNaN()는 Number 타입중에 isNaN을 찾는걸로 이해했는데.....

Number.isNaN('pony'/'foo')
// <- true, 'pony'/'foo' is NaN, NaN is NaN

• isNaN() converts the argument to a Number and returns true if the resulting value is NaN.
• Number.isNaN() does not convert the argument; it returns true when the argument is a Number and is NaN.

많이 읽어도... 헷갈리는건.. MDN이 이해해주지만 그래도 헷갈린다..

// polyfills
if(!Number.isNaN) {
  Number.isNaN = function(n) {
    if( typeof n === "number" ) {
      return window.isNaN(n)
    } 
    return false
  }
}

Reference

• https://www.codementor.io/@diegopalacios/nan-isnan-number-isnan-1agz7vzs08
• https://www.designcise.com/web/tutorial/what-is-the-difference-between-isnan-and-number-isnan-in-javascript
• https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Number/isNaN
• https://stackoverflow.com/questions/33164725/confusion-between-isnan-and-number-isnan-in-javascript

*Step by step 따라하기. *

TMDB : https://www.themoviedb.org/ API 사용하기: https://developers.themoviedb.org/3/getting-started/introduction

1.회원가입하기

2. 회원가입 후, 이메일 가서 Activate My Account 해야함.

3. 로그인하기 -> 프로필 누르기 -> Settings

4. Settings -> API 클릭 -> Developer 클릭 -> Create 클릭

5. API 키 생성하기

6. 키 생성하면, 바로 API key를 보여줌.

7. API key를 생성하면, 이메일이 날라옴. -> VIEW REPLY

8. API key 와, API 사용에 필요한 링크를 공유해줌

Enjoy learning!

TMDB : https://www.themoviedb.org/ API 사용하기: https://developers.themoviedb.org/3/getting-started/introduction