2014년 5월 10일 토요일

[소식] Chrome/Chromium 36 관련 업데이트 미리보기

오랜만에 포스팅을 하는군요. 최근 Google I/O 때문인지 HTML5Rocks의 신규 튜토리얼 등록도 미뤄지고 있고 해서 딱히 업데이트할 내용이 없다는 것이 핑계라면 핑계입니다만, 마침 크롬/크로미움 36 버전의 업데이트 관련한 소식 중에 신나는 것들이 있어서 공유하고자 합니다. :)

"아직 36버전의 공식 업데이트까지 기간이 남았기 때문에 최종 버전이라고 생각하시면 곤란합니다. ㅎㅎ 대신 중요한 추가 항목들이 생기면 이 포스트에 업데이트하도록 하겠습니다."



Chrome/Chromium 36 버전 중요 업데이트 미리보기


개인적으로 36 버전 업데이트에서 눈에 띄는 몇가지는 관심을 가지고 있는 신규 규격들의 적용입니다. 아래에 언급하고 있지 않은 기능 중에서 WebComponents와 같은 규격들에 대한 업데이트도 지속적으로 업데이트되고 있습니다. 올해는 재밌군요. :)


> CSS transform의 Prefix 제거


기존에 CSS transform을 적용하기 위해서는 -webkit-transform: ...처럼 prefix가 포함된 형태로 기술해야 했지만 36버전부터는 transform: ... 과 같이 prefix가 없는 상태로 기술이 가능해집니다. :)



> WebAnimations 자바스크립트 API 추가


Web Animations는 기존의 선언적인 방식에서 벗어나서 자바스크립트를 기반으로 능동적으로 CSS3 Animation 및 Transition, SVG 애니메이션을 처리할 수 있는 새로운 HTML5 규격입니다.

작년 말 Blink 엔진에서 WebAnimations 규격을 지원하기 위한 네이티브 엔진 교체가 이루어졌었습니다만 이때까지는 WebAnimation에서 정의하고 있는 자바스크립트 API가 빠진 상태로 기존 CSS3 애니메이션이 제대로 동작하는지만 확인할 수 있어 별로 차이를 느끼지 못하셨을 겁니다. (아마 엔진이 변경되었다는 사실조차 모르시는 분들이 많으실 것 같네요.)

이제 36버전부터 웹 애니메이션의 API 중 element.animate()가 사용 가능해집니다. 물론 Chrome for Android에서도 마찬가지입니다.



> CSS Will-change


will-change CSS 속성이 추가되었습니다. will-change 속성은 엘리먼트 내의 컨텐츠나 리스팅된 속성이 변경될 수 있음을 브라우저에 알려주는 일종의 힌트와도 같습니다.

단순히 속성 자체로 페이지 상의 변화가 일어나는 것은 아니지만 다양한 방식의 하드웨어 가속을 통해 렌더링이 이루어지는 환경에서는 브라우저의 렌더링이 보다 효율적으로 동작할 수 있도록 해줄 수 있습니다.

이 규격은 초안(Draft) 상태입니다만 크롬 36버전부터 구현되어 있는 상태입니다.



> ServiceWorker 초기 구현


ServiceWorker는 웹 페이지와는 독립적인 생명주기(life-cycle)를 가진 이벤트 기반 시스템으로 SharedWorker의 일종이지만 근본적으로는 어플리케이션과 별개의 스레드를 운용하며 필요하다면 개발자의 캐싱(Caching) 관리가 가능하게 하거나 네트워크를 통한 사용자 요청에 대하여 응답을 제어할 수 있게 되는 등 오프라인 지원을 위한 다양한 (특히 리소스의 제어에 유용한) 기능을 제공합니다.

현재 ServiceWorker 규격 정의가 W3C에서 현재 진행 중이며 데스크톱 크롬 36과 안드로이드용 크롬 36부터 ServiceWorker의 초기 구현이 포함됩니다. 구현 상태와 규격은 아래 사이트에서 참조하시기 바랍니다.

2014년 4월 25일 금요일

[튜토리얼/한글화] 크롬 개발자도구로 비동기 자바스크립트 디버깅하기(Debugging Asynchronous JavaScript with Chrome DevTools)

HTML5Rocks에 +Pearl Chen의 '크롬 개발자도구로 비동기 자바스크립트 디버깅하기(Debugging Asynchronous JavaScript with Chrome DevTools)' 한글 튜토리얼이 업데이트되었습니다. 이번 번역은 한순보님께서 수고해주셨습니다. :)

