(완료) 일일 우테톡 2021.07.12~09.11

우아한 테크코스 3기 분들의 10분 테코톡 영상을 하루에 하나 읽고, 감상이나 내용 정리를 하기 위한 문서입니다.

일일 아티클에 이어서 일일 테코톡도 나만의 일일 퀘스트에 추가하기로 했습니다! 우테톡 영상은 100개가 넘지만 우선 우테코 3기 분들이 제작하신 영상들을 순서대로 보고, 이전 기수로 넘어갈 예정입니다.

🎉 시작해보자!

7월

• 2021년 7월 12일 (월) ⚾️ 제이온의 JCF

  • 음, 일단 자바 관련 전혀 모르는 부분이다. 시작부터 이걸 내가 봐야하나? 싶었지만 일단 편식(?)하지 않기로 해서 끝까지 보았다! 백엔드도 같이 공부해야하니까.
  • JCF는
    • 다수의 데이터를 쉽고 효과적으로 처리할 수 있는 표준화된 방법을 제공하는 클래스의 집합
    • 데이터를 저장하는 자료 구조, 데이터를 처리하는 알고리즘을 구조화해서 클래스로 구현해 놓은 프레임워크
  • Collection의 사용 목적이 같더라도 각 Collection마다 문법이 달라서 문제가 있어서 공통 인터페이스의 필요성으로 만들어진 것 같다.
  • List : 순서가 있는 데이터의 집합. 데이터의 중복을 허용한다
    • ArrayList, LinkedList, Vector, Stack ..
  • 스레드 안전. 멀티 스레드 환경에서 어떤 함수, 변수, 객체가 여러 스레드로부터 동시에 접근이 이루어져도 프로그래밍 실행에 문제가 없음을 뜻함. 비동기 방식은 스레드가 안전하지 않고, 동기 방식은 안전을 위해 사용한다.
  • Queue : 선입선출의 자료구조. 주로 LinkedList를 이용해서 구현함
  • Deque : 양쪽에서 추가/삭제가 일어날 수 있는 자료구조로, 사용 방식에 따라 Stack도, Queue도 될 수 있다.
  • Set : 중복된 요소를 저장하지 않고, 요소의 순서를 유지하는 자료구조
    • HashSet, LinkedHashSet, TreeSet ..
  • Map : Key와 Value를 쌍으로 저장하는 자료구조. 탐색이 빠르지만 데이터 순서를 보장하지 않는다.
    • Hashtable, LinkedHashMap, HashMap, TreeMap
  • 처음엔 자바? 봐야하나? 싶었지만 주 내용은 자료구조에 대한 설명이어서 많은 도움이 된 것 같다.
  • 프론트 개발을 하다보면 자료구조를 이렇게 까지 신경쓰진 않는데, 자바 개발에서는 자료구조가 엄청 중요한거같다.. 프론트도 더 깊게 들어가면 이런 자료구조를 모두 이용하면서 개발할까!?

• 2021년 7월 13일 (화) 🌱 시드의 제네릭

  • 제네릭이란 : 클래스나 메소드에서 사용할 내부 데이터 타입을 외부에서 지정하는 기법
  • 제네릭을 사용하는 이유
    • 자료형에 대한 검증이 컴파일 타임에 이루어지기 때문에 런타임에서 자료형에 안전한 코드가 실행된다.
    • 캐스팅 삭제. 반환값에 대한 타입 변환 및 타입 검사에 들어가는 노력을 줄일 수 잇고, 형변환이 없어지므로 가독성이 좋아진다
  • 이후 내용은 자바 기본 지식이 너무 부족해서 도저히 이해할 수 없었다..
  • TypeScript에도 제네릭이 나와서 관련이 좀 있을까 했는데 아직 이해하기엔.. 약간의 힌트만 얻고 만 것 같아..

• 2021년 7월 14일 (수) 🕶 곤이의 DOM&BOM

  • DOM
    • 문서에 대한 모든 내용을 담고 있는 객체
    • HTML, XML 문서의 프로그래밍 interface
  • 노드 객체는 12가지가 있다
    • 문서 노드
      • DOM 트리 최상위에 있는 루트노드(document)
      • HTML 문서당 document 객체는 유일함
    • 요소 노드
      • HTML 요소를 가리키는 객체
    • 어트리뷰트 노드
      • HTML 요소의 어트리뷰트를 가리키는 객체
      • 참조/변경 하려면 먼제 형제 노드인 요소 노드에 접근해야 함
    • 텍스트 노드
      • HTML 요소의 텍스트를 가리키는 노드
      • 접근하려면 먼저 부모 노드인 요소 노드에 접근해야 함
  • 모든 노드는 EventTarget, Node prototype을 상속 받는다
  • HTMLCollection vs NodeList 구분하기
  • 노드 추가 DOM API
    • innerHTML
    • insertAdjacentHTML
    • appendChild (앞에 2개에 비해 보안 이슈 없음)
  • DOM 자체는 빠르지만 DOM 트리가 수정 될 때 마다 새로운 렌더 트리, 레이아웃, 리페인트 과정이 느리다
  • BOM
    - 웹 브라우저 환경의 다양한 기능을 객체처럼 다루는 모델
    - 정해진 표준이 없어 브라우저마다 세부사항이 다르다
    
    

• 2021년 7월 15일 (목) 📍인비의 DTO vs VO

  • 많은 사람들이 DTO와 VO를 혼용 한다(J2EE Patterns라는 책 때문이라고 추측..)

  • DTO(Data Transfer Object)

    • 데이터 전달용
    • "계층 간" 데이터를 전달하기 위해 사용하는 객체(바구니)
    • Web Layer(Controller) < - DTO(데이터) 전달 - > Service Layer(Service)
    • 오직 getter/setter 메서드만 갖고 다른 로직 x
    • setter를 제거하고 생성자로 데이터를 받아서 불변 데이터를 만들 수 있다

  • Entity Class

    • 요청/응답값을 전달하는 용도로 쓰면 안 된다.

  • VO(Value Object) : 값 그 자체를 표현하는 객체

    • 지폐의 고유번호가 달라도 똑같은 만 원(값) 짜리다
    • 생성자를 통해서만 값을 초기화해야한다.
    • getter/setter 이외의 로직 가능

  • DTO vs VO

• 2021년 7월 16일 (금) 🧀 제리의 MVC 패턴

  • MVC는 왜 생겨난걸까
    • 이전에는 유지보수가 힘들었다.
    • 유지보수하기 용이한 패턴들이 하나씩 발견되면서 만들어짐
  • 웹에 비유해보자면
    • user => Controller : 사용자가 구글에 '코딩이라 검색'
    • Controller => Model : '코딩'에 대한 검색 결과 데이터 요청
    • Controller => View : 검색 결과 데이터를 View로 전달
    • View => user : 사용자에게 데이터를 기반으로 작성한 UI 보여줌
  • MVC를 지키면서 코딩하는 5가지 방법
    • Model은 Controller와 View에 의존하지 않는다.
    • View는 Model에만 의존해야 하고, Controller에 의존하면 안 된다.
    • View가 Model => Controller 로부터 데이터를 받을 때, 사용자마다 다르게 보여주어야 하는 데이터만 받는다.
    • Controller는 Model과 View에 의존해도 된다.
    • View가 Model로부터 데이터를 받을 때, 반드시 Controller에서 받아야 한다.

• 2021년 7월 17일 (토) 🥦 브콜의 This

  • 자바스크립트의 함수는 일급 객체라서 다양한 환경에서 호출 될 수 있다.
  • 함수가 호출될 때마다 this가 동적으로 결정 되는 것을 this가 그 객체에 binding된다고 표현한다.
  • 프로그램이 실행되면
    • JS 엔진이 실행 가능한 코드(전역 코드, 함수 코드 등..) 실행
    • 실행 문맥 생성 (렉시컬 환경 컴포넌트, this 바인딩 컴포넌트 ...)
  • 전역 실행 문맥
    • 함수가 실행된다
    • 함수 실행 문맥이 생성된다. (여기서 디스 바인딩 컴포넌트의 값이 결정된다)
  • this binding rules (우선순위 높은 순으로)
    • new 바인딩
      • 새로 생성되는 객체에 this가 바인딩 된다.
    • 암시적 바인딩
      • Object.function() // 바로 호출해야 암시적 바인딩이 된다.
      • .을 사용하는 점 연산으로 객체의 프로퍼티에 접근하면 Reference type을 반환한다. (base, name, strict)
      • 바로 ()를 하면 base의 객체를 실행한다.
      • 점 연산, 대괄호 연산을 제외한 다른 연산은 참조 타입이 아닌 해당 프로퍼티의 값만 반환한다.
    • 명시적 바인딩
      • call, apply, bind으로 명시적으로 this를 바인딩한다.
    • 기본 바인딩
      • 단독 호출시.
      • static 모드라면 undefined, 아니라면 window(브라우저)
      • nodejs 라면 함수코드에서는 global, 전역에서는 exports(모듈 객체)
  • this in Arrow Fucntion
    • 상위 실행 문맥을 유지하기 위해 사용한다.
    • 선언될 당시의 상위 스코프의 this를 바인딩한다.

• 2021년 7월 18일 (일) 📣 완태의 전략패턴

  • 전략이란 특정 목표를 수행하기 위한 행동 계획이다. 배민 로봇 전략을 예시로 들자면 이동 전략은 걸어서, 뛰어서, 날아서, 로켓으로 같은걸 말한다.
  • 소프트웨어 디자인을 하면서 공통적으로 마주치는 문제를 해결하는 방법의 패턴
  • 전략 패턴은 디자인 패턴 중 하나로, 객체가 할 수 있는 행위들 각각의 전략으로 만들어 놓고 사용하며 동적으로 전략 수정이 가능한 패턴
  • 전략 패턴의 의도는
    • 동일 계열의 알고리즘을 정의하고 (걷기, 달리기, 날기, 로켓)
    • 각 알고리즘을 캡슐화
    • 이들을 상호교환 가능하도록 함

