레이블이 소식인 게시물을 표시합니다. 모든 게시물 표시
레이블이 소식인 게시물을 표시합니다. 모든 게시물 표시

2014년 2월 27일 목요일

[Summit/Summary] Google Developers Summit 후기

세미나나 컨퍼런스에 참가하는 것은 언제나 즐거운 일입니다. :) 어제(26일)도 코엑스 그랜드볼룸에서 Google Developers Summit이 있었습니다. 이번 서밋은 처음과 끝의 세션들은 서비스 관점에서의 내용들이 위주였고 중간 트랙 부분만 기술 관점의 세션들로 구성되어 있었습니다. 어제 들으며 요약해 놓은 내용을 공유합니다. 선발 신청 형태였음에도 많은 분들이 오셨더군요. 서밋 준비로 +Soonson Kwon님과 구글 코리아에서 고생하셨을 것 같습니다. 박수를~~ 보내드리며 후기 시작합니다. :)


  • 일시: 2월 26일 수요일 오후 1시 ~ 오후 6시 30분
  • 장소: 삼성역 코엑스 그랜드 볼룸 104호, 105호

아래는 제가 들은 세션의 스케쥴입니다.

시간주제 및 발표TL;DR
13:10 ~ 13:50Avoiding Pitfalls on Android App Quality and Visibility at Google Play (Ryosuke Matsuuchi)Your success with Android App depends on several quality characteristics of your app and good publishing techniques. In this session we'll discuss about how you can avoid common pitfalls on the app quality and publishing.
14:00 ~ 14:40다시 한번 안드로이드 디자인 가이드라인 (양찬석)
15:00 ~ 15:40Chrome WebView Essentials (Alex Danilo)Android 4.4 KitKat introduces a new WebView based on Chromium. The new WebView brings wonderful HTML5 APIs as well as lots of enhanced functionality. This session introduces the Chrome WebView, it's capabilities, debugging features and backward compatibility enhancements. Best practices for using the new WebView in existing applications will also be explained.
15:50 ~ 16:30Increasing user engagement in your apps with YouTube APIs (Yoshifumi Yamaguchi)In the past year, YouTube has made it easier for anyone to live stream content to the world as well as improved mobile video playback. Learn how you can utilize YouTube APIs to increase user engagement in your apps. We will show you examples of apps that have done this and walkthrough the technical implementation.
16:40 ~ 17:20크롬캐스트와 구글 캐스트 (미키김(김현유), 조시형)작년에 미국에서 출시한 크롬캐스트는 N 스크린과 스마트 TV 시장에 새로운 화두를 던지고 있으며 타임지가 뽑은 2013년도의 제품을 선정되기도 했습니다. 이번 세션에서는 크롬캐스트에 대한 소개 및 구글 캐스트 SDK에서 대해서 이야기하고 개발자가 가질 수 있는 기회에 대해서 다룹니다.

아래는 들으면서 적어둔 각 세션에 대한 요약 로그입니다.


Session.1: Avoiding Pitfalls on Android App Quality and Visibility at Google Play - +Ryosuke Matsuuchi 


료스케 마츠우치씨는 구글 플레이에서의 가이드라인에 대한 내용을 "구글 플레이에서 안드로이드 앱 품질과 가시성에 대한 위험 회피하기"라는 제목으로 세션을 진행했습니다. 일단 앞부분은 제가 딴짓 하느라 살짝 놓쳤는데 어쨌던 구글 플레이에서의 모든 노출 알고리즘은 영역에 상관없이 동일한 방식을 따른다더군요.

아래는 회피해야할 위험(Pitfall)들로 묘사된 슬라이드에 대한 내용입니다. 일반적인 내용도 많지만 참조해보시길.

> #1 나쁜 사용자 평가


일반적으로 4개에서 5개의 별을 받은 어플리케이션이 3개를 받은 어플리케이션의 매출 수준에 비해 2.8배의 매출을 보인다고 합니다. 근본적으로 사용자 평가를 관리하는 품질 관리, 운영 및 지원의 근본적 원인이겠죠.

> #2 높은 언인스톨율


가짜 스크린샷이나 잦은 알림(Notificaiton) 등으로 인한 언인스톨들이 많이 발생하며 이러한 언인스톨율이 높은 경우의 문제의 가장 일반적인 경우 중 하나는 프로모션을 통해 빠르게 랭킹에 진입한 뒤 언인스톨율이 높으면 빠르게 랭킹에서 사라지는 현상입니다.