"콜백에 의한 비동기 처리는 우리에게 성능이라는 한가지 장점과 사소해보이는 몇가지 단점을 같이 선물하였습니다. UI가 동작 중인 메인스레드에서 실행되는 자바스크립트에서 콜백에 의한 비동기 처리는 발생할 수 있는 성능 상의 문제를 해결하기 위한 최선의 방법이었습니다만 성능의 이점 대신 코드 작성은 좀 더 어려워졌고 선형적으로 디버깅할 수 있는 방법은 크게 복잡해졌습니다.  
코드에서 무엇을 어떻게 처리할 것인지는 여러분의 몫입니다만 불행하게도 디버깅 역시 그러하며 특히나 비동기 처리라면 개발 환경을 넘어선 코드에 대한 깊은 이해를 요구하는 경우가 많으며 최근과 같이 외부에서 작성된 자바스크립트 라이브러리들을 사용하는 환경에는 더욱 더 그렇습니다. 
크롬에서 추가된 비동기 자바스크립트에 대한 호출 스택과 왓치(Watch) 기능은 이러한 영역에서의 괴로움을 크게 줄여줄 것입니다."



TL;DR;


콜백 함수를 통해 비동기로 동작할 수 있는 능력은 자바스크립트를 특별하게 만드는 강력한 기능이지만 자바스크립트는 순차적으로만 실행되지 않으므로 디버깅 과정에서는 우리를 괴롭게 만듭니다.

다행스럽게도 이제 크롬 카나리 개발자 도구(DevTools)에서 비동기 자바스크립트 콜백이 포함된 호출 스택의 모두를 확인할 수 있습니다. 개발자 도구에서 비동기 콜 스택 기능을 활성화하면 다양한 지점에서 각 지점에서의 상태를 자세히 볼 수 있으며 스택을 추적해 가면서 런타임 실행에서 특정 지점의 어떤 변수 값을 분석할 수도 있습니다.


[그림] 크롬 개발자도구의 비동기 호출 스택 추적

현재 개발자 도구에서 호출 스택을 확인할 수 있는 비동기 콜백의 종류는 다음과 같습니다.

  • 타이머: setTimeout()이나 setInterval()의 초기화 지점으로 이동합니다.
  • XHR: xhr.send() 호출 지점으로 이동합니다.
  • 애니메이션 프레임: requestAnimationFrame의 호출 지점으로 이동합니다.
  • 이벤트 리스너: 이벤트와 addEventListner()의 최초 바인딩 지점으로 이동합니다.
    • addEventListner()는 성능 문제로 인해 개발자도구의 추적대상에서 제거되었습니다.
  • MutationObserver: Mutation Observer 이벤트의 지점으로 이동합니다.


아래의 자바스크립트 API는 곧 이 기능을 지원할 예정입니다.

  • Promise: Promise가 해결된(resolved) 위치로 이동합니다.
  • Object.observe: 옵저버(Observer) 콜백을 처음에 바인딩한 지점으로 이동합니다.


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

번역 링크

2014년 4월 5일 토요일

[튜토리얼/한글화] Build with Chrome: LEGO® 벽돌을 멀티디바이스 웹으로 옮기기(Build with Chrome: Bringing LEGO® bricks to the Multi-Device Web)

HTML5Rocks에 +Hans Eklund의 'Build with Chrome: LEGO® 벽돌을 멀티디바이스 웹으로 가져오기(Build with Chrome: Bringing LEGO® bricks to the Multi-Device Web)' 한글 튜토리얼이 업데이트되었습니다.

Build with Chrome은 Chrome 브라우저에 실행되며 LEGO® 벽돌들을 이용하여 구조물을 만들어낼 수 있으며 이를 Google Maps와 연동하여 전세계의 지도 위에 위치시킬 수 있는 인터랙티브 3D 컨텐츠입니다. 이 튜토리얼은 Build with Chrome이 2014년 다시 런칭하며 적용하였던 모바일 및 터치 지원 과정에서 발생한 주요 이슈에 대한 사례연구를 담고 있습니다. (저자인 Hans Eklund가 일하고 있는 North Kingdom은 그동안 '호빗 체험'이나 'RO.ME'과 같은 프로젝트를 만들어온 회사입니다. 포트폴리오도 재밌는 것이 많으니 한번 살펴보시기 바랍니다.)

"Build with Chrome이 2014년에 터치 스크린 및 모바일 디바이스를 지원하도록 적용하는 과정에서 발생한 성능, 터치 그리고 멀티 스크린 대응과 같은 주요 문제들은 다른 인터랙티브 3D 컨텐츠에서도 반복되는 문제입니다. 만약 비슷한 컨텐츠 개발을 계획 중이라면 읽어보시기 바랍니다."



