2014년 1월 23일 목요일

[튜토리얼/한글화] 사용자 타이밍 API: 웹앱의 이해(User Timing API Understanding your Web App)

HTML5Rocks에 +Alex Danilo의 튜토리얼 '사용자 타이밍 API: 웹앱의 이해(User Timing API Understanding your Web App)'의 한글 버전이 업데이트되었습니다.

이전에도 시간을 이용하여 성능을 측정하는 방법은 있었지만 실제로 스크립트의 설정과 시간 관련 API 들의 제한으로 인해 자세하고 정확하게 측정하기는 어려웠습니다. 이를 해결하기 위해 W3C에서는 High Resolution Time Stamp라는 타입을 추가하였고 이제 모던 브라우저에서 이를 사용할 수 있는 User Timing API이 구현되어 있습니다.

이 튜토리얼은 사용자가 페이지의 로딩, DOM Ready, Navigation 시간 등이나 사용자가 지정한 지점 간의 시간을 측정하기 위한 Timing API를 다루고 있습니다. 이번 번역은 한순보님께서 수고해주셨습니다. :)

"Performance API는 개발자가 직접 측정하기 어려운 페이지 로딩 시간 등을 조회할 수 있도록 해주며 개발자가 직접 지정한 지점을 표시(.mark() 함수)하고 이를 측정(.measure() 함수)할 수 있도록 해주는 등의 스크립트 수준에서의 성능 측정 방법을 제공합니다. Performance API를 이용하면 로딩, 렌더링부터 함수 혹은 특정 실행 사이클을 가지는 모듈의 측정 등 다양한 형태로도 활용할 수 있는 가능성이 있습니다. 프로젝트에서 개발자도구만으로 측정할 수 없는 부분이 있다면 Performance API를 개발 작업흐름 내에 포함하는 것도 좋은 방법이 될 것입니다."


TL;DR;


최적화에 있어서 가장 첫번째 단계는 병목 지점을 찾아내기 위한 측정(Measure)입니다. 반대로 이야기하자면 측정이 없다면 단지 경험과 시간을 사용하여 수정하고 테스트하는 반복적인 과정을 피할 수 없습니다. 물론 개발자 도구에서 렌더링이나 리소스에 대한 로딩 타임들을 측정할 수 있지만 이는 우리의 프로젝트에서 일부에 불과합니다.

User Timing API는 이렇게 도구에서 지원하지 않는 코드 상의 측정을 위한 기능들을 다음과 같이 제공합니다.

(Perfomance API는 아래에서 언급하는 내용 이외에도 Navigation에 대한 정보 그리고 Chrome의 경우 여기에 메모리 사용량도 지원하지만 이 튜토리얼에서는 다루지 않습니다.)


고해상도 시간(High Resolution Time)
  • W3C의 규격에서 High Resolution Time이란 밀리초(msec) 이하의 시간 단위를 말합니다. 이는 보다 정밀한 시간 측정이 가능하므로 아주 짧게 실행되는 코드에 대한 반복적인 실행 없이 시간 측정이 가능한 것을 뜻합니다.

사용자 타이밍 인터페이스(User Timing Interface)
  • 기본적으로 사용자 타이밍 인터페이스는 개발자가 직접 측정하기 어려운 URL 요청, 응답, 페이지 로딩 시간, DOM 로딩, 완료 등에 대한 지점(Mark)를 기본으로 포함합니다.
[그림] performance.timing이 가진 기본 Mark들
  • User Timing API는 사용자 타이밍 인터페이스의 기본 지점과 사용자가 직접 지점을 설정 및 해제할 수 있으며 이를 기반으로 하는 측정 시간과 데이터 액세스 기능을 제공합니다.
  • 설정 및 해제
    • .mark()/.clearMarks() : 사용자 지점 설정/해제
    • .measure()/.clearMeasures() : Mark 간의 시간 측정 설정/해제
  • 데이터 액세스
    • .getEntriesByType() : 주어진 타입('mark' 혹은 'measure')에 대한 엔트리 반환
    • .getEntriesByName() : 주어진 이름에 따른 엔트리 반환


이 튜토리얼은 이러한 API의 사용 방법부터 Ajax 호출에 대한 성능 측정 방법에 대해 다루고 있습니다. 보다 자세한 내용은 튜토리얼을 참고하시기 바랍니다.



번역 링크

[업데이트] Yo Polymer – 웹 컴포넌트 도구화로의 빠른 여행 (Yo Polymer – A Whirlwind Tour Of Web Component Tooling)

HTML5Rocks에 +Addy Osmani의 Yeoman, Polymer의 도구화와 관련된 포스트가 업데이트되었습니다. Whirlwind tour는 원래 '정신없이 빠르게 진행되는 여행'이라고 하네요. :)

이 포스트는 웹 컴포넌트의 Polyfill 라이브러인 폴리머(Polymer)와 이를 구축하기 위한 도구인 Yeoman의 개괄적인 사용 방법, 그리고 +Addy OsmaniChrome Dev Summit의 발표에서 보여준 데모인 Jukebox 앱에 대한 간략한 소개와 동영상을 담고 있습니다. 자세한 내용은 전문을 참조하세요. :)




전문


Web Components는 웹을 구축하는데 있어 여러분이 알고 있다고 생각하는 모든 것을 바꾸고 있습니다. 처음으로 웹이 우리 자신의 HTML 태그들을 생성하는 것만이 아니라 로직과 CSS를 캡슐화할 수 있는 저수준 API를 가질 예정이었습니다. 더 이상의 전역 스타일시트 수프나 보일러플레이트 코드는 없습니다! 이는 모든 것이 엘리먼트인 멋지고 새로운 세계입니다.

DotJS에서의 발표에서 저는 웹 컴포넌트가 무엇을 제공해야하는지와 최근의 도구들을 이용하여 이를 어떻게 구축할 수 있는지에 대해 자세하게 설명했습니다. 저는 여러분에게 오늘날 모던 브라우저에서 웹 컴포넌트를 사용하여 앱을 개발하기 위해 Yeoman과 Polymer를 이용하여 웹앱 생성을 간소화하는 도구들의 작업흐름, Polyfill 그리고 설탕 한 숟가락(sugar)을 보여드릴 것입니다.



커스텀 엘리먼트 생성하기와 다른 이들이 만든 엘리먼트 설치하기

이 발표에서 우리는 다음과 같은 것들을 배울 수 있을 것입니다.

  • 웹 컴포넌트를 구성하는 Custom ElementsTemplatesShadow DOM 그리고 HTML imports 4가지의 각 규격들에 대해
  • Bower를 이용하여 어떻게 여러분만의 커스텀 엘리먼트를 정의하고 다른 이들이 만든 엘리먼트를 설치하는지
  • 적게 자바스크립트를 작성하고 페이지 구축에 더 많은 시간을 사용하기
  • 폴리머와 generator-polymer를 사용하여 어플리케이션을 스캐폴딩하기 위한 모던 프론트엔드 도구(Yeoman) 사용하기
  • 웹 컴포넌트의 생성을 폴리머가 얼마나 대단하게 바꾸었는가