• 2021년 7월 19일 (월) 💼 크리스의 Prototype

  • 프로토타입은 연결이다. 클래스의 복사/상속과는 다르다
  • 프로토타입은 나름 공부를 했던 영역이라 그런지 새로운 내용은 없었다! 그래도 다시 한 번 복습할 수 있어서 좋았다.
  • 프로토타입에는 있고, 생성된 객체에는 없는 메소드 a가 있을 때, 생성된 객체에 a메소드를 할당하는 문이 있다면 프로토타입에 덮어쓸까, 생성 객체에 추가할까?
  • 프로토타입의 메소드가 읽기전용이면
    • 엄격 : 에러
    • 비엄격 : 아무일 없음
  • 세터라면
    • 그냥 그 세터가 실행
  • 읽기 전용이 아니라면 생성된 객체에 추가된다. 다만 프로토타입으로의 접근이 사라짐
  • 오버라이딩 x 가려짐 o
  • 함수내에서 다시 함수를 선언하는 경우 프로토타입을 잘 활용하면 메모리 이득을 얻을 수 있다.

• 2021년 7월 20일 (화) 🎧 삭정의 Web 요청 & 응답과정

  • 웹과 인터넷은 다르다
  • 인터넷(인프라)은 컴퓨터가 연결되는 거대한 네트워크 구조이며, 웹은 그 위에서 동작하는 서비스 중 하나다.
  • 웹의 존재 이유는 정보 자원의 공유! 수 많은 요청/응답 사이클의 연속!
  • 서버는 정보 자원 제공, 클라이언트는 사용
  • http(s)는 이 둘 간의 요청/응답에 대한 규약이다
    • 비연결성 : 응답을 마치면 연결을 끊어버린다. 다음 요청은 새로운 연결
      • 네트워크 비용적으로 비효율적이라 HTTP/1.1부터 지정된 시간 유지하는 기능 추가됨
    • 무상태 : 서버/클라이언트가 하나의 요청이 처리되는 동안만 서로를 인지한다
      • 로그인을 유지해야할 때 불편
      • 쿠키, 세션, 토큰 등으로 상태를 기억하도록 함
    • 응답코드
      • 1xx : 요청 받았으며, 프로세스 계속 함
      • 2xx : 요청 성공. 처리함
      • 3xx : 요청 완료를 위해 리다이렉션 함. 추가조치 필요
      • 4xx : 요청 문법 틀림, 요청 처리 불가
      • 5xx : 서버가 유효한 요청에 대해 충족 실패
    • Method : 요청의 목적
  • 크롬의 network 탭에서 헤더와 바디를 살펴보자
  • 벨로그는 graphql을 쓰고있네

• 2021년 7월 21일 (수) ⛰ 로키의 상속보다는 Composition

  • 상속 is a
  • 상속의 장점
    • 중복 줄임
    • 확장성 증가
    • 다형성 구현
    • 개발 시간 단축
  • 상속의 문제점
    • 캡슐화를 깨뜨린다. 상위 클래스 구현이 하위 클래스에 노출
    • 따라서 자식은 부모에 강하게 결합 / 의존
    • 따라서 부모가 바뀌면 자식에 영향을 미친다.
  • 조합(composition) : 기존 클래스 확장 대신, 새로운 캘르스를 만들고 private 필드로 기존 클래스의 인스턴스를 참조하게 하는 설계 has a
  • 조합의 장점
    • 새로운 클래스는 기존 클래스 내부 구현에 영향 받지 않음
    • 캡슐화를 깨뜨리지 않음
    • 상위 클래스에 의존하지 않기 때문에 변화에 유연하다.
  • 상속은 명확히 is - a / 확장 목적과 문서화가 잘 된 경우 / 한 프로그래머가 상, 하위 클래스를 모두 컨트롤 한다면 사용해도 좋다.

• 2021년 7월 22일 (목) 🧹 와이비의 빌드와 배포

  • 빌드 : 소스코드를 실행 가능한 독립된 소프트웨어 가공물로 변형하는 과정
  • 빌드 결과물 JAR, WAR 등이 있다.
  • 자바의 빌드 도구 : 엔트 / Maven / Gradle
  • 배포 : 사용자가 사용할 수 있도록 소프트웨어를 제공하는 과정
  • 협업 시 마지막에 파일을 합치면 integration Hell 발생
  • 그렇다고 중간중간 합치면 지속적으로 시간을 소모함
  • CI(Continuous Integration): 지속적 통합. 코드 변셩사항마다 빌드, 테스트까지 자동 진행 / 결과물 보고 받고 리포에 자동 통합되는 프로세스
    • Travis / Jenkins / Git Actions 등의 도구가 있음
  • CD(COntinuous Deployment) : 개발자들이 코드에 변경 사항을 줄 경우, 파이프 라인을 통해 이동하여 프로덕션 단계까지 자동으로 배포되는 프로세스
  • DevOps : 개발 / 운영이 협력

• 2021년 7월 23일 (금) 🍗 피터의 이벤트루프

  • 자바스크립트 엔진 : 자바스크립트 코드를 해석하고 실행하는 인터프리터라고 생각하자
  • 힙(Heap) + 호출 스택(Call stack)으로 구성되어있다.
  • 힙은 메모리 할당되는 저장고 / 호출 스택은 실행된 함수가 쌓여 실행되는 것
  • 자바스크립트는 싱글 스레드 언어이다 => 호출 스택을 하나만 사용한다. 동시에 하나의 일만 처리할 수 있다.
  • 다만 브라우저는 여러개의 스레드가 사용된다 (Web Api, CallStack Queue..)
  • 이벤트 루프는 호출 스택을 지켜보다가 비어있으면 콜백 큐에 있는 함수들을 호출 스택으로 집어넣어준다.

• 2021년 7월 24일 (토) 😼 피카의 TDD와 단위테스트

  • 테스트 코드를 먼저 만들고 실제 프로덕션 코드를 테스트에 맞춰 개발
  • TDD는 자연스레 테스트 커버리지가 높아진다.
  • 오버 엔지니어링을 방지한다.
  • 설계에 대한 피드백이 빨라진다.
  • TDD는 설계 방법론이 아니다
  • TDD를 실패하는 사람
    • 코드의 목적, 가치, 기능이 아니라 그 기능을 어떻게 구현하고 있는지 테스트한다.
    • 테스트 케이스들이 구현체와 결합도가 높아진다
    • 구현체를 리팩토링하면 결합된 테스트 케이스가 다 깨진다.
  • 단위 테스트 : 일반적으로 메소드 단위로 테스트
    • 문제점을 발견
    • 변경이 쉽다
    • 품질 향상
    • 코드의 문서화
  • 빠르게 / 독립적으로 / 반복 가능하게 / 자가 검증하는 / 적시에

• 2021년 7월 25일 (일) 🌊 바다의 JUnit5 사용법

  • JUnit은 자바 단위 테스트 프레임워크다
  • Jupiter / Vintage / JUnit Platform 으로 구성되어있다.
  • 스프링 부트 2.2부터 기본으로 의존성이 추가됨
  • 사용법은 영상을 다시 보는게 나은거 같다. 내가 쓸 일은 없을거 같지만..

• 2021년 7월 26일 (월) 🍧 엘라의 Scope & Closure

  • 스코프 : 변수명, 함수명, 클래스명과 같은 식별자가 본인이 선언된 위치에 따라 다른 코드에서 자신이 참조될 수 있을지/없을지 결정되는 것
  • 스코프 체인은 단방향이며, 상위 스코프로 올라간다.
  • 동적 스코프 : 함수가 호출되는 시점에 따라 상위 스코프가 결정 됨
  • 정적 스코프 : 함수가 정의되는 시점에 결정 (렉시컬 스코프. 자바스크립트는 정적 스코프다)
  • 자바스크립트에서 함수는 태어나면 본인의 내부 슬롯에 상위 스코프에 대한 참조를 저장한다
  • 중첩 함수가 상위 스코프의 식별자를 참조하고 있고, 본인의 외부 함수보다 오래 살아있다면 클로저이다.
  • 내부 함수가 참조하는 외부 함수의 변수를 자유변수라고 한다.

• 2021년 7월 27일 (화) 🍟 웨지의 OOP

  • 사람이 현실을 바라보는 방법을 개발에 접목
    • 직관적으로 이해
    • 유지보수 용이
  • 객체는 다른 객체와 협력하는 역할을 맡고 있는 대상
  • 역할을 맡으면 책임이 생긴다
  • 책임을 다하기 위한 프로세스를 가지고 있다.
  • 협력 : 시스템 목표를 달성하기 위해 여러 객체가 참여해서 행동하는 것
  • 책임 : 각 객체가 협력 안에서 해야할 임무를 알고 수행하는 것
  • 역할 : 동일한 목적을 가진 책임의 묶음
  • 메세지 : 객체가 다른 객체에게 책임을 다하라고 요구하는 것. 무엇을만 알고 어떻게는 모른다
  • 객체는 의인화 되어있다.
  • 다형성 : 서로 다른 유형의 객체가, 동일한 메세지에, 다르게 반응하기 위해(같은 역할, 다른 메세지 처리 방법)
  • 데이터 중심이 아니라 책임 주도 개발을 해야한다.

• 2021년 7월 28일 (수) 🍒 포모의 상태 패턴

  • GOF 디자인 패턴은 크게 3가지. 생성 패턴/ 구조 패턴 / 행위 패턴
  • 이는 또 수십가지 패턴으로 나뉜다
  • 상태 패턴
    • 객체 자신의 내부 상태에 따라 행위를 변경하도록 하는 패턴
  • 언제 사용하나
    • 객체의 상태에 따라 객체의 행동, 런타임에 행동이 바뀌어야 할 때
    • 객체의 상태에 따라 달라지는 다중 분기 조건 처리가 너무 많을 때
  • 효과
    • 상태에 따른 행동을 일정 범위 안으로 지정하고, 서로 다른 상태에 대한 행동을 별도 객체로 관리한다
      • 새로운 상태가 추가되어도 context 코드가 받는 영향 최소화
    • 상태 전이를 명확하게 만든다.
    • 상태에 따른 동작 코드를 수정하기 쉬움
  • 상태패턴 vs 전략패턴
    • 코드내 조건문 대체 vs 상속 대체
    • 다음 상태를 객체 내부에서 vs 클라이언트에서 결정

