lire_eruel.log

HTML과 소개팅하기

Sat, 26 Aug 2023 06:43:34 GMT

이 글은 body을 처음 배우는 사람을 위한 글 입니다. 쉬운 이해를 위해 JAVA에 비유해서 설명을 할 예정입니다. 앞으로 【자유법】은 자바식 비유라고 생각해주세요.

HTML이란?

HTML HyperText Markup Language의 약자로, 마크업 언어입니다. 웹 페이지의 구조와 콘텐츠를 정의하는데 사용되며, 웹 페이지를 브라우저에서 표시할 때 사용됩니다. 웹 페이지에 있는 텍스트, 이미지, 링크, 비디오 등의 요소를 구조화하고 레이아웃을 정의합니다.

코드로 먼저 봅시다.

HTML 코드

 //전 HTML입니다
 // 【자유법】class 파일의 최 상단 class 선언하고 감싸는 부분
 // 【자유법】import 처럼 문서 상단에 필요한 것들을 정의하는 부분
    
    
    Document // 브라우저의 상단바에 나올 이름

 // 실제 화면에 보이는 부분【자유법】 메인 메소드
     제목입니다.

실제 코드에 저런식으로 주석하면 안됩니다!! 보기 쉽게 적어놓았습니다. 주석은 조금 뒤에 알려드릴게요! 지금 이해할 필요 없어요. 밑에 자세한 설명이 있으니까요!

태그 사용법

1. 태그는 정해진 태그를 사용합니다. Java처럼 마음대로 선언하면 안돼요.

// good!
 나는 anchor 태그야. 
// error! (아무것도 보이지 않아요!)
 나는 ssafy야.

~~사실 커스텀 태그를 만들 수 있긴 합니다.~~

2. 태그 공통 문법

닫는 태그는 앞부분이

<여는 태그> 내용

ex)

 h4는 제목 태그 중 하나에요.

결과

h4는 제목 태그 중 하나에요.

3. 주석달기

```

     알고리즘은 역시 일구리즘이지
    

```

결과

알고리즘은 역시 일구리즘이지

아 좀 그런가..? 라는 텍스트는 보이지 않네요! " 를 사용하면 주석을 추가할 수 있습니다.

태그 종류를 다 알아봐야할까?

HTML의 태그는 종류가 어마무시하게 많습니다...! 이걸 전부 다 알려고 하는 것은 비효율적이죠. W3S에서 어떤 태그들이 있는지 구경하세요!

그렇다면 자주 쓰이는 것들만 알아도 중간은 가겠죠?

Advanced Web Ranking의 조사 결과를 한번 봅시다.

아래 그래프는 하나의 웹페이지에서 사용된 태그 종류의 합을 나타낸 것입니다. 생각보다 많지는 않죠? 32개가 가장 많네요 아래는 태그가 많이 사용되는 순위입니다.

가장 많이 쓰이는 태그 알아보기<<- 이 곳에 들어가서 한 번 훑어봅시다.

개발 환경 추천(window)

우선 VSCode를 설치해줍시다. 좌측에 아래 이모티콘같이 생긴 것을 눌러주세요.

꼭 다 설치해야하나요? << 아닙니다 하지만 우리 프린이 여러분들은 그냥 시키는대로 따라오세요.

이제 html을 검색해서 아래 HTML CSS Support 설치

live Server 설치

CSS Peek

시작하기

VSCode 실행 후 폴더 지정해서 열어주세요.

폴더에 마우스 커서를 가져다 대면 이런 메뉴가 보입니다. 제일 왼쪽 클릭해주세요.

이 상태에서 hello.html 입력 후 엔터

이 상황에서 html 입력해주세요. 그럼 아래처럼 무언가 뜰텐데 두번째 html:5 선택

그럼 짠! HTML 문서의 기본 틀 완성!

이제 ALT를 누른 상태에서 L과 O를 눌러주세요. 그럼 기본 브라우저로 새로운 창이 열립니다! 혹시 잘 안된다면 html문서를 우클릭 한 후 ! open in live server를 클릭해주세요.

그럼 이렇게 결과가 짠!

이제 title도 변경해보고 body에도 요소들을 추가해보면서 html을 다뤄봐요!

[TIL] Array vs Linked List

Mon, 24 Jul 2023 15:43:09 GMT

Array

Array란?

Array는 프로그래밍에서 일련의 요소들을 순차적으로 저장하는 데이터 구조입니다. 이러한 요소들은 같은 데이터 타입을 가지며, 각 요소는 배열 안에서 인덱스(index)라고 불리는 숫자로 접근할 수 있습니다. 인덱스는 보통 0부터 시작하여 배열의 크기보다 하나 작은 값을 가집니다.

예를 들어, 5개의 정수를 저장하는 배열은 다음과 같이 표현할 수 있습니다:

[10, 20, 30, 40, 50]

Array 장점

요소에 빠르게 접근할 수 있다.

가장 기본적인 자료구조인 Array는 논리적 저장 순서와 물리적 저장 순서가 일치한다. 따라서 인덱스로 해당 원소에 Big-O(1)에 해당 원소로 접근할 수 있다. 즉 random access가 가능하다.

Array 단점

삽입이나 삭제가 비효율적이다.

삽입 또는 삭제 과정에서는 해당 원소에 접근하여 작업을 완료한 뒤(O(1)), 또 한 가지의 작업을 추가적으로 해줘야 하기 때문에, 시간이 더 걸린다. 만약 삭제라고 한다면, 중간에 원소를 삭제하고 그 뒤부터 요소들을 shift해줘야 하기 때문에 시간 복잡도는 O(n)이 된다. 삽입 또한 마찬가지 이다.

크기가 고정적이다.

Array는 생성할 때 크기를 지정하고 이후에 크기를 동적으로 변경할 수 없습니다. 만약 배열의 크기를 초과하여 데이터를 추가하려면, 새로운 배열을 생성하고 기존의 데이터를 복사해야 합니다. 이로 인해 삽입과 삭제가 비효율적이며, 크기를 자주 변경해야 하는 경우에는 다른 자료구조를 고려해야 합니다.

Linked List

Linked List(연결 리스트)는 배열의 삽입과 삭제가 비효율적인 문제를 해결하기 위한 자료구조입니다. Linked List는 각 노드(Node)들이 데이터와 다음 노드를 가리키는 포인터(주소)로 구성됩니다. 각 노드들이 연결되어 있기 때문에 순차적으로 데이터를 저장하지 않고, 논리적으로 연결되어 있는 형태로 데이터를 관리합니다.

Linked List 장점

삽입이나 삭제가 빠르다.

각각의 원소들은 자기 자신 다음에 어떤 원소인지만을 기억하고 있다. 삽입이나 삭제를 할 때 해당 부분만 다른 값으로 변경하면 되기 때문에 삽입과 삭제를 O(1)만에 해결할 수 있다.

동적 크기

배열과 달리 동적으로 크기를 조정할 수 있습니다. 필요에 따라 노드를 추가하거나 제거할 수 있습니다.

Linked List 단점

결국 삽입이나 삭제가 O(n)시간이 필요하다.

원하는 위치에 삽입을 하고자 하면 원하는 위치를 Search 과정에 있어서 첫번째 원소부터 다 확인해봐야 한다는 것이다. Array 와는 달리 논리적 저장 순서와 물리적 저장 순서가 일치하지 않기 때문이다. 이것은 일단 삽입하고 정렬하는 것과 마찬가지이다. 이 과정 때문에, 어떠한 원소를 삭제 또는 추가하고자 했을 때, 그 원소를 찾기 위해서 O(n)의 시간이 추가적으로 발생하게 된다.

Linked List의 종류

단일 연결 리스트 (Singly Linked List)

단일 연결 리스트는 각 노드가 데이터와 다음 노드를 가리키는 하나의 포인터로 구성됩니다. 리스트의 시작 노드를 가리키는 특별한 포인터인 헤드(Head)가 있으며, 리스트의 끝은 NULL로 표시됩니다.

이중 연결 리스트 (Doubly Linked List)

이중 연결 리스트는 단일 연결 리스트와 비슷하지만, 각 노드가 데이터와 이전 노드와 다음 노드를 가리키는 두 개의 포인터로 구성됩니다. 이전 노드를 가리키는 포인터를 추가함으로써, 뒤에서부터도 리스트를 순회할 수 있습니다. 이중 연결 리스트는 메모리 공간을 더 많이 사용한다는 단점이 있습니다.

원형 연결 리스트 (Circular Linked List)

원형 연결 리스트는 단일 연결 리스트와 유사하지만, 마지막 노드가 첫 번째 노드를 가리키게 됩니다. 이렇게 함으로써, 끝과 시작이 연결되어 순환하는 구조가 됩니다. 원형 연결 리스트는 특정 작업을 순환적으로 처리해야 할 때 유용합니다.

언제 Array와 Linked List를 사용할까?

Array

데이터의 크기가 미리 정해져 있고, 빠른 인덱스 접근이 필요한 경우에 적합합니다.

Linked List

데이터의 크기가 동적으로 변경되거나 삽입과 삭제가 빈번한 경우에 적합합니다. 또한 메모리 사용에 유연성이 필요한 경우에도 유용합니다.

[TIL] TDD, 함수형 프로그래밍

Wed, 19 Jul 2023 13:50:46 GMT

TDD

TDD란 무엇인가?

TDD란 Test Driven Development의 줄임말로 '테스트 주도 개발'이라고 한다. 테스트 주도 개발은 설계 이후 코드 개발 및 테스트 케이스를 작성하는 기존의 개발 프로세스와 다르게 테스트케이스를 작성 한 후 실제 코드를 개발하여 리펙토링하는 절차를 따른다.

TDD의 장점

1. 함수 리팩토링이 쉬워진다.

코드 양이 많아진 상황에서는 좋은 코드를 작성할 때 고려해야하는 요소를 모두 지키며 작성하기 쉽지 않다. 하지만 테스트 주도 개발을 통해 개발을 하면 뚱뚱해진 함수를 여러 함수로 나누는 과정에서 해당 기능이 오작동을 일으킬 수 있지만 간단히 테스트를 돌려봄으로써 이에 대한 안심을 하고 계속해서 리팩토링을 진행할 수 있다. 결과적으로 리팩토링 속도도 빨라지고 코드의 퀄리티가 좋아진다.

2. 요구사항에 더욱 집중 할 수 있다.

새로운 기능을 추가하기 전 테스트를 먼저 작성한다. 이 를 위해서는 개발자는 해당 기능의 요구사항과 명세를 분명히 이해하고 있어야 한다. 이는 사용자 케이스와 사용자 스토리 등으로 이해할 수 있으며, 개발자가 코드 작성 전에 요구사항에 더욱 집중할 수 있도록 도와준다.

TDD의 단점

1. 느린 생산성

기존 코드에 테스트코드까지 작성해야 해서 필요한 코드의 양이 늘어난다. 코드의 퀄리티보다는 빠른 생산성이 요구되는 시점에서 TDD는 추천하지 않는다.

2. 진입 장벽

어떠한 부분을 어떻게 테스트해야하는지 등 여러 부분에 대한 학습이 필요하고 익숙해져야 한다. 또한 팀 전체가 익숙해져야 하므로 진입 장벽이 높다.

함수형 프로그래밍

함수형 프로그래밍이란?

