Rhio.Kim's Blog - drawing Laputa Web -

CRUD(create read update delete) Pattern정의

이번 패턴을 정리하면서 어떤 이름을 지어볼까 매우 고민 스러웠습니다.
마땅한 이름도 생각이 나질 않고...

CRUD pattern 이라고 명명 했지만 처음 이름은 XHR pattern 이였는데..
문서의 흐름과 맞지 않는 것 같기도 하고...(혼자만의 가비지...)

자세한 사항은 첨부 파일을 예제소스는 example.js 파일을..
prototype.js 를 자주 활용하다보니 예제 또한...

모티브 :
웹 페이지에서 일어나는 사용자의 단일 액션에 대응하는 일련의 프로세스를 하나의 클래스에서 구현한다.  일련의 프로세스는 사용자가 서버에 요청을 하기 위해서 클릭을 한다거나 입력을 하고 요청을 하고 그에 따른 서버 측에서 처리가 이루어지고 처리 결과를 다시 사용자의 브라우저에 통보를 하고 브라우저는 결과를 통해 사용자에게 결과를 인식 시키는 일련의 작업을 말합니다.  

목적 및 장점 :
1.    CRUD(Create, Read, Update, Delete) 인터랙션에 대한 처리와 시스템 장애에 대한 빠른 문제 파악과 대응

조건 :
1.    XHR Wrapped클래스가 존재하여야 한다. (prototype.js, dojo, jQuery, etc)
2.    XHR 오브젝트를 이용한 데이터 처리가 있어야 한다.
3.    요청을 위한 단계와 응답에 대한 처리 단계가 간단하고 명료해야 한다.

제약 :
1.    복잡한 UI 처리 및 CRUD이외의 처리가 다소 병행되어 진다면 클래스 혹은 객체가 무거워질 수 있다.

단점 :
1.    특정한 인터랙션 위한 패턴으로 확장(extend) 및 소스 재사용 면에서 용이하지 못함





요약

Ajax을 통한 개발에 있어서 사용자의 경험(user experience)은 매우 중요해졌습니다.  그만큼 사용자의 액션도 다양해졌고 매우 고급스럽게 바뀌어 가고 있습니다.  간단하게 인디케이터만 봐도 그렇습니다.  예전 Web1.0 방식에서는 웹 서버의 부하로 페이지가 열리지 않을 때 사용자는 단지 White Background 즉 아무것도 없는 하얀 백지 상태의 화면만 주시하고 있었어야 했습니다.

하지만 현재에는 인디케이터를 통해 사용자의 요청에 대한 진행 상황을 유연하게 표현함으로써 사용자의 경험을 존중해 줍니다.

이렇게 복잡해진 부분도 있지만 사용자 요청에 대한 대부분은 서버로부터 데이터를 요청하거나 입력, 갱신, 삭제에 대한 경우입니다.  요청에 대한 응답에 있어서 그 처리가 간단하고 명료한 시스템이라면 CRUD 패턴을 이용해서 하나의 요청과 하나의 응답에 대한 처리를 하나의 클래스에서 처리한다면 시스템의 장애가 발생 시 어떤 부분 즉 어떤 사용자 액션에서 발생했는지 쉽게 파악하고 대응할 수 있게 됩니다.

하지만 설계 면에 있어서 향후 시스템의 확장이 있을 경우나 사용자의 액션에 대한 처리가 복잡해지게 되면 대응하더라도 설계 구조 자체를 뒤바꿔 할 여지가 다분해 보입니다.

실제로 저는 BBS나 콘텐트의 댓글 시스템에 이전에 포스팅 한 Design by Design Pattern 과 함께 CRUD Pattern을 이용하여 개발을 했습니다.  유지 보수가 발생하지 않아서 효율 및 실무에 적용할 만한 패턴인지 증명되지는 않았습니다.

