2013년 12월 30일 월요일

[튜토리얼/한글화] CSS 페인트 타임과 페이지 렌더 가중치 (CSS Paint Times and Page Render Weight)

HTML5Rocks 'CSS 페인트 타임과 페이지 렌더 가중치(CSS Paint Times and Page Render Weight By +Colt McAnlis)' 한글 튜토리얼이 업데이트되었습니다.

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

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



TL;DR;


크롬에서의 하드웨어 가속 경로는 페이지를 페이지의 시각적요소를 레스터화하여 타일들로 출력(Paint)하며 이를 합성(Compositing)을 통해 최종적으로 출력합니다. 그리고 CSS에 의한 렌더링 모듈은 각각이 다른 동작을 수행합니다. 그렇다면 그러한 다른 CSS 속성이 여러분의 페이지를 렌더링하는 비용에 어떤 영향을 줄까요?


  • 일반적으로 더 비싼 렌더링 비용이 드는 CSS 속성들이 있습니다. 예를 들어 opacity는 빠르게 처리되지만 그라데이션이나 그림자는 그렇지 않습니다.
  • CSS 속성의 조합은 그들 부분의 합보다 훨씬 더 많은 페인트 시간을 가질 수 있습니다. 즉, A와 B에 해당하는 2가지의 CSS가 하나의 엘리먼트에서 결합될 때 예상과는 다르게 A + B보다 렌더링의 시간이 더 걸린다는 것입니다.


정확하게 판별하자면 CSS의 속성뿐만이 아니라 그 값과 그에 이어지는 다른 속성과의 조합에 따라 성능은 달리 나타날 수 있습니다. (어떤 CSS 속성들이 비용을 발생하는지는 크롬 개발자도구의 Continuous Paint mode를 사용하여 알 수 있습니다.) 이 튜토리얼은 이러한 성능을 어떻게 평가할 수 있는지에 대한 기초적인 이해에 도움될 것입니다.


번역 링크

[튜토리얼/한글화] 객체 풀 기반의 정적 메모리 자바스크립트(Static Memory Javascript with Object Pools)

HTML5Rocks '객체 풀 기반의 정적 메모리 자바스크립트(Static Memory Javascript with Object Pools By +Colt McAnlis)' 한글 튜토리얼이 업데이트되었습니다.

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

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

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



TL;DR;


가비지 콜렉터는 자동 메모리 관리의 한 형태입니다. 가비지 콜렉터는 가비지, 또는 프로그램이 사용하다가 더이상 필요가 없어진 객체가 점유하고 있는 메모리를 수거합니다. 그러나 메모리를 수거하는 과정은 비용이 들어감으로 인해 일정 시간이 지나면서 웹 게임/웹앱의 성능이 심하게 저하되는 이유 중의 하나는 가비지 콜렉션(Garbage collection) 실행으로 인한 것이라 할 수 있습니다. 이에 대한 해결 방법은 "메모리 변동(memory churn)"이라 불리는 지나친 객체 생성/제거를 가능한 막는 것이며 이것이 GC 동작을 줄이는 방법의 핵심입니다.

정적 메모리 JavaScript는 애플리케이션의 시작 시점에 실행하는 동안에 필요한 모든 메모리를 사전할당(pre-allocating)하고 객체가 더 이상 필요없어지면 실행 중에 메모리를 관리하는 테크닉입니다. 이 방법은 객체를 가비지 콜렉팅이 대상가 되지 않도록 유지하므로 GC가 성능에 미치는 영향을 줄일 수 있습니다. 함께 사용할 수 있는 추가적인 방법으로 객체 사전할당(Pre-allocating objects)을 통해 실행중에 동적으로 발생하는 객체 할당의 양을 줄일 수 있습니다.

그러나 객체 풀 자체가 GC가 발생하는 조건에 좀 더 가까워지도록 만들기 때문에 모든 애플리케이션에 적용할 수는 없으며 주의해서 사용해야 하는 테크닉이기도 합니다.

번역 링크

참고 글

2013년 12월 29일 일요일

