Wanna be a thinker

1. 개요

1.1. 파티션이란?

PC의 기억장치 내부를 용도에 따라 구분한 디렉토리 구조이다.

드라이브는 sda, sdb, sdc ... sd<A>의 말미의 알파벳 변화가 일반적이고,

드라이브 내의 파티션은 sda1, sda2, sda3 ... sda<N>과 같이 번호가 할당되는 것이 일반적이다.

1.2. 왜 파티션을 구분하는가?

실제로 구분하지 않아도 시스템 자체는 가동하지만, 파티션을 구분하면 관리상의 편의성이 향상된다.

1.2.1. 시스템 영역과 데이터 영역의 분리

시스템 복구시, 시스템 영역만을 초기화하고 데이터를 보존할 수 있다.

일반적으로 /home 아래에 유저마다의 데이터를 보존한다.

또한, 유저가 스스로 설치한 어플리케이션은 /usr 아래에 보존하는 경우가 많다.

1.2.2. swap영역의 작성

메인 메모리가 부족할 때 그 대신 사용할 수 있는 영역이다.

고가의 메인 메모리를 저가의 기억매체로 보충할 수 있다.

메인 메모리 이상의 용량을 확보하기 위해 비교적 옛날부터 존재하는 구조이다.

1.3. 기본 파티션과 확장 파티션, 논리 파티션

1.3.1. 파티션의 종류

고전적인 BIOS(Basic Input Output System)와 MBR(Master Boot Record)에 의한 파티션 관리의 경우, 기본적으로 원시적이고 단순한 파티션은 기본 파티션이라 하며 4개까지 만들 수 있다.

실제로는 더욱 상세하게 파티션을 구분할 필요가 있는 경우 확장 파티션이라는 특수영역을 확보하여 그 안에 논리 파티션을 사용해 파티션을 상세하게 분할할 수 있다.

MBR의 관리방법의 경우 기본 파티션 4개 또는, 기본 파티션 3개와 확장 파티션 내의 논리 파티션을 구분하여 사용한다.

1.3.2. 분할의 한계

Linux는 SATA 접속의 기억매체인 경우 15개의 파티션이 한계이다.

기본 파티션 3개와 확장 파티션의 논리 파티션이 12개이다.

반면, 요즘 보급되는 UEFI(Unified Extensible Firmware Interface) + GPT(GUID Partition Table)로 관리하는 경우 일반적으로 128개의 기본 파티션을 설정할 수 있다.

2. Linux 디렉토리 구조

일반적으로 다음과 같은 구조이다.

2.1. /

가장 상위의 디렉토리이며 여기서 트리구조로 디렉토리를 생성한다.

2.2. /bin

현재 /usr/bin으로의 심볼릭 링크(바로가기)로 되어 있다. /usr/bin에는 실행 가능 바이너리 즉, 커맨드가 격납되어 있다.

2.3. /boot

커널 등이 격납되어 있다.

2.4. /dev

디바이스를 제어하기 위한 디바이스 파일군이 관리되고 있다.

2.5. /etc

주로 설정파일이 설치된다.

2.6. /home

일반 유저의 데이터는 여기에 보존된다.

2.7. /lib

/usr/lib으로의 심볼릭 링크이다.

2.8. /lib64

/usr/lib64으로의 심볼릭 링크이다. 64Bit 바이너리에 대한 라이브러리이다.

2.9. /media

USB 등의 Removal Media가 마운트된다.

2.10. /mnt

현재 media 디렉토리가 역할을 대신하는 경우가 많지만, 수동 마운트시, 이 곳에 외부기억매체를 마운트할 때가 많다.

2.11. /proc

현재 시스템의 정보로서 CPU나 메모리의 내부 정보가 파일로 설치된다.

2.12. /root

root 유저 전용 디렉토리

2.13. /run

기동하고 있는 프로세스 ID 정보가 설치된다.

2.14. /sbin

/usr/sbin으로의 심볼릭 링크이다. 시스템의 근간을 이루는 기초 커맨드의 바이너리가 격납되어 있다.

2.15. /srv

FTP나 HTTP 등의 전용 디렉토리, 어디까지나 기준적인 것이며 절대적이지 않다.

2.16. /sys

드라이버 관련 프로세스에 관한 디렉토리이다.

2.17. /tmp

일시 데이터 보존용 디렉토리이다.

2.18. /usr

시스템의 라이브러리나 실행 파일 등이 격납되어 있다.

2.19. /var

대체로 로그 등이 설치된다.

출처 : eng-entrance.com/linux-partition

등장 배경

초기의 자바스크립트는 규모가 작고, 기능이 단순하여 모듈의 개념이 필요없었다.

하지만 현재, 자바스크립트를 이용한 애플리케이션의 규모가 커지면서 파일을 분할할 필요가 생겼다.