• 2021년 7월 29일 (목) 🔥 유조의 Callback

  • call / back : 호출해라 / 되돌아와서
  • 언제 되돌아와서? callback함수의 제어권
  • 콜백 함수의 제어권을 넘겨받은 함수가 제어권을 갖는다
  • new Promise(executor)

• 2021년 7월 30일 (금) 🧇 크로플의 싱글턴과 정적클래스

  • 싱글턴 : 클래스의 인스턴스를 하나만 생성해서 어디서든 그 인스턴스만 참조할수록 하는 패턴
  • 생성자가 여러번 호출 되더라도 실제로 생성되는 객체는 하나!
  • 메모리 공유. 데이터 공유 쉬움
  • 정적 클래스 : 모든 메소드가 static인 클래스
  • 사용 이유 :
    • 상태를 가지지 않고 global access제공할 때
    • static은 컴파일 때 바인딩돼서 싱글턴보다 좀 더 빠름
    • 클래스 자체에 static을 붙여서 사용 불가. inner class 일 때는 가능
  • static 변수는 모든 인스턴스가 공유한다. 메모리 하나
  • static 메소드는 인스턴스로 생성하지 않아도 클래스에서 접근할 수 있다. 다만 static 변수만 사용 가능하다
  • 종속성 주입.
    
    

• 2021년 7월 31일 (토) 🍡 춘식의 Stream

  • 스트림: 데이터 컬렉션 반복을 멋지게 처리하는 기능이다!
  • 스트림 이전에는 How 중심의 외부 반복 / 이후는 What 중심의 내부 반복
  • 적극적 생성 : 모든 값을 다 처리하고 나서 결과를 넘겨주는 것 (코스 요리를 한 번에)
  • 게으른 생성 : 요청이 올 때마다 값을 넘겨주는 것 (코스 요리를 하나씩)
  • 쇼트 서킷 : 요청이 들어왔는데 그게 뭔지 모를 때, 적극적 생성자는 전부다 만들어서 주고 실패하지만 게으른 생성자는 하나씩 보여주다가 실패했을 때 그 순간 끝나버린다.
  • 즉 스트림은 특정 연산자를 사용할 때 여러 개의 조건이 중첩된 상황에서, 값이 결정나면 불필요한 연산을 진행하지 않고 조건문을 빠져나와 실행 속도를 높인다.

8월

• 2021년 8월 1일 (일) 🍻주모의 SPA

  • MAP : 서버 사이드 렌더링(SSR)을 사용해서 인터렉션마다 해당 페이지로 이동한다
  • SSR
    • 과정
      • 서버에 요청
      • 완전한 리소스 응답
      • 서버에 요청 (일부 변경을 위해)
      • 필요한 완전한 리소스 응답 (전체를 응답)
      • 앱이 깜빡이고, 전체가 다시 렌더되는 낭비
    • 장점
      • SEO 유리
      • 초기로딩 빠름
    • 단점
      • 불편한 사용자 경험
      • 서버 부담 증가
  • SPA : 클라이언트 라이드 렌더링(CSR)
    • 과정
      • 서버에 요청
      • 완전한 리소스 응답(모든 js를 주기에 느리다)
      • 서버에 요청 (일부 요청을 위해)
      • 해당 데이터만 응답
    • 장점
      • 변경이 빠르고 서버 부하 감소
      • 좋은 UX
    • 단점
      • SEO 불리
      • 초기 로딩 속도 느림
  • Contents 중심으로 CSR/SSR을 적절히 섞자
    
    

• 2021년 8월 2일 (월) 🎲 와일더의 Git Commands

  • branch : 동일한 소스코드를 기반으로 각자 다른 작업을 할 수 있게 해준다. 브랜치를 옮기는건 checkout도 있지만 switch도 있다.
  • 브랜치 합치기
    • merge
    • rebase
    • 몰랐는데 둘 다 하나의 브랜치에서만 실행하는게 아니라 상대 브랜치?에서도 해줘야한다고 한다.
  • HEAD는 현재 작업 중인 영역
  • git switch HEAD^ ^(캐럿)은 한 칸 뒤라는 의미
  • 작업 되돌리기
    • reset. 로컬에서만 쓰는게 좋음. 아예 삭제
    • revert. 삭제 대상 커밋도 남기고, 삭제했다는 커밋도 남김
    • git reflog로 대상 커밋을 찾아서 git reset --hard ${hash}으로 돌아가기 가능.
  • 커밋로그를 내 마음대로 cherry-pick
    • git log / reflog로 해쉬 찾아두고
    • git cherry-pick 5b343f 등으로 현재 커밋 뒤에 붙이기
    • git cherry-pick 5b343f^..5b3d3f. ^..로 범위 지정 가능

• 2021년 8월 3일 (화) 🍟 웨지의 Git 브랜치 전략

  • git branch 전략 : 여러 개발바가 협업하는 환경에서 github 저장소를 효과적으로 활용하기위한 work-flow
  • 배포시 어느 브랜치를 기준으로 해야할지, 어느 브랜치가 최신인지 알 수 있다
  • git-flow / github-flow
  • git-flow
    • master : 배포 가능한 버전
    • develop : 다음 버전 개발 중
    • feature : 기능 개발
    • release : 다음 버전의 배포가 완성된 develop을 기준으로 qa 등 진행
    • hotfix : 배포된 master의 급한 문제 해결
    • 한 달 이상 긴 호흡으로 주기적 배포, QA, hotfix 등을 수행할 여력이 있으면 적합
  • github-flow
    • 배포가능한 maste만 존재
    • 간단하고 빠르게 만들며 항상 배포가 되어 있어야하는 프로젝트에 적합

• 2021년 8월 4일 (수) 📢 욘의 프레임워크 vs 라이브러리 vs API

  • 프레임워크 : 개발할 때 자주 사용되는 기능을 한 번에 제공해서 개발 효율을 향상시키는 소프트웨어 환경
    • 공통 개발 환경을 제공하기에 협업에 용이
    • 개발 할 수 있는 범위가 제한 됨
    • 제어의 역전
  • 라이브러리 : 개발자가 사용할 수 있는 API를 목적에 따라 나누어 정의한 묶음
    • 개발에 필요한 것들을 모아둔 일종의 저장소
    • 필요할 때 호출
    • 제어의 역전 x 흐름을 제어한다
  • API : 다른 프로그램이 제공하는 기능을 제어할 수 있게 만든 인터페이스
    • 다른 프로그램 다리 역할
    • 구현이 아닌 제어 담당
    • API를 조합에 원하는 프로그램 만들 수 있음

• 2021년 8월 5일 (목) ⏰ 아마찌의 ORM vs SQL Mapper vs JDBC

  • Persistence(영속성) : 데이터를 생성한 프로그램이 종료되더라도 사라지지 않는 데이터의 속성
  • JDBC(Java Database Connectivity) 자바에서 DB에 접속하도록 하는 API
  • JDBC를 뭘 쓰냐에 따라 ODBC, ORACLE, MYSQL등에 접근 가능
  • SQL을 사용하면서 몇 가지 문제가 발생했다. 이를 해결하기 위해 프레임워크가 등장
  • SQL Mapper : 객체의 필드를 SQL문과 매핑해서 데이터를 객체화
    • 쿼리 수행 결과, 객체 필드를 맵핑 / RowMapper 재활용
    • JDBC에서 반복적으로 해야하는 작업들 대신 해줌
    • MyBatis
    • 특정 DB에 종속적으로 사용하기 쉬워짐
    • 테이블 필드가 변경되면 관련된 내용을 직접 수정해야함
  • 패러다임 불일치 문제
    • 객체지향으로 설계한 내용을 관계형 DB 테이블에 저장하는데 어려움이 있다.
    • 객체 지향은 추상화, 상속, 다형성을 지향하고 RDB는 데이터 중심의 구조다. 즉 각자 지향하는 목적이 다르기에 사용법, 표현법이 다를 수 있다. 이를 패러다임 불일치라한다.
  • ORM : 객체와 관계형 DB를 맵핑
    • 페러다임 불일치 문제 해결
    • 생산성 향상 (CRUD용 SQL 작성 안 해도 됨)
    • 데이터 접근 추상화, 벤더 독립성
    • 유지보수 용이
    • 복잡한 쿼리 사용에는 어려울 수 있으나 다른 도구(?)를 사용하면 해결할 수 있음

• 2021년 8월 6일 (금) 🍟 웨지의 인텔리제이 디버깅

  • 인텔리제이. IDE
  • resume : 다음 브레이크 포인트로 넘어간다
  • stepover : 다음 라인으로 넘어간다
  • stepinto : 메소드 안으로 들어간다.
  • stepout : 밖으로 나온다(실행 후)
  • 브레이크 포인트 우클릭하면 컨디션을 넣을 수 있다.

• 2021년 8월 7일 (토) 🐭 미키의 웹 접근성 & 표준

  • 왜 웹표준을 지켜야할까?
  • 웹 표준 : 어떤 운영체제, 브라우저를 사용하여도 동일한 컨텐츠를 볼 수 있돋록 웹에서 표준적으로 사용되는 기술, 규칙
  • 동일한 컨텐츠란 완전히 똑같은 화면이 아니라 모든 플랫폼에서 동등한 수준의 정보에 접근이 가능함을 의미한다
  • 초기에는 넷스케이프 vs 익스플로러의 싸움으로 표준이 없었고, 승자인 익스플로러가 activeX 같은 자사 제품(윈도우)에서만 동작하는 기술을 대거 도입하는 등 문제가 있었음
  • step1~3은 비표준, step4가 확정 권고안으로써 표준이다.
  • 웹표준 장점
    • 검색엔진 최적화에 용이하다
    • 개발자가 더 이해하기 쉬워짐
    • 구조와 표현의 분리
    • 웹 접근성을 높임
  • 웹 접근성: 장애인/노인 등 개인의 능력에 상관없이 웹 페이지의 정보에 접근할 수 있도록 보장하는 것
  • 스크린 리더가 html 대화형 요소에 접근해서 읽어준다
  • 대화형 요소란 anchor, button, input tag처럼 사용자와 상호작용 할 수 있도록 설계된 태그이다

