Great libraries and tools for great Progressive Web Apps 요약

2016.05.31 23:32

오늘 본 비디오는 Great libraries and tools for great Progressive Web Apps 입니다. 솔직히 제목에 혹~! 했습니다만 막상 비디오를 다 보고 나니 동영상에 나온 것들을 적용하려면 고민을 많이 해야 할 것 같더군요. 동영상의 내용은 대략 다음과 같습니다.



Progressive Web Apps 은 웹에서의 최신 유행어다.

    - PWA는 최신 기술을 많이 사용하고

    - PWA를 만들면 사용자에게 유용하고, 사용성이 높고, 즐거운 경험을 줄 수 있다.

 

PWA를 만드려면 만드는 방법의 변화가 필요하다.

    - 예전 웹

        - 예전에는 고수준의 기능으로 웹페이지를 만들었다.

        - 이미지를 보여주고 싶으면 이미지 태그를 사용하고, 테이블을 보여주고 싶으면 테이블 태그를 사용했다.

    - 확장할 수 있는 웹

        - 웹 표준의 새로운 아이디어는 extensible web이다.

        - 특정한 기능을 하는 간단한 API 대신 새로운 기능은 저수준이고 강력하며 더 다양한 것을 가능하게 한다.

            - 이미지를 보여주는 태그 대신 임의의 그래프를 그릴 수 있는 태그를 제공한다.

            - 테이블 태그 보다는 원하는 것을 그리를 수 있는 CSS 속성을 제공한다.

        - 페이지를 앱으로 바꿀 수 있다.

    - 그런데 실제 만들어야 할 것과 플랫폼 사이에 간극이 생기게 되고

    - 이 간격은 라이브러리로 채운다.

    - 커뮤니티는 개발자가 원하는 특정한 기능을 수행할 수 있는 간단하고 사용하기 좋은 라이브러리를 제공할 책임이 있다.