그렇다면 랭킹에서의 drop율은 언인스톨율에 의해 가속될 수 있는 것인가? 라는 의문이 들었는데 질문 시간에 유사한 질문이 있어 따로 질의를 하지는 않았습니다. 랭킹 시스템 등은 일반적으로 비밀이기도 하고 해서 자세한 답변은 하지 않은 것 같더군요.

또다른 질의는 "개별 국가에서의 언인스톨이 영향을 주는가?" 였는데 결론적으로는 '직접적인 영향은 주지 않지만 다른 국가에 대한 간접적인 영향은 준다.'였습니다. 시스템적으로도 그런 것인지는 좀 불분명한데…기회가 되면 확인해보시고 공유해주시면 감사하겠습니다. :)

> #3 낮은 성능


소프트웨어 개발쪽에서는 '성능은 언제나 문제(Performance is always problem)'이라는 말을 쓰는 경우들이 많은데요. -저만 자주 들었나요? 제가 이쪽에 관심을 두고 있어서 그런 것 같기도 합니다만...:)-

아무튼 이에 대한 UX 관점에서의 권장 사항을 얘기하더군요.


  • 스크롤/애니메이션에 대해 20FPS 이상 유지
  • 터치에 대한 200ms 내의 반응성
  • 웹과는 다른 사용자 경험 
    • 웹과는 다르다기 보다는 멀티태스킹이나 시스템 자원 활용이 비교적 자유로운 네이티브 앱의 특성 상 프리패치나 백그라운드 태스크, 캐싱 등에 대한 지원을 통해 성능을 높이라는 얘기입니다.
  • 디버그 모드에서 Strict 상태에서의 “Red Flash”는 제거
    • 제가 안드로이드를 별로 안해봐서 정확하게는 모르지만 기억으로는 렌더링 오버헤드가 일어나는 영역에 빨간색 박스를 쳐주는 기능이 있었던 것 같은데요. 이를 응용해서 성능 최적화를 하라는 얘기로 생각합니다.


> #4 - 태블릿 사용자


일단 스마트폰과 대비했을 때 1.7배의 사용자가 앱을 구매한다고 하더군요. 그리고  13.1%의 안드로이드 디바이스가 높은 해상도를 가지고 있으므로 고해상도에 대한 대응을 반드시 해달라고 합니다.

  • 다양한 해상도를 지원하는 앱으로 제작
    • 안드로이드의 경우 Fragment를 사용하면 되겠고 하이브리드 웹앱의 경우는 반응형이나 뷰 분리같은 것들이 해당되겠죠.
  • 가급적 태블릿 버전을 별도로 분리하지 말 것
  • Google Play에서 “폰을 위해 디자인된 앱” 레이블링을 피할 것
    • 2013/11/22부터 구글 플레이에서 태블릿을 위해 디자인 된 앱에 대한 리스트를 보여주므로 사실은 태블릿을 지원한다는 것이 더 좋은 마케팅 포인트로 보입니다.


> #5 기존 디바이스 사용자를 타겟팅한 개발


매우 강조하던 부분 중의 하나인데 기존 디바이스에 비해 신규 단말의 사용자가 2.2배의 구매율을 보이므로 사실은 신규 단말을 대상으로 하라는 얘기입니다.


  • SDK Ver.19 이상으로 설정하여 “Menu button of shame”을 회피할 것
  • 2.x 버전에 대한 지원 패키지도 있으니 최신 UI/UX 가이드라인을 따를 것
  • 구글 게임 플레이 서비스 및 컨트롤러 등의 최신 기술에 대해 사용을 고려할 것

이 부분은 아무래도 최신의 안드로이드 플랫폼과 기술을 확산시키려는 구글의 의지가 반영된 내용이라고도 보입니다. 물론 UX 가이드라인은 지원 패키지가 있으니 하는게 Look & Feel에서 맞다고 보여집니다.


> #6 일반적인 배포 실수들


간단하게 정리하겠습니다.

  • 통신 사업자 및 호환 스크린 등에 대한 사용과 같은 좁은 범위의 대상으로 배포하는 것을 회피
  • 고해상도의 앱 런칭 아이콘을 제공. XXXHDPI까지 얘기를 하는 것을 보면 나름 TV 부분에 대한 니즈도 있는 것 같다는 생각이 듭니다.
  • 스팸이나 잘못된 정보 기재 조심
  • 소개 비디오는 가급적이면 삽입할 것
  • 해외 사용자를 위한 번역에도 신경쓸 것


