Peep

Chrome is deploying HTTP/3 and IETF QUIC

2013년 Google에서 공개적으로 발표했으며 처음에는 Quick UDP Internet Connections의 약어로 제안되었지만,

오늘날에는 약어가 아닌 QUIC라는 프로토콜 이름 그대로 불리운다.
발표 이후 IETF(인터넷 프로토콜 유지를 담당하는 평균 조직)에 도입 된 후 IETF에서 사용하면서 개선하기 시작했고
IETF의 QUIC는 초반에 출시한 QUIC와 유사하지만 다른 버전이 되었다.
IETF의 개선된 버전을 확인한 Google의 QUIC팀은 IETF를 추적해서 Google QUIC를 발전시켰고 많이 유사해졌다.
IETF QUIC는 TCP를 통한 TLS 1.3보다 HTTP를 훨씬 능가하는 것으로 나타났다.

• 검색시간감소 2%
• Youtube 리버퍼기간 감소 9%
• 디바이스 처리량 증가
  • PC 3%
  • Mobile 7% 

Chrome 몇달 뒤 지원을 시작할 예정이며 초안 QUIC와 호환성이 깨지는 변경사항은 없으며 무선 식별자를 변경할 계획이 없다. 만약 추후에 이러한 변경이 있을 경우 재 검토하여 발표할 예정이라고한다.

UDP?

Quic?

더보기

TCP, TLS등의 기능을 결합한 새로운 네트워킹 전송 프로토콜

 

TCP

전송 제어 프로토콜(Transmission Control Protocol)

IP와 함께 TCP/IP라는 명칭으로도 널리 불린다. TCP는 근거리 통신망이나 인트라넷, 인터넷에 연결된 컴퓨터에서 실행되는 프로그램 간에 일련의 옥텟을 안정적으로, 순서대로, 에러없이 교환할 수 있게 한다.

- 출처 : 위키백과

 

TLS

전송 계층 보안(Transport Layer Security, 과거 명칭: 보안 소켓 레이어/Secure Sockets Layer, SSL)

컴퓨터 네트워크에 통신 보안을 제공하기 위해 설계된 암호 규약이다. 

이 규약은 인터넷 같이 TCP/IP 네트워크를 사용하는 통신에 적용되며, 통신 과정에서 전송계층 종단간 보안과 데이터 무결성을 확보해준다. 

이 규약은 웹 브라우징, 전자 메일, 인스턴트 메신저, voice-over-IP (VoIP) 같은 응용 부분에 적용되고 있다.

TCP는 요청마다 3-way Handshake 와 SSL과 같은 암호화가 추가 된다면 TLS handshake 로 인한 RTT(Round Trip Time) 증가한다.

또한 HOL(head of line) 블로킹 문제 등이 있다.

- 출처 : https://devahea.github.io/2019/04/30/5G-%EC%B4%88%EC%97%B0%EA%B2%B0%EC%8B%9C%EB%8C%80%EC%97%90-%EC%9B%B9-HTTP%EC%9D%98-%EB%8C%80%EC%95%88%EC%9D%80-QUIC/

UDP와 TCP 비교

Chrome is deploying HTTP/3 and IETF QUIC

blog.chromium.org/blog.chromium.org/search/label/HTTP%2F3

취준생이 반드시 알아야 할 프론트엔드 지식들 -CSS 

Box Model

box model

• Content Area

• Padding Area

• Border Area

• Margin Area

box-sizing

• content-box : 컨텐츠 영역 기준

• border-box : 테두리 영역 기준

Float 해제

1. 부모에 float 적용

   • 자식크기만큼 크기가 줄어듬

   • 부모가 여러개일 경우 float를 또 써야하거나 clear해야함

2. 부모에 overflow 적용

   • 옵션에 따라 스크롤바가 생기거나 컨텐츠가 잘릴 수 있음

3. 부모가 끝나기 전 빈 엘리먼트 추가 후 clear 적용

   • 의미 없는 엘리먼트가 추가되므로 권장하지 않음

4. 부모에 display:inline-block 적용

   • 부모엘리먼트와 다음에 오는 엘리먼트 사이에 여백이 생김

   • 자식크기만큼 크기가 줄어듬

