구글의 Chrome and HTML DevRel 팀에서 HTML5에 대한 좋은 자료들을 모아놓은 HTML5Rocks라는 새로운 포탈을 선보였습니다.

현재 이 사이트는 HTML5 자체에 대해 설명하는 여러 자료는 물론, 브라우저 지원확인해볼 수 있는 링크나 스크립트, 오래된라우저를 위한 HTML5 지원 스크립트 등을 포함합니다.

리소스 외에도, 멋진 HTML5 슬라이드 프리젠테이션과 바로 실험해볼 수 있는 코드 놀이터도 있습니다. 슬라이드는 이전에 APIRocks에서 선보였던 것과 동일합니다.

많은 양의 좋은 자료가 한 곳에 모여있습니다. 이제 막 선보인 점을 감안하면, 곧 더 많은 내용이 추가될 것이라 생각합니다.

from HTML5Rocks.com: Google DevRel shares the love
Posted by 행복한고니 트랙백 2 : 댓글 2

http://www.flickr.com/photos/florisla/1943594953/

WebM 프로젝트는 누구나 자유롭게 사용할 수 있는 고품질의 오픈된 웹 비디오 포맷을 개발합니다.
모질라, 구글, 오페라를 비롯한 40여개 이상의 컨텐츠 배포자, 소프트웨어 및 하드웨어 제작사들이 WebM을 지원합니다.
WebM은 웹을 위한 오픈 소스의 로열티가 없는 미디어 포맷입니다.
WebM은 파일 컨테이너 구조와 비디오, 오디오 포맷을 정의합니다. WebM 파일은 VP8 비디오 코덱을 사용한 압축된 비디오 스트림과 Vorbis 오디오 코덱을 사용한 압축된 오디오 스트림으로 구성됩니다. WebM 파일 구조는 Matroka 컨테이너를 기반으로 합니다.
구글이 I/O 에서 다수의 파트너들(브라우저에서는 오페라와 모질라가 참여)과 함께 새로운 WebM 프로젝트를 공개했습니다. WebM 프로젝트는 구글이 인수했던 On2의 코덱을 사용합니다. 이 발표는 개방형 비디오 전쟁에 있어 큰 뉴스이며, 이제 모두의 눈은 사파리로 향하게 되었습니다.

WebM 프로젝트는 다음과 같은 목표를 가지고 있습니다.
  • 개방과 혁신. 웹이 성공할 수 있었던 주요 요인은 HTML, HTTP, TCP/IP 와 같은 핵심 기술들이 누구나 구현하고 개선할 수 있도록 개방되어있다는 것이었습니다. 동영상이 웹 경험의 중심이 되어가면서 고품질의 개방된 비디오 포맷이 필요해졌습니다. WebM은 100% 무료인, BSD 유사 라이센스를 가진 오픈 소스 프로젝트입니다.
  • 웹에 최적화. 웹에서 동영상을 제공한다는 것은 전통적인 방송이나 오프라인 미디어와는 다릅니다. 현존하는 비디오 포맷들은 이러한 미디어들의 필요를 충족시키기 위해 고안되었고, 그 목적에 맞게 잘 동작합니다. WebM은 웹에서의 동영상 제공이라는 독특한 필요를 충족시키는 것에 집중했습니다.
    • 넷북, 모바일 장치, 타블렛 등의 어떤 장치에서도 재생할 수 있도록 적은 계산
    • 단순한 컨테이너 포맷
    • 최고 품질의 실시간 비디오 전송
    • 쉬운 인코딩. 최소한의 코덱 프로필과 부가 옵션. 가능하다면, 어려운 결정을 인코더에 위임
* 주의 : WebM을 지원하는 브라우저의 초기 개발자 버전은 아직 완전히 최적화되지 않았습니다. 따라서, 스크린 렌더링을 위해 정상적인 릴리스에 기대했던 것보다는 많은 계산을 요구합니다. WebM의 계산 효율성은 VP8 SDK의 개발자 도구를 통해 보다 정밀하게 측정할 수 있습니다. 브라우저에서의 최적화는 앞으로 이루어질 예정입니다.

개방형 웹에 축하를!

FlashIE9에서도 VP8 코덱을 지원하기로 했습니다. 당연하겠지만, 이제 모두의 관심은 애플의 사파리로 모이고 있습니다. :)

from WebM : The On2 codec is here, with support from Google, Mozilla, and Opera
Posted by 행복한고니 트랙백 1 : 댓글 0

CCL source from http://www.lightmatterphotography.com/


FireBreath 1.0 이 릴리스 되었습니다. 이게 뭘까요?
FireBreath는 크로스 플랫폼 플러그인 아키텍쳐로, 다음을 목표로 합니다.
  • NPAPI 브라우저 지원(윈도우, 맥, 리눅스):
    • Gecko/파이어폭스
    • 구글 크롬
    • Apple 사파리
  • ActiveX 콘트롤 호스트 :
    • Microsoft 인터넷 익스플로러 6, 7, 8
새로 작성한 플러그인에서 스크립트를 실행하고 다양한 기능을 더하거나 수정할 수 있습니다. Indexed DB와 같은 W3C API를 구현해보는 것도 재밌을 것 같습니다.