• 2021년 8월 8일 (일) 🐶 코기의 Servlet vs Spring

  • 서블릿은 동적 페이지를 생성하기 위해 웹 서버에 붙이는 프로그램
  • 요청을 분석하고, 처리해서, 규약에 맞춰 응답하는 일련의 동작을 메소드로 처리할 수 있다.

• 2021년 8월 9일 (월) 🏀 에어의 Spring vs Spring Boot

  • Spring이란 Spring Framework, Spring Boot, Spring data등 여러 프로젝트의 모음을 뜻한다.
  • 프로젝트는 각자 모듈을 가지고 있다. Spring MVC같은 것
  • Spring Framework는 개발자들이 핵심 비즈니스 로직에만 집중할 수 있도록 하는 객체 지향 프레임워크
  • Spring Boot는 Spring 어플리케이션을 쉽게 만들 수 있게 해준다.
  • Spring의 설정이 점점 더 복잡해졌다. Spring Boot는 Spring을 간단하게 쓸 수 있게 해주는 프로젝트의 하나이지 별개로 사용할 수 없다.
  • 장점으로는
    • 의존성 관리. 자주 사용하게 되는 모듈간의 의존성과 버전 조합을 제공. 각 모듈의 현재 스프링 부트의 버전에 가장 적합한 버전 제공
    • 자동 설정.
    • 내장 WAS.
    • 모니터링

• 2021년 8월 10일 (화) 🥁 지그의 Virtual DOM

  • 브라우저의 동작 방식
    • DOM Tree 생성 / render tree 생성 / layout / paint
  • DOM 조작을 최소화하기 위해서 real DOM을 본 딴 virtual DOM 등장
  • 자바스크립트 객체. 실제 DOM이 아닌 메모리에서 사용.
  • DOM fragment의 변화를 묶어서 적용하고 기존 DOM에 던져주는 과정을 추상화&자동화 하는데 사용한다.
  • Virtual DOM. UI의 가상적인 표현을 메모리에 저장하고, ReactDOM과 같은 라이브러리에 의해 실제 DOM과 동기화하는 개념 (재조정)
  • Virtual DOM이 업데이트 되면 이전 Virtual DOM 스냅샷과 비교한다.
  • Diffing 알고리즘
    • element 속성 값만 변한 경우에는 속성 값만 업데이트한다
    • element의 태그/컴포넌트가 변경된 경우 해당 노드를 포함한 하위 모든 노르를 unmount하고 새로운 Virtual DOM으로 대체한다.
    • 이후 react DOM에 적용
  • Virtual DOM이 무조건 빠르고 좋은건 아니다
    - 단순 정보제공 사이트라면 인터렉션이 없거나 적기 때문에 성능이 다를 수 있다.
    - diffing 알고리즘은 빠르긴 하지만 추가 작업이기 때문에 불필요할 수 있다.
    - SPA같은 인터렉션이 많고 규모가 큰 프로젝트는 Virtual DOM이 더 나은 대안일 수 있다.
    - 상황에 맞게 선택하자.
    
    

• 2021년 8월 11일 (수) 👳‍♂️ 알리의 Web Server vs WAS

  • 웹 서버
    • 브라우저로부터 HTTP 요청을 받고 알맞은 정적 컨텐츠(html, 이미지..)를 제공한다
    • 동적 컨텐츠를 요구하면 웹 어플리케이션 서버로 전달해서 처리한 결과를 클라이언트에 전달한다
  • 웹 어플리케이션 서버
    • 클라이언트로부터 HTTP요청을 받을 수 있다
    • DB조회, 비즈니스 로직 등을 통해 동적 컨텐츠를 생성/제공한다.
    • 정적 컨텐츠를 제공할 수도 있다.
  • 동적 컨텐츠
    • 요청 인자에 따라 바뀔 수 있는 컨텐츠
  • 웹 서버가 필요한 이유
    • 책임 분할을 통한 서버 부하를 방지한다
    • 여러 대의 WAS load balancing(로드 밸런싱).
      • load balancing : 들어온 요청을 나누어서 각 WAS에 할당하는 것. 분산처리
    • 여러 대의 WAS Health check
      • Health check: 서버에 주기적으로 HTTP 요청을 보내서 서버 상태를 확인한다.
      • interval / fails / passes
    • 보안. 리버스 프록시를 통해 실제 서버를 외부에 노출하지 않는다.
  • 확장성/안정성을 고려하면 웹 서버가 필요하다.

• 2021년 8월 12일 (목) 🌟조앤의 Forward Proxy vs Reverse Proxy vs Load Balancer

  • 로드 밸런서
    • 여러 대의 서버가 분산처리를 할 수 있도록 요청을 나누어주는 서비스
    • 요청 분배 판단 근거
      • 단순한 엑세스라면 웹 서버의 부하 상태
      • 미리 웹 서버의 능력을 설정하고 판단
    • 종류 L2 / L3 / L4 / L7
      • L2 : 맥 주소
      • L3 : IP 주소
      • L4 : 전송 계층에서
      • L7 : 응용 계층에서
  • 프록시
    • 서버-클라이언트 사이의 중계 서버로서, 통신을 대신 수행하는 역할
    • 포워드 프록시
      • 클라이언트 - 인터넷 사이에서 클라이언트 대신 서버에 요청을 대신 보냄
      • 로컬 네트워크 - 인터넷 사이 트래픽 제어 가능 (초등학교 부적절 컨텐츠 접근 제어)
    • 리버스 프록시
      • 서버 - 인터넷 사이에서 서버 대신 클라이언트에 응답 대신 보냄
      • 웹서버 바로 앞에 있어서 웹서버로의 요청도 처리 가능
      • 웹 서버 캐시 등으로 성능 개선 가능
    • 입구 프록시
      • 인터넷 서비스 공급자 접근 지점에 위치해서 속도를 개선한다
    • 네트워크 교환 프록시
      • 캐시를 이용해 인터넷 혼잡을 완화하고 트래픽을 감시한다
    • 왜 사용할까
      • 필터로써 사용한다
      • 접근 제어. 허가된 클라이언트를 차단하거나 비밀번호 요구
      • 캐시. 인기있는 요청 캐싱해서 서버에 접근하지 않고 바로 응답 가능
      • 익명.
      • 로드 밸런싱

• 2021년 8월 13일 (금) ☕️ 체프의 브라우저 렌더링

  • 브라우저 구조
    • 사용자 인터페이스 : 웹페이지를 제외하고 사용자와 상호작용 부분(주소창, 새로고침 등)
    • 렌더링 엔진 : HTML/CSS 파싱, 표시
    • 브라우저 엔진 : 유저 인터페이스, 렌더링 엔진 연결
    • 네트워킹 : 네트워크 요청 수행
    • UI 백엔드 : 체크박스/버튼 같은 기본적인 위젯을 그려줌
    • 데이터 파트 : localStorage/Cookie 등 보조 기억 장치에 데이터 저장
    • 자바스크립트 인터프리터 : 자바스크립트 코드를 실행(V8)
  • 각 브라우저 렌더링 엔진, 사파리 webkit / 파이어폭스 Gecko / 크롬 Blink
  • 렌더링 엔진의 목표
    • HTMl/CSS/JS/이미지 등 웹 페이지에 표함된 모든 요소를 화면에 보여준다
    • 업데이트가 필요하면 효율적으로 렌더링을 할 수 있는 자료구조를 생성한다.
  • Critical Rendering Path
    • DOM / CSSOM Tree를 생성
    • Render Tree 생성
    • Layout : 뷰포트 내 각 요소의 정확한 위치, 크기를 계산한다
    • Paint : 실제 픽셀로 그리는 과정
  • 사용자 동작으로 css가 변경되거나 애니메이션이 동작한다면
    • 1. 레이아웃이 다시 발생하는 경우
      • 주로 요소의 크기나 위치가 바뀔 때
      • 브라우저 창의 크기가 변경되었을 때
    • 2. 페인트부터 다시 발생하는 경우
      • 주로 배경이미지 / 텍스트 색상, 그림자 등 레이아웃 수치를 변화시키지 않는 스타일 변경이 일어났을 때
    • 3. 레이어 합성만 다시 발생하는 경우
      • 레이아웃, 페인트를 하지 않아서 성능상 가장 큰 이점
  • 애니메이션 최적화 팁
    • 크롬 개발자 도구 - performance - 녹화
    • 쩜삼 눌러서 rendering으로 들어와서 / paint flashing 체크
    • 브라우저 화면에서 어떤 부분이 페인트 되는지 볼 수 있다.

• 2021년 8월 14일 (토) 🌷 코다의 Process vs Thread

  • 실행 단위 : 하나의 CPU Core에서 실행하는 하나의 단위로 프로세스/스레드를 포괄하는 개념
  • (부연설명 없는) 프로세스 : 하나의 스레드만 가지고 있는 단일 스레드 프로세스
  • 동시성(Cuncurrently) : 한 순간에 여러가지 일이 아니라, 짧은 전환으로 동시에 여러 일을 처리하는 것처럼 보이는 것
  • 소스코드(프로그램)가 실행되면 프로세스가 된다
  • 프로세스가 실행되기 위해서는
    • 메모리를 할당 받아야한다
      • Code / Data / Heap / Stack
    • 해당 프로세스에 대한 정보를 담고 있는 PCB 블럭 생성
      • Pointer / Process State / Process Number / Program Counter
  • 컨텍스트 스위칭
    • 프로세스의 경우 모든 자원을 옮겨야하지만 멀리 스레드는 Code, Data, Heap등은 공유하고 Stack만 스위치한다 => 캐시 적중률이 올라가며 효율적
  • 멀티 스레드가 무조건 좋은가?
    • 장단점이 있다. 멀티 스테드는 리소스도 효율적이지만 긴밀하게 연결되어 있기 때문에 하나의 스레드가 프로세스 전체에 영향을 미칠 수 있다.
    • 멀티 스레드는 스위칭 비용도 비싸고, 리소스도 잡아먹지만 멀티 스레드보다 안정적이다
  • 멀티코어 : 프로세스/스레드는 소프트웨어, 멀티코어는 하드웨어적 개념이다
  • 리눅스에서 프로세스/스레드