예를 들어 폴리머의 웹 컴포넌트 폴리필들(Polymer's Web Component polyfills)과 그 자신의 라이브러리를 설치하기 위해 여러분은 다음과 같이 한줄을 실행할 수 있습니다.

bower install --save Polymer/platform Polymer/polymer

이는 bower_components 폴더와 위의 패키지들을 추가합니다. --save는 이들을 앱의 bower.json 파일에 추가합니다.

그 다음, 폴리머의 아코디언(accordion) 엘리먼트를 설치하기 위해 다음과 같이 실행합니다.

bower install --save Polymer/polymer-ui-accordion

그리고나서 이를 어플리케이션 내에 불러(import)옵니다.

<link rel="import" href="bower_components/polymer-ui-accordion/polymer-ui-accordion.html">

시간을 절약하고  앱 최적화를 위한 도구들과 보일러플레이트 코드들이 완료될 수 있도록 Yeoman을 통해 새로운 폴리머 앱을 필요한 모든 의존성들과 함께 스캐폴딩하도록 다음과 같이 또다른 한줄을 실행합니다.

yo polymer

추가 설명


또한 저는 이 발표에서 보여드린 폴리머 주크박스 앱에 대한 30분짜리 자세한 추가 설명을 기록해두었습니다.




이 추가 비디오가 다루는 것들은 다음과 같습니다.

  • "모든 것이 엘리먼트(Everything is an element)"라는 주문이 무엇을 의미하는가
  • 폴리머의 플랫폼 폴리필과 엘리먼트들을 설치하기 위해 어떻게 Bower를 사용하는가
  • 주크박스 앱을 Yeoman generator와 sub-generator들을 사용하여 스캐폴딩하기
  • 보일러플래이트를 통해 스캐폴딩된 플랫폼 기능의 이해
  • 어떻게 제가 Angular 앱을 폴리머로 실용적으로 포팅했는지

또한 우리는 새로운 폴리머 엘리먼트들을 스캐폴딩하기 위해 Yeoman sub-generator를 활용하였습니다. 예를 들어 foo 엘리먼트를 위한 보일러플래이트를 생성하기 위해 다음과 같이 실행합니다.

yo polymer:element foo

엘리먼트를 자동으로 불러올지 혹은 생성자가 별도로 필요한지와 몇가지 다른 선호사항들에 대한 프롬프트가 표시될 것입니다.

앱을 위한 최종적인 소스는 발표와 GitHub에서 확인할 수 있습니다. 좀 더 구조적이고 읽기 쉽도록 약간 더 리팩토링을 해두었습니다.

앱의 미리보기는 다음과 같습니다.




추가적인 읽을거리들


요약하자면 폴리머는 웹 컴포넌트가 네이티브로 구현되기를 기다리는 동안 이를 모던 웹 브라우저에서 가능하도록 하는 자바스크립트 라이브러리입니다. 현재적인 도구화는 이들을 사용하는 여러분의 작업흐름을 개선할 수 있도록 도와주므로 여러분은 여러분만의 태그를 개발할 때 Yeoman과 Bower에 대한 시도를 즐겨볼 수 있을 것입니다.

이 주제에 대해 확인해볼만한 몇가지 다른 글들은 다음과 같습니다.




2014년 1월 20일 월요일

[튜토리얼/한글화] Shadow DOM 201: CSS와 스타일링 (Shadow DOM 201: CSS and Styling)

HTML5Rocks의 Shadow DOM 관련 튜토리얼 중 +Eric Bidelman의 'Shadow DOM 201: CSS와 스타일링 (Shadow DOM 201: CSS and Styling)' 튜토리얼의 한국어 번역이 업데이트되었습니다.

웹 컴포넌트 관련 튜토리얼마다 말씀드리는 내용입니다만 Shadow DOM 역시 이전의 Custom Element나 HTML Imports처럼 웹 컴포넌트를 지탱하는 4가지 규격 중의 하나입니다. Shadow DOM은 DOM에 대한 캡슐화(Encapsulation)와 같은 매우 강력한 기능을 제공합니다. HTML5Rocks에는 다음과 같이 Shadow DOM에 대한 3개의 튜토리얼이 업데이트되어 있습니다.
  1. Shadow DOM 101 - Shadow DOM의 기초적인 개념 및 구조
  2. Shadow DOM 201: CSS and Styling - Shadow DOM의 CSS 규칙 적용 및 스타일화 방법
  3. Shadow DOM 301: Advanced Concepts and DOM API다중 ShadowRoot 사용 및 자바스크립트를 통한 삽입 등의 발전된 DOM 동작

이 튜토리얼은 Shadow DOM를 사용할 때 캡슐화된 DOM 내의 스타일과 호스트 문서로부터의 스타일 상속 혹은 상속을 재설정하는 방법 등에 대해 설명합니다.

"Shadow DOM이 컴포넌트를 구성하는 DOM을 감추는 역할(encapsulation)뿐만이 아니라 스타일에 대한 캡슐화를 지원함으로써 여러분은 배포된(혹은 배포한) 웹 컴포넌트에 대해 여러분의 스타일을 유지하거나 반대로 사용자의 페이지의 Look&Feel을 상속받아 위화감 없는 스타일을 구성할 수도 있습니다. 이러한 스타일에 대한 캡슐화는 특히 사이트를 구축하는 UI 요소로써는 매우 중요한 속성이 될 것입니다. 더불어 이러한 캡슐화된 스타일을 어떻게 관리할 것인가도 웹 컴포넌트의 사용자들에게는 중요한 지점이 될 것입니다."


TL;DR;


이 튜토리얼은 Shadow DOM 101에서 다뤘던 개념들을 기초로 하여 Shadow DOM의 외양(Look&Feel)을 다루기 위한 몇가지 방법과 개념에 대해 다룹니다.

Shadow DOM은 DOM 자체에 대한 캡슐화(Encapsulation) 외에도 스타일에 대한 캡슐화를 지원하고 있습니다. 이렇게 스타일에 관련된 Shadow DOM의 핵심 기능 중의 하나는 섀도 경계(shadow boundary)입니다. Shadow DOM이 DOM에 대한 캡슐화만 지원하는 것이 아니라 자유로운 스타일 캡슐화를 제공하여 Shadow DOM 내의 스타일을 외부에서 격리시켜 유지하거나 반대로 외부의 스타일을 그대로 상속받아 위화감 없이 페이지의 Look & Feel을 유지할 수도 있습니다.

특히 :host를 이용하여 호스트가 되는 엘리먼트에 따라서 스타일을 다르게 지정하거나 확장하는 것이 가능하며, ^과 ^^ 연결자를 통해 섀도 경계(Shadow Boundary)를 무효화하는 것처럼 Shadow Tree 내의 스타일에 관여할 수도 있습니다. (^은 Hat, ^^은 Cat이라고 부릅니다.) 이러한 섀도 경계를 가로지르는 스타일링의 경우 Shadow DOM의 사용자가 정의한 스타일을 손쉽게 연결할 수 있도록 CSS Variable을 이용한 스타일 연결을 만들어내거나 .resetStyleInheritance 혹은 .applyAuthorStyles를 이용하여 스타일에 대한 상속 적용 여부를 결정지을 수도 있습니다. 또한 Shadow DOM 내에 배포된 노드들의 경우는 의사 엘리먼트(::content)를 이용하여 유연하게 확장할 수 있습니다.

보다 자세한 내용은 튜토리얼을 참고하시기 바랍니다.



번역 링크


참고 글

2014년 1월 17일 금요일

[튜토리얼/한글화] EME란 무엇인가? (EME WTF?: An introduction to Encrypted Media Extensions)

HTML5Rocks에 +Sam Dutton의 'EME란 무엇인가?: 암호화된 미디어 확장(EME WTF?: An Introduction to Encrypted Media Extensions)' 튜토리얼이 라이브되었습니다. 이번 번역은 한순보님께서 수고해주셨습니다. :)

EME는 말 그대로 Encrypted Media Extension의 약자로 미디어 엘리먼트(Video, Audio)에 대한 DRM(Digital Rights Management)를 제공하는 규격입니다. 논란이 있기는 했지만 어쨌던 서버에서 제어하던 비디오 등의 미디어 액세스 권한을 브라우저 측으로 내렸다고 봐도 무방합니다. 미디어 서비스를 하시는 분들이 주로 관심이 많겠네요. :)

아래는 W3C Restrict Media Community Group에서 이루어진 EME에 대한 논의 요약입니다. 본문에도 포함되어 있지만 아직 논란이 많은 부분이라 따로 발췌해서 첨부합니다.

  • 장점
    • EME(또는 같은 기술) 없이는 미디어 기업들은 웹을 통해 컨텐츠를 배포하지 않을 것입니다.
    • 잠겨진 장치에 대해 제한된 컨텐츠의 배포를 방지할 수 있습니다.
    • 파편화되고 유지보수가 불가능하며 독점적인 솔루션에 대한 의존을 줄여주는 개방형 표준입니다.
    • CDM으로부터 분리된 EME API 디자인의 유지를 통해 EME가 노후되는 것을 방지할 수 있습니다.
      • 역주: 즉, 실제 복호화 등에 대해 기능이 분리되어 운영체제 등의 업데이트로 지속적으로 암/복호화 등의 기반 기술의 업데이트가 가능하다는 뜻입니다만 이게 논란의 여지이기도 합니다. 인터페이스는 있으나 실제 구현으로 인한 의존도가 있다는 주장도 있다는 것이죠.
    • 컨텐츠 저작자가 수익을 얻는 것을 가능하게 하므로 DRM은 본질적으로 악한 것이 아닙니다.
    • 미디어 기업들이 다른 것을 건드리지 않고 웹을 통해 배포할 수 있도록 합니다.
    • EME(또는 같은 기술)은 W3C에서 관리할 것이며 W3C 표준은 여러개의 산업 표준보다 낫습니다.
  • 단점
    • 실제의 권한 관리는 W3C 규격에 포함되지 않았습니다.
    • 이를 다르게 부르자면 DRM이며 DRM은 오픈 웹에 대해 적대적인 개념입니다.
    • EME는 DRM이고 DRM은 지금까지 절대로 동작한 적이 없습니다.
      • 역주: 즉, DRM이 제대로 지원 및 표준화되어 제공된 사례가 없다는 뜻입니다.
    • (DVD에서 사용자가 광고를 건너뛰는 것을 불가능하게 한 것처럼) 사용자가 아니라 기업의 이익을 위해 설계되어 있습니다.
    • 다른 형태의 DRM보다 접근성에 있어 더 안좋습니다.
    • 본질적으로 플러그인 아키텍처를 의미하는 CDMS에 의존하며 플러그인은 좋지않은 선택입니다.
    • 컨텐츠 보호 메커니즘과 같은 결함이 있습니다 .
    • 스트리밍은 표준이 될 것이며 그 맥락에서 모든 형태의 DRM은 미디어가 훨씬 더 적게 액세스되도록 할 것입니다. 사용자 에이전트, 운영체제 그리고 하드웨어를 방해함으로써 말입니다.


"사실 DRM은 온라인 미디어 산업의 요구사항이 강하게 반영된 것이지만 도입과정에는 많은 논란이 있었습니다. 모두에게 공평하게 정보를 오픈하는 웹에 대해 보안이 아니라 사실상 컨텐츠의 제어를 제공하는 기능을 제공한다는 점과 실제 구현에 있어서 암호화된 컨텐츠를 복호화하기 위한 CDM(Content Decryption Module)은 브라우저 외부에 정의되어 기술의 지나친 경쟁과 파편화를 유도할 수 있다는 점이었죠. 현재 시점에서는 컨텐츠 저작 및 유통측의 손을 들어준 상태입니다만 CDM에 대해서는 지속적인 논란이 있을 것 같습니다."