5. 가상요소로 clear 적용

   • 권장

마진겹침 현상 (Margin-Collpasing)

• 블록 레벨 엘리먼트(Block-level element)에 한해 발생

• 수직방향으로 발생

• 2개의 마진이 겹칠 때 큰 마진으로 덮여지는 현상

• 하나의 마진이 음수일 경우 더하는 방식을 취함

조건

1. 인접한 엘리먼트 발생

2. 부모와 처음/마지막 자식 사이에서 발생

   • inline, border, padding 등을 통해 해결

3. 빈 엘리먼트에서 발생

   • 빈 엘리먼트에 height, min-height, padding, border, inline 등을 통해 해결

position:absolute, float:left, display:flex등 마진겹침현상이 발생하지 않는 예외적인 경우도 있다.

(새로운 BFC(Block Formatting Context)를 생성하는 조건이 마진겹침을 발생시키지 않는다.)

BFC(Block Formatting Context)

블록레벨요소를 렌더링하는데 사용되는 CSS 비주얼 서식 모델 중 하나

조건

• root

• root를 포함하는 요소

• float가 none이 아니며 clear되지 않은 요소

• position이 absolute나 fixed인 요소

• display가 inline-block, inline-flex, flex, table-cell, table-caption인 요소

• overflow가 visible이 아닌 요소

z-index

쌓임 맥락(Stacking Context)

동작방식을 이해하기 위해서는 사용자가 바라보는 기준으로 가상의 z축을 생성하여 3차원 개념으로 보이는 맥락을 이해해야한다.

이 요소들에 우선순의를 z-index가 정하게 되는 원리.

특징

• 동일한 성격이라면 마크업 순서대로 쌓임이 결정됨

• 쌓임 맥락은 다른 쌓임 맥락을 포함할 수 있음

• 쌓임을 고려하는것은 오직 자식요소들에 대해서만..

조건

• position가 relative, absolute이며 z-index가 auto가 아닌 요소

• position가 fixed, sticky인 요소

• opacity가 1보다 작은 요소

• transoform이 none이 아닌 요소

Reset.css VS Normalize.css

• 기본 브라우저 내장 스타일을 초기화하는 기법

Reset.css

• 모든 브라우저 내장 스타일을 제거하는 기법

• 제로 베이스에서 시작(각 태그에 적용된 모든 스타일이 초기화)

• Eric Mayer의 Reset.css가 가장 유명

Normalize.css

• 모든 브라우저 스타일을 동일하게 하는 기법

• 기존 스타일은 유지하되 브라우저마다 다른 스타일을 동일하게 고치는 방식

• Necolas의 nomalize.css가 가장 유명하며 주석을 보면 각 브라우저에 따라 추가된 이유를 설명하고 있다.

차이점

Reset.css의 경우 브라우저 버그를 고치는 부분이 아니고 모든것을 초기화하는 것이기 때문에 버그 발생 가능성이 있다.

하지만 아예 초기화하는 부분이기때문에 Reset.css 소스에 대한 업데이트가 필요없다.

Nomalize.cs는 브라우저 업데이트의 경우 영향이 있을 수 있기 때문에 업데이트가 필요하고 초기화하여 스타일링을 시작하는 것이 아니기때문에 작업 시 크로스브라우징에 신경써야한다.

하지만 브라우저 버그를 고치는 부분이기에 버그 발생 가능성이 낮다.

뭐가 좋고 나쁘다고 할 수는 없고 상황에 따라 사용하길..

그리드 시스템 (Grid System)

• 레이아웃을 구현하기 위해 설계한 시스템

• 열(Column) 개수에 따라 12단/16단/24단 그리드라고 부르기도 한다.

Float grid system

• float 속성으로 구현한 그리드

• float된 높이를 잡기 위해 clearfix 핵을 사용해야한다.

• 각 너비를 열/행에 맞게 계산해줘야한다.

Flexbox grid system

• float와 거의 동일하되 clearfix핵을 없애고 flex를 적용

Grid layout grid system

• grid를 사용한 것으로 flat/flexbox와 완전히다르다.

• 너비계산도 필요없고 row, column을 따로 지정하지 안흔다.

