설치

electron과 electron-builder를 설치한다. npm install -D electron electron-builder

main.js 작성

public 폴더 안에 public/index.html의 랜더링 프로세스와 연결하는 main.js를 만들어준다.

const { app, BrowserWindow } = require("electron");
const path = require("path");
const url = require("url");

function createWindow() {
  const win = new BrowserWindow({
    width: 1920,
    height: 1080,
  });

  const startUrl =
    process.env.ELECTRON_START_URL ||
    url.format({
      pathname: path.join(__dirname, "/../build/index.html"),
      protocol: "file:",
      slashes: true,
    });
  win.loadURL(startUrl);
}

app.on("ready", createWindow);

main 파일 바꾸기

package.json에서 main 파일을 바꿔준다. "main": "public/main.js",

스크립트 추가

package.json에 데스크탑 앱으로 띄우기 위한 script를 추가

"react-start": "BROWSER=none npm start",
"electron-start": "ELECTRON_START_URL=http://localhost:3000 electron .",
"electron-pack": "npm run build && electron-builder build -c.extraMetadata.main=build/main.js"

react-start: 브라우저 모드가 아닌 채로 리액트를 돌린다 electron-start: http://localhost:3000를 일렉트론에서 띄운다 electron-pack: 일렉트론으로 데스크탑 앱 빌드하는 명령어

개발 환경 돌리기

npm run react-start, npm run electron-start 터미널창을 두개 띄워서 두 명령어를 동시에 돌려야 한다.

배포용 빌드

빌드하는 명령어이다. npm run electron-pack

프론트엔드 스터디 스프린트

Google Developer Student Club에서 프론트엔트 파트 관련 스터디를 진행하고 있다. 4개의 프로젝트를 받아서 2주씩 진행을 한다. 두번째 스프린트인 npm 패키지 배포가 끝나서 후기를 작성하려고 한다.

1.dom-visualizer 2.npm 패키지 배포 3.electron 비즈니스툴 4.graphic 프로젝트

Javascript 라이브러리를 만들어 npm에 배포한다

명세

필수 요구사항

• 다른 라이브러리에 의존성이 있을 것
• README.md 작성
• .npmignore 작성
• 프론트엔드 테스트 라이브러리(jest , mocha , karma , TestCafe , jasmine) 중 하나 사용
• github 업로드
• 적절한 난이도

추가 요구 사항

• Typescript 지원
• React

처음부터 테스트하면서 했어야하는데(ㅠㅠ) 코드 다 짜고 굳이 넣으려니까 필요를 못 느꼈고, karma가 react와 호환이 잘 안되는 것 같다.

기간

일주일 받았는데 원래 하던 걸 고친거라 그렇게 오래 걸리지 않았다.

기술 스택

React 컴포넌트라 React에 peerDependency가 있고, 다른 라이브러리에 의존성이 있어야 해서 gradient-color v2를 사용했다.

library 번들링 할때는 rollup(esm, cjs, d.ts 등의 여러 버전으로 나눠서 한꺼번에 번들링이 가능해서)이 좋다는 말을 들어서 rollup을 사용했다.

과정&코드

magic-boolean-conch

연습용으로 간단한 것 하나 배포했다.

magic-boolean-conch라는 뭘 넣든 true,false, "true","false", undefined 중 하나를 리턴하는 클래스를 가진 라이브러리이다.

typescript를 지원한다. 쉽다. tsc로 빌드된 두 파일을 package.json에 이렇게 나눠 쓰면 된다.

  "main": "dist/index.js",
  "types": "dist/index.d.ts",

test 라이브러리로 jest를 사용했다. 검색해 본 결과 jest도 react처럼 페이스북에서 만들었기 때문에 둘이 호환이 좀 더 쉬운 것 같은데, 이미 jest를 사용해서 이번에는 다른 거 써보자 했다가 뒤에서 좀 꼬인 듯ㅎㅎ...

react-pinwheel-navbar

누가 z-index paradox flower처럼 생긴 카드 네비바를 앱 디자인에 넣었는데 개발자 친구들과 그 상태에 대해 얘기하다가 하게 되었다.

1번 위에 2번, 2번 위에 3번씩 가다가, 5번이 다시 1번 위에 와야하는데 어떻게 구현할거냐는 얘기였다. 3d로 하거나 개별 element를 쪼개서 z-index를 조절해주면 된다. 나는 꼭 생기는 하나의 문제 카드와 겹치는 교집합 부분만 위에 덧그려줬다. 다만 그냥 css로 구현하는 한 애니메이션을 넣는 것은 아주 어렵다. 나는 clip-path로 카드를 쪼개서 z-index를 다르게 했는데, 멀쩡하게 보이게 하기 위해서 한 카드 엘리먼트를 3파트로 나눴다. rollup으로 esm 버전, cjs 버전 한번에 번들링하고 pacakge.json에 각각 나누어썼다.

  "main": "dist/cjs/index.js",
  "module": "dist/esm/index.js",

react 모듈을 살짝 본 적이 있는데 그 친구도 main은 common.js더라고요.

결과

https://github.com/gdsc-ys/react-pinwheel-navbar https://www.npmjs.com/package/react-pinwheel-navbar 아래가 사용하는 코드이다. npm에서 react-pinwheel-navbar를 다운받는다. import PinwheelNavbar from "react-pinwheel-navbar"; 카드 가로세로, 카드 개수 등은 자유롭다. 색깔이나 눌렀을 때 이동하는 링크, 텍스트 등은 배열로 넣는다.

import React from "react";
import ReactDOM from "react-dom/client";
import "./index.css";
import PinwheelNavbar from "react-pinwheel-navbar";
import { colors, texts, links, onClicks } from "./value";

const root = ReactDOM.createRoot(document.getElementById("root"));

root.render(
  <React.StrictMode>
    <PinwheelNavbar
      colors={colors}
      texts={texts}
      number={30}
      width={80}
      height={120}
      border={"1px solid black"}
      borderRadius={"5px"}
      textColor={"black"}
      fontWeight={"regular"}
      onClicks={onClicks}
      links={links}
    ></PinwheelNavbar>
  </React.StrictMode>
);

그럼 여러 모양으로 바꿔서 쓸 수가 있다.

아쉬운 점& 앞으로 고치고 싶은 점

• style object를 만들어 인라인으로 넣는 방식으로 짰는데 별로 좋은 방법이 아니었던 것 같다. 추가 속성을 넣을 때마다 객체 복사를 해야 했고 hover 옵션 지원을 못했다. 다른 식으로 고치고 싶다.
• Test 라이브러리 못 붙인 것
• Typescript로 짜지 않은 것 (Typescript 지원하지 못한 것)
• 애니메이션 가능하게 하기 (아예 다른 패키지로 배포하고 싶다)
• 카드 커스텀 자유도 높이기

아쉬운 점이 많지만 2번 배포했으니까 다음에는 좀 더 잘 해보겠습니다. npm 프로젝트에서 제일 먼저 봐야할 것은 package.json임을 다시 한 번 느낀 스프린트...

rollup은 index.jsx를 알아서 찾을 수가 없다. 이런 구조일 때 리액트 스크립트로 빌드를 하거나 돌리는 경우 './Card'나 './Card/index' 경로로도 index 파일을 잘 찾지만, rollup은 못 찾는다.

'./Card/index.jsx'로 정확히 써야한다.

프론트엔드 스터디 스프린트

Google Developer Student Club에서 프론트엔트 파트 관련 스터디를 진행하고 있다. 4개의 프로젝트를 받아서 2주씩 진행을 한다. 첫번째 스프린트인 dom visualizer가 끝나서 후기를 작성하려고한다.

1. dom-visualizer 2. npm 패키지 배포 3. electron 비즈니스툴 4. graphic 프로젝트

명세

주제가 모 기업 인턴 과제라는 소문이 있었다. html 코드를 받아서 dom 트리 모양으로 랜더하면 된다.

• html 인풋창
• html 파싱 기능
• 잘못된 DOM 입력 시 에러 처리-간단하게 사유를 표시 1) 제대로 닫히지 않은 태그 <></> 2) 깊이가 잘못된 태그 <div><span><div/></span> 3) 속성값이 쌍따옴표/따옴표로 잘 감싸져 있는지 data-attr=“’, data-attr=“ 4) 빈 값이 할당된 속성 data-attr=”” 5) 태그 내 중복된 속성 값 6) script, style 태그는 무시하지만, (1)(2) 에러 처리에는 포함
• 돔 트리 이미지 랜더
• 태그(element)/속성(attribute)/텍스트(text)끼리 시각적으로 구분 가능

나는 명세만 딱 맞췄다. 지금 코드에서 주석 태그 처리가 별로 어렵진 않은데 하진 않았다.

기간

3주를 받긴 했는데 실제 작업 시간은 3-4일 정도...

기술 스택

TypeScript를 요구해서 TypeScript를 사용했고... devDependency말고 없다.

과정&코드

세팅

module

html에 js를 module로 가져왔더니 html에서 js를 호출하지 못하고 js만으로 html을 건드려야 했는데, 리액트가 왜 그런 구조인지 조금 더 이해가 된 듯...

브라우저는 common.js를 지원하지 않는다. ESmodule도 SOP(single origin policy) 등으로 돌릴 때마다 터지거나 모듈 위치 못 찾거나 그랬다.

TypeScript

예전에 JavaScript 코드에 TypeScript를 씌운 적이 있는데 그 때는 그냥 막힐 때마다 any를 사용했는데, 처음부터 아예 TypeScript로 작성하니까 느낌이 달랐다.

any를 한 번 할당했는데 가슴이 찢어진다...

TypeScript를 얹는 게 확실히 낫다!는 건 모르겠는데(여전히 NaN이 나를 괴롭혔다) null이나 undefined, 코드 구조, JavaScript의 타입 관련해서 조금 더 신경 쓰게 됐다.

학교에서 배운 객체 지향 한 번 더 익힌 거 같기도 하다.

rollup

rollup를 번들링에 사용했다. rollup은 npm 패키지 배포할 때 rollup을 썼더니 익숙해져서 관성으로 그냥 사용했다.

코드

작업 순서도 아래와 같은 순서로... 차례로... Parser는 금방 끝났는데 Tokenizer와 Renderer가 오래 걸렸다...

Tokenizer

• input-날 것의 html string
• output-태그 이름, 태그 종류, 속성 등을 가지는 Token 객체.

여기를 또 3부분으로 쪼갰다.

태그/텍스트로 일단 구분하는 기능, 태그 내에서 tagname text와 attribute text를 구분하는 부분, attribute를 객체로 키/값으로 구분하는 부분.

여는 태그, 닫는 태그, 텍스트를 준다. 여는 태그 중 여기서 혼자 닫히는 태그(meta, link, img, br)등에게 따로 번호를 준다.

tagname, attribute 둘 다 문제가 있을 때는 에러 키와 에러 이유를 넣어서 파서에 일단 넘겼다.

Parser

• input-태그 이름, 태그 종류, 속성 등을 가지는 Token 객체.
• output-dom tree 객체의 root node, 최대 레벨과 레벨 별 노드 개수

stack으로 열린 태그는 push, 닫힌 태그는 top과 같을 때 pop하면서 Token을 상속해 부모/자식 속성과 level을 추가한 Node 객체를 만든다.