TL;DR;


데스크탑 크롬용으로 개발되었던 Build with Chrome은 다시 릴리즈되는 과정에서 모바일 디바이스들을 지원하는 기능이 새로 추가되었습니다. 이 과정에서의 가장 큰 이슈들은 사용자 경험과 디자인에 대한 해결이었으며 기술적인 도전은 많은 화면 크기, 터치 이벤트 그리고 성능 이슈들을 관리하는 것이었습니다. 터치 디바이스 상에서의 WebGL 쉐이더 사용에 대한 몇가지 도전과제들이 있었지만 이는 기대했던 것보다 꽤나 잘 동작했습니다. 디바이스들은 점점 더 강력해지고 있으며 WebGL 구현들은 빠르게 개선되고 있으므로 가까운 시일 내에 더 많은 디바이스에서 WebGL을 더 많이 사용할 수 있을 것이라고 예상할 수 있습니다.

> 반응형 프론트엔드


터치와 마우스 입력을 사용하는 디바이스 모두를 지원해야 했으나, 작은 터치 스크린 상에서 동일한 UI를 사용하는 것은 공간 제약을 제대로 해결할 수 없었고 사용자의 손가락이 상호작용을 하는 동안 작은 스크린의 많은 부분을 커버하였으므로 픽셀들보다 물리적인 스크린 사이즈에 대해 정말 고려하고 실제 컨텐츠에 전념할 수 있도록 가능한 많은 공간을 확보하는 것이 중요합니다.

Build with Chrome의 경우 터치 디바이스에서 자연스럽게 느끼도록 만들고 정말 터치 입력을 의도한 것처럼 느끼도록 하기 위해 미디어쿼리를 이용하여 2가지의 UI 변경 버전을 개발하였습니다.

  • 마우스와 터치를 지원하는 큰 화면
    • 큰 화면 버전은 마우스를 지원하는 모든 데스크탑 컴퓨터와 큰 화면을 가진 터치 디바이스에 제공되며 터치 지원과 몇가지 제스쳐가 추가된 오리지널 데스크탑 버전과 유사합니다.
  • 터치만 지원하는 작은 화면
    • 이 모바일 디바이스들과 작은 태블릿용 버전은 멀티-터치를 요구하며 화면 상의 공간을 최대화하기 위한 대부분의 작업은 잘 사용하지 않는 UI 요소들을 최소화하거나 멀티 터치 제스쳐로 변경하고 풀스크린 모드를 지원하는 것이었습니다.


> WebGL 성능과 지원


현재의 터치 디바이스들은 꽤 강력한 GPU들을 가지고 있지만 여전히 데스크탑의 상대가 되기는 어려우므로 성능, 특히 동시간에 많은 구조물을 렌더링할 필요가 있는 3D 탐색 모드에 대해 텍스쳐, 구조물 로딩이나 구조물들의 애니메이션 및 렌더링 등 많은 것들이 동시에 처리되어 GPU와 CPU 모두를 크게 요구했으므로 모바일 디바이스에서는 구조물에 꽤 가깝게 줌하도록 하여 동시에 많은 구조물을 렌더링할 필요가 없도록 하는 접근을 취했습니다. 다만, WebGL 기능이 없는 디바이스의 경우 WebGL의 사용없이 빌드와 3D 탐색 기능을 유사하게 동작할 수 있는 충분히 훌륭한 해결방법을 찾지는 못했습니다.


> 화면 방향 관리하기


모바일 디바이스에 적용을 시작할 때 세로 모드(Portrait mode)에서 가로 모드(Landscape mode)에 대해 고려할 필요가 있습니다. Build with Chrome의 경우 컨텐츠의 흐름을 유지하고 편안한 방식의 상호작용을 제공하면서 가로와 세로 방향으로 모두 동작하는 대신 가로 모드만을 지원하기로 하였습니다.

대부분의 컨텐츠 레이아웃은 CSS에 의해 제어되지만 방향과 관련된 것은 자바스크립트에서의 구현을 필요로 하였으며 이를 위해 window.orientation을 사용하는 것은 좋은 크로스-디바이스 솔루션이 아니라는 것을 확인하였으므로 window의 .innerWidth와 .innerHeight의 비교하였습니다.


> 터치 지원 추가하기