Functional Programming is programming without assignment satements _함수형 프로그래밍은 대입문이 없는 프로그래밍이다. _ _ -Rober C.Martin(클린 코드 저자)- _

함수형 프로그래밍은 거의 모든 것을 순수 함수로 나누어 문제를 해결하는 기법으로, 작은 문제를 해결하기 위한 함수를 작성하여 가독성을 높이고 유지보수를 용이하게 해준다.

immutable vs mutable

immutable

immutable 객체는 객체가 가지고 있는 값을 변경할 수 없는 객체를 의미한다. 값이 변경될 경우, 새로운 객체를 생성하고 변경된 값을 주입하여 반환해야 한다.

mutable

mutable 객체는 해당 객체의 값이 변경될 경우 값을 변경한다.

일급 객체 (first-class citizen)

일급 객체란?

변수나 데이터 구조 안에 함수를 담을 수 있어서 함수의 파라미터로 전달할 수 있고, 함수의 반환값으로 사용할 수 있다.
할당에 사용된 이름과 관계없이 고유한 구별이 가능하다.
함수를 리터럴로 바로 정의할 수 있다.

함수형 프로그래밍에서 함수(function)는 일급 객체로 간주된다.

[TIL] OOP, Restful API

Tue, 18 Jul 2023 13:26:30 GMT

객체 지향 프로그래밍

객체 지향 프로그래밍의 장점

이미 작성한 코드에 대한 재사용성이 높다.
객체 단위로 코드가 나눠져 작성되기 때문에 디버깅이 쉽고 유지보수에 용이하다.
데이터 모델링을 할 때 객체와 매필하는 것이 수월하기 때문에 요구사항을 보다 명확하게 파악하여 프로그래밍 할 수 있다.

객체 지향적 설계 원칙

SRP(Single Resposibility Principle) : 단일 책임 원칙
- 클래스는 단 하나의 책임을 가져야 하며 클래스를 변경하는 이유는 단 하나의 이유여야 한다.
OCP(Open-Closed Principle) : 개방-폐쇄 원칙 확장에는 열려 있어야 하고 변경에는 닫혀 있어야 한다.
LSP(Liskov Substitution Principle) : 리스코프 치환 원칙 상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다.
ISP(Interface Segregation Principle) : 인터페이스 분리 원칙 인터페이스는 그 인터페이스를 사용하는 클라이언트를 기준으로 분리해야 한다.
DIP(Dependency Inversion Principle) : 의존 역전 원칙 고수준 모듈은 저수준 모듈의 구현에 의존해서는 안된다.

Restful API

Restful API란?

REST란 , REpresentational State Transfer 의 약자이다. REST에서 "Representational State"는 자원의 상태를 표현하는 것을 의미한다. 시스템의 리소스를 표현하는데 사용되는 표현은 클라이언트와 서버 간에 주고받는 데이터 형식이다. 주로 JSON 혹은 XML 형태의 데이터를 사용한다.

"Transfer"는 클라이언트와 서버 간의 데이터 전송을 의미한다. REST는 HTTP 프로토콜을 기반으로 하며, 클라이언트는 HTTP 메소드(GET, POST, PUT, DELETE 등)를 사용하여 서버의 리소스를 조작하고 요청한다.

따라서, REST는 웹 시스템에서 클라이언트와 서버 간의 상호작용을 위한 아키텍처 스타일로서, 자원의 표현과 상태 전송을 중심으로 하는 웹 API 디자인을 의미한다.

REST 6가지 원칙

Uniform Interface (일관된 인터페이스)

클라이언트와 서버 간의 통신을 위한 인터페이스가 일관성 있게 설계되어야 한다.
- 리소스 식별, 리소스 조작을 위한 통일된 방식을 사용하고, 메시지 형식 및 프로토콜도 통일된 규칙을 따라야 함
  Stateless
클라이언트와 서버 간의 세션 상태를 서버에 저장하지 않고, 각 요청이 독립적으로 처리되도록 설계되어야 한다. 클라이언트는 필요한 모든 정보를 요청에 포함시켜야 하며, 서버는 각 요청을 별개의 요청으로 이해하고 처리한다. -> 서버의 확장성과 재사용성이 향상됨.
Caching
서버 응답을 클라이언트나 중간 서버에서 캐시로 저장하여, 동일한 요청이 반복될 때 캐시된 응답을 사용함으로써 네트워크 대역폭을 절약하고 응답 시간을 단축시킨다.
Client-Server
RESTful API는 클라이언트와 서버 간의 엄격한 역할 분리를 한다. 서로의 역할을 엄격히 분리하여 서버와 클라이언트 간의 상호작용이 단순하도록 한다.
Hierarchical System
계층 구조를 가진다. 클라이언트는 리소스에 대한 직접적인 접근만 가능하며, 중간 서버는 인증, 보안, 로드 밸런싱 등의 기능을 담당한다. -> 시스템의 확장성과 유연성을 높인다.
Code on demand
필요에 따라 서버로부터 실행 가능한 코드를 클라이언트에게 전달할 수 있는 옵션을 제공 -> 웹 브라우저에서 JavaScript 코드를 다운로드하고 실행하는 방식

REST API 장점

Open API 를 제공하기 쉽다
멀티플랫폼 지원 및 연동이 용이하다.
원하는 타입으로 데이터를 주고 받을 수 있다.
기존 웹 인프라(HTTP)를 그대로 사용할 수 있다.

REST API 단점

사용할 수 있는 메소드가 한정적이다.
분산환경에는 부적합하다.
HTTP 통신 모델에 대해서만 지원한다.

[TIL] 그리디 알고리즘

Fri, 23 Jun 2023 06:43:12 GMT

그리디 알고리즘

현재 상황에서 지금 당장 좋은 것만 고르는 방법

특징

매 순간 가장 좋아 보이는 것을 선택
현재의 선택이 나중에 미칠 영향은 고려하지 않음.
사전에 외우고 있지 않아도 풀 수 있을 가능성이 높은 문제 유형

예제 : 거스름돈

Q : 카운터에 거스름돈으로 500, 100, 50, 10원짜리 동전이 무한이 있다. 손님에게 거슬러 줘야 할 돈이 N원일 때 거슬러줘야 할 동전의 최소 개수를 구하라. 단 거술러 줘야할 돈 N은 항상 10의 배수이다.

해설) 이 문제는 그리디 알고리즘을 이용해 풀 수 있는 대표적인 문제이다. 바로 '가장 큰 화폐 단위부터' 돈을 거슬러 주는 것.

그리디 알고리즘의 정당성

그리디 알고리즘을 모든 알고리즘 문제에 적용할 수 있는 것은 아니다. 대부분은 그리디로 '최적의 해'를 구할 수 없기 때문.

➡️ 따라서 그리디 알고리즘으로 문제의 해법을 찾았다면 정당한지 검토 필요.

위의 방법이 정당한 이유는 가지고 있는 동전 중에서 큰 단위가 항상 작은 단위의 배수이므로 작은 단위의 동전들을 조합해 다른 해가 나올 수 없기 때문이다. 예를 들어 단위가 500, 400, 100 이라면 그리디로는 4개의 동전 (500 + 100 + 100+ 100)이지만 최적해는 2개(400 + 400)이기 때문.

이처럼 그리디 알고리즘으로 풀었다면 정당한지 확인 가능

코딩테스트에 응용

코딩테스트 문제를 만났을 때 바로 문제 유형을 파악하기 어렵다면, 그리디 알고리즘을 의심하고, 문제를 해 결할 수 있는 해결법이 존재하는지 고민하자. 만약 그리디로 안된다면 나중에 만날 DP나 그래프로 해결할지 고민해보자.

그리디 알고리즘을 그냥 풀다가 책을 읽고 예제도 풀어보니 무엇인지 확실히 감이 잡힌다. 책 구매는 잘한 선택 같다! 굳

한국인이라면 당신도 가능하다. Next.js 오픈소스 기여! (자리 얼마 안남음)

Fri, 23 Jun 2023 03:14:14 GMT

Next.js Docs를 한국어로 번역할 사람들을 찾는다는 소식에 헐레벌떡 뛰어갔다.

한국어만 할 줄 알면 나도 이제 오픈소스 기여를 해봤다고 할 수 있다니...! 이거 참을 수 있으면 그 사람 개발자 아님.

그렇다면, 바로 시작합시다!

1. 해당 깃허브 페이지로 접속합니다.

적혀있는 것처럼 Readme와 Guide Line을 정독해줍니다.

Vecel Discussions에 들어가서 감정 표현도 마구 눌러주구요!

저는 이미 다 눌렀습니다.

2. 빈 자리 확인하기.

스크롤을 내리면 이런 식으로 콘텐츠들을 볼 수 있습니다. 파란색으로 되어있는 것은 이미 자리가 차 버린 것이고,

아래쪽에 보면 dist.Dir.mdx 처럼 아직 배정받지 않은 문서를 확인할 수 있습니다.

이걸 하기로 마음먹었다면

다시 스크롤을 점점 올리면서 경로를 메모장에 따로 적어둡시다. 예를 들면 위의 distDir.mdx와 같은 경우아래와 같습니다.

02-app - 02-api-reference - 05-next-config-js - distDir.mdx

스크롤을 쭉 내리면 사람들의 신청이 있을 텐데

~~이건 제 신청 ㅎㅎ~~

이 로켓 표시가 없다면 아직 위쪽의 진행사항에 안된거니까, 로켓 표시 없는 코멘트들은 혹시 나와 중복되었는지 확인해보고 없다면

맨 밑에 코멘트로 아까 미리 적어둔 경로 붙여놓고 신청을 하면 됩니다

이 하드같은 곳에 파란 불이 들어오면 냉큼 들어가서 로켓 이모지가 달린지 확인하고, 달렸다면 작업을 시작합시다!

3. 작업 시작하기

로켓 이모지가 달렸다면 본인이 담당자인 이슈도 하나 만들어져 있을 겁니다. 작업을 시작할 때 밑에 댓글로 시작했습니다! 를 달아줍니다.

프로젝트 Fork 하기

저기 Fork를 눌러서 프로젝트를 생성해줍니다. 그럼 본인의 레포지토리로 가면 똑같이 생긴 레포가 있을텐데 이걸 Fork 라고 합니다. ㅎㅎ

프로젝트 복제라고 생각하면 됩니다!

본인 레포에서 git clone을 해줍니다.

VSCode를 실행해줍니다.

vscode를 실행하면 이거저거 많이 설치하라고 권유해주는데 전부 설치해주면 됩니다.

우리가 번역할 문서는 docs 안에 있으니 경로를 잘 따라가줍시다. 제가 번역한 문서의 위치는 이 곳 이네요.

이제 번역을 하면 되는데, 아까 VSCODE의 추천 설치들을 다 설치했다면, 우측 상단에 돋보기 아이콘이 있을 겁니다. 클릭해주세요!

클릭하면 mdx 파일의 preview가 나옵니다.

이제 아까 읽었던 가이드라인에 맞게 잘 번역을 해주면 됩니다.

이 개념을 내 마음대로 잘 설명한다기 보다는 영어를 한국어로 그대로 옮기는 것에 초점을 맞추는게 중요합니다.

mdx파일을 수정하다보며면, preview에 뭔가 오류가 뜨면서 이상해지는데 저장을 하면 다시 잘 보입니다.

~~저도 mdx파일은 처음이라 이유는 잘 모르겠네요. ㅎㅎ....~~

