꾸준한 사람이 되자

Jsconvention

2021-11-08T00:00:00+09:00

title: “JS 컨벤션 정리(추가 중~~)” excerpt: “구글(Google), 에어비엔비(Airbnb), NHN style guide”

categories:

JavaScript tags:
Convention

last_modified_at: 2021-11-08T18:00:00-19:00:00

웹개발자를 지망하고 있는데 JS style guide를 한번도 제대로 보지 못했다.
그래서 구글, 에어비엔비, NHN의 js style guide를 정리해보려고 한다.

Source File Basics

2.3.1 White spaces (공백 문자)

All other whitespace characters in string literals are escaped, and ‘string literals’ 안에 있는 모든 공백문제는 escape => \ 처리 되어야 한다.

Tab characters are not used for indentation. indentation(들여쓰기)를 위해서 Tab을 사용하면 안 된다??

Tab을 쓰면 안되는 이유는 다음과 같다. Tab 문자 자체가 태생적으로 모호하고 (can be blank 2칸 or 4칸) Tab이 코드라인 처음에 위치하기 때문에 Tool에 따라서 같은 코드가 다르게 렌더될 수 있다. 코드예시

Objects

3.1 Use the literal syntax for object creation. eslint: no-new-object

// bad
const item = new Object();
    
// good
const item = {}; 

3.2 Use computed property names when creating objects with dynamic property names.

Why? They allow you to define all the properties of an object in one place.

    function getKey(k) {
      return `a key named ${k}`;
    }
    
    // bad
    const obj = {
      id: 5,
      name: 'San Francisco',
    };
    obj[getKey('enabled')] = true;
    
    // good
    const obj = {
      id: 5,
      name: 'San Francisco',
      [getKey('enabled')]: true,
    };

3.3 Use object method shorthand. eslint: object-shorthand

    // bad
    const atom = {
      value: 1,
    
      addValue: function (value) {
        return atom.value + value;
      },
    };
    
    // good
    const atom = {
      value: 1,
    
      addValue(value) {
        return atom.value + value;
      },
    };

target=_blank을 쓸 때 유의할 점

2021-11-08T00:00:00+09:00

개발자들은 새 탭이나 새 창으로 특정 페이지를 여는 링크를 구현할 때, 아래와 같이 target=”_blank” 옵션을 이용하곤 한다.
하지만 이 방식에는 2가지 문제가 있었다. 오늘은 이 2가지 문제에 대해서 알아보려고 한다.

  <a href="https://minje0204.github.io/" target="_blank">
	Made by minje0204 </a>

target=”_blank”의 문제점

target=”_blank” 에는 2가지 문제가 있는데 한가지는 tab-napping이고 다른 한가지는

1. 보안상 취약점이 생긴다.

target=”_blank” 가 사용된 a tag는 사용자가 클릭하면 새 탭에서 링크된 페이지가 열린다. 여기서, 해당 링크를 연 윈도우가 window.opener에 저장된다.

Window.opener
Window 인터페이스의 opener 속성은 open()을 사용해 현재 창을 열었던 창의 참조를 반환합니다.

예제로 설명하자면, 창 A가 창 B를 열었을 때 B.opener는 A를 반환합니다.
ref by. Mozilia|MDN

그리고 window.opener를 사용하면 새 페이지에서 이전 윈도우를 마음대로 조작할 수 있다. 예를 들면, window.opener.location = new malicious URL 와 같이 악성 url로 리다이렉트 시킬 수 도 있다.

2. 퍼포먼스가 떨어질 수 있다

target=”_blank” 가 사용된 링크에 의해 열린 링크된 페이지는 링크를 건 페이지와 같은 프로세스를 통해서 실행된다. 그래서 main-thread에서 진행중이던 모든 작업들이 순간적으로 disrupt 될 수 있다.

현재는 target=”blank”로 이 문제를 재현 할 수 없지만, window.open으로는 가능하다. 심심하면 해보시길…

문제 해결방법(이었던 것)

예시 코드

  <a
	href="https://minje0204.github.io/"
	target="_blank"
	rel="_noreferrer noopener"
>
	Made by minje0204
</a>

위 두가지 문제 때문에 보통 _blank 옵션으로 새창에서 링크를 띄울 경우 위와 같이 rel=”_noreferrer noopener” 를 보통 사용해왔다.

noreferrer
브라우저가 링크를 건 페이지의 주소와 같은 정보를 Referer: HTTP 헤더에 리퍼러(referer 또는 referrer)로 송신하지 않습니다.
noopener
noopener(노오프너)를 지정하면, 링크된 페이지에서 window.opener을 사용해서 링크를 건 페이지를 참조(reference)할 수 없게 됩니다. 더불어 링크된 페이지와 링크를 건 페이지는 별개의 프로세스로 취급