이 내용은Ajax/Rich UI의 특정한 개발을 위한 방법론에 가깝다고 봐도 무방합니다.  또한 개인적인 경험에 의한 정리이며 일반적인 시스템 설계에서 말하는 패턴의 정의와는 상이하거나 다른 의미를 갖을 수 있습니다.

Design by Design Pattern정의


모티브 :
HTML 디자인을 개발자에 의해서 동적으로 생성되도록 처리하려면 개발자에 의해서 디자인을 javascript의 정해진 변수에 넣고 프로세서에 맞춰 필요한 디자인을 Document에 렌더링을 해야합니다.  유지보수 시 디자인적인 추가 요소가 발생할 경우 개발자가 디자인을 수정하거나 편집해야 하는 일이 발생한다.

목적 및 장점 :

조건 :


제약 :

단점 :


좀더 자세한 패턴에 대한 설명은 PDF 문서에 담았습니다.

이 내용은Ajax/Rich UI의 특정한 개발을 위한 방법론에 가깝다고 봐도 무방합니다.  또한 개인적인 경험에 의한 정리이며 일반적인 시스템 설계에서 말하는 패턴의 정의와는 상이하거나 다른 의미를 갖을 수 있습니다.

Javascript Optional pattern

디자인 패턴에 이미 있나? 패턴에 대한 심도 있는 연구를 해본 적이 없지만 javascript 개발을 하다 보니 자주 사용하게 되는 패턴이라 정리해봅니다.  (이미 GoF 나 POSA 에 일부분에 적용되어져 있을 수도 있습니다.)

간단하면서 이미 많은 개발자들이 이런 방식으로 개발하고 있을지 모른다고 생각한다.  외국 라이브러리 역시 이런 방식으로 개발된 라이브러리가 꾀나 있다. 거론하자니 생각이 나지 않네요. Javascript Lib 카테고리 가면 몇몇 링크가 있는데 그들 중에도 있었다.

의도 :
  하나의 클래스를 통하여 다양한 표현할 수 있다.

동기 :
  컴포넌트, 위젯 형태의 개발에 좀더 사용자 설정을 강화하여 다양한 형태의 결과를 표현하고 싶을 때, 이로 개발된 산물은 pre-config 에 대한 이해를 통해 디자이너도 쉽게 접근할 수 있도록 해보자.

sample code
//Prototype Object.extend like function extend(dest, sous) { for (var property in sous) dest[property] = sous[property]; return dest; } function foo(options) { /* private * pre-config object for this class */ var options = extend({ target: '', x: 100, y: 200, width: 300, height: 300, title: 'Optional Pattern', hook: ['click', 'mouseover'] }, options || {}); return { /* public * get pre-config object of class * @param {string} key config property name * @return {All} value */ getOption: function(key) { return (typeof key == 'string') ? options[key] : options; }, /* public * get pre-config X,Y position value * @return {Array} value */ getXY: function() { return [options['x'], options['y']]; } }; } var Foo1 = new foo(); Foo1.getXY(); //[100, 200] var Foo2 = new foo({ target:'rhio', x:300, y:300}); Foo2.getXY(); //[300, 300]

위 소스에서도 알 수 있듯이 사용자는 Hash형 Object 타입으로서 pre-config를 설정하여 해당 클래스가 new 키워드로 인스턴스화 되어질 때 해당 객체의 초기 설정값에 의해 동작한거나 config의 설정된 Option을 참고하여 객체가 동작되게 됩니다.

foo 클래스는 new 키워드에 의해 인스턴스화 될때 options 이라는 파라미터를 받아서 내부의 설정값으로 동작하게 됩니다.  컴포넌트의 Positioning, Sizing, Target Element 등을 생성할때 마다 다른 형태의 결과물을 볼 수 있습니다.