TL;DR;


EME는 미디어 엘리먼트(Video, Audio)에 대한 DRM(Digital Rights Management)를 제공하는 규격입니다. EME(Encrypted Media Extensions)는 웹 어플리케이션이 암호화된 오디오와 비디오 재생의 허가를 위한 컨텐츠 보호 시스템과 연동할 수 있도록 하는 API를 제공합니다.

이 튜토리얼은 다음과 같은 EME를 이용한 미디어 재생의 개략적인 동작 과정을 다루며

  1. 하나 이상의 암호화된 스트림을 가진 오디오나 비디오의 재생 시도
  2. 브라우저가 미디어의 암호화를 인지하고 액세스를 위한 키 요청 이벤트(needkey)를 메타데이터와 함께 전달하고
  3. 어플리케이션이 needkey 이벤트에 대해 미디어키가 없을 경우 사용가능한 키 시스템과 라이센스 서버를 통해 키 생성합니다.
  4. CDM 연동을 위한 세션을 생성하여
  5. CDM이 준비되면 message 이벤트를 발생하고
  6. 세션이 message 이벤트를 수신하여 라이센스 서버에 대해 키를 요청하고
  7. 라이센스 서버로부터 전달받은 데이터를 미디어 키 세션을 통해 전달받고
  8. 라이센스 내의 키들을 이용하여 미디어 복호화하여
  9. 미디어 재생을 시작

이외에도 기본적인 기능으로 미디어에 대한 복호화 기능을 제공하는 CDM부터 라이센스 서버로부터의 키획득, 일반적인 암호화 및 클리어 키(Clear Key) 등에 대한 소개와 데모 등을 포함하고 있습니다.

보다 자세한 내용은 튜토리얼을 참고하시기 바랍니다.

번역 링크


2014년 1월 16일 목요일

[업데이트] 말하는 웹앱 - Speech Synthesis API (Web apps that talk - Introduction to the Speech Synthesis API)

+Eric Bidelman이 재밌는 포스트를 올렸네요. 바로 Web Speech API입니다. 아주 간단한 형식으로 되어 있는 API들이지만 손쉽게 TTS(Text To Speech)를 수행하며, 반대로 STT(Speech To Text)를 수행할 수도 있습니다. 현재는 크롬에서만 지원하고 있는 기능이지만 유용하게 사용할 수 있는 기능입니다. 무엇보다 쉬워서 재밌네요! :)


전문


Web Speech API는 음성인식(Voice recognition, Speech To Text)와 음성합성(Speech synthesis, Text To Speech) 기능을 자바스크립트에 추가하였습니다. 이 포스트는 Chrome 33 버전(모바일 및 데스크탑)에 최근 추가된 API에 대한 마지막 버전을 대략적으로 포함하고 있습니다. 만약 음성 인식에 흥미가 있으시다면 Glen Shires가 얼마전
음성 인식 기능에 대해 쓴 "말로 동작하는 웹앱: Web Speech API의 소개(Voice Driven Web Apps: Introduction to the Web Speech API)"을 참조하시기 바랍니다.

기초 사항


Synthesis API의 가장 기본적인 사용은 다음과 같이 speechSynthesis.speak()로 보내고 말로 표현하는 것입니다.
var msg = new SpeechSynthesisUtterance('Hello World');
window.speechSynthesis.speak(msg);
직접 시도해보세요! 

또한 볼륨, 말하는 속도, 음의 높이, 목소리 그리고 언어에 영향을 미치는 인자를 대치하는 것 역시 다음과 같이 가능합니다.
var msg = new SpeechSynthesisUtterance();
var voices = window.speechSynthesis.getVoices();
msg.voice = voices[10]; // Note: some voices don't support altering params
msg.voiceURI = 'native';
msg.volume = 1; // 0 to 1
msg.rate = 1; // 0.1 to 10
msg.pitch = 2; //0 to 2
msg.text = 'Hello World';
msg.lang = 'en-US';

msg.onend = function(e) {
  console.log('Finished in ' + event.elapsedTime + ' seconds.');
};

speechSynthesis.speak(msg);

목소리(Voice) 설정


또한 API를 통해 엔진에서 지원하는 목소리(Voice)의 리스트를 다음과 같이 얻을 수 있습니다.
speechSynthesis.getVoices().forEach(function(voice) {
  console.log(voice.name, voice.default ? '(default)' :'');
});
그리고나서 다음과 같이 utterance 객체의 .voice의 설정을 통해 다른 목소리를 설정할 수 있습니다.
var msg = new SpeechSynthesisUtterance('I see dead people!');
msg.voice = speechSynthesis.getVoices().filter(function(voice) { return voice.name == 'Whisper'; })[0];
speechSynthesis.speak(msg);

데모


구글 I/O 2013 발표 "더 멋진 웹: 여러분이 언제나 원하는 기능들(More Awesome Web: features you've always wanted)"에서 저는 구글 나우(Google Now)나 시리(Siri)와 비슷하게 Web Speech API의 SpeechRecognition 서비스와 구글 번역 API(Google Translate API)를 통해 마이크 입력을 다른 언어로 자동으로 번역하는 데모를 보여드렸습니다.



불행하게도 이는 음성 합성(Speech synthesis)를 수행하기 위해 문서화되지 않은 기능(그리고 비공식적인 API)을 사용하였습니다. 자 이제 우리는 다시 번역을 말할 수 있는 완전한 Web Speech API를 가지게 되었습니다! 데모는 Synthesis API를 사용하도록 업데이트해두었습니다.


브라우저 지원


현재 Chrome 33 버전은 Web Speech API를 완전하게 지원하며 iOS7의 사파리는 일부의 기능을 지원하고 있습니다. 

기능의 지원여부 검사


(크로미움의 경우처럼) 각 브라우저들은 Web Speech API를 각 부분을 따로 지원하고 있을 것이므로 다음과 같이 각 기능을 분리하여 검사할 수 있습니다.
if ('speechSynthesis' in window) {
 // Synthesis support. Make your web apps talk!
}

if ('SpeechRecognition' in window) {
  // Speech recognition support. Talk to your apps!
}

2014년 1월 13일 월요일

[업데이트/Summit] 크롬 개발자 서밋: 오픈 웹 플랫폼 부문 요약(Chrome Dev Summit: Open Web Platform Summary)

Chrome Dev Summit의 오픈 웹 플랫폼에 대한 +Sam Dutton의 요약이 업데이트되었습니다.






블링크(Blink) by +Greg Simon & +Eric Seidel



블링크는 크롬의 오픈소스 렌더링 엔진입니다. 블링크 팀은 개발자들이 부딪히는 이슈들을 고민하며 웹을 혁신하고 있습니다.

여기에는 지난 4월의 런칭으로부터 시작하는 수많은 감춰진 개선사항들이 있습니다.

첫번째로 우리는 더 이상 필요로 하지 않는 절반가량의 소스를 삭제했으며 아직도 이는 끝나지 않았습니다! 그리고 리포팅 의사 표시를 한 크롬 사용자들로부터 익명으로 리포팅된 종합적인 통계들에 기반한 코드 제거에 대해 묵과하지 않고 있습니다.

우리는 새로운 개발자 API를 크롬의 탑재 스케줄과 동일하게 매 6주마다 발행하고 있습니다.

블링크로부터 포크했을 때 가장 큰 변경은 다음과 같은 인텐트(Intent) 시스템을 추가하는 것입니다. 웹 플랫폼을 변경하려 하기 전 매번 우리는 기능의 추가나 삭제를 위한 우리의 의도를 표현하기 위해 블링크 개발자 그룹을 통해 공개 발표를 해왔습니다. 그리고나서 움직였고 코드를 작성했습니다! 그리고나서 기능을 체크인한 바로 다음날이면 카나리 빌드에 이미 탑재된 상태였습니다. 이러한 기능은 기본적으로 Off된 상태이지만 about:flags를 이용하여 이를 활성화할 수 있습니다.

그 후 우리는 공용 메일링 리스트 상에서 이에 대한 탑재 의도를 발표했습니다.

chromestatus.com에서 우리가 작업한 기능들, 탑재한 기능들, 제거할 계획을 가지고 있는 것들을 확인할 수 있습니다. 또한 크롬 배포 블로그에서 버그들에 대한 링크들과 추적 대쉬보드를 확인할 수도 있습니다.

또다른 큰 변경사항은 WebKit 접두어를 삭제하고 있는 것입니다. 의도는 블링크의 접두어를 사용하기 위함이 아니라 (그저 컴파일 시의 플래그만이 아닌) 런타임 플래그를 가지기 위함입니다.

안드로이드 웹뷰는 아주 커다란 도전이었습니다만 HTML5Test는 이들이 더 좋아졌음을 보여줍니다. 웹 플랫폼 API들이 어디에서나 하나의 세트를 가지는 관점에서 데스크탑에 훨씬 더 가까워졌습니다. (웹 오디오는 이에 대한 훌륭한 예제입니다!)

그러나 어떻게 소세지 기계가 동작하나요? 각각의 모든 변화들은 나중에 추가적으로 실행할 모든 크로미움 테스트는 말 할 필요도 없이 블링크가 30,000개 이상의 테스트를 즉시 거치도록 했습니다. 우리는 24시간 보안관, 수천개의 봇들, 수천개의 벤치마크 그리고 갑자기 중단되지 않음을 확신하기 위해 몇백만개의 깨진 웹 페이지를 엔진으로 던지는 시스템들을 사용하고 있습니다. 우리는 모바일이 두드러지게 느리고 이는 우리가 개선을 위해 훨씬 더 열심히 일해야한다는 뜻임을 알고 있습니다.