from FireBreath: Cross platform plugin framework
Posted by 행복한고니 트랙백 1 : 댓글 0
구글이 최근 획득한 특허에 따르면, 구글 스트리트 뷰에 광고가 포함될 듯 합니다. 구글이 2008년 7월에 출원한 이 특허는 온라인 지도에서 사용할 수 있는 광고 시스템에 관한 것입니다. 이 특허에서 구글은 건물, 포스터, 광고판을 인식하고 이들 대신 최신의 광고를 보여줄 보여줄 계획을 세웠습니다. 또한, 문제가 되지 않는 범위 내에서 광고를 경매할 계획도 가지고 있습니다.

구글이 제시한 사례를 보면, 극장 포스터를 새로운 정보로 대체합니다. 이 방법을 통해, 해당 극장은 스트리트 뷰의 이미지가 오래됐다해도, 극장의 포스터를 항상 최신 상영중인 작품으로 보여줄 수 있습니다.


(자세한 내용은 아래 링크에서 확인할 수 있습니다.)

Posted by 행복한고니 트랙백 0 : 댓글 1
구글 크롬에는 V8 디버거라는 자바스크립트 디버거도 있습니다만, 이번에 새롭게 크롬 개발툴 프로토콜(Chrome Dev Tools Protocol)이라는 것을 선보였습니다.
V8 디버거는 자바스크립트 디버깅만 할 수 있었고, 하나의 V8 가상 머신에서만 동작했었습니다. 사실 하나의 구글 크롬 인스턴스에는 렌더링 프로세스에 따라 한 개 이상의 V8 가상 머신이 존재할 수 있습니다. 게다가 브라우저 탭에서 URL을 가져오거나 DOM 트리를 탐색하고 수정하는 작업은 자바스크립트 만으로는 다룰 수 없습니다.
이러한 제약때문에 원격 디버거와 디버깅되는 프로세스간에 추가 정보를 주고받을 수 있는 크롬 개발툴 프로토콜을 만들었습니다. 크롬 개발툴 프로토콜은 현재의 V8 디버거 프로토콜을 비롯한 다른 디버깅 관련 프로토콜의 전송 수단으로도 사용할 수 있습니다.
이 프로토콜을 사용해서 만든 도구 중 하나가 바로 이클립스 기반의 디버거입니다.
원격 디버거에 대한 노력은 그 밖에도 많이 있습니다. 한가지 예로, 오페라 드래곤플라이의 디버깅 및 검사 아키텍쳐인 스코프 인터페이스를 들 수 있습니다. 파이어버그 역시 웹 디버그 프로토콜을 가지고 있으며, ActiveState 에서 사용하던 전통있는 DBGP도 있습니다.

from Google Chrome Eclipse Debugger

Posted by 행복한고니 트랙백 0 : 댓글 0
Chromium 프로젝트의 장점 중 하나는 구글 크롬에 어떤 기능이 추가될지 미리 알 수 있다는 것입니다. WebKit이 Safari 브라우저에 그러했듯이 말이죠.

SVN에서 Geasemonkey 비슷한 지원과 관련된 체크인을 발견할 수 있었습니다:
Greasemonkey 지원 약간 숨겨진 상태로 추가. --enable-greasemonkey 플래그 사용해야 가능.
구현은 방문한 링크 시스템의 패턴을 따름.
  • 직접 코딩된 스크립트 디렉토리 사용안함
  • 필요할 경우 스크립트 디렉토리를 감시하고 공유 메모리를 업데이트
  • 파일 IO를 백그라운드 쓰레드로 옮김
  • @include 패턴 지원 - 지금은 모든 스크립트가 모든 페이지에 적용
Committed

from Grease up your Chrome; Userscripts coming soon?
Posted by 행복한고니 트랙백 0 : 댓글 0
Microsoft의 Sameer Chabungbam씨가 아래 기능을 포함하고 있는 새로운 JScript 프로파일러에 대한 글을 작성하셨습니다:
  • JScript 함수의 성능 데이터를 두가지 방법으로 제공
    • 함수 View  - 모든 함수의 비계층적 목록
    • 호출 트리 View - 호출 흐름에 기반한 함수의 계층적 목록
  • 데이터를 파일로 내보내는 기능 지원
  • 익명 함수를 위해 추측된 이름 제공
  • 내장 JScript 함수 프로파일링
  • 다중 프로파일 보고서 지원
  • 페이지 탐색과 리프레시에 걸친 프로파일링 지원
사용자 삽입 이미지

한편 Eric Pascarello씨는 새로운 도구를 찾아  구글 크롬 디버거에 대한 자신의 경험을 글로 작성했습니다. 그는 다양한 명령어와 중단점 기능에 대해 상세히 기술했습니다.

from New Profilers and Debuggers in Google Chrome and IE
Posted by 행복한고니 트랙백 0 : 댓글 0

App Engine상에서 구동되는 작고 유용한 서비스들이 계속 나타나고 있습니다. 이번에는, Adam Burmister씨가 만든 img2json으로, 이미지 URL로부터 메타데이터를 추출하는 Google AppEngine 서비스입니다.