웹 컨텐츠에 대한 터치 기능의 추가 지원은 합리적이며 올바른 것입니다. 마우스와 터치를 동시에 지원하기 위한 포인터 이벤트는 W3C에 표준으로 제출되었습니다만 아직 인터넷 익스플로러에서만 구현되어 있습니다. 따라서 터치 이벤트들 또한 다루는 것이 필요할 것입니다. 이 글은 이 이벤트들을 어떻게 사용하는지에 대한 기초들을 다루고 있습니다.

  • 멀티터치 제스쳐
    • 핀치(Pinch)와 회전 제스쳐를 관리하기 위해 두번째 손가락이 화면에 얹어질 때마다 두손가락 사이의 거리와 각도를 저장했습니다.
  • 마우스와 터치의 동시 지원
    • 오늘 날에는 마우스와 터치 입력을 둘 다 지원하는 디바이스가 있으므로 터치 지원의 검출만으로 마우스 입력을 무시하는 대신 동시에 전부를 지원하지 않는다면 몇가지 예상치 못한 동작을 발생할 수 있습니다.
  • 마우스, 터치 그리고 키보드 입력 처리
    • 이벤트 핸들러 내에서의 입력을 변수에 저장하고 requestAnimationFrame의 렌더 루프에서 입력에 반응하도록 하여 렌더링 성능 등의 오버헤드를 최대한 회피하고 마우스 입력 등으로의 확장을 보다 용이하도록 합니다.
    • 또한 각 이벤트 핸들러에서 event.preventDefault()는 브라우저가 스크롤이나 전체 페이지의 스케일을 조정하는 것과 같은 예상치 못한 동작을 발생할 수 있는 터치 이벤트의 지속적인 처리를 막을 수 있습니다.




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

번역 링크

2014년 3월 27일 목요일

[튜토리얼/한글화] WebRTC 시작하기(Getting started with WebRTC)

HTML5Rocks에 +Sam Dutton의 'WebRTC 시작하기(Getting Started With WebRTC)' 튜토리얼의 한글 버전이 업데이트되었습니다. 이번 번역은 이원제(+nuri nam)님께서 수고해주셨습니다. :)

"말그대로 WebRTC는 웹을 위한 실시간 통신 규격입니다. 이는 오디오나 비디오 스트림을 P2P로 송수신하는 것뿐만이 아니라 데이터 전달을 위한 메커니즘을 포함하고 있습니다. 대다수의 서비스들은 클라언트-서버 간의 데이터 통신을 통해 기능을 제공하고 있지만 어떤 경우는 클라이언트 간의 빠른 데이터 교환이 주요 기능 구현 사항이 되기도 합니다. 바로 이러한 경우 WebRTC는 중요한 기반 기능을 제공합니다. 뒤집어 얘기하자면 서버를 중계할 이유가 없으며 클라이언트 간의 데이터를 빠르게 송수신하고자 한다면 WebRTC는 좋은 선택이 될 수 있습니다. WebRTC의 다양한 구현 사례를 보기 전에 이 튜토리얼을 통해 WebRTC가 어떠한 것이고 어떻게 사용하는지를 확인해보시기 바랍니다."


TL;DR;


현재 웹의 주요 도전 과제 중에 남은 하나는 실시간 대화(Real Time Communication, RTC) 가능하게 하는 것입니다. 많은 웹서비스들이 이미 실시간 통신을 사용하고 지만 네이티브 앱이나 플러그인들의 다운로드가 필요했습니다. 이제 HTML5에서 플러그인 없는 실시간 통신을 위한 규격인 WebRTC는 현재 크롬, 오페라, 파이어폭스에서 가능하며 WebKitGTK+ 와 Qt 네이티브 프레임워크에도 통합되어 있습니다.

WebRTC 어플리케이션이 취하는 일반적인 기능은 다음과 같습니다.

  • 스트리밍 오디오, 비디오 또는 데이터의 획득
  • 네트워크 정보의 획득 및 다른 WebRTC 클라이언트들과 정보 교환
  • 에러들의 보고, 세션 초기화/종료를 위한 Signal 통신 관리
  • 미디어와 클라이언트의 지원 기능(해상도와 코덱 등)에 대한 정보 교환
  • 스트리밍 오디오, 비디오, 데이터의 송수신



apprtc.appspot.com의 WebRTC 통신 및 일반 통신

스트리밍 데이터를 얻고 통신하기 위해 WebRTC에서는 다음과 같은 API를 제공합니다.

  • (getUserMedia라고도 하는) MediaStream - 카메라/마이크 등 데이터 스트림 접근
  • RTCPeerConnection - 암호화 및 대역폭 관리 및 오디오 또는 비디오 연결
  • RTCDataChannel - 일반적인 데이터 P2P통신


> MediaStream