[업데이트] Yeoman 월간 다이제스트 #2 (The Yeoman Monthly Digest #2)

+Addy Osmani가 'Yeoman 월간 다이제스트 #2'를 포스팅했습니다. 더불어서 +Jimmy Moon 님이 이번에 +Yeoman 코어팀 멤버가 되셨네요. 축하합니다! 기념해서 이번 요약 설명은 +Jimmy Moon님의 포스팅으로 대신합니다. :)

"+Yeoman 월간 다이제스트 2호가 발간 되었습니다. 이번호 에서는 grunt pro-tips 을 포함해서 역시 Yeoman 을 활용하는 다양한 Video, Tutorial 이 있습니다. MadJs, NetbraskaJS Meetup 의 강좌 비디오가 있구요 AngularJs, Ember.Js 그리고 Node.js 를 활용한 강좌와 Cordova 를 이용해서 만드는 Webapp 강좌가 있습니다. 
yo 는 1.0.7-pre 가 npm 에 올라와 있구요. Backbone, AngularJs, Ember.JS, WebApp, Polymer 그리고 Chrome App Generator 공식 제네레이터들이 버전업 되었습니다. 그외로 프레젠테이션으로 유명한 Reveal.js, Javascript 3D Library three.js 등의 커뮤니티 제네레이터들을 선정했습니다."

월간 다이제스트의 전문은 아래를 참고하시기 바랍니다.


Yeoman

Yeoman 월간 다이제스트 #2 전문


안녕, 안녕? 행복한 연휴되시길! 여러분이 좋아하시는 모자 쓴 남자와 함께 무엇이 새로워졌는지를 훤히 알 수 있는 우리의 공식적인 글들, 팁들, 생성기들 그리고 비디오들을 담고 있는 Yeoman의 월간 다이제스트의 2번째 이슈에 오신것을 환영합니다. 아래의 소식에서 도움되는 것을 찾을 수 있기를 바랍니다!


프로페셔널한 Grunt 조언들(Pro Tips)


존재하는 모든 Grunt 플러그인을 시도해는 것은 구미가 당기는 일입니다. 엄청 많고 많죠!! 게다가 흥분하기도 쉽습니다. 이를 깨닫기까지 여러분은 실제 사용보다 더 오랜 시간동안 터미널을 노려보고 있어야 할 것입니다. 이는 빌드를 하는 동안에도 좌절하는 일이지만 실제 터미널을 지켜보는 동안에도 훨씬 더 많이 좌절하게 만들 것입니다.

다행히도 커뮤니티는 개발 사이클은 한층 더 빠르게 만드데 노력을 기울여 왔습니다.
  • 커스텀 작업 트릭을 이용한 Grunt 의 컴파일 시간의 감소
  • 변경된 파일들에 대해서만 Grunt 작업을 실행하기 위한 grunt-newer의 사용
  • 작업을 병렬로 수행하는 grunt-concurrent을 실행하여 여러 작업들을 동시에 실행할 수 있도록 함
그외의 조언들은 다음과 같습니다.




생성기


yo 1.0.7-pre 버전은 현재 NPM에서 테스트 가능하며 차주 중에 2014년 로드맵에 대해 더논의할 것이 없는지 확인할 것입니다. 그 사이에 공식 생성기와 여러분들이 작성했던 것에 대한 새로운 업데이트들이 아래와 같이 흘러넘칠 지경입니다.


공식 생성기에 대한 업데이트


  • Backbone 0.2.2 버전 릴리즈
    • RequireJS와 CoffeeScript 지원
    • --appPath 옵션 지원
  • AngularJS 0.7.1 버전 릴리즈
    • Angular 1.2.6과 grunt-bower-install 지원
  • Ember.js 0.8.0 버전 릴리즈
    • Ember 1.2 문법에 대한 스캐폴딩 업데이트
    • CoffeeScript 지원
    • 템플릿 기능(Templating)
    • REST 라우터
  • WebApp 0.4.5 및 0.4.6 버전 릴리즈
    • 개선된 HTMLMin 포함
    • bower 인스톨 버그 수정
    • CSS 의존성을 지원하는 grunt-bower-install 포함
  • Polymer 생성기 0.0.8 버전 릴리즈
    • Web Component 연결(Concatenization) 및 다른 업데이트들
  • Chrome app 0.2.5 버전 릴리즈
    • 라이브리로드(Livereload)의 지원 개선
    • 앱 생성기의 재작성
    • 패키징을 위한 빌드 태스크
    • 새로운 권한 코드 등