여기서 stack에 넣느라 순회하는 김에 여기서 error 태그를 체크해서 에러를 리턴했다. Html 구조가 잘 닫혔는지도 여기서 체크한다.

node마다 레벨이 어디인지 체크해서 넣어주고, 한 레벨에 최대 몇 노드가 들어가는지 체크하여 배열로 만든다. 랜더러에 넘겨서 랜더에 사용할 것이다.

Renderer

• input-dom tree 객체의 root node, 최대 레벨과 레벨 별 노드 개수
• output-html 화면에 돔트리 랜더

트리를 재귀로 순회하면서 attribute도 레벨 별 카운트에 넣어준다. 현재 레벨의 다음 레벨 노드 개수와 합친다. 이렇게 레벨이 몇 개인지, 한 레벨에 몇 노드가 들어가는지 파악해서 각 노드의 좌표를 잡아준다. 부모가 100 100이라고 치고 퍼센트로 잡는다. 나름 반응형인...ㅎㅎ

좌표와 속성을 받아 화면에 Node 이미지를 만드는 함수, 부모 노드 좌표와 내 좌표를 받아 줄을 그어주는 함수를 만들었다.

renderingLine 함수가 부모 노드 좌표와 내 좌표를 기준으로 div를 만들고 clip-path로 선을 만들었다. %로 뒀더니 div 크기에 따라 선 굵기가 달라진다ㅠㅠ 그래서 사실 선마다 div가 깔려있다.

다시 순회하면서 render해준다. error 어트리뷰트는 빨갛게 랜더하고 왜 에러가 났는지 이유를 띄워준다.

결과

https://mumwa.github.io/dom-visualizer/ https://github.com/mumwa/dom-visualizer

아쉬운 점& 앞으로 고치고 싶은 점

• KMP 같은 문자열 비교 관련 알고리즘을 몰라서 공부하고 적용할 수 있으면 하고 싶다.

• 그래픽 라이브러리 안 쓰고 선을 긋거나 하는데 한계가 있었다. 어차피 좌표를 다 구했으니까 쓰면 훨씬 나은 모양으로 만들 수 있을 것 같다.

• 내가 임의로 넣은 self-closing같은 속성들을 랜더에서는 쳐내기

• 주석 처리를 넣고 싶다.

나중에 고치면 알려드리겠습니다.

디자인이나 구성 자체는 마음에 듭니다. 튜닝의 끝은 순정이다!

표현식 평가 도중 평가 결과가 확정된 경우 나머지 평가 과정을 생략한다는 뜻이다. Javascript말고 다른 언어에서도 대부분 적용된다.

대부분의 코드가 좌항->우항 순서로 평가된다는 것을 전제로 한다.

논리곱에서 단축 평가

a and b
a && b

둘 다 true면 참을, 둘 중 하나라도 false면 false가 반환될 것이다.

그렇다면 a가 false면 b가 무엇이든 무조건 false일 것이다. 그러니까 &&의 앞부분, 우항, a가 true면 바로 a를 반환한다.

그렇다면 a가 true면 결과는 b가 true인지 false인지에 따라 결정이 된다. 그러니까 &&의 앞부분, 우항, a가 false면 바로 b를 반환한다.

Javascript에서

String에 뭐가 들어있기만 하다면, Javascript는 truthy로 평가할 것이다. 그러면 아래 코드는 무슨 값을 반환할까?

'Cat'&&'Dog'

'Cat'이다. 앞 부분의 'Cat'이 truthy로 평가되어 'Dog'는 값에 영향을 끼치지 못한다고 생각하고 단축해 무조건 앞부분을 반환하기 때문이다.

논리합에서 단축 평가

윗부분을 이해했다면, 여기도 비슷하다.

a or b
a || b

둘 중 하나라도 true면 참을 반환하고 둘 다 false일 때만 둘 다 반환한다.

그렇다면 a가 true면 b가 무엇이든 무조건 true일 것이다. 그러니까 &&의 앞부분, 우항, a가 true면 바로 a를 반환한다.

그렇다면 a가 false면 결과는 b가 true인지 false인지에 따라 결정이 된다. 그러니까 &&의 앞부분, 우항, a가 false면 바로 b를 반환한다.

Javascript에서

아까 말했듯이, 'Cat'은 truthy로 평가된다. 그러면 아래 코드는 무슨 값을 반환할까?

'Cat'||'Dog'

'Dog'이다. 앞 부분의 'Cat'이 true로 평가되어 뒷부분의 'Dog'의 값이 전체를 결정할거라고 생각하고 단축해 무조건 뒷부분을 반환하기 때문이다.

활용 방법

&&:값이 있으면 뒤의 값을 반환(연산을 이어가기)

if문 대체

done이 true면 '완료'가 message값에 들어간다.

let done=true;
const message = ''; 

if (done) message='완료';//if문
message=done&&'완료';//논리연산자 단축평가 활용

이렇게 단축 평가를 활용하여 if문을 대체할 수 있다.

null이나 undefined 프로퍼티 참조 막기

원래는 null이나 undefined의 프로퍼티 참조하면 에러가 발생한다. 논리연산자를 활용하여 에러 대신에 null과 undefined를 반환하도록 코드를 쓸 수가 있다.

var elem=null;
var value=elem.value;//에러가 남
var value=elem&&elem.value;//있으면 값 반환, 없으면 null 반환

옵셔널 체이닝 연산자

여러 값을 알아서 truthy로 평가하는 js 특성과 논리 연산자를 활용하여 논리 연산자를 이렇게 사용하는 사람들이 많아지자, ECMAScript2020부터 아예 그런 식으로 쓰라고 구문을 제공했다. '?' 연산자이다.

var value=null;

var valueAnd=elem&&elem.value;

var valueOption=elem?.value;//optional chaining 

&&과 조금 다른 점은, &&는 '', 0이나 ''를 falsy로 평가하지 않고 객체가 존재한다고 평가하기도 한다. ?는 0이나 ''까지 무조건 false로 치고 뒷부분을 리턴한다.

var str='';

var lengtHand=str&&str.length;//''

var lengthOption=str?.length;//0

||:값이 없으면 뒤의 값을 반환(연산을 이어가기)

if문 대체

done이 false면 '미완료'가 error에 들어가는 코드이다.

let done=true;
const error = ''; 

if (!done) error='미완료';//if문
error=done||'미완료';//논리연산자 단축평가 활용

이렇게 단축 평가를 활용하여 if문을 대체할 수 있다.

default 설정

function getStringLength(str){
    str=str||'';
    return str.length;
}

매개 변수에 값이 들어오지 않았다면, 뒤의 값으로 설정한다.

null 병합 연산자

옵셔널 체이닝 연산자와 마찬가지로, 여러 값을 알아서 truthy로 평가하는 js 특성과 논리 연산자를 활용하여 논리 연산자를 이렇게 사용하는 사람들이 많아지자, ECMAScript2020부터 아예 그런 식으로 쓰라고 구문을 제공했다.

'??' 연산자이다.

var foo = null || 'default string';//"default string"
var foo = null ?? 'default string';//"default string"

둘이 다른 점은, 아까 ? 반대로, ''나 0을 기본값으로 칠 수 있으므로 ''나 0을 truthy로 평가한다.

var fooOr= ''||'default string';//"default string"
var fooNull= ''??'default string';//""

참고자료

모던 자바스크립트 Deep Dive-이웅모 저 9장 타입 변환과 단축 평가

구글이나 네이버 등에서 키워드를 검색 했을 때, 상단에, 앞페이지에 뜰수록 유저를 유입시키기 쉬울 것이다. 같은 내용이라도 검색 엔진에서 매기는 높은 순위에 들 수 있도록 작성되거나, 프론트가 개발되어 있으면 유리할 것이다. 사이트가 검색이 유리하도록 작성하는 것을 검색 엔진 최적화 Search Engine Optimization이라고 한다. 가볍게 알아두면 좋을 것 같아서 글을 작성한다.

유리한 키워드를 찾기

https://blackkiwi.net/ 여기는 블랙 키위라고 어떤 키워드가 검색에 유리한지, 어떤 키워드로 글을 써야 상단에 오를 확률에 높을지 확인할 수 있다. 예를 들어 '파이썬'이라는 키워드는 불리하다. 검색자도 많지만 게시글도 이미 너무 많기 때문이다. 이런 식으로 키워드가 유리한 키워드인지 확인할 수 있는 사이트가 많다. 근데 이건 개발자보다는 블로그 운영하는 사람이나 콘텐츠 쪽 사람이 신경 써줘야하는 내용 같기도 하다.

검색 엔진 점수를 받기 유리한 코드

검색 엔진이니까, 구글의 검색 엔진이 다르고 네이버의 검색 엔진이 다를 것이다. 나는 구글 기준으로 작성하겠다.

구글은 검색 순위를 매기는 기준이 완전히 자동화되어있다. 사람이 개입하지 않고 어떤 프로세스가 크롤링해서 점수를 매긴다.

참고: 크롤링이 싫다면 루트 디렉토리에 robots.txt 파일을 통해 특정 파일의 크롤링을 막을 수 있다.

# brandonsbaseballcards.com/robots.txt
# Tell Google not to crawl any URLs in the shopping cart or images in the icons folder,
# because they won't be useful in Google Search results.
User-agent: googlebot
Disallow: /checkout/
Disallow: /icons/

구글에서 제공하는 가이드를 내 나름 정리할텐데, 구글은 서치 콘솔이라고 이런 최적화 관련된 정보를 직접 입력하거나 매겨진 점수를 확인할 수 있는 콘솔을 제공한다. 내가 구글 서치 콘솔이라고 하면-> https://search.google.com/search-console/ 이 사이트를 의미한다. 참고한 가이드 자체가 구글 서치 내용이 많다.

사이트맵 작성

구글의 가이드에 따라 어떤 사이트인지 알려주는 정보를 xml, html 형식 사이트맵 파일을 작성한다. 이 사이트맵 파일의 위치(url)를 구글 서치 콘솔에 입력하면 구글에서 이 사이트가 어떤 사이트인지에 관한 정보를 인지하고 검색 점수 계산에 반영해 줄 것이다.

Google이 파일에 항상 액세스할 수 있도록 허용

robots.txt로 막으면 점수를 좀 깎는다고 합니다

<title> 태그

1. 페이지와 관련 있는 내용
2. 페이지마다 내용이 다를 것. 고유할 것
3. 길이가 너무 길면 감점이 들어간다

<meta> 태그

1. 페이지 내용을 잘 표현하기
2. 페이지마다 내용이 다를 것. 고유할 것
3. 이것도 길이로 점수를 매긴다

표제(h6) 태그

꼭 필요한 부분에서만 표제 태그 사용하기. 구조가 잘 짜여져 있고, <em> 및 <strong>으로 대체 가능한 부분 제외하기.

구조화된 데이터 마크업

이름: 삼성전자 노트북 컴퓨터 NT900X5N 평점: 4.8 사용자 검토: 540 가격: 239.99 재고 유무: 재고 있음. 등으로 데이터 양식을 잘 적어서 사용자가 알아보기 쉽게 하기. 이것도 구글 서치 콘솔에서 어떻게 보일지 확인 가능. 확실한 양식이 없는 상태에서 넣으면 오히려 불리할 수 있다.

검색엔진의 URL 사용 방식 이해

