tsts_.log

Javascript - Module

Wed, 15 Sep 2021 09:09:47 GMT

Module

모듈이란 어플리케이션을 구성하는 개별적 요소로써, 재사용 가능한 코드 조각을 말한다. 일반적으로 모든 모듈은 기능을 기준으로 파일 단위로 분리한다. 이때 모듈이 성립하려면 모듈은 자신만의 파일 스코프(모듈 스코프)를 가질 수 있어야 한다.

어플리케이션과 완전히 분리되어 개별적으로 존재하는 모듈은 재사용이 불가능하므로 존재의 의미가 없다. 모듈은 어플리케이션이나 다른 모듈에 의해 재사용되어야 의미가 있다. 따라서 모듈은 공개가 필요한 자산에 한정하여 명시적으로 선택적 공개가 가능하다. 이를 export라 한다.

공개된 모듈의 자산은 다른 모듈에서 재사용할 수 있다. 이때 공개된 모듈의 자산을 사용하는 모듈을 모듈 사용자라 하며 모듈 사용자는 모듈이 공개한 자산중 일부 또는 전체를 선택해 자신의 스코프 내로 불러들여 재사용할 수 있다. 이를 import라 한다.

자바스크립트의 모듈

자바스크립트는 초기에 웹페이지의 단순한 보조 기능을 처리하기 위한 제한적인 용도를 목적으로 태어났다. 이러한 태생적 한계로 인해 다른 프로그래밍 언어에는 존재하는 파일 스코프와 import, export를 지원하지 않았다.

그러나 자바스크립트를 브라우저 환경에 국한하지 않고 범용적으로 사용하려는 움직임이 생기면서 모듈 시스템은 반드시 해결해야 하는 핵심 과제가 되었다. 이런 상황에서 제안된 것이 CommonJS ```ESM`` 이다.

node.js의 모듈

ES6(ESM) 모듈

ES6 모듈의 사용법은 간단하다. script 태그에 type="module" 어트리뷰트를 추가하면 로드된 자바스크립트 파일은 모듈로써 동작한다. ESM은 독자적인 모듈 스코프를 갖으며 일반적인 자바스크립트 파일을 script 태그로 분리해서 로드해도 독자적인 모듈 스코프를 갖지 않게된다.

모듈 내부에서 선언한 식별자를 외부에 공개하여 다른 모듈들이 재사용할 수 있게 하려면 export 키워드를 사용한다. export 키워드는 선언문 앞에 사용하며 이로써 변수, 함수, 클래스등 모든 식별자를 export할 수 있다.

export const hello = 'world';

export function kim() {
  console.log('taesu');
}

export class Human {
  constructor(name) {
    this.name = name;
  }
}

const hello = 'world';

function kim() {
  console.log('taesu');
}

class Human {
  constructor(name) {
    this.name = name;
  }
}

export {hello, kim, Human};

위와같이 사용할 수 있다.

다른 모듈에서 공개(export)한 식별자를 자신의 모듈 스코프 내부로 로드하려면 import 키워드를 사용한다. 다른 모듈이 export한 식별자 이름으로 import해야 하며 ESM의 경우 파일 확장자를 생략할 수 없다.

import { hello, kim, Human} from './exports.mjs';

모듈에서 하나의 값만 export 한다면 default키워드를 사용할 수 있다. default 키워드를 사용하는 경우 기본적으로 이름 없이 하나의 값을 export 한다. default 키워드를 사용하는 경우 var, let const 키워드는 사용할 수 없다.

export default x => x * x;

import square from './exports.mjs';

default 키워드로 export한 모듈은 {}없이 임의의 이름으로 import 한다.

Javascript-async/await

Tue, 07 Sep 2021 14:00:31 GMT

async / await

ES8(ECMAScript 2017)에서는 간단하고 가독성 좋게 비동기 처리를 동기 처리처럼 동작하도록 구현할 수 있는 async/await가 도입되었다.

async/await은 프로미스를 기반으로 동작하며, async / await을 사용하면 promise의 then catch finally 후속 처리 메서드에 콜백 함수를 전달하여 비동기 처리 결과를 후속 처리할 필요 없이 마치 동기 처리처럼 promise를 사용할 수 있다. 프로미스의 후속 처리 메서드 없이 마치 동기 처리처럼 프로미스가 처리 결과를 반환하도록 구현할 수 있다.

Promise를 사용한 api호출

const fetch = require('node-fetch');
const url = 'https://jsonplaceholder.typicode.com/todos/1';
const fetchTodo = () => {
  fetch(url)
    .then(res => res.json())
    .then(console.log)
    .catch(err => console.log(err.response))
}

async/await을 사용한 api호출

const fetch = require('node-fetch');
const url = 'https://jsonplaceholder.typicode.com/todos/1';
const fetchTodo = async () => {
  const res = await fetch(url);
  const data = await res.json();
  console.log(data);
}

async 함수와 await 키워드

await 키워드는 반드시 async 함수 내에서만 사용 되어야 하며, async 함수는 promise를 반환하지 않더라도, 암묵적으로 반환값을 resolve 하는 프로미스를 반환한다. await 키워드는 프로미스가 settled 상태가 될 때까지 대기하다가 settled 상태가 되면 프로미스가 resolve한 처리 결과를 반환한다. await 키워드는 반드시 프로미스 앞에서 사용해야 한다.

const fetch = require('node-fetch');

const getGithubUserName = async id => {
  const res = await fetch(`https://api.github.com/users/${id}`);
  const { name } = await res.json();
  console.log(name);
};

getGithubUserName('aaron'); // 'aarron Kim'

위와 같이 await 키워드는 프로미스가 settled 상태가 될 때까지 대기한다. 따라서 fetch 함수가 수행한 http 요청에 대한 서버의 응답이 도착하여 fetch 함수가 반환한 프로미스가 settled 상태가 될 때까지 res 변수 컨텍스트에서 대기하며, 이후 프로미스가 settled 상태가 되면 프로미스가 resolve한 처리 결과가 res 변수에 할당 된다. 이처럼 await 키워드는 다음 실행을 일시 중지시켰다가 프로미스가 settled 상태가 되면 다시 재개한다.

이러한 async/await 문은 자바스크립트 뿐만 아니라 c#, python 등의 언어에서도 존재한다. 상세한 기능이나 구현 방법은 다르지만 비동기 동작을 동기처럼 작동하게 하는 부분에서 일맥상통 한다.

Javascript - Debounce, throttle

Thu, 19 Aug 2021 14:54:29 GMT

Event handling

브라우저에서 동작하는 scroll, resize, input, mousemove, ... 와 같은 이벤트들은 아주 짧은 시간 간격으로 연속하여 발생한다. 이러한 이벤트에 바인딩한 이벤트 핸들러는 과도하게 호출되어 성능에 문제를 일으키는 경우가 많다. Debounce와 throttle은 짧은 시간 간격으로 연속해서 발생하는 이벤트를 그룹화 하여 과도한 이벤트 핸들러의 호출을 방지하는 프로그래밍 기법이다.

예를 들어, 아래와 같은 버튼을 짧은 시간 간격으로 연속해서 클릭했을 때 일반적인 이벤트 핸들러와 디바운스, 스로틀 된 이벤트 핸들러의 호출 빈도는 어떻게 다를까.


  
  
    
    일반 클릭 이벤트 카운터 0
    디바운스 클릭 이벤트 카운터 0
    스로틀 클릭 이벤트 카운터 0
    
  
  

/*         <20회 연속 클릭>
    일반 클릭 이벤트 카운터 20
        디바운스 클릭 이벤트 카운터 1
        스로틀 클릭 이벤트 카운터 6
*/

디바운스와 스로틀은 이벤트를 처리할 때 매우 유용하며, 디바운스와 스로틀 구현에는 타이머 함수가 사용된다.

Debounce

디바운스는 짧은 시간 간격으로 이벤트가 연속해서 발생하면, 이벤트 핸들러를 호출하지 않다가 일정 시간이 경과한 이후에 이벤트 핸들러가 한번만 호출 되도록 한다. 즉, 디바운스는 짧은 시간 간격으로 발생하는 이벤트를 그룹화 하여, 이전 요청은 무시하고 마지막에 한번만 이벤트 핸들러가 호출되도록 한다
input이벤트로 사용자가 텍스트 입력 필드에 값을 입력할 때 마다 Ajax요청과 같은 무거운 처리를 수행한다면 사용자가 아직 입력을 완료하지 않았어도 요청이 여러번 전송될 것이다. 이는 서버에 부담을 주는 불필요한 처리이므로, 사용자가 입력을 완료했을 때 한 번만 Ajax 요청을 전송하는 것이 바람직하다.

Throttle

스로틀은 짧은 시간 간격으로 이벤트가 연속해서 발생하더라도 일정 시간 간격으로 이벤트 핸들러가 최대 한번만 호출되도록 한다. 즉 스로틀은 짧은시간 간격으로 연속해서 발생하는 이벤트를 그룹화하여 일정시간 단위로 이벤트 핸들러가 호출 되도록 호출 주기를 만든다.
예를들어, scroll이벤트를 이용할때, 사용자가 스크롤할 때 짧은 시간 간격으로 연속해서 발생한다. 이처럼 짧은 시간 간격으로 연속해서 발생하는 이벤트의 과도한 이벤트 핸들러의 호출을 방지하기 위해 스로틀은 일정한 주기를 만들어 해당 주기가 경과하기 이전에 이벤트가 발생하면 아무것도 하지 않다가, 해당 주기가 경과 했을 때 이벤트가 발생한다. 일정 시간 간격으로 이벤트 핸들러를 호출하는 스로틀은 scroll이벤트 처리나 무한 스크롤UI구현 등에 유용하게 사용된다.

Debounce, Throttle 구현