jQuery, Gruntfile, CommonJS, NodeJS 및 Mocha를 포함한 다른 공식 생성기 역시 업데이트되었습니다.


커뮤니티 위주의 생성기들




요, 새해입니다(yo newyear!)


끝났습니다! 만약 다음 이슈에서 제안하시고 싶은 Yeoman 리소스들이 있다면, 트위터 @yeoman 혹은 구글플러스 +Yeoman에 그것들을 편안하게 제안해주시기 바라며 저희는 반드시 제안된 것들을 확인하도록 하겠습니다. 행복한 연휴되시고 환상적인 새해 맞으시기를 바랍니다!

이 이슈의 리뷰를 해준 Stephen Sawchuk, Sindre Sorhus 그리고 Pascal Hartig에게 특별히 감사드리며...


"Yeoman은 어떠한 프레임워크에 특화된 기반 구조(scaffold)들을  조합 가능한 생성기(Generator)를 이용한 작업흐름을 도와주는 도구입니다. Yeoman에 대해서는 Yeoman과 Polymer를 이용한 웹앱 개발(Building Web Apps With Yeoman And Polymer) 튜토리얼에서 자세하게 다루고 있으니 관심있으신 분들은 참고하시기 바랍니다."

2013년 12월 27일 금요일

[업데이트] 크롬 개발자도구 12월 요약(Chrome DevTools Digest December 2013)

크롬 개발자도구에 대한 요약이 11월 다이제스트에 이어 +Umar Hansa가 작성한 12월 버전이 나왔네요. 이전에는 튜토리얼이었지만 이번은 포스팅으로 제공되어 따로 번역에 대한 링크 없이 이 포스팅에서 전문을 다루도록 하겠습니다.

"여기서 다루는 기능은 기본적으로 크롬 Canary에서 동작합니다. 일반적으로 Official은 대부분 8~10주 뒤에 적용되므로 혼동이 없으시기 바랍니다. Chrome Canary Version은 여기에서 다운로드하시기 바랍니다."


크롬 개발자도구 12월 다이제스트


최근 많은 개선된 기능들이 크롬 개발자도구에 포함되고 있으며 몇 가지는 작은 것이지만 몇가지는 아주 큰 기능들입니다. 오늘은 엘리먼트 패널의 업데이트에 대한 이야기부터 시작하여 콘솔, 타임라인 등으로 주제를 넓혀나가보려 합니다.

비활성화되어 있는 스타일 규칙의 복사가 코멘트처럼 처리


Styles pane에서 전체 CSS 규칙을 복사하는 것은 이제 토글로 꺼둔것을 포함하며 클립보드에는 코멘트처리한 것처럼 존재하게 됩니다. [crbug.com/316532]

CSS 경로로써 복사하기


‘Copy as CSS path’가 이제 엘리먼트 패널의 DOM 노드의 메뉴 아이템에서 사용가능합니다. (Copy XPath 메뉴와 유사합니다.)


CSS 셀렉터의 생성은 여러분의 스타일시트/자바스크립트에 제한되지 않으며 WebDriver 테스트의 로케이터 전략으로 대체될 수도 있습니다.[crbug.com/277286]

쉐도우 DOM 엘리먼트 스타일 보기


이제 쉐도우 루트의 자식 엘리먼트는 별도로 확인 가능한 스타일을 가집니다. [crbug.com/279390]

콘솔의 copy()가 객체에 대해 동작