메타데이터에는 너비, 높이, MIME 타입, 파일크기처럼 단순한 정보뿐만 아니라 EXIF 정보(카메라 제조사, GPS 위치, 사진 방향 등등)등이 포함됩니다.

서비스를 사용하시려면 그냥 아래처럼 URL만 입력하시면 됩니다:

http://img2json.appspot.com/go/?callback=myCallbackMethod&url=http://assets.flog.co.nz/favicon.png

위 URL을 입력하면 다음과 같은 데이터를 얻을 수 있습니다.
myCallbackMethod({
    'url': 'http://assets.flog.co.nz/favicon.png',
    'mimeType': 'image/png',
    'width': 16,
    'height': 16,
    'byteSize': 524,
    'exif': {}
});

from img2json: get your image metadata via App Engine
Posted by 행복한고니 트랙백 0 : 댓글 0

검색엔진이 Flash 파일을 읽지 못하는 이유로, SEO(Search Engine Optimization:검색엔진최적화)와는 요원한 것으로 알려져왔습니다. 하지만, Google과 Adobe는 Flash 프로그램의 인덱싱을 개선하는 작업을 계속해왔었습니다. 예전에도 SWF 파일에서 문자열을 추출해내는 것은 본적이 있었지만 거기에는 컨텍스트가 없었죠.

좀 더 진행이 되어, Google이 Adobe의 검색가능한 SWF를 프로그램에서 보다 '인간스러운' 행동을 위해 사용하기로 했습니다.

한계는 이렇습니다:

  1. 구글봇은 몇몇 JavaScript를 실행할 수 없습니다. 그래서 웹 페이지가 JavaScript를 통해서 Flash를 읽어들인다면 Google은 Flash 파일을 인식하지 못할 수도 있고, 이 경우에는 인덱스가 되지도 않습니다.
  2. Flash 파일에서 HTML 파일, XML 파일, 다른 SWF 파일 등을 불러온다면, 현재로서는 Flash 파일에서 읽어들인 외부 리소스의 컨텐트는 덧붙일 수 없습니다. Google은 해당 리소스를 따로 인덱스할 것이지만,  하나의 Flash 파일의 일부라고 인식하지는 않습니다.
  3. 웹 상의 거의 모든 언어로 Flash를 인덱스 할 수 있지만, 현재로서는 양방향 언어로 작성된 플래시 컨텐트에는 어려움이 있습니다. 이것이 수정되기전까지는 Flash파일의 히브리어나 아랍어 컨텐트는 인덱스할 수 없습니다.

아마 모든 리치 응용프로그램에 좋은 소식이 아닐까 싶습니다. 검색 엔진이 발달함에 따라 리치한 프로그램을 작성하면서 하는 고민도 줄어가는 것 같습니다.

from SEO and RIA get closer together with Flash indexing news
Posted by 행복한고니 트랙백 0 : 댓글 0
Dion씨가 자신의 블로그에 쓴 글입니다.

최근 Dion씨는 주소록의 사례를 이용해 Form History 패턴 예제를 작성한 바 있습니다.

On Air tour에서 App Engine에 대해 말한 Dion씨는 예제를 바꾸기로 결정했습니다. Gear를 통해 데이터를 로컬에 저장하는 대신 App Engine을 이용해 원격지 cloud에 저장하기로 한 것입니다.
사용자 삽입 이미지
왜 사람들은 Adobe 컨퍼런스에서 App Engine에 대해서 듣고 싶어했을까요? Dion씨는 Jonathan Schwartz씨가 그 이유를 Rich Internet Backends에 대해서 말했을 때 알고 있었다고 생각합니다. 여러분은 리치 클라이언트를 작성하자마자, 이내 웹 서비스의 약속된 이점들이 이를 더 좋게 해준다는 깨닫게 될 것입니다.
사용자 삽입 이미지
예제로 돌아가보죠. 구조 변경은 아주 간단합니다. 로컬 DB에 저장하던 부분에서 작업에 의존하는 /loadcontacts/savecontact 와 같은 백엔드 서비스를 호출했습니다.

이 예제의 전체 App Engine 프로젝트 코드를 다운로드 받아서 보실 수도 있고 실제로 App Engine 위에서 실행되는 것을 보실 수도 있습니다.

코드가 동작하는 것을 보려면 다음의 비디오를 보세요. 또는 고화질 버전으로 보실 수도 있습니다(권장). App Engine이 제공하는 개발, 디버그, 응용프로그램 모니터링 등의 다양한 툴을 보실 수도 있습니다.

from Addressbook History goes into the cloud with App Engine
Posted by 행복한고니 트랙백 0 : 댓글 0
구글에서 몇가지 소식이 있습니다. 첫째는 Gears 0.3이 릴리스 되었다는 것입니다. Firefox3 를 지원합니다! Firefox 3 정식버전(6월 17일 예정)에 맞춰서 출시하려고 했다는군요. Gears와 같은 플러그인은 브라우저 내부에 깊이 다가갈 수 있으므로 베타판의 API 변경덕분에 날짜를 지키는 것이 큰 도전이었다고 합니다. 결국은 훌륭하게 수행해냈습니다.

Gears 0.3은 Firefox 3 지원 이외에도, 다음을 포함하고 있습니다:
그리고, Google I/O 세션들의 모든 동영상의 공개되었습니다.