위의 예제와 같이 debounce와 throttle 함수를 직접 구현할 수 있으나, 실무에서는 더 정교하게 구현된 underscore 나 lodash 의 debounce, throttle 함수를 사용하도록 하자. ~~Lodash를 사용하도록 하자~~

Javascript - Symbol

Tue, 10 Aug 2021 13:12:28 GMT

Symbol

Symbol은 ES6에서 새롭게 추가된 자바스크립트의 7번째 원시 데이터 타입이다 심벌 값은 다른값과 중복되지 않는 유일무이한 값이다. 따라서 주로 이름의 충돌 위험이 없는 유일한 프로퍼티 키를 만들기 위해 사용한다.

MDN 에서는 다음과 같이 서술하고 있다.

Symbol() 함수는 심볼(symbol) 형식의 값을 반환하는데, 이 심볼은 내장 객체(built-in objects)의 여러 멤버를 가리키는 정적 프로퍼티와 전역 심볼 레지스트리(global symbol registry)를 가리키는 정적 메서드를 가지며, "new Symbol()" 문법을 지원하지 않아 생성자 측면에서는 불완전한 내장 객체 클래스(built-in object class)와 유사합니다.

심볼의 생성

심볼은 세가지 방법으로 생성할 수 있다.

Symbol();
Symbol.for();
Symbol.iterator 이 중 Symbol.iterator 는 iterator객체를 정의하기 위해 쓰인다.

Symbol()과 Symbol.for()의 차이점

Symbol()은 고유한 심볼을 반환한다, 하지만 Symbol.for()는 전역으로 존재하는 global symbol table의 목록을 참조하여, 아래와같이 'hello world'로 정의된 심볼이 이미 존재 한다면, 해당 심볼을 반환하고, 존재하지 않다면 해당 심볼을 생성 후, 만들어진 해당 심볼을 반환하게 된다.

const obj = {};
const mySymbol1 = Symbol.for('hello world');
const mySymbol2 = Symbol.for('hello world');
obj[mySymbol1] = 20;
console.log(obj[mySymbol2] === 20);

Symbol 속성은 열거형 속성이 아니기 때문에 for...of 문이나, Object.keys때 찾지 못한다. Object.getOwnPropertySymbols로 찾아야 한다. 또한 JSON.stringify()에서도 무시된다.

그래서 왜 필요한데?

심볼 값으로 고유한 프로퍼티 키를 만들 수 있다. 외부에 노출할 필요가 없는 프로퍼티를 은닉할 수 있다. 다만 Object.getOwnPropertySymbols 메서드를 사용하면 심볼 값을 프로퍼티 키로 사용하여 생성한 프로퍼티를 찾을 수 있다.
enum 처럼 값에는 의미가 없고, 상수 이름 자체에 의미가 있는 경우가 있다. 상수 값은 변경될 수 있으며 다른 변수 값과 중복될 수 있다는 문제가 있다. 변경/중복될 가능성이 있는 무의미한 상수 대신 중복될 가능성이 없는 유일무이한 심볼 값을 사용할 수 있다.
빌트인 객체에 사용자 정의 메서드를 직접 추가할 때, 다음 ECMAScript에 똑같은 이름의 메서드가 도입된다면 문제가 된다. 따라서 중복될 가능성이 없는 심볼 값으로 빌트인 객체를 확장하면 나중에 추가될지 모르는 어떤 메서드와도 충돌할 위험이 없어 안전하게 빌트인 객체를 확장할 수 있다.

Javascript - class는 그저 prototype의 syntax sugar 일까?

Tue, 03 Aug 2021 12:58:46 GMT

JS class

자바스크립트는 prototype기반 객체지향 언어로써, 다른 객체지향 언어와의 차이점에 대한 논쟁이 있지만 강력한 객체지향 프로그래밍 능력을 지니고 있다. es5에서는 클래스 없이도 다음과 같이 생성자 함수와 프로토타입을 통하여 객체지향 언어의 상속을 구현할 수 있다.

const Person = (function () {
  function Person(name) {
    this.name = name;
  }

  Person.prototype.sayHi = function () {
    console.log('Hi! My name is ' + this.name);
  };

  return Person;
}());

const me = new Person('Lee');
me.sayHi(); // Hi! My name is Lee

다만 클래스기반 언어에 익숙한 프로그래머들은 프로토타입 기반의 프로그래밍 방식에 혼란을 느낄 수 있다. 따라서 es6 이상의 class 키워드를 사용하여 클래스 기반 객체지향 프로그래밍에 익숙한 프로그래머가 더욱 빠르게 학습할 수 있도록 클래스 기반 객체지향 프로그래밍 언어와 흡사한 형태의 객체 생성 매커니즘이 구현 되었다. 그러나 자바스크립트가 기존의 프로토타입 기반 인스턴스 생성을 버리고 클래스 기반의 모델을 제공하는것은 아니며, 기존 프로토타입 기반 패턴을 가져가되 클래스 기반 패턴처럼 사용 할 수 있도록 하는 syntax sugar 라고 할 수 있다.

다만 둘은 정확히 동일하게 동작하지는 않으며, 클래스 생성자가 프로토타입 생성자 함수보다 엄격하며, 생성자 함수에서 지원하지 않는 기능도 제공한다. 클래스와 생성자함수간의 차이점은 대표적으로 다음과 같다.

- 클래스를 new 연산자 없이 호출하면 에러가 발생한다. 그러나 생성자 함수는 new없이 일반 함수로써 호출할 수 있다.
- 클래스는 상속을 지원하는 extends와 super 키워드를 제공한다.
- 클래스는 호이스팅이 발생하지 않는다. 하지만 함수 선언문으로 정의된 함수는 함수 호이스팅이, 함수 표현식으로 정의한 생성자 함수는 변수 호이스팅이 발생한다.
- 클래스 내의 모든 코드는 암묵적으로 strict mode가 지정되어 실행된다.
- 클래스의 constructor, 프로토타입 메서드, 정적 메서드는 모두 프로퍼티 어트리뷰트 [[Enumerable]]의 값이 false다. 열거되지 않는다.

생성자 함수와 클래스는 프로토타입 기반의 객체지향을 구현했다는 점에서 매우 유사하다. 하지만 클래스는 생성자 함수 기반의 객체 생성 방식보다 명료하다. 따라서 클래스를 프로토타입 기반의 생성 패턴의 단순한 문법적 설탕이라고 보기 보다는 새로운 객체 생성 메커니즘으로 보는것이 좀 더 합당하다.

prototype과 class의 차이

프로토타입 기반의 프로그래밍 언어인 자바스크립트에서 Class 키워드가 추가되었다고 해서 자바스크립트가 Class기반의 언어가 되었다는 것이 아니다. 프로토타입 기반은 클래스 기반의 구시대적 방법보다 강력한 시스템이 될 수 있다. 프로토타입 기반의 코드를 클래스 기반으로 바꾸는 것은 쉽지만, 반대의 경우는 거의 불가능에 가깝다.

Class는 설계도이다

Class 상속을 이용한 방법은 변경하기 어렵고 기반이 되는 클래스를 수정했을 때 하위 클래스들이 영향을 쉽게 받을 수 있는 계급 계층구조를 만든다. Class의 정의에 인스턴스의 함수를 불러올 수 없다. 인스턴스를 먼저 생성한 후에 해당 함수를 불러올 수 있다.

Prototype은 오브젝트 인스턴스이다

Prototype 상속이 반드시 유사한 계층구조를 생성하지는 않는다. 프로토타입 체인을 최대한 간결하게 만드는 것이 중요하다. 위임형 상속을 사용하는 것은 말 그대로 다른 오브젝트와 연결된 오브젝트라고 할 수 있다. 프로토타입 객체는 다른 객체의 기반이 된다. 연결상속을 사용하면 새인스턴스로 속성을 복사함으로써 상속을 구현하는 방법이다.

Prototype

Javascript 안에서는 원시 데이터타입을 제외한 모든것이 객체이다. 객체를 생성하기 위해서는 자신을 만드는데 원형인 프로토타입 객체를 사용하여 객체를 만드는데, 이 때 만들어진 객체 안에는 __proto__속성이 있으며, 이는 자신을 만들어내는데 사용된 원형 프로토타입 객체를 참조하는 링크를 갖고 있다. 이 숨겨진 링크를 프로토타입이라 지칭한다.

Javascript - this

Tue, 20 Jul 2021 07:01:16 GMT

this

this는 여러 프로그래밍 언어에서 class의 instance를 바인딩 하는 키워드 이다. 몇몇 프로그래밍 언어에서는 다른 이름으로도 불리우는데, 대표적으로 python의 self 등이 유사한 동작을 보여준다. 그러나 자바스크립트의 this는 해당 기능 말고도 많은 기능을 보유했는데 이런 부분이 javascript에서의 this를 어렵게 만드는 부분이다.

this의 4가지 동작

javascript 함수의 this에 바인딩 되는 값은 함수의 호출 방식에 따라 동적으로 결정 되는데

일반 함수 호출
메서드 호출
생성자 함수 호출
Function.prototype.call/apply/bind 메서드에 의한 간접 호출

의 경우가 있다.

일반 함수 호출

function foo() {
  console.log(this); // window
  function bar() {
    console.log(this); // window
  }
}

다음과 같이 전역 함수는 물론이고, 중첩 함수를 일반 함수로 호출할 시, this에는 window or global 객체가 바인딩 된다. 일반 함수에서의 this 호출은 의미가 없는 행동이기 때문에, strict mode에서는 일반 함수 호출에 this는 undefined가 바인딩 된다.

메서드 호출

const person = {
  name: 'KimTaesu',
  getName() {
    return this.name;
  }
};

console.log(person.getName()); // KimTaesu