1. https에 구글이 높은 점수를 주는데, http https 둘 다 지원(http를 https로 리다이랙트)하고
2. www가 있는 버전과 없는 버전 둘 다 지원할 것

구조화된 사이트 url

1. url은 해당 페이지가 뭔지 잘 표현해야한다.
2. 구조가 너무 복잡하지 않을(depth가 너무 깊지 않을)것
3. main>article>card식의 구조가 잘 되어있고 흐름이 자연스러울 것.
4. 사용자가 이용하기 편하게 이동하는 링크를 잘 넣어줄 것.
5. 사용자가 잘 못 넘어갔을 때 404처리를 잘 해줄 것.

링크

무슨 링크인지 잘 설명해주기

이미지

1. 무슨 이미지인지 잘 표현하는 파일 이름과 대체 텍스트
2. css로 이미지를 넣는 것보다 html <img>로 넣는 것이 유리하다

모바일 친화적

반응형~

사용자에게 흥미로운 사이트

사실 검색 엔진의 점수에 가장 큰 영향을 미치는 것은 사용자이다. 여기에 추천하는 것들도 점수로 들어가는지는 모르겠다. 사용자가 명확하고 알아보기 쉬운 페이지로 만들어야한다!

참고 자료

검색엔진 최적화(SEO) 기본 가이드 https://developers.google.com/search/docs/beginner/seo-starter-guide?hl=ko

사전 지식

이 둘은 HTTP 프로토콜에서 제공하는 요청 시 포함하는 양식이다. 네트워크 통신 시 이 데이터로 무엇을 하려는건지 요청에 태그를 달아 보내는 것이다.

차이점

공통점

참고 자료

https://brilliantdevelop.tistory.com/33#:~:text=GET%EC%9D%80%20%EB%A6%AC%EC%86%8C%EC%8A%A4%EB%A5%BC%20%EC%A1%B0%ED%9A%8C,%EA%B0%80%20%EB%B3%80%EA%B2%BD%EB%90%A0%20%EC%88%98%20%EC%9E%88%EB%8B%A4.)

네트워크는 네트워크 프로토콜이 통신하는 구조를 7개의 계층으로 분리하여 각 계층간 상호 작동하는 방식을 정해 놓은 것이다.

1계층-물리계층(Physical Layer)

디지털 데이터를 아날로그 신호로 바꾸는 모듈. 하드웨어로 PHY칩으로 구현된다.

encoding 모듈 데이터를 아날로그 신호로 (전선으로 보낼 수 있게)바꾸어내보낸다.

decoding 모듈 아날로그 신호를 데이터로 해석한다.
두 컴퓨터를 전선으로 연결하여 1, 0 전기 신호를 주고 받는다. 이렇게 0, 1을 주고 받을 수 있다면, 컴퓨터의 모든 데이터를 주고 받을 수가 있게 될 것이다.

전기전자공학 기초에서 알 수 있을 어떤 사항들에 의하여, 우리는 딱 1 신호, 0 신호를 보내는 것은 불가능하다. 5v는 1, -5v는 0이라고 했을 때 딱딱 5, -5v만 보내는 것은 불가능하다. 그러므로 우리는 0과 1을 아날로그 신호로 바꿔서 보내고(encoding), 그 아날로그 신호를 0과 1로 바꾸는 과정(decoding)을 필요로 한다. 이 기능을 담당하는 게 물리 계층인 것이다.

이 모듈들은 함수인가요? 아니고 하드웨어적으로 구현되어있다. PHY칩이 해주는 일이다. 상위 계층의 패킷을 맨체스터 코딩과 차동 신호로 바꿔주는 역할을 한다고 한다. 그렇대요.

2계층-데이터 링크계층(DataLink Layer)

한 요청 단위를 식별할 수 있게 플래그를 달아 감싸는 모듈. 하드웨어로 랜카드에 구현된다.

encoding 모듈 한 요청 단위를 식별할 수 있게 플래그로 감싼다.

decoding 모듈 한 요청 단위를 식별하여 플래그를 푼다.
이렇게 한 컴퓨터에 여러 컴퓨터가 요청을 보낼텐데, 요청을 어떻게 끊어읽어야할까? 예를 들어, 1번 컴퓨터가 0101, 2번 컴퓨터가 0111, 3번 컴퓨터가 1011을 보냈다면, 내 컴퓨터에는 010101111011 식으로 들어온다. 그냥 들어오는게 아니고 계속 들어올 것이다. 어떻게 구분할까? 요청마다 앞뒤에 요청의 시작과 끝을 의미하는 데이터를 넣어서 보낸다. 맨 앞에 무조건 00, 맨뒤에 무조건 11을 붙이는 것이다. 그럼 이 비트를 기준으로 요청을 끊어 읽으면 된다. 이걸 '프레이밍'이라고 한다. 보낸 게 여기서 여기까지에요라고 감싸주는 것이다.

이렇게 보내는 쪽에서 원본 데이터를 플래그로 감싸고, 받는 쪽에서 원본 데이터를 플래그 푸는 것 역할을 데이터 링크 계층에서 하게 된다.

이것도 하드웨어적으로 구현된다. LAN카드(컴퓨터 통신을 위해 쓰는 장비)에서 해준다.

3계층-네트워크 계층(Network Layer)

데이터가 가야하는 목적지인 컴퓨터 주소를 표시하는 모듈. 운영체제의 커널에 소프트웨어적으로 구현된다. 라우터, IP.

encoding 모듈 데이터에 감싸서 주소를 달아 객체(구조체)로 만든다.

decoding 모듈 모듈을 풀어서 주소와 데이터를 구분한다.

엄청 많은 컴퓨터가 연결되어 있을텐데, 어느 컴퓨터로 갈지 알기 위해 컴퓨터마다 있는 고유한 주소, ip를 데이터에 앞에 달아서 보낸다.

이렇게 주소가 달린 데이터를 컴퓨터가 연결된 라우터에 보내면, 라우터가 패킷(여러 헤더가 달린 감싸진 데이터, 통신 단위)을 까서 주소를 보고 어디로 보내야할지 확인한다. 자신과 연결된 컴퓨터이면 거기로 보내고, 아니면 다른 라우터로 넘기고, 다른 라우터가 확인하고, 넘기고... 하면서 결국 목적지에 도착한다.

이렇게 많은 네트워크에 연결 속에서, 어디로 가야할지 찾는 걸 routing, 다른 라우터에게 넘겨주는 걸 forwarding이라고 한다.

라우터도 컴퓨터의 일종이라, 라우터를 지날 때마다 이 계층들을 다 지나서 다시 풀고 감싸고 한 다음에 다른 라우터나 컴퓨터로 보낸다.

4계층-전송 계층(Transport Layer)

컴퓨터에서 데이터가 어느 프로세스로 갈지 표시하는 모듈. 운영체제의 커널에 소프트웨어적으로 구현된다. TCP, UDP

encoding 모듈 포트 번호를 달아 데이터를 감싼다

decoding 모듈 포트 번호를 보고 데이터를 해당 프로세스로 보낸다

그래서 전세계의 컴퓨터가 연결되었다. 컴퓨터는 프로그램, 프로세스에 데이터를 넘겨줘야한다. 그런데 컴퓨터에 프로세스가 하나가 있는 게 아니다. 어느 프로세스로 갈 지 구분하기 위해 포트 번호를 둔다.

이렇게 어느 프로세스로 가야할지 포트 번호로 식별하여 해당 프로세스로 보내는 모듈인 것이다. 프로세스가 요청을 받고, 보내는 부분들을 담당한다.

거기에 데이터를 순차적, 안정적으로 보내는 부분을 담당한다.

5, 6, 7계층-응용 계층(Application Layer)

응용 프로그램에서 사용하기 편하게 맞춰 데이터에 규약을 추가하는 모듈. 소프트웨어적으로 Transport layer에서 제공하는 API에 맞춰 구현된다.

encoding 모듈 응용 프로그램에 맞는 네트워크 양식을 추가한다

decoding 모듈 응용 프로그램에 맞는 네트워크 양식에 맞춰 데이터를 읽어낸다

Transport layer에서 제공하는 API로 통신 가능한 프로그램을 만들 수가 있다. 이걸 TCP/IP 소켓 프로그래밍, 혹은 네트워크 프로그래밍이라고 한다. 그러니까 어플리케이션 레이어의 인코더 디코더를 만드는 걸 네트워크 프로그래밍이라고 한다. 어플리케이션은 누구나 만들 수 있다.

대표적인 응용 계층 프로토콜이 HTTP이다. 보내는 데이터에 메소드(GET, POST, PUT, DELETE)를 붙이고, 응답으로 보내는 데이터에 상태 코드(200, 400, 404, 500)등으로 감싸서 보낸다.

자주 쓰는 기존 프로토콜(HTTP)가 본인의 프로그램에서 수행하는 일과 잘 맞지 않거나, 성능을 너무 저하시킨다면, 이 계층은 프로그램에 맞춰 직접 구현해서 쓸 수 있다. 만들어 쓰는 사람 꽤 많다.

5계층-세션 계층(Session Layer)

데이터가 통신하기 위한 논리적 연결을 담당한다. TCP/IP 세션을 만들고 없애는 책임을 지닌다. API, Socket

6계층-표현 계층(Presentation Layer)

데이터 표현에 대한 독립성을 제공하고 암호화하는 역할을 담당한다. 파일 인코딩, 명령어를 포장, 압축, 암호화

7계층-응용 계층(Application Layer)

최종 목적지로, 응용 프로세스와 직접 관계하여 일반적인 응용 서비스를 수행한다.

사용자 인터페이스, 전자우편, 데이터베이스 관리 등의 서비스를 제공한다.

참고 자료

https://www.youtube.com/watch?v=1pfTxp25MA8 우아한테크코스 테코톡을 정리했습니다

개발하는 입장에선 요청과 응답 컨벤션이다. 다만 많은 프레임워크가 여기에 맞춰져서 짜여있어서 프레임워크 쓰다보면 여기저기 강제되는 부분들이 많다.

용어 구분이 곤란해서 간단한 개요를 말하고 들어가겠다. REST, REST API, RESTful API가 살짝 다르다.

REST

Representational State Transfer 소프트웨어 아키텍처. 복잡한 네트워크에서 통신을 관리하기 위한 지침이다.

REST API

그 규칙에 맞춰 구현한 API이다.

RESTful API

그 규칙에 맞게 잘 구현된 '웹' API를 특히 이렇게 불러준다. REST API와 RESTful API는 굳이 구분해서 생각할 필요는 없다.

REST

REST 설계 규칙

Uniform Interface 균일한 인터페이스

URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다. 어떤 걸 전송하든 표준 양식을 가지라는 것이다. 어떤 표준 양식이냐면

1. 요청이 자원(리소스)이 뭔지 표현할 수 있는 양식.

2. 클라이언트가 리소스를 자유롭게 사용할 수 있도록 서버가 충분한 정보를 제공하는 양식. 수정, 삭제를 위한 정보, 요청을 어떻게 보내하는지, 자원을 어떻게 쓰는 게 좋은지 정보를 제공한다. 메타데이터, 설명 메세지 등.

Statelessness 무상태

모든 요청이 독립적이다. 나는 순수 함수가 생각났다. 이전의 요청은 다음에 요청에 영향을 끼치지 않는다. 그걸 위해 상태 정보를 따로 저장하거나 관리하지 않는다. 구현이 쉬워지고 처리가 단순해진다.