• 2021년 8월 15일 (일) 🐰 멍토의 Blocking vs Non-Blocking, Sync vs Async

  • Blocking : 자신의 작업을 진행하다가 다른 주체의 작업이 시작되면, 다른 작업이 끝날 때까지 기다렸다가 자신의 작업을 시작하는 것
  • Non-Blocking : 다른 주체의 작업에 상관없이 자신의 작업을 하는 것
  • 다른 주체가 작업을 할 때 자신의 제어권이 있는지/없는지
  • Synchronous : 작업을 동시에 수행하거나, 동시에 끝나거나, 끝나는 동시에 시작함
  • Asynchronous : 시작, 종료가 일치하지 않으며, 끝나는 동시에 시작을 하지 않음
  • 결과를 돌려주었을 때 순서와 결과에 관심이 있는지/없는지

• 2021년 8월 16일 (월) 🌳 나봄의 CORS

  • SOP(Same Origin Policy) : 다른 출처의 리소스를 사용하는 것을 제한하는 보안 방식
  • 출처(origin)은 protocol, host, port로 구성됨
  • 인터넷 익스플로러의 경우 port가 달라도 동일 origin이라고 판단한다
  • CORS(Cross-Origin-Resource-Sharing): HTTP 헤더를 사용해서 다른 출처의 선택한 자원에 접근할 수 있는 권한을 브라우저에게 알려주는 것 체제
  • CORS 접근제어 시나리오
    • 프리플라이트 요청 (Preflight Request)
      • 사전 확인 작업
      • 본요청을 보내기 전 OPTIONS 메소드를 통해 cross origin 요청이 가능한지 확인하고, 가능하면 본 요청을 보내는 방식
      • 요청 header에 origin / Access-Control-Request-Method / Access-Control-Request-Headers를 담아 보낸다. 뒤에 2개는 본요청의 메소드, 헤더
      • 응답 헤더에 Access-Control-Allow-Origin / Access-Control-Allow-Methods / Access-Control-Allow-Headers / Access-Control-Max-Age(캐싱 기간)이 담겨 온다
      • 응답 코드는 200대여야하며, 응답 바디는 비어있는게 좋다.
      • CORS를 모르는 서버를 위해 필요하다. 프리 플라이트를 하지 않으면 서버에서는 요청을 처리했는데(db 삭제 등) 정작 브라우저에서는 에러가 나면서 서버 데이터만 처리된 꼴이 된다.
    • 단순요청 (Simple Request)
      • 바로 본요청을 보낸다
      • GET / POST / HEAD 만 가능
      • Content-Type이 아래 3개중 하나여야 한다
        • application/x-www-form-urlecoded
        • multipart/form-data
        • text-plain
      • header는 아래 4가지만 허용한다
        • Accept
        • Accept-Language
        • Content-Language
        • Content-Type
    • 인증정보 포함 요청 (Credentialed Request)
      • 인증 관련 헤더를 포함할 때
      • 클라이언트에서는 credentials : includes를 해야하며
      • 서버에서는 Access-Control-Allow-Credentials :true를 해야한다. 이 때 Access-Control-Allow-Origin : \*은 안 된다
  • CORS 해결 방법
    • 프론트 프록시 서버 설정
    • 직접 헤더에 설정하기
    • 스프링 부트를 이용하기

• 2021년 8월 17일 (화) 🤷‍♂️ 현구막의 리눅스 메모리 관리

  • 메모리는 주소로 인덱싱하는 커다란 덩어리다. 배열이다
  • 코드의 메서드, 변수들을 심볼릭 주소, 컴파일러가 변환 시킨 숫자 주소를 논리 주소(가상 주소) 라고 한다. 이 논리주소는 중복될 수 있다.
  • 논리주소에 각각 다른 주소가 하나 더 붙어 물리 주소가 된다.
  • CPU는 논리 주소만 읽는다.
  • 따라서 소프트웨어적으로는 물리주소를 읽을 방법이 없다
  • 이를 도와주는 하드웨어가 MMU(Memory Management Unit)
  • 메모리 공간에 구멍을 메우기 위해 여러 방법(ex 스와핑 기법. 느리다)이 존재하지만 프로그램을 잘라서(Frame) 메모리에 저장하는 방식(페이징 기법)이 채택 됨'
  • 즉 메모리가 관리되는 방식은
    • 현대 메모리는 paging을 베이스로한 기법을 채택했으며
    • 하드디스크를 swap area로 활용
    • MMU, TLB 같은 하드웨어의 지원을 받아 page table을 확인하고 메모리 참조
  • 리눅스는 이 와중에
    • 가상 메모리로 사용자 프로세스를 속이며
    • I/O 장치 관리 를한다

• 2021년 8월 18일 (수) 🕺 루트의 리눅스 파일 시스템

  • 파일이란 컴퓨에서 의미가 있는 정보를 담은 논리적 단위
  • 실행/데이터 파일
  • 파일 시스템. 파일의 생성, 관리 등을 효율적으로 하기 위함
  • 윈도우 NTFS / 맥 APFS / 리눅스 ext1~4
  • ext3
    • 파일의 할당/접근/보호/일관성 기능
  • 블록 : 하드디스크와 데이터를 주고 받을 때 사용되는 논리적 단위 (일반적으로 4KB) 메타 데이터/데이터로 구성
  • 디렉터리도 파일로 관리한다
  • 파일 접근 권한 방법 2가지 Access Control List / 접근 권한 비트
  • read / write / execute
  • 각각 디렉터리 내 파일 리스트 접근 권한 / 생성,삭제,이름변경 권한 / 디렉터리 접속, 디렉터리내 파일 접근 권한

• 2021년 8월 19일 (목) 📖 카일의 프론트엔드의 비동기

  • 프론트엔드에서 비동기를 왜 처리해야하고, 왜 해당 기술들이 생겨났을 까
  • 단방향 웹에서 사용자와 상호작용하는 웹으로 발전했다
  • "대기"가 발생함. 무언가를 기다리는건 유저가 아닌 브라우저의 역할이다
  • 제어권을 잃은 콜백
  • Promise 미래의 값을 반환할 수도 있는 함수를 캡슐화한 객체
    • 장점
      • 제어권을 확보함. 신뢰할 수 없었던 콜백 방식의 여러 상황이 대처 가능해짐
      • 체이닝 구조로 구조화된 콜백 작성
    • 단점
      • Promise 외부에서 Promise 내부의 연쇄 흐름에 대한 예외 처리 어려움
      • 단일 값을 전달하기에 연관성이 부족한 여러 값을 넘기려면 객체/배열로 감싸야 함
      • 단순 콜백에 비해 성능 낮음
  • 가독성이 좋지 않은 콜백
  • 인간의 사고 방식(선형적)과 좀 다르기에 친숙하지 않다
  • generator. 함수를 도중에 중단하고, 중간 지점에 값을 보낼 수 있다 => 외부의 값을 기다렸다가 받은 시점부터 함수를 다시 실행
  • async await
    • 장점
      • await를 통해 반환 받은 값이 Promise의 수행값이기에 외부에서 예외 처리 용이
      • 가독성 굳
    • 단점
      • Promise에 대한 이해가 선행되어야 함
      • 하나의 함수 안에서 다수의 Promise를 병렬 처리할 수 없음 => Promise.all / Promise.race등 사용
      • async를 일일이 선언해야할 수도 있음

• 2021년 8월 20일 (금) 👍 파즈의 OSI 7 Layer

  • 국제표준기구 iso가 발표한 네트워크 모델
  • 7. 어플리케이션 계층. 응용프로세스를 직접 사용해서 응용 서비스 수행
    • FTP / HTTP / SMTP / Telnet
  • 6. 프레젠테이션 계층. 데이터 변환/압축/암호화
  • 5. 세션 계층. 세션 열고/닫음
    • 세션 복구도 가능.
    • 체크포인트로 용량을 지정(ex 5MB)하면 중간에 끊겨도 5MB단위로 저장되어 있음
  • 4. 트랜스포트 계층. 서로 다른 네트워크간 전송 담당
    • 세그멘테이션/흐름제어/오류제어
    • 세그멘테이션 : 작은 단위(세그먼트)로 나눈다. 비디오 버퍼링과 같은 거
    • 흐름제어. 전송량을 조절하는 것
    • 오류제어. 데이터 손실을 확인해서 다시 받는 것
  • 3. 네트워크 계층. 라우터, IP
  • 2. 데이터 링크 계층. 동일한 네트워크 데이터 전송 담당
    • 프레임이 오류나면 데이터 조각 버려버림(다시 요청 안 함)
  • 1. 물리 계층
    • 위의 비트 단위를 전기신호로 변환/전송
  • 우리는 주로 TCP/IP 모델 사용 중
  • TCP는 데이터 손실을 관측해서 재요청함 => 안정
  • UDP는 데이터 손실 관심 없음 => 대신 빠르다

• 2021년 8월 21일 (토) 🎪 도비의 프론트엔드에서의 테스트 종류

  • 테스트는 발생 가능한 결함을 검증, 어플이 요구사항을 충족하는지 검증
  • 개발 과정에서 변경사항이 새로운 결함이 생기는지 확인
  • 테스트는 내 코드에 대한 자신감이 생긴다!
  • 리팩토링, 새로운 기능 추가 등이 수월해짐
  • 정적 테스트
    • 코드를 실행하지 않고 테스트
    • 구문오류/스타일 검증 등
    • Esling, TypeScript
  • 단위 테스트
    • 작은 단위의 기능 테스트
    • 복잡한 알고리즘이 제대로 동작하는지 확인
    • Mocking 필요
    • 작성 비용 낮음 / 실행 속도 빠름
    • Jest
  • 통합 테스트
    • 어플리케이션 여러 부분이 통합되어 상호작용이 잘 되는지 테스트
    • 단위 테스트보다 큰 범위, 페이지 규모의 테스트
    • 앱의 모든 기능이 제대로 동작한다는 확신을 가질 수 있음
    • Jest, RTL, Enzyme
    • 중간에 있어서 가장 비중이 큼
  • E2E 테스트
    • 실제 사용자가 사용하는 환경 조건에서 전체 시스템 테스트
    • API/DB 등 외부서버 통합해서 테스트
    • cypress slenium
  • 프론트엔드 테스트 대상
    • 사용자 이벤트 / API 서버 통신 / UI
    • UI 테스트는
      • 스냅샷 테스트 : HTMl가 구조대로 렌더되었는지
      • 시각적 회귀 테스트 : HTML+CSS 컴포넌트가 실제 브라우저에서 의도한 모습으로 렌더되는지
  • 테스트 환경
    • 브라우저(느림) / Node
    • 크로스 브라우징 테스트가 필요한가?
    • 브라우저 실제 동작에 대한 테스트가 필요한가?
    • 그 외에는 Node.js환경에서 테스트하자