Ajax와 Gears와 관련된 컨텐트들을 정리해두었습니다:

Gears

GWT

General Ajax



from Gears 0.3 Released, and Google I/O videos on Ajax related content available
Posted by 행복한고니 트랙백 0 : 댓글 0
이와 관련된 비슷한 이슈를 살펴보는 두 개의 글이 있습니다.

첫째, Google Analytics는 Pete Higgins씨가 살펴본 것과 같이 보통 응용프로그램이 멈춰 대기하게 되는 스크립트 태그를 사용합니다.

그래서 "google-anaytics.com 을 기다리는 중..." 과 같은 글을 보아왔었습니다.
이것은 보통 body 태그가 닫히기 전에 있어, Dojo의 addOnLoad 함수가 ga.js가 읽히고 실행되기 전까지 대기하도록 합니다. 저는 SitePen의 Dojo QuickStart 가이드에서 그것을 알게되었습니다. 모든 가이드는 유효한 HTML과 CSS 이고, 커스텀 탭 뷰와 간단한 네비게이션으로 주요 섹션을 구분하고 있습니다. 안타깝지만, 그런 역할을 하는 모든 코드는 addOnLoad 함수내에서 실행됩니다. 그래서, Tennesse의 제 비천한 인터넷 망은 ga.js가 읽히는데 5초 이상 걸리게 하더군요. 요컨데, 때때로 저는 탭이 추가되고 선택되지 않은 탭이 사라짐에 따라 화면이 짜증나게 흔들리며 렌더링되는 것을 경험합니다.

저는 script 태그를 head 엘리먼트에 추가하고 그 코드를 Google의 코드가 준비되는 것과는 상관없이 Dom 이 준비되자마자 남은 코드를 실행할 수 있도록 하면서 onLoad 에서 실행하는 것이 안전하리라 판단했습니다.
그는 코드를 보여주었습니다:
[code:js]
dojo.provide("dojox.analytics.ga");
dojo.mixin(dojox.analytics.ga, {
        // _acct: String
        //            your GA urchin tracker account numbers.
        _acct: dojo.config.urchin || "",
 
        // _loadInterval: Integer
        //           time in ms to wait between checking again
        _loadInterval: 420,
 
        _loadGA: function(){
                // summary: load the ga.js file and begin initialization process
                var gaHost = ("https:" == document.location.protocol) ? "https://ssl." : "http://www.";
                var s = dojo.doc.createElement('script');
                s.src = gaHost + "google-analytics.com/ga.js";
                dojo.doc.getElementsByTagName("head")[0].appendChild(s);
                setTimeout(dojo.hitch(this, "_checkGA"), this._loadInterval);
        },
 
        _checkGA: function(){
                // summary: sniff the global _gat variable Google defines.
                //           if it exists, run _gotGA, otherwise, do another interval
                setTimeout(dojo.hitch(this, window['_gat'] ? "_gotGA" : "_checkGA"), this._loadInterval);
        },
 
        _gotGA: function(){
                // summary: initialize the tracker, we've got ga.js loaded
                var ga = this._tracker = dojo.hitch(_gat, "_getTracker", this._acct)();
                ga._initData();
                ga._trackPageview();
                this.GAonLoad.apply(this, arguments);
        },
 
        GAonLoad: function(){
                // stub function to fire when urchin is complete
                // you also have access in this function to this._tracker, which is the
                // root tracker instance you called _initData() on
        }
 
});
 
// start it all up after body is ready:
dojo.addOnLoad(dojox.analytics.ga,"_loadGA");
이것은 Dojo 에서 곧 제공될 예정입니다, 그러면 이렇게 사용하실 수 있게 됩니다:
[code:js]
var pagetracker = new dojox.analytics.Urchin({ ua: "UA-123456-7" });
pagetracker.trackPageView("/ajaxy-notification");

둘째, Weston Ruter씨는 인라인 script 태그에 document.write()를 사용하는 Google AdSense와 AJAX 라이브러리 API를 같이 사용할 때 일어나는 다른 문제를 알려주셨습니다. 예전에 John Resig 씨가 document.write 대신 DOM 작업을 하는 작은 래퍼를 작성하신 적이 있습니다. Weston 씨는 그것에 기초하여 작성했습니다.

전체 코드를 확인해보세요.

from Google Anaytics after onLoad and document.write for XHTML
Posted by 행복한고니 트랙백 0 : 댓글 0

Gears, 첫 돌을 맞다

2008.06.06 13:55 from [IT] Web Tech
Chris Prince 씨가 Gears가 첫 돌을 맞았다는 글을 작성하셨습니다. 지난해 Google Developer Day에서 런칭되었었는데, 1년뒤 Google I/O에 있게 되었습니다.

어제 Gears와 관련된 몇 개의 재밌는 소식이 있었습니다. 첫째는, MySpace가 Gears를 이용해 사용자들이 MySpace 메시지를 검색할 수 있도록 했다는 것입니다.