이제는 상관없다?

그럼 첫번째 이슈(보안상 취약점이 생긴다.)를 재현해보자! window.opener로 부모 윈도우를 실제로 조작해보기 재밌겠다~!

<a href="www.naver.com" target="_blank">naver<a/>

target=”_blank” 만 주고 별다른 옵션은 주지 않았다. 그리고 브라우저에 opener를 쳐보았는데…(또잉..?)

noopener 옵션을 주지 않아도 opener를 받아 오지 못했고, 두번째 퍼포먼스 이슈도 재현되지 않아서 찾아보니 이미 크롬은 작년에 해당 이슈관련 업데이트를 했다.

The new update to Chrome will instead force target="_blank" to behave as rel="noopener" by default. ref. GOOGLE CHROME WILL SOON BLOCK JAVASCRIPT REDIRECTS WHEN CLICKING WEB LINKS

결론은 chromium 88 업데이트 이후 크롬에서 target=”_blank” 는 기본적으로 noopener옵션으로 동작한다. 따라서, 개발자가 따로 신경을 써주지 않아도 된다.

인프런 강의를 보다가 강사분께서 말씀해주신 이슈를 찾아봤는데 과거에 이슈였던 것이었다….

ORM vs Raw Query / N+1 Problem

2021-09-02T00:00:00+09:00

수 많은 정보가 저장되는 Data Base에서 원하는 정보를 얻기 위해서는 Query문을 작성해야 한다.
간단하게, single 테이블에서 정보를 가져오기도 하고 좀 복잡하게는 여러 join문을 이용하여 여러 테이블에서 정보를 가져올 수 도 있다.
현업에서는 다양하고 복잡한 Query문 작성이 요구되고 SQL에 능숙해지기까지 많은 시간이 걸린다.
그리고 꼬리에 꼬리를 무는 Query문에서 작은 실수는 디버깅을 힘들게 만든다.
이를 해결해줄 도구가 ORM이다.
ORM(Object - Relational Mapping)은 관계형 데이터베이스와 객체 사이를 매핑시키는 것을 말한다.
ORM은 객체 지향 언어를 사용하여 데이터베이스에 접근할 수 있는 여러 method들을 제공해준다.
ORM이 매핑 시켜놓은 객체를 통해 데이터베이스 데이터를 다룰 수 있게 되는 것이다.
그럼 ORM에 대해서 본격적으로 알아보자!

ORM의 장점

Code와 Database 간의 종속성 DOWN
DB 위에 하나의 추상화된 층을 쌓는 것이기 때문에 개발자들이 MySQL, PostgreSQL, SQLite…등 DB간의 사소한 차이들을 일일이 몰라도 된다.
SQL Query 작성 부담을 덜 수 있다.
인터페이스 작성에 할애하는 시간을 비지니스 로직에 쏟을 수 있다. 직관적 쿼리 => 에러, 버그 발생 가능성 DOWN, 가독성 UP
재사용 및 유지보수에 용이하다.

ORM의 단점

실행 속도가 잘 짜여진 raw query보다 느리다.
한정된 명령문으로 인한 한계
추상화로 인해 Low level 디버깅이 불편함
ORM은 주로 library나 framework, API 형태로 제공되기 때문에 ORM에 종속되게 되고 다른 solution으로의 이동이 어려워진다.

Raw Query의 장점

Best Performance를 달성할 수 있다.
ORM을 사용할 때보다 디버깅이 편하다.
third-party code에 대한 종속성이 없다.

Raw Query의 단점은 위에 적었으니 따로 적지 않겠다.
여기까지 읽어보면 사실 ORM의 단점이 곧 Raw Query의 장점이고 ORM의 장점이 곧 Raw Query의 단점이다.
그래서, SQL query문에 능숙하다는 전제하에 정답은 없고 주어진 task 환경에 맞추어 어떤 방법을 사용할지 선택해야 한다. ~~SQL에 익숙하지 않으면 ORM…~~

N+1 Problem

ORM은 N+1 문제라는 대표적인 Anti - pattern을 가진다.

위 그림과 같은 관계 모델에서 DB에 있는 모든 Book을 차례로 불러와 (iterative) 책마다 달려있는 BookReview에 접근한다고 생각해보자.
여기서 ORM은 default가 lazy-loading (정말 필요한 시점에만 SQL을 호출한다)이기 때문에, 아래와 같이 진행될 것 이다.

