GDG devFest수원 참석후기

[느낀점]

좋은 기회를 만들어주신 GDG 수원 운영진 분들께 감사드립니다.

오늘 발표하신 나동희 발표자님, 조 은 발표자님, 라이트닝 토크에서 말씀해주신 크로미움 컨트리뷰터님 포함해서 많은분들이

오픈소스의 컨트리뷰터로 활동한 뒤에 좋은 결과가 있으셨던 것을 보아 오픈소스에 컨트리뷰터로 활동하는 것이 개발자로서는 매우 유리하다고 생각했습니다.(번역을 하면서 신문물을 국내에 들여오는 것도 좋은생각인듯 합니다 !)

yoon jake님의 flutter의 발표에서는 flutter가 ios와 안드로이드의 개발을 하나의 코드로 할 수 있다는 점에서는 매우 획기적이었습니다. 하지만, 아직 발전이 되어야할 부분이 많아보였기 때문에 저같이 코드를 잘 못짜는 사람들은 진입할 단계가 아니라고 생각했습니다. 안드로이드 피규어 감사합니다 !!

나동희님의 open source with google summer code 세션에서는 제가 졸업을 해버려서 google summer of code에 참여할 수 없어서 아쉬웠습니다. 상세한 설명을 해주셨지만 참여할 수 없기에 아쉬웠습니다. coala라는 컨벤션 체크툴의 존재를 알게되었습니다. 

조은 발표자님의 세션이 특히 인상깊었는데, 웹 사이트의 성능을 향상시키기 위한 기준과 구체적인 방법을 제시해주셔서 매우 도움이 되었고 GDE(Google Developer Expert)가 되는 과정에 대해서 질문드렸을 때, 과정을 명쾌하게 말씀해주셔서 도움이 되었습니다.

라이트닝 톡에서도 다양한 분들의 얘기를 들을 수 있어 좋았습니다.

---

[진행 순서]

[18:30 ~ 19:00] 참가자 등록 확인 및 저녁식사
[19:00 ~ 19:20] Keynote (GDG Suwon 운영자)

세션
[19:30 ~ 20:05] 세션 1. Flutter 101 - Jake Yoon, GDG Suwon,  삼성전자
[20:15 ~ 20:50] 세션 2. Improve Web Performance - Cho eun, GDE, NAVER
[21:00 ~ 21:35] 세션 3. Open Source with Google Summer Code - Dong-hee Na, Kakao

라이트닝 톡
[21:45 ~ 22:20] Whoever

뒷풀이 (맥주파티) - 저는 서울로 다시 올라가야해서 아쉽지만 뒷풀이에 참석하지 못했습니다.
[22:30 ~ ]

---

[세미나 내용]

세션 1. Flutter 101 - Jake Yoon, GDG Suwon,  삼성전자

[모바일 앱 시장에 대한 배경설명]

모바일 앱을 개발하는 사람들도 있고, 모바일 웹을 개발하는 사람도 있습니다.

이용자들은 네이티브 앱은 평균 180분을 쓰고, 웹은 15.7분을 사용한다고 합니다.

즉, 사람들은 웹의 형식보다는 모바일 앱을 사용하는 것을 더 선호하고

오래 머물러도 괜찮다는 인식을 가지고 있는 것을 볼 수 있습니다.

(디자인 트렌드에 관하여는, 사람들은 디자인이 심플하고 UX가 간단한 것을 선호합니다.)

하지만, 네이티브 앱은 30일 이후에 살아남는 앱이 전체 앱 중 3%밖에 안됨.

모바일 개발에는 다음과 같은 역설이 있습니다.

"

네이티브로 만들면 너무 많은 것을 유지보수 해야 하고,

네이티브가 아니면 제대로 만들기 어렵다.

"

따라서 심플한 디자인트렌드, 크로스플랫폼 추세를 고려한 네이티브앱 개발 SDK인 flutter를 사용하는 것이 좋습니다.

[flutter]

구글의 모바일 SDK

언어 : dart

- 특징

빠른 속도의 개발 : Hot Reload, script 언어처럼 실시간으로 적용 할 수 있음(Android Studio, Intelli J, Visual Studio Code 사용가능)