• 2021년 8월 22일 (일) 🎃손너잘의 HTTP1.1, HTTP2, 그리고 QUIC

  • 웹 서비스 성능 하락의 가장 큰 요인
    • 레이턴시 > 대역폭
  • TCP위의 HTTP
    • 3 way handshake
    • 느린 전송. 최대 데이터 크기 한계를 두고 여러번 송신하면서 최대 데이터 크기를 판별
  • HTTP 1.0은 요청마다 새로 연결하고, 끊고를 반복(커넥션) => 레이턴시 생김. 느린 전송까지 겹치면서 성능 떨어짐
  • keep alive로 연결을 끊지 않고 남길 수 있었지만 표준이 아니라서 잘 안 씀.
  • HTTP 1.1 에서 지속 커넥션 지원
  • HTTP는 데이터를 순서대로 주고 받아야해서 동기적으로 이루어져야만 했음. => 파이프라인
  • 멀티 플렉싱. 요청 순서 상관없이 병렬처리
  • HTTP 2.0 스트림
    • 스트림 : 전송되는 데이터에 특별한 식별자 붙였다고 생각하자
  • Head of Line Blocking. TCP 는 순서대로 요청을 처리하기에 하나가 막히면 뒤에 요청이 대기하는 현상
  • QUIC. 독립 스트림

• 2021년 8월 23일 (월) 🎁 브랜의 프론트엔드에서 Component란

  • 컴포넌트는 전체의 부분
  • 큰 문제를 작은 문제로 나눈다. 작은 단위부터 설계하고 조립한다
  • XML로 필요한 데이터만 받게 되면서 웹이 더 복잡해짐. => 작은 웹으로 나눠야한다!
  • 아토믹 디자인
  • 디자인 시스템. 컴포넌트와 스타일을 관리한다
    • 제약을 통해 올바른 방향으로 유도
    • 일관된 인터페이스 제공
    • 유지보수 용이하다

• 2021년 8월 24일 (화) 🌳 나봄의 인증과 인가

  • 인증. 나는 누구인가. 사용자는 누구인지 확인한다. (로그인)
  • 인가. 나의 권한은 어디까지인가. 이 사용자는 권한이 어디까지인가.
  • HTTP는 요청을 처리하면 연결이 끊긴다. 휘발성. 상태보존 안 함
  • 상태를 유지하기 위한 방법
    • 쿠키.
      • 브라우저에 저장
      • Domain / Expiration / Host Only / Session / Secure / Http Only
      • 보안에 취약,
    • 세션.
      • 서버에 저장
      • 쿠키에 비해 상대적으로 안전
      • 단, 서버확장 부담 / 멀티 디바이스 환경 고려사항 / 서버 메모리 소비 등의 단점
    • 토큰.
      • 브라우저에 저장
      • 서버 부담 적음 / 서버확장 o / 멀티 디바이스 o
      • 강제 만료 불가능 => 유효기간사용

• 2021년 8월 25일 (수) ☀️ 썬의 모듈 번들러와 빌드도구

  • module. 분리된 코드의 조각 / 시스템을 이루는 논리적인 일부분
  • 모듈화를 위해 스코프 / 정의 / 사용 가 필요하다
  • commonJS
    • module.exports로 정의하고, require로 사용한다
    • 모든 파일이 로컬에 존재하여 바로 불러올 수 있다는 전제하에 동작
    • 동기적으로 동작한다
  • AMD
    • 브라우저환경에서 비동기 모듈 사용!
  • UMD
    • commonJS/AMD를 모두 사용할 수 있도록 지원하는 디자인패턴에 가까움
  • ES Module
  • 모듈화를 하다보니 파일이 너무 많아짐 => 번들러가 필요하다
  • Webpack. 모든 파일을 모듈로본다. js뿐아니라 이미지, css 등
    • mode / entry / output 필수
    • 로더(loader) 웹팩이 JS가 아닌 웹 자원(css/HTML/이미지/폰트 등)을 변환하도록 도와주는 도구
    • 플러그인(plugin) 로더가 해석하고 변환한 결과물의 형태를 변경한다
  • Rollup.js
    • ES Module을 사용한다
  • Snowpack(모듈 번들러가 아니라 빌드 도구)
    • 월등히 빠른 빌드 속도
    • 번들 과정 없이 캐시를 사용해서 변경되지 않은 파일은 다시 빌드하지 않음
    • 브라우저 ES Module을 지원하기에 가능
    • 스노우팩을 사용하다가 번들링이 필요해지면 웹팩/rollup.js를 추가로 사용할 수도 있음
  • Babel 트랜스파일러!

• 2021년 8월 26일 (목) ☂️ 검프의 Logging(로깅) #1

  • 테스트가 통과했으니 배포에서도 정상 동작하겠지?라고 생각함
  • 로깅 : 프로그램 동작시 발생하는 모든 일을 기록하는 행위
  • 모든 일 : 서비스 동작 상태 / 장애(error)
  • 로깅은 언제할까 : 프로젝트 성격/팀에 맞게. 로깅 시점은 때에 따라 다르다
  • 출력을 직접하거나, 로깅 프레임워크를 사용하거나
  • 로그레벨. Fatal / Error < x 개발자 의도 o > / Warn / Info / Debug / Trace
  • 디버깅과의 차이점
    • 예외 상황을 가장 잘 파악할 수 있는건 디버깅이다
    • 실 서버 구동 중 처럼 디버깅을 할 수 없는 상황에서 로깅을 한다.
    • 선 디버깅, 할 수 없다면 후 로깅

• 2021년 8월 27일 (금) ☂️ 검프의 Logging(로깅) #2

  • Logback ; SLF4J의 구현체. Log4J를 토대로 만든 프레임워크
  • 사용법에 대해서는 기록하지 않겠음!

• 2021년 8월 28일 (토) ⛄️ 에드의 네트워크 보안

  • 네트워크. 노드(컴퓨터, 스마트폰, 서버 등..)와 링크의 집합
  • 보안. 자산을 위협 요소로부터 보호하는 것.
  • 네트워크 보안. 네트워크 자산을 보호하는 것!
  • 보안의 3요소
    • 기밀성. 인가되지 않은 사용자가 정보의 내용을 알 수 없도록 하는 것
    • 무결성. 인가된 사용자에 의해서만 정보를 변경 가능한 것
    • 가용성. 정보에 대한 사용이 확실하게 보장되는 것
  • 네트워크 공격
    • 스니핑(Sniffing): 네트워크 패킷을 중간에 도청하는 공격 (기밀성 x)
    • 스푸핑(Spoofing): 네트워크 패킷을 중간에 변조하는 공격 (무결성 x)
    • Dos(Denial of Service): 공격 대상(서버)의 자원을 소비시켜 서비스를 마비시키는 공격. 무의미한 요청을 계속 보내는 것에 해당한다(가용성 x). 참고로 여러대의 PC에서 공격하는걸 DDoS(디도스)라고 함
  • TLS(Transport Layer Security)
    • 전송계층의 보안 프로토콜
    • 대칭키를 통한 암호화 / 메세지 인증 코드(MAC)를 통한 데이터 인증 제공
    • 연결 과정에서 서버 인증 제공
    • TLS기반의 HTTP가 바로 HTTPS!
  • IPsec(Internet Protocol Security)
    • 인터넷 계층의 보안 프로토콜 모음
    • TCP만 보호하는 TLS와 달리, TCP/UDP까지 보호
    • 대표적으로 AH/ESP 프로토콜
  • 방화벽. 미리 정해놓은 규칙만 따라서 수동적임
    • 트래픽 차단/필터링
    • 접근 제어
    • 외부 불법 침입 차단
    • 내부 정보 유출 방지
    • 내/외부 네트워크 상호간의 영향 차단
  • IDS(Intrusion Detection System)
    • 침입 패턴 데이터베이스와 지능형 엔진 사용
    • 네트워크 실시간 모니터링 / 불법 침입 탐지
  • IPS(Intrusion Prevention System)
    • IDS + 차단 기능
    • 침입 탐지 후 자동으로 대응/차단
    • 방화벽과 함께 사용하면 효율적
  • VPN(Virtual Private Network) 가상 사설망.
  • 망분리
    • 회사 내부 정보가 노출되거나, 외부의 공격을 차단하기 위해 필요하다
    • 물리적으로 다른 pc를 사용하거나, 가상화를 통해 논리적으로 망분리를 할 수 있다.

• 2021년 8월 29일 (일) 🏖 파피의 Caching(캐싱)

  • Cache. 자주 사용되는 데이터, 값을 일시적으로 저장, 보관
  • CPU에 비해 RAM의 성능이 뒤따라 오지 못 하면서, CPU가 끊임없이 데이터를 처리하며 메모리와 데이터를 주고 받아야함에도 메모리가 CPU의 속도를 쫓아오지 못 하게 되었다. 즉 병목 현상이 발생하게 됨!
  • 이 문제를 해결하기위해 CPU-메모리 사이에 캐시 메모리를 두었다. 크기는 작지만 빠름
  • 대신 비싸서 반복적으로 사용되는 값에만 사용하는 것.
  • 재사용성이 큰지 어떻게 판단할까
    • 데이터 지역성의 원리
    • 데이터 접근이 시간/공간적으로 가깝게 일어나는 것
  • 데이터 업데이트 시 메인 메모리를 업데이트하는 타이밍에 따라 2 가지 정책으로 나뉜다
    • Write Through
      • 메인 메모리를 바로 업데이트한다
      • 단순하고 캐시 메모리와 일관성 유지 가능
      • 매번 바꿔줘야해서 느리다
    • Write Back
      • 캐시 메모리만 업데이트하다가 해당 데이터가 캐시에서 빠져나갈 때 메인 메모리를 업데이트
      • 속도가 빠르지만 캐시 - 메인과 다를 경우가 있음
  • 캐시는 복사본을 이용하는 것이므로, 원본가 다를 수 있으니 일관성 유지에 주의해야 한다