간단하게 생성한 객체들의 getXY 메서드를 수행했을 때 다른 결과 즉
Foo1 의 x, y 포지션은 생성시 아무런 파라미터도 주지 않았기 때문에 [100, 200]이 출력되었고
Foo2 의 x, y 포지션은 생성시 Hash 형태의 Object에 { x:300, y:300 } 을 넘겼기 때문에 생성시 넘겼던 옵션값을 그대로 취하게 됩니다.

이는 위젯 방식의 컴포넌트 개발 시에 매우 유용하며 javascript를 이용한 Rich UI, Application 개발 시 기획에 의도를 다양하게(?) 받아들일 수 있다.

또한 디자이너나 개발자들도 pre-config에 대한 이해만 있다면 값의 설정을 통해서 쉽게 원하는 결과물을 얻을 수 있다.

ExtJS 의 구조적 이해를 하고자 정리해 봅니다.

부제 : Javascript의 prototype은 어떤 의미를 갖는가?



그럼 오브젝트는 무엇일까요?

다시 MDC 에서 정의한 프로토타입에 대한 설명입니다.

Constructor

prototype 이라는 것은
javascript의 표준인 ECMAScript의 오브젝트 중 하나입니다.


이렇게 정의를 하고 계속해서 좀더 상세히 알아보도록 합니다.


ECMAScript는 C++, Smalltalk, Java 처럼 클래스의 개념이 존재하지 않지만 오히려 오브젝트를 위해 스토리지를 할당하고 그들의 프로퍼티에 초기값 할당을 통해 그것들의 일부 혹은 모든것을 초기화하는 실행 코드로 오브젝트를 만드는 생성자를 제공합니다.

생성자를 포함하는 모든 함수들은 오브젝트이지만 모든 오브젝트가 생성자가 되는 것은 아닙니다.

각각의 생성자^constructor는 프로토타입 기반^{prototype-based} 상속^inheritance과 공유^shared 프로퍼티^properties를 구현하기 위하여 프로토타입 프로퍼티 갖습니다.

오브젝트는 new 연산자에 생성자를 사용하여 생성되어짐 : 예를 들어 new String(“A String”)는 새로운 string 오브젝트를 생성합니다.

new를 사용하지 않고 생성자를 적용하는 것은 생성자에 따른 결과를 갖습니다.

예를 들어 String(“A String”) 는 초기 문자열이 만들어집니다. 하지만 오브젝트는 아닙니다.

ECMAScript는 프로토타입 기반^{prototype-based} 상속^inheritance을 지원합니다.

모든 생성자는 연관된 프로토타입을 가집니다. 그리고 생성자에 의해 생성되어진 모든 오브젝트는 생성자와 연관된 프로토타입(Object’s prototype 이라 불리우는)에 절대적인 레퍼런스를 갖습니다.

더욱이 프로토타입^prototype은 null이 아닌 원형^prototype에 절대적인 레퍼런스를 갖습니다. 그래서 이것을 프로토타입 체인^{prototype chain} 이라고 부릅니다.

오브젝트에서 레퍼런스^reference가 프로퍼티^property에 만들어 질 때 저 이름의 프로퍼티를 포함하는 프로토타입 체인^chain의 첫번째 오브젝트에 저 이름으로 프로퍼티를 갖는다.

바꿔 말하면,  

첫번째는 오브젝트가 직접 언급했던 프로퍼티가 있는지 없는지 조사(검토)하는 것입니다.  만약 오브젝트가 정해진 프로퍼티를 포함한다면 그 레퍼런스가 참조하는 프로퍼티입니다.  만약 그렇지 않다면 오브젝트는 찾기 위해서 다음 프로토타입^prototype으로 넘어간다. 

즉 위의 예제 소스를 예로 설명하자면 마지막에  childObject.name.toString(); 를 호출했습니다.
최초 childObject가 가지고 있는 name을 참조합니다. childObject에는 name 프로퍼티를 가지고 있기 때문에  toString()을 수행하게 됩니다. 만약 name 프로퍼티가 존재하지 않는다면 fatherObject -> grandFather -> Object 까지 찾아가게 되겠죠.