커맨드라인 API의 copy() 메소드가 이제 객체에 대해 동작합니다. 일단 가서 콘솔 패널에 copy({foo:'bar'})를 입력하고 어떻게 문자열화가 되는지와 객체의 형식화된 버전이 클립보드에 어떻게 남아 있는지 확인하시기 바랍니다. [crbug.com/289348]

콘솔을 위한 정규표현 필터


콘솔 패널에서 정규 표현식을 이용한 콘솔 메시지의 필터가 가능합니다.[crbug.com/318308]

손쉬운 이벤트 리스너 제거


콘솔 패널에서 document의 첫번째 마우스 이벤트 리스너를 검색하기 위해getEventListeners(document).mousewheel[0];를 실행하여 보시기 바랍니다. 계속해서 이벤트 리스너를 제거하기 위해 $_.remove();를 실행하여 보시기 바랍니다.($_는 가장 최근에 평가된 표현의 값입니다.) [crbug.com/309524]

CSS 경고의 제거


"Invalid CSS property value(유효하지 않은 CSS 속성값)"과 같은 스타일 경고는 이제 제거되었습니다. 브라우저의 핵(hack)을 포함하여 실제 CSS에 대해 더 견고한 구현을 만들기 위한 노력은 계속되고 있습니다. [crbug.com/309982]

타임라인 동작의 파이차트 요약



타임라인 패널은 이제 Details pane 내에 렌더링 비용의 소스를 시각적으로 보여주는 파이 차트를 포함합니다. - 이는 슬쩍 보는 것만으로도 성능의 병목지점을 파악하는데 도움을 줄 것입니다.
이제 pane 자체에서 알려주는 팝오버 디스플레이를를 사용하여 더 많은 정보를 발견할 수 있습니다. 이를 보기 위해 타임라인 기록을 시작하고 프레임을 선택하여 파이차트를 포함하는 새로운 Details pane을 보시기 바랍니다. 프레임뷰를 볼 때 평균 FPS (1000ms/프레임)과 같은 흥미로운 상태값을 선택한 프레임에 대해 볼 수 있습니다. [crbug.com/247786]

이미지 리사이즈 이벤트 상세정보


이제 이미지의 리사이즈 및 디코딩 이벤트가 타임라인 패널에 엘리먼트 패널 내의 DOM 노드에 대한 링크를 포함합니다.


이미지 URL 링크는 리소스 패널에서 관련된 리소스를 찾을 수 있도록 해줍니다. [crbug.com/244159]

GPU 프레임


GPU에서 발생하는 프레임들은 이제 최상단 및 메인 스레드 상의 프레임 위에서 보여집니다. [crbug.com/305863]

popstate 리스너 상에서의 브레이크


'popstate'는 이제 Sources panel의 사이드바에서 이벤트 리스너 중단점처럼 사용이 가능합니다. [crbug.com/88112]

렌더링 설정의 서랍(Drawer) 기능


서랍을 열면 이제 많은 pane들이 표시되며 그 중의 하나가 새로 그리는 영역을 표시하는(역주: 이전의 기능에서는 Show paint rectangles로 설정할 수 있는 기능입니다.) 렌더링 패널, FPS 메터기 등입니다. 이것이 이제 설정(Settings) > "Show 'Rendering' view in console drawer"가 가능하도록 기본 설정이 되었습니다.

이미지의 Data URL 복사



리소스 패널의 이미지들은 이제 그들의 컨텐츠를 data URI (data:image/png;base64,iVBO...) 형태로 복사할 수 있습니다. 이를 사용하기 위해서는 Frames > [Resource] > Images에서 이미지 리소스를 찾아 이미지 미리보기 화면에서 오른쪽 클릭으로 컨텍스트 메뉴를 열고 ‘Copy Image as Data URL’를 선택하면 됩니다. [crbug.com/321132]

Data URI 필터링


만약 그것들이 없다고 생각되신다면 Data URIs는 이제 Network 탭에서 걸러내질 수 있습니다.  다른 리소스 필터 타입을 보기 위해서는 필터 아이콘()을 클릭하시기 바랍니다. [crbug.com/313845]

네트워크 타이밍 버그의 수정