• 단순히 grid 관련된 속성을 사용해서 열/행의 너비 및 높이와 각 항목의 비율을 지정한다.

<img> 하단 공백

하단 공백이 생기는 이유는 img가 인라인 레벨 요소이기 때문이다.

따라서 vertical-align:baseline이 default값이며 텍스트와 동일하게 baseline기준으로 정렬된다.

인라인 레벨 요소는 알파벳의 y,j,p,g,q등과 같은 하강문자(descender)를 위해 아래쪽에 더 공간이 있어야하기때문에 img의 아래에 공백이 생긴다.

해결방법

• img 요소에 display:block

• img 요소에 vertical-align:middle/top/botto (권장)

• 요소의 컨테이너에 line-height:0; (컨테이너 요소에 다른 컨텐츠가 있을 경우 문제가 될 수 있음, 권장하지 않음)

취준생이 반드시 알아야 할 프론트엔드 지식들 - CSS

https://github.com/baeharam/Must-Know-About-Frontend

아티클은 "TypeScript를 활용한 서비스개발"을 읽었는데, ORM이 뭔가 찾아보다가 정리해봤다.

ORM이란

객체 관계 매핑(ORM, Object-relational mapping)

"

데이터베이스와 객체 지향 프로그래밍 언어간의 호환되지 않는 데이터를 변환하는 프로그래밍 기법

객체 지향 언어에서 사용할 수 있는 "가상" 객체 데이터베이스를 구축하는 방법이다. 

"

- 위키백과

ORM

객체와 관계형 데이터베이스의 데이터를 자동으로 연결해주는 것을 말한다.

• 객체지향프로그래밍은 클래스, 관계형데이터베이스(RDB, Relational Database)는 테이블을 사용
• 객체모델과 관계형 모델간의 호환 불일치가 발생할 수 있다.
• ORM을 통해 불일치를 해결한다.
  • 객체지향프로그래밍 시 데이터베이스와 호환가능성을 염두하고 개발하지 않는 이상 둘 사이에 호환 불일치가 발생하는 경우가 생긴다. 
  • 이를 ORM을 통해 객체간의 관계를 바탕으로 SQL문을 자동으로 생성하여 불일치를 해결한다.
  • 따라서 ORM을 사용하면 따로 SQL문을 작성하지 않아도 객체를 통해 간접적으로 데이터베이스를 조작할 수 있다.

장점

• 객체지향적인 코드
  • 클래스의 메서드를 통해 데이터베이스를 조작할 수 있기때문에 비즈니스로직에 집중할 시간을 확보할 수 있다.
  • SQL문과 관련된 부수적인 코드가 줄어들거나 필요하지 않아도되는 경우가 있다.
  • 객체에 대한 코드를 별도로 작성하기에 코드 가독성이 증가한다.
  • 객체지향접근, SQL의 절차/순차적 접근이 혼재되지 않아도되기에 객체지향적 접근만 고려, 생산성 증가한다.
• 재사용, 유지보수, 리팩터링 용이성
  • ORM은 독립적으로 작성되어있고 해당 객체를 재활용할 수 있다.
  • 모델에서 가공된 데이터를 컨트롤러에 의해 뷰와 합치는 형태로 디자인 패턴을 견고하게 다지는데 유리하다.
  • 연결정보가 정확하여 ERD 의존도를 낮출 수 있다.

단점

• 첫 설계를 잘못하면 망할 가능성이 크다.
• 프로젝트 복잡성에 따라 난이도가 높아지고 잘못된설계는 속도 저하 및 일관성의 문제가 생길 수 있다.
• 속도를 위해 별도의 튜닝이 필요한 경우 결국 SQL문을 사용해야하는 경우가 생길 수 있다.

객체-관계간의 불일치

• 세분성
  • 데이터베이스 테이블 수보다 더 많은 클래스를 가진 모델이 생기는 경우
• 상속성
  • RDBMS는 객체지향언어 특징인 상속 개념이 없다.
• 일치 (이해가 잘안됨???)
• 연관성
  • 객체지향언어는 객체의 참조를 사용해 연관성을 나타낸다. 하지만 RDBMS는 방향성이 없는 외래키(foreign key)를 이용해 나타낸다.