위와 같이 메서드 에서는 this가 메서드를 호출한 객체에 바인딩 되어, 위 코드에서의 this는 person object를 가르키게 된다. 해당 메서드가 해당 객체 내에서 선언된것이 아닌, 상속등을 통해 가져오더라도, this는 메서드를 호출한 객체를 바인딩된다.

생성자 함수 호출

const Circle(radius) {
  this.radius = radius;
  this.getDiameter = function () {
    return 2 * this.radius;
  };
}

const circle1 = new Circle(5);
const circle2 = new Circle(10);

console.log(circle1.getDiameter()); // 10
console.log(circle1.getDiameter()); // 20

위와같이 생성자 함수 내부의 this는 생성자 함수가 미래에 생성할 인스턴스가 바인딩 된다. new 연산자와 함께 호출하지 않으면 일반 함수로써 호출 되니, 주의하자. 그렇게 된다면 코드 내에서의 this는 다시 전역 객체(window, global)을 가르키게 된다.

Function.prototype.call/apply/bind 메서드에 의한 간접 호출

function getThisBinding() {
  return this;
}

const thisArg = { a: 1 };

console.log(getThisBinding());

console.log(getThisBinding.apply(thisArg)); // { a: 1}
console.log(getThisBinding.call(thisArg)); // { a: 1}

call/apply 메서드는 this로 사용할 객체와 인수 리스트를 인수로 전달받아 함수를 호출한다. call/apply 메서드의 본질적인 기능은 함수를 호출하는 것이다. apply와 call 메서드는 함수를 호출하면서, 첫 번째 인수로 전달한 특정 객체를 호출한 함수의 this에 바인딩 한다.

타 언어에서의 this

C / C++ 언어에도 this 키워드가 존재하며, 대부분의 객체 지향 언어에서는 this는 class가 만들게 될 instance를 가르키는 상수로써 사용 된다. python과 몇몇 언어의 경우 self 키워드를 사용하기도 하는데, 역할은 기본적으로 같다.

Javascript - V8

Mon, 28 Jun 2021 16:18:20 GMT

Javascript Engine

자바스크립트 엔진은 자바스크립트 코드를 실행하는 프로그램 / 인터프리터 이다. 자바스크립트의 엔진은 브라우저 뿐만 아니라, 다양한 곳에서 동작할 수 있는데, 대표적으로 Google의 V8엔진 MS의 Chakra엔진 Mozilla의 SpiderMonkey 등이 있다. 그중 Chrome, Node.js, Electron 등으로 유명한 V8엔진이 대표적이며, 이하 등장하는 모든 자바스크립트 엔진은 V8엔진을 기반으로 한 얘기가 될것이다.

V8

V8엔진은 Google이 개발한 오픈소스 엔진이며, C++언어로 작성 되었다. Just in time 컴파일러로써, 코드를 실행 시에 바이트코드와 같은 중간 코드를 생산하지 않고 컴퓨터의 언어인 머신코드로 컴파일 해 준다.

hidden class

자바스크립트의 객체는 프로퍼티 및 메서드의 수가 정해져 있지 않으며, 동적으로 추가되고 삭제되며 변형될 수 있다. 객체는 복합적인 자료 구조로써, 객체를 관리하는 방식이 원시값(number, string...) 과 비교해 복잡해 각 브라우저마다 다른데, Java, C++과 같은 class 기반 객체지향 언어에서는 미리 정의된 class를 기반으로 객체(즉 인스턴스)를 생성하며, 생성된 이후에는 class에 미리 정의된 내용과 다르게 변형할 수 없다. 그러나 자바스크립트는 클래스없이 객체를 생성할 수 있으며

const 객체 = {a: 1, b: 2 c: 'c'};

생성된 이후, 어느 때라도 프로퍼티와 메서드를 생성하거나 변형할 수 있다. 사용하기 편리하지만, class기반 언어의 객체에 접근하는것 보다 비용이 많이 든다. 이때문에 V8엔진은 hidden class라는 방식을 사용해 C++의 객체 접근 정도의 성능을 보장하는데, 비효율적인 객체의 탐색을 피하기 위해, 객체를 생성할 때 hidden class라는 객체를 만들어 각각의 객체에 대한 오프셋 정보를 저장한다. 히든 클래스는 다음과 같은 특징을 갖고 있다.

하나의 객체마다 부여된다
각각의 property에 대한 오프셋정보를 가진다
property가 추가및 수정,삭제 될 때 새로운 hidden class가 만들어 지며, 기존 hidden class는 참조해야하는 hidden class 정보가 추가된다.
```
let goyangyi = {};
```
다음과 같은 객체를 생성하는 순간 V8은 goyangyi에 대한 hidden class [A1]이 생겨난다. 이 때, [A1]은 아무런 정보도 가지고 있지 않다.
```
let goyangyi = {};
goyangyi.food = 'fish';
```
위와 같이 property를 생성하는 순간, hidden class[A2]가 생겨나며 goyangyi는 [A2]를 가르키게 된다. 이때 [A1]에는 food property를 추가하여 참조하는 hidden class가 A1에서 A2로 변경되었다는 정보가 추가 되는데 이를 transition이라 한다.
이러한 과정이 연쇄적으로 일어나면, 하나의 객체에 대한 hidden class cycle이 만들어지고 인스턴스가 새로 생성될 때 마다, 미리 정의된 hidden class cycle을 타고 올라가, 동일한 오프셋을 찾아 내 사용하게 된다. #### Inline caching

Javascript - 변수

Mon, 21 Jun 2021 13:34:16 GMT

변수의 선언문

ES6 이전의 javascript 변수 선언에는 유일하게 var 키워드 만을 사용할 수 있었으나, ES6(ECMAscript2015) 이후의 자바스크립트는 let과 const의 키워드를 추가적으로 갖게 됨
ES6등장 이후 변수 선언에서의 var는 권고되지 않고 있으며, 변수의 선언으로 let 상수의 선언으로 const를 사용하는 추세.

var

ES6이전 변수를 선언하던 방식인 var를 사용했을 때 대표적인 단점은 다음과 같다.

hoisting var키워드는 순차적으로 실행되는 자바스크립트 환경에서, 다음과 같이 예상치 못한 결과를 초래한다. var키워드는 자바스크립트가 돌아가는 런타임 이전에 실행되기 때문.
```
console.log(foo) //undefined
var foo = 'bar';
```
function level scope var키워드는 블록 단위를 가지는 다른 선언 키워드와는 다르게 함수 단위의 범위를 갖게 된다.
```
{
var bar = 'foo';
}
console.log(bar) //'foo'
```

값의 할당

let foo = 'bar';