> #7 끔찍한 권한 요청들


이 부분은 저도 동의하는 바입니다만, 가끔 퍼미션을 필요한 것보다 과도하게 넣는 경우들이 있는데 이건 좀 피해줬으면 좋겠습니다. 요즘 같이 정보 보안에 민감한 시대에 아무래도 걱정되는 부분들이 사용자 입장에서는 있으니까요. 예를 들어 게임에서 사용하지 않는 경우에도 사진 촬영 퍼미션을 넣는다던지 하는 경우죠. 권한이 필요하다면 왜 쓰는지 깔끔하게 정리해서 설명하는 것이 좋습니다.

게임에서 주로 잘못된 권한 요청의 예는 다음과 같습니다. -가만 보면 가끔 게임에서 쓰는 것들은 있기는 합니다.-

  1. WiFi 설정 변경
  2. 부팅 완료 노티
  3. 실행 태스크들에 대한 쿼리
  4. 현재 위치 정보
  5. 시스템 로그 접근
  6. 직접적인 전화 연결
  7. 연락처 및 캘린더 접근
  8. 북마크 접근
  9. 시스템 수준의 경고 출력
  10. SMS 송수신


> #8 IA 결제 API에 대한 잚못된 사용



  • Version 3 API를 사용하세요! - 구버전을 사용하는 경우가 많은가 봅니다.
  • 메모리 부족에 대해 반드시 테스트할 것
    • 생각보다 많은 프로그램이 결제 중 메모리 문제로 셧다운이 일어나서 사용자에게 결제 처리 여부에 대한 고민을 하게 되므로 사용자에게 결제가 진행되지 않았으면 이를 다시 시작한다는 것을 명확하게 처리
  • 구매 토큰을 반드시 서버에 저장할 것!!!!!
    • 어쨌던지 사용자의 불만 제기에 대해서 대응 시에도 이러한 부분은 필요하다는 것이 주요한 내용입니다. 생각보다 많은 사람들이 서버 없이 해서 그런가 싶기도 하네요.
  • 서버측 인증서 검증 기능을 구현할 것
    • java.security.Signature.verify()를 믿지 말고 서버에서 할 것.
    • …이건 뭐지…싶었는데 실제로는 가짜 신용카드나 결제 정보를 이용하여 구매를 해킹하는 경우가 많은 듯 합니다.
  • 사용자 구매 정보, 커스텀 리포트 등을 이용하여 잘 운영할 것


전반적으로 이 세션은 개괄적인 구글 플레이의 가이드라인임과 동시에 향후 구글이 준비하거나 진행 중인 서비스/플랫폼에 대한 최신화 유지에 대한 의지를 약간 느낄 수 있었던 듯 합니다.


Session.2: 다시 한번 안드로이드 디자인 가이드라인 - +Chansuk Yang


이번 세션은 구글코리아 Dev Relation의 안드로이드 담당이신 양찬석님의 발표였습니다. 간단하게 정리하자면 구글에서 제공하는 안드로이드 디자인 가이드라인에 따라 앱과 플랫폼의 UX를 일관성있게 가져가자는게 주요 내용입니다. - 사이트에도 있는 내용이라 일부만 텍스트로 정리했습니다. :)

그리고 킷캣 관련 수정 사항에 대한 얘기가 좀 있었는데요. 기본적인 내용은 개발자 블로그를 참고하셔도 될 듯 합니다.