번역이 완료되었다면 commit과 push까지 해줍니다.

PR하기

여기서 Pull requests 를 클릭해줍시다.

클릭!

Progress가 적혀있는데 하나씩 따라가봅시다.

progress에 원래 [ ] 로 체크박스가 있을텐데 [x]로 바꾸면 체크박스로 바뀝니다.

pnpm prettier-fix

터미널에 pnpm prettier-fix를 입력해줍니다.

사실 저는 저렇게 하면 모들 파일이 다 뒤집어엎어져서 제가 작성한 파일만 prettier를 적용했습니다.

pnpm prettier --write 경로로 하면 됩니다.

pnpm prettier --write docs/02-app/02-api-reference/02-file-conventions/not-found.mdx

번역 초안 작성

처음 번역 했던것이 잘 되었는지 어색하진 않은지 다시 점검해보고 이상하면 수정해줍시다. 수정을 했다면 위의 prettier도 다시 한번 해줍시다.

수정이 끝났다면 체크!

그 밖의 다른 것들 체크

그 밖에 공통 스타일 가이드, 모범사례 확인 등등을 체크해줍시다. 수정사항이 있다면 prettier도 한번 더 해주세요.

리뷰는 다른 분이 오셔서 해주니까 체크를 풀어주세요. 다른 분이 오셔서 리뷰 해주시면 그거 반영하면 됩니다. 리뷰 반영은 스크린샷을 깜빡했네요. ㅎㅎ

PR 열기!

PR을 열고 나면 리뷰가 곧 달릴거에요. 리뷰를 받는다면 리뷰 반영 후 위에 리뷰 반영에 체크한 후 기다려봅시다.

저도 아직 Merge 대기중이라, Merge 되면 추가하겠습니다!

다들 어서 막차타세요! 티켓 몇장 안남았습니다. :)

후련한 SSAFY 10기 탈락 ( 이었던 추가 합격) 후기

Thu, 22 Jun 2023 02:12:01 GMT

지원 동기

NCSOFT 계약직이 종료되고 실업급여를 받으면서 취업준비를 하고 있었다. 집에 혼자 있는게 답답하기도 하고 사실 시간도 허투루 쓰는 듯 하여 사람들과 함께 성장하고자 지원하게 되었다.

에세이 작성

나는 사실 1년 조금 넘는 경력이 있기 때문에 이 부분을 살려 다른 동기들에게 선한 영향력을 끼치겠다는 장점을 부각했다. 그리고 교육기관이기 때문에 내 부족한 부분인 알고리즘 실력과 빈약한 포트폴리오를 ssafy에서 채우겠다는 느낌으로 작성했다.

코딩테스트

내 인생에서 코딩테스트에 합격한 적이 없었다... 난 진짜 알고리즘을 잘 못하니까, (준비를 안한게 맞다) 그래도 D2~~D3 수준으로 나온다고 하여 그에 맞춰 D3~~D4 수준의 문제를 2-3문제씩 풀면서 준비했고, 1솔로 합격했다!

면접 준비

지인들과 함께 면접 스터디를 했다. 서로 질문해주고 뉴스 스크랩해서 PT 준비도 진행했다.

우리가 PT 면접 준비한 방법은 예를 들어 주제가 층간 소음이라면

chat gpt를 활용해서 층간소음 문제 정리, 해결 방법 등을 A4 2장 분량으로 문서 생성
생성된 문서를 각자 보고 15분 동안 각자 종이에 작성
돌아가면서 발표

이런식으로 했는데 실전에도 아주 도움이 되었다.

면접 후기

이 때 우리가 준비한 PT 주제중 하나가 내 실전 PT 주제로 나와서 정말 기뻤다!

사실 나는 면접을 잘 봤다고 생각했다... 나는 원래도 면접에 익숙하고 잘 하는 편이기도 해서 더 그랬다.

이번에도 내가 잘 아는 분야가 PT 주제로 나왔어서 더 자신있었다.

인성면접도 예상한 질문들이 100%였어서 준비한대로 잘 말했다.

후기

결과는 탈락했다.

자만한 것일 수도 있지만... 주위 사람들도 내 스펙은 싸피에 가기에 아깝다고 그냥 취업을 하라는 얘기가 많았다. 면접관도 그렇게 생각해서 그냥 취업을 하라는 의미로 불합을 줬을 수도 있겠다는 생각이 든다.

그냥 부족해서 그렇다고 해도 그냥 이렇게 생각하는게 마음이 편하니까. ㅎㅎ

싸피만 바라본 한달은 희망에 젖어 마냥 행복했던 것 같다. 하지만 이제 싸피는 물건너 갔으니까 취업 준비를 다시 열심히 영차영차해볼 예정이다.

잘가 싸피! :)

추가합격

추합 기대 컨트롤 실패..

추가합격.. 사실 알고 있었다. 하지만 주위에 기대는 안한다고 말하고 있었다. 이게 추합은 언제 될 지도 모르는 거니까... 그리고 기대하는 것은 내게 너무 가혹했다. 마음이 너무 아파서.

그렇지만 사람 마음이라는 것이.... 기대를 하지 않을 수가 없었다. 하루하루 커뮤니티를 들락날락 거리며 추가합격 가능성이 있는지 사례는 많은지 돌아다녔다. 사실 진심으로 추가합격만을 바랬다. 싸피가 정말 내게 꼭 필요했으니까... 듣도보도 못한 중소기업에 가야하는 것은 너무 우울했다. 그 탓에 싸피를 포기하려는 마음이 잡히지 않아, 공부도 제대로 못하게 되어 버려 폐관수련하겠다는 의미로 평생 잘라본 적 없는 길이로 머리도 단발로 잘랐다.

아무리 잊으려고 발악해도 자꾸 추합을 꿈꾸는 내 마음은 조절하기 힘들었다.

추가합격날

본가에서 서울로 오는 기차에서 잠에 들었다 깨어났는데 부재중이 와 있었다. 혹시..? 혹시 하고 보았더니 멀티캠퍼스 사무실 전화번호였다..!

아니 이거 전화 못받으면 불합격인가 하고 대성통곡 하고있었는데

대성통곡하느라 전화를 한번 더 못받았다.

~~(진짜 바보인가?)~~

그리고 나서 또 한번 전화가 왔다.

이름을 확인 하시고

10기 추가 합격 축하드립니다!!

라고 얘기해주셨다. 그리고 수 많은 추합 후기에서 봤던것처럼 입과 여부를 여쭤보시는 것 같길래 듣지도 않고

네!! 네!! 갈게요 바로 갈게요 좋아요!!!!

라고했다. 담당자분도 웃어주셨다. ㅎㅎ 사진 제출도 바로 하라고 해주셨는데 내가 아직 기차를 타고 있어서 바로 제출은 불가해서 집에서 제출했다.

후련한 불합격 후기가... 추가합격 후기가 되어 진심으로 기쁘다.

[TIL]CSS 선택자 우선순위

Thu, 02 Mar 2023 13:03:47 GMT

CSS 선택자 우선 순위

CSS 선택자 우선순위는 CSS 규칙의 적용 우선순위를 결정하는 방법입니다. CSS 규칙은 여러 개의 선택자와 스타일 선언으로 이루어져 있으며, 이 중 어떤 규칙이 우선적으로 적용될지는 다음과 같은 기준에 따라 결정됩니다.

중요도 (Importance): !important 규칙은 다른 모든 규칙보다 우선합니다.
인라인 스타일 (Inline Styles): HTML 요소에 직접 적용된 스타일은 다른 모든 규칙보다 우선합니다.
아이디 선택자 (ID Selectors): ID 선택자에 의해 스타일이 적용되는 요소는 다른 모든 선택자보다 우선합니다.
클래스 선택자 (Class Selectors) 및 속성 선택자(Attribute Selectors): 클래스 선택자와 속성 선택자는 태그 선택자보다 우선합니다.
태그 선택자 (Tag Selectors): 태그 선택자에 의해 스타일이 적용되는 요소는 다른 모든 선택자보다 낮은 우선순위를 가집니다.
전체 선택자 (Universal Selector): 전체 선택자는 다른 모든 선택자보다 낮은 우선순위를 가집니다.

우선순위가 같은 경우에는 나중에 선언된 규칙이 우선합니다. 따라서 같은 선택자에 대해 뒤에 나온 스타일이 우선적으로 적용됩니다.

위와 같은 우선순위 규칙을 이용하여 CSS를 작성하면, 스타일이 일관되고 예측 가능한 방식으로 적용됩니다. 그러나 우선순위가 높은 규칙을 남용하거나 중복되는 규칙을 작성할 경우, 코드의 복잡도가 증가하고 유지 보수성이 낮아질 수 있으므로 주의해야 합니다.

[TIL] 웹 표준과 웹 접근성

Thu, 02 Mar 2023 13:03:05 GMT

웹 표준

웹 표준(웹 스탠다드)은 월드 와이드 웹(WWW)에서 사용되는 기술과 규약들의 표준화를 말합니다. 이는 HTML, CSS, JavaScript 등의 웹 기술을 표준화하여 다양한 웹 브라우저와 플랫폼에서 동일한 웹 페이지를 구현할 수 있도록 하여 웹 개발자들이 보다 쉽게 웹 사이트를 개발할 수 있도록 돕는 역할을 합니다.

웹 표준을 준수하는 방법

DOCTYPE 선언하기: HTML 문서의 첫 번째 줄에 DOCTYPE을 선언해야 합니다. 이는 웹 브라우저가 문서의 버전과 유형을 파악하여 적절한 방식으로 문서를 해석할 수 있도록 합니다.
유효한 HTML과 CSS 사용하기: HTML과 CSS는 웹 표준을 따르는 방식으로 작성되어야 합니다. 이는 웹 브라우저에서 문서를 올바르게 해석할 수 있도록 하는 것입니다.
웹 페이지의 구조와 스타일을 분리하기: HTML 문서에서는 구조를, CSS에서는 스타일을 담당하도록 분리하여 작성해야 합니다. 이는 유지 보수성을 높이고, 코드 가독성을 높이며, 웹 사이트의 디자인을 보다 쉽게 변경할 수 있도록 합니다.
적절한 이미지 대체 텍스트 제공하기: 이미지가 있는 경우에는 alt 속성을 이용하여 적절한 대체 텍스트를 제공해야 합니다. 이는 시각 장애를 가진 사용자들이 이미지를 이해할 수 있도록 하는 것입니다.
웹 접근성 고려하기: 웹 표준을 준수하면서 웹 접근성을 고려하여 웹 사이트를 제작해야 합니다. 이는 장애를 가진 사용자들이 웹 사이트에 쉽게 접근할 수 있도록 하는 것입니다.
웹 사이트의 성능 최적화하기: 웹 표준을 준수하면서 웹 사이트의 성능을 최적화해야 합니다. 이는 빠른 로딩 속도와 높은 사용성을 보장하는 것입니다.

웹 접근성

웹 접근성은 장애를 가진 사용자들이 웹 사이트에 쉽게 접근할 수 있도록 웹 사이트를 설계하는 것을 말합니다. 예를 들어 시각 장애를 가진 사용자들은 음성 출력, 화면 돋보기 등의 보조 기술을 사용하여 웹 사이트에 접근합니다. 이를 위해서는 웹 사이트의 콘텐츠, 기능, 디자인 등이 웹 접근성을 고려하여 제작되어야 합니다.