이것은 "오프라인"만을 뜻하는 것이 아닌 Gears의 또 다른 사용법입니다. 사실, Chris Prince씨는 어제 사람들이 찾아볼 Gears의 프로토타입과 예제들을 보여주었습니다. 거기에는 아래와 같은 흥미있는 것들이 있었습니다:
  • 멀티파일 업로드: File System API를 사용해서, Chirs씨가 멀티파일 업로드를 시연했습니다. 여러개의 파일을 선택하면, 끝입니다!
  • 파일업로드 이어하기: 그는 그 뒤 YouTube 예제를 보여주었습니다. 이 예제는 다중 파일 업로드와 업로드 상태 보기를 포함하고 있으며, 또한 Blog API와 HttpRequest를 기반으로 작성된 ResumableRequest를 이용해 접속이 끊긴 후 파일 업로드를 재개해 0% 부터 시작하지 않는 예제를 보여주었습니다.
  • 주변지역을 찾아보세요! 다음 데모에서 Chris 씨가 맥주 마실 곳을 찾았고, 결과로 Moscone Center 주변의 장소가 나왔습니다. 이 예제는 여러분의 위치를 알기 위해 GPS, Wifi IDs, Cell IDs, IP 주소를 사용하는 Geolocation API를 사용했습니다.
  • 알림기능: Windows 토스터나 Mac의 Growl을 좋아하세요? Chris씨가 알림기능의 예를 보여주셨습니다
사용자 삽입 이미지

from Gears turns one; Old enough to power MySpace message search on Ajaxian
Posted by 행복한고니 트랙백 0 : 댓글 0
GWT 1.5 의 RC 버전이 출시되었습니다. 1.5 릴리스는 Java 5 지원을 비롯 변화가 많은 것 같습니다.
GWT의 이전 릴리스부터, 우리는 여러분이 사용자에게 집중하고 여러 브라우저의 괴상함과 다른 Ajax의 장애물들에 대한 상당한 걱정을 멈추는 것이 가능하다는 것을 보여준 많은 양의 정말 훌륭한 응용프로그램들을 보아왔습니다. 우리가 본 것들에 고무되어, 우리는 개발자들이 사용자들이 즐길 웹 응용프로그램을 작성하는데 자신들이 기존에 사용하던 도구를 사용하도록 하려는 작업에 계속 집중했습니다. GWT 1.5에는 이러한 노력이 포함되어있으며, 더 나아가 새로운 기능과 150개가 넘는 버그 수정도 들어있습니다. 그리고, 모든 GWT 릴리스들과 마찬가지로, 으뜸가는 이점은 업그레이드하고 재컴파일만 하면 되는 것입니다.
Dion씨가 잠시 사용해본 바로는 꽤 재밌다고 합니다. 주요 기능은 어떤 것이 있을까요?

새로운 컴파일러 최적화로 성능 개선
이번 릴리스를 통해 개발자가 직접 짜는 코드보다 GWT의 컴파일러가 생성하는 코드가 더 빠르다고 합니다. 어떻게 그게 가능할까요?  새 컴파일러의 여러 최적화를 통해 효율적인 인라인 메소드 호출이 심지어 직접적이지 않는 방법을 통해서도 가능해졌습니다. 다시 말하자면, 거대한 코드 기반을 유지하기 위해 필수적인 훌륭한 추상화와 명확한 설계가 컴파일 결과물에 고스란히 녹아있으며, 동시에 사용자들은 가능한 가장 빠른 응용프로그램을 경험할 수 있습니다. 반면에, 여러분이 직접 JavaScript를 작성한다면, 좋은 코드와 빠른 코드 중에서 선택을 해야할 것입니다. 그리고, 응용프로그램이 일정 규모가 되면 유지보수성 때문에 두번째 안(빠른 코드)을 선택할 수는 없게될 것입니다. GWT 1.5를 이용하면, 타협하지 않아도 됩니다; 그냥 좋은 코드를 작성하면 컴파일러가 그것을 빠른 코드로 바꿔줍니다.

JavaScript Overlay Types
이것은 GWT의 JavaScript 기반 레이어와의 상호운용성을 개선합니다. “Overlay type”은 우리가 추가적인 런타임 비용없이 스트롱 타입인 Java 인스턴스로서의 JavaScript 객체를 만드는 능력을 기술하는데 사용하는 새 용어입니다. Overlay type은 직접 작성한 JavaScript 라이브러리와의 소단위(fine-grained) 상호운용성 제공을 용이하게 할 뿐만 아니라, JSON 구조체가 GWT 코드에 직접 접근할 수 있게 하는 최적화된 방법을 제공합니다.

고성능 DOM API
GWT 1.5 까지, 우리는 위젯 레벨의 API에 거의 집중해왔고, overlay type(윗글 참고)이 나타나기 전까지, 직접적인 DOM 프로그래밍은 특별히 편리하진 않았습니다. GWT 1.5는 완전히 새로운 DOM API로 "편리함"을 넘어 "세련됨"으로 가고 있습니다. 이 새로운 DOM API는 DOM 전문가들의 편리함과 런타임 부하로부터의 자유를 주는 타입 안정적인 저수준 DOM 프로그래밍을 가능하게 합니다.

기본 시각 테마
몇 개의 기본 시각 테마가 기본적으로 가능해져서, 개발자들은 박스를 벗어난 매력적인 UI를 가지게 되었고, CSS로 자신들의 커스텀 스타일을 작성하는데 있어 좋은 출발점을 가지게 되었습니다.