아무튼 name 프로퍼티가 존재하므로 childObject에는 toString()이라는 메서드를 수행하게 됩니다. 하지만 childObject 에는 toString() 이라는 메서드가 존재하지 않기 때문에 Object.prototype.toString()을 수행하게 됩니다. 만약 Object.prototype.toString 메서드가 존재하지 않는다면 당연히 (fireBug)toString is not a function 이라는 메세지를 보게되겠죠.

그래서 클래스 기반^class-based 객체 지향 언어는 일반적으로 인스턴스^instance에 의해 이동된 상태, 클래스에 의해서 이동된 메서드 그리고 상속은 구조와 습성의 유일함이다.

ECMAScript에서 상태와 메서드들은 오브젝트에 의해서 이동되어 집니다.  그리고 구조, 습성, 상태는 모두 상속되어 집니다.

직접 그것들의 프로토타입^prototype이 포함하는 특별한 프로퍼티^property를 포함하지 않는 모든 오브젝트들은 저 프로퍼티와 그 값^value을 공유한다.

아래 다이어그램을 참조

CF는 생성자 입니다(그리고 또한 오브젝트 입니다.).

다섯개의 오브젝트는 new 연산자를 통해 생성 : CF1, CF2, CF3, CF4, CF5

각각의 오브젝트는 q1, q2의 프로퍼티를 포함합니다. 점선 라인은 절대적인^implicit 프로토타입^prototype 관계; 예를 들어 CF3의 프로토타입은 CFp입니다.

그 생성자 CF는 자체적으로 CFp, CF1, CF2, CF3, CF4, CF5에 보이지 않는 2개의 프로퍼티를 갖습니다.

CFp 안에 CFp1 프로퍼티는 q1, q2 혹은 CFp1라 지정되지 않는 CFp의 절대적인 프로토타입 체인에서 발견되어지는 어떤 프로퍼티들 처럼 CF1, CF2, CF3, CF4, CF5에 의해서 공유되어 집니다.

CFp와 CF 사이에 절대적인 프로토타입 링크가 없다는 것을 알아야 합니다.

클래스 기반 언어들과는 달라 프로퍼티들은 값을 할당하는 것으로 오브젝트에 동적으로 추가될 수 있습니다.

즉 생성자는 생성되어진 오브젝트의 프로퍼티 일부분 혹은 전체에 이름과 값의 할당하는 것을 요구하지 않습니다.

위의 다이어그램에서, 한가지 CFp에 프로퍼티에 새로운 값을 할당하는 것에 의해 CF1, CF2, CF3, CF4, CF5를 위한 새로운 공유된 프로퍼티를 추가할 수 있다.

모두 ECMAScript 262-2 Spec 자료입니다.
중간에 번역의 이해를 돕고자 이미지화 하였습니다.  혹 이미지화 한 것이 혼동을 잃으킬 수도 있습니다. ^-^;
오역이 있을 수 있지만 최대한 번역에 대한 점검을 하였습니다. (외국에 살다온 직장 동료에게 검증을 받았습니다. ^^;;)

몇 일전 가비지 컬랙션에 대해서 포스팅할때 함께 기재할 메모리 테스트 부분에 대한 결과입니다.
이미지 첨부할게 너무 많아 PDF로 만들어서 첨부합니다.

도움이 될련지는 모르겠습니다.

테스트 코드 역시 첨부합니다.
테스트 코드는 IE 8의 순환참조에 대한 메모리 누수 마이그레이션 팁에 대한 내용을 실제로 구현 테스트 해 본것입니다.  실제로 테스트 코드와 같은 패턴의 사용은 메모리 IE에서 메모리 누수의 심각성을 보여줍니다.


도움이 얼마나 될른지는 모르겠습니다. ^^
순환참조에 대한 경각심 정도는 불러 일으킬 수 있지 않을까 싶기도 하네요.