그럼 무엇이 새로워졌을까요?
  • Web Components: +Eric Bidelman의 발표를 확인해보세요!
  • Web Animations: 가능한한 GPU를 사용하는 복잡하고 동기화된 고성능 애니메이션
  • Partial Layout: 필요한 것만 계산하는!
  • CSS Grid
  • Responsive images: srcset 혹은 srcN 또는?
  • 더 빨라진 텍스트 자동 래스터 조정(Autosizing) 일관된 서브픽셀(Sub-pixel) 폰트
  • 블링크의 그래픽 시스템인 SKIA가 윈도우즈용에서 GDI에서 DirectWrite로 이동

우리는 여러분들이 무엇을 말할지 알고 싶습니다!

만약 여러분이 혈관을 흐르는 C++을 느끼고 작성하고 싶다면, 우리의 모든 코드는 열려있습니다. 만약 누구에게도 말하지 않고 우리에게 전파를 할 수 있습니다. 그냥 패치를 포스팅하거나 버그를 정리해주세요!

슬라이드: Blink



보안(Security) by +Parisa Tabriz


오늘날은 그 언제보다도 더 많은 사람들이 더 많은 곳에서 웹으로 연결되어 있습니다.

우리는 랩탑, 휴대폰 그리고 태블릿으로 연결되어 있으며 아마도 곧 개인 디바이스들과 액세서리들로도 충분해질 것입니다. 우리는 신뢰할 수 없거나 가끔은 적대적인 네트워크로부터도 인터넷을 액세스합니다. 삶의 많은 부분이 온라인으로 이동하며 우리의 데이터와 우리 사용자의 데이터를 보호하기 위한 단계가 중요해졌습니다.

무엇보다 개발자로써의 우리는 SSL의 필요성과 실현 가능성에 대해 이해할 필요가 있습니다.

SSL이란 무엇일까요? 이는 전송 계층 보안(Secure Sockets Layer)를 의미하고 인터넷 간의 통신 보안을 제공하기 위해 디자인된 암호화 프로토콜입니다. 암호화와 완전성을 통해 인터넷 연결을 통한 스누핑(Snooping)이나 데이터 훼손(Tempering)을 방지하기 위한 프라이버시를 보장합니다. SSL은 결점이 있지만 주도적인 방식-그리고 실제로는 유일한 방식-이며 인터넷 상의 데이터 통신 보안의 어떠한 것이라도 보장할 수 있는 방식입니다.

SSL Pulse에 따르면 1년 전에는 우리의 SSL 적용은 15% 미만 밖에 안되었지만 현재는 50%가 넘습니다.


다음과 같이 2가지 약어(Acronyms)가 있습니다.

  • TLS: SSL과 거의 마찬가지의 목적 및 의도를 가집니다. 보다 정확하게는 SSL 3.1의 명칭이 TLS로 변경되었으며 TLS는 IETF 표준 명칭입니다. 그러나 이는 교환 가능합니다!
  • HTTPS: SSL를 통한 HTTP이며, 그저 SSL과 표준 HTTP의 보안 능력을 계층화한 것입니다. 처음 클라이언트-서버 간의 Handshake는 통신을 암호화하기 위한 SSL 프로토콜의 두번째 부분에서 사용되는 공용 키를 생성하기 위해 공용/개인 키 암호화를 사용합니다.

인터넷 상의 네트워킹은 안전하고, 즉각적이며 빠르다고 느낄 수도 있습니다. 이는 우리가 주로 웹사이트에 대해 얘기하는 것과 비슷한 느낌입니다. 그러나 실제로는 이는 직접적인 연결이 아닙니다. 우리의 통신은 디바이스와 웹 사이트 간의 WiFi 라우터나 ISP 그리고 잠재적인 다른 중간 프록시를 통해 움직입니다. HTTPS가 없이는 모든 연결은 평문 속에 존재합니다.

문제는 사용자가 아주 가끔 HTTPS를 정의하는 완전한 URL을 타이핑하거나 HTTP를 사용한 링크를 클릭하는 것입니다. 더 나쁘게 얘기하자면 중간자 공격을 시작하거나 HTTPS를 HTTP로 변경할 수 있습니다. 2009년에 소개된 SSLstrip으로 불리는 도구가 바로 그러한 일을 수행합니다. 2010년에 발표된 Firesheep은 열려있는 WiFi 네트워크에서 깔끔하게 전송된 쿠키들을 바로 청취할 수 있으며 이는 다른 사람의 페이스북 계정에 로그인하거나 채팅을 엿들을 수 있다는 것을 의미합니다.

그러나 SSL은 (비교적) 저렴하고 빠르며 배포하기 쉽습니다. (ssllabs.com과 +Ilya Grigorik 의 저서 '고성능 브라우저 네트워킹'을 확인해보시기 바랍니다.) 상용이 아닌 경우 여러분은 startsll.com으로 부터 무료로 인증을 받을 수도 있습니다! Public Key Pinning은 웹사이트 운영자들이 당사자들이 그들의 사이트 인증서를 실제로 이슈화할 수 있는 인증 범위를 제한할 수 있도록 디자인되었습니다.

"올해(2010) 1월, Gmail은 기본사항으로 모든 것에 대해 HTTPS를 사용하도록 변경되었습니다. ..이를 위해 우리는 추가적인 장치나 특별한 하드웨어 없이 이를 배포해야 했습니다. 우리의 프론트엔드 생성 장비들 상에서 SSL 계정들은 1% 이하의 CPU 부하와 10KB 이하의 연결당 메모리 사용량 그리고 2% 이하의 네트워크 부하를 차지하며...
만약 지금 여기까지만 읽고 싶으시다면 그냥 하나만 기억하세요. SSL은 더 이상 연산량에 있어 비싸지 않습니다." – Overclocking SSL, Adam Langley (Google)

마지막으로 우리가 일반적으로 볼 수 있는 몇가지 버그들은 다음과 같습니다.

  • 혼합된 컨텐츠:
    • HTTPS뿐만이 아니라 HTTP를 사용하는 사이트들. 컨텐츠가 로딩될 때 권한에 대한 클릭을 해야하므로 여러분의 사용자는 짜증이 날 수 있습니다. (크롬, 파이어폭스는 실제로 iframe들이 컨텐츠를 혼합하는 것을 막습니다.) 예를 들어 <style src="//foo.com/style.css">와 같이 HTTPS 페이지 내의 모든 리소스들을 상대 경로 혹은 상대-스키마(Scheme-Relative)를 사용하여 반드시 HTTPS로 로딩하도록 합니다.
  • 안전하지 않은 쿠키들:
    • HTTP 연결을 통해 깨끗하게 보내는 경우. 쿠키 헤더들 상의 보안 속성의 설정을 통해 이를 회피하도록 합니다. 여러분은 SSL 전송 보안(SSL Transport Security, HSTS)를 요구하도록 새로운 "Strict Transport Security"를 사용할 수도 있습니다.


요점(Takeaways)


  • 만약 프라이버시와 사용자 데이터의 완전성을 관리하고 싶으시다면 SSL을 사용하여야 합니다.
  • 이는 그 무엇보다 빠르고 쉬우며 저렴합니다.
  • 혼합된 컨텐츠 버그나 올바른 HTTP 헤더 부분의 설정없는 일반적인 구현들을 회피하여야 합니다.
  • 상대 경로 혹은 상대-스키마 URL을 사용합니다.
  • HSTS와 인증서 피닝(Certification pinning)과 같은 훌륭한 신규 기능을 확인해보시기 바랍니다.


슬라이드: Got SSL?



멀티디바이스 웹을 위한 Media APIs by +Sam Dutton & +Jan Linden


웹 상의 새로운 디바이스나 플랫폼들의 확산 속에서 우리는 오디오, 비디오 그리고 실시간 통신의 커다란 성장을 보고 있습니다. 온라인 미디어는 모든 종류의 미디어를 우리가 소비할 수 있도록 방식을 바꾸고 있습니다.

영국 정부의 사례에서 53%의 성인이 TV를 보는 동안 모바일 디바이스를 사용하여 미디어를 소비하고 공유하는 '미디어 멀티-태스크'를 한다는 것을 발견할 수 있습니다. 많은 나라에서 TV를 보는 것은 감소하고 있고 온라인 시청은 증가하고 있습니다. 예를 들어 중국의 경우 2009년에 70% 달했던 베이징 가정의 TV 시청이 2012년 단 30%로 감소하였습니다. W3C 2013년 하이라이트에 따르면 '작년동안 모바일 장비에서의 비디오 시청이 2배로 증가하였습니다. 미국의 경우 올해 디지털 미디어의 일일 사용에 대한 평균 시간이 TV 시청을 넘었습니다. 시청은 더 이상 일반적인 행동이 아닙니다. 미국에서는 87%의 엔터테인먼트 소비자들이 TV를 시청하는 동안 최소한 1개 이상의 세컨-디바이스를 사용하고 있다고 말하고 있습니다.' Cisco에 따르면 '비디오는...2017년 글로벌 사용자 트래픽의 80%에서 90%를 차지할 것`이라고 합니다. 이는 매초마다 몇백만분의 비디오가 보여진다는 것과 거의 동일합니다.