만약 이미지가 다운로드되는데 300,000년이 걸린다는 것을 본적이 있으시다면 사과드리겠습니다. ;) 이러한 네트워크 리소스에 대한 잘못된 시간 계산은 이제 수정되었습니다. [crbug.com/309570]

네트워크 기록 동작에 대한 조작성 향상


네트워크 기록 동작이 약간 달라졌습니다. 첫번째로 기록 버튼이 타임라인이나 CPU 프로파일에서 기대하던 것처럼 동작합니다. 그리고 여러분들이 원했던 방식으로 개발자도구가 열려있는 동안 페이지를 리로딩한다면 네트워크 기록은 자동으로 시작할 것입니다. 그리고 나서 자동으로 꺼지므로 페이지 로딩 뒤의 네트워크 동작을 캡쳐하고 싶으시다면 이를 다시 켜시면 됩니다. 이는 여러분의 임시적인 네트워크 요청으로 인한 결과의 왜곡없이 폭포수 모델을 손쉽게 시각화할 수 있도록 해줍니다. [crbug.com/325878]

개발자도구의 테마가 이제 Extension을 통해 가능


사용자의 스타일시트가 개발자도구에 대한 커스텀 스타일을 적용하기 위한 크롬 익스텐션을 허가하는 개발자도구의 실험실 기능("Allow custom UI themes" 체크박스)을 통해 가능합니다. Sample DevTools Theme Extension에서 예제를 보실 수 있습니다. [crbug.com/318566]


개발자도구 요약의 이번 에디션은 여기까지입니다. 기존 것을 보신 적이 없으시다면 11월 에디션도 확인해보시기 바랍니다.

참조 링크

2013년 12월 23일 월요일

[업데이트] 블링크의 CSS 애니메이션/트랜지션 엔진이 웹 애니메이션으로 대체되었습니다.

이미 이에 대해 포스팅한 바를 보셨을 것입니다. Web Animaiton은 기존의 CSS 애니메이션 및 트랜지션, SVG 애니메이션과 SMIL 등 기존의 애니메이션 요소를 자바스크립트로 동적 제어가 가능하도록 정의하고 있는 새로운 애니메이션 규격입니다. -그렇다고 해서 아주 새로운 것은 아닙니다. 기존 CSS 애니메이션/트랜지션이나 SVG, SMIL 등의 기존 기술에 대한 '제어'를 주된 목표로 두고 있다고 이해하셔도 무방합니다.-

이에 대한 시작으로 Web Animations의 자바스크립트 API 구현을 참조할 수 있는 Polyfill 라이브러리인 web-animtations.js이 진행되고 있습니다. 현재 블링크(Blink)에는 이 기능을 네이티브로 구현하는 작업이 진행 중인데 이에 대한 첫 단계로 크롬 카나리에서 기존 CSS 애니메이션과 트랜지션 엔진이 Web Animation 구현 엔진으로 대치되어 배포되고 있습니다.

현재는 JS API가 존재하지 않으므로 외부에서는 차이점을 느끼기 힘들겠지만 대략 2월 말에는 공식 버전으로도 배포가 될 예정입니다. (물론 이는 JS API를 포함하지는 않습니다.) 아래는 HTML5Rocks에 +Alex Danilo 가 올린 업데이트 'New Web Animations engine in Blink drives CSS Animations & Transitions'에 대한 번역입니다. 실제 API의 구현 및 동작에 대해서는 아래 참조 링크에서 확인하시기 바랍니다. :)


전문


사용자들은 멀티 디바이스 UI들에 대해 부드러운 60fps 애니메이션을 기대합니다. 웹의 현재 애니메이션 기본형을 가지고 그러한 성능 품질을 달성하는 것은 어려울 수 있습니다. 다행히도 Blink의 새로운 애니메이션을 구현하고 있으며 크롬 카나리에 막 탑재되었습니다!

블링크의 내부가 단순화되고 Web Animation 1.0 규격의 새로운 API 기능을 포함하는 바탕이 마련된 것에 대해 매우 기쁘게 생각합니다.