분할 파일 그 자체로 모듈이며, 모듈은 대개 클래스 하나 혹은 특정 목적을 가진 복수의 함수로 구성된 라이브러리이다.

개요

JavaScript에서의 모듈이란, ES2015(ES6) 이후부터 제공하는 import / export 키워드를 통해 스크립트의 변수나 함수를 타 스크립트에서 이용할 수 있도록 기능을 공유하는 것이다.

모듈의 핵심 기능

1) '엄격 모드(use strict)'로 실행되어 올바르지 않은 문법을 사전에 검출하여 에러를 발생시킨다.

2) 모듈은 자신만의 스코프가 있어 import / export를 사용하지 않고는 기능을 주고 받을 수 없다.

3) 동일한 모듈이 여러 곳에서 사용되더라도 모듈은 최초 호출 시 단 한 번만 실행된다.
   실행 후 결과는 이 모듈을 가져가려는 모든 모듈에 내보내 진다.

4) import.meta 객체는 현재 모듈에 대한 정보를 제공한다.

   실행 환경에 따라 다른 정보를 제공한다.

   ex) 브라우저 : 현재 실행 중인 웹페이지의 URL 정보

5) HTML에 type="module" 속성을 부여한 script(이하, 모듈 스크립트)에서의 'this'는 undefined이다.

   일반 스크립트에서의 this는 전역 객체인 것과 대조된다.

브라우저의 특정 기능

1) 모듈 스크립트는 HTML 문서가 완전히 렌더링 된 후에 실행된다.

   이러한 특징 덕분에 항상 완전한 HTML 페이지를 볼 수 있고, 문서 내 요소에도 접근할 수 있다.

2) 모듈 스크립트에 async 속성을 부여하면, 모듈을 import한 직후 HTML 문서의 렌더링 완료에 관계 없이 실행된다.

3) src 속성 값이 동일한 모듈 스크립트는 중복 실행되지 않는다.

4) 외부 사이트의 모듈 스크립트를 호출하기 위해서는 외부 사이트에서 CORS 헤더(Access-Control-Allow-Origin: *)를

   제공해야 한다.

5) 브라우저 환경에서 모듈을 import할 시, URL을 지정해야 한다.

   Node.js나 번들링 툴은 별도로 해당 모듈을 찾는 방법이 존재하기 때문에 경로가 없는 모듈을 사용할 수 있다.

6) 구식 브라우저와의 호환성을 위해 nomodule 속성을 정의한 스크립트로 모듈 스크립트가 실행되지 않을 때의

   예외처리를 정의할 수 있다.

출처 :

uwostudy.tistory.com/55

ko.javascript.info/modules-intro#ref-93

개요

'스코프(Scope)'는 변수의 범위를 의미한다.

Scope의 종류

1. 전역(Global)

2. 지역(Local)

  2.1. 함수(function)

  2.2. 블록(block)

Scope의 예제

// 전역
const a = 111;

// 지역(함수)
function sayNumber() {
    const a = 1;
    console.log(a);
}

sayNumber();	// 출력 : 1

console.log(a);	// 출력 : 111

자신의 지역 내에 변수가 없는 경우 ScopeChain을 통해 해당하는 변수를 전역 스코프에서 찾는다.

// 전역
const a = 111;

// 지역(함수)
function sayNumber() {
    console.log(a);
}

sayNumber();	// 출력 : 111

기존 var의 경우, 함수 스코프를 가졌기 때문에 함수 내에서만 지역 변수가 유지되는 문제가 있었다.

하지만, ES2015(ES6)에서 let, const 키워드의 추가로 함수가 아닌 일반 블록에서도 지역변수를 선언할 수 있게 되었다.

// 전역
const a = 111;

// 지역(블록)
{
    const a = 1;
    console.log(a);	// 출력 : 1
}

console.log(a);	// 출력 : 111

출처 : medium.com/@yeon22/javascript-%EC%8A%A4%EC%BD%94%ED%94%84-scope-%EB%9E%80-bc761cba1023

개요

ESLint란 ES(EcmaScript 즉, JavaScript)와 Lint(에러가 있는 코드에 표시를 달아놓는 것)의 합성어이다.

사용자가 정의한대로 코드를 점검, 에러가 있으면 표시해주고 또한 코딩스타일을 정할 수 있는 도구이다.

장점

1. 문법 에러를 잡아준다.

2. 코딩스타일을 정해 팀 단위로 작업해도 한 사람이 코드를 작성한 듯한 결과를 낸다.

3. 다양한 플러그인을 사용할 수 있어 손쉽게 다른 회사나 사람의 설정을 도입할 수 있는 확장성이 있다.

출처 :

velog.io/@jiwon/ESlint

www.zerocho.com/category/JavaScript/post/583231719a87ec001834a0f2

용어

컴파일(Compile) : 인간이 작성한 소스코드를 기계가 이해할 수 있는 머신코드로 변환하는 것이다.