그렇다면 웹 개발자들은 무엇을 해야 할까요? 오픈 웹을 위한 미디어 API의 생태계는 멀티플랫폼 간에 동작하는 표준화되고 상호 호환되는 기술입니다.

요점(Takeaways)


  • WebRTC는 브라우저에서의 실시간 통신을 제공하며 이제 모바일과 데스크탑 상에서 폭넓게 지원됩니다. 전체적으로 이미 12억개 이상의 WebRTC 종단점들이 존재합니다.
  • Web Audio는 오디오 통합 및 처리를 위한 이상적인 도구를 제공합니다.
  • Web Audio와 통합된 Web MIDI는 MIDI 장치들과 상호작용을 할 수 있습니다.
  • 오디오와 비디오 엘리먼트들은 이제 85% 이상의 모바일 및 데스크탑 브라우저에서 지원됩니다.
  • 미디어 소스 확장(Media Source Extensions)은 적응형 스트리밍 및 타임 시프팅(Time Shifting)에서 사용할 수 있습니다.
  • EME는 보호된 컨텐츠의 재생을 가능하게 합니다.
  • 트랜스크립트(Transcript), 캡션 그리고 트랙(track) 엘리먼트는 자막, 캡션, 시간 메타데이터(Timed metadata), 딥 링크(Deep link, 페이지가 아닌 파일로의 링크) 및 딥 서치(Deep search)를 가능하게 합니다.


슬라이드: Media APIs for the multi-device Web


2014년 1월 11일 토요일

[업데이트/Summit] 크롬 개발자 서밋: 플랫폼 부문 요약(Chrome Dev Summit: Platform Summary)

Chrome Dev Summit의 플랫폼 부분에 대한 +Seth Ladd의 요약이 업데이트 되었습니다. 요즘 확장을 선언한 Dart로 시작하여 Chrome Apps, PNaCl에 대한 요약입니다. 공통적으로 표준적인 웹 기술은 아닙니다만 반대로 말하면 현재 웹의 보완재에 해당하는 기술이 어떤 것들이 있는지 살펴볼 수도 있겠군요. :)


"HTML5는 순수한 표준 규격으로써의 기술을 일컫기도 하지만 HTML5과 관련된 기술을 통칭하는 개념으로 사용되기도 합니다. 표준된 규격도 중요하지만 상호보완재의 역할은 규격을 기반으로 한 기술의 범위를 넓혀주기도 합니다."




다트(Dart)


다트는 자바스크립트로 컴파일되며 때로는 직접 작성한 자바스크립트보다도 더 빠른 코드를 생성하기도 합니다. 다트의 공동 설립자 캐스퍼 런드(Kasper Lund)가 dart2js 컴파일러가 빠르고 문법적으로 옳은 자바스크립트를 생성하기 위해 지역 및 전역 최적화를 어떻게 수행하는지에 대해 설명합니다. 트리 흔들기(Tree shaking), 형식 추론(Type inference) 그리고 최소화(minification)을 이용하여 다트는 여러분의 웹 앱을 최적화할 수 있도록 도울 것입니다.




크롬 앱스(Chrome Apps)


크롬 앱스는 개발 단순성, 웹의 보안성 및 구글 드라이브 같은 심리스(Seamless)한 구글 서비스들 통해 강력함과 네이티브 앱의 사용자 경험을 제공합니다. 크롬 앱스는 맥, 윈도우즈, 리눅스 그리고 크롬OS뿐만이 아니라 iOS 그리고 안드로이드까지 즉시 사용할 수 있도록 합니다.




포터블 네이티브 클라이언트(PNaCl)


Portable Native Client는 이식성, 네이티브 어플리케이션의 보안서 있는 실행 모델을 크롬에서 가능하게 하는 기술입니다. Native Client 프로젝트에 대한 이러한 확장은 네이티브 코드의 성능과 저수준 제어를 웹의 보안성과 이식성에 대한 희생없이 모던 웹브라우저에서 가능하도록 합니다.

PNaCl은 개발자가 그들의 네이티브 어플리케이션을 플랫폼 독립적인 형태로 생산할 수 있으며 이를 어떠한 설치과정도 없이 웹 브라우저에서 실행할 수 있도록 합니다. 크롬은 네이티브에 근접하는 성능을 달성하기 위해 PNaCl 어플리케이션을 실행 시간에 기계어로 번역합니다. 다른 브라우저에서 PNaCl 어플리케이션은 Emscripten과 pepper.js를 사용하여 최소의 성능으로 기능을 유지할 수 있습니다.


2014년 1월 9일 목요일

[업데이트/Summit] 크롬 개발자 서밋: 성능 부문 요약(Chrome Dev Summit: Performance Summary)

오늘은 +Paul Lewis가 Chrome  Dev Summit의 성능과 관련된 세션들의 요약을 업데이트했네요. 개인적으로도 관심이 많은 영역입니다만 도구화, 렌더링, 네트워크, 모바일에 대한 최적화가 한곳에 있으니 다들 읽어보시면 좋을 듯 합니다. 이전과 마찬가지로 자세한 내용은 전문을 참고하시기 바랍니다.


"성능은 언제나 이슈지요. 그래서 성능 역시 기능입니다."


#perfmatters: 퍼포먼스 닌자를 위한 도구화 기술들


개발도구에 대해 방향을 앎에 있어 요점은 성능의 그랜드 마스터가 되는 것입니다.
+Colt McAnlis는 성능과 관련하여 네트워크, 연산, 렌더링에 대한 3개의 기둥을 다루었습니다.

슬라이드


  • 이제 여러분은 데스크탑에서 알고 사랑해온 크롬 개발자도구를 사용하여 안드로이드 크롬(Chrome on Android)를 프로파일링할 수 있게 되었습니다.
  • 성능 개선은 데이터를 수집하여 검토한 것을 기록하고 액션을 취하는 작업의 반복적인 루프입니다.
  • 페이지에 대해 중대한 렌더링 경로 상의 애셋(Asset)의 우선순위를 결정하세요.
  • 페인팅을 피하세요. 이는 엄청나게 비싼 비용을 소모합니다.
  • 앱 내에서 메모리 변동(Churn)과 임계시간의 코드 실행을 피하세요.

#perfmatters: 네트워크 성능 최적화