계층화 시스템

서버가 다시 서버에게 요청을 보내고, 프록시 서버를 두거나 하는 등의 요청이 자유롭다. 그래서 여러 계층을 나눠서 여러 서버에서 실행되도록 나눌 수가 있다. 웹서버(정적 파일 서버), API 서버로 나눈다거나. 이 계층은 클라이언트 입장에선 보이지 않는다.

Cacheable 캐시

캐시 구현이 가능해야한다. 뭘 캐싱할지 표현할 수 있어야한다. RESTful 웹 서비스는 캐시 옵션으로 API 응답을 사용하여 캐싱을 제어한다.

온디맨드 코드

서버에서 클라이언트에 코드가 삽입되도록 보낼 수가 있다.

REST API

그렇다면 이런 규칙에 맞추기 위하여, 어떤 요청을 보내고 어떤 응답을 보내도록 양식을 짜야할까?(요청이 할 게 많아보임)

요청

클라이언트->서버 요청은 어떤 양식으로 어떤 정보를 보내야하는가?

고유 리소스 식별자

어떤 자원인지 말해주기

URL(Uniform Resource Locator)을 사용하여 리소스 식별을 수행한다. 리소스에 대한 경로를 지정하는 것이다. URL은 웹페이지를 방문하기 위해 브라우저에 입력하는 웹 사이트 주소와 유사하다. 요청 엔드포인트라고도 하며 클라이언트가 요구하는 사항을 서버에 명확하게 지정한다.

컨트롤러에 ~/user 같은 부분이 있고, 요청을 보낼 때 이를 명시하며, 이는 리소스를 식별할 수 있는 표현이여야 한다는 것이다.

메서드

이 자원으로 뭐하는지 말해주기 자원으로 뭘할 건지 말해줘야 한다.

HTTP 프로토콜에서는 리소스가 뭘 작업할지 구분하는 메서드를 제공한다.

GET-자원에 접근 POST-자원을 생성 PUT-자원을 업데이트 DELETE-자원을 제거

뭐... PATCH도 있고... 더 있다...

헤더

자원의 메타 데이터 응답의 형식을 나타내고 요청 상태 등에 대한 정보를 제공한다. 헤더의 content-type등이 데이터가 어떤 타입인지 제공하는데, 이런 친구들이다.

데이터

당연히 데이터가 갈텐데, 이 데이터는 메소드에 맞춰 잘 실행되도록 보내줘야한다.

파라미터 Parameters

패스로 표현되는 params(앤드 포인트랑 비슷하지 않나?) query 인증에 쓰는 cookie 등으로 서버에 정보를 제공한다.

응답

상태 표시줄

요청이 어떻게 처리 됐는지에 관한 번호 100번대-하는중 200번대-OK 400번대-클라이언트가 잘못 요청함 500번대-서버가 처리를 못함ㅠㅠ 등으로 요청이 어떻게 처리 됐는지를 표현하는 번호가 있다. 이걸 응답에 보내줘야한다.

메시지 본문

적절한 표현 형식을 선택 요청 헤더에 포함된 내용을 기반으로 적절한 표현 형식을 선택하여 보낸다. json이나 xml 형식 등을 사용한다.

헤더

자원의 메타 데이터 응답에 대한 추가 컨텍스트를 제공하고 서버, 인코딩, 날짜 및 콘텐츠 유형과 같은 정보를 포함한다.

참고 자료

https://aws.amazon.com/ko/what-is/restful-api/

크롬을 켜서, 브라우저 주소창에 google.com을 치자, 구글 페이지가 나타났다. https://velog.io/@old_dorim 라고 치자 내 블로그가 나타났다. 이 사이에 무슨 일이 일어났을까?

들어가기 전에 알아야할 것

DNS 서버

DNS 서버는 도메인 주소를 서버의 실제 IP 주소로 변환해주는 서버이다.

브라우저

브라우저(전체적인 처리, 탭 같은 부분), 네트워크(요청을 보내고 받음), 랜더링 프로세스(개별 창 안 내용물 처리, html, css, javascript)등으로 이루어져 있다. 프로세스 안에 여러 스레드가 있고, 그러나 여유 메모리에 따라 프로세스였다가 스레드였다가 하기도 한다.

과정

url 입력이 어디로 들어왔는가? 브라우저 주소창이다. 브라우저 프로그램의 브라우저 프로세스의 UI 스레드가 담당하는 부분에 입력이 들어온 것이다.

1. UI 스레드가 입력을 판별한다

• 검색어인가? 주소인가? 주소창에 주소를 치면 해당 주소의 데이터를 받아오겠지만, 글을 입력하면 바로 검색이 되기도 하니까. 이를 확인해서 검색어로 판별되면 검색 요청을 보내고, 아니면 해당 주소에 요청을 보낸다. 주소인지 판별이 안되면 DNS 서버를 한 번 보고 오기도 한다.

2. UI 스레드가 네트워크 쓰레드를 호출하여 요청을 보낸다

• 예전에 한 번 다녀온 주소인가? UI 스레드가 네트워크 호출한다. 캐싱된, 최근에 다녀와서 기록이 남아 있는 DNS 기록이 있는지 찾아본다. 브라우저 캐시->운영체제 캐시->라우터 캐시->ISP 캐시를 둘러본다. ISP의 캐시는 사실 ISP의 DNS 서버(ISP의 DNS 서버는 캐싱으로만 이루어지는 Recursive DNS Server이기 때문에)로, KT, SKT 같은 업체의 서버이다. ISP의 DNS 서버는 도메인의 IP를 찾아줄 책임이 있다. 본인에게 없으면, 다른 곳을 찾아봐준다.

• 실제 ip 주소가 뭔가? ISP의 DNS 서버가 root DNS에 요청을 보내고, TLS DNS 보내고... 정해진 규칙에 맞춰 찾을 때까지 이곳저곳 물어본다. 자세한 건 나는 스킵. 아래 참고할 글. 그렇게 실제 ip를 찾아온다. https://gentlysallim.com/dns%EB%9E%80-%EB%AD%90%EA%B3%A0-%EB%84%A4%EC%9E%84%EC%84%9C%EB%B2%84%EB%9E%80-%EB%AD%94%EC%A7%80-%EA%B0%9C%EB%85%90%EC%A0%95%EB%A6%AC/

• 그 주소 서버 연결해주실래요? TCP connection을 한다. TCP는 패킷이 유실됐는지 확인하고 유실 됐으면 다시 보내는 통신 방식이다(유실을 확인하지 않으면 UDP, 웬만하면 TCP 쓴다). three-way handshake 라는 프로세스를 통해 서로 서버가 켜져있는지 확인한 후 요청을 날린 쪽과 서버 간의 connection이 이뤄지게 된다. 그냥 서로 확인한 상태를 connection이 되었다고 하는 것 같다.

• 서버에 요청한다 http 프로토콜에 맞춰 데이터와 관련 정보 헤더(쿠키 같은 거)들을 보낸다. 서버 리디렉션 헤더를 받아서 요청을 다시 보내기도 한다.

3. 응답을 처리하여 창에 띄운다

• 컨텐츠(응답 데이터) 타입을 확인한다 네트워크 쓰레드가 Content-Type 헤더를 확인하고, 페이로드(응답) 스트림의 처음 몇 바이트를 확인하는 등의 작업으로 어떤 컨텐츠가 응답으로 왔는지 확인한다. 사실 아주 다양한 절차가 필요한 복잡한 작업이다. zip 파일이거나, 뭐 여러 다른 파일이라면 다운로드를 하도록 다운로드 매니저에 넘긴다. html 파일이라면, 랜더러 프로세스로 들어간다. 우리는 google.com을 쳤으니, html과 그 친구들이 왔을 것이다. 악성 데이터인지, 서로 다른 사이트의 민감한 데이터인지 확인하여 문제가 있다면 렌더러 프로세스로 넘기지 않도록 확인한다.

• 랜더러 프로세스에게 데이터를 넘긴다 네트워크 쓰레드가 UI 쓰레드에게 데이터가 준비되었음을 알리면, 브라우저가 랜더해줄 랜더러 프로세스를 찾는다. 빨리 수행하기 위해, 사실 이 단계는 요청이 들어간 순간 시작되고, 응답이 제대로 오지 않으면 그냥 버린다. 내비게이션을 실행해달라는 요청을 브라우저 프로세스에서 렌더러 프로세스로 IPC 메시지를 전송한다. 렌더러 프로세스에 브라우저 프로세스가 HTML 데이터를 전달한다.

• 화면을 랜더한다 HTML 파일과 CSS 파일(있다면)을 파싱해서 각각 Tree를 만든다. 중간에 script를 만나면 제어권이 JS 엔진으로 넘어가서 AST 트리를 구성한다. AST는 바이트코드로 변환되어 인터프리터가 실행한다. DOM Tree와 CSSOM Tree를 매칭시켜서 Render Tree를 구성. JS가 있다면 트리를 바꾸기도 할 것이다. Rendering Tree에서 각 노드의 위치와 크기를 계산한다. 계산된 값을 이용해 각 노드를 화면상의 실제 픽셀로 변환하고, 레이어를 만든다. 레이어를 합성하여 실제 화면에 나타낸다.

참고자료

https://velog.io/@uncyclocity/JavaScript-%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80%EC%9D%98-%EB%A0%8C%EB%8D%94%EB%A7%81-%EA%B3%BC%EC%A0%95

https://babycoder05.tistory.com/entry/wwwgooglecom-%EC%9D%84-%EC%A3%BC%EC%86%8C%EC%B0%BD%EC%97%90-%EC%B9%98%EB%A9%B4-%EC%9D%BC%EC%96%B4%EB%82%98%EB%8A%94-%EC%9D%BC-What-happens-when-type-wwwgooglecom

https://d2.naver.com/helloworld/9274593

https://tecoble.techcourse.co.kr/post/2021-10-24-browser-rendering/

https://gentlysallim.com/dns%EB%9E%80-%EB%AD%90%EA%B3%A0-%EB%84%A4%EC%9E%84%EC%84%9C%EB%B2%84%EB%9E%80-%EB%AD%94%EC%A7%80-%EA%B0%9C%EB%85%90%EC%A0%95%EB%A6%AC/

언어의 최고 로우 레벨에서 직접 표현되는 불변 데이터이다.

string

문자

number