MediaStream API는 미디어의 동기화된 스트림들을 말합니다. 예를 들어, 카메라와 마이크의 입력에서 받아온 스트림은 오디오와 비디오 트랙들로 동기화 됩니다. getUserMedia()는 반드시 로컬 파일 시스템이 아닌 서버에서 사용되어야 합니다.


> 시그널링(Signaling)


WebRTC 클라이언트로 사용되는 웹 브라우저들 사이에 스트리밍 데이터를 주고 받기 위해 RTCPeerConnection를 사용하며 통신을 조율하고 조장할 메세지를 주고 받기 위해 시그널링(Signaling)으로 알려진 일련의 과정이 필요합니다. 시그널링(Signaling)은 RTCPeerConnection API에 포함되지 않지만 WebRTC 개발자들은 SIP, XMPP 또는 적절한 쌍방통신 채널 등 자신들에게 편한 방식을 선택할 수 있습니다.


> RTCPeerConnection


RTCPeerConnection은 Peer들 간의 데이터를 안정적이고 효율적으로 통신하게 처리하는 WebRTC 컴포넌트입니다. JavaScript 측면에서 보면 RTCPeerConnection는 WebRTC에서 사용되는 엄청나게 많은 일들을 개발자가 신경쓰지 않을 수 있도록 많은 기능을 백그라운드에서 지원하고 있습니다. 실제로 WebRTC는 서버가 필요하지만 단순합니다.


> RTCDataChannel


오디오와 비디오처럼, WebRTC는 실시간으로 다른 형태의 데이터 통신도 지원합니다. RTCDataChannel API는 피어와 피어간 임의의 데이터 교환을 빠른 반응속도와 높은 처리량으로 가능하게 합니다. 이 API를 이용하여 게임이나 원격 데스크탑 어플리케이션, 실시간 채팅, 파일 전송, 분산 네트워크 등으로의 응용이 가능합니다.

RTCDataChannel API는 RTCPeerConnection의 대부분의 기능들을 활용하여 강력하고 유연한 P2P통신을 가능하게 하는 몇가지 기능을 가지고 있으며 통신은 브라우저간 직접 연결됩니다 , 그래서 RTCDataChannel은 WebSocket보다 매우 빠릅니다. 심지어 방화벽과 NAT의 방해로 '구멍내기'가 실패하여 중계(TURN) 서버와 연결이 되더라도 빠릅니다.


> 보안


실시간 통신 어플리케이션이나 플러그인에서 보안 문제가 발생하는 경우가 몇가지가 있습니다. WebRTC는 이 문제들을 피할 수 있는 몇가지 기능들을 가지고 있습니다:


  • WebRTC는 DTLS와 SRTP등의 보안 프로토콜을 사용하여 구현되었습니다. 따라서 암호화는 Signlaing 메커니즘을 포함한 모든 WebRTC Components의 필수 조건입니다.
  • WebRTC는 플러그인이 아니므로 컴포넌트들은 브라우저의 샌드박스위에서 실행되고 별도의 프로세스로 나눠지지 않습니다.
  • 카메라와 마이크에 접근은 반드시 허가를 통합니다.


WebRTC에 대한 자세한 내용은 튜토리얼을 참조하시기 바랍니다.

번역 링크


참조 링크

[튜토리얼/한글화] HTML5에서 오디오 및 비디오 캡쳐하기(Capturing Audio & Video in HTML5)

HTML5Rocks에 +Eric Bidelman의 'HTML5에서 오디오 및 비디오 캡쳐하기(Capturing Audio & Video in HTML5)' 한글 튜토리얼이 업데이트되었습니다.

그동안 웹에서 오디오와 비디오의 캡쳐는 재생과는 전혀 다른 범주의 기능처럼 인식되어 왔습니다. HTML5는 다른 많은 기능과 마찬가지로 오디오 및 비디오의 재생뿐만이 아니라 오디오나 비디오 입력 스트림의 처리를 가능하도록 그 기능을 확장하였습니다. 이 튜토리얼은 이 기능들을 다루기 위한 기초적인 설정 방법부터 몇가지 일반적인 구현 사례를 설명합니다.

이번 번역은 이원제(+nuri nam)님께서 수고해주셨습니다. :)

"오랜 기간동안 웹 환경은 개발자에게 플래시나 실버라이트와 같은 플러그인을 이용하여 오디오와 비디오 캡쳐를 구현하도록 강요해왔습니다. HTML5는 이러한 플러그인 종속성을 없애고 이들 장치에 대한 입력 스트림을 직접 제어할 수 있도록 기능을 제공하고 있습니다. 입력 스트림을 제어한다는 것은 여러분의 웹 앱을 생각보다 더 크게 확장할 수 있습니다. WebRTC의 일반적인 사례처럼 비디오 컨퍼런스 서비스를 구현할 수도 있지만 조금만 더 아이디어를 덧붙인다면 네이티브에서 구현해왔던 얼굴/모션의 검출 등으로 얼마든지 확장할 수 있습니다."