네트워크와 지연시간은 일반적으로 사이트의 전체 페이지 로딩 시간의 70%를 차지합니다. 이는 정말 큰 비율입니다만 또한 사용자를 위한 아주 큰 장점으로 뛰어넘는 개선을 만들 수 있다는 것을 의미하기도 합니다. 이 발표에서 +Ilya Grigorik은 절대적인 최소 시간으로 네트워크 부하를 유지하도록 도와주는 환경을 만들도록 해주는 작은 변화뿐만이 아니라 로딩 타임을 개선할 수 있는 크롬에서의 최근 변경들에 대해 다뤘습니다. 


    • Chrome M27은 새롭게 개선된 리소스 스케쥴러를 가지고 있습니다.
    • Chrome M28은 SPDY 사이트들을(조차도) 더 빠르게 만들었습니다.
    • Chrome의 단순한 캐쉬(Simple cache)는 재정비를 받았습니다.
    • SPDY / HTTP/2.0는 전송 속도의 엄청난 개선을 제공합니다. (일단 3가지만 나열하자면) nginx, 아파치 그리고 Jetty에서 사용 가능한 우아한 SPDY 모듈이 있습니다.
    • QUIC은 UDP의 최상위에 구축된 새롭고 실험적인 프로토콜입니다. 아직 초기지만 사용자가 (성능과의 전쟁에서) 승리할 수 있도록 해줍니다.


    #perfmatters: 60fps 레이아웃 및 렌더링


    여러분의 프로젝트에서 60fps에 닿는다는 것은 사용자와의 약속과  프로젝트의 성공에 중대하게 즉각적으로 연관되어 있습니다. 이번 발표에서 +Nat Duca와 +Tom Wiltzius는 크롬의 렌더링 파이프라인에 대해 설명하고 프레임을 떨어뜨리는 몇가지 일반적인 경우와 그를 회피하기 위한 방법을 다룹니다.

    슬라이드


    • 프레임은 16ms입니다. 이는 자바스크립트, 스타일 계산, 페인팅, 합성(Compositing)을 포함하는 과정입니다.
    • 페인팅은 매우 비싼 비용을 소모합니다. 페인팅의 폭풍은 불필요하게 비싼 페인트 동작을 반복합니다.
    • 레이어는 페인팅된 엘리먼트들을 캐싱하는데 사용됩니다.
    • 입력 핸들러들(터치, 마우스휠 리스너들)은 반응성을 죽일 수도 있습니다. 가능하다면 이를 피하세요. 그럴 수 없는 곳에서는 이를 최소화해야 합니다.


    #perfmatters: 즉각적인 모바일 웹앱


    중대한 렌더링 경로(Critical Rendering Path, 이하 CRP)는 페이지 페인팅을 시작할 수 있기 전까지 브라우저가 필요로 하는 어떠한 것(JavaScript, HTML, CSS, 이미지 등)과도 연관될 수 있습니다. CRP에서 애셋의 전달 우선순위를 결정하는 것은 셀룰러 네트워크 상의 스마트폰같이 네트워크가 제한적인 디바이스의 사용자들을 위한 필수적이고 까다로운  것입니다. +Bryan McQuade가 구글의 팀이 어떻게 PageSpeed Insights 웹사이트를 위해 애셋들을 선정과 우선순위의 결정 과정을 진행하는지에 대해 설명하고, 20초의 로딩 시간을 단 1초로 바꿀 수 있었는지에 대해 이야기합니다!

    슬라이드


    • 렌더링을 블록하는 자바스크립트와 CSS를 제거하세요
    • 보여야하는 컨텐츠의 우선순위를 결정하세요.
    • 스크립트는 비동기적으로 로딩하세요.
    • 초기 뷰를 서버 사이드 HTML으로 렌더링하고 이후에 JavaScript로 강화하세요.
    • 렌더링을 블록하는 CSS를 최소화하세요. 초기 뷰포트를 디스플레이하는데 필요한 스타일만 전달하고 그 뒤에 나머지를 전달하세요.
    • 렌더링을 블록하는 CSS 내에서 인라인된 커다란 Data URI들은 렌더링 성능에 치명적입니다. 이미지 URL들이 논-블로킹인 곳에서도 리소스를 블록합니다.

    2014년 1월 8일 수요일

    [업데이트/Summit] 크롬 개발자 서밋: Polymer, 선언적/캡슐화/재사용가능한 컴포넌트(Chrome Dev Summit: Polymer declarative, encapsulated, reusable components)

    작년 Chrome Dev Summit에 대한 +Paul Kinlan모바일 부문 서밋 요약 포스팅에 이어서 바로 +Eric Bidelman이 Web Component에 대한 Polyfill 라이브러리인 폴리머(Polymer)에 대한 발표 요약을 포스팅했습니다. 자세한 내용은 아래를 참조하시기 바랍니다.



    전문


    Polymer는 웹 컴포넌트의 놀라운 미래로 가는 하나의 관문입니다. 우리는 사용자 엘리먼트(Custom element)를 쉽게 만들고 구축할 수 있기를 바래왔습니다. 작년동안 팀은 혁신적인 규격에 대한 Polyfill 세트를 위해 열심히 일했습니다. 우리는 그 최상위에 웹 컴포넌트를 더 쉽게 구축하기 위한 편리하고 간편한 라이브러리(sugaring library)를 만들었으며 마지막으로 여러분의 앱에서 재사용할 수 있는 UI와 유틸리티 엘리먼트들의 세트를 공들여 만들고 있습니다. 2013 Chrome Dev Summit에서 저는 Polymer의 각 부분들과 "모든 것이 엘리먼트"라는 마법주문 뒤에 감춰진 철학에 대해 깊이 파고 들어가 보았습니다.



    "모든 것이 엘리먼트입니다(Everything is an element)"

    - <select>에서 사용자 엘리먼트까지



    90년대의 웹 페이지 구축은 제한적이었지만 강력했습니다. 단지 곧 없어질 몇가지 엘리먼트를 가지고 있었을 뿐입니다. 강력한 부분이요? ...모든 것이 선언적이었습니다. 이는 자바스크립트의 덩어리 없이도 페이지를 생성하고 폼 컨트롤을 추가하고 "앱"을 생성하는데 놀라울 정도로 간편했습니다.

    겸손하기 그지없는 <select> 엘리먼트를 보세요. 여기에는 엘리먼트 내에 구축된 엄청나게 많은 기능이 있으며 다음과 같이 그를 정의하는 것으로 간편하게 사용할 수 있습니다.
    • HTML 속성들을 통한 사용자화(Customizable)
    • 속성을 통해 설정 가능한 기본 UI를 사용한 자식들(예. <option>)의 렌더링
    • <form> 같은 다른 컨텍스트 내에서의 활용성
    • DOM API: 속성들과 메소드들
    • 흥미있는 것이 발생했을 때의 이벤트 전달

    웹 컴포넌트는 이러한 웹 개발의 전성기로 되돌아가기 위한 도구를 제공합니다. <select>를 연상시키지만 2014의 사례를 위해 디자인된  새로운 엘리먼트를 생성할 수 있는 것입니다. 예를 들어 AJAX가 오늘날 발명되었다면 아마도 다음과 같은 HTML 태그가 될 것입니다. (예제)
    <polymer-ajax url="http://gdata.youtube.com/feeds/api/videos/" 
                   params='{"alt":"json"}'></polymer-ajax>

    혹은 다음과 같이 queryMatches 속성으로의 데이터 바인딩을 제공하는 반응형 엘리먼트들이 될 수도 있습니다.
    <polymer-media-query query="max-width:640px" queryMatches="{{isPhone}}"></…
    이는 Polymer에서 우리가 취하고 있는 정확한 접근 방법입니다. 단일한 덩어리로 된 자바스크립트 기반의 웹앱을 구축하는 대신 재사용가능한 엘리먼트를 생성해봅시다. 시간이 흐르고나면 전체 앱을 작은 엘리먼트들로 구성하도록 성장할 것입니다. 그리고 전체 앱은 다음과 같이 하나의 엘리먼트가 될 수도 있습니다.
    <my-app></my-app>


    Polymer의 특제양념을 이용한 웹 컴포넌트 구축



    폴리머는 웹 컴포넌트 기반의 어플리케이션을 구축하기 위한 엄청나게 많은 편리성들을 다음과 같이 가지고 있습니다.
    • 선언적인 엘리먼트 등록: <polymer-element> 
    • 선언적인 상속: <polymer-element extends="..."> 
    • 선언적인 양방향 데이터 바인딩: <input id="input" value="{{foo}}"> 
    • 선언적인 이벤트 핸들러: <button on-click="{{handleClick}}"> 
    • 배포 속성: xFoo.bar = 5 <-> <x-foo bar="5"> 
    • 속성 관찰: barChanged: function() {...} 
    • 기본적으로 내장된 PointerEvents / PointerGestures
    이 이야기의 교훈은 Polymer 엘리먼트의 작성은 전부 선언적이라는 것입니다.
    코드는 적게 작성하면서 더 나아진다는 것이죠. ;)


    웹 컴포넌트: 웹 개발의 미래



    슬라이드: http://html5-demos.appspot.com/static/cds2013/index.html#26

    만약 웹 컴포넌트 뒤의 표준을 내밀지 않았다면 제가 태만한 탓입니다. 결국 Polymer는 이러한 혁신적인 기초 API들에 기반하고 있습니다.

    지금은 웹 개발의 매우 흥미진진 시기인 듯 합니다. 웹 플랫폼에 추가되는 다른 새로운 기능과는 달리, Web Components를 구성하는 API들은 눈부시거나 사용자를 대상으로 하고 있지 않습니다. 이들은 순수하게 개발자 생산성을 위한 것입니다. 4가지 API 각각이 그 자체로 유용하지만 함께 사용하면 마법과도 같은 일이 벌어집니다!

    • Shadow DOM
      • 스타일과 DOM의 캡슐화
    • Custom Elements
      • 새로운 엘리먼트의 정의
      • 엘리먼트에 속성과 메소드를 이용해 API를 정의할 수 있습니다.
    • HTML Imports
      • CSS, JS 그리고 HTML의 패키지를 위한 배포 모델
    • Templates
      • 이후의 템플릿 처리를 위해 비활성화된 마크업 덩어리를 정의하기 위한 제대로된 DOM 템플릿 기능

    API에 대해 더 자세하게 알고 싶으시다면,  ebidel.github.com/webcomponents를 확인해보시기 바랍니다.

    2014년 1월 7일 화요일

    [업데이트/Summit] 크롬 개발자 서밋: 모바일 부문 요약(Chrome Dev Summit: Mobile Summary)

    2013년 열렸던 Chrome Dev Summit의 세션 소개 요약을 포스팅한 적이 있었는데 이 중 모바일 부문에 대한 요약을 +Paul Kinlan이 업데이트했네요. 자세한 내용은 아래를 참조하시기 바랍니다.





    몇 주 전 개최되었던 Chrome Dev Summit이 여기 이벤트에 대한 리포트들이 처음으로 발간되었습니다. 모바일과 크로스 디바이스 개발에 대한 매우 인상적인 글들이 있어 이로부터 시작하고자 합니다.


    모바일 웹 앱을 위한 최고의 UX 패턴들 by +Paul Kinlan 


    최상위 1000개 사이트에 대해 모바일 친화 여부에 대한 분석 후에 우리는 다음과 같은 몇가지 문제 영역을 발견했습니다. 53%는 여전히 데스크탑만으로 체험을 제공하고 있으며 82%의 사이트는 모바일 디바이스와의 상호작용에 대한 이슈들을 가지고 있고 64%의 사이트들은 사용자들이 읽는데 문제가되는 텍스트를 가지고 있습니다.

    모바일 웹 사용자 경험을 극적으로 개선 방법을 다음과 같이 빠르게 훑어봅니다.

    • 항상 뷰포트(Viewport)를 정의할 것
    • 뷰포트 내에 컨텐츠를 맞출 것
    • 읽기 좋은 수준으로 폰트 사이즈를 유지할 것
    • 웹 폰트의 사용을 제한할 것
    • 탭(Tab) 대상들에 대해 크기와 공백을 적절하게 만들 것
    • 입력(Input) 엘리먼트들에 대해 시멘틱 타입을 사용할 것

    PageSpeed Insights는 여러분의 사이트가 얼마나 모바일 친화적인지를 검토하는 UX 분석 기능을 얼마전 런칭했습니다. 이는 사이트의 모바일 UX를 통해 일반적인 문제를 발견하는데 도움을 줄 것입니다. 사용해보시기 바랍니다!


    슬라이드: 모바일 웹 앱을 위한 최고의 UX 패턴들




    멀티디바이스 접근성 by +Alice Boxhall


    사용자들은 접근성에 대한 넓은 범위의 각기 다른 요구사항을 가지는 아주 많은 디바이스를 통해 여러분의 사이트와 서비스에 접근할 것입니다. 올바른 시멘틱 엘리먼트들과 올바른 ARIA 역할들의 사용에 의해 브라우저과 보조적인 기술들이 여러분의 페이지를 이해하는데 많은 개선을 할 수 있도록 도와줄 수 있습니다.


    슬라이드: 멀티디바이스 접근성(Multi-device Accessibility)



    접근성 이슈들을 참조하고 이해하기 위한 주요 방법

    • 키보드만의 사용자 경험을 가지도록 할 것
    • 올바른 엘리먼트의 선택과 ARIA를 통해 인터페이스의 시멘틱을 표출할 것
    • 테스트를 위해 데스크탑은 ChromeVox를 안드로이드에서 TalkBack를 사용할 것
    • 접근성 개발자도구(Accessibility Developer Tools Chrome extension)을 사용할 것
    • 용이한 사이트 접근성을 확대하도록 더 다양한 사용자를 온라인으로 유지할 것


    크롬 웹뷰를 사용한 모바일 앱 구축 by +Matt Gaunt 


    우리 모두는 개발자들이 웹뷰를 사용한 구축 시 제한된 HTML5 기능, 디버깅 도구의 부재, 빌드 도구의 부재와 같은 문제들을 예전에 가지고 있었음을 알고 있습니다. 안드로이드 4.4(KitKat)의 Chromium powered WebView의 소개를 통해 이제 개발자들이 웹뷰를 사용하여 훌륭한 네이티브 앱을 개발하기 위한 거대한 범주의 새로운 도구들을 가지게 되었음을 알리고자 합니다.

    웹뷰는 크롬에서 사용하는 것과 동일한 도구로 완전한 리모트 디버깅을 지원합니다. 또한 Grunt를 사용한 믿을 수 있는 웹 개발 워크플로우를 가지게 되었으며 이를 Gradle을 통해 여러분의 네이티브 도구 스택에 통합할 수 있습니다. 통합된 세계들에 더 깊게 들어가, 여러분의 네이티브 코드를 자바스크립트로 테스트하기 위해 크롬 개발자도구를 사용할 수 있는 현명한 기법들을 살펴봅니다.


    효율적인 웹뷰 개발 방법들

    • 새로운 기능들이 아니라 워크플로우 속도 향상에 대해 지금 사용가능한 도구들이 중요
    • 네이티브 UI의 에뮬레이션 대신 웹 컨텐츠로 보이게 하는 것들을 확실하게 제거할 것
    • 필요할 때만 기능의 네이티브 구현을 사용할 것.
      • 예> 큰 파일에 대한 XHR 대신 다운로드매니저 사용


    크로스디바이스를 위한 워크플로우 최적화 by +Matt Gaunt 


    우리가 데스크탑, 모바일, 태블릿, 웨어러블 그리고 다른 형태의 디바이스에 대한 개발을 해야한다면 어떻게 덜 스트레스를 받도록 워크플로우를 최적화할 수 있을까요? 여기 LiveReload, Grunt, Yeoman 그리고 새롭게 베일을 벗은 Mini Mobile Device Lab을 통해 빠르게 반복적인 작업을 처리할 수 있는 튼튼한 멀티디바이스 접근방법이 있습니다. 만약 테스트하고자 하는 실제 디바이스가 없다면 클라우드를통해 이를 가능하게 하는 몇몇 서비스 제공자들이 있습니다.

    • 우리가 공급해야할 많은 디바이스들은 증가하기만 할 것임
    • Grunt와 Yeoman을 적절하게 이용한 워크플로우 가지기
    • Mini Mobile Device Lab를 이용한 크로스 브라우저 및 크로스 디바이스 테스트의 간소화
    • SaucelabsBrowserstack 그리고 Device Anywhere와 같은 클라우드 기반 에뮬레이터와 서드파티 에뮬레이터 Genymotion
    • 모바일 테스팅은 WiFi를 통한 테스트보다 더 많은 것들을 의미하므로 더 느린 네트워크 성능을 시뮬레이션하기 위한 프록시를 사용할 것


    네트워크 연결성: 선택적 접근 by +Jake Archibald 


    이 토크로부터 우리는 Jake는 프리젠테이션할 때 신발을 신지 않고 Business Kinlan은 곧 발매될 새로운 책을 가지고 있으며 오프라인이 되는 것은 브라우저 벤더들에게 심각하게 받아들여지고 있고 여러분은 곧 오프라인 시에도 잘 동작하는 훌륭한 체험을 구축할 수 있도록 도와줄 도구들을 손에 쥐게 될 것이라는 많은 사실들을 배울 수 있습니다. :)

    ServiceWorker는 우리에게 눈을 뗄 수 없는 첫번째 체험의 구축을 위해 필요한 유연성을 쉽고 AppCache로부터 기인한 고통을 느낄 필요가 없이 제공해줍니다. Polyfill을 사용한 API를  실험해 볼 수도 있습니다.


    슬라이드: 네트워크 연결성: 선택적 접근



    ServiceWorker로 바뀌는 것들

    • 차세대 점진적 향상(Progressive enhancement)으로써 네트워크를 잠재적 향상 버전처럼 다룰 수 있니다.
    • ServiceWorker는 완전하고 스크립트와 디버깅이 가능한 네트워크 요청을 제어할 수 있도록 합니다.
    • 만약 오프라인 기능을 가지고 있다면 컨텐츠 표시 전에 실패한 네트워크를 기다리지 않고 보여줄 수 있습니다.

    2014년 1월 6일 월요일

    [튜토리얼/한글화 소식] JavaScript Promise 외 튜토리얼 4종 라이브 소식

    안녕하세요. 연말 연휴로 밀렸던 HTML5Rocks 한글화 업데이트가 오늘 전부 라이브되었습니다. 평상 시에는 개별적인 튜토리얼 단위로만 포스팅을 했지만 조금 밀려있는 관계로 금번 업데이트 소식을 모은 포스팅을 추가하여 전달해드립니다. 각 제목을 클릭하시면 개별 튜토리얼에 대한 포스트로 이동합니다. :)


    1. 자바스크립트 Promise: 또 다른 시작


    자바스크립트의 비동기 동작으로 인해 콜백이 콜백을 부르고 다시 콜백이 콜백을 부른 과정이 중첩되다보면 내가 콜백인지 콜백이 나인지 헷갈릴 정도의 Callback Hell에 빠지게 됩니다. Promise는 이러한 비동기 동작을 손쉽게 처리할 수 있도록 고안된 비동기 프로그래밍 모델입니다.

    이번 튜토리얼은 거의 작정하고 만든 듯이 완벽 해설서에 가깝습니다. Polyfill을 이용해서 당장 적용해보실 수도 있으니 비동기 콜백에 지치거나 그 지옥 한가운데에 있으시다면 잠시 코딩을 멈추시고 일단 읽어보시길 바랍니다.

    "콜백 지옥(Callback Hell)은 멀리 있지 않습니다. 몇가지의 이벤트를 순차적으로 사용하기 위한 시나리오만 있으면 됩니다. 그러나 겹겹이 이어지는 콜백 함수가 포함된 코드는 주말이 지나고 새로운 모습으로 여러분에게 다가올 것입니다."



    2. 객체 풀 기반의 정적 메모리 자바스크립트


    아시다시피 자바스크립트에서는 자바와 마찬가지로 개발자가 직접 메모리를 관리할 필요가 없습니다. 이 둘은 전혀 다른 언어 스펙을 가지고 있지만 메모리 관리에 대해서는 가비지 콜렉션(Garbage Collection, 이하 GC)을 사용하기 때문입니다. 이번 튜토리얼은 이러한 GC의 동작을 회피하기 위해 정적으로 메모리 공간을 할당하고 이를 지속적으로 재사용하는 모델을 자바스크립트를 기반으로 설명합니다.

    번역은 김훈민님께서 수고해주셨습니다.  :)

    "GC는 개발자가 메모리를 직접 관리하는 대신 경험적으로 효율적이라 판단되는 형태로 메모리를 자동으로 수거하고 관리합니다. 그러나 메모리의 할당/해제는 아주 오래된 성능 병목지점의 하나이기 때문에 직접적으로 관리하지 못하는 모델에서는 순간적인 지연으로 인한 멈칫거리는 현상이 발생하고는 합니다. 정적 메모리 모델이 모든 것에 대한 해답은 되지 못하지만 GC에서 매뉴얼적인 메모리 관리 모델이 제공되지 않는 경우 유일한 해결 방법이기도 합니다."



    3. CSS 페인트 타임과 페이지 렌더 가중치


    이전에 포스팅한 렌더링 관련 튜토리얼들은 웹킷 혹은 크롬의 렌더링 모델이 취하는 구조나 그로 인한 렌더링 성능의 형태 및 최적화에 대해 논의한 글이었습니다. 그리고 이 튜토리얼은 조금 다른 관점에서의 렌더링 성능과 관련하여 가중치와 그 측정 방법에 대해 논의하고 있습니다. 특히, CSS의 속성들의 조합이 그 각각의 페인트 시간의 합보다 더 많은-심지어 훨씬 더 많은- 시간을 소모할 수 있다는 것은 특별히 더 염두에 두어야 할 내용 중의 하나입니다. :)

    "GPU 기반으로 가속되는 그래픽스의 성능 향상은 웹에서도 많은 효과를 가능하도록 만들었습니다. 그러나 그래픽스 시스템이 가지는 특성으로 인해 이러한 효과들이 조합되는 경우 중 어떠한 것들은 우리가 기대하는 바와는 달리 더 많은 렌더링 시간을 차지하여 예상치 못한 성능 상의 영향을 주기도 합니다."



    4. 안티앨리어싱 101


     다른 그래픽스와 마찬가지로 안티앨리어싱은 다양한 방식으로 처리될 수 있습니다. 또한 폰트의 안티앨리어싱 처리는 기본사항이라고 생각해도 무방합니다. 이 튜토리얼에서는 현재 크롬에서 사용하고 있는 '그레이스케일 안티앨리어싱(Grayscale Antialiasing)과 서브픽셀 안티앨리어싱(Antialiasing)'에 대해 차이점을 설명하고 어떠한 기준으로 각 방식이 사용되는지에 대해 설명합니다.

    "안티앨리어싱은 그래픽스에서 2가지 이상의 색상들이 충돌하는 픽셀과 그 주변들에 대해 어떠한 색상으로 채울 것인지를 결정하는 처리 과정을 말합니다. 특히 폰트의 렌더링에서 윤곽선의 처리는 미려한 출력을 위해 아주 오랜동안 사용된 기법이기도 합니다."


    5. Shadow DOM 301: 고급 개념과 DOM API


    웹 컴포넌트 관련 튜토리얼마다 말씀드리는 내용입니다만 DOM에 대한 캡슐화(Encapsulation)와 같은 매우 강력한 기능을 제공하는 Shadow DOM 역시 이전의 Custom Element나 HTML Imports처럼 웹 컴포넌트를 지탱하는 4가지 규격 중의 하나입니다. 이 튜토리얼은 여러개의 Shadow root 사용하는 방법과 호스트의 Shadow tree를 얻고, 자바스크립트을 통한 Shadow DOM의 구축 및 삽입지점을 통한 동작에 대해 논의합니다. 그리고 Shadow DOM을 쉽게 이해할 수 있도록 만들어진 도구인 Shadow DOM Visualizer와 이벤트 모델의 동작 방식을 소개합니다.

    "Shadow DOM이 컴포넌트를 구성하는 DOM을 감추는 역할(encapsulation)을 하고 HTML Template가 DOM의 복제 및 재 사용성을 제공하며 Custom Element는 웹 문서에서 사용할 엘리먼트를 모듈에서 직접 등록할 수 있도록 하는 기능을 제공하여 컴포넌트의 명시적인 alias를 선언하는 역할을 한다면 HTML Imports는 웹 문서 내에 외부 리소스를 포함(Import)하기 위한 기능을 제공합니다."

    [튜토리얼/한글화] Shadow DOM 301: 고급 개념과 DOM API (Shadow DOM 301: Advanced Concepts & DOM APIs)

    HTML5Rocks의 Shadow DOM 관련 튜토리얼 중 마지막 글인 +Eric Bidelman의 '섀도 DOM 301: 고급 개념과 DOM API (Shadow DOM 301: Advanced Concepts & DOM APIs)' 튜토리얼의 한국어 번역이 업데이트되었습니다.

    웹 컴포넌트 관련 튜토리얼마다 말씀드리는 내용입니다만 Shadow DOM 역시 이전의 Custom ElementHTML Imports처럼 웹 컴포넌트를 지탱하는 4가지 규격 중의 하나입니다. Shadow DOM은 DOM에 대한 캡슐화(Encapsulation)와 같은 매우 강력한 기능을 제공합니다. 이 튜토리얼은 여러개의 Shadow root 사용하는 방법과 호스트의 Shadow tree를 얻고, 자바스크립트을 통한 Shadow DOM의 구축 및 삽입지점을 통한 동작에 대해 논의합니다. 그리고 Shadow DOM을 쉽게 이해할 수 있도록 만들어진 도구인 Shadow DOM Visualizer와 이벤트 모델의 동작 방식을 소개합니다.

    "Shadow DOM이 컴포넌트를 구성하는 DOM을 감추는 역할(encapsulation)을 하고 HTML Template가 DOM의 복제 및 재 사용성을 제공하며 Custom Element는 웹 문서에서 사용할 엘리먼트를 모듈에서 직접 등록할 수 있도록 하는 기능을 제공하여 컴포넌트의 명시적인 alias를 선언하는 역할을 한다면 HTML Imports는 웹 문서 내에 외부 리소스를 포함(Import)하기 위한 기능을 제공합니다."


    TL;DR;


    Shadow DOM은 DOM에 대한 캡슐화(Encapsulation)와 같은 매우 강력한 기능을 제공합니다. 이 튜토리얼은 Shadow DOM 101과 Shadow DOM 201에서 다뤘던 개념들을 기초로 하여 고급 개념과 활용 방법에 대해 논의합니다.

    Shadow DOM을 호스팅하는 엘리먼트도 한번에 하나 이상의 Shadow Root를 호스팅할 수 있습니다. 호스트에 추가된 섀도 트리들은 그들이 추가된 순서대로 스택에 쌓이며 가장 최근에 추가된 것부터 시작합니다. 따라서 만약 여러개의 <shadow> 삽입지점들이 섀도 트리 내에 존재한다면 첫번째만이 인식되며 나머지는 무시되고 렌더링됩니다.

    또한 만약 자바스크립트에서 DOM을 구축하는 것을 선호한다면, HTMLContentElement과 HTMLShadowElement는 그를 위한 인터페이스를 가지고 있으며 Shadow DOM 내의 <content>내로 탐색은 원칙적으로 불가능하나 .getDistributedNodes() API나 .getDestinationInsertionPoints()를 통해 액세스할 수 있습니다.

    삽입지점(Insertion Point)은 DOM이 실제로 이동하는 것이 아니라 삽입지점이 가르키고 있는 위치에 대해 마치 DOM이 존재하는 것처럼 렌더링하고 동작하는 것을 뜻합니다. 이러한 이유로 여러분의 DOM 트리는 여전히 원래 상태대로 유지되고 있지만 실제 렌더링 결과는 DOM이 그리로 이동하거나 복사된 것처럼 동작합니다.

    이벤트는 Shadow Root의 상위 경계가 제공하는 캡슐화(Encapsulation)을 유지하기 위해 Shadow DOM으로 이동한 내부 엘리먼트들로 대상을 재설정되며 abort, error, select, change,load, reset, resize, scroll, selectstart와 같은 이벤트들은 Shadow Boundary 간의 전달이 일어나지 않습니다.


    +Eric Bidelman의 Shadow DOM Visualizer 소개 영상



    보다 자세한 내용은 튜토리얼을 참고하시기 바랍니다.

    번역 링크


    참고 글

    2014년 1월 1일 수요일

    [튜토리얼/한글화] 안티앨리어싱 101 (Antialiasing 101)

    어느새 새해의 첫날이 시작되었네요. 먼저 새해 복 많이 받으세요. :-)

    HTML5Rocks에 +Paul Lewis의 '안티앨리어싱 101(Antialiasing 101)' 한글 튜토리얼이 업데이트되었습니다.

     다른 그래픽스와 마찬가지로 안티앨리어싱은 다양한 방식으로 처리될 수 있습니다. 또한 폰트에 대한 안티앨리어싱은 기본사항이나 마찬가지입니다. 이 튜토리얼에서는 현재 크롬에서 사용하고 있는 '그레이스케일 안티앨리어싱(Grayscale Antialiasing)과 서브픽셀 안티앨리어싱(Antialiasing)'에 대해 차이점을 설명하고 어떠한 기준으로 각 방식이 사용되는지에 대해 설명합니다.

    "안티앨리어싱은 그래픽스에서 2가지 이상의 색상들이 충돌하는 픽셀과 그 주변들에 대해 어떠한 색상으로 채울 것인지를 결정하는 처리 과정을 말합니다. 특히 폰트의 렌더링에서 윤곽선의 처리는 미려한 출력을 위해 아주 오랜동안 사용된 기법이기도 합니다."



    TL;DR;


    안티앨리어싱은 스크린 상에서 깔끔한 텍스트와 부드러운 벡터 형태를 가지게 된 근본적인 이유인데도 불구하고 웹 그래픽스에서 알려지지 못한 영웅과도 같습니다. 실제로 안티앨리어싱의 접근 방법들 중 다음 방법들은 최근의 브라우저에서 텍스트를 렌더링할 때 가장 분명하게 사용되고 있습니다.


    • 그레이스케일 안티앨리어싱(Grayscale Antialiasing)
      • 픽셀들의 처리에 있어 RGB 요소를 모두 균등한 비율의 값으로 처리합니다.
    • 서브픽셀 안티앨리어싱(Subpixel Anitialiasing) 
      • 픽셀 별로 RGB의 각 요소를 각각의 연산에 따라 다른 비율로 처리합니다.
      • 그레이스케일보다 깔끔하지만 처리 비용은 더 높습니다.

    보다 자세한 내용과 각 안티앨리어싱 알고리즘이 선택되는 기준에 대해서는 본문을 참조하시기 바랍니다.


    번역 링크