웹 표준과 웹 접근성은 서로 밀접한 관련이 있습니다. 웹 표준을 준수하면 웹 사이트가 다양한 플랫폼과 웹 브라우저에서 일관되게 보여지므로 사용자들이 쉽게 접근할 수 있습니다. 또한 웹 접근성을 고려한 웹 사이트는 장애를 가진 사용자들이 더 쉽게 접근할 수 있도록 구성되어 있으므로 웹 접근성이 높은 웹 사이트는 모든 사용자에게 유용합니다. 따라서 웹 사이트를 개발할 때는 웹 표준을 준수하고 웹 접근성을 고려하여 개발해야 합니다.

[TIL] CSS에서 사용되는 단위의 종류와 특징

Mon, 27 Feb 2023 13:06:11 GMT

CSS에서 사용되는 단위

px

- 화면의 크기와 무관하게 픽셀 단위로 지정
- 정확한 크기를 표현할 때 사용

vh, vw

- 뷰포트의 크기를 기준으로 상대적인 크기를 지정
- 레이아웃을 유동적으로 유지할 때 유용하다.

%

- 부모 요소의 크기에 따라 크기가 결정
- 반응형 레이아웃에서 많이 사용

rem, em

- 폰트 크기를 지정할 때 사용
- rem은 루트 요소의 폰트 크기에 영향을 받음.
- em은 상위 요소의 폰트 크기에 영향을 받음.

[TIL] 인터뷰 정리 - React, 렌더링 기법, SEO, CORS, 세션과 쿠키, 프록시 서버

Fri, 24 Feb 2023 14:53:18 GMT

React

상태와 속성

상태(state)

상태란 컴포넌트 내부에서 변경 가능한 데이터를 의미합니다. 상태는 컴포넌트 내에서 변경되며, 이에 따라 컴포넌트가 다시 렌더링됩니다. React에서 상태는 클래스형 컴포넌트나 함수형 컴포넌트에서 uesEffect 훅을 사용하여 관리할 수 있습니다.

속성 (prop)

속성(prop)이란 컴포넌트에 전잘되는 읽기 전용 데이터를 의미합니다. 속성은 부모 컴포넌트에서 자식 컴포넌트로 전달되며, 컴포넌트 내에서 변경할 수 없습니다. 속성을 통해 부모 컴포넌트에서 데이터를 전달받아 사용할 수 있습니다.

상태와 속성을 잘 활용하여 React App을 개발하면, 유지보수성이 높고 코드의 가독성도 좋아집니다.

라이프사이클 메서드 (lifecycle methods)

React에서 라이프사이클 메서드(lifecycle methods)는 컴포넌트의 생성, 업데이트, 제거와 관련된 이벤트에 대해 처리하는 메서드입니다. React 16 이전까지는 클래스형 컴포넌트에서만 사용할 수 있었지만, 16 이후부터는 함수형 컴포넌트에서도 사용이 가능해졌습니다.

React에서는 컴포넌트가 생성되고, 업데이트되며, 제거될 때 다양한 라이프사이클 메서드를 호출합니다. 이를 통해 컴포넌트가 마운트, 언마운트, 업데이트되는 동안 원하는 작업을 수행할 수

있습니다.

React의 라이프사이클 메서드는 크게 3가지 카테고리로 나눌 수 있습니다.

마운트(Mounting) : 컴포넌트가 처음으로 생성되어 DOM에 삽입되는 것

업데이트(Updating) : 컴포넌트가 업데이트 되는 것

언마운트(Unmounting) : 컴포넌트가 DOM에서 제거되는 것

React 16 이전의 클래스형 컴포넌트에서는 라이프사이클 메서드를 사용하여 위 세 가지 단계에서 원하는 작업을 수행할 수 있었습니다. 하지만 React 16 이후의 함수형 컴포넌트에서는 라이프사이클 메서드 대신에, useEffect 훅을 사용하여 원하는 작업을 수행할 수 있습니다.

React에서 라이프사이클 메서드를 사용할 때는, 컴포넌트의 상태와 속성에 대한 이해가 필요합니다. 라이프사이클 메서드를 적절히 활용하여, 컴포넌트의 마운트, 업데이트, 언마운트에 대한 동작을 제어할 수 있습니다. 그러나 최근에는 함수형 컴포넌트와 훅의 등장으로 라이프사이클 메서드를 사용하지 않고도 컴포넌트의 동작을 제어할 수 있게 되었습니다. 따라서, 최신 React에서는 라이프사이클 메서드 대신에 useEffect 훅을 사용하는 것을 권장합니다.

렌더링 기법

SPA (Single Page Application)

SPA는 한 개의 HTML 파일을 사용하고, 페이지의 일부분만을 변경하는 방식으로 동작합니다. 클라이언트 측에서 렌더링이 이루어지므로 서버 부담이 적습니다. 사용자 경험이 좋고, 빠른 속도를 제공할 수 있습니다. 초기 로딩 시간이 길고, SEO에 좋지 않을 수 있습니다.

CSR (Client Side Rendering)

CSR은 SPA의 한 종류로, 서버에서 제공되는 데이터를 받아와 클라이언트 측에서 렌더링을 수행하는 방식입니다. 초기 로딩 시간이 짧고, SPA처럼 빠른 속도를 제공할 수 있습니다. SEO 문제와 초기 로딩 속도가 느릴 수 있는 단점이 있습니다.

SSR (Server Side Rendering)

SSR은 서버 측에서 HTML 파일을 생성하여 클라이언트에 전달하는 방식으로 동작합니다. 초기 로딩 시간이 빠르고, SEO에 우수합니다. 서버 부하가 높을 수 있으며, 전체적인 사용자 경험이 떨어질 수 있습니다. 초기 구성 비용이 높을 수 있습니다.

SEO(Search Engine Optimization)

검색 엔진 최적화를 의미합니다. 즉, 검색 엔진에서 웹 페이지를 검색하여 순위를 매기는 방식에서 높은 순위를 얻을 수 있도록 웹 사이트를 최적화하는 기술이나 작업을 말합니다.

검색 엔진에서 사용자가 검색한 단어 또는 구를 검색해서 최적의 검색 결과를 보여주는데, 이 때 검색어와 관련된 웹 페이지를 높은 순위로 보여주는 것이 SEO의 목적입니다. 이를 위해서는 검색 엔진이 사용하는 알고리즘에 맞는 웹 페이지를 만들고, 검색 엔진이 크롤링하기 쉬운 웹 페이지를 만들어야 합니다. 이를 위해 HTML 태그, 제목, 내용, 이미지, URL, 링크 등에 키워드를 적절히 활용하고, 검색 엔진에서 웹 페이지를 검색하면 빠르게 로딩되는 웹 페이지를 제공하도록 개발합니다.

SEO 개선 방법

적절한 키워드 사용
- 검색어를 찾아서 웹 페이지의 콘텐츠와 HTML 태그에서 적절한 위치에 삽입합니다.
고품질 콘텐츠 작성
- 사용자에게 유용한 정보를 제공하고, 키워드를 적절하게 사용하면서, 인공적인 키워드 채우기를 하지 않습 니다.
웹 페이지의 속도 향상
- 웹 페이지의 로딩 속도가 빠르면 검색 엔진에서 높은 순위를 얻을 수 있습니다. 이미지 크기를 줄이고, HTML/CSS/JavaScript 파일을 압축하고, CDN을 사용하여 속도를 향상시킵니다.
모바일 최적화
- 모바일 장치에서도 웹 페이지가 잘 작동하도록 개발하고, 모바일 최적화된 디자인을 적용합니다.
링크 구조 개선
- 내부 링크 구조를 개선하여 검색 엔진이 페이지를 쉽게 탐색할 수 있도록 합니다.
메타 데이터 최적화
- 메타 데이터(타이틀, 설명 등)를 적절하게 작성하여 검색 결과에서 노출되도록 합니다.

세션과 쿠키

세션(Session)이란?

세션은 서버에서 클라이언트를 구분하고 클라이언트의 상태를 유지하는 기술입니다.
세션은 클라이언트가 서버에 접속한 이후 브라우저를 닫거나 일정 시간이 지난 후에도 서버에서 클라이언트의 정보를 유지할 수 있습니다.
세션은 보안 측면에서 중요합니다. 서버에서 세션 ID를 발급하고, 클라이언트는 이 세션 ID를 쿠키로 저장하여 서버와 통신합니다. 이를 통해 서버는 세션 ID를 확인하여 유효한 클라이언트인지 판단할 수 있습니다.

쿠키(Cookie)란?

쿠키는 클라이언트 측에서 저장되는 작은 데이터 파일입니다.
쿠키는 사용자 인증, 세션 유지, 개인화 등 다양한 목적으로 사용됩니다.
쿠키는 이름, 값, 만료 날짜 및 경로 정보 등을 가집니다.
쿠키는 브라우저에서 관리되며, 만료 날짜가 지나면 자동으로 삭제됩니다.
쿠키는 서버에서 응답 헤더를 통해 클라이언트에게 전송되며, 클라이언트에서는 요청 헤더를 통해 쿠키를 서버에 전송합니다.

CORS(Cross-Origin Resource Sharing)는 웹 개발에서 발생하는 보안 이슈 중 하나입니다. 보안 상의 이유로, 브라우저는 한 도메인에서 실행되는 웹 페이지가 다른 도메인에 있는 리소스에 접근하는 것을 제한합니다.

CORS는 이러한 보안 이슈를 해결하기 위한 기술 중 하나입니다. CORS를 사용하면, 웹 페이지에서 다른 도메인의 리소스에 접근할 수 있습니다. 이를 위해 서버에서는 특정 HTTP 헤더를 설정하여, 클라이언트가 다른 도메인의 리소스에 접근할 수 있도록 허용합니다. 브라우저는 이러한 헤더를 확인하고, 해당 리소스에 대한 접근 권한이 있는지 확인합니다. 이를 통해, 서로 다른 도메인 간에도 안전하게 리소스를 공유할 수 있습니다.

CORS는 웹 개발에서 매우 중요한 보안 이슈이며, 개발자는 서버에서 CORS 설정을 올바르게 구성하여, 다른 도메인의 리소스에 대한 접근을 안전하게 허용해야 합니다.

CORS를 해결하는 방법

CORS를 해결하는 방법은 크게 두 가지로 나눌 수 있습니다.

첫 번째 방법은 서버 측에서 CORS를 허용하는 설정을 추가하는 것입니다. 서버에서는 Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers와 같은 헤더를 설정하여 허용된 도메인에서만 리소스에 접근이 가능하도록 허용할 수 있습니다. 이를 통해, 브라우저에서는 서버에서 설정한 도메인에서만 리소스에 접근이 가능하도록 제한됩니다.

두 번째 방법은 JSONP(JSON with Padding)를 사용하는 것입니다. JSONP는 AJAX 요청을 보내는 대신, 동적으로 스크립트 태그를 생성하고, JSON 데이터를 콜백 함수로 전달하는 방식으로 동작합니다. JSONP는 브라우저에서 CORS를 우회하는 방법 중 하나이며, 서버에서는 JSONP 요청을 받을 수 있도록 응답을 구성해야 합니다.

서버에서 CORS를 허용하는 방법이 가장 일반적이며, 보안상의 이유로, JSONP는 사용하지 않는 것이 좋습니다. 따라서, 서버에서 CORS 설정을 제대로 구성하는 것이 중요합니다.