TL;DR;


지난 세월동안 오디오와 비디오 캡쳐는 외부 플러그인들을 사용할 수 밖에 없었습니다. HTML5는 다양한 하드웨어에 대한 접근을 표준 규격으로 정의하고 있으며 오디오와 비디오의 캡쳐 역시 예외는 아닙니다. 이와 관련해서 그동안 다양한 규격들이 W3C에서 시도되어 왔지만 현재 getUserMedia()를 통해 대다수의 작업을 할 수 있도록 정리되었습니다. 이제 여러분은 getUserMedia()를 통해 사용자의 카메라와 마이크를 웹앱에서 접근할 수 있습니다.

> 멀티미디어 디바이스의 접근


사용자의 멀티미디어 디바이스의 입력 스트림을 제어하기 위해서 다음과 같은 기능들이 필요할 것입니다.


  • 미디어에 대한 권한 요청
    • 웹캠과 마이크에 접근하기 위해서는 먼저 어떤 디바이스에 어떠한 방식으로 접근하는지에 대한 권한을 getUserMedia()를 이용하여 요청해야 합니다.
  • 미디어 기능 요구사항 설정
    • 필요하다면 getUserMedia()의 호출 시 접근하고자 하는 미디어 스트림에 대해 필요한 요구사항들(해상도, 비트레이트 등)을 설정할 수 있습니다.
  • 미디어 소스의 검색과 선택
    • 크롬의 경우 버전 30 이후부터는 getUserMedia()에서 입력 스트림으로 사용가능한 소스를 검색할 수 있도록 MediaStreamTrack.getSources() API를 지원합니다.
    • 이 API를 이용하면 현재 디바이스에 지원하고 있는 접근 가능한 입력 스트림 소스에 대한 리스트를 액세스할 수 있으며 이를 통해 적합한 디바이스를 선택할 수 있습니다.


getUserMedia()를 사용할 때 일부 브라우저는 카메라와 마이크에 대한 접근에 대한 사용자 허가를 요청하는 상태바를 표시할 수 있으며 getUserMedia()가 지원되지 않거나 API 호출이 실패하였을때 다른 형태의 미디어로 대체하는 과정이 필요할 수 있습니다.


> 입력 스트림을 통한 몇가지 구현 사례들

디바이스의 입력 스트림에 성공적으로 접근한 뒤에 <video>나 <audio> 태그의 소스로 사용할 수도 있지만 이를 통해 다음과 같이 추가적인 기능을 구현할 수도 있습니다.


  • 사진 찍기
    • <canvas> API의 ctx.drawImage()를 이용하여 입력 스트림을 정적인 사진 이미지 형태로 활용하여 사진 촬영 기능으로 사용할 수 있습니다.
  • 효과 적용
    • CSS Filters를 사용해서 <video>에 대한 효과를 적용할 수 있습니다.
    • 비디오 스트림을 WebGL Texture로 이용할 수 있습니다.
    • 크롬의 경우 getUserMedia()의 스트림을 Web Audio API로 연결하여 오디오를 직접 제어할 수 있습니다.


이제 웹앱의 범주를 확장하기 위한 다양한 시도들 중의 하나인 getUserMedia()를 이용하여 다양한 어플리케이션의 개발을 시도해보시기 바랍니다. 자세한 내용은 튜토리얼을 참조하세요.



번역 링크

참고 글


2014년 3월 7일 금요일

[튜토리얼/한글화] 자바스크립트 성능 수수께끼를 해결하기 위한 과학적인 검출 방법 사용하기(Use forensics and detective work to solve JavaScript performance mysteries)

HTML5Rocks에 +John McCutchan의 '자바스크립트 성능 수수께끼를 해결하기 위한 과학적인 검출 방법 사용하기(Use forensics and detective work to solve JavaScript performance mysteries)' 한글 튜토리얼이 업데이트되었습니다.

당연한 얘기지만 모든 최적화는 문제가 되는 지점을 개선하는 작업입니다. 당연한 얘기겠지만 이러한 이유로 성능 병목 지점을 찾는 것이 가장 첫번째 단계입니다. 문제의 원인을 찾으면 여러가지 테크닉 중 어떤 것을 선택해서 해결할 수 있는지에 대한 방법을 결정할 수 있을 것입니다. 이 튜토리얼은 Find Your Way to Oz의 개발 과정에서 성능 문제를 개선하기 위해 병목 지점들을 찾는데 사용된 방법을 다루고 있는 사례 연구이기도 하며 실질적인 가이드라인이기도 합니다.