풍부하고 아름다운 UI

네이티브 성능(arm코드 등 사용)

구글은 애니메이션을 구현하기에 적합하기 때문에 dart를 채택을 했음

- 위젯의 종류

- Stateless widget(정적인 위젯)

개념 : 고정된 Text나 Icon, Button처럼 더 이상 갱신이 되지 않는 widget

특징 : 빌드라는 펑션만 구현하면 되서 간단함.

- statefulWidget(정적인 위젯과 반대되는 개념. 동적으로 업데이트함)

개념 : 컨텐츠가 변경되거나 사용자의 interaction등으로 인해 다시 그려져야 하는 widget

특징 : Createstate를 해야함, build라는 펑션이 다시 호출 되면서 업데이트됨.

※ 유튜브 flutter widget of the week이 있는데 그 주의 유명한 위젯을 설명해주는 채널입니다. 어떤 위젯이 있는지 정보를 얻기에 좋다고 합니다.

---

세션 2. Improve Web Performance - Cho eun, GDE, NAVER  (sanfrancisco에서 현지시각 새벽4시에 발표)

[웹에서의 성능은 무엇일까 ?] - 추상적인 개념

10초가 걸려도 누구는 느리다고 생각 할 수도 있고,

1초가 걸려도 누구는 느리다고 생각 할 수 있어서 주관적(추상적인 것임)인 개념입니다.

[성능은 어떻게 측정할 수 있을까?] - RAIL model 소개

RAIL model은 User의 사용성을 주로 다루고 있는 guideline입니다.

모든 웹 앱은 수명 주기에 다음과 같은(Response, animation, idle, load) 뚜렷한 네 가지 측면이 있으며, 여기에 성능이 각기 다른 방식으로 적용됩니다.

중요한 점은 “user에게 포커스를 맞춘다”는 것이 중요한 개념입니다.

- 성능지연에 따라 사용자가 느끼는 정도

0 to 16ms (millisecond) (지연을 못느끼는 정도라고 하셨던 것 같습니다.)

0 to 100ms         good

100 to 300ms fast

300 to 1000ms delayed

1000ms or more bad

10000ms or more terrible

Response : 100ms안에 반응하라 (스크롤을 하든 뭘 하든 100ms 이내로 무언가를 실행을 해라)

Animation : 10ms안에 프레임 생성을 하라 