그 외에도 풀스크린 모드가 있었는데 제가 안드로이드 개발을 안해서 2가지 모드가 있는지도 모르고 살았네요. :(


  • Lean Back - 일반적인 비디오 관련 재생과 유사한 풀스크린 처리 모델
  • Immersive - 화면 밖으로부터의 스와이프 인/아웃을 통해 풀스크린 뷰를 제어하여 일반적인 터치에는 메뉴 화면 등으로 전환 등이 반응하지 않는 형태의 뷰입니다. 많이 사용할 것 같은 기능이더군요. 안드로이드 개발자분들은 어떻게 생각하시는지 조금 궁금하네요.


그외에는 안드로이드 디자인에 대한 내용이 있었는데 정리하면 네비게이션과 관련된 UI 및 액션들은 안드로이드 공식 지원 패키지를 사용하여 작업하고 알림(Notification) 바의 각 알림이 중첩될 경우는 하나의 알림에 업데이트하는 것 등에 대한 가이드가 있었습니다. 마지막은 정말 동의!!!! 하는 바이고 웹에서도 그렇습니다!!!! 제발 좀!!!! ;(

또, 반응형 디자인에 대한 얘기가 있었는데 간략하게 정리하자면 만드는게 좋고 이유는 태블릿이나 고해상도 단말에 대한 이슈이기도 합니다. Pitfalls에서도 같은 내용이 있었죠. 웹이라고 예외는 아니니 요즘 시대의 앱이나 서비스는 반응형이던 분리형 뷰를 다루던 디테일한 접근이 필요한 것은 사실입니다.


Session.3: Chrome WebView Essentials - +Alex Danilo 


킷캣에서부터 안드로이드 크롬 웹뷰는 많은 변화가 있었습니다. 가장 중요한 것 중의 하나는 크롬과의 코드 베이스를 공유하게 된 것이죠. 최신 웹 기술의 반영 속도가 이제 중요한 이슈 중의 하나인 것을 반증하는 것이기도 합니다. 다시 정리하면 안드로이드 웹뷰는 크로미움 30 버전의 스냅샷을 각 앱들이 사용하는 것이나 마찬가지이고 Chrome for Android 역시도 코드 베이스는 같습니다. (그렇다고 모든 기능이 똑같이 적용되지는 않습니다. 이쪽도 포팅과 검증은 필요하니까요.)



이미 많이 다뤄진 내용이기도 하고 안드로이드 공식 문서에서도 있던 내용들이라 간략하게만 살펴보자면 HTML5 지원 점수가 284점 > 424점으로 크게! 향상되었고 IndexDB, Web Socket, requestAnimationFrame, SVG Filters and effects, H/W 가속 그래픽스(Canvas 포함)들이 새로 지원되었습니다.

디버깅 인터페이스가 정리되서 웹뷰에서도 데스크탑 크롬의 "chrome://insepct"를 사용해서 원격 디버깅을 할 수 있습니다. 그리고 개발자도구가 완전하게 동작하는 이유는 데스크톱 크롬과 동일한 버전이라는 설명도요. 자세한 내용은 여기를 참조하세요. :)

Hybird Web App에 대한 언급도 있었는데 Look & Feel의 통일을 위해서 네이티브 컨트롤로 앱의 UI를 구성하고 실제 컨텐츠만 웹뷰를 통해서 사용하는 것도 좋은 방법이라는 얘기가 있었습니다. Cordova에서도 그런 시도들이 있었는데 실제로는 자바스크립트와 네이티브 클라이언트 개발이 둘 다 필요해서 팀 단위의 프로젝트에서 적용은 해볼만 할 것 같습니다. (개인적으로도 몇달 전에 그러한 형태로 적용한 프로젝트가 있는데 약간의 시나리오 구상은 필요합니다.)

그리고 모르던 내용이었는데 웹뷰가 하위 호환을 위한 기능을 지원하고 있습니다. - targetSDKVersion이 19 미만일 경우 호환모드로 동작하도록 되어 있다고 합니다.-

UA String이 Chrome 30.0.0.0으로 변경된 것은 알고 계실테고 멀티스레드 관련해서 웹뷰와 인터페이스를 사용할 경우 기본적으로 mainUIThread에서 웹 컨텐츠 연동 기능을 호출하는 것이 시스템의 흐름 상 옳은 방법이지만 멀티스레드가 필요할 경우는 runOnUiThread() 사용하라고 합니다. (이는 웹에서의 자바스크립트 로직이 메인 UI 스레드 상에서 동작하는 이유로도 옳은 방법으로 보입니다.)

커스텀 URL 핸들링은  RFC 3986 기반의 URL Scheme 지원하고 있고 많이들 활용하시니 따로 언급은 필요없을 것 같고 뷰포트 관련하여 target-densitydpi는 지원되지 않고 실제 화면이 작을 때만 줌인으로 동작되며 다중 뷰포트 메타 태그는 지원되지 않는 부분은 주의하셔야 합니다. 메타 태그의 뷰포트 관련한 내용은 한번 정리를 해봐야 할 것 같네요. 아! 그리고 기본 줌 엔진은 deprecated되었습니다

그리고 스타일링 관련하여 변경으로 인한 주의 사항이 좀 있는데 예를 들자면 background 축약 표현(Shorthand)은 긴 표현(Longhand)을 오버라이딩하므로 아래와 같이 사용해야 합니다.

// 'background' will reset 'background-size'
.some-class {
  background-size: contain;
  background: url('images/image.png') no-repeat;
}

// fixed
.some-class {
  background: url('images/image.png') no-repeat;
  background-size: contain;
}


뷰포트 내에서의 CSS에서의 픽셀 단위는 window.outerWidth와 window.outerHeight를 기준으로 동작합니다.

지금까지의 내용을 기준으로 간략하게 3가지의 사례를 보자면 다음과 같습니다.

  • targetSDKVersion
  • <application android:hardwareAccelerated="true">
  • WebView.setWebContentsDebuggingEnabled(true);


향후 계획과 관련하여 WebRTC가 마침내 다음 버전의 크롬 웹뷰에 탑재될 예정이라고 하고, WebGL은 안드로이드의 기존 렌더링 시스템과의 문제 해결을 진행 중이며  그리고 자동 업데이트에 대한 이슈들을 풀기 위해 많은 개발자들이 노력 중이하고 하네요.

개인적인 질의 사항으로 현재 크롬의 경우 CSS3 Animation 및 Transition 엔진이 이미 웹 애니메이션 규격의 네이티브 엔진으로 대체되었는데 이에 대한 Chrome for Android 및 WebView에서의 현재 현황과 계획에 대해 물었습니다.

답변을 정리하자면 아마도 다음 웹뷰에서 Web Animation Engine이 탑재될 것이고 올해 내에는 JS API도 만나볼 수 있지 않을까라고 하네요. 정말 그랬으면 좋겠습니다! :)