이번 번역은 +Jae-Hoon Kim님께서 수고해주셨습니다. GDG Seoul 2월 밋업에서의 발표 후 얼마 안되서 바로 참여해주셨는데 감사드립니다. :)

"가비지 콜렉션이나 로직 오버헤드, 렌더링 오버헤드  혹은 리소스 로딩으로 인한 jank 등 하나의 어플리케이션에서 성능에 영향을 주는 요인은 굉장히 많습니다. 점진적으로 하나씩 개선해나가는 방식도 좋지만 가능하다면 가장 큰 요인 중 가장 쉽게 해결할 수 있는 것들부터 찾아나가거나 다른 기준에 의해 성능을 개선할 수도 있을 것입니다. 만약 이러한 방식을 원하신다면 그 무엇보다도 우선시되어야 할 작업은 최적화가 아닌 진단입니다."



TL;DR;


최근 몇 년 동안 자바스크립트 가상 머신 기술의 놀라운 진보에도 불구하고, 최근 한 연구는 Google 어플리케이션이 그들의 시간 중 50~80%를 V8에서 보내고 있음을 증명하였습니다. CPU 사이클은 하나의 제로-썸 게임입니다. 시스템 리소스를 더 적게 사용하도록 하는 것은 더 높은 성능을 보여주는 방법이며 고성능 실시간 어플리케이션에서 무엇보다 중요합니다.

성능 문제를 해결하는 것은 범죄를 해결하는 것과 유사합니다. 여러분은 조심스럽게 증거를 조사하고 의심되는 원인들을 확인하고 다른 해결책들을 실험하는 것이 필요합니다. 이러한 과정 내내 문제를 실제로 고쳤는지 확인할 수 있도록 반드시 측정된 결과들을 문서화해야 합니다.

이 튜토리얼은 Find Your Way to Oz의 모호한 성능 문제를 찾아내고 자바스크립트를 최적화와 프로파일링한 방법들을 다루고 있습니다. Oz의 경우 가설을 통해 최종적으로 선택된 두 개의 용의자가 있었으며 이를 V8 엔진의 로그와 V8 내부의 최적화에 관련된 추적을 통해 정확한 문제점을 도출하고 자바스크립트 for-in 구문의 수정을 통해 성능을 개선하였습니다.

> 자바스크립트의 로그를 이용한 성능 요인 검출 방법


V8 자바스크립트 엔진은 내장된 로깅 시스템을 가지고 있습니다.

터미널에서 "--no-sandbox --js-flags="--prof --noprof-lazy --log-timer-events" 인자들을 이용하여 크롬을 실행하고 어플리케이션을 구동한 뒤 종료하면 현재 디렉터리 안에 v8.log 파일이 생성됩니다. 이렇게 생성된 로그는 tick processor와 plot-timer-event를 통해 분석할 수 있습니다.


> V8 최적화의 추적


V8의 자바스크립트 성능 관련 팁들에서 언급된 바 있듯이 V8은 높은 성능을 위해 실행 시간에 자바스크립트에 대한 많은 최적화를 수행합니다. 만약 이 과정에서 의심되는 문제가 있다면 터미널에서 "--js-flags="--trace-deopt --trace-opt-verbose" 인자를 통해 크롬을 실행하여 상세 로그를 확인할 수 있습니다.


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


번역 링크

참고 글

[튜토리얼/한글화] 여러분의 Gruntfile을 강력하게: 빌드 설정 쥐어짜기(Supercharging your Gruntfile: How to squeeze the most out of your build configuration)

HTML5Rocks에 +Paul Bakaus의 튜토리얼 'Gruntfile을 강력하게: 빌드 설정 쥐어짜기(Supercharging your Gruntfile: How to squeeze the most out of your build configuration)'의 한글 버전이 업데이트되었습니다.

Node.js가 등장한 이후 이를 이용한 다양한 모듈과 서비스들 쏟아져 나왔습니다. 아마 Ben Alman이 만든 Grunt 역시 그 중의 하나이며 가장 사랑받는 모듈 중의 하나일 것입니다. Grunt는 프론트엔드 웹 개발 및 배포 환경의 많은 부분을 자동화할 수 있도록 강력한 빌드 기능을 제공합니다. 특히 JavaScript를 통해 이러한 부분이 제어될 수 있다는 점 역시 프론트엔드 개발자들에게 Grunt가 사랑받는 이유 중의 하나일 것입니다.