Google I/O에서 가까운 미래의 온라인을 보여주는 멋진 대화를 보았습니다(이에 대해서는 곧 포스팅할 예정이라고 합니다). 지금은 1.5 버전을 한번 써보세요.

from GWT 1.5 Release Candidate Announced on Ajaxian
Posted by 행복한고니 트랙백 0 : 댓글 0
사용자 삽입 이미지
워드프레스 팀에서 어마어마한 작업을 하고 있다고 합니다. 이미 꽤 진행이 된 것 같은데, Google Gears를 이용해서 워드프레스가 오프라인에서도 동작하도록 하고 있답니다.

James 씨의 글에 따르면 이와 같은 Gears 지원이 몇몇 기쁜 선물을 가져다 줄 것이라고 합니다. 예를 들면, 남아프리카처럼 속도가 좋지 않은 곳에서는 상당한 속도 향상 효과를 볼 수 있다는 것이 그의 주장입니다(우리나라 상황과는 별 상관없겠네요.. 남아프리카라니...).

Dion씨는 이 같은 움직임에 대해서 Gears팀을 자랑스러워하는 한편, Gears가 오프라인만이 아닌 그 이상이라고 말했습니다. Gears는 웹 개발 모델의 간극을 채우기 위해 노력 중이고, HTML5 기능을 브라우저에서 사용할 수 있도록 하고 있다고 합니다. 그 외에도 재밌는 요소는 많죠. 내장 데이터베이스, 로컬 서버 스토리지, 데스크톱 API 등등.

뭐... 여하튼 재밌는 소식이네요. 국내에선 어디서 가장 먼저 Gears를 도입하게 될지 기대됩니다.

from Speed Up! with Wordpress and Gears on Ajaxian
Posted by 행복한고니 트랙백 0 : 댓글 0
Google에서 또 일을 저지른 것 같습니다(물론, 좋은 의미입니다). 간단히 본문을 요약하자면, Prototype, jQuery등의 주요 Ajax 프레임웍을 자기네들이 호스팅해서 전세계 개발자들에게 제공하겠다는 것입니다.

버전관리, 버그패치, 트래픽 다 감당하겠다는 거죠. 심지어 오래된 버전까지 그냥 끌어다 쓸 수 있으니 속도만 보장된다면(본문에는 세계 전역에 분포된 CDN을 사용하므로 빠를 것이라고는 합니다만..), 정말 간편하게 사용할 수 있을 것 같습니다. 아직 관련 소식을 다른 곳에선 들은 적이 없네요. 제가 보기엔 꽤 큰 사건임에 분명해보이는데요. :)
사용자 삽입 이미지
________________
Google에서 Prototype, Script.aculo.us, jQuery, Dojo, MooTools와 같은 유명 프레임웍들을 사용하는 Ajax 응용프로그램을 만들 수 있는 Google AJAX Libraries API발표했습니다.

응용프로그램을 작성할 때마다 매번 파일을 다운로드 받아서 설치하기를 반복하실텐데요, 글을 쓴 Dion씨는 무려 자신의 응용프로그램에서 33개의 prototype.js 복사본을 사용하고 있다고 합니다. 사이트가 달라질 때마다 매번 다운로드 받게 되는거죠. 얼마나 큰 낭비입니까!

또한, Steve Souder씨는 성능면에서 우리가 이러한 라이브러리를 제공함에 있어 얼마나 잘못하고 있는지 지적한 바 있습니다. 개발자로서 우리는 캐싱을 정확하게 해서 파일이 필요할 때만 다운로드되도록 해야합니다. 또한 gzip 압축이 가능한 브라우저라면 압축 전송을 해야합니다. 아, 조금이라도 용량을 줄이기 위해 최소화 버전도 사용해야 할 것입니다. 파일의 버전 관리도 제대로 해야죠. 아니면, 수없이 많은, 때론 파일 끝에 조금씩 입맛에 맞게 수정을 가한, 버전이 없는 jquery.js 파일을 발견하고, 캐시는 전혀 제대로 설정되어있지 않아 아무런 이유도 없이 파일을 항상 전송할 겁니다.

Dion씨는 Google에 입사해서 이런 것들을 도울 수 있을 것 같다고 생각했다고 합니다. 우리가 이런 파일들을 호스팅하면 어떨까? 모든 사람이 바로 이런 혜택을 받게 되었겠죠:
  • 제대로 된 캐싱, Google이 한번만 작업하면 개발자들이 할 일은 아무것도 없음
  • Gzip 압축
  • 최소화 버전 제공
  • Google에 의해 호스팅되는 파일들은 세계 전역에 걸쳐있는 분산 CDN에서 제공되므로, 파일은 사용자들에게 "근접"해있음.
  • 서버가 빠름
  • 똑같은 URL을 사용하므로, 응용프로그램의 상당 부분이 Google의 인프라를 사용한다면, 누군가 여러분의 응용프로그램에 접근할 때 그 파일은 이미 로딩되어있을 것!
  • 여러분이 보내고 받는 헤더와 관련된 미묘한 성능(그리고 보안) 문제 해결. 특정 도메인을 사용하고 있으므로(주의: google.com은 아닙니다!), 쿠키나 다른 쓸데없는 헤더가 전송되지 않으므로 귀중한 트래픽 절약
