Merge branch 'release/v19.11.0'

KunHwanAhn · Dec 12, 2019 · f9705ba · f9705ba
2 parents f602296 + 1406584
commit f9705ba
Show file tree

Hide file tree

Showing 14 changed files with 601 additions and 2 deletions.
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -1,5 +1,9 @@
 # Changelog
 
+## v19.11.0 (2019-12-12)
+- [GDG] DevFest WebTech with Chrome Dev Summit 2019
+- [mozilla] Roadshow Asia 2019
+
 ## v19.10.0 (2019-11-13)
 - [GDG] DevFest 2019
 

diff --git a/GDGKR/2019-07-13_io_extended_web_tech/04_web_assembly_101.md b/GDGKR/2019-07-13_io_extended_web_tech/04_web_assembly_101.md
@@ -98,7 +98,7 @@ int main() {
 
 # What would com next?
 - Thread / Shared Memory Support
-- ECMASvript Module Integration
+- ECMAScript Module Integration
 - Garbage Collection
 - And even more language support!
 
@@ -125,4 +125,4 @@ int main() {
 - https://webassembly.studio/
 
 # Reference
-- http://ujinbot.blogsopt.com/2013/07
+- ~http://ujinbot.blogsopt.com/2013/07~ 페이지 폭파됨
diff --git a/GDGKR/2019-11-23_devfest_webtech_2019/00_keynote.md b/GDGKR/2019-11-23_devfest_webtech_2019/00_keynote.md
@@ -0,0 +1,4 @@
+# Keynote
+
+- https://developer.chrome.com/devsummit/
+- https://www.youtube.com/watch?v=F1UP7wRCPH8&list=PLNYkxOF6rcIDA1uGhqy45bqlul0VcvKMr
diff --git a/GDGKR/2019-11-23_devfest_webtech_2019/01_visbug_opensource.md b/GDGKR/2019-11-23_devfest_webtech_2019/01_visbug_opensource.md
@@ -0,0 +1,49 @@
+# VisBug와 함께 하는 오픈소스 기여 이야기
+- 안도형, 스튜디오씨드 코리아
+- [발표자료](https://speakerdeck.com/rinae/visbugwa-hamgge-haneun-opeunsoseu-giyeo-iyagi)
+
+> VisBug 소개 및 활용 방법 공유
+> 오픈소스 생태계에 기여해보고픈 분들을 위해 VisBug 프로젝트에 기여하며 얻었던 경험 공유
+
+# VisBug가 뭐죠?
+- https://github.com/GoogleChromeLabs/ProjectVisBug
+- Firebug for designers
+- 모든 웹페이지를 아트보드 처럼 쓸 수 있게 하는 것을 목표로 하는 프로젝트
+- [Chrome Extension](https://chrome.google.com/webstore/detail/visbug/cdockenadnadldjbbgcallicgledbeoc)으로 제공
+- Firefox 확장 및 npm 패키지로 어디든지 가져다 쓸 수 있는 기능이 추가 예정
+- 주된 사용 대상은 웹 디자이너와 웹 개발자
+
+# 웹 컴포넌트
+- http://www.webcomponents.org
+- https://slides.com/rinae/deck-2
+- HTML을 확장하여 고유의 태그를 만들 수 있음
+- 라이프사이클도 있음
+- 속성 변화 감지 등
+
+## Shadow DOM
+- 엘리먼트의 스타일과 마크업을 캡슐화
+- 브라우저의 모든 엘리먼트에 대한 CSS와 스크립트는 `전역으로 적용된다`는 문제를 해결
+
+- 웹 컴포넌트와 기능함수의 조합으로 이루어짐
+- 컴포넌트의 스타일링은 PostCSS + Constructable Stylesheet 활용
+- Ava + Puppeteer로 E2E Testing
+
+# VisBug의 기능
+- Inspect
+- Accessibility
+- Move
+- Margin / Padding
+- Flexbox align
+- Hue shift
+- Shadow
+- ETC...
+
+# VisBug 활용
+- 개발자로서 어지간한 기능은 Dev Tools를 열어 해겨할 수 있는 것들이지만, 화면 넓게 쓰고 싶을 때도 유용
+- 특히 가이드 기능이 좋음
+- 디자이너, QA 엔지니어에게 알려주고 협업할 때, 다양한 방식으로 활용
+- 디자이너 분들이라면 더 유용하고 적절한 활용 방법을 찾을 수 있을듯!
+
+# 왜 오픈소스로 제품을 만들까?
+- 진입 장벽을 낮추어 빠른 확산과 발전
+
diff --git a/GDGKR/2019-11-23_devfest_webtech_2019/02_main_thread_with_code.md b/GDGKR/2019-11-23_devfest_webtech_2019/02_main_thread_with_code.md
@@ -0,0 +1,105 @@
+# The main thread is a bad place to run your code
+- 도창욱 / Riot Games
+- [발표자료](https://speakerdeck.com/cwdoh/web-worker-101-the-main-thread-is-a-bad-place-to-run-your-code)
+
+> Chrome Dev Summit 2019 Review - Main Thread: Overworked & underpaid
+> https://www.youtube.com/watch?v=7Rrv9qFMWNM
+
+# Thread? Main Thread?
+- Thread는 어떠한 프로그램 내에서, 특히 프로세스 내에서 실행되는 흐름의 단위
+- App 시작 시, 렌더링, 이벤트 등을 처리하는 기본적인 스레드 생성 = **"Main Thread"**
+
+> Main Thread === UI Thread // ture
+
+# 무엇이 문제일까?
+
+## JavaScript는 Single Thread이다?
+- 정확히는 Single-threaded **event loop**
+- https://blog.sessionstack.com/how-does-javascript-actually-work-part-1-b0bacc073cf
+
+## **"브라우저의 렌더링"**에 대해 알아보고 갑시다.
+- [프론트엔드 개발자를 위한 크롬 렌더링 성능 인자 이해하기](https://medium.com/@cwdoh/%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%EA%B0%9C%EB%B0%9C%EC%9E%90%EB%A5%BC-%EC%9C%84%ED%95%9C-%ED%81%AC%EB%A1%AC-%EB%A0%8C%EB%8D%94%EB%A7%81-%EC%84%B1%EB%8A%A5-%EC%9D%B8%EC%9E%90-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-4c9e4d715638)
+- [Web Fundamentals - Rendering Performance](https://developers.google.com/web/fundamentals/performance/rendering)
+
+> Chrome 브라우저는 60FPS의 렌더링 성능을 추가합니다. Framerate가 올라갈수록 사용자는 부드러움을 느낀다.
+
+- 1Frame / 16ms & [requestAnimationFrame()](https://developer.mozilla.org/ko/docs/Web/API/Window/requestAnimationFrame)
+- 자바스크립트는 분명히 렌더링 성능에 영향을 줍니다.
+
+> 아무리 최적화 한다한들, 우리에겐 다양한 Device가 있다...
+
+# JavaScript의 실행은 UI Thread에서 동작한다.
+- 가장 좋은 방법은? 최적화? 기능이라 우긴다? => 백그라운드 실행
+- [Web Workers](https://developer.mozilla.org/ko/docs/Web/API/Web_Workers_API)
+
+## WC3에서 말하는 Web Worker
+- 메인페이지와 **병렬로 스크립트를 실행하는 백그라운드 워커**를 생성하는 API
+- **메시지 전송 기반**으로 Thread와 유사한 동작을 가능하게 한다.
+
+## Wokrer: Thumb of Rules
+- UI스레드에서 분릳뢰어 실행되어야 한다.
+- DOM에 대한 직접 접근/조작 불가
+- 자체적인 글로벌 스코프
+- 일부 속성과 API만 허가
+
+## 3 Types of Worker
+- Service Worker
+- Shared Worker
+- Dedicated Worker
+
+### Service Worker
+- https://developer.mozilla.org/ko/docs/Web/API/Service_Worker_API
+- 브라우저에 설치되는 일종의 시스템 요소 기능
+- 페이지/브라우저가 실행 중이지 않더라도 브라우저에 의해 라이프사이클 제어
+- 외부 요소 제어를 위한 이벤트 모델
+- 원격 푸시 알림이나 백그라운드 동기화의 최초 진입점으로 적합
+- 런타임에 생성되는 것이 아니라 설치/해제
+
+### Shared Worker
+- https://developer.mozilla.org/ko/docs/Web/API/SharedWorker
+- 다수의 브라우징 컨텍스트에서 접근할 수 있는 워커
+- 윈도우, iframe, 워커와 같은 다수의 브라우징 컨텍스트에서 접근할 수 있는 특정한 종류의 워커
+- 런타임에 코드에서 직접 워커 인스턴스 생성
+- 동일한 Origin을 가지는 컨텍스트에서 접근 가능
+- SharedWorkerGlobalScope라고 하는 별도의 글로벌 스코프를 가진다
+
+#### 사용 예시
+- 로그인 기능이 있는 페이지가 있을 때, 사용자가 다양한 탭을 동시에 띄워놓고 있는 상태로 사용하는 상황에서, SharedWorker의 상태를 변경하면 동시에 모두 로그아웃을 가능하게 할 수 있다.
+
+### Dedicated Worker
+- 단일 브라우징 컨텍스트에서 접근할 수 있는 워커
+
+#### 사용 예시
+- 아주 오래 걸리는 디코딩 작업이 있을 때, 이 작업을 메인 스레드에서 작업하다면, 웹 페이지는 디코딩 작업동안 화면도 멈춰있고 아무런 동작을 하지 않는다.
+- 이런 작업을 Worker에서 실행하면 좋다!
+
+##### decoder.js
+```JavaScript
+self.addEventListener('message', e => {
+  // Decode...
+  self.postMessage(decodedResult)
+})
+```
+
+##### main.js
+```JavaScript
+fetch('my-encrypted-doc.txt').then(function(res) {
+  // spawn worker
+  const worker = new Worker('decoder.js')
+  worker.onmessage = function(e) {
+    console.log(`Decoded ${e.data}`)
+  }
+  // decode blob data with worker
+  worker.postMessage([res.clone().blob()])
+})
+```
+
+# ComLink
+- https://github.com/GoogleChromeLabs/comlink
+- 메인 스레드와 워커 사이에서 객체나 값 등을 공유할 수 있도록 인터페이스르 제공합니다.
+- 하지만, 액세스는 메시지에 의해 이루어지므로, 비동기임을 주의!!
+
+# 결론
+- JavaScript의 성능 이슈는 JavaScript만의 문제는 아니다.
+- UI와 관련이 없지만, 부하가 큰 기능을 구현해야 한다면, Worker를 고민할만 합니다.
+- ComLink 사용하세요!
diff --git a/GDGKR/2019-11-23_devfest_webtech_2019/03_http3_performance.md b/GDGKR/2019-11-23_devfest_webtech_2019/03_http3_performance.md
@@ -0,0 +1,114 @@
+# HTTP/3 시대의 웹 최적화 기술 이해햐기
+- 강상진, 빈스마트
+- [발표자료](https://drive.google.com/file/d/1H7UYxOYwYWB-20GxKzS5ZziwPAoAAOAC/view)
+
+> HTTP/3 Faster and Securer
+
+# 최적화(Optimization)
+- 최고의 성능(Performance)을 만들 수 있는 최적의 조건(Condition)을 갖추는 것
+
+> 한국은 전세계적으로 1, 2위를 다툴 정도로 네트워크 강국. 하지만 이로 인해서 국내 서비스들은 성능 최적화에 대한 고민이 덜 되어 있다고 볼 수 있다.
+
+# 웹 최적화
+- 웹 사이트의 로딩 속도를 최대한 빠르게 만드는 기술
+- 백엔드 최적화 - DNS 성능, DB 정규화, DB Query 개선, Scale Out/Up etc..
+- 프론트엔드 최적화 - gzip compress, image optimization, code splitting, etc..
+- **프로토콜 최적화(오늘의 주제..)**
+
+## 백엔드 최적화
+- DNS RTT 가속
+- DNS 캐싱
+- 네트워크 throughout/bandwidth
+- 웹 서버/WAS CPU/RAM 증설
+- 웹 서버 프록시 서버
+- 웹 서버 컨텐츠 캐싱
+- CDN(Content Delivery Network)
+- 오브젝트 스토리지
+- 데이터베이스 정규화
+- 데이터베이스 캐싱 - Query 결과 캐싱 / e.g.) Redis, Cloud Cache
+- 로드 밸런스 - 단순 헬스체크로 50:50이 아니라, 각 서버별 성능을 측정하여 가용한 리소스가 많은 쪽으로 유동적으로 제어
+- 웹 애플리케이션 로직
+- etc...
+
+## 프론트엔드 최적화
+- 실제 사용자 환경(네트워크, 디바이스, 브라우저, etc)에 알맞은 최적화 / e.g. Android 사용자가 많다면, Android에 집중
+- 스크립트 병합(Script combination) - 코드를 분할하여 개발하면 좋지만 실제로 사용자가 사용할 때는 너무나 많은 수의 데이터를 주고 받는 것을 방지하기 위해서
+- 스크립트 최소화(Script Minification) - 주석 등 불필요한 내용을 제거함으로써 용량을 제거
+- 스크립트 압축 전달(Gzip Encoding)
+- 이미지 형힉 최적화(WebP)
+- 이미지 손실 압축(compression)
+- 브라우저 캐시 사용(cache-control 헤더)
+- DNS 조회 최소화(Domain Sharding)
+   - 모던 브라우저들은 TCP/IP Connection을 최대 6개까지 가능하기에, 도메인을 분리하여 여러곳에서 병렬적으로 데이터를 가져오는 것
+   - 단, DNS Server가 성능이 충분할 때 사용하는 것을 권장함
+- DNS 정보 미리 읽어오기(DNS prefetching)
+- CSS/JS 위치 조절 (Top/Botton)
+- 페이지 미리 읽어오기(Page Prefetching)
+- 서드 파티(3rd Party) 스크립트 조정
+- etc...
+
+## 프로토콜 최적화
+- 좀 더 Web을 빠르게 요청하고, 빠르게 응답할 수 있는 프로토콜
+- 프로토콜을 버전을 올린다면(v1.1 -> v2), 10~20% 정도의 성능 개선 효과를 얻을 수 있다.
+
+# HTTP의 역사
+
+## HTTP의 발전
+- HTTP0.9 - 1991
+- HTTP1.0 - 1995
+- HTTP1.1 - 1997
+- SPDY - 2012 - 잠깐 사용하다가 보안적 취약점이 발생되어 사장.. HTTP/2에 녹아들었음
+- QUIC - 2013
+- HTTP/2 - 2015
+- HTTP/3 - 2019
+- v1.1 -> v2는 18년, v2 -> v3은 4년
+
+## HTTP/2 돌아보기
+- Stream 구조, why? -> 멀티플렉싱(Multiplexing)을 지원하기 위해서!
+
+### 멀티플렉싱(Multiplexing)
+- HTTP1.0 -> 한 번에 1개씩
+- HTTP1.1 -> 파이프라이닝(Pipelining), 응답을 기다리지 않고 먼저 요청 후 순서대로 받는다. / FIFO
+- HTTP/2 -> 멀티플렉싱(Multiplexing) / 용량이 적은 것부터 먼저 응답을 받음!
+
+### 헤더 인덱싱과 압축
+- 정적 테이블/동적테이블을 사용한 헤더의 인덱싱
+- 인덱싱이 완료된 헤더는 허프만(Huffman)알고리즘으로 압축
+- Encoder/Decoder를 사용한 헤더의 해석
+
+## 서버 푸시(Server Push)
+- 클라이언트가 요청하지 않은 콘텐츠를 서버가 알아서 내려주기
+   - HTTP는 기본이지만 `요청 -> 응답`의 순서이지만, HTML 분석 후 요청할 데이터를 미리 전달하는 것!
+- 클라이언트 - 서버 간, RTT(Round Trip Time) 절약
+- HTML, CSS는 우선순위가 Highest, Image는 Low, JavaScript는 Medium 정도의 우선순위를 가짐.
+- CRP(Critical Rendering Path) - ???
+
+## HTTP3의 등장배경
+- HTTP의 HOLB(Head Of Line Blocking)은 해결하였으나, TCP의 HOLB문제는 여전히 남아 있다.
+- UDP 프로토콜을 사용하는 QUIC을 사용해보는 것은 어떨까?
+
+### QUIC
+- 한 번이라도 접속해봤던 페이지라면, 연결을 최소화한다!
+- Zero RTT(0 ~ 100ms)
+
+### HTTP/3 프로토콜 스택
+- IP -> TCP -> TLS 1.2+ -> HTTP/2
+- IP -> UDP -> TLS 1.3 & QUIC -> HTTP/3
+
+### HTTP/3 신뢰성
+- UDP를 믿을 수 있는가? -> 신뢰성 레이어 추가
+   - 패킷 재전송
+   - 혼잡제어
+   - 손실 회복
+   - 기타 TCP 기능 추가
+
+### HTTP/3 - QPCK
+- 인코더를 사용하여 동적 테이블 업데이트, 압축
+
+# HTTP/3
+- 아직 HTTP/3는 현재 Chrome Canary에서 지원
+
+## HTTP/3가 풀어야할 숙제는?
+- Google, CloudFlare 등 총 3개 회사 정도만 사용하고 있음.
+- 기관이나 보안 관련 업체에서는 UDP 포트를 막아놓는 경우가 많아, 이를 풀어야 한다.
+- cURL 이외의 HTTP/3를 지원하는 도구들이 늘어나야 함.
diff --git a/GDGKR/2019-11-23_devfest_webtech_2019/04_modern_web_assembly.md b/GDGKR/2019-11-23_devfest_webtech_2019/04_modern_web_assembly.md
@@ -0,0 +1,48 @@
+# Modern WebAssembly
+- 지미문, 프로토파이 & GDE
+- [발표자료](https://speakerdeck.com/ragingwind/recap-modern-webassembly-in-cds-2019)
+
+# WebAssembly?
+- [WebAssembly 101 참조](https://github.com/KunHwanAhn/ParticipatedSeminars/blob/develop/GDGKR/2019-07-13_io_extended_web_tech/04_web_assembly_101.md)
+- 웹에서 동작하는 새로운 언어
+- 다른 언어로부터 컴파일
+- 최적화되고 일관성 있는 성능
+- 자바스크립트를 **대체하지 않음!**
+
+## 웹에서 동작하는 새로운 언어
+- Chrome, Edge, Firefox, **Safari** love WebAssembly
+
+## 다른 언어로부터 컴파일
+- https://mbebenita.github.io/WasmExplorer/
+- https://hacks.mozilla.org/2017/07/memory-in-webassembly-and-why-its-safer-than-you-think
+
+## 최적화되고 일관성 있는 성능
+- https://www.youtube.com/watch?v=njt-Qzw0mVY
+- WASM -> Liftoff(WebAssembly base line compiler) -> Result
+- WASM -> Liftoff(WebAssembly base line compiler) -> TurboFan(Optimization Compiler) -> Result Hot Swap
+   - 중간 중간 TurboFan에 의해서 최적화한 코드를 Hot Swap 함.
+
+## 자바스크립트를 **대체하지 않음!**
+
+> https://webassembly.studio/
+
+# WebAssembly at Dev Summit 2019
+- https://www.youtube.com/watch?v=kZrl91SPSpc
+- Implicit Caching
+- Thread
+   - Chrome Canary 한정 (2019-11 기준)
+   - Sample code - https://github.com/ragingwind/wasm-hello-world
+   - https://medium.com/google-earth/performance-of-web-assembly-a-thread-on-threading-54f62fd50cf7
+- SIMD - Single Instruction, Multiple Data
+   - https://github.com/google/mediapipe
+- Tooling Update
+- Native LLVM Backend
+- Asyncify
+- WAT Debugging on Chrome Dev Tools
+   - Sourcemap, Native Debugging
+
+> https://wasi.dev - 브라우저를 벗어난 WASM
+
+> bytecode allience
+
+> https://hacks.mozilla.org/2019/08/webassembly-interface-types/