Apress 에서 간만에(?) 좋은 책을 출간한듯 합니다.
조금 되긴했지만요.. ^^

요즘 출퇴근 시간에 어디 오갈때 보고 있는 책입니다. 
사실 구매는 하지 않았고 에디나양이 재본을 해줘서 잘 보고 있습니다.

javascript에 대한 기술적인 소개와 DOM 과의 연동에 있어서 이슈가 될만한 사항들
jQuery 창시자이니 만큼 그에 관련된 기술적인 노하우도 조금씩 섞여있는 듯 합니다.

또한 내용들은 Ajax 어플리케이션 개발에 많은 도움을 주는 듯합니다.
또한 Framework에 대한 이해도도 좀더 빨라지지 않을까 라는 생각을 해봅니다.

아직 읽기 시작한지 얼마 되지 않았지만 상당히 좋은 내용이 많았습니다.
Javascript를 통한 DOM 처리 부분, Javascript의 특징, OOP가 가능하게되는 것들 다양한 기술적으로
접하지 못하는 부분들까지 조목조목 잘 집어주는 듯 합니다.

또한 국내에서는 그다지 javascript에 대한 프로그래밍 언어로서의 교재는 턱없이 부족한데 이 책의
번역서가 나온다면 참 좋은 레퍼런스가 되지 않을까 생각해봅니다.


Pro javascript technical 에 더불어 Design patterns 책인데요.  다른 디자인 패턴 책들과 내용은 유사합니다.
다만 Javascript의 디자인 패턴이라는 것!!

기회가 된다면 이 책도 함께 읽어보면 좋을 것같습니다.
Java나 다른 객체지향을 했던 분들이 javascript의 패턴 책을 본다면 몹시도 혼돈스럽지 않을까도 생각이 듭니다. 그 흐름은 같지만 예제가 그다지 와닫지 않을 수 있다라는 생각을 했었습니다.

과연 자바스크립트 OOP에 대한 이해도를 조금 높히는데 도움이 될까 번역해 보았습니다.  경우에 따라 오역이 있을 수도 있습니다.  또한 완벽하지 않다는 말이 될 수도 있습니다.

원글은 아래 링크를 기재해 두었습니다.  이번 글을 개념적인 부분을 설명하고 있어 글로만 표현하였습니다.  이미지를 첨부해 좀더 이해도를 높이려고 했으나.. 힘들어서 포기 ^-^;

우리가 흔히 알고 있는 객체 지향 언어인 Java 와 C++ 의 간단한 비교가 아래부분의 표로 기재되어있습니다.   하지만 기재된 것이 차이점의 전부라고 할 수는 없습니다.

언어와 다른 언어를 비교해가며 OOP가 된다 안된다를 거론하지는 않았으면 합니다.
또한 어느 언어나 객체지향이 가능하다라고 말하고 싶습니다.  마지막으로 OOP에 대한 비교 우위를 따지는 것은 단지 수치화 해보고 싶은 마음에서만 하는것이 좋다고 생각합니다.

Java와 C++과 같은 클래스 기반 객체지향 언어는 두 가지의 뚜렷한 본질적인 개념을 갖는다.

클래스

인스턴스


클래스 정의

자바스크립트 같은 프로토타입 기반prototype-based 언어는 이렇게까지 구분하지 않습니다. : 단순히 오브젝트Object를 같습니다.

프로토타입 기반 언어는 prototype 오브젝트의 개념을 갖습니다.  개체를 사용하는 템플릿으로써 새로운 오브젝트를 위한 초기 프로퍼티를 얻기 위해 사용됩니다.

모든 오브젝트는 생성할 때나 런타임 때 자신의 속성을 지정할 수 있습니다. 또한 모든 오브젝트는 prototype 통해서 다른 오브젝트에 연결 될 수 있고 두 번째 오브젝트에 첫 번째 오브젝트의 프로퍼티를 공유하도록 허락합니다.