이게 Google이 AJAX Libraries API를 출시한 이유입니다. 몇 개의 유명 오픈소스 프레임웍 진영과 대화한 결과 그들은 모두 이 아이디어를 흥미로워했습니다. 그래서 그들과 이 작업을 시작했으며, 이제 여러분은 Google의 서버에서 그들의 훌륭한 작업물에 접근할 수 있습니다.

세부사항

라이브러리에는 두 가지 방법으로 접근할 수 있고, 둘 다 라이브러리를 호스팅하는 고통 - 정확하게는 캐시 헤더를 설정하고 최근 버그 패치들을 적용하도록 꾸준히 업데이트 하는 일 등 - 을 덜어주는 방법입니다.

첫번째 방법은 간단하게 표준 <script src="..."> 태그를 이용해서 스크립트에 접근하는 방법입니다.

예를 들면, Prototype 1.6.0.2 버전을 읽어들이려면 HTML에 아래와 같은 코드를 입력하면 됩니다.
[code:js]
<script src="http://ajax.googleapis.com/ajax/libs/prototype/1.6.0.2/prototype.js"></script>
두번째 방법은 Google AJAX API 로더의 google.load() 메소드를 이용하는 것입니다.

아래는 간단한 검색 매시업을 위해 jQuery를 읽고 사용하는데에 해당 기술을 사용한 예제입니다.
[code:js]
<script src="http://www.google.com/jsapi"></script>
<script>
  // Load jQuery
  google.load("jquery", "1");
 
  // on page load complete, fire off a jQuery json-p query
  // against Google web search
  google.setOnLoadCallback(function() {
    $.getJSON("http://ajax.googleapis.com/ajax/services/search/web?q=google&;v=1.0&;callback=?",
 
      // on search completion, process the results
      function (data) {
        if (data.responseDate.results &&
            data.responseDate.results.length>0) {
          renderResults(data.responseDate.results);
        }
      });
    });
</script>
아마 사용한 버전이 그냥 "1"라는 것을 알아차리셨을 것입니다. 이는 스마트 버저닝 기능으로, 여러분의 응용프로그램에서 필요한 앞자리만 지정할 수 있도록 하고 있습니다. 버전 필드를 입력하지 않음으로써, 필드에 와일드 카드를 사용한 것입니다. 간단히, 이런 버전들을 생각해보세요: 1.9.1, 1.8.4, 1.9.2

"1.8.2"라는 버전을 지정하면 정확한 버전이 선택됩니다. 이는 사용할 버전 전체를 지정했기 때문입니다. "1.8"과 같이 버전을 지정하면 1.8 브랜치에서 가장 높은 릴리스 버전인 1.8.4 가 선택됩니다. 같은 이유로, "1"을 요청하면, 실제로 읽히는 버전은 "1.9.1" 입니다.

아셔야 할 것은 이러한 버전관리 시맨틱이 google.load를 사용할 때와 직접 script url을 사용할 때 똑같은 방식으로 작동한다는 것입니다.

기본적으로, 로더가 되돌려주는 JavaScript는, 지원되는 버전이 있다면, 최소화 되어있습니다. 그러므로, 위의 예제는 jQuery의 최소화된 버전을 반환할 것입니다. 만약 최소화 되지 않은 JavaScript 파일을 원하신다면 "uncompress" 파라미터를 추가하시면 됩니다.
[code:js]
google.load("jquery", "1.2", {uncompressed:true});
오늘은 라이브러리들의 현재 버전으로 시작하지만, 앞으로는 현재부터의 모든 버전을 제공하겠다고 합니다.

현재 지원하는 라이브러리의 전체 목록은, 문서 부분을 보시기 바랍니다.

Dion씨가 자신들이 작업한 것에 대해 두 장의 짧은 슬라이드를 보여주셨습니다.


미래

이것은 단지 시작일 뿐입니다. Google에서는 유용하게 사용할 수 있도록 보다 많은 라이브러리들을 추가하려고 합니다. 또한, 약간의 관심만 있으시면 어떻게 이들이 더 나아갈 수 있는지 아시게 될 것입니다.

이것이 잘 사용되면 다음번에는 이러한 라이브러리들을 자동으로 읽어들일 수 있도록 브라우저 벤더들과 작업할 것이라고 합니다. 그러면, 해당 URL에 접근했을 때, 자동으로 라이브러리를 읽어들일 수 있게 됩니다. 심지어는 로컬에 있는 특별한 JIT된 것까지도요. 그러므로, 네트웍은 전혀 사용하지 않게 되죠! 또한, 브라우저는 이 서비스가 가능한 IP 주소를 가지고 있을 수 있어 DNS 탐색도 하지 않게됩니다. 오래 유지되는 JavaScript 라이브러리를 위한 브라우저 캐시도 이런 URL을 사용합니다.