• 2021년 8월 30일 (월) 🍫 찰리의 인덱싱

  • Index. 원하는 데이터를 빠르게 찾기 위해 사용한다
  • 데이터베이스에서 대용량 데이터 조회시 Select문의 조회 속도를 향상시킨다
  • 단, Insert, Update, Delete 시 성능을 조금 희생한다
  • Index도 하나의 DB 객체이기에 저장 공간이 필요하다.
    • Oracle/DB2 - 스키마 객체 / MySQL/SQL Server - 테이블 내 객체
  • Index 검색에 사용하는 알고리즘
    • Full Table Scan. 데이터가 1억건 있으면 1억번의 값 비교
    • B-Tree. Balanced-Tree
  • Clustered Index 무리를 이루는 인덱스. 군집 인덱스
    • 테이블당 1개만 존재
    • PK 제약 조건으로 컬럼 생성시 자동 생성
    • 인덱스에 데이터 페이지 함께 존재
    • 리프 페이지 === 데이터 페이지
    • 데이터 정렬된 상태
  • Non-Clustered Index
    • 보조인덱스 라고도 함
    • 테이블에 여러개 존재 가능
    • Unique 제약 조건으로 컬럼 생성시 자동 생성
    • 인덱스/데이터 페이지 따로 존재
    • 리프 페이지가 데이터가 있는 곳의 주소를 가짐
    • 데이터 페이지에 데이터 정렬 필요 없음
    • Clustered Index에 비해 조회 속도가 느리지만 나머지 CUD에서 부하가 적음
  • Cardinality.
  • 어떤 컬럼에 인덱스를 생성해야 하는가? => 중복된 수치가 낮은 것(카디널리티가 높다)

• 2021년 8월 31일 (화) 🐤 샐리의 트랜잭션

  • 데이터베이스 조회 결과를 어떻게 신뢰할 수 있을까? => 트랜잭션!
  • 트랜잭션 : 더 이상 나눌 수 없는 가장 작은 하나의 단위
    • 송금을 예로 들어 A의 계좌에서 10000원을 깎고, B의 계좌에 10000원을 추가하는 동작이 있을 때 일부만 수행되지 않고 전부 실행되어야 한다 => 절대 깨져서는 안 되는 하나의 작업 (원자성. 다 성공하거나, 다 실패하거나)
    • 일부만 성공하거나 실패하면 이전의 동작을 모두 되돌려야 함 => Rollback
    • 모두 성공했다면 데이터베이스에 반영한다 => 트랜잭션 커밋
    • 원자성 / 일관성 / 독립성 / 지속성

9월

• 2021년 9월 1일 (수) 🎉 동동의 CSS 방법론

  • OOCSS(Object Oriented CSS) 객체지향 CSS
    • 레고처럼 자유로운 조합이 가능한 모듈 집합 만들기
    • 그 모듈을 조합해서 페이지 구성
    • 신규페이지 만들 때 추가적인 CSS 생성 필요 없음
    • structure(구조) / skin(화면) 분리
    • container / contents 분리
    • 오늘날은 그다지 현실직이지 안흥ㅁ
  • SMACSS (Scalable and Modular Architecture for CSS)
    • CSS 코드를 역할에 따라 분류
    • 베이스 / 레이아웃 / 모듈 / 스테이트 / 테마
    • 프로젝트에서 고려해야하는 대부분의 CSS 규칙 포함
    • 각 규칙이 유연하지만 때론 너무 유연해서 실제 코드 지침으로 삼기 어려움
    • 다른 설계 기법과 조합하는 경우가 많음
  • BEM (Block, Element, Modifier)
    • UI를 독립된 블록으로 분리. 복잡한 페이지에서 간단하고 신속하게 개발하는게 목적
    • 기본으로는 모듈 기반이지만 다른 설계 기법에 비해 엄격/강력해서 널리 사용 되는 중
    • id, 요소 셀렉터를 사용하지 않고 class만 사용한다
    • Block. 재사용 할 수 있는, 기능적으로 독립적인 페이지 구성 요소
      • 상태가 아닌 용도를 나타낸다 (red-text가 아니라 error로 표현한다)
      • 환경에 영향을 미치면 안 된다. margin이나 position 설정 x
      • Block끼리 중첩 가능
    • Element. Block의 복합 부품으로 Block과 별도도 사용할 수 없음
      • 마찬가지로 상태가 아닌 용도를 나타낸다
      • Block__{ElementName} 의형태를 띈다
    • Block / Element 구분 기준
      • 다른 컴포넌트에 의존하지 않고 코드가 재사용 됨 => Block
      • 부모 엔티티없이 사용할 수 없음 => Element
      • 더 작은 부분으로 나누어져야 한다 => Block
    • Modifier. Block/Element의 모양, 상태, 동작을 정의한다
      • 어떤 사이즈, 테마인가 / 어떻게 다른 것들과 다른가 / 어떻게 행동하는가
      • size_s / theme_islands / disabled / forcused / directions_left-top 등
      • 홀로 사용되지 않음.
    • Mix. Block/Element가 하나의 HTML 요소에 존재함을 의미
      • 코드 중복 피하면서 여러 BEM 엔티티 동작/스타일 결합
  • 기존 CSS는 HTML 구조에 강하게 결합되어 있다.
  • Utility-First CSS / Functional CSS
    • 클래스명만 봐도 CSS 속성/값을 유추할 수 있는 CSS를 미리 정의
    • HTML 요소에 제공하는 API처럼 사용한다
    • Tailwind / Tachyons / Atomic 등이 있다.

• 2021년 9월 2일 (목) 🐶 코기의 Flyway

  • Flyway. DB 형상 관리
  • DB의 변경 사항을 관리하고 싶다는 것.
  • 엔티티가 변경되었다면? create하면 기존 테이블이 사라지고, update를 부족한 부분은 추가한다. (수정되지 않음)
  • 둘 다 문제가 있기에 Flyway를 사용해서 변경사항을 관리하는 것

• 2021년 9월 3일 (금) 🍺 서니의 프론트엔드 성능 측정

  • 지연속도와 이탈율은 비례 관계다(당연하게도)
  • 2초 지연시 디바이스에 따라 62~102.9% 이탈률에 영향을 미치고 구매 전환률도 25~36% 가량 영양을 미친다.
  • 사용성 개선을 통한 이익성 증대를 위해!
  • 프론트엔드에서 측정해야할 성능. 로딩 시간 / 렌더링 시간 / 메모리 누수
  • 로딩 시간
    • FCP (First Contentful Paint)
      • 첫 요소가 로드 될 때까지 걸리는 시간
    • FMP (First Meaningful paint)
      • 사용자에게 의미있는 첫 요소가 로드 될 때까지 걸리는 ㅣㅅ간
    • LCP (Largest Contentful Paint)
      • 주요 콘텐츠가 로드 될 때 까지 걸리는 시간
    • FMP의 경우 약 20% 항모에서 정확하지 않는다 해서, 현재는 LCP를 기준으로 로딩 속도를 측정한다.
  • 렌더링 성능
    • 사람이 자연스럽다고 느끼는 초당 프레임 수 60. 즉 프레임당 16ms 미만이어야한다
    • JavaScript / Style / Layout / Paing / Composite 순으로 진행된다.
  • 메모리 누수
    • 가비지 컬렉터가 웬만하면 처리해주지만 전역변수 / 타이머, 콜백 미해지 / 돔 외부에서 참조 / 클로저 등의 이유로 누수가 발생할 수 있음
  • Web Vitals LCP / FID / CLS
    • FID (First Input Delay)
      • 사용자의 행동에 대해 실제 이벤트 핸들러가 반응하기 까지 걸리는 시간
    • CLS (Cumulative Layout Shift)
      • 시작 위치에서 레이아웃이 얼마나 변화하는지
  • Front-End Performance Checklist 2021 (77가지...)
  • 크롬 개발자 도구의 lighthouse / perfomance / memory / network 탭 등을 사용해서 측정한다
  • React Profiler
  • 성능 측정시 고려할 점
    • 서비스에 맞는 성능 개선 요소에 집중하자
    • 넥플릭스는 사용자와 인터렉션이 많은 스트리밍 서비스이기 때문에 사용자 입력 반응속도(FID), 메모리 관리 등이 중요
    • 위키피디아는 정보가 많으니 로드 속도, CPU 소요 시간 등이 중요할 것
    • 기본 환경에서 측정하자
      • 확장 프로그램 제거
      • 크롬 시크릿 모드 사용
    • 타겟 사용자 환경(모바일/PC 등)에 맞춰 데이터 수집하자