Session.4: Increasing user engagement in your apps with YouTube APIs - +Yoshifumi YAMAGUCHI


유튜브가 gData API 이외에도 많은 API를 제공하고 있는데 오늘 세션에서 주로 다뤄진 내용은 유튜브에 비디오를 생성할 수 있는 기능을 포커스하여 발표가 진행되었습니다.

> 유튜브 API를 통해 무엇을 얻을 수 있는가? 바이럴???


'왜 사용해야 하는가?'에 대한 얘기로 세션이 시작되었는데 나온 예 중의 하나를 들자면 90% 이상의 게이머들이 게임 트레일러 영상을 봤다고 합니다. -일주일에 7시간 이상 게임을 플레이하는 13~35세의 게이머를 대상으로 한 조사라서 대략 하드코어 유저군이긴 합니다만 트레일러가 중요한 홍보 수단 중의 하나이니 틀린 말은 아니라고 봅니다.-

> Youtube API


유튜브 API는 구독 위젯, 라이브 스트리밍 API 등으로 구성되어 있고 이 모든 기능을 합치면  YouTube와 기능 상으로는 동치 관계에 가깝다네요. APIs들은 재생과 관련된 Playback API 외에도 Upload, Explore, Live Stream, 채널/비디오, 사용자 동작 및 플레이리스트 등의 오프사이트 API와 채널, 커스텀 리포트, Metric과 관련된 분석 기능들이 제공됩니다.

> 개발자 생태계와 사례


개발자 생태계에 대해서는  정리하자면 어쨌던 사용자의 게임 플레이와 같은 동작에 대해 앱 내에서 직접 레코딩 후 유튜브로 업로드하는 방법을 통해 바이럴 커뮤니티를 만들어 낼 수 있다는 것이 핵심이라고 볼 수 있을 것 같고 github.com/youtube 에서 관련 라이브러리를 확인할 수 있습니다. 물론 OAuth2를 사용하여 인증하는 과정이 필요합니다. 개인적으로는 Builder를 통해 API Interface 객체를 만드는 과정은 맘에 쏙 들었습니다. :)

Elgato, XSplit 같은 제게는 생소한 게임과 서비스로 예제를 들었는데 잠깐 딴짓하느라 자세하게는 못들었습니다. 제가 https://code.google.com/p/youtube-direct-lite/를 기록해두었는데 일단은 샘플 데모입니다만 왜 여기에 적어두었는지 도저히 생각이 안나네요. ;;

> Youtube Streaming API


Youtube Streaming API에 대한 이야기도 있었는데 자세한 내용은 개발자 사이트를 참조하시고 간단하게 다음 3가지의 요소로 구성되어 있는데 Boradcast가 일종의 중계 센터가 되는 개념이고 bind()를 통해 각 Peer가 스트리밍 데이터 연결되며 insert()를 통해 스트리밍 송신 채널 생성할 수 있도록 하는 개념을 가지고 있다고 보시면 되겠습니다.