SELECT * FROM Books;

for each Book

SELECT * FROM BookReview WHERE BookId = ?

결과적으로 1번의 Books를 가져오는 SELECT문과 N번의 추가적인 SELECT문이 필요하다.
만약, Book이 100개 있다면 BookReview SQL은 100번 호출된다.

Query를 한번 날릴 때 마다 오버헤드가 발생하기 때문에 Query문 100 개에 1개의 정보를 return받는 것 보다 Query문 1개에 100개의 정보를 return 받는 것이 훨씬 빠르다.
이 차이는 DB가 다른 machine에서 돌아가고 있을 때 더 극명해진다.
통신하는데 걸리는 속도가 1-2ms 라면, 100개의 Query를 날리는데 필요한 시간은 100ms-200ms다.

이 문제를 해결하기 위해서는 Eager-Loading을 사용하면 된다. Eager-Loading을 사용하면 사전에 쓸 데이터를 포함하여 쿼리를 날리기 때문에 비효율적으로 늘어나는 쿼리 요청을 방지할 수 있다.

Virtual Dom (가상돔)

2021-08-25T00:00:00+09:00

Virtual Dom (가상돔)

react를 사용해오면서 가상돔을 알게 되고, 이게 왜 필요한 것인지 궁금해졌다. 먼저, 한줄 요약을 해보자면, 실제 DOM 트리를 직접 조작하기에 시간이 오래 걸리기 때문에 가상돔을 활용하여 DOM트리 노드들의 배치를 최적화 시킬 수 있다고 한다. 이를 더 자세히 알아보기 위해서는 먼저 브라우저의 작동 방식을 알아야 한다.

브라우저 주요 기능

사용자가 선택한 자원(주로, html문서)의 URI를 참조하여 서버에 요청한다. 이를 W3C가 정한 HTML CSS 명세에 따라 해석하여 브라우저에 표시한다.

브라우저의 렌더링 방식 (WebKit엔진 기준)

다음은 webkit이 작동하는 방식이다.

브라우저는 HTML문서를 파싱하여 DOM Tree를 생성한다.
css style에 관한 style sheet를 파싱하고 해당하는 Node의 Attach Method를 실행하여 해당 노드에 스타일을 덫붙힌다. 이 동작을 Attachment라고 하며, Synchronous하게 처리된다.
브라우저에서 각 Node들이 어떤 위치에 있어야하는지 스크린의 좌표를 계산하는 Layout 과정을 거친다.
Tree에 각 노드들을 거쳐가면서 색을 칠해준다.
Rendering 완료

왜 DOM Tree를 직접 수정하는 것이 오래걸릴까?

DOM Tree에 변화가 생기면, 위 렌더링 과정이 처음부터 다시 시작되어야 한다. 특히, attachement 과정에서 style은 tag, class, id별로 style이 다르게 주어질 수 있고, 별다른 언급이 없다면 부모 노드의 style을 따르기 때문에 상당한 연산이 필요한데, 복잡한 SPA 와 같이 DOM 변경이 잦아 진다면, 렌더링 과정을 비효율적으로 만들것이다.

가상돔을 쓴다면?

뷰의 변화가 있을 때, 실제 DOM에서 만들어 질 수 있는 가능한 모든 후보군을 가상돔에서 만들어보고(실제 DOM에서 적용하는 것이 아니기 때문에 비용이 덜 들어간다.) 실제 DOM에 적용 시킴으로서 렌더링 과정을 더 효율적으로 만들 수 있다. 렌더링의 연쇄과정을 가상 DOM에서 진행하고 이 결과물만 떼어 실제 DOM에 적용시킨다고 난 이해했다.

DOM fragment를 직접 관리하지 않아도 되게(어디를 변화시켜야 하는지, 어디까지 변화를 반영했는지 등등) 자동화, 추상화 시켜 준다. DOM Tree변화를 하나로 묶어 적용시킴으로서, 변경된 노드사이의 동기화 작업이 필요없어진다.

어쨌든 가상 돔을 사용해도, 연산이 아예 사라지는 것이 아니기 때문에 단순히 가상 돔을 쓴다고 해서 빠르다고 볼 수 없다. 그래도 보통 문제없이 사용할 정도는 된다고 한다. 가상 돔에서의 연산과정 조차 줄이기 위해서 아예 빌드시 해당 연산을 해버리는 svelte도 있다. 하지만 html 변경시 재빌드가 필요하다는 단점이 있다.

REFERENCE