• 탐색
  • 자바와 RDBMS 객체 접근 방법이 다르다.
  • 자바는 그래프형태로 연결 연결하여 탐색한다.
  • RDBMS는 JOIN은 통해 여러 엔티티를 로드하고 원하는 엔티티를 선택하는 방식으로 탐색한다.

* 관계형 데이터베이스 (RDB, Relational Database)

* 관계형 데이터베이스 관리 시스템 (RDBMS, Relational Database Management System)

ORM이란?

https://geonlee.tistory.com/207

RDB, RDBMS란

https://jwprogramming.tistory.com/52

https://thefif19wlsvy.tistory.com/147

플랫폼 디자이너 없이 디자인 시스템을 구축하는 프로덕트 디자이너의 우당탕탕 고통 연대기

가이드를 만들기로 결심

• 플랫폼마다 사용자 UI/UX 다름
• 업무 용어의 통일성이 없었음
• ===> 디자이너가 하나의 프로덕트에 고립되게 되는 현상

! 플랫폼의 공통사항을 정리하자

Style Guide 개선이유

• 사용성을 더 좋게 개선하자.
• 커뮤니케이션이 더이상 발전하지 않았다.
• 디자인 원칙을 세우자! (문법과 어조를 추가로 통일, 정리하자)

디자인 시스템

- 두가지 시스템을 예시로 들수 있다.

1. UX, Style Guide, Code가 왁벽한 가이드

2. Code가 빠져있는 가이드

스타일 가이드 장점

• 확장성이 있어서 커뮤니케이션 비용이 줄어든다.
• 일관된 사용성
  • 새로운 디자인을 할 때, 스타일 가이드를 토대로 재사용에 대한 근거가 됨 ("기존에 사용되고 있었다")
• 사용자 경험 디자인에 집중할 수 있음
  • 기본 값이 정의되어있기 때문에 흐름에 대한 디자인이나 추가적인 경험에 대한 디자인을 할 수 있는 시간이 확보됨
• 신입도 같은 결과물을 생성할 수 있음

스타일 가이드 단점

• 해당 가이드를 만들기 위한 리소스

다른 직군과의 커뮤니케이션을 위해

• 디자인 중심적으로 글 작성하지 않기
  • 간결, 쉽게, 일관성, 신뢰성
• 글 구성 템플릿화
  • 개요, 종류, 구성, 상태

  

• 관리
  • 해당 컴포넌트별 담당자를 나누어 오너쉽을 가진다.
    • 디자이너별로 리뷰하기

디자인 관리 툴

Sketch ----> Figma ----> zeroheight

Sketch는 로컬기반이라 실시간 공유이 어려웠다.

Figma는 클라우드 기반이라 여러명이 공유하면서 작업하기 쉬웠다.

zeroheight 

+ 개발자 도움없이 code snippet 추가 가능

+디자인 가이드를 만들때 프론트엔드 개발자도 고통을 받는다.

Q&A

1. 기존 시스템 디자인가이드를 만드는가? 리뉴얼에 적용하기 위해 만드는가?
   • 기존 시스템에 추가하기 위해 만들고 있다.
2. 성과 측정
   • Figma에서 가장 높은 단계의 플랜을 사용하면 어떤 컴포넌트가 가장많이 사용되는지를 확인할 수 있다고한다.
3. 커뮤니케이션 효율성에 대해 어떻게 설득하는가
   • 용어정리
   • 아이콘 디자인의 재활용
   • 설득이 필요없을 정도로 효율성을 느끼고들 있다.
4. 서로의 의견을 수렴하는 과정
   • 원칙을 정할때 동의를 기준으로 함
   • 시스템 대의를 만듬
   • 토론
5. 예외케이스 관리
   • 발생 정의, 정리 후 팀내 논의

NAVER FE devtalk: 디자인 시스템에 대한 소개와 효율성 개선 및 구축 경험공유

https://d2.naver.com/news/4194542

플랫폼 디자이너 없이 디자인 시스템을 구축하는 프로덕트 디자이너의 우당탕탕 고통 연대기

https://tv.naver.com/v/15841749