프록시를 이용하여 CORS 문제를 우회하는 방법

프록시 서버는 클라이언트와 서버 사이에서 중계 역할을 수행하며, 클라이언트와 서버 간의 통신을 대신 처리해줍니다. 클라이언트는 프록시 서버에 요청을 보내고, 프록시 서버는 서버에서 리소스를 가져와 클라이언트에게 반환해줍니다. 이를 통해, 클라이언트는 서버의 도메인과는 직접적으로 통신하지 않기 때문에 CORS 문제를 우회할 수 있습니다.

프록시를 이용하여 CORS 문제를 해결하는 방법은 보안성이 높아지는 장점이 있으나, 구성하기가 복잡하며, 프록시 서버의 성능 이슈가 발생할 수도 있습니다. 따라서, 프록시를 사용하는 경우, 이러한 문제들을 고려하여 적절하게 구성하는 것이 중요합니다.

프록시 서버

프록시 서버란, 클라이언트와 서버 사이에서 중계 역할을 수행하는 서버를 말합니다. 프록시 서버는 클라이언트가 서버에 직접적으로 접근하는 것을 막고, 클라이언트와 서버 사이의 통신을 대신 처리해줍니다. 이를 통해, 클라이언트의 IP 주소나 위치 등의 정보를 숨기거나, 웹 콘텐츠를 캐시하여 빠른 로딩을 도와주는 등의 기능을 수행할 수 있습니다.

프록시 서버는 일반적으로, 브라우저나 애플리케이션 설정에서 직접 설정할 수 있으며, 클라이언트는 프록시 서버에 요청을 보내고, 프록시 서버는 서버에서 리소스를 가져와 클라이언트에게 반환해줍니다. 이를 통해, 클라이언트는 서버의 도메인과는 직접적으로 통신하지 않기 때문에, 보안성이 높아질 수 있습니다.

프록시 서버는 클라이언트와 서버 사이에서 중개자 역할을 수행하기 때문에, 웹 보안과 성능 개선 등에 활용될 수 있으며, 프록시 서버의 종류에 따라 다양한 기능을 수행할 수 있습니다.

[TIL] HTML, CSS, JavaScript 기본 개념 정리

Thu, 23 Feb 2023 13:06:52 GMT

HTML

HTML5에서 추가된 새로운 기능

HTML5에서는 여러 가지 새로운 요소와 기능이 추가되었습니다.

시멘틱 요소가 추가되었습니다. 예를 들어 header,nav, article, section, footer가 있습니다.
비디오와 오디오 태그 video와 audio 태그를 사용하여 비디오와 오디오를 쉽게 재생할 수 있습니다.
폼 관련 개선 ( 새로운 폼 요소들이 추가되어, 폼 요소들의 속성과 이벤트들이 개선되었습니다. )
캔버스와 SVG canvas와 svg 태그를 사용하여 그래픽과 애니메이션을 만들 수 있습니다.
웹 저장소 (Web Storage) : 로컬 저장소와 세션 저장소를 지원합니다. 이를 이용하여 브라우저 내에서 데이터를 저장하고 사용할 수 있습니다.
웹 서비스를 개발 할 때 사용하는 localStorage와 sessionStorage 는 HTML5에서 지원하는 기능 중 하나인 Web Storage API의 의 일종이다.
웹 워커 (Web Worker) : 웹 워커를 사용하면 백그라운드에서 스크립트를 실행하여 웹 페이지의 성능을 향상시킬 수 있다.
- 기존의 자바스크립트는 싱글 스레드로 실행되기 때문에, 여러 가지 작업을 동시에 처리하려면 비동기 처리를 해야했다. 하지만 이 비동기 처리는 복잡하고 어려운 방식이라 웹 워커가 이 처리를 쉽게 할 수 있도록 도와줍니다.
  - 메인 스레드와 별도로 동작하며, 브라우저에서 백그라운드에서 스크립트를 실행할 수 있게 한다. 웹 워커는 병렬로 작업을 처리하기 때문에 여러 개의 웹 워커를 사용하면 더 빠르게 처리할 수 있다.
  - 주로 대용량의 데이터 처리나 복잡한 계산, 그리고 이미지 처리에 사용된다.
미디어 쿼리
웹 폰트
드래그 앤 드롭

CSS

CSS는 Cascading Style Sheets의 약자로, 웹 페이지의 스타일을 정의하는 언어입니다. HTML과 함께 사용되며, HTML 요소들의 스타일으 정의하는데 사용됩니다.

CSS3에서 추가된 새로운 기능

그리드 레이아웃
플렉스 박스
다단 Drop Cap
- 텍스트의 첫 글자를 크게 만들 어 다단의 시작 부분을 장식할 수 있습니다.
그림자
Transform
새로운 셀렉터
- :not(), :nth-child(), :first-child()
애니메이션과 트랜지션 같은 기능

JavaScript

개념

객체 기반의 동적 프로그래밍 언어
주로 웹 페이지를 동적으로 제어하는 데에 사용
브라우저에서 실행되며 HTML 문서와 함께 사용하여 웹 페이지를 만들고 상호작용하는 기능을 추가할 수 있음
특징
가볍고 빠름
동적 타이핑 (변수의 타입을 런타임 시점에 결정)
함수형 프로그래밍과 객체지향 프로그래밍 모두 지원

ES6에서 추가된 내용

let, const 키워드 추가
화살표 함수 (Arrow function) 추가
템플릿 리터럴 (Template literal) 추가
클래스 (Class) 추가
모듈 (Module) 추가
Async/Await 추가
for...of 추가
객체 리터럴 (Object literal) 추가

ES6

개념

ECMAScript 2015의 준말로, JavaScript의 버전 업그레이드
가독성이 좋고 코드의 양을 줄일 수 있는 새로운 기능들을 제공

주요 기능

let, const

블록 레벨 스코프 변수 선언
let은 재할당이 가능하고 const는 재할당이 불가능
화살표 함수
함수를 간결하게 작성할 수 있음
this, arguments 등의 바인딩을 가지지 않음
템플릿 리터럴
문자열을 보다 쉽게 다룰 수 있음
백틱(``)으로 감싸고 ${}를 사용하여 변수나 표현식을 삽입할 수 있음
클래스
클래스 기반 객체 지향 프로그래밍 지원
생성자, 상속 등의 기능 제공
모듈
파일 단위로 모듈화할 수 있음
import, export 키워드로 모듈을 가져오거나 내보낼 수 있음
Promise, Async/Await
비동기 처리를 더욱 쉽게 작성할 수 있음
for...of
for...in과 달리, 배열 등의 컬렉션 객체에 대한 반복문에서 요소의 값을 반환할 수 있음
객체 리터럴
객체를 보다 쉽게 작성할 수 있음
변수를 속성 이름으로 사용 가능

[TIL] Vue 2와 Vue 3의 차이

Tue, 18 Oct 2022 14:26:50 GMT

오늘은 Vue 2와 Vue 3의 차이가 모르는 나를 위해 알아보도록 하겠다.

가장 큰 차이는 Vue 2는 Options API를 사용하고 Vue 3은 Composition API를 사용한다.

세부적인 내용은 시작해 보자!

Creating App의 차이

Vue2와** Vue3**은 앱을 만들 때부터 차이가 있다.

** Vue2**

import Vue from 'vue'
import App from './App.vue'

Vue.config.productionTip = false

new Vue({
  render: h => h(App),
}).$mount('#app')

** Vue3**

import { createApp } from 'vue'
import App from './App.vue'
import './index.css'

createApp(App).mount('#app')

Multiple Root

** Vue2에서는 template 안에 root node가 하나만 있어야 했다. ** Vue3에서는 전혀 상관 없다.

** Vue2**

** Vue3**

차이가 느껴지나? root node를 하나로 제한하기 위해 쓸데없이 태그 하나로 감쌀 필요가 사라졌다! 약간 스벨트가 생각이 난다

Computed를 사용하는 방법의 차이

** Vue2에서는 computed 블록 안에 계산될 값들을 넣어야 했다. ** Vue3에서는 setup()안에서 변수 선언시 computed(() => {return _}); 형식으로 사용이 가능하다.

Watch를 사용하는 방법의 차이

watch는 특정 값을 바라보다 변경이 발생하면 호출된다. 대부분의 경우 computed 속성을 사용하는 것이 더 적절하다. 하지만 데이터 변경에 의한 응답으로 비동기 혹은 비용이 많이 드는 작업을 하려고 할 때 watch가 유용하다.

** Vue2**

watch : {
    name(newVal, oldVal){
        console.log(`${newVal} ${oldVal}`);    
    }
}

** Vue3**

const name = ref('');
watchEffect(() => {
    console.log(name.value);
})

게임회사 출근 2일차 후기

Tue, 18 Oct 2022 14:09:50 GMT

게임 회사 일기를 써보려고 한다. 평생 가보고 싶었던 게임 회사에서 3개월간 일할 수 있게 되었는데 그것도 국내에서 제일 큰 기업중 하나에 다니니 이런 소중한 3개월을 잊지않고 소중히 여기고 싶다.

혹시 읽어볼 분들을 위해 소개를 하자면, 저는 게임회사 내부 연구실 소속에 단기계약직으로 입사를 하였습니다. 아르바이트/인턴/계약직/정규직과 다른 점 미리 알아주세요! ㅎㅎ

난 앞으로 밥 안주는 회사 안가.

회사에서 지금까지 총 4끼를 먹어봤는데 싫어하던 음식도 좋아하게되었다. 나는 사실 돈까스를 싫어하는데 어제 구내식당 돈까스를 먹어보고 이제 돈까스를 좋아하게 되었다...

정말 모든 음식이 너무 맛있는데 선택지도 많고 가격도 저렴해서 진짜 행복하다.

개발자 회고인데 밥 얘기 부터 나와서 당황스러울 수 있지만.... 전직장에서 밥으로 서러운 일이 너무 많았기 때문에 밥을 잘 챙겨주는 회사가 이렇게 고마울 데가 없다.

이제 눈이 높아져서 구내식당이 있거나 식비를 주는 회사만 지원할 것 같다. 구내식당은 정말 최고야!

점심시간에 게임을 해도 된다구요....?

다음주에 워크샵이 있어서 워크샵 게임대회 예선전이 점심시간마다 열리고 있어 점심시간에 게임을 하는 사람들을 많이 볼 수 있었다. 나도 게임 대회에 출전하기로 했다! 나는 폴가이즈에 참가하게 되었다. 어제 점심시간에 사람들이랑 했었는데 내가 1등을 했다..! ~~세상에 나 폴가이즈 몇번 안해봤는데 혹시 나 재능충인걸까...?~~

워크샵에서도 꼭! 1등을 하고싶다.

그런데 오늘 들은 얘기가 회사에서 점심시간에 게임을 해도 된다는 사실이었다.

진짜 롤 해도 돼요....?

근데 진짜 였다. 대신 디스코드는 하지 말라고하셨다.

진짜 나 여기 평생 일하고싶다. 여기 정직원이나 인턴이나 계약직으로 오려면 공부 열심히 해야겠지. 화이팅! 정말 매일매일이 동기부여의 연속이다.

드디어 나도 일을 받게 되었다!

여기서 사내업무를 자세히 얘기하면 안될 것 같다.

오늘 처음으로 회의에 들어가게 되었다. 요구사항을 잘 정리하고 회의 후 일을 받았다.