그러나 대부분의 프론트엔드 개발 프로젝트는 강력해진 기능만큼이나 복잡한 개발 및 테스트, 배포 환경을 필요로 하게 되었고 부피가 커진 만큼이나 다루기가 어려워져 가고 있습니다. Grunt도 이 부분에서는 예외가 아닙니다.

이 튜토리얼은 프로젝트가 커질 수록 더 유용해지는 몇가지 Grunt 플러그인들과 Grunt의 빌드 프로세스 자체를 개선할 수 있는 핵심적인 내용을 살펴볼 것 입니다.


"Grunt는 개발자가 커스터마이징할 수 있는 강력한 빌드 환경을 제공합니다. 하지만 복잡하고 거대해진 프로젝트 빌드 환경을 관리하는 것은 프로그래밍과는 또다른 영역의 작업들을 수반합니다. Gruntfile을 얼마나 깔끔하게 관리할 수 있는지, 빌드를 얼마나 신속하게 끝낼 수 있는지, 빌드의 완료나 문제에 따른 알림 처리를 통해 작업에 빠르게 복귀할 수 있는지에 대한 문제는 프로젝트가 커질 수록 더 중요해집니다. 과거의 (물론 현재도) Makefile이 그랬듯이 큰 프로젝트를 관리하는 것은 프로페셔널의 또 다른 모습일 것입니다."


TL;DR;


프로젝트가 커질 수록 깔끔하게 정리되고 빠르고 선택적인 처리, 무언가가 잘못되었을 때 알림을 발생하는 빌드 시스템은 언제나 개발자에게 유용합니다. 이 튜토리얼은 최근 프론트엔드 개발에서 널리 쓰이고 있는 Grunt의 빌드 프로세스 자체를 다음 관점에서 살펴봅니다.

  1. 어떻게 Gruntfile을 산뜻하고 깔끔하게 유지할 수 있는가,
  2. 어떻게 빌드 시간을 극적으로 개선할 수 있는가,
  3. 빌드 시 발생한 이벤트들을 어떻게 전달받을 수 있는가.


> Gruntfile의 체계적인 정리


Gruntfile 체계화하는 것은 지속적인 빌드 설정의 관리와 유지 보수 측면에서 매우 중요합니다.  Gruntfile 내에 수많은 Grunt 플러그인이나 수동 태스크들을 깔끔하게 정리할 수 있는 플러그인들은 다음과 같습니다.

  • Grunt 플러그인의 자동로딩
    • load-grunt-tasks는 package.json 파일을 분석할 것이며 이 태스크가 어떠한 Grunt 플러그인들에 대한 의존성들을 가지는지에 따라 이들 모두를 자동으로 로딩합니다.
  • Grunt 설정의 파일 단위 분리
    • load-grunt-config은 Gruntfile 설정을 작업 단위로 분리하며 load-grunt-tasks 및 그 기능들을 캡슐화해줍니다.


> 빌드 시간의 최소화


웹 앱의 실행 성능은 사업적으로 중요한 의미를 가지지만 빌드 성능은 개발의 반복에 대한 생산성을 담보합니다. 빌드 성능을 개선하기 위한 방법은 다음과 같습니다.

  • 변경 파일들만의 빌드
    • grunt-newer는 실제 파일 변경 정보를 저장하는 로컬 캐시를 통해  변경된 파일들에 대해서만 태스크를 실행합니다.
  • 다중 태스크의 동시 실행
    • grunt-concurrent는 CPU 단위의 스레드를 이용하여 동시에 여러개의 태스크를 실행합니다.
    • 서로에 대해 독립적이며 큰 실행 시간을 필요로 하는 다량의 태스크들을 가지고 있을 때 유용합니다.
  • 빌드 시간의 측정
    • 작업 단위별로 실행 요구 시간을 측정하기 위해 time-grunt를 사용할 수 있습니다.
    • 이는 다른 최적화와 마찬가지로 각 작업에 대한 최적화 지점을 찾을 수 있도록 합니다.


> 자동화된 시스템 알림


만약 다음 빌드가 가능하다던지 빌드 중의 오류를 개발자에게 알려주는 것은 자동화된 프로세스만큼이나 개발자에게 유용할 수 있습니다. 이런 기능이 필요하다면 grunt-notify는 Grunt 에러와 경고 전부에 대해 자동화된 알림을 제공하는 방법으로 사용할 수 있습니다.


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


번역 링크

참고 링크