다음과 같은 변수의 선언식은 두가지 동작을 연속적으로 하게 되며, 그 동작은 다음과 같다.
```js
let foo;
foo = 'bar';

let foo = 'bar'; 와 같은 동작을 수행할 때 자바스크립트는 식별자 foo의 메모리 공간을 먼저 확보 후, 해당값에 undefined를 할당하게 된다. 그 후, 'bar'를 재할당 하게 된다.

let bar;
console.log(bar) // undefined

변수에 어떠한 값을 할당하지 않는다 해도, 자바스크립트는 자동으로 해당 변수에 undefined를 할당한다.

값의 재 할당

자바스크립트에서의 변수에 데이터를 재할당 하는 작업은, 해당 메모리 공간을 지우고, 그 메모리 공간에 재할당 값을 저장하는 것이 아닌, 새로운 메모리 공간을 확보 후 그 메모리에 재할당하는 데이터를 기록후 식별자, 즉 변수의 이름을 새로 할당 해 준다.

가비지 콜렉터

위와 같이 값의 재할당이 일어날 때, 식별자(변수 이름)이 사라져 더이상 접근할 수 없는 데이터가 남게 되는데, 이 데이터의 경우 무한정 메모리에 쌓이는 것이 아닌 가비지 컬렉터 (garbage collector)에 의해 자동으로 메모리에서 해제 된다. 해당 가비지 컬렉터가 런타임의 어느 시점에 동작 하는지는 알 수 없다. 단순한 변수 뿐만 아니라, 외부에서 더이상 접근할 수 없게된 데이터는 모두 가비지 컬렉터에 의해 제거되어, 메모리 누수를 방지한다.

가비지 컬렉션은 엔진이 자동으로 수행하므로 개발자는 이를 억지로 실행하거나 막을 수 없다.
각 자바스크립트 엔진마다, 가비지 컬렉터의 알고리즘과 작동 방식이 상이하다.

코드스테이츠를 수료하며 느낀점

Tue, 09 Feb 2021 11:48:49 GMT

코드스테이츠 31주 웹개발 이머시브코스를 마치고..

2020/06 ~ 2021/02 횟수로 약 9개월간 코드스테이츠 이머시브코스를 진행하며 많은 어려움이 있었다. 첫 6월~10월 동안 9-6 알바를 다니며, 퇴근 후 밥을 대충 삼켜넣고 7시부터 10시까지 Pre 코스를 수강하였다. Pre 코스였기에 진행상의 큰 어려움은 없었지만, 아침부터 밤까지 이어지는 일상의 반복으로 지쳐갈때 쯤 Pre코스를 수료하고 Immersive코스로 넘어가게 되었다. Immersive코스는 개인적으로 9-6 풀타임으로 진행 해야겠다는 생각이 있었기에 아르바이트를 그만두게 되었고, 10월부터 2월까지는 9-6 혹은 9-12 코딩만 하는 일상으로 바뀌었다.

그러나 힘든 일정 와중에, 새로운것 또는 '우리가 기획한 것' 을 내 손으로 만들어가는 과정에 점점 더 큰 흥미를 느꼈고, 기대되는 스프린트 순서가 얼른 왔으면 하는 기대도 생겨나갔다! 해당 스프린트는 리액트였고 그 스프린트에 가장 큰 재미와 흥미를 느낀 지금은 프론트엔드 개발자를 희망하며 구직활동을 하고있다!

Immersive 코스

코드스테이츠의 모든 학습 내용 90% 같은 기수의 다른 수강생들과 페어프로그래밍 형태로 진행되며, 그 과정에서 협업하는 법 또는 소통하는 방법등 코딩 외의 사회생활의 중요한 부분들을 배울 수 있었다. 전혀 다른 배경과 다른 성별 다른 나이의 수강생과 대화를 나누며, 서로의 코드에 대해 서로에게 설명하면서 내가 작성한 코드를 나의 언어로 설명하는게 점점 익숙해져 갔다!

학습 내용은 전반적으로 Frontend 와 Backend의 전반적인 부분을 다루는 FullStack 과정으로 이루어져 있으며, AWS를 활용한 클라이언트, 서버 배포또한 다루고 있다. 때문에 서비스의 요람부터 무덤까지 전부 기획하여 탄생시킬 능력이 생겼으며, 내가 목표로하는 Frontend는 물론 Node.js와 Express를 기반으로 한 서버 지식까지 알아갈 수 있었다.

First / Final Project

코드스테이츠의 모든 과정이 끝나면 총 두번의 팀 프로젝트를 진행하게 된다. 수강생들끼리 4명씩 모여 프로젝트를 기획부터 배포까지 진행하게 되는데, First의 경우 약 2주, Final의 경우 약 4주동안의 기간동안 진행하게 된다.

사실 2주 프로젝트가 끝남과 동시에 4주 프로젝트를 진행하기 때문에 6~7주간의 힘든 과정이 시작된다. 그러나 해당 기간동안 가장 많은 배움을 얻을수 있었다고 생각한다! 코스에서 다루지않는 새로운 기술뿐 아니라, 팀 내 갈등과 협업, 프로젝트 진행 단계 등 공식문서 읽는 법 등, 프로그래밍 뿐만아니라 프로그래밍 이외의 많은 것들을 가져갈 수 있는 기간이다!

아쉬운 점

다른 부트캠프의 경우, 2달만에 취업, 혹은 전직을 시켜준다는 부트캠프의 광고를 본적이 있다. 사실 수료하고 나니 웹개발 이라는 직종 자체가 2달은 커녕, 코드스테이츠의 6개월 ~ 1년 코스로도 많이 부족하다는 생각이든다. 코딩도 물론 중요하지만 기본적인 CS지식이나 자료구조, 알고리즘 등.. 알아야할 지식이 많은게 사실이다.

또한 기업에서도 컴공과를 주로한 4년제 이공계열 졸업자와 정보처리기사를 우대하는 곳이 많으며, 이는 어쩔수 없다고 생각한다. 그들이 개발자가 되기위해 노력해온 것들과 들여온 시간들 또한 귀중하기 때문이다. 누군가는 전공자와 비전공자의 초봉과 처우가 다르다며 불평할 수 있겠지만, 나는 충분히 합당하다 생각하고 당연하겠지만 코드스테이츠의 과정을 듣는것 만으로는 그 갭을 완벽하게 메울수 없다고 생각한다.

*그럼에도 비전공자로써 웹개발에 도전하기로 마음 먹은이유는, 시작선은 다를지라도 취직 후 학위를 따고, 똑같이 자격증을 준비하면 충분히 간극을 좁힐 수 있는 직종이라고 생각했기 때문이다. *

근데 취업먼저 시켜주세요..

[Codestates] Final-Project 후기

Tue, 02 Feb 2021 15:13:38 GMT

Komma

코드스테이츠 Final project를 마치며..

2021/01/06 ~ 2021/02/02 약 4주동안 끊임없이 달려온 코드스테이츠 에서의 마지막 프로젝트가 끝났다. 지난 프로젝트 에서의 팀과 동일하게 진행하되, 좀 더 코드에 집중하고싶은 마음에 이번에는 팀장을 거절하고 팀원으로써 진행하게 되었다. 크게 달라지는것은 없었지만, 적어도 심적인 부담감 만은 조금이나마 덜 수 있었다! 프로젝트를 진행하며 조금 더 디테일있게 완성하고싶은 욕심이 강해 팀원들에게 많은 요구들을 했었는데, 싫은소리 없이 같이 진행해준 팀원들에게 항상 감사하다.

Komma,

Komma는 휴식, 공부, 또는 잠들기 전 언제나 사용할 수 있는 '백색소음' 청취가 가능한 사이트이다.

백색소음 우리 주변에서 들리는 백색음으로는 비 오는 소리, 폭포수 소리, 파도치는 소리, 시냇물 소리, 나뭇가지가 바람에 스치는 소리 등이 있답니다.

출처 네이버 백과

유저는 30개의 백색소음 중 적게는 1개부터 여러개의 소음을 유저가 마음대로 조합하여 청취할 수 있는 사이트 이다. 유저는 본인이 마음에드는 소음과 볼륨의 조합으로 한개의 믹스테잎을 만들어 저장해 두었다가, 언제든 본인이 필요할 시에 꺼내어 청취할 수 있다! 또한 원하는 시간에 종료되는 타이머 기능과, 청각과 함께 마음을 편안하게 해주는 컬러와 애니메이션 기능도 제공된다. 기본적으로 서비스는 비회원 유저도 이용할 수 있게 제작되었으며, 믹스테잎 추가 및 배경컬러 변경 등의 기능을 이용하기 위해서는 로그인이 필요하다.

공통적으로 Typescript로 제작되었으며, 클라이언트는 React Redux Sass, 서버는 TypeORM 등의 기술이 사용되었다.

본인은 이 프로젝트에서 클라이언트, 그 중에서도 메인페이지의 전체를 담당하였다.

프로젝트를 진행하며..

이번 프로젝트의 진행방식은 전에 경험했던 first project와 다르지 않았기에, 지난번 프로젝트의 경험과 다른점을 위주로 기록해 보려 한다.

Typescript
Redux
Sass
프로젝트를 진행하며 느낀 점

Typescript

이번 프로젝트에는 클라이언트, 서버 기본 공용언어로 타입스크립트를 사용하였다! 타입스크립트를 사용하며 느낀점은, ~~번거롭다~~ 특히 리덕스 관련 부분에서 타입에러가 많이 발생해 애를먹었다. 계속해서 타입에러를 내보내는 컴파일러가 원망스러웠지만, 타입스크립트 자체에서 미리 에러가 날만한 부분을 체크해서 예상치 못한 에러를 방지해주기 때문에, 결론적으로 수월한 진행에 도움이 되었다! 처음 인터페이스를 정의하고 하나하나 타입을 입력해 주는 과정은 번거롭지만, 후에 더 큰 에러를 방지해 주기 때문에 이제는 타입스크립트가 아니면 불편함을 느낄것 같다! 물론 좀 더 유연함이 필요할땐 상황에 맞게 자바스크립트가 강점이될 수 있다.

Redux

지난번 위아래로 오르락 내리락하던 State와 Prop를 감당할수 없었어서, 이번 프로젝트에서는 React 상태관리 라이브러리로 Redux 를 사용하기로 했다! 리덕스 역시, 기존 Class Component 또는 Function Component 방식의 일반적인 상태관리와 비교하면 굉장히 쉽게 상태를 변경하고, 상속해줄 수 있었다. 하지만 리덕스에서 상태와 그 상태를 핸들링하는 액션을 하나 만들어주기 위해 작성해야 하는 코드가 상당히 많은 편이였고, 이 또한 처음에는 '이게 맞나..?' 싶었다. 이 또한 작업이 계속되면서, 후반부에는 오히려 초반에 고생하길 잘했다는 생각이 들었다! State가 점점 늘어나며 Redux를 사용하지 않았다면 일어났을 일에대해 생각하기도 싫다.

Sass

Sass에 대해서는 고마운점도, 아쉬운점도 많다. CSS에 변수, 반복문, 배열 등등의 강력한 기능들을 더한 Sass를 이용하며 비주얼적으로 큰 부분을 차지했던, 주기적인 랜덤 배경컬러 생성이 가능했다. 해당 기능을 JS의 setInterval 로 구현하려했지만 이상하리만치 clearInterval 이 동작하지 않아 애를먹고 있었다.이 부분은 아직도 해결법을 모르겠다. 이때 Sass의 변수 및 list 기능을 사용하여 이 문제를 해결하였다!!
이 외에도 반복문등의 기능을 활용하였지만, CSS와 혼용 가능한 SCSS 문법을 활용한덕에, 그냥 일반적인 CSS문법의 활용이 많아져 많은 강력한 기능을 제대로 사용하지 못한 느낌이라 앞으로 더 공부해봐야겠다.

프로젝트를 진행하며 느낀 점

이번 Komma 프로젝트를 진행하면서, 메인페이지의 대부분의 기능들과 UI/UX를 적용했는데, 작업을 하면서 에러 핸들링과 사용자 피드백에 대해 많이 고민하며 작업하였다. 예를 들어 에러 핸들링 부분에서는 개발자의 의도대로 유저가 따라주지 않기 때문에 완벽히 작업했다 생각 하더라도, 유저가 예상치 못한 행동을 했을때 UI나 로직들이 무너져내리는 경우가 많았다! 이를 해결하기 위해 주변사람한테 이용하게도 시켜보고, 맥북, 22인치 모니터, 핸드폰, 아이패드 등 여러 기기를 돌아다니며 다양한 방면으로 테스트를 시도해 보았고, 에러를 최대한 막아낼 수 있었다!
또한 사용자 피드백에 관해서는, 프론트엔드 개발자가 되기 위해 항상 신경써야 할 디테일이라 생각되었다. 버튼 하나를 만들 때에도, 클릭 했을때의 스타일 변화를 주어 사용자로 하여금 내가 올바르게 클릭을 했구나 라는 인식을 하게 만들어 주어야 할것같았다. 그 외에도 요청 실패시 문구를 띄워주거나, 하다못해 alert 창이라도 띄워서 유저에게 '당신은 어떠한 행동을 하였고, 이래서 이 행동은 실패/성공 하였다' 라는 확신을 주게 만들어 주어야겠다고 생각하였고, 그대로 적용하였다.

기능 시연

음원 실행/종료 및 회전

믹스테잎 기능

설정

모바일

Komma

마지막으로 아침 9시부터 새벽 2시까지 거의 매일같이 컴퓨터앞에 앉아서 많은양을 소화하느라 육체적으로 정신적으로 많은 도전을 받았다.. 그럼에도 계속해서 작업을 하게되는 묘한 매력이 있는게 이 직업인것 같다.

[CodeStates] First-Project 후기

Tue, 05 Jan 2021 15:16:12 GMT

고독한 한끼

코드스테이츠 First-Project를 마치며...

2020/12/21 ~ 2021/01/05 까지 약 2주동안 4명이서 프로젝트를 진행 하였다.
얼떨결에 팀장역할을 맡게 되어서 전체적인 일정 관리와 의견을 종합해 의사결정을 진행하게 되었다.
사실 대단한 일을 한것도 아니였고, 팀원들이 도와주었기에 가능했지만 큰 불만없이
협조해 주어서 팀원들에게 고마운 마음이 든다!

고독한 한끼

고독한 한끼는 수많은 자취생 청년들의 한 끼를 책임지는 서비스로써
유저의 냉장고속에 잠들어있는 식재료들을 목록에서 선택하면 해당 식재료로 만들 수 있는 간단한
요리를 재미있게 소개해 주는 서비스이다.

유저는 로그인과 비로그인에 상관 없이, 원하는 재료를 선택하여 결과를 확인할 수 있고
회원가입과 로그인 절차를 마치면 결과로 나온 음식을 저장해둘 수 있으며,
마이페이지에서 해당 결과를 언제든 확인할 수 있고, 저장해둔 음식을 삭제하거나
간단하게 사용자이름, 비밀번호, 프로필사진 또한 변경할 수 있다!
Github를 통해 소셜로그인또한 가능하다.

클라이언트는 React.js, React-Router 등이 사용되었고, 서버는 Express.js, MySql 등이 사용되었다!

프로젝트를 진행하며..

지금부터는 아래의 주제로 프로젝트를 진행하며 겪었던 일이나 느낀점 등을 말해보려 한다.

SR 및 사전준비 진행
React 상태관리의 중요성
팀원과의 소통
배포와 마무리
후기

SR 및 사전준비 진행

혼돈의 브랜치 트리

처음 아이디어 회의를 진행하며 서비스를 정하고, 해당 서비스를 제작하는데 필요한 기술들과 약속들을 정하면서, 팀장인 내가 확실하게 짚고 넘어갔어야 하는 부분은 코드 컨벤션등.. 작업을 하며 우리가 지켜야할 약속등을 정하는 일이였는데, 결론적으로 그러지 못했다. 때문에 중반쯤 부터 깃을 통해 서로의 코드를 넘겨받는 과정에서 '그때 왜 확실히 하지 않았을까' 하는 후회가 밀려왔고, 해당 부분은 퍼포먼스 저하로 이어졌다고 생각한다. 정확한 커밋, 코드 컨벤션등을 확립해야만 2차적으로 밀려오는 하지 않아도 될 작업들을 방지할 수 있었고, 그것을 중요하게 생각하지 않은 나는 2칸, 4칸 으로 난립하는 들여쓰기와 코딩규칙 때문에 유쾌한 작업은 아니였다고 생각한다..!

초반 컨셉팅 및 와이어프레임 Figma 링크

아이디어를 처음으로 실체화 시키고, 비주얼화 하는 작업은 내가 맡았다. 유일하게 디자인 전공자기도 하며, 프론트엔드 담당자여서 떠맡기듯 하게 되었지만 ~~나는 2D디자인을 해본적이 없다.~~ 작업은 Figma를 이용하여 작업하였으며, 최대한 초기 컨셉팅과 비슷하게 하려 노력하며 진행하였다.

React 상태관리의 중요성

아,,,,,,,,.....

상태관리는 프론트엔드 포지션을 맡은 우리 두명에게 중요한 이슈였다. 사실 처음부터 Redux의 사용을 고려하였지만, 2주라는 짧은 시간덕에 익숙지않은 기술을 사용하기 꺼려져서 함께 고려했던 React Hooks와 둘다 사용하지 않고 순수 React만으로 작업하여 상태관리 기술의 필요성을 이한몸던져 몸소 체험하기로 하였다!

그것은 하면 안되는 짓이였다...

팀원과의 소통
팀원과의 소통 문제는 항상 예민하고 중요한 문제인것 같다. 프로젝트를 통해서 얼떨결에 넷의 의사결정을 하나로 모으는 역할을 하게 되었지만, 정작 본인포함 프론트엔드 작업자 둘의 합은 별로 좋지 못했다고 생각한다. 나는 보통 사람과의 트러블을 기피하는 경향이 있고, 만약 불합리한 경우에 있다 하더라도, 그 경우가 심하지 않으면 내가 참는 편이다. 이번 프로젝트간 프론트엔드 작업을 진행하며 그런 경우는 없었지만, 잠깐이나마 다른 한분의 책임감과 성실도에 대해 의문을 품었던 시간이 있었다. 작업량의 형평성에 있어서 불합리하다는 마음을 조금 갖게되었고, 한번 짜증을 내었던 적이 있었다. 팀원과의 마찰에 대해서는 내가 스트레스 받기 전에 자주 소통하며 의견을 주고받을수 있도록 해야겠다!

배포와 마무리

사랑해요 AWS

먼저 URL앞에 자물쇠를 달기 전까지 험난한 시련이 존재했고,
그 이후에는 https로 배포를 완료 해야만 코드 테스팅이 가능하게 만든 죄악을 저질렀다.
때문에 코딩 후 기능 테스트를 한번 진행해야 할때 마다, 혹은 오타 등등의 모든 수정이 들어갈 시 빠른 갱신을 위해 S3 --> CloudFront --> Route 53 을 차례로 내리고 다시 재배포하는데 엄청난 시간적 손해와 피곤함을 감당하였다.. 클라이언트 배포 또한 내가 진행하였기 때문에 한번의 테스트를 위해 엄청난 에너지를 쏟는 과오를 저질러버렸다..

후기
정말 말도안되는 실수와, 또는 나름의 선방쇼로 버무려져 결국은 시간안에 어떻게든 완성한 프로젝트였다. 짧은 시간안에 종종 직면하는 문제들을 해결하느라 유지보수가 용이한 코드보단, 당장 작동하는 코드를 짠 점이 가장 아쉽게 느껴진다. 위에서 기술한 이상한 짓들을 하느라 보낸 시간들은, 이후의 실수를 방지하기위한 끔찍한 신고식이라고 생각되지만, 시간의 압박속에서 내가 만들어내는 누더기 괴물을 보는것은 즐겁지 않았다.
이번 First-Project에서 느낀점을 양분삼아, Final-Project에서는 과감한 도전을 계획중이다! TypeScript Redux React-Hooks Sass의 사용을 팀 차원에서 생각중이지만 네개 전부 다 한꺼번에 새로운 기술을 사용하기는 쉽지않아 선택과 집중이 필요할것 같다! 아침부터 새벽까지 컴퓨터앞에 앉아서 주말과 휴일도 반납해가며 진행한 2주짜리 프로젝트의 결과는 아쉽지만, 느낀점과 얻어가는것 만큼은 많았던 시간 같다.

고독한 한끼

[TIL][Git] MacOS 업데이트 관련 Git 커맨드 오류 (xcrun error)

Sun, 20 Dec 2020 10:11:55 GMT

포트폴리오 작업 도중에

xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun

깃을 사용하려 하니 다음과 같은 에러가 발생한다... 검색 해 보니 MacOS 업데이트 관련 Xcode Command Line 오류라고 하는데, 나는 Xcode는 현재 설치하지 않았지만 바로 직전에 OS업데이트를 한게 원인인것 같다. 왜 업데이트 함부러 하지 말라고 하는지 알것만 같았다..

어찌 되었든 $ xcode-select --install 다음 명령어로 xcode cli를 설치해주면 문제가 해결된다!

편-안

[TIL][CodeStates] 마지막 Hiring-Assessment

Thu, 17 Dec 2020 14:25:28 GMT

마지막 HA

코드스테이츠 풀스택 웹개발과정 마지막 HA를 보게 되었다. 이번 HA는 클라이언트, 서버, DB를 구축하여 회원가입, 로그인, 로그아웃의 기능을 구현 해 내는 것이 목표였다!

코드를 공개할 수는 없지만, 서버단 에서는 세션을 사용한 인증을 구현하기 위하여 해당 설정들을 해줄 필요가 있었으며, 각각의 회원가입, 로그인, 마이페이지, 로그아웃 라우터 분기별로 클라이언트에 알맞은 데이터를 보내 줄 수 있어야 했으며, DB와도 연결되어 회원가입한 유저의 데이터를 저장하여 필요할 때 꺼내서 쓸수 있어야 했다!

해당 기능들은 MVC 디자인패턴 이론을 기반으로 제작되었으며, 쿠키와 세션을 사용하여 인증을 하기에 http통신의 헤더 설정에 신경을 써서 사전 공부를 했었다!

서버단에서 회원가입 기능을 구현할 때 MySQL DB안의 데이터를 가져오게 되는데, 이 부분에서의 sequelize 지식이 부족해 중복 email이 존재한다면 에러를 내보내고, 중복이 존재하지 않으면 새로운 정보들을 DB에 추가하여 회원가입을 완료하는 부분을 완료시키는데 조금 애를 먹었다. 이 부분은 다시한번 Sequelize 공식 문서를 천천히 찾아보아서 해결할 수 있었다!

클라이언트단에서 서버와의 통신에는 axios를 사용하였는데, 처음 서버와의 비동기통신을 배울 때에는 fetch를 선호 하였으나, node.js 환경에서의 비호환성과 지원하지 않는 구형 브라우저들이 있기 때문에, 뭔가 코스를 거듭하며 axios를 더 선호하게 되었다. 물론 fetch는 브라우저 내장 api이기 때문에 업데이트 대응에 더 발빠른점 등 여러가지 장단점이 있으니 더 많은 공부를 통해 적절한 사용처 등을 생각하여 사용해야 할것 같다!

후기

해당 기능을 구현한 후 기능구현 발표를 녹화하여 같이 제출해야 했는데, 이 부분에서 내가 이 부분의 코드를 왜 이렇게 작성했는지 등에 대해 좀더 구체적으로 생각하게 되었고 다른 사람에게 내가 의도한 바를 설명하는 작업이 아직 많이 낯설고 힘든 부분이라는 것을 깨닿게 되었다! 비단 코드를 잘 짜는것 뿐만 아니라 그 의도에 대해 설명하는 소통 또한 중요한 개발자의 덕목인것 같아서 많은 생각이 들게 하는 부분이였다.

다행히도 나는 1차 제출기한 내에 완료하여 통과 하였지만 하루동안 꼬박 붙잡고 있어서야 끝낼 수 있었고, 많은 생각이 들었다.. 이제 모든 스프린트가 끝났고 두번의 프로젝트 이후 수료를 하게 되지만 배우면 배울수록 이대로 괜찮은가 에 대한 생각이 들고, 부족함은 계속해서 발견하는 중이다..

[TIL][Deployment] AWS 이용한 서비스 배포

Tue, 15 Dec 2020 05:18:31 GMT

배포와 AWS

이제야 막 DB를 포함한 서버와 클라이언트의 관계를 이해하게된 나로써는 매우 생소한 개념이라 생각했다. 그러나 나는 지금껏 GitHub를 통한 호스팅 및 배포를 통해, 내가만든 공부의 결과물들을 개발자인 친구, 혹은 코드에 대하여 아무것도 모르는 친구들과 공유하고 있었으며, AWS를 이용한 배포 또한 과정만 복잡할 뿐, 한층 더 개발자로써 성장할 수 있는 기회라 생각하며 해당 내용을 정리 해 보았다.

나는 아마도, 전 우주상에서 가장 유명한 아마존 웹 서비스 AWS를 이용하여 클라이언트, 서버, DB의 배포에 대하여 공부하였다. 클라이언트의 배포에는 S3 서버에는 EC2 DB에는 RDS를 사용하였으며, 기본적인 개념에 대하여 정리하였다!

AWS S3

AWS S3의 풀 네임은 Simple Srorage Service S가 3개라고 하여 S3 이다.... S3는 '버킷' 이라는 단위의 데이터 저장소를 만들어 사용할 수 있으며 이 버킷에는 특정 데이터, 또는 클라이언트의 정적 빌드파일 등을 업로드하여, 서버가 필요 없을 수 있는 정적웹을 배포하여 사용할 수도 있다.

각 버킷은 최대 5TB의 저장공간을 가질 수 있으나 요금은 사용자가 실제로 사용한 만큼 과금된다고 한다. 이 서비스를 통해 서버가 필요없는 정적웹을 배포하여 사용할 수 있으나, 아래 기술할 서비스들과 함께라면 서버, DB또한 같이 사용하여 제대로된 웹앱 서비스를 배포할 수 있게된다!

AWS EC2

EC2는 사용자에 따른 맞춤형 가상 컴퓨팅 서비스인데, 사용자의 니즈에 따라 용량 및 CPU GPU 등의 프로세서, OS 또한 입맛에 맞게 가져갈 수 있다!

그러나 나는 현재 프리티어 계정 유저이기 때문에.. 폭넓게 선택할 수 있는 권한은 없고 가능한 선에서 해결 해야한다..!

EC2 서비스는 각각의 지역 (North East Asia지역에 서울도 있다.)에 있는 컴퓨터들을 임대하여, 원격으로 사용하는 것이라고 볼 수 있다. 이 서비스를 사용하여, 내 컴퓨터를 사용하여 서버를 계속 켜놓지 않아도, AWS의 컴퓨터를 원격으로 항시 켜 놓아서 서버를 돌릴 수 있게 된다.

AWS RDS

RDS는 SQL형태의 DB를 사용할 수 있는, DB특화 EC2라고 생각하면 쉽다!

아마존의 Aurora, PostgresSQL, MySQL, MariaDB, OracleSQL, MSSQL 총 여섯개의 데이터베이스 엔진을 지원하며 AWS Database Migration Service 를 이용하면, 기존 데이터베이스를 RDS로 손쉽게 마이그레이션할 수 있다!

사용 가능한 DB엔진의 종류는 6개지만, 무료 프리티어 계정인 관계로.. 과금이 되지않는 MySQL을 사용해야겠다..

위의 세가지 서비스와 별개로 Amazon Route 53 과 같은 서비스도 추가로 이용하여 원하는 도메인으로 리디렉션도 가능하다. 조만간 포트폴리오 정도는 도메인 구매와 더불어, AWS로 배포까지 해보려고 한다.

[CodeStates] Pair Programming - Pair Review 모음! (상시 업데이트)

Thu, 10 Dec 2020 16:41:16 GMT

CodeStates Pair Programming

코드스테이츠 Web FullStack 개발자 31주 과정을 진행하며, 미숙하지만 조금씩 이라도 성장하는 저의 과정을 기록하고자 그간 Pair Programming 과정간에 받은 Pair Review를 기록해 놓으려 합니다. 모두 좋은 평가는 받지 못하겠고, 저에게 평가를 해줄만한 가치를 느끼지 못하셔서든 여러 이유로 보내주시지 않은 분들도 계시겠지만! 저에대한 평가를 겸손하고 감사하게 받아들여 부족한 부분을 보완해 나가는 좋은 개발자가 되겠습니다! 저에대해 충고의 말씀 주신분들께 모두 감사드립니다! 🙇🙇

매회 세션 마다 2인 1조로 페어 프로그래밍으로 짝을 이루어 진행하며, 아래 내용은 각자 페어분께서 저와 페어 프로그래밍을 진행하신 후 작성해주신 저에대한 평가 입니다!

2020/12/02 ~ 2020/12/04 Imersive course__Database
잘한 점👍 페어 하시면서 여러 이야기를 들으셨을 것 같아요 저는 저 나름 느낀 부분을 이야기해볼게요! 첫째, 페어로 처음 만났음에도 불구하고 뭔지 모르겠지만..? 편안한 환경을 조성을 해주신거 같아요. 처음부터 끝까지 (뭐.. 마감 때문에 긴장의 끈은 놓지 않고 있었지만) 스프린트에 집중할 수 있었네요! 둘째, 제가 단점으로 어떤 문제가 잘 안 되면, 집착하면서 시간을 허비하는데, 희안하게 적절하게 저한테 먼저 뭐가 잘 안 되는지에 대해 물어봐주셔서 효율적(?)인 스프린트 시간이 되었던 거 같아요~ 셋째, 제가 부족해 모르는 질문을 여러 번 해도 그 때마다 대답을 친절하게 해 주셨어요.
개선할 점👎 흠.. 크게 이게 문제다!라는 부분을 느껴보진 못 했는데요, 제 관점으로 이것만 이렇게 해주셨으면 어떨까?라는 부분을 말씀드려볼게요. 그건 바로! 목소리!! 가 잘 안 들립니다! ㅎㅎ 목 상태가 안 좋으신건 아닌 거 같은데 목소리를 작게 내주셔서 여러 번 전달하는 내용이 안 들렸던 기억이 있어요! 별거 아니죠? ㅋㅋ 아무튼 짧은 기간이였지만, 태수님 덕분에 더 많이 배워간 시간이었습니다 :)) 앞으로도, 남은 기간 잘 헤쳐나가실길 바랍니답!!

2020/11/18 ~ 2020/11/23 Imersive course__React
잘한 점👍 리액트 스프린트 첫 시작 부터 어려움이였는데 태수님께서 알게 되고 적용한 방법을 태수님 만의 언어로 쉽게 알려주시려 했던 점이 그게 너무 잘 와닿았습니다. 실제로 잘 이해가 되어서 이제 해볼 수 있겠구나 라는 작은 불씨를 지펴주는 역할이 되어주셨습니다. 차분하게 하지만 핵심은 명확 간결하게 하시는 모습에서 협업을 잘 해내는 개발자의 모습이 보였습니다.
개선할 점👎 개선점은 다른 분들이 보더라도 찾기 어려울거 같습니다. 오늘 살짝 늦으셨던 부분만 제외하고는 이대로만 하신다면 좋은 개발자가 되실거 같아요. 정말 고생하셨습니다.

2020/11/09 ~ 2020/11/10 *Imersive course__Asynchronous & Promise *
잘한 점👍 태수님은 어떠한 문제를 풀이할 때 접근방법이 생각나지 않아도 포기하지않고 끈기있게 문제를 해결하려고 노력하는 모습이 인상깊었습니다.. 그로인해 이번 스프린트를 예정시간보다 일찍 끝낼 수 있어 개인시간을 가질 수 있었습니다. 그리고 코드 작성에 있어서 제가 의문을 가졌을 때, 이해가 잘 되도록 왜 이렇게 구현을 해야하는지 설명을 잘해주어서 이번 스프린트 시간이 유익했습니다.
개선할 점👎 이번 페어를 진행함에 있어서 개선할 점은 발견하지 못했습니다. 저도 이번 스프린트를 완벽히 이해하지는 못했지만, 복습을 통하여 본인의 것으로 만들어 봅시다 !

2020/11/02 ~ 2020/11/03 Imersive course__NQeens Algorithm
잘한 점👍 의사소통 잘해주시고, 같이 문제점 찾아가며 문제 해결에 집중해주셔서 저에게도 많이 도움되셨습니다! 코드도 작성하시면서 의도를 자세하게 설명해주셔서 의도 서로 정확하게 주고받아서 좋은 페어시간이었습니다!
개선할 점👎 마지막에 고생한 findQueens부분 진작에 왜 에러메세지를 따라가보지 못했을까 후회가 됩니다 ㅠㅠ 앞으로는 에러와 마주했을 때 에러메세지를 등한시 하지 않을 수 있을 것 같습니다.. 정말 최고 힘든 스프린트였지만 꼭 끝까지 완주해서 같이 수료하시면 좋겠어요! 화이팅!!

2020/07/06 ~ 2020/07/14 Pre course__JavaScript Basic Method
잘한 점👍 코플릿 문제로부터 도출한 코드가 잘 수행하는지 크롬 개발자도구를 적극적으로 코드검사를 수행하셨습니다. 또한 문제해결이 끝이 아니라 다른 방식으로도 코드를 작성해보는 노력을 계속 하셨고, 모르거나 헷갈리는 부분이 나오면 구글링을 통해 해답을 정확하고 빠르게 얻어와 정보를 함께 공유하려는 노력을 해주셨습니다.
개선할 점👎 아직 네비게이터와 드라이버의 역할수행에 서로가 익숙하지 않아 조금 더 커뮤니케이션을 원활히 했다면 하는 아쉬움이 남았습니다. 저와 페어분 모두, 역할분담으로 인한 역할수행에 대해 조금 더 고민하며 코스를 수강한다면 보다 더 바람직한 협업을 하는 개발자가 될 수 있을 것 같습니다.

2020/06/22 ~ 2020/07/04 Pre course__JavaScript Basic
잘한 점👍 페어 프로그래머의 의견을 존중해 주시면서 확실하지 않은 부분과 서로 해결해야 할 부분을 꼼꼼히 확인하는 부분이 인상적이었습니다. 좋은 커뮤니케이션 능력을 갖은 프로그래머로 성장하실 거 같습니다.
개선할 점👎 저도 그렇고 페어님께서도 아직 드라이버와 네비게이터로서의 역할을 명확히 인지하지는 못하고 있는 상황이었던거 같고, 아무래도 저희가 푸는 문제들도 첫 문제들이라 더 단순했어서 그랬던거 같은데 그 외에는 좋은 페어 프로그래밍 시간이었습니다!

[TIL][Authentication] HTTPS 프로토콜과 구현

Thu, 10 Dec 2020 15:17:23 GMT

인증에 대하여 공부하고있다

클라이언트와 서버를 가리지않고 중요하게 생각되는 인증에 대하여 공부하고 있다. 그 중요도가 높은 많큼 적지않게 어려움을 겪고있고 어렵게만 느껴진다..

하지만 대부분의 사이트가 가장 기본적인 인증인 로그인/로그아웃은 기본으로 갖고가고 있으며 클라이언트와 서버가 소통하는 중요한 통로이니, 좋은 프론트엔드 개발자가 되기 위하여 제쳐놓고 갈 수 없는 부분이라 생각해 아직은 전부 이해할수 없지만 그나마 머리속안을 휘젓고 돌아다니는 지식이라도 정리를 해놔야겠다!

HTTPS 프로토콜

HTTPS는 기본적으로 HTTP와 같은 프로토콜이며, HTTP와 동일한 기능에 보안(Secure) 기능을 추가한 업그레이드 버전이라 할 수 있다! HTTPS는 현대 웹에서 통상적으로 많이 사용하며, 보안 기능이 빠진 HTTP만을 사용하는 웹은 찾아보기 힘들다. 검색엔진최적화(Search Engine Optimization, SEO) 에서도 중요한데, 구글도 2014년 부터 보안의 중요성을 강조하며 HTTP를 사용하는 사이트보다 HTTPS를 사용하는 사이트에 점수를 더 주어 검색엔진에 노출이 잘 되게 하는 정책을 시행중이며, 크롬으로 HTTP사이트를 접속할 경우 경고메시지가 노출이 된다.

HTTPS의 특징은 인증서, CA, 비대칭 키 암호화 등이 있는데

인증서 (Certificate) 인증서의 경우 서버와 클라이언트를 오가는 reqest와 response에 올라가 날라가며, 해당 인증서에 기록되어있는 Domain을 비교해 제 3자로인한 도메인 변경등의 공격을 방지할 수 있다!
CA (Certificate Authority) CA는 인증서를 발급하는 공인기관이며, 해당 기관의 공인여부는 불변하지 않으며 각 브라우저(IE, Chrome 등..) 마다 각자 인증서를 발급한 CA가 다르다!
비대칭 키 암호화 (RSA) 비대칭 키 암호화는 A키로 특정 데이터를 암호화 한다면, A키의 페어인 B키로만 해당 데이터의 복호화가 가능하다! 해당 키중 하나는 클라이언트에 공개 해두고, 다른 하나는 서버에 숨겨놓는다! 이 방식은 매우 복잡한 알고리즘이기 때문에 모든 통신과정에서 사용되지 않는다.

로컬 환경에서의 HTTPS 서버 구현

로컬 환경에서의 HTTPS 적용은 mkcert라는 프로그램을 통해 인증서를 만들어 적용할 수 있다.

MacOs 기준으로 homebrew를 사용하여 설치할 수 있으며

$ brew install mkcert

아래 명령어를 통해 나의 로컬 환경을 인증된 발급기관으로 추가할 수 있다.

$ mkcert -install

이제 나의 로컬 환경이 발급기관이 되었으니, 인증서를 만들 수 있다. localhost 환경에 대하여 인증서를 만드는 명령어는 다음과 같다.

$ mkcert -key-file key.pem -cert-file cert.pem localhost 127.0.0.1 ::1

이제 위와 같이 cert.pem (인증서) key.pem (개인키) 두 파일이 지정한 디렉토리에 만들어 졌을텐데, 이 두가지를 사용하여 https 서버를 만들 수 있다! cert.pem 파일의 경우 인증서이기 때문에 노출되어도 상관 없지만, key.pem의 경우 비공개 개인키 이기 때문에 반드시 암호처럼 다루어야 한다. 때문에 git에 커밋하지 않게 조심하고, gitignore에 반드시 등록하도록 하자!!

HTTPS 서버 생성

node.js

const https = require('https'); //____ http 모듈 대신 https 모듈을 사용한다!!
const fs = require('fs');
https
  .createServer(
    {
      key: fs.readFileSync(__dirname + 'key.pem', 'utf-8'),
      cert: fs.readFileSync(__dirname + 'cert.pem', 'utf-8'),
    }, //____ fs모듈을 이용해 위에서 생성한 cert와 key를 불러온다!!
    function (req, res) {
      res.write('https 서버입니다!');
      res.end();
    }
  )
  .listen(3001);

express.js

const https = require('https');
const fs = require('fs');
const express = require('express');
const app = express();
https
  .createServer(
    {
      key: fs.readFileSync(__dirname + 'key.pem', 'utf-8'),
      cert: fs.readFileSync(__dirname + 'cert.pem', 'utf-8'),
    },
    app.use('/', (req, res) => {
      res.send('https 서버입니다! 근데 익스프레스지롱');
    }) //____ node.js 방식에서 https.createServer의 두번째 인자만 express의 미들웨어로 교체해주면 된다!!
  )
  .listen(3001);

각각 node.js와 express.js를 이용한 방식이며, 두 방식간의 차이는 거의 없다!

기존에 HTTP로 구축해 놓았던 서버를 HTTPS로 터널링 해주고싶다면 ngrok 이라는 프로그램을 이용하면 된다! 이 부분은 추후 배포를 배우고 직접 해보며 공부해 봐야겠다!

[TIL][Database] RDB 데이터베이스와 NoSQL 데이터베이스 & MySQL

Sun, 06 Dec 2020 11:26:34 GMT

RDB와 NoSQL

데이터베이스는 크게 RDB(Relational DataBase)와 NoSQL(non SQL or non Relational) 로 나눌 수 있다. RDB는 MySQL, Oracle SQL, PostgreSQL 등이 주로 많이 쓰이며 NoSQL 진영의 경우 Couch DB, Mongo DB 등이 있다!

RDB의 경우 우리가 흔히 이용했던 스프레드 시트와 같다고 할 수 있다! 다수의 테이블(시트)와 그 안의 필드들로 이루어진 row와 column형식의 데이터 베이스 이며 SQL(Structured Query Language)를 사용하여 스키마를 작성하게 된다. 반면 NoSQL의 경우 각 테이블간의 관계가 없으며, 트리구조에 가까운 형태이다!

MySQL

나는 이 중에서 RDB 진영의 MySQL에 대하여 공부하였다. 처음 SQL언어를 접하고, 또 다시 새로운 언어와 문법을 배운다는 생각에 겁을먹고 어려움을 겪었다.. 하지만 언어의 문법 자체가 JS와 비교해서 더욱 사람의 언어와 같은 형태였고 공부를 조금 하게되니 기본적인 CRUD를 실행할 수 있는 수준이 되었다! (물론 w3school을 참고하며)

다만 내가 MySQL에 대하여 크게 어려움을 느낀 부분은 기본 셋팅 부분이였다. Homebrew를 통한 MySQL 설치와 특히 root계정의 password 설정에 있어서 큰 고난이 있었다.. MySQL을 완전히 지워버린 후 재설치 하는 방식으로 해결 하였다. 프론트엔드 개발자로써 SQL을 주로 사용하게되진 않겠지만, 이런 경험을 잊지말고 각종 툴 등의 설치 및 관리를 CLI를 통해 잘 해결할 수 있는 계기가 되었으면 좋겠다!

[TIL]React + TypeScript 개인 포트폴리오 제작

Tue, 01 Dec 2020 16:06:23 GMT

포트폴리오 만들기

React와 Typescript를 사용하여 개인 포트폴리오를 만들었다. JSX조차 100% 완벽하다고 말할 수 없는 상황에서 큰 도전이였다... 결과적으로 타입스크립트가 제공하는 모든 강력한 기술들을 사용하여 타입스크립트의 능력을 100%로 활용하여 제작지는 못하였다. 어쨋건 TSX 문법에 발을 들였으니, 도중에 그만두고 포기하고 싶지는 않았다!

어떻게 하던 말도안되는 오류가 아니면 유기적으로 작동은 하는 JS에 비하여, 사사건건 내 발목을 잡고 한번 TS관련 오류가 발생하면 CSS작업 확인조차 못하게 렌더링조차 안시켜주기 때문에 내가 내손으로 채운 족쇄 같았다..

그때문에 어떻게 해서라도 해결할 수 밖에 없었고, 그 과정에서 미약하게나마 타입스크립트의 접근제한자, interface type 같은 개념을 공부할 수 밖에 없었다

완벽하지않은 React와 맛만봤던 수준이였던 Typescript 그리고 그간 등한시 했던 CSS의 온갖게 뒤섞여 혼란 그 자체였다!!!

2일간 하루종일 탐구하고 작업한 결과인데, 이제보니 별 기능은 없지만 2일간의 과정을 뒤돌아보니 내 자신이 뿌듯하다!

포트폴리오 공간

가장 중요한 센터 부분은 앞으로 만들어질 작업물들이 올라갈 수 있도록 제작 후, 좌/우 클릭으로 다음 작업물을 볼 수 있도록 구현하였다. 앞으로 이 부분에 들어가게 될 작업물들을 만드는게 가장 중요할것 같다! 좌, 우 전환 구역 진입시 커서 또한 화살표로 바뀌어 클릭을 유도하였다.

스크롤 바

올라와있는 총 작업물의 갯수에서 현재 몇번째 작업물을 보고 있는지 확인할 수 있도록 표현하였다. 작업물의 총 갯수와, 현재 몇번째 작업물에 있는지를 state로 관리하여 위의 작업물의 사진과 같이 유기적으로 움직이게 작업하였다! 굉장히 별거 없고 간단해 보이지만 나에게 있어서는 꽤나 생각을 하게했던 부분이였다.

사이드 바

클릭 시 사이드바 화면이 나오도록 하였다. 이곳에는 간략한 자기 소개를 작성하였다.

반성

아직 구조 면에서 완벽하지 않으며, 생각 했던 기능들이 많이 구현되지 않은 미완성이다. CSS역시 일단 되게하자는 생각으로 한곳에서 터지면 일단 막고보는 카드 돌려막기식 작업을 하였다... 이 부분은 구조부터 매끄럽지 않아 추후에 리팩토링을 해야 할것같다. 힘들지만 재미있어서 시간가는줄 모르고 작업하며 많은것을 배웠다!!

https://kimts2627.github.io/portfolio/ https://kimts2627.github.io/portfolio/ https://kimts2627.github.io/portfolio/ https://kimts2627.github.io/portfolio/

[TIL] ToDo App

Fri, 27 Nov 2020 14:26:27 GMT

그동안 익혀왔던 JS 및 React를 이용하여..

매우매우 간단한 투두앱을 만들어 봤다.. 리액트를 배웠다면 투두리스트 정도는 한번쯤 만들어 봐야 한다고 어디서 들어서 그런지 꼭 해봐야 할것 같았다.

기본적으로 Redux나 Hook를 사용하지 않은 class component 기반의 React로 만들었으며, 사실 크게 어려운 부분은 없었다.

의외로 가장 시간을 잡아먹은 복병은 CSS였다...

최적화 문제..

문제가 하나 생겼다. 기본적으로 Mac OS의 바로 전 버전인 Catalina 배경 화면을 이용하였는데 큰 사이즈의 파일을 그대로 이용하다 보니 로딩이 엄청나게 느려졌다.

최종

문제 해결은 간단하게 이미지를 재압축 시켜서 다시 넣었다. 하지만 내 컴퓨터 문제인지 아직도 용량이 너무 큰것인지 다크모드로 변경할 때 이전보다 좋아졌지만 여전히 느린게 느껴졌다...

후기

다 만들었다고 생각 하니 작성 후 input 내에 value를 초기화 하지 않은것, 기본적인 CRUD 구현을 목표로 만들었으나 잡다한 CSS에 심취해 Update 와 Delete 기능을 까먹은것. 등이 보였다.. CSS를 작성 할때마다 계속해서 찾아가면서 하다 보니 정작 중요한 기능 구현에 있어서 잊어먹은것 등이 많이 보였다..

그리고 2D 디자인 쪽은 아니였으나, 나름 디자인전공 이였다는게 무색하게, 레이아웃 배치와 구성을 이쁘게 짜는데 있어서 큰 어려움을 겪었다.. 물론 내 생각대로 되지 않으니 중간중간 타협또한 했었다.

또한 모바일에서 와이드모니터 까지의 화면 대응에 있어서 충분하게 동적 웹앱을 구축하지 못했다는 생각도 들어 조만간 수정을 봐야할것 같다...

gh-pages 라이브러리를 활용하여 깃헙 레포지토리를 통해 간단하게 호스팅 해 놓았다. 마음껏 욕해주세요... https://kimts2627.github.io/todo_list/

[TIL][Git] Github로 무료 호스팅 하기 & 리액트 작업 무료 호스팅 하기

Fri, 27 Nov 2020 07:05:14 GMT

Github로 무료 호스팅 하기

이 방법을 알게된지는 꽤 오래되었지만, 아마 나와같은 초보 개발자들은 아직 모르는 사람이 많다고 생각하여 혹시 누군가 이 글을 보게된다면 조금이나마 도움이 될 수 있도록 깃헙으로 무료 호스팅 하는법을 적어보려 한다!

이 방법을 찾게 된 계기는 내가 한 작업물을 친구들 및 주변사람들에게 자랑하고 싶은 욕구에서 시작되었다... 많지않은 돈을 내고 구입하여 사용할 수 있지만, 아직은 초보 개발자로써 무료로 자신만의 홈페이지 또는 포트폴리오 사이트를 제작하는데 이만한 방법이 없을것 같다. 또한 아직 제한은 모르지만 계속해서 만들어본 결과 딱히 갯수제한은 없는듯 하다!

먼저 호스팅 하길 원하는 프로젝트의 레포에 들어간 후 상단의 셋팅을 누른다!

*셋팅 페이지로 들어온 후 가장 아래로 내리면 깃헙 페이지라는 탭이 존재하는데, 이 탭이 무료 호스팅을 도와준다! *

None 부분을 클릭하면 다음과 같이 원하는 branch를 선택 할 수 있게 나온다. 선택 후 옆의 Save를 클릭 해 주면 된다. 이번에는 master 브랜치로 적용해 보겠다.

Save를 클릭 해주면 적용된 후 페이지가 새로고침 되는데, 다시 아래로 내려가 보면 다음과 같이 https://{깃헙아이디}.github.io/{레포이름}/ 의 형태로 사이트가 만들어졌다!

해당 링크를 통해 들어가면 짜잔. 이제 친구들에게 사이트 주소를 주는것 만으로도 마음껏 자랑할 수 있다!!!!!!!!

참고로 해당 사이트가 보여주는 파일은

1순위가 index.html 파일
2순위가 readme 파일이다!

그러니 반드시 아래와 같이 최상단 디렉토리에 index 라는 이름으로 메인 html파일이 존재해야 가능하다! 그리고, 레포지토리를 반드시 퍼블릭으로 생성해야 한다!

리액트 프로젝트 호스팅하기!!

그렇다면 리액트로 제작된 프로젝트를 같은방법을 사용할 수 있을까..? index.html 파일이 가장 최상단 디렉토리에 존재해야 하니 힘들다고 생각한다.

이는 gh-pages 라는 라이브러리를 사용하면 가능하다! https://www.npmjs.com/package/gh-pages

. . .

일단 이전과정과 동일하되 index.html 부분을 신경쓰지 말고 진행한다!

그 후 해당 프로젝트 디렉토리에 들어간 후 npm install gh-pages 를 통해 라이브러리를 인스톨한다!

그 후 위와 같이 package.json 파일의 script에 "predeploy": "react-scripts build" "deploy": "gh-pages -d build" 이 두가지 스크립트 명령어를 적는다! 그리고 가장 하단에 hompage 설정을 만든 후, 자신이 방금 만든 사이트 주소를 적는다!

그 이후 프로젝트 내 에서 deploy 스크립트를 실행시키면 자신의 깃헙 레포지토리에 gh-pages 라는 브랜치가 생성된다!! (로컬 git에는 없다) 이제 다시 셋팅 페이지로 간 후, 아래와 같이 사이트를 만들 브랜치를 gh-pages 브랜치로 변경 해 주면 된다!

얌얌굿.

위와같은 방법을 이용해 몇달 전부터 주변에 자랑질을 시전하고 있었다! 물론 서버및 DB 적용은 힘들다는 점..

트위틀러 앱 https://kimts2627.github.io/twittler/

리액트 투두 앱 https://kimts2627.github.io/todo_list/