이러한 것들이 일어난다면 웹 개발자들에게는 어떤 의미일까요? 항상 표준 라이브러리를 다시 다운로드받아야 했던 늘상 있어왔던 부담에서 벗어날 수 있습니다. 다른 어떤 플랫폼에서 이런 것이 가능했을까요? Java 응용프로그램을 실행할 때마다 매번 JRE를 다운로드 받아야 한다고 생각해보세요! 만약 그런 부담을 덜 수 있다면, 필요한 기능을 만드는데 보다 많은 시간을 투자할 수 있고, 실제 다운로드 크기에 대해서 고민할 시간은 줄일 수 있습니다.

감사의 말씀
(이 부분은 번역 생략하겠습니다. ^^;;)

from Announcing AJAX Libraries API: Speed up your Ajax apps with Google's infrastructure on Ajaxian
Posted by 행복한고니 트랙백 5 : 댓글 4

Doctype에 대해서 또 다른 글이 올라왔습니다. Dion씨는 이 프로젝트에 대해서 꽤 흥분하고 있는 듯 보입니다.

Doctype에는 주장을 뒷받침 하기위한 여러 테스트들이 있습니다. 별로 생각하지 않아도 될만큼 간단합니다. 테스트들은 총체적으로 보여집니다만, 테스트는 Google Code 프로젝트에 있으므로 직접 접근하실 수도 있습니다.

document 테스트를 한번 살펴보세요, 그러면 Mark씨가 우리에게 튼튼한 기반을 제공하기 위해 이 일에 얼마나 많은 작업을 했는지 알게 될 것입니다.

또한 테스트가 goog.* 라는 JavaScript 라이브러리들을 사용하고 있는 것을 알 수 있습니다.

Simon Willison씨가 이미 다음과 같이 몇가지 재밌는 점을 발견하셨습니다:

Goog 라이브러리는사용자 환경에 설치된 iPhoto의 버전을 찾아내는 코드를 포함합니다. 그 코드는 Mac.com의 Gallery RSS 피드를 리버스 엔지니어링한 것을 기반으로 합니다.

수많은 훌륭한 코드들이 있습니다. 아무거나 한 번 시도해보세요. 그리고 알아낸 것을 알려주세요!

from Doctype: You want tests with your copy? on Ajaxian
Posted by 행복한고니 트랙백 0 : 댓글 0

Mark Pilgrim씨가 오픈 백과사전이자 레퍼런스 라이브러리인 Google Doctype을 릴리스했습니다. 웹 개발자들에 의해, 웹 개발자들을 위해 쓰여지는 이 문서들은 웹 보안, JavaScript DOM 다루기, CSS 팁과 트릭 등에 대해서 다루고 있습니다.

레퍼런스 부분에는 크로스 브라우저와 크로스 플랫폼 호환성을 확인하기 위한 계속 추가되는 테스트 케이스 라이브러리도 있습니다.

이것은 오픈소스이자 오픈 라이센스(Creativce Commons)를 표방하는 야심찬 프로젝트의 시작일뿐입니다. 개발자들이라면 참여해서 이 문서를 성장시키는 가치 있는 데이터를 추가하는 것도 좋을 것 같습니다.

Dion씨가 Mark씨를 만났던 모양입니다. 이 프로젝트에 대한 Mark씨의 말씀을 들어보세요:


from Google Doctype: Documenting the Open Web on Ajaxian
Posted by 행복한고니 트랙백 0 : 댓글 0

오늘은 GWT팀의 Bruce Johnson씨와 GWT 1.5에 대한 얘기를 나누어보았습니다. 그는 오래 기다려왔던 Java 5 에 대한 지원, 성능 개선 등과 같은 새로운 기능에 대해서 얘기했습니다.

응용프로그램을 새로운 GWT 1.5 컴파일러를 통해서 실행하고 "공짜"로 더 빨리 동작하는 응용프로그램을 얻을 수 있으니 아주 좋습니다.

Ajax Pioneer: Bruce Johnson of GWT from Dion Almaer on Vimeo.

다른 인터뷰들...

from Ajax Pioneer Week: Bruce Johnson of GWT on Ajaxian
Posted by 행복한고니 트랙백 0 : 댓글 0

오는 5월 28-29일에 걸쳐 구글의 연중 이벤트 중 최대 행사인 Google I/O라는 행사가 있다고 합니다. 글 쓰신 Dion씨와 Ben씨는 Ajax와 JavaScript 트랙에 참여하시고, 아울러 이 트랙에는 GWT 팀의 Bruce Johnson, AJAX API 팀의 Mark Lucovsky, Dojo의 Alex Russell 등 쟁쟁하신 분들이 참여한다고 합니다. API, Social, 지도, 모바일 등을 다루는 다른 트랙들도 있고요.

Ajaxian 커뮤니티가 참여했으면 좋을 것 같아 문의해봤더니 10개의 티켓을 받았다고 합니다. 메일이나 Twitter를 이용해 신청해달라고 하는데, 국내에선 아무래도 무리겠죠? ^^;;

끝으로, 콩코드의 비행(Flight of the Conchords)라는 분들이 이 행사에서 공연을 하나본데, 원래 있는 가수인지 아니면 구글 내부의 동호회인지는 모르겠습니다. 동영상을 보면 아시겠지만 아마도 노래 제목이 It's Business Time 인 것 같군요.



from It’s Business Time: Free Passes to Google I/O on Ajaxian
Posted by 행복한고니 트랙백 0 : 댓글 0

티스토리 툴바