트랜스파일(Transpile) : 다른 실행 환경에서도 동작하도록 같은 언어를 유지한 채 소스 코드의 형태만 바꾸는 것이다.

개요

JavaScript의 트랜스파일러(Transpiler)이다. 아래의 변환 대상으로 작성한 JavaScript 코드를 ES5 이하의 문법으로 변경하여, 최신 문법을 지원하는 환경과 그렇지 않은 환경 양 쪽에서 잘 동작하도록 해준다.

사용하는 이유

JavaScript 언어의 문법은 빠르게 진화하지만 정작 실행 환경은 이를 받쳐주지 못하는 경우가 많다.

실행 환경인 브라우저의 경우 종류가 다양하고 어떤 브라우저가 어떤 문법을 지원하는지 일일이 파악하기가 힘들 정도이고, 노드(NodeJS)의 경우에도 버젼별로 지원하는 언어나 문법이 다르다.

개발자가 JavaScript ES6 이상의 최신 문법으로 작성한 코드는 일부 실행 환경에서 작동하지 않기 때문에 모든 환경에서 돌아가도록 보수적으로 예전의 ES5 이하 방식으로 코드를 작성해야 하는 문제를 겪는다.

변환 대상

ES6 이상의 최신 문법, TypeScript나 JSX로 작성된 코드 등

특징

Babel은 단독으로 사용되기도 하지만 규모가 큰 프로젝트에서는 Webpack이나 Rollup같은 번들러(bundler)와 함께 사용되거나 프레임워크의 일부로 포함되기도 한다.

출처 : www.daleseo.com/js-babel/

용어 정리

- 유기적 : 많은 조직, 요소 등이 모여 하나를 이루고 서로 긴밀히 연관되어 서로 떼어 낼 수 없는 (것).

- 뷰의 반응성 : 뷰가 데이터 변화를 감지했을 때 자동으로 화면을 다시 갱신하는 특성이다.

- 컴포넌트 : 화면의 영역을 일정한 단위로 쪼개어 재활용 가능한 형태로 관리하는 것이다.

개요

상태 관리 패턴이자 라이브러리이다.

상태관리란?

여러 컴포넌트 간의 데이터 전달과 이벤트 통신을 한 곳에서 관리하는 패턴을 의미한다.

상태관리의 필요성

- Vue는 컴포넌트를 조합하여 화면을 구성한다.

- 한 화면에 많은 컴포넌트를 사용함에 따라, 컴포넌트 간 통신이나 데이터 전달을 유기적으로 관리할 필요가 있다.

상태관리 패턴으로 해결할 수 있는 문제란?

- 일반적으로 App의 규모가 커지면 다음과 같은 문제가 발생한다.

1) 뷰의 컴포넌트 통신 방식인 props, event emit 때문에 중간에 거쳐야 할 컴포넌트가 많아지는 것.

2) 위의 문제를 피하기 위해 EventBus를 사용함에 따라 컴포넌트간 데이터의 흐름을 파악하기 어려워 지는 것.

- 위의 문제들을 해결하기 위해 모든 데이터 통신을 한 곳에서 중앙 집중식으로 관리하는 것이 상태 관리이다.

Vuex 구성 요소

1. state : 여러 컴포넌트간 공유할 데이터를 정의한 것이다.

2. getters : state를 컴포넌트에서 취득할 시, 복잡한 로직을 거치지 않도록 getter 메소드를 vuex에 정의한 것이다.

3. mutations : state 값을 변경(state 관리)하는 로직으로 setter 메소드를 vuex에 정의한 것이다.

4. actions : 비동기 처리 로직들을 vuex에 정의한 것이다.

폴더 구조화 & Name Spacing

규모 있는 복잡한 앱 제작 시, getters, mutations, actions의 이름을 유일하게 정하지 않으면 namespace 충돌이 난다.

이에 다음 두 가지 방법이 있다.

(1) 네임스페이스를 구분하기 위해 types.js로 각 속성의 이름들을 빼고 store.js와 각 컴포넌트에 import하여 사용.

(2) 혹은 modules라는 폴더로 만들어 각 단위별로 파일을 쪼개서 관리.

핵심 요약

1. vuex는 컴포넌트간 데이터 전달, 이벤트 통신을 중앙 집중식으로 관리하기 위한 라이브러리이다.

2. vue는 컴포넌트를 조합하여 화면을 만들고, 컴포넌트 간 복잡한 데이터 전달을 관리하기 위해 vuex를 사용한다.

3. vuex의 구성요소 중, state는 데이터의 보관, getters는 데이터의 취득 로직, mutations는 데이터의 갱신 로직,

   actions는 비동기 처리 로직을 담당한다.

출처 : 

joshua1988.github.io/web-development/vuejs/vuex-start/

joshua1988.github.io/web-development/vuejs/vuex-getters-mutations/

joshua1988.github.io/web-development/vuejs/vuex-actions-modules/