(https://hashnode.com/post/the-one-thing-that-no-one-properly-explains-about-react-why-virtual-dom-cisczhfj41bmssp53mvfwmgrq) (https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/)

DOM트리

2021-08-18T00:00:00+09:00

Document Object Model (DOM)

DOM 이란?

브라우저에 의해 생성되는 node/element 트리
객체지향적인 표현방식
JavaScript는 DOM트리를 읽기/쓰기/수정 할 수 있다.

JavaScript는 DOM트리를 읽을 수 있어 JS를 이용하면 웹 페이지에 존재하는 것들을 모두 수정, 추가, 제거할 수 있다. 이를 위해 예전에는 Jquery를 사용했지만, 요즘은 vanilla JS가 더 자주 쓰인다고 한다.

위 그림에서는 생략 됐지만 브라우저는 DOM tree 최상단에 window object를 위치시키고 바로 밑에 DOM tree의 core인 Document object를 둔다.

Root element부터 html로 표현해본다면 이렇게 될 것 같다.

<!DOCTYPE HTML>
<html>
<head>
	<title>My title</title>
</head>
<body>
	<a href="~~~">My link</a>
	<h1>My header</h1>
</body>
</html>

그럼 이제 vanilla JS를 이용해서 DOM tree을 조작해보자.

개발자 도구를 켜서 document를 찍어보면

console.dir(document)

URL이 나오고 all에는 html 문서에 작성한 순서대로 웹을 구성하는 모든 태그들이 들어 있다. 이외에도 많은 정보들이 담겨있다.

그럼 이제 document node를 이용해 h1 태그를 수정해보자.

index.html

<header>
	<div  id="title-container">
		<h1  id="header-title">Item Lister1</h1>

console

document.getElementById('header-title').textContent = 'hello'   
document.getElementById('header-title').innerText = 'hello'

getElementById를 이용하여 간단하게 title을 바꿔 보았다. (참고. innerText와 textContent 둘의 차이점은 style의 영향 유무이다 )

+ display:none인 다른 tag가 있을 때 
+ innerText는 그 태그 text를 제외하고 출력
+ textContent는 style 무시하고 모든 text를 출력

이제 h1 태그 안에 새로운 태그를 추가해보자

console

var newTag = document.createElement('h3')  
newTag.innerText = 'Hello'
var h1Tag = document.getElementById('header-title')
h1Tag.appendChild(newTag)

Story Mapping, Product Backlog를 시각적으로 구성하는 방법

2021-03-30T00:00:00+09:00

졸업프로젝트를 시작한지 한달…. 이제 대략적인 컨셉이 잡혔다. 프로젝트 구현에 앞서 구체적인 개발 계획을 짜야한다. 애자일 방법론을 활용한 프로젝트 관리를 알아보자. 애자일 방법론에서 제일 선행되어야 할 일은 Product backlog이다.

Product backlog

Product backlog는 프로젝트에서 구현해야할 모든 List를 말한다. 그렇다면 Product backlog는 어떻게 작성해야 할까?

누가, 무엇을,왜 3가지 항목을 포함하여 작성해보자 (사실상 유저 스토리 작성법)

누가(type of user)
여기서 누가는 고객이나 사용자를 말한다. 연령대,취미등을 고려하여 구체화시키면 좋다. 예를 들자면, 30~40대 안전한 거래를 원하는 여성 주부들
무엇을(goal)
누가에 해당하는 이해관계자의 goal이다.
왜
단순하게 왜 해당기능을 사용하는지 이기도 하지만 결과적으로 누가에 해당하는 고객이나 사용자가 얻을 수 있는 이점이 된다.

Product Backlog 작성시 생각해야할 3가지

Product Backlog는 항상 우선순위에 따라 정리한다.
팀 내부 판단하에 중요한 일들은 올리고 상대적으로 덜 중요하거나 기한의 여유가 있는 일은 백로그의 아래로 위치시킨다.
Detail and Rough
백로그 상단에 위치한 일들은 중요도가 높은 일이기 때문에 Detail한 표기가 필요하다. 반대로 하단에 위치한 일들은 상대적으로 Rough해도 괜찮다. 자세할수록 좋겠지만, 최소한 제품이 지향하는 핵심가치나 차별화 포인트가 드러나야한다.
Product Owner
프로덕트 오너는 백로그를 관리하는 사람이다. 일들의 우선순위를 정하고, 새로운일을 추가하거나 이미 진행중인 일들을 수정하기도 한다. 그래서, 프로덕트 오너는 모든 StakeHolders들과 의사소통하고 이를 백로그에 반영하여 한다.

요구사항의 우선순위 정하기

(MoSCow 방법)[https://wemake.services/meta/rsdp/requirements-analysis/#requirements-prioritization]

총 4가지 카테고리로 요구사항을 나눈다.
must, should, could, and won't

Sprint Backlog

Product Backlog를 작성했으면 Sprint Backlog를 정해야한다.
Sprint는 무엇인가?
Sprint란 작은 기능 하나에 대한 계획부터 개발, 테스트, 기능 구현까지의 주기를 말한다.
대략 1~4주 사이의 기간으로 정해진다.
Sprint Backlog는 해당 Sprint기간에 해야할 백로그다.
하지만 당장 해야할 일들이기 때문에 백로그에 위치할 때보다 더 세분화 되어야 한다. 주로 task형식으로

Burndown Chart

위에서 Sprint를 알아봤다. 번다운 차트는 스프린트동안의 개발 진행정도를 알려주는 차트다.
daily scrum에서 매일 업데이트 된다.

Story Mapping

요구사항 분석하는 top-down 방식 tree형태로 그려진다. Story Map의 최상단은 Vision이다. 이 Vision은 Goal을 통해서 이루어진다. 그리고 이 Goal은 activities에 의해서 이루어진다. 다시 이 activites는 Task로 이루어지고, 이 Task는 User Story가 된다.

Story Map Structure: Goals > Activities > Tasks > Stories 순이다.

Add profile image & File transfer from Window10 to WSL2

2021-03-14T00:00:00+09:00

프로필 이미지를 추가하려고 아이폰에 저장되있는 사진을 불러오려고 했는데,원래 블로그 작업을 wsl에서 하고 있다 보니까 윈도우에 사진을 옮기고 scp로 wsl로 옮기려고 했다.

scp profile.jpg minje0204@ip:/mnt/c/...(파일저장위치)

위명령어를 쳤는데 ssh: connect to host (wsl ip) port 22: Connection refused 에러가 떴다.

찾아본 결과 나는 wsl에서

vi /etc/ssh/sshd_config

로 ssh 세팅 환경에서 port지정해주는 부분의 주석처리를 지웠다 default는 22다.
PasswordAuthentication yes도 No에서 yes로 바꿔주었다.

이렇게 세팅 2개를 완료하고도 똑같이 connection refused 에러가 뜨길래 찾아보니까 WSL2부터는 hyper-v 엔진위에서 Linux를 돌리기 때문에 별도의 가상 NIC를 가지고 있다는 말을 보고
WSL 내에서 ip를 확인해보니 왠걸 window 프롬프트에서 wsl로 나온 ip주소와 다른 ip주소가 나왔다.

WSL에서 찾은 ip주소를 입력해주는 정상적으로 scp 가 작동했다.

github.io 블로그 시작하기

2021-03-13T00:00:00+09:00

GitHub Blog 서비스인 github.io 블로그 시작하기로 했다.

GitHub Blog 서비스의 이름은 Pages이다.

Pages가 다른 블로그 플랫폼 보다 편한 것 같아서 마음에 든다.

다른 사람들도 같이 많이 사용했으면 좋겠다는 생각이 든다.

YFM에서 정의한 제목을 이중 괄호 구문으로 본문에 추가할 수 있다.

이 글의 제목은 github.io 블로그 시작하기 ({{page.title}}로 표현) 이고

마지막으로 수정된 시간은 2021-03-13T00:00:00-02:36:00 ({{ page.last_modified_at }}로 표현)이다.

다음은 GitHubBlog를 작성하기 위해 필요한 간단한 markdown을 알아보자.

텍스트 줄바꿈

텍스트 줄바꿈을 하려면 스페이스 2번을 표기하면 된다.  
*기울이기*는 '*'를 이용하고,  
**볼딕체**는 '**'를 이용한다.  
~~취소선~~은 '~~'를 이용한다.  

글자 크기 지정

'#'개수가 적을 수록 글자가 커지며 # 개수는 6개 까지 가능하다.
#h1  ###h3  ######h6  

인용
```
> 인용문 
```
코드인용
```
int main(){
}
```

markdown 코드를 그대로 표현하고 싶은데 C언어 처럼 ‘`’ 백틱은 작동하지 않는 것 같다. 한번 알아봐야겠다.

왜 인지는 아직 모르겠지만 지킬 서비스를 background에서 수행중에 post 내용을 수정하면 반영이 되지 않는데, 다른 터미널에서 지킬 서비스를 동작시키고 또다른 터미널에서 post내용을 수정하면 그때는 바로 반영이 된다.

GitHubBlog 개설 처음부터 마크 다운까지 devinlife님의 블로그를 참조했다.