클래스 기반 언어, 별도의 클래스로 정의합니다.
이 정의는 여러분이 클래스의 인스턴스를 생성하기 위해서 특별한 메서드를 지정하고 생성자를 호출합니다.  생성자 메서드는 초기값을 지정할 수 있고 생성 주기에 다른 처리를 할 수 있습니다.

여러분은 클래스의 인스턴스를 생성하기 위해 생성자 함수와 관련된 new 오퍼레이터를 사용합니다.

자바스크립트 또한 같은 모델이지만 생성자로부터 별도의 클래스 정의를 갖지 않습니다.  대신에 사용자는 오브젝트를 생성하기 위해서 특정한 초기 프로퍼티와 값의 구성을 정의합니다.  모든 자바스크립트 함수는 생성자처럼 사용될 수 있습니다.  새로운 오브젝트를 만들기 위해서 new 오퍼레이터로 생성자 함수를 사용하면 됩니다.


서브클래스subclass와 상속inheritance

클래스 기반 언어는 클래스의 정의를 통해 클래스 계층hierarchy 구조를 만듭니다.  클래스의 정의에 이미 존재하는 클래스의 하위 클래스로 새로운 클래스를 지정할 수 있습니다.  서브 클래스는 슈퍼 클래스의 모든 속성을 상속 받습니다.  또한 추가적으로 새로운 속성을 부여하거나 상속 받은 것들 것 수정할 수도 있습니다.

예를 들어 직원 클래스는 이름과 부서의 속성만 갖고 하위 클래스인 관리자는 보고 속성을 추가합니다.  이 경우 관리자 클래스의 인스턴스는 세가지 모든(이름, 부서, 보고) 속성을 갖게 됩니다.

자바스크립트는 prototypical 오브젝트를 어떤 생성자 함수와 연결시키는 것을 통해서 상속을 구현한다.

그래서 직원-관리자 예제를 정확하게 만들 수 있습니다.  하지만 약간의 다른 용어를 사용합니다.  직원 생성자 함수를 정의하고 이름과 부서 속성을 지정합니다.  그런 다음 관리자 생성자 함수를 정의하고 보고서 속성을 지정합니다.  마지막으로 관리자 생성자 함수를 위해 prototype에 새로운 직원 오브젝트를 할당합니다.  여러분이 새로운 관리자를 생성할 때 직원 오브젝트로부터 이름과 부서의 속성을 상속 받습니다.


속성 추가addding 및 제거removing

클래스 기반 언어는 전형적으로 컴파일 될 때 클래스가 생성됩니다.  그렇지 않으면 클래스의 인스턴스는 컴파일 시간 또는 런타임 시에 인스턴스화 됩니다.  클래스의 정의된 후에는 클래스의 속성 타입이나 숫자를 변경할 수 없습니다.  그러나 자바스크립트에서는 런타임 시에 어떤 오브젝트의 속성을 추가하거나 삭제할 수 있습니다.
한 구성의 오브젝트를 위해 prototype으로 사용되는 오브젝트에 프로퍼티를 추가하면 그것이 프로토타입인 오브젝트들 또한 새로운 프로퍼티를 얻는다.

클래스 기반 (자바)	프로토 타입 – 기반 (자바 스크립트)
클래스와 인스턴스는 별개의 엔티티이다.	모든 오브젝트는 인스턴스이다.
인스턴스는 생성자 메서드와 갖는	생성자 함수를 갖는 일련의 오브젝트를 정의하고 생성
new 연산자로 단일 개체 생성	동일
기존 클래스들의 하위 클래스를 정의하기 위해 클래스 정의에 의한 오브젝트 계층 생성	생성자 함수와 관련되어 프로토타입으로 오브젝트를 할당하므로써 오브젝트의 계층구조를 생성
클래스 체인으로 프로퍼티 상속	프로토타입 체인에 따라 프로퍼티를 상속
클래스 정의는 클래스의 모든 인스턴스의 모든 속성을 지정합니다.  동적 런타임 시에는 속성을 추가할 수 없다.	생성자 함수 혹은 prototype은 일련의 속성을 지정합니다. 단일 오브젝트 혹은 일련의 오브젝트들에 동적인 메서드 추가 및 삭제할 수 있습니다.