• 2021년 9월 4일 (토) 🧲코일의 Web Socket

  • 웹 소켓: 두 프로그램 간의 메세지를 교환하기 위한 통신 방법 중 하나
  • 양방향 통신(Full-Duplex)
    • 데이터 송수신을 동시에 처리
    • 클라이언트/서버가 서로 원할 때 데이터 주고 받기 가능
    • HTTP는 클라이언트=>서버 요청만 가능한 단방향
  • 실시간 네트워킹
    • 채팅/주식/비디오 같은 연속된 데이터를 빠르게 노출하는 웹 환경에서 사용
    • 여러 단말기에서 빠르게 데이터를 교환해야한다.
  • Polling
    • 양방향 통신을 하는 실시간 네트워킹을 구현하기 위한 다른 방법으로, 서버에 일정 주기로 요청을 송신한다.
    • 변함이 없어도 불필요한 요청/커넥션 발생
    • 실시간이라고 하기 애매함
  • long Polling
    • 주기적 요청은 같지만 서버에서 요청에 대해 대기하다가 이벤트가 발생하면 응답
    • 많은 양의 데이터가 쏟아질 경우 polling과 차이 없음
  • streaming
    • 서버에 요청 보내고 연결을 끊지 않으며 데이터를 계속 수신
    • 클라이언트 => 서버로의 데이터 송신이 어려움
  • 위 3가지 모두 HTTP를 사용하기때문에 req/res의 headers가 불필요하게 크다
  • 최초 접속에서만 HTTP/HTTPS 프로토콜 위에서 핸드쉐이킹을 하기에 HTTP Headers 사용 Host / Upgrade / Connection / Sec-WebSocket-Key / Origin / Sec-WebSocket-Protocol / Sec-WebSocket-Version 등
  • 웹 소켓을 위한 별도 포트는 없음. 기본 포트(80/433)을 사용한다
  • 프레임으로 구성된 메세지라는 논리적 단위로 송수신
  • 메세지에 포함될 수 있는 교환 가능한 메세지는 텍스트/바이너리
  • 한계
    • HTML5 이후에 나온 기술이기에, HTML5 이전 서비스에서는 Socket.io / SockJS 등을 사용해야 함
    • 위 두 라이브러리는 브라우저/웹 서버의 종류/버전을 파악해서 가장 적합한 기술을 선택하여 사용하는 방식
    • 문자열만 주고 받을 수 있어서 문자열 해독을 어플리케이션이 해야 함
    • HTTP는 형식이 있어서 따르기만 하면 해석 가능하지만 웹소켓은 형식이 없어서 힘들다
  • STOMP
    
    

• 2021년 9월 5일 (일) 🪐빙봉의 정규 표현식

  • 정규표현식 : 특정 패턴으로 문자열을 찾을 수 있다
  • 메타문자 : 문자를 나타내는 문자
    • . [] | \s \d \w 등
  • 수량자 : 앞 문자의 개수
    • ? + * {n, m} 등
  • 패턴으로 검증하기에 if문을 쓰지 않아도 되지만, 가독성이 좋지 않아서 유지보수가 어렵다.
  • 간단한 검증은 if로, 복잡한 검증만 정규표현식으로. 주석을 달자
  • 컴파일러 파서 / CLI 환경 / 이메일, 주소, 전화번호 규칙 / 불필요한 입력 검증 / 문자열 치환 / 로깅 / 코딩테스트 등..
  • 외우지 말고 그 때 그 때 알아보자.

• 2021년 9월 6일 (월) 🧑‍💻🧑‍💻동글&라면의 DNS

  • IP 주소를 외우기 어려운 "사람"을 위해
  • SRI : 전세계 IP/도메인을 수집, Hosts 파일에 저장
  • 각 통신사가 DNS에 연결되어 있기에 우리는 신경쓰지 않아도 된다.
  • Name / Type / Class / Resource Data
  • 도메인 네임은 우측 끝부터 Root / Top Level / Second Level / Sub Domain이다.

• 2021년 9월 7일 (화) 🤠럿고의 CORS

  • URI는 Protocol/Host/Port/Path/QueryString/Fragment 로 나뉜다
  • Origin은 Protocol, Host, Port 까지를 말하며, 브라우저에 따라 Port를 인정하지 않기도 하는데, 모던 브라우저에서는 IE를 제외한 모든 브라우저는 Port까지 Origin으로 인정한다 . location.origin으로 확인하자
  • SOP (Same-Origin Policy) : 같은 출처의 요청만 리소스를 받을 수 있다.
  • Preflight Request : OPTIONS 메소드로 예비 요청을 보내고 본 요청 보냄
  • Simple Request : GET/HEAD/POST 메소드로 본요청을 바로 보냄
  • Credentialed Request : 쿠키를 담아서 보낸다.

• 2021년 9월 8일 (수) 🔧알트의 XSS

  • 공격 대상 사이트에 스크립트를 삽입할 수 있는 보안 취약점
  • C&C(좀비 PC에 명령을 내리거나 악성 코드를 제어하는 서버)로 리다리엑트 / 사용자 쿠키 탈취 및 세션 하이재킹 공격 가능
  • Stored XSS / Reflected XSS / DOM Based XSS
  • Stored XSS : 공격자가 제공한 데이터가 서버에 저장된 후 서비스를 제공하는 정상 페이지의 사용자에게 지속적으로 공격 스크립트를 노출 한다
  • Reflected XSS : 웹 어플리케이션의 지정된 파라미터를 사용할 때 발생하는 취약점을 이용한 공격
    • 공격용 스크립트가 대상 웹사이트가 아닌 더미 사이트, 이메일 등에 포함될 수 있다
    • Stored XSS와 달리 공격 스크립트가 데이터베이스가 아닌 응답 페이지에 바로 존재한다는 차이점이 있다
  • Stored XSS는 <script> 태그를 직접 주입하는 것도 있지만 막히기 쉽다. <img src=""/> 처럼 img 태그를 사용하면 XSS 공격이 가능하다.
  • XSS 공격 방지 방법
    • innerHTML 사용 지양
      • 클라이언트에서는 innerHTML 사용을 자제한다. 다행히 HTML5에서는 innerHTML로 주입한 script 태그는 실행되지 않는다
      • 하지만 여전히 onerror 이벤트 속성을 사용하면 주입이 가능하다
      • 그러므로 꼭 필요한 경우가 아니라면 innerHTML을 지양하고 textContent, innerText를 사용하자.
    • vue.js는 v-html 디렉티브를 사용하면 취약점 발생 가능
      • 사용자가 제공한 컨텐츠는 HTML에서 절대 사용하지 말 것을 공식문서에서 명시하고 있다
    • Cookie의 http-only 속성 활성화
      • 자바스크립트에서 접근할 수 없기에 스크립트로 쿠키 값을 빼가는걸 막을 수 있다
    • XSS 특수문자를 치환
      • spring에서는 오픈소스 라이브러리로 가능
      • 단 RequestBody로 전달되는 JSON 요청에 대해서는 처리 안 해줌
      • & > < 등등을 & < > 등으로 변경!

• 2021년 9월 9일 (목) 🕴핀의 Realtime Web

  • 소리가 안 들리는 수준이라 PPT만 봤음
  • Realtime web이란 인터넷 사용자에게 서비스의 정보를 즉시 수신할 수 있도록 하는 기술/서비스이다
  • 전통적으로 HTTP를 사용해서 요청에 대한 내용을 가공해서 새로운 웹을 보여주었으나, AJAX 등장으로 부분 데이터를 받아오고 일부 리렌더링 하는 방식으로 발전
  • Realtiem web 구현을 위한 기술로 (Long) Polling / Server-sent events / Websocket 등이 있다.
  • Polling은 서버 개발을 할수 없거나, 외부 API가 서버 푸시를 지원하지 않을 때 사용한다
  • Server-sent events는 새로운 데이터를 즉시 수신만하면 될 때, 알림/실시간 댓글 등을 구현해야할 때 사용한다
  • Websocket은 네트워크 지연을 최소화하고, 채팅/게임과 같은 사용자간 빠른 피드백이 필요할 때 사용한다

• 2021년 9월 10일 (금) 🐳스티치의 빌드와 배포

  • 컴파일 : 소스코드를 바이너리 코드로 변환하는 과정
  • 링크 : 여러 개로 분리된 소스코드를 컴파일한 결과물들에서, 최종 실행 가능한 파일을 만들기 위해 필요한 부분을 찾아서 연결하는 작업
  • 빌드 : 소스코드를 실행 가능한 소프트웨어 산출물로 만드는 일련의 과정
  • 배포 : 작성한 코드를 빌드하고, 빌드된 실행 가능한 파일을 사용자가 접근할 수 있는 환경에 배치하는 것
    • git에 올려두고, 코드가 정상 동작하는지 테스트하고, 수행/검증하는 작업까지를 말한다
  • CI (Continuous Integration) : 지속적 통합.
    • 코드를 통합하고 / 동작, 빌드를 테스트하고 / 버그가 발생하면 로깅한다
    • 이 일련의 동작을 자동화한다
  • CD (Continuous Deploy) : 지속적 배포
    • 소프트웨어가 항상 신뢰 가능한 수준에서 배포될 수 있도록 자동 관리
    • CI를 통과한 코드를 신뢰하고, 바로 배포한다
  • 무중단배포 : 새롭게 배포할 버전의 서버를 배포하고, 기존 서버를 없애면서 다운 타임을 발생시키지 않는다
    • 기존 서비스를 닫고, 새로운 서버를 올리는 과정에서 서비스가 중단되는 시간
    • Rolling 배포
      • 배포 서버가 너무 많으면 배포 과정 중 사용자에 따라 다른 서비스를 보게 될 수 있다
      • 일반적인 배포 방식보다 최소 2배 이상 느리다
    • Canary 배포
      • 소수의 유저 혹은 사내에서 사용하는 환경에 신규 버전을 배포하고, 문제가 없다 판단되면 다른 모든 서버에 배포하는 방식
    • Blue/Green 배포
      • 실제 서비스 환경(Blue)과 새로운 배포 환경(Green)을 세트로, Green에서 문제가 없다면 Green의 환경을 Blue로 변경하는 방식
      • 배포 속도가 빠르고, Green에서 문제가 생기면 신속하게 롤백 가능
      • Green을 항상 사용중이기에 비용이 2배로 든다

• 2021년 9월 11일 (토) 🐢터틀의 네트워크 보안

  • 네트워크 보안 : 엔드포인트 - 엔드포인트에서 전송되는 데이터를 보호하는 것
  • 스니핑(Sniffing) : 네트워크 패킷을 훔쳐보는 것
  • 스푸핑(Spoofing) : 네트워크 패킷을 변조하거나 악의적인 코드를 삽입 하는 것
  • Dos(Denial of Service) : 공격 대상의 자원을 소모시켜 정상적인 서비스를 하지 못 하도록 만드는 공격
  • 올해 우테톡을 모두 보고, 작년 우테톡을 보고 있었으나 거의 같은 내용이라서 더 이상 보는 것보다 한 번 공부한 내용을 다시 복습하는게 낫다고 판단, 일일 우테톡은 여기까지!