> 한글 개발자 문서와 질의


아 그리고 얼마전에 YouTube 개발자 센터의 한글 문서가 오픈되었는데 아직 전부가 번역된 것은 아니지만 퀄리티가 좋더군요. 관심있으시면 방문하셔서 한글로 언어 선택을 하고 보시면 되겠습니다.

질의 시간에는 "Make Less With NO Budget"이라는 문구로 혼동이 있어 질의가 갔는데 결론적으로는 "Write Less Do More"와 비슷하게 비디오를 만들어 올리는데는 약간의 노력만 있으면 되고 실제 공유에 관련된 API 사용에 대한 어떠한 비용도 청구되지 않는다는 뜻이라고 합니다. 그리고 개인화된 미디어를 유튜브에 업로드하는 경우에 대한 질의가 있었는데 기본적으로 유튜브가 비디오 공유 서비스이므로 같은 API를 가진 개인화 서비스인 드라이브 API를 추천한다는 것으로 발표가 마무리 되었습니다.


Session.5: 크롬캐스트와 구글 캐스트 - +Mickey Kim+Chansuk Yang 


작년에 크롬캐스트에 대해 많은 관심들이 있었는데 이번에 +Mickey Kim님이 세션에서 이에 대한 소개를 하고 +Chansuk Yang님이 다시 등장해서 개발 환경을 살펴보는 시간을 가졌습니다.  일단 구글 TV는 이제 별도로 사용하지 않고 안드로이드 플랫폼으로 통합 운영되게 되었고 랩탑이나 안드로이드 디바이스로부터 스크린 캐스트가 가능한 서비스 형태로 제공됩니다. Android, iOS, ChromeApps  API가 개발 환경으로 배포된 상태이고 자세한 내용은 개발자 사이트에서 참조할 수 있습니다. 국내 출시 예정에 대한 질의가 있었는데 올해 출시를 목표로 준비 중이라네요. 나머지 질문은 개발자 사이트에서 확인할 수 있는 내용이라 생략합니다. :)

#