참조 자료 : http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Class-Based_vs._Prototype-Based_Languages

Ajaxian.com 에 재미있는 포스팅이 있길레 퍼옵니다. ^-^;

스타게이트(stargate) 에피소드에서도 javascript를 사용한다는것!!!
대략 난감하지만 재미있네요..
콘솔에 외계어를 넣으니까 자바스크립트로 디코딩 되어서 보여주는 군요.


대단한 javascript!!!
미래를 선두할 자바스크립트의 세계!!

외계의 오염된 저그같은 녀석들이 지구를 침범하려 할때 분명 전세계에서는 자바스크립트 개발자를 절실히 필요하게 될 것입니다.. (-_-;; 막나가봅니다.)

Jacob Seidelin 씨가 매우 재미있는 실험을 했네요.
14KB라는 작은 용량의 자바스크립트 단일 파일로 슈퍼 마리오를 구현했습니다.

재미있는 사실은 외부 이미지를 하나도 사용하지 않고 오로지 Canvas를 사용하고 거기에 자바스크립트로 직접 랜더링하는 기법을 사용하였습니다.

스프라이트(sprite)는 지정된 사용자 정의 문자열만 일정 형식으로 저장되어있고 오직 4가지 색상만 지원되며 그외의 스프라이트는 약 40~60byte 정도 소비하게 될것입니다.

스프라이트 : 화면을 구성하기 위해서 미리 지정해놓은 데이터

aSpriteData = [
    "}\"??"??"??"??"엘?~C_ +?"??"??"?P7콿K%?퐑_\"?죂죂죃M@??,    //  0 ground
    "a ' ![?7개b?mt<N?z]~쭽R?f_7l},tl},+}%XN쾄b[bl??Y_?!@ $",        //  1 qbox
    "!A % @,[] ??;탇?X?<$ ℓ 8}}@Prc'U#Z'H'@??"is ?08@?",            //  2 mario
    "  ?A.@H#q8말e-퐊?켹W:&X줭<&bbX~# }LWP41}k?3쮙#1f RQ@@:4@$",            //  3 mario jump
    "   40 q$!hWa-퐊?_Y}a?0#aaPw@=cmY<mq쯋Bagaq&@q#0?t0?$",            //  4 mario run
    "+hP_@",                                    //  5 pipe left
]


특이한 점은 파이어폭스에서 보게 되면 64base로 인코딩 된 데이터를 소리를 바로 출력해준다는 것입니다.
64Base 인코딩 데이터는 IE에서는 현재 지원하지 않아 no Music 버젼도 따로 있습니다.