숫자 Number 타입은 배정밀도 64비트 이진 형식 IEEE 754 값(-(2^53 − 1)부터 2^53 − 1까지의 수. 부동소수점 숫자, +Infinity, -Infinity, NaN.

참고로 Not a Number인 NaN의 타입도 number이다. NaN은 number type인데 숫자가 아닌데요... 라는 뜻이다.

bigint(최근 추가)

지원 안 되는 브라우저 많음. number보다 큰 정수 처리가 가능하며, Number와 혼합 연산이 안된다.

const bigint = 1234567890123456789012345678901234567890n;

const sameBigint = BigInt("1234567890123456789012345678901234567890");

둘 중 한 방식으로 사용 가능.

boolean

true/false 0과 1로 자동으로 변환되거나 변환 당하는 일이 많은 친구들.

undefined

값을 할당하지 않은 변수.

symbol(최근 추가)

'심볼(symbol)'은 유일한 식별자(unique identifier)를 만들고 싶을 때 사용. 문자형(string)과 함께 객체 프로퍼티 키로 쓸 수 있다. 유일한 값을 만들어준다.

const good=Symbol("what")
const bad=Symbol("what")
console.log(good==bad)//false

null

console.log(typeof null)//object

typeof null을 하면 object라고 나오지만, 사실 원시 타입 null이다. primitive 타입이다. typeof의 에러이다...

자바스크립트를 처음 구현할 때, 자바스크립트 값은 타입 태그와 값으로 표시되었고, 객체의 타입 태그는 0이었다. null은 Null pointer(대부분의 플랫폼에서 0x00)로 표시했고, null이 타입 태그로 0을 가지게 되었다고 mdn에 있는데 그걸 말이라고 하냐 지금.

ES6에 누가 바꾸자고 제안했는데 튕겼다. 고치기엔 이미 여기 맞춰 쓴 코드들이 너무 많아서 못 바꾸고 있다고.

객체

속성의 컬렉션. 객체는 hip 구역에 메모리를 할당받아 올라간다. 원시타입 아니면 다 객체이다.

두 가지 방식으로 선언 가능.

let user = new Object();
let user = {};

모든 객체는 prototype 속성을 가지며, 객체가 사용되기 위하여 생성되는 prototype을 참조해둔다. (JS는 프로토타입을 복사하여 객체를 생성하는 방식의 언어라서) 객체는 관련된 프로퍼티와 메소드의 집합으로, 키와 값을 가지는 값들로 구성된다.

const person = {
  name: ['Bob', 'Smith'],
  age: 32,
  gender: 'male',
  interests: ['music', 'skiing'],
  bio: function() {
    alert(this.name[0] + ' ' + this.name[1] + ' is ' + this.age + ' years old. He likes ' + this.interests[0] + ' and ' + this.interests[1] + '.');
  },
  greeting: function() {
    alert('Hi! I\'m ' + this.name[0] + '.');
  }
};

Array

index를 키로 가진다. {}가 아니라 []를 사용하여 선언한다. typeof에서 Array까지는 구분을 해준다.

Function

대표적인 객체라고 보긴 힘들지만 js에서 중요한 속성 중 하나이다. function은 객체이다. 다른 객체처럼 프로퍼티와 메소드를 가지며(생각해보면...), 호출 가능하다는 점만 추가된다.

1급 객체라고 불리는데,

1. 변수나 데이타에 할당 할 수 있으며
2. 객체의 인자로 넘길 수 있다
3. 객체의 리턴값으로 리턴 할 수 있다

+무명의 리터럴로 표현이 가능하다.

JS 쓰다보면 당연하게 쓰게 되는데, 다른 언어와 비교하면 특이하다. java에서는 불가능하고 kotlin에서는 가능하다.

JS의 호이스팅으로 인하여 함수 또한 호이스팅 되는데, 변수와 분리되어 호이스팅 된다. 근데 변수에 할당하면 호이스팅에서 제외된다.

참고 자료

https://developer.mozilla.org/ko/docs/Learn/JavaScript/Objects/Basics https://curryyou.tistory.com/183 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/null https://2ality.com/2013/10/typeof-null.html https://developer.mozilla.org/ko/docs/Web/JavaScript/Data_structures

동기/비동기, 블로킹/논블로킹은 해당 함수나 프로세스가 끝났는지 확인하기 위한 방법으로, 끝났는지 확인하는데 필요한 모든 곳에서 쓰일 수 있는 개념이다. 운영체제에서나...

사실 JS 공부를 위해서라면 동기/비동기 정도만 이해해도 된다.

동기vs비동기

동기

함수를 호출할 때 해당 함수가 끝났는지 호출한 쪽에서 즉 리턴을 했는지 신경 쓰는 것이 동기이다.

code1
function1()
code2

식으로 있을 때 차례대로 code1, function1(), code2 앞의 실행이 끝나야 끝날 것이다. 일반적이다.

비동기

함수를 호출할 때 해당 함수가 끝났는지 호출한 쪽에서 신경 쓰지 않는다. 대신 보통 콜백 함수를 넘겨서 호출된 함수가 끝나면 콜백 함수가 실행된다. 코드의 실행순서는 호출된 함수가 언제 끝나느냐에 따라 달라질 것이다.

블로킹vs논블로킹

블로킹

호출한 함수에게 제어권을 넘겨준다. 즉 호출한 쪽은 호출한 함수가 리턴값과 돌아올때까지 멈춘다.

논블로킹

그냥 호출하고 자기도 쭉 실행된다.

이렇게 보면 동기는 무조건 블로킹이고 비동기는 논블로킹 아니야? 라고 생각하게 된다. 물론 대부분 그 둘둘 조합이긴한데, 다른 쪽과의 조합도 가능하다.

조합

논블로킹일때는 동기/비동기 선택지가 있다.(그래도 논블로킹 비동기가 일반적이고 더 효율적으로 보인다.)

근데 블로킹 비동기를 보면 그냥 블로킹 동기랑 작동이 같다. 비동기는 보통 코드가 절차적으로 가지 않고 순서가 조정된다는 느낌으로 이해하게 되는데 블로킹 비동기는 그냥 차례대로 간다... 블로킹이면 차례대로 실행된다. 그걸 강제한다. 그러니까 블로킹 비동기는 작동 차이도 없고 쓸모도 없어보인다.

TS와 다른 객체지향언어

TypeScript-Handbook의 시작하기를 보면 사용하던 언어를 기준으로 Typescript가 어떻게 다를지 설명해준다. 그 중 TS for OOP Programming 부분을 보면, 기존 객체지향언어와 어떻게 다른지를 얘기한다.

TypeScript의 타입 시스템은 오류를 조기에 발견할 수 있게 하고 좀 더 명확히 지시한다는 점에서 JAVA, C++ 같은 정적 타이핑이 가지는 많은 이점을 제공한다.

그러나 TypeScript는 JavaScript와 동일한 런타임을 사용한다. 그러므로 특정한 런타임 동작(문자열을 숫자로 변환하기, 경고 표시, 디스크에 파일 쓰기 등)들이 TypeScript 프로그램에 똑같이 적용된다. TypeScript는 결국 JavaScript로 변환되며 JavaScript의 그 물렁물렁한 속성들을 많이 가지고 있으며, 타입이 집합으로 인식된다는 게 엄청 다르다. 문서에서 이 부분 위주로 빼오겠다.

집합으로서의 타입 (Types as Sets)

TypeScript에서 타입은 공통의 무언가를 공유하는 값의 집합으로 생각하는 것이 좋다.

C#에서는 ‘string’과 ‘int’ 둘 다 가능한 타입이 존재하지 않기 때문에 이 값을 인자로 전달하는 것은 이상하지만, TypeScript에서는 ‘string’ 집합 또는 ‘number’ 집합에 속할 수 있는 값을 전달할 수 있다. 그 값은 단순히 그 집합들의 유니언: ‘string | number’에 속한다. 띠용...

덕타이핑-삭제된 구조적 타입 (Erased Structural Types)

TypeScript에서, 객체는 정확히 단일 타입이 아니며, 인터페이스를 만족하는 객체를 생성할 때, 둘 사이의 선언적인 관계가 없더라도 해당 인터페이스가 예상되는 곳에 해당 객체를 사용할 수 있다고 나와있다.

Pointlike 타입을 인수로 받는 함수와, Named 타입을 인수로 받는 있는 함수가 있다. Pointlike는 x,y 프로퍼티를 가지고, Named는 name 프로퍼티를 가진다. 이때 obj는 x, y, name 프로퍼티를 가진 객체이다. obj가 Pointlike라고, Named라고 선언하는 구문도 없다. 이 경우 함수들이 obj를 인수로 받을 수 있는가? Typescript에서는 된다.

 interface Pointlike {
  x: number;
  y: number;
}
interface Named {
  name: string;
}

function printPoint(point: Pointlike) {
  console.log("x = " + point.x + ", y = " + point.y);
}

function printName(x: Named) {
  console.log("Hello, " + x.name);
}

const obj = {
  x: 0,
  y: 0,
  name: "Origin",
};

printPoint(obj);
printName(obj);

타입 간의 관계는 특정 관계로 선언되었는지가 아닌, 포함된 프로퍼티에 의해 결정된다. 게다가 이렇게 보니 obj는 Pointlike 타입이면서, Named 타입인걸로 보인다.

그래서

class Empty {}

function fn(arg: Empty) {

}

fn({ k: 10 });

이런 식의 호출이 된다. 공집합은 모든 집합의 부분집합이니까...

class Car {
  drive() {
    // hit the gas
  }
}
class Golfer {
  drive() {
    // hit the ball far
  }
}

// No error?
let w: Car = new Golfer();

이것도 에러가 나지 않는다... Golfer의 프로퍼티나 Car의 프로퍼티나 같기 때문이다. 영어에서 공을 세게 쳐서 drive라고 하든 가스를 채워서 drive라고 하든 철자는 같고 프로퍼티가 같으니까 둘을 같은 타입으로 보는 것이다.

이걸 덕타이핑이라고 한다. 오리처럼 굴면 대충 오리로 쳐주기 때문이다. 골프치는 사람이 자동차처럼 굴면 자동차로 쳐주기 때문이다.

문서에 반영 부분이 이해가 안되네. 제가 나약하기 때문이겠죠? 나중에 시간을 들여 읽어보겠습니다.

참고자료

https://typescript-kr.github.io/pages/tutorials/ts-for-oopers.html

https://mygumi.tistory.com/367

https://stackoverflow.com/questions/31810881/typescript-overloading-class-methods-same-return-type-different-parameters

둘 다 라이언 달이 만들었다. 아버지가 같음. deno는 node를 뒤집어서 이름을 지었다. node.js를 만든 라이언 달이 node.js의 단점을 보완해서 만들었다고 한다. 언급된 것 중 꽤 많은 단점을 node.js가 보완한 상태인데가 node.js가 이미 점유율이 너무 높아서 많이 쓰지는 않는다. 장점 중에 top-level await가 된다 이런 거 있던데 node도 이젠 되니까... https://kdydesign.github.io/2022/02/17/deno-tutorial/ 이 글을 엄청... 참고해서... 그냥 다시 정리해서 썼다.

차이점

기반 언어

node는 c/c++, javascript로 만들어졌다. deno는 rust, typescript, javascript로 만들어졌다. deno는 typescript를 사용하기 위한 별도의 모듈이 필요없고, 자체적으로 typescript를 쓸 수 있도록 다 내장 되어 있다.

의존성 관리

node.js는 package.json, node_modules를 사용하여 패키지를 관리한다. Deno는 패키지 관리 시스템이 없고, URL로 처리된다. 이 URL의 경로가 버전정보를 포함하여 따로 명세(package.json같은)가 필요없다.

node.js는 npm으로 패키지를 설치한 다음 require/import를 써서 가져오게 될 것이다.

deno는 이렇다.

import {format} from 'https://deno.land/std@0.126.0/datetime/mod.ts'

모듈 가져오기

위에서 보면 알 수 있겠지만,

node.js는 ES방식(import)와 common.js(require)을 둘 다 지원한다. Deno는 ES방식(import)을 사용한다. 최신 브라우저와 더 잘 호환되기 위해서라고 한다.

예전에 node가 common.js 방식만 사용했을테니, 그게 단점이었는데 이제는 둘 다 사용이 가능하다. 둘 다 사용 가능한 것도 단점일지 장점일지는 모르겠지만.

프로미스

당연히 node.js도 프로미스 있다. 그러나 Deno는 설계부터 Promise 방식을 전제하여 만들어졌다. 모든 비동기 작업은 Promise를 반환한다. 둘 다 callback매커니즘이다.

보안

가장 이슈가 된 점이다. Deno는 실행 환경이 되는 샌드박스 안에서 코드를 실행하는 방식으로 코드를 분리하고, 권한별 접근을 허용한다. 특별히 특정 기능을 활성화하지 않는 한은 Deno로 실행되는 프로그램은 파일, 네트워크 또는 환경에 액세스할 수 없다. node.js는 node_modules이 local에서 돌아가고, 유저가 로컬 내 정보에 접근할 수 있기 보안이 취약한 면이 있었다.

deno에서는

deno run [PERMISSION FLAG] URL

식으로 접근 권한을 설정한 채 실행할 수 있다. permission flag에 -allow-env 붙이면 환경 변수 접근 권한 허용한 채로 돌아간다. –allow-all를 붙이면 모든 접근 권한 허용한 채 돌아간다.

https://deno.land/manual@v1.18.2/getting_started/permissions

참고자료

https://kdydesign.github.io/2022/02/17/deno-tutorial/

https://www.stefanjudis.com/today-i-learned/top-level-await-is-available-in-node-js-modules/

node.js는 이런 구조로 이루어져있다. 인터넷에 조금씩 다르게 나와있던데 대충 말하는 건 같아보인다. 명백한 사실관계가 궁금하면 해당 깃허브에 들어가면 node.js 프로젝트를 확인할 수 있다. src 디렉토리를 확인하면 된다. https://github.com/nodejs/node

v8

여기서 v8이 Javascript를 돌리는 메인 엔진이다. 크롬도 이걸 쓴다. Javascript엔진은 브라우저의 랜더링 프로세스에서 한 자리 빌려준 싱글스레드이기 때문에, 병렬로 처리되는 것처럼 보이는 비동기처리가 불가능하다. 혼자서는. 그래서 따로 비동기처리를 담당하는 libuv 엔진과 같이 돌아간다.

libuv

비동기처리를 담당하는 라이브러리다. 네트워크, 파일 I/O등의 비동기 처리를 지원해준다. 구 버전에서는 libeio, libev였는데 libuv 바뀌었다. 이벤트루프와 시스템 커널 API를 제공하여 비동기처리를 돕는다.

참고자료

https://blog.naver.com/pjt3591oo/221976414901 위 블로그가 정말 잘 나와있어서 다음에 다시 읽고 공부해봐야겠다 https://yjhjstz.gitbooks.io/deep-into-node/content/chapter1/chapter1-0.html

특정한 규칙을 가진 문자열의 집합을 표현하는 형식이다. 비밀번호를 만들 때 몇 개의 숫자, 몇 개의 영어 대소문자, 특수문자를 포함해야한다 이런 내용을 적는 것을 경험해보았을 것이다. 문자열에서 특정 문자 패턴을 검색(검사) 하는 것이다.

/pattern/[Flag]

식으로 작성한다. 안이 문자의 패턴, 밖에 flag 부분이 어떻게 검색되는 것인지 알 수 있다.

Flags

flag는 설정하지 않으면 해당 문자열을 한번 찾는다 g- global, 해당 문자열을 전부 찾는다 i- ignore case, 대소문자 전부 구분 m- multi line, 문자열 행이 바뀌어도 찾는다

/pattern/g

위에 3개말고도 많은데 mdn 웹 독스에 많이 나와있다.

Patterns

간단하게 적고 예시 하나씩만 들겠다

Groups and ranges

범위 내에서 검색

|, (), [], [^], (?:) [1-3],[a-g]식으로 범위 안에 속한 것을 검색한다, 1,2,3 검색, abcdefg 검색하게 된다.

Quantifiers

수량자, 검색 수량 정하기

?, *, +, {n}, {min,}, {min,max}

{3}하면 3개 찾는다.

Boundary-type

문자 위치를 제한한다

\b, \B, ^, $ \b string의 중간이나 맨 끝만 검색한다(문자열이 아닌 것과 붙은 문자열만 검색)

Character classes

글자 타입을 제한한다

, ., \d, \D, \w, \W, \s, \S \ 특수문자가 아닌 문자

reDOS

대부분의 언어에서 기본으로 제공하는 Regexp 엔진은 Backtracking(하다가 막히면 돌아감)으로 정규표현식 처리 시 가능한 모든 경로를 탐색하는데, 이로 인해 비효율적인 작업을 여러번 시도하게 된다. 이는 서버나 처리에 큰 무리를 줄 수가 있다. 어떤 경우에는 aaaaX일 때는 16번의 검색, aaaaaaaaaaaaaaaaX가 들어오면 65536번의 검색이 필요해진다. 이 regex 처리를 이용하여 DOS 공격을 할 수도 있다.(당할 수도 있다...) stackoverflow가 이것 때문에 털린 적이 있다.

이를 막기 위해서는

1. 아예 다른 처리 방식의 외부 Regex 엔진을 쓴다.
2. Regexp 패턴을 체크해보고 반복적인 작업이 발생할 수 있는지 테스트하고 보완한다.
3. ReScue, SafeRegex 같은 ReDOS 탐지 도구를 통해서 ReDOS의 가능성을 체크해볼 수 있다.

참고 자료

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions#writing_a_regular_expression_pattern https://www.youtube.com/watch?v=t3M6toIflyQ&t=162s https://www.nextree.co.kr/p4327/ https://www.hahwul.com/cullinan/redos/

린트(lint) 또는 린터(linter)는 소스 코드를 분석하여 프로그램 오류, 버그, 스타일 오류, 의심스러운 구조체에 표시(flag)를 달아놓기 위한 도구들을 가리킨다. 이 용어는 C 언어 소스 코드를 검사하는 유닉스 유틸리티에서 기원한다. ESLint는 EcmaScript용 Lint이다.

vscode 보면 코드 치다가 중간에 코드 이상하다고 잡아주는 친구들이다.

vscode extension으로 ESLint를 쓰는 경우 .eslintrc 파일로 설정할 수 있다. 다른 환경에서도 대부분 이런 설정 파일이 있다.

제약이 많기 때문에 굳이 쓰지 않고 그냥 vscode 설정을 올리는 게 낫다는 사람들도 있다. 걸리는 설정들을 끄면서 작업하다보면 죄책감이 든다...

Prettier

이름 그대로 조금 더 예쁘게, 보기 좋게 해주는 것이다. 띄어쓰기, 간격, 코드 색깔.... 양식 같은 것을 바꿔준다. vscode에서는 vscode 설정의 전반을 담당하는 setting.json에서 설정해준다.

Lint와 Prettier 이 둘이 충돌하는 경우가 있다. 이 경우 추가 플러그인을 통해 해결할 수가 있다.

참고 자료

https://ko.wikipedia.org/wiki/%EB%A6%B0%ED%8A%B8_(%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4)

https://velog.io/@treejy/React-ESLint%EC%99%80-Prettier%EA%B0%80-%EB%AC%B4%EC%97%87%EC%9D%B4%EB%A9%B0-%EC%99%9C-%ED%95%84%EC%9A%94%ED%95%98%EA%B3%A0-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%82%AC%EC%9A%A9%ED%95%98%EB%8A%94%EC%A7%80#:~:text=Prettier%EB%8A%94%20%EC%9D%BC%EA%B4%80%EC%A0%81%EC%9D%B8%20%EC%BD%94%EB%93%9C,%EA%B0%99%EC%9D%80%20%EC%8A%A4%ED%83%80%EC%9D%BC%EC%9D%84%20%EA%B5%90%EC%A0%95%ED%95%B4%EC%A4%80%EB%8B%A4.

JS 진입장벽이 낮고 비전공자들이 처음 입문하는 경우가 많은 언어이다. 그렇지만 깊게 파면 어려운데다 다른 언어에 비해 덕지덕지 뭘 붙인 것 같은 느낌을 준다. 버전별 차이도 심하다. 그런데 이 덕지덕지도 다들 이유를 가지고 있고, JS의 역사를 이해하면 좀 받아들일 수 있을 것이다.

아래에 역사를 이해하기 위한 기반 지식을 써놨다. 나도 정리를 좀 하고 싶어져서. 근데 스크립트 언어가 뭔지, 네트워크가 뭔지 안다면 스킵해도 된다.

글이 드림코딩 자바스크립트 배우기전 꼭 봐야할 영상 | 자바스크립트의 역사와 현재 그리고 미래 (JavaScript, ECMAScript, JQuery, Babel, Node.js)(https://www.youtube.com/watch?v=wcsVjmHrUQg)를 많이 참고했다.

JS 공식 로고도 없네... 어쩔 수 없이 화난 햄스터를 드리겠습니다.

스크립트 언어

JS는 처음에 스크립트 언어였다. 내용에서 계속 **스크립트 언어**라는 말이 나오는데, 미리 설명하고 들어가겠다.

스크립트 언어란 **기존에 존재하는 어떤 다른 프로그램들을 제어**하기 위해 만들어진 것이다. 약간 애매하긴 한데, 하여튼 다른 컴파일러로 번역되는 언어와는 좀 다르다. 응용 소프트웨어에서 스크립트 언어에 맞는 API를 제공, 응용 소프트웨어와 상호작용하면서 돌아가게 되고, 주로 인터프리터 방식이다. 이 개념을 적용하면 python도 스크립트 언어이다. 예를 들어 Adobe photoshop같은 프로그램에 파일 메뉴를 보면 자동화나 스크립트라는 메뉴가 있을 것이다(사람들이 잘 사용 안했는지 포토샵 버전마다 좀 차이가 있다). 여기서 Adobe용 Script파일을 넣어서 포토샵이 자동으로 돌아가게 제어할 수 있다. 완전 Script이다.

처음에 **Javascript**는 브라우저 환경에서 돌아가며 웹페이지를 제어하기 위해 만든 언어였다. 이름도 JavaScript. 지금은 Node.js(JS 서버 구축해서 돌릴 수 있게 해주는 런타임 환경)가 등장하고, 다양하게 보완되고 고도화되면서, 단순히 스크립트 언어라고 부르기 힘들어졌다.

그렇지만 JavaScript가 C나 C++같은 언어와 같은 등위라고 생각하면, 굉장한 오해가 생긴다.

네트워크

네트워크란 컴퓨터들이 통신망을 통해 서로 그물처럼 연결된 체계이다. 나는 이론적인 거 하나도 모르고 냅다 클론코딩해서 웹 개발한게 시작이었기 때문에, 이 개념도 나중에야 이해했다. 그것 때문에 좀 고생했으므로, 혹시 초보 웹개발자 누가 글을 읽는다면 미리 알길 바란다.

계산기에 메모리 장치가 달린 컴퓨터가 있고, 남의 컴퓨터와 내 컴퓨터를 연결해서 데이터, 전기신호를 주고 받을 수가 있다. 그래서 나는 모르는 멋진 기술들을 이용해서 컴퓨터들을 모두 연결할 수 있게 한 것이다. 그물처럼. 해저 케이블로 나라마다 연결하고, 나라에서 KT, SKT 같은 회사들에 위탁하여 이런 기반 시설을 만들게 하고, 랜선을 내 컴퓨터에 연결하고 공유기를 연결해서.

내가 네이버에 들어가면, 네이버의 서버컴퓨터와 내 컴퓨터가 연결되어 정보를 주고 받고 연결이 끊긴다. 당신이 들어가는 모든 사이트는 다 다른 남의 컴퓨터들에서 받아온 정보이다. (서버 컴퓨터도 그냥 성능이 좋은 컴퓨터이고 내 컴퓨터랑 근본적으로 다르진 않다. 그냥 용도를 얘기하는 거다. 내 컴퓨터에서 서버 돌리면 그게 서버 컴퓨터.)

**내 컴퓨터와 다른 컴퓨터가 데이터를 주고 받기 위한 프로토콜(규칙)이 있고, 규칙에 맞춰서 정보를 주고 받고, 브라우저가 데이터를 가공해서 보여주는 멋진 과정**들이 있다. 정보를 받고 보내고 DB에 저장하는 것이 백엔드, 브라우저에서 어떻게 가공하고 보이게 할지 처리하는 것이 프론트엔드이다. 그러니까 이 길고 긴 과정에서 오직 브라우저를 위한, 처음에는 굉장히 한정되게 만들어진 것이 JavaScript인 것이다.

JS의 역사

동적인 웹을 위한 언어

웹 브라우저를 제어하는 스크립트 언어

더글라스 엥겔바트가 개발한 NLS은 인터넷의 탄생에 기초가 됐고, 팀 버너스 리는 인터넷과 하이퍼텍스트를 결합해 월드 와이드 웹이라는 새로운 정보검색 방식을 개발해냈다. 팀 버너스 리라는 이름 웹 관련 수업 들을 때마다 5초씩 나와서 어딘가 익숙하다...

1993년 미국 일리노이 대학교 NCSA 연구소의 대학생이었던 마크 앤드리슨과 에릭 비나가 넷스케이프라는 회사를 세우고 MOZAIC 웹 브라우저라는 것을 만든다. 기존에 웹 브라우저가 없었던 건 아닌데, 텍스트 위주였던 것을 이미지를 표시할 수 있게 한 것이다.

여기서 개발 책임자 마크 앤드리슨이 동료들을 데리고 나와서(그래서 MOZAIC는 개발이 중지된다.) 좀 더 발전된 Netscape Navigator를 만든다. 당시에는 html, css로 정적인 웹페이지만 가능했는데, 넷스케이크 버전 2에 **동적인 웹페이지가 구현 가능하도록 스크립팅 언어를 넣어서 출시**한다. 그렇다. JavaScript이다.

Scheme Script를 기반으로 LiveScript(10일만에 만들라고 했다고 한다...)라는 것을 만들었고, 당시 Java가 굉장히 잘 나갔기 때문에, 이름을 슬쩍 JavaScript로 바꾼다. 내부적으로는 Mocha라고 불렸다. Mocha가 더 귀엽다.

너무 많은 버전과 표준안

브라우저 호환성 문제와 ECMAScript

그런데 이 웹 브라우저가 굉장히 잘나가기 시작했다. 이를 본 마이크로소프트사에서 1995년 Internet Explorer, 내가 초등학생 때 잘나갔지만 지금은 지원 종료된 웹 브라우저를 만들어 출시한다. 기존 MOZAIC 웹 브라우저를 인수한 스파이글래스라는 회사에 저작권료를 지급하여 MOZAIC의 소스코드를 활용하고, 리버스 엔지니어링(만들어진 프로그램 바이너리 코드 분석해서 소스 코드 복원하는... 배껴버리는 거)해서 JScript라고 이름 붙인 Script 언어까지 만들어서.

이것이 지금도 웹개발자들을 괴롭게 하는, 브라우저 호환성 문제의 시작이었다. 그러니까 웹 사이트들이 Internet Explorer에 맞지만 Netscape Navigator에 안 맞거나, Netscape Navigator에 맞지만 Internet Explorer에 안 맞는 문제들 말이다. 결국 Netscape사는 ECMA Interational사를 찾아가서 표준안을 만들어달라고 부탁한다. 그래서 **ECMAScript라는 브라우저용 Script 표준**을 제공한다. 문법과 convention, error handling 관련한 내용들이다.

ECMAScript는 다양한 제안을 받고 적용하면서 class가 추가되는 등 좀 높은 기준을 요구하게 되었는데, 마이크로소프트사는 스크립트 언어에 그런 복잡한 기능이 추가되는 것이 사용 목적에 적합하지 않다고 생각했다. 마이크로소프트 사의 IE가 ECMA 표준을 따르지 않게 되었다. 당시 Netscape Navigator를 밀어내고 95%의 점유율을 차지한 IE가 지키지 않는 표준안은 거의 무용해보여서, 새로 만들려는 움직임이 약간 시들해진다. 이런 상황에서 Netscape사에서 파생된(Netscape가 IE에 밀려서 인수당하고 Netscape의 개발자들이 떨어져 나와서 만든) Mozilla사의 FireFox가 나온다. Mozilla는 ECMA사에 Tamarin이라는 새로운 엔진과 ActionScript3라는 새로운 스크립트 언어를 제안하게 된다. 그러나 ActionScript는 다른 스크립트들과도 너무 달랐고, 3사가 표준 관련하여 공방을 벌인다.

많은 브라우저와 신기술의 등장

이렇게 표준이 세워지지 않을 동안, 더 많은 브라우저들이 등장했고, 웹개발 시장은 점점 커지고 많은 개발자들이 들어왔다. 그러면서 개발자들 사이의 커뮤니티가 등장하고, 더 많은 웹을 위한 신기술이 등장했다. 대표적인 것은 비동기처리가 가능하게 하는 AJAX. 그 중 Jquery, dojo, mootools 등은 이 들이 제공하는 api를 따르면 어떤 브라우저에서 돌아가는지 신경쓰지 않을 수 있었다. 확실한 표준안이 없는 채로 신기술들, JavaScript와 유사한 Script 언어를 돌리는 다양한 엔진들이 나타나면서, JS는 너무 다양한 버전과 문법을 가지게 되고 말았다...

그런데 그 때 크롬이 나타났다

그런데, 지금도 내가 글을 쓰고 있는 velog에 접속시켜준 크롬 브라우저가 2008년에 등장한다. google사에서 만든 이 크롬은 **JIT라는 강력한 엔진을 포함하여 JavaScript의 실행 속도를 획기적으로 높혔다.** 현재도 점유율의 절반 정도를 먹고 있다. JavaScript convention도 구글에서 제공하는게 제일 잘 나간다. 나머지 브라우저 회사들은 큰 자극을 받고, 드디어 모여서 표준안을 새로 낸다. 모든 회사들이 이 표준안을 따르면서 JavaScript는 드디어 확정이 난다. **엔진은 다 다르지만, 모두 ECMAScript 표준안을 따른다.** 그러면서 Jquery, dojo, mootools 등은 필요 없어져 버렸고.

+그리고 JavaScript를 다른 환경에서도 돌리려는 시도들도 일어났다. Chrome에서 사용하는 V8엔진을 node.js와 electron에서도 사용한다.

ES5, ES6

그렇게 모두가 따르기 시작해서 드디어 ECMAScript5는 표준안다운 표준안이 된다. ECMAScript를 줄여서 주로 ES5, ES6처럼 부른다. ES5, ES6 정도가 이전 버전과 큰 차이를 지니며 그 뒤는 큰 차이가 없다.

ESNEXT

그래서 개발자들은 이제 ECMA사에서 내놓을 새로운 표준에 큰 관심을 가지게 되었고, 제일 최신 버전의 표준안을 ESNEXT라고 부른다.

즉 어딘가 ESNEXT라는 코드로 쓰여있으면, 여태 나온 모든 표준안에서 허용되는 모든 것들을 다 허용해서 작성한다는 것이다.

여전히 여러 버전이 혼용된다

Babel

근데 옛날 브라우저를 사용하고 있는 공기관은? 최신버전으로 업데이트하지 않는 사람들한테는? 그냥 우리 페이지 들어오지 말라고 할까? 그럴 수도 있겠지만, 아량을 베풀어서 우리 페이지를 잘 쓸 수 있게 하자. 프론트엔드라면 들어봤을 Babel은 배포할 때 ES 최신 표준에 맞춰 쓴 코드를 다른 JS 버전을 요구하는 엔진에서도 돌아갈 수 있게 코드를 컴파일해준다.

common.js

common.js는 Mozilla사의 엔지니어였던 Kevin Dangoor가 2009년에 당시에 JavaScript가 웹 브라우저 밖에서 돌아갈때 모듈화를 어떻게 할건지에 대한 내용이 없어서 만든 것이다. 그래서 주로 모듈 import export 형식 관련된 내용이다. 문제는 ES에서도 이것과 겹치는 내용을 제공한다. node.js나 TypeScript는 common.js의 모듈 사용 문법과 ES5,6의 모듈 사용 문법을 모두 지원한다. TypeScript의 tsconfig 파일에는 컴파일을 어떻게 할지 쓰는 옵션도 있다.

 {
    "compilerOptions": {
        "target": "es5",
        "module": "commonjs",
    }
}

글을 읽었다면, 이제 이게 뭘 의미하는지 알 것이다.

JavaScript는 뭐랄까... 웹이 너무 잘 나가버려서 단순 스크립트 언어라고 부르기 어려워진... 많은 파생버전과 엄청난 보완을 거친... 어떤 문법 흐름인 것이다... 다른 언어 역사는 공부한 적이 없어서 걔네도 이런지 모르겠지만요...

참고자료

JS 역사 전체 흐름 https://www.youtube.com/watch?v=wcsVjmHrUQg

JS 역사 일부 참고 https://it.donga.com/20721/

모자이크 웹 브라우저 관련 https://ko.wikipedia.org/wiki/%EB%AA%A8%EC%9E%90%EC%9D%B4%ED%81%AC_(%EC%9B%B9_%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80)

웹브라우저의 역사 참고 https://www.heecheolman.dev/post/%EC%9B%B9-%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80%EC%9D%98-%EC%97%AD%EC%82%AC/

ESnext가 뭔지 https://stackoverflow.com/questions/56521178/what-is-esnext

common.js가 왜 만들어졌는지 관련 https://medium.com/@lisa.berteau.smith/commonjs-and-the-history-of-javascript-modularity-63d8518f103e#:~:text=CommonJS%20was%20started%20by%20Mozilla,is%20executed%20in%20its%20namespace.

넷스케이프 네비게이터 관련 https://ko.wikipedia.org/wiki/%EB%84%B7%EC%8A%A4%EC%BC%80%EC%9D%B4%ED%94%84_%EB%82%B4%EB%B9%84%EA%B2%8C%EC%9D%B4%ED%84%B0#:~:text=%EB%84%B7%EC%8A%A4%EC%BC%80%EC%9D%B4%ED%94%84%20%EB%82%B4%EB%B9%84%EA%B2%8C%EC%9D%B4%ED%84%B0(Netscape%20Navigator%2C%20%EB%98%90%EB%8A%94,Jim%20Clark)%EC%9D%B4%20%ED%88%AC%EC%9E%90%ED%96%88%EB%8B%A4.

https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms

Idioms라는 용어가 생소하다. 한국어로 하면 관용구인데, 개발 용어로는 그냥 관용구라고 생각하면 안될 것 같아서 서문을 살짝 읽어봤다.

Idiom라는 것은 C++를 사용하여 프로그래밍하거나 설계할 때 자주 사용하게 되는, 재사용 가능한 패턴이나 팁이다. 특정 상황에서 쓰이는, 특정 상황에 대처하기 위한 일반적인 관행이라는 뜻이다.

이 목록은 이런 관용구들을 모아둔 리스트이다. 이 관용구들을 이해함으로써 다른 사람의 코드가 왜 그렇게 짜였는지 읽기 쉬워지고, 언어가 어떤 특성을 가져서 어떻게 짜면 좋은지 등등을 이해할 수가 있다.

이 목록들은 각각 Idiom의 Intent, Also Known As(Alias), Motivation, Solution and Sample Code, Known Uses, Related Idioms, References를 설명한다. 양식이 그렇게 되어있다. 나도 맞춰서 정리하겠다.

동아리 세미나 과제인데, 빨갛게 안 만들어진 페이지빼고 공부한다.

4. Attach by Initialization(Static-object-with-constructor)

Intent 목적

프로그램 실행 이전에 프레임 워크에 유저가 정의한 객체를 붙인다. 동기를 읽는게 더 이해가 된다.

Motivation 동기

GUI(ex.Microsoft MFC)나 object request brokers같은 특정 프레임 워크는 자기만의 이벤트 루프를 가지고 전체 어플리케이션을 컨트롤한다.

이런 경우 어플리케이션 프로그래머는 메인 함수를 쓰지 못할 수 있다. MFC의 메인 함수인 AfxWinMain처럼 메인 함수 자체가 깊게 숨겨져 있는 경우도 있다. 이렇게 메인함수에 접근 못하는 경우 이벤트 루프가 시작되기 전에 초기화 코드를 쓸 수가 없게 된다. The attach-by-initialization idiom으로 프레임워크를 컨트롤하는 루프가 시작되기 전에 특정 코드를 실행할 수 있게 한다.

Solution and Sample Code 솔루션과 예제코드

C++에서, 전역 namespace에 있는 전역 오브젝트와 정적 오브젝트는 main이 시작되기 전에 초기화 된다. static storage duration(메모리에 데이터를 저장하고 있는 시간. static의 경우 프로그램이 실행되는 동안 계속 메모리에 저장되어 있다)라는 특성을 가지는 오브젝트들이다. 이런 오브젝트들을 써서 시스템 프로그래머가 메인 함수에 접근할 수 없을 때 시스템에 메인 함수 이전에 실행 되는 객체를 붙일 수가 있다. 아래가 Microsoft Foundation Classes(MFC)에서의 예시이다.

///// File = Hello.h
class HelloApp: public CWinApp
{
public:
  virtual BOOL InitInstance ();
};
///// File = Hello.cpp

#include <afxwin.h>
#include "Hello.h"
HelloApp myApp; // Global "application" object
BOOL HelloApp::InitInstance ()
{
 m_pMainWnd = new CFrameWnd();
 m_pMainWnd->Create(0,"Hello, World!!");
 m_pMainWnd->ShowWindow(SW_SHOW);
 return TRUE;
}

이건 그냥 "Hello, World!" 윈도우를 띄우는 코드이다. 중요한 것은 HelleApp 타입의 myApp 객체가 전역 객체라는 것이다. myApp objects는 메인 함수가 실행되기 전에 기본적으로 초기화되게 된다. 그러면서 CWinApp의 생성자가 호출된다. CWinApp class는 framework의 일부로 여러 다른 클래스의 생성자를 불러낸다. 이 생성자들이 실행되는 동안 전역 객체가 프레임 워크에 붙여지고, 나중에 AfxWinMain(MFC의 메인)에 의해 회수된다.

HelloApp::InitInstance member function은 그냥 확인을 위해 있는 부분으로, 이 함수는 AfxWinMain의 실행이 시작된 이후에 호출된다.

본생성자, 파리미터를 가진 생성자, 어떤 함수의 리턴값으로 할당, 동적 초기화 등의 방식으로 전역, 정적 오브젝트을 초기화 할 수 있다.

Caveat 경고

C++에서, 같은 네임스페이스에 있는 객체들은 순서대로 컴파일이 된다. 그러나 static storage duration 객체가 어떤 순서로 컴파일되느냐는 표준화되어있지 않다. 소멸의 순서도 초기화의 순서의 정반대인데, 이게 표준화되어있지 않다는 것이다.

네임스페이스의 객체들은 어떤 함수나 변수가 객체에 접근하기 전에 생성되어야하는데(당연하지...), 이 시점이 메인 전인지 후인지 알 수가 없다. 그래서 static object의 생성자가 다른 static object가 초기화 되기 전에 사용하려고 하는 문제가 발생할 수 있다.

이 idiom은 이런 tatic storage duration의 객체들을 사용하기 때문에 이런 문제에 쉽게 빠질 수 있다.

Known Uses

Microsoft Foundation Classes (MFC)

Related Idioms

없음

References

Proposed C++ language extension to improve portability of the Attach by Initialization idiom https://www.open-std.org/jtc1/sc22/wg21/docs/papers/1995/N0717.htm

https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms

Idioms라는 용어가 생소하다. 한국어로 하면 관용구인데, 개발 용어로는 그냥 관용구라고 생각하면 안될 것 같아서 서문을 살짝 읽어봤다.

Idiom라는 것은 C++를 사용하여 프로그래밍하거나 설계할 때 자주 사용하게 되는, 재사용 가능한 패턴이나 팁이다. 특정 상황에서 쓰이는, 특정 상황에 대처하기 위한 일반적인 관행이라는 뜻이다.

이 목록은 이런 관용구들을 모아둔 리스트이다. 이 관용구들을 이해함으로써 다른 사람의 코드가 왜 그렇게 짜였는지 읽기 쉬워지고, 언어가 어떤 특성을 가져서 어떻게 짜면 좋은지 등등을 이해할 수가 있다.

이 목록들은 각각 Idiom의 Intent, Also Known As(Alias), Motivation, Solution and Sample Code, Known Uses, Related Idioms, References를 설명한다. 양식이 그렇게 되어있다. 나도 맞춰서 정리하겠다.

동아리 세미나 과제인데, 빨갛게 안 만들어진 페이지빼고 공부한다.

43. Int-To-Type(Integral constant wrappers)

Intent 목적

정수형 상수를 컴파일 타임에 타입으로 취급되게 한다. 정수형 상수 값에 따라 static call dispatch를 구현한다.

dispatch

디스패치란 프로그램이 어떤 메소드를 호출할 것인가를 결정하고 실행하는 것이다. 특히 많은 객체 지향 언어들이 메소드와 프로퍼티들을 오버라이드 할 수 있도록 허용한다. 그러면 받는 인자에 따라 어떤 메소드가 호출될지 여부가 결정이 된다.

Static Dispatch:변수의 명목상 타입에 맞춰서 메소드와 프로퍼티를 참조한다. 이 경우 참조될 요소를 컴파일 타임에 결정된다. Dynamic Dispatch:변수의 실제 타입의 맞춰서 메소드와 프로퍼티를 호출한다. 코드상으로는 이것이 드러나지 않기 때문에 실제 참조될 요소는 런타임에 결정된다.

참고: https://jcsoohwancho.github.io/2019-10-11-Dynamic-Dispatch%EC%99%80-%EC%84%B1%EB%8A%A5-%EC%B5%9C%EC%A0%81%ED%99%94/

Motivation 동기

C++의 함수 오버로딩은 타입에 의존하기 때문에 정수형 상수가 컴파일 타임에 오버로드 함수가 결정되는 것을 방해한다. 이것을 해결하는 첫번째 방법은 enable-if idiom, 그리고 다른 것이 우리가 설명할 int-to-type idiom이다.

Solution and Sample Code 솔루션과 예제코드

Andrei Alexandrescu가 쓴 Dr. Dobb's Journal에 따르면 해답으로 간단하게 이런 코드를 제공한다.

template <int I>
struct Int2Type
{
  enum { value = I };
};

위의 양식으로 다른 정수는 다른 타입을 가지게 된다. 예를 들어, Int2Type<5>은 Int2Type<10>과 다른 타입이 된다. 또한 정수 파라미터가 관련된 상수 값에 저장이 된다. 이렇게 모든 정수형 상수 결과가 다른 타입이되고, 이 간단한 탬플릿으로 아래 예시처럼 정수형 상수를 통해 static dispatching을 할 수가 있다.

표준 배열 클래스인 TR1과 유사하게, 배열의 고정된 사이즈를 캡슐화하는 배열 클래스가 있다고 가정하자. 사실은 우리의 배열 클래스는 TR1 표준 배열 클래스를 상속하여 구현했으며, 다른 것은 오직 정렬 기능이다.

우리의 정렬 기능은 array의 size를 사용하여 성능을 최적화하고 complie time에 dispatch 작동되도록 의도했다. size를 써서 성능을 최적화한다는 게, 사이즈가 0이면 작동을 막고, 50보다 크기가 작으면 삽입정렬, 더 크면 퀵소트를 쓰게 되어있다. 근데 이러면 어떤 정렬 알고리즘을 쓸지 결정하는게 런타임에 결정될 수 밖에 없다.

이런 경우에 int-to-type idiom을 써서 complie time에 결정되도록 하겠다는 것이다. 아래가 그 예시이다.

#include <iostream>
#include <array>

template <int I>
struct Int2Type
{
  enum { value = I };
};

template <class T, unsigned int N>
class Array : public std::array <T, N>
{
   enum AlgoType { NOOP, INSERTION_SORT, QUICK_SORT };
   static const int algo = (N==0) ? NOOP : 
                           (N==1) ? NOOP :
               (N<50) ? INSERTION_SORT : QUICK_SORT;
   void sort (Int2Type<NOOP>) { std::cout << "NOOP\n"; }
   void sort (Int2Type<INSERTION_SORT>) { std::cout << "INSERTION_SORT\n"; }
   void sort (Int2Type<QUICK_SORT>) { std::cout << "QUICK_SORT\n"; }
 public:
   void sort()
   {
     sort (Int2Type<algo>());
   }
};
int main(void)
{
  Array<int, 1> a;
  a.sort(); // No-op!
  Array<int, 400> b;
  b.sort(); // Quick sort  
}

몇 개 더 있는 관련된 타입과 상수들이 Int2Type 양식에 의해 정의되어 사용성을 높일 수 있다. 예를 들어 enumeration 값을 정수 상수와 관련된 타입을 회수 하는데 쓸 수 있다.

Finally, other typedefs such as, next and previous are used to find other types in order such that Int2Type<7>::next is the same type as Int2Type<9>::previous.

template <int I>
struct Int2Type
{
  enum { value = I };
  typedef int value_type;
  typedef Int2Type<I> type;
  typedef Int2Type<I+1> next;
  typedef Int2Type<I-1> previous;
};

Known Uses 알려진 사용처

Integral Constant(boost library) Dimensional Analysis(boost library) std::integral_constant

Related Idioms 관련 관용구

enable-if Type Generator

References 출처

Generic<Programming>: Mappings between Types and Values https://www.ddj.com/genericprogramming-mappings-between-type/184403750