Idle : idle time을 최대화 하라 (유휴시간을 이용해서 지연된 작업을 완료하라는 의미라고 합니다. https://developers.google.com/web/fundamentals/performance/rail?hl=ko)

Load : contents를 5seconds 이내에 로딩을 해라(네이버 메인이 뜨는 시간이 샌프란시스코에서 5초 걸림)

이 가이드라인을 따르면 사용자에게 좋은 사용성을 제공할 수 있을 것이라고 합니다.

["당신이 문제를 모른다면, 문제를 해결할수 없다." ] - 성능에서 문제란?(문제를 알아야 풀 수 있음. 따라서 도구가 필요함)

Chrome Dev Tools : 성능 측정툴1

ighthouse : 성능 측정툴2, 현존하는 성능측정도구 중에서는 가장 좋음

(특징 : open-source, 문제가 어떤 것인지 찾아줌.)

pageSpeed insights : 성능 측정툴3, 서비스형태로 제공됨

특징 : 다른 서비스와 차별점은 Field Data라는 것을 제공함. FCP / FID를 참조해서 이 사이트가 얼마나 성능이 좋은지 평가 가능

(네이버의 경우 FCP는 1.6s, FID는 499ms -> 16%에 속해서 위험한 축에 속한 결과가 나왔음)

(수정필요)

[성능 최적화는 어떻게 ?] - critical rendering path / offscreen image / optimize image

critical rendering path(중요한 렌더링 단계)

개념 : 이것을 최적화 한다는 것은 어떤 컨텐츠를 먼저 보여줄지 결정한다는 의미임.

Optimized된 것은 어떠한 것을 순차적으로 보여주고, optimized되지 않은 것은 한번에 늦게 뜸.

- Ajax는 어디에나 쓰임.

- Rendering을 어떻게 하는지?

Token화 된 html을 보면, 스타트 태그와 엔드 태그가 있음 html -> head

[bytes -> Characters -> token -> nodes -> dom] 이런식으로 되어있음. 웹에서는 parse html이라고 함. Dom tree로 만드는 과정임. 이 과정 중에서 Script를 만나는 시점부터 렌더링이 멈춤. 그다음에 stylesheet를 읽어들이는데 selector를 기반으로 돌아가게됨. ?? Width:50%처럼 ?? css가 된 경우가 있는 것은 recalculating을 하게 됨.

Layout은 위치계산, paint는 그리기, composite layers는 합성인데 이 중에서 가장 비용이 큰 것은 layout임. 왜냐면 연산과정이 들어가기 때문에.layout은 cpu를 사용하고, paint와 composite layers에서는 기본적으로 gpu를 사용하기 때문에 cpu를 거치지 않아서 부담이 더 적음.

[Javascript > style > layout > paint > composite] 페이지를 불러 올 땐, 이런 과정을 거침

Javascript, style, layout, paint과정을 거치지 않고 composite만 거치면 한단계밖에 거치지 않기 때문에 16ms 안에 충분히 할 수 있음.

- css는 rendering을 막는 resources이다.

css가 없으면 사람들은 장애가 있는 페이지라고 생각을 함. 따라서 css가 렌더링을 블로킹 해야함.

따라서 css로딩할 때 중요한 점은 중요한 리소스는 우선 로딩하고, 중요하지 않은 리소스는 비동기로 로딩하도록 하자. 크롬에서는 커버리지라는 것을 제공하는데, 현재 사용하고 있는 css들을 최초로 로딩하는데 얼마나 필요로 하는지 ? 를 말하고 있음??

커버리지에서 어떤 css가 쓰이고 어떤 것이 쓰이지 않았는지 볼 수 있음.중요한 것은 inline으로 헤더로 불러오고, 중요하지 않은 것은 link href stylesheet로 나중에 부름

이 과정이 critical reading path에서 가장 중요한 부분임.

- Offscreen image

뷰포트 밖에 있는 이미지를 먼저 불러올 필요는 없다.

Javascript의 콜백함수에서 문자열 등을 바꾸는 방식은 레이지로딩으로 방식함.

- Optimize images -> imagemin을 사용하면 됨.

Images의 용량이 매우 크기 때문에 이미지의 용량을 줄이는 것이 중요.

[Jpeg, png gif]old, [svg, webp]new라는 형식을 지원함. Svg, webp는 chrome과 firefox에서만 지원을 함.

사용법 imagemin images/* --out-dir=images

Drag & drop or ??? 로 최적화 하는 서비스가 있음.  (squash)

- Showcase & resources

- 오늘 발표한 내용은 fast load times에서 볼 수 있음(나와있는 내용임)

Deba에 들어가서 보면 laymodel이 뭔지 등등이 나와있음. Webr

Q. GDE(Google Developer Expert)는 어떻게 되셨습니까?

3년 가까이 opensource에 기여를 했고, 오픈소스 기여활동을 굉장히 높이 사서

구글에서 웹테크의 GDE를 하면 어떻겠냐 제안을 해서 한번 해보겠다고 했습니다.

GDE 선발 프로세스가 있는데,  Google korea의 추천을 받았고, 1차면접, 2차면접 보고 GDE가 되었습니다.

1차면접은 다른 GDE와 보고, 2차면접은 구글러랑 봤는데,

평가는 본인이 가지고 있는 technical한 지식이 얼마나 되는지에 대해 질문받았고,

영어로 면접이 이루어지기 때문에 영어를 할 줄 알아야한다고 합니다.

※ amp project , lighthouse에 opensource 기여를 했고, 구글 developer 관련 번역을 하셨다고 하셨습니다.

(2번째 세션은 원래 발표시간에 통화 품질이 너무 떨어져서 3번째 세션을 먼저 듣고 추후에 다시 진행되었었습니다.)

---

세션 3. Open Source with Google Summer Code - Dong-hee Na, Kakao (카카오의 추천시스템 개발업무하심)

google summer of code는 학생만 참가 가능하다고 합니다.(대학생 및 대학원생. 수료생 참여 불가능)

프로젝트 지원시에 지원자에게 $3800정도 지원해주고, 멘토에게는 티셔츠 하나만 준다고 합니다.

[방법]

참가하려는 프로젝트 도메인 지식에 대하여 충분히 준비하여 멘토에게 프로젝트를 어떻게하겠다고 proposal을 적어야합니다.

원하는 프로젝트(coala, LLVM, 등)에 미리 제안서를 작성해야합니다.

프로젝트 참가여부가 결정되는 것은 양보다는 퀄리티가 매우 중요함. 따라서 한군데 쓰더라도 퀄리티있게 !!

프로젝트마다 할당받는 학생 slot수가 정해져 있어서, 학생은 해당 slot을 받기 위해 경쟁을 해야하는데, 오랫동안 유지된 프로젝트 일 수록 프로젝트에 할당 되는 slot 수가 많다고 합니다.

재학증명서도 제출해야하는데 '구글에서 요구하는 양식'에 맞춰서 제출해야한다고 합니다.

[지원가능기간] 

3월 경

[잘 작성된 proposal의 예]

https://github.com/saurabhshri/GSoC-2017-Accepted-Proposals

[프로젝트 진행 중 주의사항]

- 화상미팅으로 최종발표함.(이 부분은 프로젝트마다 다를 수 있다고 합니다.)

- 프로젝트 하면서 최소 주 1회 이상은 멘토와 연락을 하자. 이렇게 하지 않으면, 멘토가 학생이 프로젝트를 하지 않고 있다고 판단 할 가능성이 있기 때문입니다.

- Final submit은 영구박제되기 때문에 최대한 신중하게 작성해야한다고 합니다.

[기타]

coala : 컨벤션 체크를 쉽게 할 수 있도록 도와주는 프로젝트라고 소개해 주셨고, 나동희님께서 이 프로젝트의 멘토로 활동하셨다고 하셨습니다.

---

3분 라이트닝 토크

1. 지도와 함께 삽질하기 ??(제목을 놓쳤습니다.)

법정동과 행정동이 달라서 공공기관에서 다운받은 지도에 표시하는 것이 어렵습니다.

이 발표를 하신 개발자님은 직접 데이터 추가하고 표시함으로써 해결하셨다고 하셨습니다.

바라는 점은 공공기관에서 관리가 안된 데이터를 주는 경우가 있어서 고통스럽다! 정리가된 데이터를 줬으면 좋겠다 !!

2. C/C++빌드속도 줄이는 간단한 방법 - 고병건, chromium contributer로 활동

크로미움에서는 빌드를 빠르게 하기 위해 jumbo 빌드를 사용했습니다.

C++ hello world가 Java hello world보다 line수가 적어서 빌드가 빠를 것 같지만 사실은 그렇지 않습니다.

왜냐면, include는 copy& paste 형식이고 import는 imform 방식이라서 C++에서 iostream을 include하면 만팔천줄을 복사합니다.

C++에서 이것을 해결하기 위한 방법은 점보빌드를 하는 것입니다.

점보빌드의 핵심은 모든 코드를 한파일에 작성하는 것입니다. (빌드시 하나의 파일로 묶어서 빌드!!)

#include "test1.cpp"

#include "test2.cpp"

이런식으로 인클루드해도 괜찮은 이유는 헤더가드가 있기 때문이라고 합니다.

Flutter_101_JakeYoon_GDG_DevFest_Suwon.pdf

GDG_Devfest_2018_Suwon_gsoc.pdf

https://speakerdeck.com/gdg/gdg-devfest-suwon-2018-improve-web-performance-cho-eun  (용량이 10M를 초과해서 첨부가 불가능합니다.)

https://speakerdeck.com/gdg

+ lightening talk

https://docs.google.com/presentation/d/e/2PACX-1vTdVRykDQ8uzk6OBFXGXfIJoXrCWAyfyri2rpL7YNO0E-PgwbbGMplPbt2nehCL6T9zrsl3Fy_T1Lly/pub?start=true&loop=false&delayms=3000&slide=id.p

임시저장(수정예정입니다.)