지금까지 CSS 애니메이션과 CSS 트랜지션은 분리되어 구현되었으며 독립적으로 작성되어 동시에 재생할 필요가 없었습니다. 지난 몇년간 브라우저 구현자들은 동기화나 애니메이션 체인, 순차적으로 재생되고 애니메이션의 특정한 위치로의 이동, 애니메이션의 재생 속도 변경이나 역재생 등과 같은 것을 지원하는 다음 세대의 애니메이션 모델을 위해 일해왔습니다. 이러한 노력이 W3C의 Web Animations 1.0을 정립하도록 하였습니다.

블링크팀은 Web Animation을 세상에 내보이기 위한 첫 걸음으로 기존 블링크의 CSS 애니메이션/트랜지션에 대한 C++ 구현을 Web Animaiton 엔진으로 대치하는 것입니다. 현재 그 마일스톤에 도달하여 많은 개발자들이 아무것도 깨지지 않고 구현에 매진하는 것이 더 중요하며, 무엇이 좋아졌고 나쁜지나 변경이 필요한 부분에 대한 피드백을 주기를 원하고 있습니다.

다음은 자바스크립트로 애니메이션의 생성, 변경, 조회를 제공하는 API의 구현이 될 것입니다. API는 여전히 자바스크립트 개발자에게 완전한 애니메이션 제어를 보여주면서 애니메이션이 (선언적인 문법을 사용하여 자바스크립트가 애니메이션을 생성하는 것을 관리하고 브라우저가 이를 컨트롤하여) 더 효율적으로 동작할 수 있도록 합니다.

우리는 강력한 애니메이션 조작을 위해 필요한 어떠한 기능도 놓지지 않았음을 확신하기 위해 제안된 API에 대한 활발한 피드백을 찾고 있습니다. 어떠한 새로운 기능이나 규격이라도 변경이 지속되고 있으므로 이제 여러분의 목소리를 들을 시간입니다. - public-fx@w3.org 메일링 리스트를 구독하고 기여하는 것이 이상적입니다. (그리고 제목에 [Web Animations]를 넣어주시면 효과적입니다.)

이미 CSS 애니메이션과 트랜지션을 강력하게 하고 있는 새로운 엔진을 지금 사용해보시고 어떤 이상한 점이라도 Chromium 버그 트래커에 포스팅해서 알 수 있도록 해주시기 바랍니다. 우리는 차세대 애니메이션 역량을 블링크로 제공하고 또한 새로운 모델의 구현에 커밋한 웹킷과 모질라와 같은 다른 브라우저 개발자와 일할 수 있기를 기대합니다.

참조링크

2013년 12월 18일 수요일

[튜토리얼/한글화] 레이서 게임의 구축(Case Study: Building Racer)

HTML5Rocks '사례연구: 레이서 게임의 구축(Case Study: Building Racer)' 한글 튜토리얼이 업데이트되었습니다.

이전 튜토리얼인 사례연구: Racer의 사운드(Case Study: The Sounds of Racer)에서는 레이서 게임 내의 사운드 구축을 위한 개발 과정과 기술에 대해서 다루었습니다면 이번 튜토리얼에서는 게임을 구축하기 위한 나머지 과정, 특히 렌더링에 대한 내용을 주로 다루고 있습니다. HTML5 게임이나 인터랙티브 컨텐츠를 개발하시거나 계획 중이시라면 읽어보시면 좋을 듯 합니다. 이번 번역은 신현진님(+Hyunjin Shin)께서 수고해주셨습니다.  :)




TL;DR;


레이서는 5명의 친구가 폰이나 태블릿을 이용하여 게임을 진행할 수 있도록 Google Creative Lab과 Plan8의 사운드를 기반으로 8주간 진행되어 Google I/0 2013에서 발표된 실제 이론에 기반한 웹 기반 크롬 실험 형태의 게임입니다. 이번 글에서는 개발자 커뮤니티에서 주로 질의되었던 몇가지 동작 방식에 대한 내용과 레이서의 주요 기능 및 질의 사항에 대한 응답을 정리하였습니다.