나는 프론트 개발로 입사를 하게 되었으니 프론트 개발을 맡게 되었다. 사실 나는 React와 JS가 제일 자신있는데 Vue와 TypeScript를 하게 되어 약간 무섭기도 하다. 하지만 새로운 프레임워크를 배우는 것은 재미있기도 하고 스스로가 성장속도가 빠른 주니어라고 생각하고 있어서 괜찮을 것 같다! ㅎㅎ

오늘 사수님이 이번주 까지 하라고 하신거 바로 시작해봤는데 그렇게 어려울 것 같지 않아 다행이다. 일정에 맞출 수 있을 것 같다.

스타트업과 다른 점이 이것 같다. 전직장에서는 퇴근 후 시간이나 공휴일 주말 등도 모두 포함해서 워킹데이를 잡았는데 여기서는 현실적인 일정을 주신다.

덕분에 집에서 따로 공부를 할 수 있다! 계약직 기간동안 열심히 공부해서 다른 곳들 인턴하며 여기 공채를 기다리다 다음 신입 채용때 꼭 지원하고 싶다.

진짜 최고의 직장이야 여기 사람들 채고고 다 너무 멋져버려...

그럼에도 단점은 있어요.

키보드 마우스가 별로다.

그냥 진짜 별로다 헤헷. 근데 이건 개인 취향의 문제도 있고 정직원/인턴/계약직 분들은 따로 구매를 해주시지 않을까..? 싶다.

프론트 개발자분들 대부분 mac쓰던데 여기는 mac을 쓰지 않았다. 아마도 라이브 서비스를 위한 프론트 개발이 아니라 그런걸까..? 지원이 안되나..? 잘 모르겠다.

혹시 정직원/인턴/계약직인데 이걸보고 걱정하시는 분들은 그러지마세요..! 전 단기계약직이라 다를겁니다! 다른분들은 직접사신건지 아닌지 모르겠지만 다들 엄청 좋은 키보드 쓰고계셨어욧

나도 월급받으면 바로 키보드 마우스 flex 해버릴거다! 후후

약간 곤란한 점이 있다.

그.. 정보 교육..?? 같은 윤리교육..? 을 반드시 이수해야하는데 아마 동영상 같은데 나는 데스크탑이고 내게 이어폰은 없다 ^-^..... 그냥 틀어만 놓기 아쉬운걸...? 대기업의 윤리교육.. .놓치고 싶지 않아..!

조만간 이어폰을 마련해야겠다. 다음주 월요일까지 이수해야하는데...

오늘 근무시간이 1분 모자라다. 29분 초과근무했는데 저녁을 먹어서 30분 차감되어서 1분 모자라다. 이건 한달동안 시간을 맞추면 된다고 하셨으니까 내일 화끈하게 일찍 출근해서 저녁먹고 와야겠다! 후후

그러려면 어서자야지.

공부한거 빠르게 정리하구 자야겠다.

[TIL] TypeScript (1) 정적 타입 체크

Tue, 18 Oct 2022 13:30:04 GMT

TypeScript란?

타입스크립트는 자바스크립트에 타입이 추가된 언어입니다.

TypeScript는 JavaScript의 Superset이므로 기존의 자바스크립트(ES5)문법을 그대로 사용할 수 있습니다.
정적 타입을 지원하므로 코드의 가독성을 높이고 디버깅을 쉽게 할 수 있게 하여 협업에 용이합니다.

Non-exception Failures

이러한 코드가 있다고 해봅시다.

const user = {
  name : "daniel",
  age : 26
};

user.location;

이 코드를 js에서 실행하면 undefined를 반환하고 ts에서는 에러를 발생시킵니다. 다시말해, js에서는 존재하지 않은 객체에 접근해도 valid 하지만 ts에서는 즉시 error를 발생시킵니다.

이처럼 ts에서는 컴파일 단계에서 오류를 포착할 수 있는 장점이 있어 개발 시간을 단축시킬 수 있습니다.

이 외에도 타입스크립트에서는 여러 문법적 버그들을 찾아줍니다.

타이핑 에러

    const announcement = "Hello World!";
    // How quickly can you spot the typos?
    announcement.toLocaleLowercase();
    announcement.toLocalLowerCase();
    // We probably meant to write this...
    announcement.toLocaleLowerCase();

uncalled function

function flipCoin() {
 // Meant to be Math.random()
 return Math.random < 0.5;
// Operator '<' cannot be applied to types '() => number' and 'number'.
}

기본적인 문법 에러

const value = Math.random() < 0.5 ? "a" : "b";
if (value !== "a") {
// ...
} else if (value === "b") {
This condition will always return 'false' since the types '"a"' and
'"b"' have no overlap.
// Oops, unreachable
}

### 타입스크립트 컴파일러 "tsc"
> 설치 방법
**npm install -g typescript**

#### typeScript파일 터미널로 실행하기 

vscode에 hello.ts파일을 생성한다. 

terminal에 tsc typescript파일이름 을 작성하고 실행하면 js 파일이 생성된다.

> ***tsc hello.ts ***
 -> hello.js 파일 생성/업데이트

> *** node hello.js***
-> hello.js 파일 실행

> *** tsc --noEmitOnError hello.ts ***
-> 에러가 없었을 때만 hello.js 파일 생성/업데이트

**알아야 할 것!**
java는 컴파일 에러시 class 파일 생성이 되지 않지만 ts는 오류가 나도 js파일이 생성 또는 업데이트된다. 이는 오류가 나는 파일로 업데이트가 될 수 있다는 뜻이고 큰 장애를 낳을 수 있는 문제이다. 이를 방지하려면 tsc --noEmitOnError ts파일이름 을 사용하면 된다. 

### 타입 추가 해보기