마지막 세션은 제가 GDG Seoul에서 발표가 있어서 못듣고 미리 나왔네요. 기념품이 노트북 파우치라는 소식을 전해듣고 땅을 칠 뻔 했지만 대신 커뮤니티에서 즐거운 시간을 가진 하루였습니다. ㅎㅎㅎ

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는 완전하고 스크립트와 디버깅이 가능한 네트워크 요청을 제어할 수 있도록 합니다.
    • 만약 오프라인 기능을 가지고 있다면 컨텐츠 표시 전에 실패한 네트워크를 기다리지 않고 보여줄 수 있습니다.

    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월 16일 월요일

    [업데이트] 안드로이드 버전 32부터 300ms 탭 딜레이 제거 가능!

    전통적으로 모바일 브라우저는 PC의 그것과는 조금 다른 300ms의 클릭 딜레이를 가져왔습니다. PC의 경우 주로 마우스를 사용하였으므로 사실 클릭의 딜레이는 시스템에 따라 더블클릭을 구분하기 위한 시간차 정도였거나 없는 경우가 대다수였습니다만 터치를 기반으로 하는 모바일 디바이스의 경우 사용자의 탭 제스쳐 자체가 이후의 많은 연결 동작(예를 들어 스크롤, 핀치 줌 등)과의 이슈가 존재했습니다.



    이러한 300ms의 딜레이가 모바일 디바이스에서 웹 사용자들에게 미묘하고 지속적으로 늦은 반응을 인식하게 만든 장본인이기도 합니다. 아무튼 시스템이 다음 동작을 판별하기 위한 일반적인 시간 딜레이값이 300ms 였습니다만 사용자가 핀치 줌 제스처를 이용하는 것을 비활성화함으로써 Chrome For Android Version 32부터 이를 제거할 수 있습니다.


    간략하게 정리하면 다음과 같은 선결 조건이 있습니다.

    • Chrome For Android version 32 이상 혹은 Firefox for Android
    • 다음과 같이 메타 태그를 통해 핀치 줌(Pinch Zoom) 제스처를 사용하는 사용자 스케일을 막을 것

    <meta name="viewport" content="width=device-width, user-scalable=no">

    참조링크


    "마이크로소프트에서 제안했던 Pointer 이벤트(터치와 마우스를 동시에 지원하는 이벤트 규격)에 브라우저 벤더들이 동의를 하는 것 같은데 표준안 처리 이전에라도 빠르게 다른 브라우저에서도 구현되었으면 좋겠네요."

    2013년 11월 19일 화요일

    [소식/Summit] Chrome Dev Summit 세션 소개 요약

    귀국 후 첫포스팅이네요. 역시 인터넷은 한국이 빠릅니다. :+1:

    내일부터 모레(20일부터 21일)까지 크롬 개발자 서밋(Chrome Dev. Summit)이 있습니다. 온라인으로 라이브도 진행한다고 합니다. Linus Upson, 크롬 엔지니어링 부사장의 Keynote 발표로 시작하여 성능 최적화(클라이언트와 네트워크 부분)부터 보안, 블링크, 폴리머까지 다양한 부분을 다루니 이에 대해서 요약해보는 것도 좋을 것 같습니다. 아래 링크 참조하시기 바랍니다.



    주요 세션


    #perfmatters: Optimizing network performance - +Ilya Grigorik

    웹 사이트의 주요 병목 지점에 대한 네트워크 지연 사항에 대한 해결을 위해 어떠한 흐름으로 네트워크 성능을 수집하고 빠른 사이트로 변경할 수 있는지에 대해 설명합니다. (O'Reilly의 네트워크 성능 최적화 책도 있죠.)

    Network connectivity: optional +Jake Archibald 

    ApplicationCache를 이용하여 Offline 처리를 해왔는데 ServiceWorker API를 이용하여 Offline 어플리케이션 데이터를 어떻게 관리할 수 있는지 설명합니다. 당장은 넓게 적용할 수는 없는 규격이지만 ServiceWorker는 저도 이번에 TPAC2013 가서 처음 듣고 찾아보았는데 복잡하니 설명을 들어두는 것도 좋을 것 같습니다. Jake Archibald는 프리젠테이션 테크닉도 화려해서 기대하고 있습니다. :)

    #perfmatters: 60fps layout and rendering +Tom Wiltzius+Nat Duca 

    스크롤, 애니메이션, 터치 등의 최적화에 대한 몇가지 구축 방안과 크롬 개발자 도구를 이용한 성능 최적화의 방법에 대해서 설명합니다. 최근에 렌더링 성능 최적화 관련해서 몇가지 글에 대한 번역 소식을 전해 드린바 있는데 전반적인 정리가 필요하신 분들은 이 세션에서 한번에 들어보시는 것도 좋을 것 같습니다.

    Dart for the modern web developer +Kasper Lund+Seth Ladd 

    구글에서 이번에 Dart 1.0을 공식으로 릴리즈했습니다. 생소한 언어와 환경이니만큼 어떻게 이를 이용해서 웹 개발에 적용할 수 있는지와 자바스크립트와의 연동/변환 방법에 대해서 설명합니다.

    Chrome DevTools for Mobile +Paul Irish 

    크롬 개발자 도구를 이용하여 어떻게 모바일 웹을 개발할 수 있는지에 대해 전반적인 설명을 합니다. ScreenCast, Port Forwarding 등 개발자 도구의 크롬 모바일 지원 사항 관련해서는 지난번 Chrome Dev. Day 요약에서 살짝 설명드린바 있습니다.

    Optimizing your workflow for a cross-device world +Matt Gaunt 

    웹앱에서 멀티 디바이스/플랫폼 등에 대해 어떠한 방식으로 이들에 대한 검증을 할 수 있는지 테스팅 관련하여 설명을 한다고 하네요. 금번에 HTML5Rocks에서도 해당 튜토리얼이 올라올 예정이니 한번 보시고 튜토리얼을 읽어 보시는 것도 좋을 듯 하네요. :)

    Polymer: declarative, encapsulated, and reusable components for the web +Eric Bidelman 

    웹 컴포넌트에 대해서는 여러가지로 설명드린바 있고 이에 대한 튜토리얼들 역시 포스팅(Yeoman, Custom Element)한 바 있는데 웹 컴포넌트를 기존 모던 웹 브라우저에서 지원하기 위한 Polymer에 대해서 설명합니다. 최근에 핫한 오픈소스 프로젝트 중의 하나인데 미리 살펴보시길 바랍니다.

    #perfmatters: Tooling techniques for the performance ninja +Colt McAnlis 

    Colt McAnlis는 최근에 Image CompressionText Compression(참고로 텍스트 압축은 아직 번역 전입니다.)에 대한 글을 HTML5Rocks에 올린 적이 있는데 크롬 개발자 도구를 이용한 성능 최적화 방법에 대해 설명한다고 하네요. 개발 도구 관련해서 어떠한 부분을 설명할지는 모르겠지만 아마 리소스 송수신에 대한 부분이 아닐까 싶긴하네요. :)

    Develop Chrome Apps on desktop/mobile, distribute and profit +Joe Marini 

    크롬 앱을 이용한 개발 및 보안 관련한 내용에 대해서 설명하고 4개의 데스크탑 OS, 2개의 모바일 OS 상에서 시연한다고 합니다. (크롬 앱의 경우 모바일에서는 아직 지원이 되지 않지만 Cordova 플러그인을 통해 이를 개발할 수 있는 내용은 설명 드린 바 있습니다.)

    Portable Native Client: How we Learned to Stop Compiling and Love the Translator +Molly Mackinlay+David Sehr 

    얼마 전에 PNaCl도 릴리즈되었는데 크롬 기반에서 네이티브 기술을 이용하여 어떻게 플랫폼 독립적인 네이티브 연동 어플리케이션을 만들 수 있는지에 대해서 설명합니다. (개인적으로 보안 및 실행 모델에 대해서는 달리 얘기되기는 하지만 개발 환경에 대해서는 좀 궁금한 부분입니다.)

    Got SSL? An overview of why you need it and how to do it right. +Parisa Tabriz 

    간단하게 요약하면 웹 어플리케이션이 어떻게 SSL에서 보호되고 어떻게 구현되는지에 대해서 설명합니다.

    Blink: Behind the scenes +Greg Simon+Eric Seidel 

    크롬 28버전부터 렌더링 엔진이 Blink로 변경되었고 이제 크롬 안드로이드 역시 이를 사용합니다. 현재 어떻게 블링크가 진행되고 있는지 실제 웹 개발자들이 블링크로 인해 개발 시에 변경되는 부분(지원되는 부분)들은 어떤 것이 있는지 살펴본답니다. 앞으로의 계획에 대해서도 언급이 있을 듯 하니 살펴봐두는 것이 좋을 것 같습니다.

    Build mobile apps with Chrome WebView +Matt Gaunt 

    하이브리드 웹 앱을 개발하시는 분들이 좀 관심이 있으실 듯 한데 Chrome Webview가 킷캣부터는 꽤 많이 바뀌었죠. 크롬 웹뷰를 이용한 UI 개발, HTML5 기능 사용, Native UI 등에 대해 설명합니다.

    Best UX patterns for mobile web apps +Paul Kinlan 

    모바일 디바이스에서 다양한 형태의 스크린 및 해상도 그리고 터치 등으로 인해 많은 인터랙션 방식들이 제안되고 활용되고 있는데 +Paul Kinlan이 이에 대한 구축 이슈들과 활용 가능한 도구에 대해서 설명합니다.

    Media APIs for the multi-platform web +Sam Dutton+Jan Linden 

    비디오, 오디오, WebRTC, 웹 오디오 등을 활용하는 멀티 디바이스 웹 어플리케이션의 구축에 대해서 설명하고 어떻게 성능을 최적화할 수 있는지 모바일에 이를 구현하기 위한 방법등을 설명합니다. (Sam Dutton은 최근에 WebRTC에 대한 튜토리얼을 작성한 바 있습니다.)

    #perfmatters: Instant mobile web apps +Bryan McQuade 

    모바일 사용자들에게 쾌적한 환경을 제공하기 위한 렌더링 최적화를 위한 모바일 웹의 좋은 패턴과 안티 패턴들을 소개하고 성능에 치명적인 CSS와 HTML 문서 내에서 인라인 CSS의 장단점 등에 대해 소개합니다. (관심 가는 세션 중의 하나네요.)

    Multi-device accessibility +Alice Boxhall

    (장애인을 포함하여) 다양한 사용자에게 모던 웹사이트를 제공하기 위해 제공 및 사용할 수 있는 기술과 웹 기능, 크롬 기능을 설명하고 접근성과 디버깅에 관련된 몇가지 도구에 대해서 소개합니다. (해외에서의 웹 접근성에 대한 내용도 살펴보는 기회가 되겠네요.)



    요약만 정리해도 양이 엄청 많네요. 동시 진행되는 세션은 없지만 이틀내내 지켜볼 수는 없으니 가능하면 나눠서 정리가 되면 좋을텐데 안되면 며칠을 나눠서 봐야겠네요. :(