Service Worker libraries

    - PWA에서 가장 중요한 기술은 Service Worker다.

        - 오프라인, 푸시 메시지, 백그라운드 데이터 싱크 같은 기능을 제공

    - sw-toolbox (https://github.com/GoogleChrome/sw-toolbox)

        - 연결 상태와 관련된 패턴을 추출하여 쉽게 사용할 수 있도록 만듬

    - sw-precache (https://github.com/GoogleChrome/sw-precache)

        - 캐시 관리를 쉽게 하도록 도와줌

        - cli로도 사용 가능

    - sw-appcache-behavior (https://github.com/GoogleChrome/sw-helpers/tree/master/projects/sw-appcache-behavior)

        - 기존에 만들어진 appCache 사이트를 Service Worker로 바꾸도록 도와줌

    - sw-helpers (https://github.com/GoogleChrome/sw-helpers)

        - sw-appcache-behavior는 sw-helpers의 일부임

    - 현재 작업 중인 것에는 offline analytics 가 있음

        - 오프라인일 때 ga 요청을 저장하고 있다가 온라인이 되면 서버로 전송


Chrome DevTools

    - 최신 버전 (Canaray 52)에서 사용 가능

    - resources 패널이 application 패널로 변경

    - manifest panel

        - manifest 의 정보를 확인 가능

        - add to homescreen 가 있어서 homescreen에 추가되지는 않지만 onbeforeinstallprompt 이벤트를 트리거함

    - service worker panel

        - offline, update on reload, bypass for network(service worker 미동작) 등의 상태를 테스트할 수 있다.

    - clear storage panel

        - 현재 사이트의 값만 제거할 수 있다.

    - cache storage viewer

        - 추가된지는 좀 됐지만 사람들은 잘 모른다.

        - 캐시된 항목의 목록


Lighthouse (https://github.com/GoogleChrome/lighthouse)

    - 크롬 익스텐션이나 npm 모듈로 제공

    - remote debugging API 사용

    - 몇 번 페이지 로드한 후 PWA의 관점에서 리포트를 제공해줌

    - cli: $ lighthouse your.address

        - 콘솔에 찍거나, json, html로 리포트 제공

    - node module로도 사용 가능

        - ci 과정에서 활용 가능

    - 알파 버전 상태, 규칙은 아직 확정되지 않은 상태, 카나리 52+에서만 동작, 

    - 아직 초기 단계료 여러분의 도움이 필요함



잘못된 부분이 있을 수 있으니, 꼭 원본 동영상을 참고하시기 바랍니다.





nundefined ETC Canary, Chrome, devtools, extensible web, google io, google io 2016, LIGHTHOUSE, progressive web app, pwa, service worker, sw-appcache-behavior, sw-helpers, sw-precache, sw-toolbox, 서비스 워커, 크롬

V8, modern JavaScript, and beyond 요약

2016.05.31 00:31

Google I/O 2016 에서 웹을 주제로 하는 세션 중에 동영상으로 공개된 것은 27편입니다. 이게 전체인지 일부인지는 알 수 없지만 작년에 비하면 상당히 많아졌습니다. 그 중 V8, modern JavaScript, and beyond 라는 세션의 동영상을 간단히 요약해봅니다.


V8의 미션

    - Speed up real-world performance for modern JavaScript, and enable developers to build a faster future web.

    - 크롬에서 현재 사용 중인 자바스크립트를 빠르게 동작 시키는 것

    - 개발자들이 더 빠른 앱을 만들도록 지원하는 것 - 올바른 도구, 언어의 새로운 기능, 다양한 리소스 등


Real-world performance

    - 과거

        - 마이크로 벤치마크

            - 일정한 기능을 반복적으로 테스트해서 속도를 확인

        - 테스트 스위트

            - 일정한 기능(pdf.js, gameboy 에뮬레이터 등)을 실행

    - 지금부터

        - 실제 웹 페이지를 대상으로 퍼포먼스 확인

        - 구글을 포함하여 전세계의 사이트를 대상으로 자동 확인


JS engine upgrades

    - 구조 개선

    - GC의 개선

        - 메모리가 어느 선을 넘으면 GC했으나

        - 16ms마다 진행되는 렌더링에 걸려 GC로 인해 frame을 건너 뛸수도

        - frame 사이의 idle time에 일부 GC

    - 인터프리터

        - 시작을 빠르게

        - 컴파일에 걸리는 시간을 짧게

        - 메모리 사용량은 적게

        - 순수 JS의 실행 시간은 길어지나 파싱, 컴파일에 걸리는 시간이 짧아져 전체 실행 시간은 짧아짐


ES6 & ES7

    - M51까지 점진적으로 ES6의 feature를 구현

    - M52에서는 ES6과 ES7를 네이티브로 지원

    - ES.next도 곧

    - 트랜스파일러나 폴리필이 있지만 네이티브로 지원하는 것은 여러 모로 중요하다.


Debugging + Node.js

    - V8_inspector support를 Node.js core project에 pull request를 보냈음 (https://github.com/nodejs/node/pull/6792)

    - Node.js에서 실행되는 코드를 개발도구에서 디버깅할 수 있음.


WebAssembly

    - binary로 된 c/c++ 코드를 실행.

    - 주요 브라우저에서 지원.

    - 성능 좋음. 2012년 맥북 에어에서 시연.

        - 동시에 두 개의 브라우저에서 시연하지만 매끄럽게 동작

        - 발표하는 동안 계속 백그라운드에서 동작하고 있었음



잘못된 부분이 있을 수 있으니 꼭 원본 동영상을 참고하시기 바랍니다.


nundefined ETC devtools, ES2016, ES6, es7, google io, google io 2016, node.js, Performance, V8, WebAssembly, 성능, 웹어셈블리, 크롬, 퍼포먼스

카카오스토리팀의 코드리뷰에 대한 질문과 답

2016.03.20 16:04

얼마 전 카카오 개발자 블로그에 카카오스토리팀의 코드 리뷰 도입 사례라는 글이 올라왔습니다. 현재 일하고 있는 곳에서 2년이 넘는 시간 동안 진행한 코드 리뷰의 경험을 잘 설명한 글입니다. 제가 쓴 글은 아니지만 코드 리뷰에 참여하고 있는 한 명으로서 이 글을 잘 읽었다는 피드백을 받을 때마다 솔직히 기분은 좋더군요.


여기서는 코드 리뷰 경험에 대한 글을 공개하기 전, 후에 코드 리뷰에 대해 질문받은 내용과 답변에 대해 기억나는대로 정리해보려 합니다.


Q. 코드 리뷰가 성공할 수 있었던 이유는 무엇일까요?


1. 리뷰도 개발의 한 과정이라고 생각하는 개발문화입니다. 많은 경우 리뷰를 개발 과정의 일부가 아닌 개발 외적의 일로 여기는 경우가 있는데, 리뷰 자체도 개발의 일부라고 생각하고 일정과 같이 개발에 필요한 자원을 챙길 때 항상 리뷰를 고려했습니다.

2. 리뷰를 실행하는 구성원의 의지입니다. 중간에 여러 난관에 맞닥뜨렸을 때, 리뷰를 중단함으로써 문제를 해결할 수도 있었지만 리뷰는 반드시 지켜야 할 좋은 가치라는데 이견이 없었기에 리뷰가 아닌 부분에서 해결 방법을 찾으려고 계속 시도했습니다.

3. 리뷰의 전, 후에 진행했던 작업을 리뷰와 관계 없는 업무 흐름으로 분리했습니다. 원문에서 볼 수 있는 '병목이 새로운 병목을 만들었다.'부터 '브랜치 미리보기 서버' 절까지가 대표적인 예입니다. 이를 통해 리뷰는 '개발 - 리뷰 - 머지 - 테스트 - 배포'의 업무 흐름에만 속해 있으며 다른 업무에는 영향을 주지 않습니다.

4. 좋은 도구를 사용하고, 반복적인 업무는 자동화하여 개발자는 코드 자체의 품질을 개선하는데 집중할 수 있게 했습니다. 깃헙, 미리보기 서버, 깃훅을 이용한 린트와 테스트의 실행 등이 큰 도움이 됐습니다.


Q. 코드 리뷰에 어느 정도의 시간을 사용하나요?


리뷰해야 할 코드에 따라 많이 달라지는 요소라 정확하게 시간을 측정해보지는 않았습니다. 리뷰 중반까지는 대략 전체 개발 시간의 30% 수준으로 느꼈고 구성원들도 이에 동의한 적이 있습니다. 이 시간은 업무 방식에도 영향을 많이 받는데, 2~3주에 한 번 리뷰를 하는 경우 읽어야 할 코드도 많고, 리뷰 받은 코드의 양도 많아 리뷰의 의견에 답변하고 수정해야 하는 시간이 많이 필요했습니다. 시간이 흐르면서 리뷰 참여자의 역량이 향상되고, 리뷰에 능숙해지면서 리뷰에 필요한 시간은 점점 짧아졌고, 리뷰할 대상의 코드의 양을 적절히 관리하여 지금은 코드 리뷰를 특별히 시간을 많이 소모하는 작업으로 느끼지 않습니다.


Q. 코드 리뷰가 잘 될 수 있었던 것은 코드 리뷰에 참여하는 사람의 숫자가 적기 때문이 아닐까요? 사람이 많은 경우에는 적용하기 어려울 것 같은데 어떻게 생각하시는지 궁금합니다.


저희가 시작할 때 코드 리뷰에 참여하는 사람의 숫자가 적어서 의견의 일치를 이루기 쉬웠기 때문에 쉽게 진행할 수 있었다는 점은 부인하기 어렵습니다. 하지만 개발자가 소수인 곳에서의 '의견의 일치'는 개발자가 다수인 조직에서의 '개발자 문화'로 치환해 볼 수 있다고 생각합니다. 개발자의 공감을 받고 있는 개발자 문화가 있고 이 문화를 지키고 실천한다면 대규모 조직에서의 코드 리뷰도 충분히 가능하리라 생각합니다. 종종 발견하는 페이스북이나 구글에서의 코드 리뷰에 대한 글을 보면 - 실제로 그 곳에서 코드 리뷰가 잘 되고 있는지는 모르겠습니다만 - 사람의 숫자는 실행을 어렵게 할 뿐, 실행을 불가능하게 만드는 요소는 아니라고 생각합니다.


Q. 대규모 조직에서 코드리뷰를 시작한다면 어떻게 시작하실 생각인가요?


저도 대규모 조직에서 코드 리뷰를 도입해본 경험이 없으므로 아래에서 설명할 내용이 성공으로 이어질 지는 확신할 수 없습니다. 다만 팀 내에서 3명에서 시작한 리뷰가 8명까지 늘어나면서 겪었던 경험을 바탕으로 간단하게 방법을 정리해봤습니다.


1. 코드 리뷰를 실행할 개발자들이 코드 리뷰를 개발 과정의 일부로써 당연히 수행해야 하는 작업으로 생각하는 문화를 만듭니다.

2. 코딩 컨벤션 등 개발 조직에서 필요한 규칙들을 만듭니다. 그리고 이런 규칙을 쉽게 적용할 수 있는 도구를 사용합니다.

3. 개발 과정에서 리뷰의 과정이 크리티컬 패스가 되지 않도록 업무의 흐름을 재조정합니다. 특히 개발자가 아닌 다른 직군과의 협업이 필요한 부분은 리뷰의 앞단계로 빼놓거나 다른 흐름으로 분리합니다. 리뷰의 뒷 단계에는 테스트와 배포 작업만 남겨둡니다.

4. 개발 환경 설정부터 배포에 이르는 전 과정에 걸쳐 있는 작업을 자동화합니다.

5. 리뷰를 시작할 팀 2~3개를 설정합니다. 리뷰팀은 최대한 같은 코드 혹은 동일한 서비스를 만드는 사람으로만 구성합니다. 각 팀은 3~5명으로 구성합니다.

6. 리뷰팀 내에서 리뷰를 시작하며 각 리뷰팀간의 정기적인 교류를 시도합니다. 리뷰팀 사이에서 교류하는 목적은 각 리뷰팀 사이에서 발생하는 차이를 줄이고자 함입니다. 

7. 각 리뷰팀 내의 멤버를 서로 교환하여 리뷰를 진행합니다. 목적은 6번과 같습니다.

8. 6~7의 과정을 거친 후 해당 멤버들을 중심으로 5~8의 과정을 반복하며 리뷰를 진행하는 개발자를 늘려갑니다.


Q. 저희 조직에는 개발자가 저 밖에 없습니다. 이럴 때 코드 리뷰의 효과를 볼 수 있는 방법은 없을까요?


리뷰는 혼자서는 할 수 없는 활동이므로 조직 내에서 리뷰를 진행하기는 어려울 것으로 생각합니다. 오픈소스 중에서 기여할 수 있는 것을 찾아 보면 어떨까요?


Q. 지금 조직에서 코드 리뷰를 시작하고 싶습니다. 그런데 조직적으로 코드 리뷰에 대한 도움을 얻기 어려울 것 같습니다. 어떻게 시작하면 좋을까요?


무엇보다도 조직 내에서 마음이 맞는 사람을 찾으면 좋겠습니다. 두 분 정도 찾은 후, '대규모 조직에서 코드를 시작한다면 어떤 방법으로?' 질문에 있는 답에서 1, 2번을 실행하신 후 코드 리뷰를 시작하세요. 3, 4번은 리뷰를 진행하면서 개선이 가능한 부분부터 하나씩 고쳐나가면 됩니다. 조직의 도움이 없다면 개인적인 노력이 많이 필요할 수 있어 쉬운 길은 아니지만 시간을 투자하는 만큼 얻는 것은 있으리라 생각합니다.


Q. 초보 개발자끼리 코드 리뷰를 해도 도움이 될까요?


큰 도움이 됩니다. 타인의 코드를 읽고 생각하는 능력을 기를 수 있습니다. 또한 코드를 짤 때, 수정하기 쉬운 코드를 만드는 방법을 고민하게 됩니다. 이와 함께 오픈 소스 중에 맘에 드는 프로젝트를 찾아 코드를 읽어보기 바랍니다.


Q. 스타트업에 근무하는 개발자입니다. 개발할 내용이 많아 리뷰할 시간을 내기 어려운데 이 경우에 해결 가능한 방법이 있을까요?


기본적으로 코드 리뷰는 적지 않은 시간을 소비하는 활동으로 시간을 확보하는 것이 중요합니다. 시간을 만드는 방법은 여러 가지가 있겠지만 개발자인만큼 프로그램을 개발하여 업무의 효율성을 높이는 방법을 추천합니다. 반복해서 진행하는 수작업을 자동화할 수도 있겠고, 적당한 도구를 만들어 개발자가 아닌 다른 이들에게 업무를 이전할 수도 있을 것입니다. 시간을 내기 어렵다면 짧은 시간 안에 리뷰를 완료할 수 있도록 리뷰할 대상이 되는 코드를 한정지을 수도 있을 것입니다.


Q. 리뷰를 진행하면서 힘든 적은 없었나요?


첫 번째는 코딩 컨벤션에 익숙해질 때까지 입니다. 코딩 컨벤션은 자동화으로 컨벤션을 맞춰주는 도구를 사용하면 편리합니다. 어느 정도 시간이 지나고 익숙해지게 되면 특별히 도구를 사용하지 않아도 자연스럽게 컨벤션을 맞추는 자신을 발견할 수 있습니다.

두 번째는 컨벤션에 없는 암묵적인 스타일을 맞춰나가는 과정입니다. 이 부분은 실제 프로그램을 구조적으로 작성하는 방식을 맞추는 과정을 의미합니다. 로직을 작성하는 방법이나, 클래스를 설계하는 방법, 함수가 갖게 되는 기능의 범위를 결정하는 방식 등 프로그램을 실제로 만들 때 구성하는 방법을 맞춰가는 과정이 매우 힘든 경험이었습니다. 이 시기를 성공적으로 넘긴다면 코드 리뷰가 정말 큰 도움이 될 것입니다.

세 번째는 일정과 리뷰 사이에서 고민했던 시기입니다. 저희는 다행이 리뷰의 가치를 해치지 않는 방향으로 해답을 찾았고 그 결과 지금처럼 좋은 경험으로 이어질 수 있었습니다.


Q. 코드 리뷰를 통해 개발 과정에서 얻은 장점은 뭔가요?


담당하는 업무가 바뀔 때 업무의 인수 인계에 걸리는 시간이 필요 없거나 매우 짧아집니다. 이를 통해 누구나 대부분의 기능을 개발할 수 있게 되어 유연하게 업무를 진행할 수 있습니다. 물론 이 장점은 코드 리뷰와 함께 프레임워크의 도움도 매우 큽니다.

내가 작성한 코드와 타인이 작성한 코드를 구별할 수 없어 코드를 재작성하려는 하는 욕구를 최소화할 수 있습니다. 코드 리뷰의 과정을 거치고 나면 더 좋은 로직이 떠오를 때 외에는 코드를 재작성하고 싶은 생각이 들지 않습니다. 이것은 위에서 이야기한 암묵적인 스타일을 맞춰나가는 과정을 거친 후에 얻는 장점이라고 생각합니다.

타인이 작성한 좋은 패턴과 나쁜 패턴을 쉽게 익힐 수 있고 내 코드에 반영하게 됩니다. 코드를 많이 읽어 얻게 되는 장점입니다.



위의 질문 외에 더 궁금하신 내용은 댓글로 남겨주시면 계속 추가하도록 하겠습니다.



3월 20일 최초 작성

4월 3일 질문, 답변 추가




nundefined ETC Code review, KAKAO, kakaostory, 카카오, 카카오스토리, 코드 리뷰

Chrome Dev Summit 2015 - Developing for Billions 요약

2015.12.03 00:03

Chrome Dev Summit 2015의 Developing for Billions 를 요약해봅니다.


====


발표자: Tal Oppenheimer, Product Manager for Chrome


- 전세계를 대상으로 하는 웹 경험 만들기

- 2014년 말

    - 32억명의 인터넷 유저

    - 미국과 인도가 비슷한 규모

    - 인도의 경우 2014년에 3천만의 사용자가 인터넷을 처음 사용하기 시작

    - 인도와 중국의 사용자는 아직 온라인이 아닌 사람이 많음

        - 인도만 10억 이상

- 도전꺼리

    - 처음 인터넷을 사용하게 되는 경험이 다르다.

        - 남편의 전화기를 빌려 처음으로 인터넷을 경험.

    - 인도에 처음 인터넷을 쓰는 사람들이 쓰는 기기는...

        - Samsung Galaxy J1

            - 2015 발매

            - 4.3인치, 512 램, 4GB 저장공간

        - 우리가 쓰는 기기와는 다르다.

    - 웹은 이런 이런 차이에서 발생하는 문제를 많이 해결할 수 있다.

        - 저장 공간이 한정된 기기에서 인스톨이 필요 없다는 점

        - APK 크기의 제약이 없음

        - 항상 최신의 프로그램

    - 하지만 다른 제약 조건들도 있다.

        - 연결 품질: 2G가 대부분

            - 전세계의 62%가 2G

            - 인디아의 경우 87%가 2G

            - 1초가 지연되면

                - PV는 11%가 줄어듬

                - 사용자의 만족도는 16%가 감소

                - 4G나 Wifi에 비해 2G에서는 지연이 10배? 100배?가 될 수 있다.

            - 가능한 빨라지도록 만드는 것이 중요

        - 연결 비용이 비쌈

            - 500MB 데이터 요금제를 쓰려면 최저 시급으로 17시간을 일해야 함

            - 1시간의 급료로는 15페이지를 볼 수 있다. (사이트가 아님)

- 이런 이유로 사용자가 폰으로 인터넷을 사용하는 경험은 (우리와는) 다르다.

    - 주기적으로 트레이드 오프를 하게 됨

        - 하나의 사용자 경험을 선택하는 것은 다른 경험을 포기하는 것임

            - 나중에는 인터넷 연결을 못할 수도 있고

            - 그 날 혹은 그 달의 데이터를 다 쓰게 될 수도 있다.

        - 브라질의 학생의 경우

            - 하루를 시작할 때는 브라우즈를 많이 하지 않음

            - 만나기로 한 친구에게 메시지를 보낼 때 등 꼭 필요한 경우에만 사용

            - 그날 늦게, 남은 데이터 상태를 알고 나면 더 많이 탐색하고

            - 집에 도착하면 브라우즈를 함

            - 정말 데이터를 써야 할 때 데이터가 끊어지지 않을 것이라는 것을 알게 됐기 때문임.

    - 매일 데이터를 끄고 켠다.

        - 인도에서 하루에 14번 비행 모드로 옮겨가는 경우가 있었음

            - 데이터 사용에 대한 우려로 간헐적으로 접속하는 것과 더불어

            - 데이터 사용을 잘 관리하고자 하고

            - 비행 모드 전환이 데이터를 조금씩 쓰게 될거라는 믿음이 있음

            - 그래서 알지 못하고 필요하지 않을 때 데이터가 소진되지 않도록 데이터를 끔

    - 추가적인 것을 할 때는 시간과 돈이 듬

        - 페이지를 이동하면 데이터가 필요하고 충분한 데이터 요금제를 사용하기 위해서는 일을 더 해야 함.

- 그럼 뭘 해야 할까..?

    - re-engagement에 필요한 단계를 없애라.

        - 검색을 해서 원하는 페이지에 갈 때까지 여러 단계를 거치는데 add to homescreen 과 같은 것을 제공해서 중간 단계를 없앨 수 있다.

        - 앱에서 사용자에게 가장 중요하고 필수적인 경험을 바로 제공한다.

            - 웹 노티피케이션이라면 딥 링크를 제공

    - 빠르고 데이터를 조금쓰도록

        - Chrome data saver

            - 60%까지 데이터를 줄일 수 있음

            - 전세계 10%의 사용자가 사용 중

            - 이미지를 플레이스홀더로 바꿔서 필요한 이미지만 로드하도록

        - pagespeed module

            - 한 줄의 코드로도 데이터를 줄일 수 있다.

            - WebP를 지원하는 기기의 경우 이것만으로도 37%의 데이터를 아낄 수 있다. 사용자에게 보여지는 것은 동일.

        - M46 이후의 버전에서는 클라이언트에 대한 정보를 더 많이 얻을 수 있다.

            - DPR, Width, Viewport-Width

                - 사용자의 기기에 맞게 경험을 최적화 할 수 있다.

                - 화면이 작은 사용자의 경우 큰 이미지 전체를 보내지 않고 적절한 이미지를 보낼 수 있다.

            - Save-Data

                - M49

                - 사용자가 Data Saver를 사용하는지 알 수 있다.

                - save-data를 키면

                    - 꼭 필요한 이미지만 로드

                    - 비디오 해상도를 변경

                    - 동영상 자동 플레이 끔

                    - 이를 통해 사용자에게 주도권을 줌으로써 데이터에 민감한 사용자를 만족시킬 수 있다.

            - downlinkMax

                - M48

                - actual navigation connection type뿐 아니라 connection type의 maximum expected throughput을 알 수 있음

            - 개발자 도구에서 속도를 시뮬레이트 할 수 있음

    - offline experience

        - 사용자가 재방문을 하려 할 때 오프라인 공룡 페이지를 만나게 될 수 있다.

        - Service worker를 사용하면 오프라인일때도 사용자 경험을 제공할 수 있다.

            - 온라인이 되면 자연스럽게 이어질 수 있다.

- 이런 작업을 하면

    - 모든 기기에 최적화할 수 있고

    - 쉽게 재방문하도록 할 수 있고

    - 사용자의 시간과 돈을 배려할 수 있고

    - 어떤 종류의 네트워크라도 대응할 수 있다.

- 이런 방법을 적용하면 모든 사람에게 경험을 제공하는 결과물을 만들게 될 것이다.


====


동영상을 보고 가볍게 정리한 것이므로 내용을 빠뜨렸거나 잘못된 내용이 있을 수 있습니다. 발견하시는 분은 댓글로 내용을 남겨주시면 반영하겠습니다.



nundefined ETC Chrome, chrome dev summit 2015, Google, 구글, 인도, 중국, 크롬

Chrome Dev Summit 2015 - Keynote 요약

2015.11.25 01:19

지난 17, 18 양일간 마운틴뷰에서는 Chrome Dev Summit 2015가 열렸습니다. 유튜브에 행사 양일의 라이브 동영상(17일, 18일)이 공개되어 있고 각 세션별 동영상도 공개되어 있습니다. 관심있으신 분들은 동영상을 보셔도 좋겠습니다.


여기서는 첫날의 Keynote를 간단히 요약해봅니다.


====


발표자: Darin Fisher, VP of Chrome


- Android chrome은 3년 됐음

- 롤리팝 이후의 사용자들은 크롬, 웹뷰가 자동 업데이트됨

- 작년 4억명이 크롬 모바일 사용

- 올해 8억명이 크롬 모바일 사용

- 플랫폼으로써 웹의 가치

    - low friction: 설치 없이 클릭만으로 개발자가 만든 결과물에 접근할 수 있음.

        - 6월 기준

            - 매월 25개의 앱을 사용

            - 크롬 사용자는 100개가 넘는 웹 사이트를 방문

            - 80%의 시간은 3개의 앱에서 사용

            - top 10k app vs web에서 웹의 monthly uv가 더 높음

            - 모웹 트래픽이 앱보다 두 배 이상 빠르게 성장하고 있음

            - 플립보드는 모웹을 시작한 후 75% 액티브 유저 증가

- 모웹은 모바일 전략에서 매우 중요

- 웹은 크롬만이 아님. 다양한 벤더와 개발자와 협조할 것임.

- 크롬을 개선하기 위해 한 일

    - reliability

        - 네트워크 상황이 좋지 않을 때에 대한 이야기

        - 개발자는 항상 네트워크가 연결되어 있다고 가정하면 안된다.

        - 해법은 service worker

        - 2.2B Page loads/day 에서 서비스 워커 사용 중

    - performance

        - 엔진을 빠르게 하기 위해 많은 일을 하고 있음.

        - 여기서는 javascript의 속도에 대해 이야기함

        - performance is what a user perceives it is

        - RAIL이라는 metric을 사용

            - Reaction Time

            - Animation Time

            - Idle Time

            - Load Time

            - 크롬 엔진 팀에서도 이 기준으로 엔진 개선작업을 하고 있음

        - 내부적으로 개선 하는 것은

            - 10% 메모리 사용량 감소

            - 25% 시작 시간 감소

            - 25% 이상 파워 사용 감소 (맥)

        - amp project

        - polymer

    - engagement

        - 사용자가 사이트를 재방문하게 만드는 것 (re-engagement)

        - 홈스크린

            - 홈스크린에서 웹을 실행시키는 비율은 79% 성장

            - 사용자가 웹을 많이 사용하면 홈스크린에 아이콘을 추가하겠냐고 물어봄

        - push notification

            - 3억5천만 push notification / day

            - 2300 사이트에서 사용

- 이런 특징을 다 모으면 웹을 변화시킬 수 있다.

- progressive web apps

    - flipkart.com

- 크롬팀은 모바일 웹에서의 여러분의 성공을 위해 노력하고 있음.

- MDN에 많은 기여를 하고 있음.

- udacity web nanodegree 개설


====


동영상을 보고 가볍게 정리한 것이므로 내용을 빠뜨렸거나 잘못된 내용이 있을 수 있습니다. 발견하시는 분은 댓글로 내용을 남겨주시면 반영하겠습니다.





nundefined ETC Chrome, chrome dev summit 2015, Google, 구글, 크롬