이 코드를 TS로 실행시키면 결과가 어떻게 될까? 
``` typescript
function greet (person : string, date : Date) {
    console.log(`Hello ${person}, today is ${date.toDateString()}!`); 
}
greet("soni", Date());

결과 Argument of type 'string' is not assignable to parameter of type 'Date'.

그 이유는 javascript에서 new 없이 Date()를 호출하면 반환 타입이 string인데 함수에서 파라미터의 타입을 Date타입으로 지정했기 때문에 에러가 나는 것이다.

이를 에러가 나지 않도록 수정하면 하단의 코드이다.

function greet (person : string, date : Date) {
    console.log(`Hello ${person}, today is ${date.toDateString()}!`); 
}
greet("soni", new Date());

참고사항

변수의 타입을 명시할 때에는 "변수명 : 타입"의 형태를 따른다.
ts는 모든 변수에 전부 type annotation을 붙이지 않는다. 많은 경우 ts는 타입 추론이 가능하다.
상단 코드에서 today is ${date}도 버그를 발생시키지 않는다. 다만 실행결과가_ today is Mon Oct 17 2022 16:52:13 GMT +0900 (대한민국 표준시)_로 나온다.

ts에서 js로 바뀌면 일어나는 일

모든 type annotations가 사라진다.
template string이 plain string with concatenations로 변환된다.

point : type annotations는 절대 프로그램의 runtime behavior를 바꾸지 않습니다.

Downleveling

Template strings가 plain string으로 바뀌는 이유가 뭘까?

Template strings는 ECMAScript_의 특정 버전 (ES6 등)의 특징이다. TypeScript는 ECMAScript의 높은 버전 코드를 낮은 버전으로 변환하는 능력이 있다. 이를 **_downleveling** 이라고 한다.

참고자료

https://velog.io/@taeg92/TypeScript-%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0 https://www.typescriptlang.org/assets/typescript-handbook.pdf

쿠키/세션의 차이점

Wed, 28 Sep 2022 10:18:02 GMT

0. 쿠키/세션을 쓰는 이유는 뭘까?

텍스트HTTP의 특징은 2가지가 있다.

1. Stateless 프로토콜 클라이언트의 상태 정보를 가지지 않는 서버 처리 방식이다. 어떠한 이전 요청과도 무관한 각각의 요청을 독립적인 트랜잭션으로 취급하는 통신 프로토콜이다.

2. Connectionless 프로토콜 클라이언트가 서버에 요청을 했을 때, 그 요청에 맞는 응답을 보낸 후 연결을 끊는 처리 방식이다. 연결을 유지하기 위한 리소스를 줄이면 더 많은 연결을 할 수 있으므로 비 연결적인 특징을 갖습니다.

-> 하지만 실제로는 데이터 유지가 필요한 경우가 많으므로 쿠키/세션을 사용합니다.

1.🍪🍪 쿠키(Cookie) 🍪🍪

쿠키는 클라이언트(브라우저) 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일입니다.
사용자 인증이 유효한 시간을 명시할 수 있으며, 유효 시간이 정해지면 브라우저가 종료되어도 인증이 유지된다는 특징이 있습니다.
Response Header에 Set-Cookie 속성을 사용하면 클라이언트에 쿠키를 만들 수 있습니다.

*쿠키의 동작 방식 *

클라이언트가 페이지를 요청
서버에서 쿠키를 생성
HTTP 헤더에 쿠키를 포함시켜 응답
브라우저가 종료되어도 쿠키 만료 기간이 있다면 클라이언트에서 보관하고 있음.
같은 요청을 할 경우 HTTP 헤더에 쿠키를 함께 보냄.
서버에서 쿠키를 읽어 이전 상태 정보를 변경 할 필요가 있을 때 쿠키를 업데이트 하여 변경된 쿠키를 HYYP 헤더에 포함시켜 응답

2. 세션

새션은 쿠키를 기반하고 있지만, 사용자 정보 파일을 브라우저에 저장하는 쿠키와 달리 세션은 서버측에서 관리합니다.
서버에서는 클라이언트를 구분하기 위해 세션 ID를 부여하며 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지합니다.
쿠키보다 보안에 좋지만 사용자가 많아질수록 서버 메모리를 많이 차지하게 됩니다.

세션의 동작 방식

클라이언트가 서버에 접속 시 세션 ID를 발급 받음
클라이언트는 세션 ID에 대해 쿠키를 사용해서 저장하고 가지고 있음
클라이언트는 서버에 요청할 때, 이 쿠키의 세션 ID를 같이 서버에 전달해서 요청
서버는 세션 ID를 전달 받아서 별다른 작업없이 세션 ID로 세션에 있는 클라이언트 정보를 가져와서 사용
클라이언트 정보를 가지고 서버 요청을 처리하여 클라이언트에게 응답

3. 쿠키와 세션의 비교

저장위치
- 쿠키는 클라이언트, 세션은 서버에 저장된다.
보안
- 세션이 쿠키보다 비교적 보안이 좋다.
라이프 사이클
- 쿠키는 만료 기간을 지정, 브라우저 종료시에도 유지
- 세션은 브라우저 종료시 삭제
속도
- 쿠키가 세션보다 빠르다. (세션은 서버에 정보가 있어 느리다)

참고 자료 😎

Github페이지에 Svelte + Vite 프로젝트 배포하기!

Tue, 06 Sep 2022 06:40:42 GMT

배포를 하기위해 제가 대신 굴러보았습니다..! 여러분은 그저 따라만 오십시오.

1. 내 프로젝트가 Vite를 사용하고 있는지 확인한다.

프로젝트를 실행할 때 vite를 사용하고 있다면

이런식으로 실행이 됩니다. 만약 vite를 사용하고 있지 않다면 이곳 으로 가서 Svelte 프로젝트를 배포하는 방법을 알아보세요 😊

2. github repository에 code push하기

터미널에서 push하는 방법

$ git init
$ git add .
$ git commit -m "first-commit"
$ git branch -M main
$ git remote add origin http://github.com/username/repo-name.git
$ git push -u origin main

꼭 이렇게 안해도 되고 그냥 push를 하면 됩니다. repository에서 내 code를 볼 수 있으면 됩니다.

3 Deploying (배포하기)

프로젝트의 루트 디렉토리에 vite.config.js 수정

만약 배포하는 url이 https://.github.io/ 이런 형식이라면 base를 '/'로 하면 됩니다. 만약 https://.github.io//이런식으로 repository가 뒤에 붙는다면 base를 '/레포지토리 이름/' 으로 하면 됩니다.

plugins에 svelte로 되어있을텐데 가만히 냅두면 됩니다. 혹시 react와 vite를 사용하고 계신다면 사진처럼 plugins가 react로 되어있을 겁니다.

빌드하기

npm을 사용한다면npm run build yarn을 사용한다면 yarn build 터미널에서 실행하기 /dist 폴더에 index.html , assets, vite.svg가 있는 것을 확인할 수 있습니다.
repository에 /dist 폴더를 추가 합니다.
1. git add dist -f
2. git commit -m "Adding dist"
3. git subtree push --prefix dist origin gh-pages
github 페이지 설정
1. repository의 Settings로 들어간다.
2. 왼쪽에 pages 클릭
3. 브랜치를 gh-pages로 변경 후 Save
4. 바로 반영되지는 않고 5~10분정도 걸립니다. 여유롭게 커피타임 한번 가집시다.😗
5. 설정하는곳 위쪽에 떠있는 Visit site클릭해서 확인해봅니다. 혹시 잘 안되더라도 그냥 늦는거일 수 있으니 차분하게 기다려 봅니다.

후설정

잘 되었다면 package.json의 "scripts"안에
"deploy":"npm run build && git add dist -f && git commit -m'hosting' && git subtree push --prefix dist origin gh-pages"를 넣어줍니다. 이미 deploy가 있다면 덮어씌웁니다. 수정을 합니다!

혹시 이렇게 했는데도 잘 안된다면 댓글 또는 메일 주세요 :)

로딩속도 5분에서 5초로 줄여보았다!

Fri, 02 Sep 2022 11:05:45 GMT

다국어 채팅 앱을 개발하던 당시 겪었던 로딩속도 개선 프로젝트에 대해 정리한 글 입니다.

로딩 속도 튜닝의 필요성

우리는 채팅에 번역시스템을 추가한 서비스를 개발하고있었다.

채팅 앱이라면 빨리 답장해야하는 만큼 로딩속도가 중요한데 기존 앱의 로딩속도는 최소 40초에서 길면 5분까지도 걸렸다.

배치 처리가 되어 있지 않아 정말 문제가 많았다.

로딩속도 개선의 목표는 3초에서 5초 이내로 잡고 로딩속도 개선 프로젝트에 참여하게 되었다.

시도 1 : API 통합하기

기존에 로그인을 할 때 사용하던 API들

기존 API 로그인은 다음 과정을 순차적으로 호출합니다.

로그인
이모티콘 리스트 수신
자동 친구 추가
단체방들 정보 업데이트
1:1 채팅방 정보 업데이트
메시지 번역
- 4번, 5번에서 번역을 다시 해야하는 메시지들이 있다면 서버에 메시지 번역을 요청한다. 이 때 다른 언어로부터 온 메시지가 10개라면 메시지 번역 API도 10번을 요청한다.
- 서버에서 다른 번역 서버를 한번 더 거쳐서 오기 때문에 시간이 오래 걸린다.
*마지막 읽은 메시지 index 수신 *
*친구 목록 업데이트 *
알림 설정 서버에 전송
유저 정보 조회
- 로그인 과정 중 친구 추천 리스트 생성, 채팅방 내부 유저 정보 조회를 할 때 API를 사용해서 유저 정보를 조회한다.

10가지라는 숫자가 그렇게 놀랍지 않을 수도 있지만 5번과 10번의 경우 로그인 마다 요청 횟수만도 엄청 많아서 한번 로그인할 때 많으면 정말 100개도 넘게 API를 보내고 있었다. (앱을 사용하지 않고 있는 동안 번역해야하는 메시지가 온 만큼 하나씩 번역 요청을 보냈으니.. 정말 한계가 없었던 수준이다. 😂)

신입이었던 내 눈에도 이 과정은 너무나도 비효율적이었다.

😒 ... API의 수가 너무 많은 것 같은데... 이거 통합해도 무리 없을 것 같은데 통합하는건 어떨까요?

감사히 내 의견은 받아들여졌다..! 그리고 멋진 시니어분들의 의견이 쌓여 멋지게 구조를 바꿀 수 있었다.

통합된 API 구조

API중 단순히 정보를 받아오는 API의 경우, 하나로 통합이 되었다. 그 결과 대부분의 API 들이 통합이 되었다.

로그인 - 유지
~~이모티콘 리스트 수신~~
자동 친구 추가 - 유지
~~단체방들 정보 업데이트~~
~~1:1 채팅방 정보 업데이트~~
~~메시지 번역~~
~~*마지막 읽은 메시지 index 수신 *~~
~~*친구 목록 업데이트 *~~
~~알림 설정~~ (삭제)
~~유저 정보 조회~~ (삭제)
통합 로그인 <-- new!!

API 통합 결과 👍

통합 로그인 API의 전송부터 수신까지 평균 15초(15000ms) 정도 걸리게 되었다.

이전보다는 분명 개선되었다는 것이 체감이 되었다. 하지만 목표치인 3~5초에는 한참 못미쳤다.

시도 2 : 통합 로그인 API에서 번역 API 분리

여전히 통합 로그인 API가 느린 이유

서버측에서 시간이 가장 오래 걸리는 이유는 역시, 번역 API 때문이었다.

언어마다 사용하는 API가 달랐는데, 이 중 특정 API는 하나의 번역 송수신에 약 0.7초_정도나 필요하였다. 여전히 번역해야하는 수 만큼 로딩 시간도 비례한 문제점도 있었다. 예를 들어, 로그인 시도했을 때 그동안 수신된 채팅이 30개라면 _번역에만 20초 정도를 소모해야하는 것이다.

하지만 번역을 굳이 로그인할 때 모두 할 필요는 없으므로 채팅을 보낼 때 서버에서 미리 번역을 해놓아 로그인 과정에서 번역을 하지 않아도 되도록 개선하였다.

번역 API 분리 결과

통합 로그인 API의 전송부터 수신까지 평균 100~200ms로 현저하게 줄일 수 있게 되었다!

시도 3 : 클라이언트 내부 데이터 저장 구조 변경

기존 클라이언트 데이터 저장소

1. Redux

2. SQLite

3. AsyncStorage

이것만 봐서는 그렇게 큰 문제는 없지 않을까? 라고 생각할 수 있다. 하지만문제는 따로 있었다.

대부분의 데이터를 저 세곳 모두 똑같이 저장을 한다는 점이다. 예를 들어, 친구 목록에 관한 데이터를 저장한다고 하면 Redux에 저장하고 SQLite에도 저장을 하고 전역 변수에도 저장을 한다는 뜻이다.

로그인 과정에서 발생하는 모든 데이터의 업데이트도 저렇게 세곳 모두 업데이트를 계속 한다.

하지만 저렇게 쓴 이유는 레거시 코드이기 때문에 명확히 알 수는 없지만 추측을 하자면

1. 상태관리를 하기 위해 Redux를 사용했다. 2. 앱을 종료했다가 다시 켜도 유지되어야하는 정보를 저장하기 위해 SQLite를 사용했다. (일반적인 Redux는 유지되지 않는다.) 3. 모든 정보를 Redux와 SQLite에 넣을 수 없으니 전역 변수에도 저장하여 개발 용이성을 높인다.

해결 방법

Redux-Persist를 사용하여 Redux의 정보가 사라지지 않도록 하면 SQLite를 사용하지 않아도 된다! 또한 상태관리까지 한번에 할 수 있다.

1. SQLite, AsyncStorage 삭제

Redux-Persist를 사용한다면 SQLite를 굳이 사용할 이유가 없기 때문에 프로젝트에서 삭제하기로 하였다.

실제로 React Native에서는 redux-persist를 SQLite보다 월등하게 많이 사용하고 있다.

일부 데이터는 AsyncStorage를 사용하고 있었는데... (몇몇 설정에 관한 정보) 굳이 AsnycStorage를 따로 써야하는 이유를 찾지 못했다.

결론 : SQLite와 AsyncStorage를 사용하는 코드는 삭제하였다.

2. Redux Persist 도입

기존에 앱을 재시작해도 유지가 되어야 하는 데이터의 경우에는 SQLite에 넣었다. 그리고 그런 데이터의 경우에는 대부분 상태관리도 필요하기 때문에 Redux에도 넣었다.

Redux Persist를 사용하면 SQLite에 넣는 과정없이 상태관리와 데이터 저장을 한번에 할 수 있어서 효율적이다.

Redux를 Redux Persist로 바꾸는 과정은 그리 어렵지 않았다. 궁금하신 분들은 링크 에서 확인해보시면 될것 같습니다! 😊

결과

우리 팀은 크게 3가지를 개선하였다. (이 외에도 자잘한 변경 사항도 있다.)

1. 비효율적인 로그인 과정에서의 API 구조

2. 로그인과정에서 번역 제외

2. 비효율적인 클라이언트 내부 데이터 저장 구조

그 결과, 평균 로딩시간이 기존 40초~5분에서 현재 3~5초로 90%이상 단축했다. :)

후기

성능을 튜닝한 경험이 생겨서 정말 기쁘다!

비록 딱 같은 유저가 기존 버전에서는 ##초가 걸렸는데 지금은 #초가 걸린다! 같은 자료는 없지만 정말 개편 이전에는 하루 웬종일 로딩창을 봐야 끝났는데 이제는 잠깐만 기다려도 로딩이 끝나는 점이 너무 좋다. 실제로, 로딩이 너무 길어서 로딩이 오류가 난게 아닌가? 하고 개발자들 마저 오해하는 상황도 많을 정도로 로딩이 정~말 오래걸렸었다. 몇초가 아니라 분단위로 로딩이 필요했다... 하지만 이제는 길어도 10초안에는 로딩이 되어서 체감이 커서 좋다. 단순히 UI를 더 그리고 바꾸고 기능을 하나 더 구현하는 것보다 성능 튜닝을 위해 고민하고 개발하고 테스트할 때가 훨씬 재미있었던 것 같다. 유익한 시간이라고 생각한다 👍

제대로 문서를 만들고 분석하고 개편하지 않은점이 아쉽다.

API하는데만 몇초정도 걸리고, 클라이언트 단에서는 어디서 얼마나 걸리는지, 기존 시간이 정확히 평균 시간이 어느 상황에서 어느 정도나 걸리는지 등을 분석하지 않고 바로 개편부터 한 점이 아쉽다.

API만 수정했을때 얼마나 단축되고, 내부 데이터 저장 구조만 개편 했을때 얼마나 단축되는지 미리 분석하지 않은 점이 너무 아쉽다.

지금 이 글을 작성하면서 성능 개선에 관한 글에는 이런 정확한 수치가 상당히 중요하다는 점을 알아 슬플 뿐이다.

데이터 구조를 바꾸는 것은 꽤 신중해야했다.

처음에는

아니 그냥 ~ SQLite, AsyncStorage쓰던거 redux-persist로 바꾸면 되는거니까 오래 걸려도 2주면 되겠지 😗~

라고 생각했다.

하지만 현실은 많이 달랐다. 구조를 바꿈으로서 사소한 모든 기능을 다시 개발해야 했다.

앱을 새로 만들듯 다시 해야 했다.

QA도 생각보다 엄청 많이 나오고... 2주면 될 줄 알았는데 기존 기능을 다 구현하고 크리티컬 버그까지 전부 수정하는 데에는 2달이 넘는 시간이 필요했다.

데이터 구조를 바꾼다는 것은 정말 신중하게 고려하고 해야하는 점 같다. 그냥 무턱대고 성능에 나쁘다고 막 바꾸는 행동은 위험하다.

참고자료 😎

https://npmtrends.com/react-native-sqlite-storage-vs-react-native-sqlite3-vs-redux-persist-vs-redux-session-storage-vs-redux-storage

포켓몬스터로 이해하는 Context switching!

Thu, 28 Jul 2022 14:28:37 GMT

Context switching이 뭔데요?

한줄 요약 : CPU가 한 개의 Task(process/Thread)의 상태를 저장하고 다음 진행할 Task의 상태값을 읽어 적용하는 과정입니다.

CPU는 기본적으로 한번에 한가지 일만 합니다. 하지만 우리의 프로그램들은 동시에 여러 일이 필요합니다. 하지만 중간 중간 선수 교체는 필요한 법이죠.

포켓몬스터를 하는데 포켓몬이 Process라고 생각하면 됩니다. *포켓몬이 하는 일은 Thread * 입니다.

포켓몬스터로 이해해봅시다. 결투중 어떤 포켓몬을 사용할지는 트레이너가 정합니다. *CPU가 무슨 일을 할 지는 OS(운영체제)가 정합니다. *

우리는 이제부터 포켓몬 트레이너(OS)입니다.

OS : CPU가 휴식하기에는 너무 일이 많단다! 일단 하나를 하고 있으렴

우리는 박사님의 조언에 따라 우선 파이리를 데려가기로 했습니다.

파이리의 선택은 정말 좋았습니다. 당장 필요했던 안전을 지켜주고, 요리가 필요할 때에는 불도 문제가 없었습니다.

식량 문제도 해결할 수 있었습니다. 하지만 저런,,,! 문제가 생겼습니다.

파이리가 불을 내고 말았습니다.

우리에게 필요한 것은 파이리가 아니라 꼬부기입니다...!!

나와라 꼬부기..!

꼬부기는 열심히 불을 꺼줬습니다. 우리는 꼬부기와 함께 여행을 지속했습니다. 역시 목 마를 때에는 꼬부기죠!

하지만 꼬부기랑만 다닐 수는 없습니다.

배는 너무 금방 꺼지고 배를 채우려면 파이리가 필요합니다. 우리는 배고파 죽을때 쯤 파이리를 다시 불렀고, 목말라 죽을때 쯤 꼬부기를 불렀습니다.

이쯤되면 생각이 납니다.

배고파 죽을것같을때, 목말라 죽을 것 같을 때 말고 그냥 정기적으로 꼬부기랑 파이리를 교체하자 !

그래서 우리는 스케줄을 짜기로 했습니다.

파이리와 꼬부기는 2시간 마다 교대로 소환되기로 하였습니다. 그리고 일도 정기적으로 하기로 했습니다.

파이리의 업무 목록

장작에 불 피우기 - 10분
식어가는 국 데우기 - 30분
꺼져가는 횟불에 불 붙이기 - 7분 ...

꼬부기의 업무 목록

파이리가 태운 꽃에 물주기 - 4분
너무 끓여서 짠 국에 물타기 - 20초
애교부리기 - 1시간 ...

파이리와 꼬부기는 업무가 많아서 모든 업무를 2시간만에 끝낼 수 없습니다. 다음에 소환될 때 이전에 하던 일을 바로 이어서 할 수 있도록 각 포켓몬은 본인이 뭘 하고 있었는지 수첩에 기록한 뒤 다음 포켓몬을 소환하기로 했습니다.

이처럼 Task(포켓몬, 포켓몬의 업무)를 교체하는 것을 Context Switching이라고 합니다.

우리는 2시간마다 스케줄에 맞게 포켓몬(Process)만 교체합니다. OS는 PCB(Process Control Block)정보를 바탕으로 Process를 교체합니다.

포켓몬의 업무는 포켓몬의 일 이므로 우리(OS)가 관리하지 않습니다. 포켓몬은 스스로 적은 수첩을 활용하여 업무 목록에 맞게 업무를 교체합니다. Process는 TCB(Task Control Block)이라는 내부 구조를 활용하여 Thread를 관리합니다.

포켓몬들도 소환되자마자 바로 일을 시작 할 수는 없습니다. 포켓볼에 들어가기 전에 뭘 하고 있었는지 기록했던 수첩도 읽고 스트레칭도 한번 하고 일을 시작할 수 있습니다. CPU도 Context Switching을 수행하는 동안 Cache를 초기화하고 Memory Mapping을 초기화하는 등 바로 일을 할 수 없습니다.

포켓몬들을 1분마다 소환한다면?

분명 일을 제대로 못할 겁니다. 소환되고 수첩 읽고 스트레칭하고 일 좀 할까? 하면 다른 포켓몬으로 교체될 테니까요. 대신에 업무를 자주 바꾸는건 어떨까요? 수첩읽고 스트레칭하는 시간은 필요없을테니 조금 더 시간이 절약되겠죠?

컴퓨터도 잦은 Context Switching은 성능 저하를 야기합니다.

멀티 프로세스를 통해 PCB를 Context Switching하는 것 보다 멀티 Thread를 통해 TCB를 Context Switching하는 비용이 더 적습니다.

정리

Context Switch는 Process 교체와 Thread 교체가 있다.
Process의 스케쥴링은 OS에 의해 PCB(Process Control Block)로 관리되며 Thread는 Process에 의해 TCB(Task Control Block)로 관리된다.
잦은 Context Switch는 성능 저하를 야기하며 PCB의 교체보다 TCB의 교체가 비용이 더 적다.
댓글이나 하트로 관심을 주면 작성자가 기쁘다

[JS] 이젠 알아야지.. var let const 차이

Mon, 11 Jul 2022 14:10:48 GMT

그동안.... var let const 애써 정확히 뭐가 다른지 무시했던 나날들... 이제 무시할 수 없다..!

1. 호이스팅

이 코드는 과연 실행이 될까?

a();

function a () {
  console.log("3");
}

정답은... YES!

그 이유는 JavaScript는 함수의 코드를 실행하기 전에 함수 '선언'에 대한 메모리부터 할당합니다. 우린 이걸 호이스팅이라고 부르기로 사회적으로 합의했어요

호이스팅 : 인터프리터가 변수와 함수의 메모리 공간을 선언 전에 미리 할당하는 것을 의미

console.log(num); // 호이스팅한 var 선언으로 인해 undefined 출력
var num = 6; // 선언과 초기화

var num = 6은 한 줄에 선언과 초기화를 했지만 호이스팅은 선언만 메모리에 미리 할당합니다. 만약 호이스팅이 되지 않았다면 ReferenceError 예외가 발생했을 겁니다. 위 코드는 아래와 같습니다.

var num;
console.log(num); // 호이스팅한 var 선언으로 인해 undefined 출력
num = 6; // 선언과 초기화

물론, let과 const로 선언한 변수도 호이스팅 대상이지만, 호이스팅시 undefined로 변수를 초기화 하지 않습니다. 따라서

console.log(num); // 호이스팅이 되었지만 let으로 ReferenceError 예외
let num = 6; // 선언과 초기화

var가 아닌 let으로 선언했다면 undefined로 초기화가 되어있지 않고 메모리 할당만 되어있어 ReferenceError 예외가 발생한다.

2. 변수 재선언, 재할당

var a = apple;
var a = tree; // OK!

let b = pretty;
let b = cute; // SyntaxError!
b = beautiful; // OK!

const b = cat;
const b = dog; // SyntaxError!
b = bird; // TypeError!

var의 경우 변수 재선언이 가능하다.

따라서 같은 이름으로 변수 선언해도 오류가 나지 않음. 하지만 let과 const는 변수 재선언은 안된다. const는 재할당도 되지 않는다.

이젠 알자, const 재할당!

const a = [1,2,3];
a.push(3); //ok!

const b = {name : "jon"}
b.name = "happy"//ok!
b = a; //TypeError!

const가 보호해주는 것은 할당 주소값이지 객체의 내용은 아닙니다. 따라서 배열이나 객체 속 내용은 변경해도 괜찮습니다. 하지만 아예 const로 할당된 객체에 다른 객체를 할당하면 안됩니다.

lire_eruel.log

HTML과 소개팅하기

HTML이란?

코드로 먼저 봅시다.

HTML 코드

제목입니다.

태그 사용법

1. 태그는 정해진 태그를 사용합니다. Java처럼 마음대로 선언하면 안돼요.

2. 태그 공통 문법

h4는 제목 태그 중 하나에요.

h4는 제목 태그 중 하나에요.

3. 주석달기

결과

태그 종류를 다 알아봐야할까?

개발 환경 추천(window)

시작하기

[TIL] Array vs Linked List

Array

Array란?

Array 장점

요소에 빠르게 접근할 수 있다.

Array 단점

삽입이나 삭제가 비효율적이다.

크기가 고정적이다.

Linked List

Linked List 장점

삽입이나 삭제가 빠르다.

동적 크기

Linked List 단점

결국 삽입이나 삭제가 O(n)시간이 필요하다.

Linked List의 종류

단일 연결 리스트 (Singly Linked List)

이중 연결 리스트 (Doubly Linked List)

원형 연결 리스트 (Circular Linked List)

언제 Array와 Linked List를 사용할까?

Array

Linked List

[TIL] TDD, 함수형 프로그래밍

TDD

TDD란 무엇인가?

TDD의 장점

1. 함수 리팩토링이 쉬워진다.

2. 요구사항에 더욱 집중 할 수 있다.

TDD의 단점

1. 느린 생산성

2. 진입 장벽

함수형 프로그래밍

함수형 프로그래밍이란?

immutable vs mutable

immutable

mutable

일급 객체 (first-class citizen)

일급 객체란?

[TIL] OOP, Restful API

객체 지향 프로그래밍

객체 지향 프로그래밍의 장점

객체 지향적 설계 원칙

Restful API

Restful API란?

REST 6가지 원칙

Uniform Interface (일관된 인터페이스)

Stateless

Caching

Client-Server

Hierarchical System

Code on demand

REST API 장점

REST API 단점

[TIL] 그리디 알고리즘

그리디 알고리즘

특징

예제 : 거스름돈

그리디 알고리즘의 정당성

코딩테스트에 응용

한국인이라면 당신도 가능하다. Next.js 오픈소스 기여! (자리 얼마 안남음)

그렇다면, 바로 시작합시다!

1. 해당 깃허브 페이지로 접속합니다.

2. 빈 자리 확인하기.

3. 작업 시작하기

프로젝트 Fork 하기