트랙을 그리기 위해 해상도를 설정하고 이를 그리기 위한 로직, CSS 애니메이션과 CSS 스프라이트를 통한 렌더링 팁, 실제 게임 내에서 자동차를 렌더링하기 위해 트랜스폼을 어떻게 사용하였는지와 실제 디바이스 간의 동기화를 위해 지연 시간을 계산하고 이를 보정한 방법을 실제 코드와 함께 설명합니다.

아래는 그 중 일부 중요한 내용만 따로 차용한 것입니다.
  • 모바일 디바이스의 해상도 변화에 대응하기 위한 해상도 설정
  • CSS 스프라이트시트를 이용한 스프라이트 애니메이션
  • 궤적의 변화에 따른 애니메이션 처리를 위한 실시간 트랜스폼 연산 및 적용
  • 동기화를 위한 지연 시간의 계산 및 라운드 트립
자세한 내용은 본문을 참조하시기 바랍니다.

번역 링크

참고 글

2013년 12월 16일 월요일

[튜토리얼/한글화] 자바스크립트 Promise: 또 다른 시작(JavaScript Promise: There and Back Again)

HTML5Rocks에 내리는 눈과 함께 기대했던 +Jake Archibald 의 "자바스크립트 Promise: 또 다른 시작(JavaScript Promise: There and Back Again)"이 업데이트되었습니다.
"참고로 There and Back Again은 영화 The Hobbit 3부작 중 마지막 편의 제목이기도 합니다. 뜻밖의 여정, 스마우그의 폐허는 일단 나왔으니 이어서 붙인 장난스러운 제목일지도 모르겠군요. :)"
자바스크립트의 비동기 동작으로 인해 콜백이 콜백을 부르고 다시 콜백이 콜백을 부른 과정이 중첩되다보면 내가 콜백인지 콜백이 나인지 헷갈릴 정도의 Callback Hell에 빠지게 됩니다. Promise는 이러한 비동기 동작을 손쉽게 처리할 수 있도록 고안된 비동기 프로그래밍 모델입니다.

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



TL;DR;


이 글은 브라우저의 지원 사항 및 Polyfill 소개, 다른 라이브러리와의 호환성, 복잡한 비동기 코드를 쉽게 만들기, XMLHttpRequest의 Promise화, Promise 객체의 체이닝(Chaining) 및 에러 핸들링, 병렬과 시퀀싱, Promise API 레퍼런스 등에 대해 다루며 이에 대한 예제들이 포함되어 있습니다. 지금까지 나온 Promise 관련 튜토리얼 중에 가장 자세한 내용이 아닐까 싶네요.


  • 이벤트는 비동기적인 모듈의 동작 결과를 처리하는 최고의 방법 중의 하나입니다만 콜백 형태의 호출이 꼬리를 물어가는 콜백 지옥(Callback Hell)에 빠지게 되는 것은 개발자에게는 일종의 불행과도 같습니다. Promise는 이를 순차적인(동기화)된 듯한 개발 방법을 제공합니다. 코드가 읽기 쉬워지고 콜백의 분기처리를 익숙한 순차적인 처리가 가능해지기 때문에 복잡한 콜백이 얽히는 과정에는 훌륭한 모델을 제공할 수 있습니다.
  • Promise에 대한 개념을 잡아보고 현재 브라우저 지원 상황 및 대체 라이브러리(Polyfill), 다른 라이브러리들과의 호환성을 소개합니다.
  • 실제 예제로는 복잡한 비동기 코드를 좀더 쉽게 만들기 위한 코드를 예제로 동기화된 모듈로부터 비동기화된 모듈, 그리고 최종적으로는 Promise화된 모듈의 구현 사항들을 순서대로 진행합니다.
  • 이 과정에서 Promise의 연결을 구현하는 체이닝(Chaining)과 에러 핸들링, 그리고 비동기적인 처리를 동시 수행하면서 필요한 로직을 Promise를 통해 순차적으로 처리하는 방법을 다루고 Promise API 레퍼런스를 수록하고 있습니다.


튜토리얼 링크