<embed id="sound_0"
src="data:audio/mid;base64,TVRoZAAAAAYAAQAEAMBNVHJrAAAAGQD/UQMFe3EA/1gEBAIYCAD/
WQIAAAD/LwBNVHJrAAABqwD/AwRCYXNzAP8gAQAAsAdhAMAjhgCQJGGCHoAkQAeQK1qCB5AwX
AeAK0CBUZApVQSAMECCJJAwWQmAKUCCD5ApVwGAMECBRJAkXQyAKUCCC5AoWQSAJECCC5Ar
XA+AKEBGgCtAB5AwU4UjgDBAAZArXIFMgCtAAZAkWYIjkCtYBIAkQIIYkDBXDYArQIEsgDBACZApXIITg
ClABJAwWYILgDBAA5ApVoFJkCRcAoApQIFPkCxsBIAkQIISgCxABpAubIIEkDBiBIAuQII7kCtiA4AwQDmA
K0AgkCtWgUKQJGUQgCtAgQ6AJEAqkCRZgiKQK1gJgCRAgg6AK0AAkDBZgUmAMEADkClOghiQMFEBg
ClAggiAMEAFkClTgUmQJFwGgClAgiSQKFYLgCRAggiQK1oOgChAT5AwVQOAK0CFFIAwQASQK1aBOJ
AkXAWAK0CCMJArXASAJECCF4ArQAKQMFeBRpApUwKAMECCHYApQAKQMFaCFoAwQAiQKUGBN5
AkWg2AKUCBN5AsbBCAJECCFoAsQAOQLnGCCpAwZAKALkCFEoAwQAD/LwBNVHJrAAACSAD/Aw
ZNZWxvZHkA/yABAQCxB38AwRmHTJFPXyuBT0AskU5mKYFOQDaRTWU3gU1ALpFLdU6BS0BtkUxiaYF
MQFeRRFlJgURAEpFFalqBRUALkUhxgUqRRVwIgUhAUZFIbg6BRUBAgUhAB5FKZ3uBSkCBM5FPZDWB
T0AhkU5nLYFOQDGRTWUzgU1AKZFLX4EzgUtAE5FMZ36BTEAnkVRugR2BVEAvkVRkRYFUQBmRVGSC
fYFUQIFPkU9nMIFPQCqRTmcmgU5AN5FNZjeBTUArkUtlMoFLQIEikUxhQoFMQHiRRFRYkUVhAYFEQFm
BRUAJkUhqgUCRRWECgUhAWZFIbAiBRUBDgUhACpFKc4FigUpASJFLdoIFgUtAHZFKc4IEgUpADZFIaY
McgUhAhCuRT2Q4gU9AJJFOZi+BTkAukU1fMoFNQC6RS2qBV4FLQAWRTF6BTpFETx6BTEAxkUVnB4FE
QF+RSGANgUVAgSqRRV4IgUhAV5FIYhqBRUAugUhACJFKX4E4gUpAd5FPZS2BT0ArkU5qLIFOQDSRTW
BTgU1AEpFLaoFGkUxXBIFLQIEEgUxAMpFUX4ENgVRAKpFUXjqBVEAckVRkgxCBVECBO5FPV1eRTlwW
gU9APYFOQBKRTVYugU1ALZFLbIE3kUxUAoFLQIFwkUROCYFMQFSBREAMkUU6U5FIXAGBRUCBLIFIQ
AmRRVNRgUVACJFIXEyBSEAIkUpBghqBSkALkUtzgguBS0AFkUpnghuBSkAHkUNmhjaBQ0AA/y8ATVRy
awAAACwA/wMYU2VxdWVuY2VkIGJ5IE1pa2UgTWFydGVsAP8gAQcAtwdkAMcAAP8vAA"
loop="true" autostart="true" style="position: absolute; left: -1000px;" type="audio/mid"/>

브라우저마다의 테스트 또한 해보았나 봅니다.  모든 브라우저에서 잘 동작하고 유독 최신 사파리에서는 가장 좋은 퍼포먼스를 보인다고 합니다.

간단히 테스트 해봤지만 조금 불안하기는 합니다.  그런데  외부 요소 없이 오로지 Javascript 로만 이정도로
구현했다는 것에 박수를 보냅니다. ^^

Jacob Seidelin 씨도 이 것을 테스트라고 표현했고 만들어 놓은 마리오가 어떤 다른것들을 만들기 위한 수단으로는 완벽하지는 않고 레퍼런스 정도로 본다고 했네요.

원글 : http://blog.nihilogic.dk/2008/04/super-mario-in-14kb-javascript.html
게임 : http://www.nihilogic.dk/labs/mario/mario_large_music.htm

John Resig 가 벌써 관련 글을 올렸네요.
참고 : http://ejohn.org/blog/embedding-and-encoding-in-javascript/