다음의 코드를 JavaScript의 맨 앞쪽에서 수행하면 됩니다.

/* @ cc_on _d = document; eval(‘var document = _d’) @*/

위의 코드를 IE에서 수행을 하면 document 접근이 약 5배 정도 빨라집니다.


//before
var date = new Date;
for(var i = 0; i < 100000; i++) document;
alert( new Date – date);
//547

/* @ cc_on _d = document; eval(‘var document = _d’) @*/

//after
date = new Date;
for(var i = 0; i < 100000; i++) document;
alert( new Date – date);
//47


IE에서는 document에 그냥 접근하게 되면 window 객체의 내부 메서드가 실행됩니다. IE에서는 이 부분이 아주 무거운 부분인데요.

var _d = document;


이렇게 하고 _d 라는 document의 레퍼런스를 통해서 접근하면 매우 빨라집니다.
위의 코드를 몇 가지의 형태로 더 테스트 해봤습니다.
 대부분의 브라우저에서 속도가 10배 혹은 20배 이상 나타나는 경우도 있었습니다.

// Before
var date = new Date; 
for (var i = 0; i <100000; i++) document.getElementById; 
			
alert ('before '+ (new Date - date)); // 100
			
/*@cc_on _d=document; eval('var document=_d; var getEl=_d.getElementById;')@*/
			
var _d = document;
var getEl= _d.getElementById;

// After
date = new Date; 
for (var i = 0; i <100000; i ++) getEl;  

alert ('after '+ (new Date - date)); // 4 

Chrome 에 document.getElementById 의 DOM 메서드에 대한 테스트에서는 Before : 100s,  After : 4s 정도가 평균적으로 나타났습니다.

위의 내용은
일본의 amachang 씨가 블로그에 소개한 내용입니다.

원글 :
http://d.hatena.ne.jp/amachang/20071010/1192012056
추가글 :
http://d.hatena.ne.jp/uupaa/20081230/1230604575

이 글에 대한 자세한 테스트 자료가 있어서 함께 소개합니다.

JavaScript Library | Posted by Rhio.kim 2008/10/15 01:50

Good bye alert(); - JavaScript Library

심플한 라이브러리를 소개할까 합니다.  최근에 라이브러리 소개를 하지 않았는데 오랜만에 ^^..
소개하는데도 당연히 이유가 있겠죠.



Blackbird 라는 라이브러리 입니다.

일단 사이트에 접속을 하면 큰 글자로 이렇게 적혀있습니다.


Blackbird 에게는 "만나서 반가워" 이라고 말하고 alert() 에게는 "이만 안녕" 이라 말하라고 합니다. 
그래서 무엇인고 봤더니 log와 profiler로 활용하기 좋은 rich application을 JavaScript로 구현을 해 놓았군요.
이런 라이브러리야 이미 YUI에도 유사한 모양으로 있고 firebug에서도 강력하게 지원을 해주고 있는데...

깜직한 아이콘은 둘째 치고 개발자 편의를 위해 단축키까지 처리해 놓은 것을 보면 참. 많은 것을 느낍니다.

이미 나온 Blackbird 라이브러리는 누구나가 만들 수 있지만... 처음 나온 Blackbird 라이브러리는 처음 만든 개발자의 스킬과 마인드에서 밖에 나올 수 없는게 아닐까 생각해봅니다.

alert() 에게 "이만 안녕" 이라 말 할만 한가요?

Library : http://www.gscottolson.com/blackbirdjs/
Google : http://blackbirdjs.googlecode.com/
JavaScript | Posted by Rhio.kim 2008/10/11 14:10

JavaScript Injection Attack

JavaScript Injection Attack - 자바스크립트 인젝션 공격

JavaScript 보안 관련 자료가 있어 번역하여 올립니다.
웹 기술의 변화와 관심이 달라지는 만큼 함께 신경써야 할 부분도 많아지고 그만큼 복잡해지나 봅니다.


최근 JavaScript 인젝션 공격이 유행하고 있습니다.  Malware 감염을 전파하는 효과적인 수단으로 이러한 종류의 공격을 활용하는 악성웨어들이 늘고 있다.

불과 1 년 전만해도 악의적인 공격자가 의지하고 있던 것은 공격용 Web 사이트를 가리키는 이메일, 검색 링크 또는 인스턴트 메시징 웜 등의 연결로 사람들을 유도하는 방식이었다.

지금은 JavaScript 인젝션 공격을 이용하여 Web 사이트의 방문자를 "납치"하고 만다. 이 공격은, 이른바 어둠 세계의 해커들이 악성웨어가 만연하도록 하는데 사용하는 맥가이버 칼과도 같다.


예시


우리는 다수의 높은 트래픽을 보았고, 합법적인 웹 사이트들은 이 기술을 이용해 공격을 받았다.  최근  알렉사 랭크 3172의 미국의 매우 유명한 게임 포털인 MegaGame도 하나의 예이다. 자바스크립트 인젝션 공격은 MegaGame 서버 중 하나의 서버에 몇 줄의 코드를 성공적으로 추가하였고 이 추가는 아무것도 모른체 웹 사이트를 접속한 방문자들을 악의적인 유럽 사이트로 이동시키고 악성웨어에 감염시키려 시도되었다.

그 악의적인 사이트는 두 가지 다른 방법을 통해 방문자들에게 공격을 시도하였다.  첫 번째는 Microsoft MDAC RDS.Dataspace ActiveX Control Remote Code Execution Vulnerability (MS06-014).
를 시도했다.

 


이 공격은 Microsoft's Internet Explorer (IE) 브라우저를 사용하는 방문자에게만 성공할 수 있었다.
왜냐하면 이 Web 사이트는 기본적으로 ActiveX 컨트롤의 사용을 요구하고 ActiveX 컨트롤 및 IE 간의 상호 작용에 존재하는 허점 (루프 홀)을 통해 원격으로 컴퓨터를 공중 납치하기 때문이다.

두 번째 공격은 다운로드 시 실행되고 IE뿐만 아니라 "Firefox"버전 1.0이 2.0이 대상이다. 이 공격에서는 JavaScript를 사용하여 Web 브라우저 종류를 확인하고 그 후에 미국 어도비 시스템의 Flash의 악용을 통해 공격에 대한 바이너리 파일을 PC에 다운로드하고 실행한다.

 


MegaGames의 Web 사이트는 여전히 감염된 상태. 불행히도 이것이 바로 현재의 상황을 말해 준다

인터넷 이용자의 대부분은 "pr0n"(포르노) 나 "warez"(와레즈 : 불법 복제 소프트웨어) 와 같은 계시의 위험이 높다.  (dodgy: 자못 의심스러운) Web 사이트를 방문한 경우 감염도 없다고 생각하고 듯하지만,  불행이도 그것은 잘못된 생각이다.

Malware 수법은 이전보다 성공화되고 있으며, 현재는 제대로 된 뉴스 사이트 및 비즈니스 관련 사이트도 감염되어있을 가능성이 있다.

"안전한 Web 사이트는 존재하지 않는다"는 것을 보여주는 또 경우가 BusinessWeek.com이다.  아주 정통으로 접근할 수가 많은 이 사이트가 SQL 주입 공격 타겟이 됐다.  이 같은 SQL 인젝션 공격이  JavaScript 인젝션 공격으로 연결 된다.

출처 : http://www.f-secure.com/weblog/archives/00001502.html


포스팅하려고 준비해 둔 JavaScript Injection 공격에 대한 자료를 첨부합니다.
상세한 자료는 아니고 아웃라인(흐름)에 대한 내용입니다.


올해 Ajax Experience 에서 Oliver Steele 의 JavaScript 발표 자료입니다.
JavaScript의 예제 중심의 키 포인트를 집어주고 있네요.

JavaScript의 언어적 특징을 이해하는데 도움이 되겠네요.

블로그 : http://osteele.com/
페이지 : http://osteele.com/talks/ajaxian-2008/samples/
프리젠테이션 : http://www.slideshare.net/osteele/oliver-steele-functional-javascript-presentation
PDF : http://osteele.com/talks/Oliver_Steele_Functional_JavaScript_v2.pdf
JavaScript Study | Posted by Rhio.kim 2008/10/07 00:31

jQuery의 현재 그리고 미래


jQuery의 무서운 돌진…

jQuery의 MS와 Nokia이 adopting 소식과 존 레식 블로그의 컨퍼런스에 대한 소개 자료를 살펴보다.  약간의 번역과 요약정리 해봅니다.

jQuery 창시자이자 리더 개발자인 존 레식은 보스턴에서 열린 Ajax Experience에서 3일간의 행사 기간중 2개의 패널에서 아홉 가지의 이야기를 했습니다.  조만간 컨퍼런스의 발표 내용에 대한 것들은 비디오 자료와 함께 곧 포스팅 할 예정이라는데 언제 올라 올른지…

State of jQuery `08
급속한 성장을 보여준 jQuery에 대한 변화에 대한 프리젠테이션.  간략하게 요약하자면 jQuery 사이트의 UV와 PV의 향상, Google Trend에서도 확인할 수 있지만 2008년도의 jQuery의 변화를 보여주는 자료입니다.

아래 구글 트랜드의 그래프 자료를 보더라도 2분기에 오면서 꾸준한 유저층을 유지해오던 Prototype과 2007년 후반기부터 갑작스레 높아졌다 2008년 1분기에 급속한 하락한 Dojo에 반해 jQuery는 꾸준히 상승하고 있습니다.

비교그래프

Google Trend 자료



2008년 3월에 이미 Prototype과 비슷한 사용자층을 유지하고 있습니다.  Script.aculo.us가 있기는 하지만 ^^ 4월에서 6월의 기간 동안에는 Designer와 Ruby Dev 그룹에서는 이미 jQuery가 앞서가는 모습을 보입니다.

2008년에 다양한 기능 업그레이드와 퍼포먼스 향상의 대표적인 부분들에 대해서 알려주고 있었고 이에 대한 기술적인 다양한 방법으로 공개하였고 이로 jQuery의 트래픽이 꾸준히 상승한 것이 아닌가 추측해봅니다.

그리고 2009년에도 jQuery의 노력은 헛되지 않으리라 봐지는 다른 부분은 MS와 Nokia의 jQuery 탑재에 대한 소식도 빼놓을 수 없을 것 같습니다.  (Microsoft and Nokia are both adopting jQuery)

Nokia의 Phone 에 들어가는 웹 런터임(Webkit)에 사용될 포팅 어플리케이션의 작동을 위해 jQuery를 사용하고 새로운 Phone 에도 적용될 예정이라고 합니다.

Microsoft의 경우 그들의 개발 플렛폼 일부분에 jQuery를 만들었고 Visual Studio .NET에 탑재되었습니다. 그리고 jQuery를 이용한 다양한 컴포넌트를 제작하였습니다.

참조 : http://www.slideshare.net/jeresig/state-of-jquery-08-presentation/


jQuery Internals + Cool Stuff
이 프리젠테이션 자료에는 jQuery의 내부 기술과 쿨한 재료들에 대한 소개입니다.  Wrapping과 다른 사용자와 프레임웍들 간의 코드 충돌이 일어 나지 않도록 처리한 기술, Element에 Data 바인딩 및 캐시 활용 기술 등에 대한 소개,  jQuery의 Selector는 타 프레임웍과는 달리 비 종속적 동작으로 다른 프레임웍(Prototype이나 Mochikit)하고 함께 사용 가능하다는 것과 동작 원리에 대한 소개,  Event System 에 대한 소개, 브라우저 Sniffing 에 대한 기술.  마지막으로 TDD(Testing Driven Development) 를 위한 Suite 와 Profiling에 대한 소개가 있었습니다.

참조 : http://www.slideshare.net/jeresig/jquery-internals-cool-stuff-presentation/


JavaScript Library Overview
  90분 동안 발표한 자료로 다양한 라이브러리의 Overview는 각 라이브러리들 간의 비교를 쉽게 파악할 수 있도록 꾀 많은 자료 매우 다양한 방면에서 비교, 분석해 놓았네요. 

참조 : http://www.slideshare.net/jeresig/javascript-library-overview-presentation/
Ajaxian : http://ajaxian.com/archives/thinking-about-the-difference-between-frameworks


존 레식의 활동과 jQuery의 개발팀의 열정만큼이나 2008년도에 JavaScript 프레임워크는 MS와 Nokia의 adopting으로 2009년에는 더 많은 유저층과 트래픽을 유지하지 않을까 짐작해봅니다.    

또한 다양한 RIA 개발을 위한 다양한 플랫폼들과 대등한 관계에서 경쟁구도를 형성하리라 본다.  Silverlight의 최대 라이벌은 Adobe Systems 의 Flash가 아닌 JavaScript(http://live-kj2164.tistory.com/?page=2)라는 전문가들의 말처럼 jQuery 뿐만 아니라 모든 JavaScript 프레임웍들이 2009년도에는 좀더 다양한 기술로 발전할 수 있었으면 하는 바램입니다.


자료 출처 : http://ejohn.org/blog/jqueryembraceextend/

'JavaScript Study' 카테고리의 다른 글

jQuery의 현재 그리고 미래  (0) 2008/10/07

Find Equal게임이란?
  간단히 같은 이미지 찾기를 JavaScript로 개발한 게임입니다.

모티브
  외국 사람들도 JavaScript, SVG, Canvas를 이용해서 게임을 만드는데 국내 개발자도 알고리즘과 아이디어로 게임을 만들 수 있다는 것을 보여주고 싶어설까? 

  한가지 본연의 동기부여를 추가한다면 Ajax/Rich Application을 개발할 때 HTML 구조, CSS, JavaScript의 DOM과의 작동에 대한 잘된 설계와 UX(사용자 경험)가 잘 혼합된다면 어플리케이션의 성능 향상과 실 사용자(end user)에게 분명 유용한 서비스 혹은 어플리케이션이 된다는 것을 보여주고 싶어서입니다.

왜 그런지는 다음 설명들을 통해서 살펴 보겠습니다.


요구
1.    게임용 이미지 리소스는 요소별로 따로 관리하지 않고 게임에 필요한 리소스를 하나의 파일로 관리한다.
2.    HTML, CSS, JavaScript의 완벽한 구분을 꾀한 Unobtrusive JavaScript를 지향한다.
3.    DOM, CSS 제어를 위해 Prototype.js Framework를 사용한다.


구현 방식
요구사항
A.    게임을 구동하고 사용자가 사용함에 필요한 기본 리소스는 초기 HTML과 함께 로딩한다.
B.    초급자, 중급자, 고급자별 Game Panel의 요소의 개수는 변할 수 있다.
C.    다양한 이미지로 화면이 리프래쉬 되거나 유저에 의해 reset 버튼을 이용할 경우에 다양한 이미지를 제공하여 식상하지 않도록 한다.
D.    틀린 그림 찾기 게임의 룰을 만족시킨다.

첫번째 요구사항은 매우 간단합니다. 하지만 왜 이렇게 하는 이유는 알아야겠네요.

<img src=”image_resource.jpg” style=”display:none;” />


  이렇게 html 페이지에 위와 같이하게 되면 이미지 리소스는 화면상에 노출되지 않은 채 로딩됩니다. 이는 유저에 의해서 게임을 할 때 이미지 리소스를 가져오거나 잘못된 CSS Background-Image 속성을 사용하게 되면 동일 한 이미지를 캐시를 활용하지 못할 수가 있기 때문입니다.  그래서 미리 HTML에서 로딩을 하게 되면 캐시를 활용할 수 있어 게임 동작 시 성능을 향상할 수 있습니다.

사용자 삽입 이미지


  두번째 요구사항을 만족하기 위해서는 위의 Game Panel을 Table구조나 Div 구조로 개발되어야 합니다.  하지만 틀린 그림 특성상 Table 구조도 적합하기 때문에 Table 구조를 선택하였고 동적으로 n*n(cel * row) 의 table을 생성할 수 있도록 하였습니다.

  자! 지금부터 설명할 부분이 이 게임을 구현하는데 있어서 필수적인 요소가 되겠습니다.  위에서 언급한 개발 시 요구사항 부분에서 언급한 내용처럼 이미 게임의 동작을 위한 Image Resource는 미리 제작되어 있습니다.  이것은 위의 Game Panel의 TD에 들어갈 요소들로 요소 별 하나의 이미지가 아닌 이 게임(틀린 그림 찾기)에서 사용될 수 있는 모든 요소 이미지를 하나의 이미지로 만들었습니다.  다음 그림과 같아집니다.

 
사용자 삽입 이미지


  흐름과 틀리지만 예를 들어 위의 Game Panel의 Table을 동적으로 만들 때 TD에 blank 이미지를 설정해 놓고 클릭할 때 해당 blank 이미지에 JavaScript를 이용해 src 속성에 이미지의 위치를 지정하는 방식도 있습니다. 하지만 그렇게 하면 다양한 요구사항을 받아들이기가 어려워지고 원격지의 이미지를 HTTP를 통해 가져오는 동안 문제가 발생하는 경우 표시를 못하게 되거나 다양한 문제점이 게임 진행중에 발생할 수 있습니다.

  그래서 위의 이미지 리소스와 같이 하나의 이미지 파일에 다양한 요소를 지정해 놓았습니다.  적어도 게임이 진행중에는 오류로 인한 문제는 최소화 해야 하기 때문입니다.  만약 초기 로딩 시 이미지를 가져오지 못한 경우에는 체크해서 사용자에게 알려주어 게임 진행에 대한 상황을 사용자에게 전달 할 수 있습니다.

  그러면 이 하나의 이미지를 어떻게 Game Panel에 표시할 것인가가 문제입니다.  큰 문제는 아닙니다. 누구든지 아는 부분일 것입니다.

  이미 로딩된 Image Resource를 Game Panel의 각 요소(TD)에 Style 제어를 통해서 표시할 수 있습니다.
각 TD에 style.backgroundPosition = ‘-0px -0px’; 와 같은 방식으로 부여를 하면 됩니다.

 
사용자 삽입 이미지


  위의 좌표처럼 TD에 backgroundImage는 Image Resource로 설정해주고 backgroundPosition을 제어하면 하나의 이미지 리소스로 다양한 위치를 각 요소에 설정할 수 있습니다.

  마지막 요구사항은 각 요소에 표시될 이미지가 순차적이라면 틀린 그림 찾기의 게임 룰을 만족할 수 없기 때문에 이미지 리소스에 있는 이미지 요소들을 랜덤으로 Game Panel에 설정하는 부분만 처리하면 유저가 게임을 할 수 있는 기본적인 설정이 갖춰집니다.

랜덤 설정은 알고리즘이니 조금만 고민하면 위의 조건들을 만족하는 렌덤 배열을 생성할 수 있을 것입니다.

랜덤 배열 범위 = ( ImageResource 가로요소 개수 * ImageResource 세로요소 개수) – 1;

 
사용자 삽입 이미지


랜덤 배열의 범위 즉 [0, 1 ,…, 195] 를 random 알고리즘을 이용하여 뒤섞어 줍니다.

_random: function(arr){
	var i = arr.length;
	if (i == 0) 
		return false;
	
	while (--i) {
		var j = Math.floor(Math.random() * (i + 1));
		
		var ti = arr[i];
		var tj = arr[j];
		arr[i] = tj;
		arr[j] = ti;
	}
		
	return arr;
}


 섞여진 배열(return arr)은 Image Resource의 index를 가리킵니다.  즉 TD의 backgroundPositon 을 제어할 때 바로 이 섞여진 배열을 통해서 지정하게 됩니다.  하지만 틀린 그림 찾기는 위의 섞여진 배열로만은 이용할 수 없습니다. 

  Arr = [ 28, 13, 99, 2, 84, 50, 38 ];
  Arr = [ 28, 13, 99, 2, 84, 50, 38, 28, 13, 99, 2, 84, 50, 38 ];
  Arr = [ 84, 28, 38, 13, 2, 13, 84, 50, 2, 38, 28, 99, 99, 50 ];

위의 과정을 거치면 정말로 틀린 그림을 찾기의 배열 요소가 갖춰집니다.  이 배열을 이용해 Game Panel의 각 구성 요소에 Image를 지정할 때 Image Resource의 이미지 index와 매칭하여 Position을 TD의 CSS Style로 부여합니다.


요약
여기까지는 게임을 만들면서 생겼던 주요 이슈에 대한 정리입니다.  대단한 건 아니지만 여러 가지 이유는 숨어있습니다. 

요약해보자면 HTML에 미리 <img> 를 이용하여 Image Resource를 로딩한 이유 또한 이미지를 하나의 파일에 넣어둔 이유, CSS Style 제어를 통해서 이미지를 렌더링 한 이유 좀더 찾아보면 몇 가지가 더 있겠네요.

구현의 초점은 게임을 즐기는 유저에게 게임을 즐기는 동안에는 최대한의 성능과 오류가 발생할 요인을 최대한 줄이는데 있습니다.  간단한 게임을 가지고 복잡하게 설명한 건 아닌지.


웹 서비스도 마찬가지 입니다.  Ajax/Rich Application 개발 시에 간과해서는 안될 상황들이 매우 많습니다.  아시다시피 크로스 브라우징부터 검색에 노출에 대한 부분,  HTTP에 대한 이해, 다국어 지원 여부,  Embeding 에 대한 부분… 나열하자면 매우 많겠네요.

그만큼 단순 요구사항에 대한 구현이 아닌 웹 서비스에서는 다양한 환경과 사용자 경험에 대한 바탕으로 설계가 일차적으로 되고(머리 속의 설계도 좋을 것 같습니다.) 개발이 되어진다면 좋지 않을까요?

사용법
이미 TFindEqual.js 파일에 기본 설정값이 지정되어 있어서 4*6의 게임이 자동으로 생성됩니다. 개수를 늘리거나 줄이고 싶으면 row와 cel 속성을 수정해주면 됩니다. 나머지 속성은 고정된 속성입니다.
//기존 소스
var FindEqual = new TFindEqual(this);
Event.observe(window, 'load', FindEqual.set.bind(FindEqual));

//이렇게
var FindEqual = new TFindEqual(this, {
            target: 'panel', //Game Panel이 그려질 target 엘리먼트 id
            row:    4,    //게임 row 개수
            cel:    6,    //게임 cel 개수
            bgrow:    14,  //Image Resource 가로 개수
            bgcel:    14,  //Image Resource 세로 개수
            width:    57, //이미지 너비
            height:    56 //이미지 폭
        });
Event.observe(window, 'load', FindEqual.set.bind(FindEqual));


작성된 게임 소스와 작성된 PDF를 첨부합니다.

JavaScript | Posted by Rhio.kim 2008/09/18 02:15

JavaScript 패턴 - Flyweight Pattern

JavaScript 패턴 - Flyweight Pattern

일반적으로 Flyweight pattern은 효율적으로 유사한 오브젝트들의 공유를 제공하여 메모리 사용을 최소화하고 고성능을 위한 소프트웨어 디자인 패턴입니다.

Ajax/Rich UI 개발의 경우 수 많은 DOM 오브젝트에 비슷한 기능을 부여하거나 수행하는 경우가 많다.  이런 경우 각 DOM 오브젝트에 메소드를 부여하거나 상속에 의한 혹은 prototype chain에 의한 레퍼런스를 통하여 기능을 수행하도록 처리합니다.
 
하지만 경우에 따라서는 매우 복잡한 DOM 오브젝트 제어가 필요하게 됩니다.  그럴 경우에 위의 패턴을 적용하면 성능 향상에 뛰어남을 보입니다.

실제로 jQuery와 ExtJS에서는 이 패턴을 적용하고 있습니다.  반대로 prototype.js 의 Element의 경우에는 $함수를 통하여 얻어온 DOM 오브젝트에 Element가 갖는 메소드 즉 down() up(), next(), previous() 등등 수 많은 메소드를 prototype에 의해서 DOM 오브젝트가 Element.down(), Element.up() 등의 메소드를 레퍼런스하게 됩니다.

IE, Safari의 경우에는 __proto__ chain메카니즘이 존재하지 않기 때문에 해당 엘리먼트에 Element 객체가 갖는 모든 메소드를 부여하는 과정을 한번 더 거치게 됩니다. <관련기사:옷장수님 블로그#Element-메소드-상속>

이 처럼 브라우저에 따라서는 수많은 오브젝트에 확장 메소드를 부여하여 수행하려고 한다면 메모리 사용과 성능면에서 뒤 떨어질 수밖에 없습니다.  

Flyweight 패턴의 경우에는 성능 향상과 메모리 사용면에서 탁월하다는 것을 느끼실 수 있을 것입니다.

간단한 그림을 통해서 Pattern을 이해해보도록 하겠습니다.

사용자 삽입 이미지


좌측은 코드의 주요 수행 과정이고 우측의 Element는 DOM 오브젝트의 기본적인 제어를 위한 공유 오브젝트입니다.  dom 프로퍼티는 Element객체 내에서 내부적으로 제어를 하게 됩니다.
예를 들어 hide 프로퍼티는 dom.style.display = ‘none’; 가 수행되는 기능을 가지고 있게 됩니다. 

좀더 섬세한 예제로 Prototype.js의 $ 함수를 예로 들어보겠습니다.
$(‘rhio’) 라는 명령문을 수행하였다면 document.getElementById(‘rhio’)를 내부적으로 수행하여 순수한 DOM 오브젝트가 반환되면 내부적으로 Element.extend가 수행되어 DOM 오브젝트에 $(‘rhio’).update(‘본 내용이 innerHTML됩니다.’); 라는 명령을 수행할 수 있게 됩니다.

즉 $ 함수를 수행할 때마다 얻어온 DOM 오브젝트에 extend하는 과정이 수행됩니다.  (Firefox의 경우 __proto__ chain에 의해서 extend 과정없이 레퍼런스가 가능하기는 합니다.)

prototype 1.6.0.2 기준으로 2543line 에 보면 $함수를 호출할 때 자동적으로 수행되는 Element.extend 수행 시

if (Prototype.BrowserFeatures.SpecificElementExtensions)
    return Prototype.K;

명령 구문의 Prototype.BrowserFeatures.SpecificElementExtensions 에 의해서 __proto__ 메카니즘을 제공하는 브라우저인지를 체크되며 Mozilla브라우저의 경우에는 Prototype.K를 반환하고 종료됩니다.
각설하고...

반면 위의 Flyweight Pattern의 경우에 순수한 DOM은 Element.dom 프로퍼티로 레퍼런스되고 그 레퍼런스는 Element의 공유 메소드들을 통해서 제어되게 됩니다.


Source Example
var Fn = function() { };
Fn.prototype = Element.prototype;
var _fly = new Fn();

Element.Flyweight = function(dom) {
   this.dom = dom;
};
Element.Flyweight.prototype = _fly;
Element.Flyeight.prototype.isFlyweight = true;
var _flyweights = { };

Element.fly = function(el) {
  el = document.getElementById(el);
  
  if(!el) { 
     return null;
  }
  
  if(! _flyweights[‘cache’]) {
      _flyweights[‘cache’] = new Element.Flyweight();
  }
  _flyweights[‘cache’].dom = el;
  return _flyweights[‘cache’];
}; 


위의 그림과 소스를 번갈아 가면서 보시면 좀더 이해가 빠를 수 있습니다.  설명은 중요한 부분만 정리해 설명드리고 소스는 ExtJS의 Element.fly 부분을 인용하여 변경한 소스입니다.
c.f) ExtJS > Element.js 2986 line ~ 3019 line

Element.Flyweight.prototype는 implicit prototype 이 Element.prototype을 향하고Element.prototype 이 갖는 메소드들(get, hide, show 등)은 Element에 의해서 공유되게 됩니다.
Element.Flyweight function은 new 키워드를 통해 인스턴스화 될 때 Element의 공유 프로퍼티에 접근할 수 있게 됩니다.  여기까지가 Flyweight Pattern의 기본 구조라 할 수 있고 ExtJS의 경우 경우에 따라 좀더 개선된 방식까지 제공하고 있습니다.

ExtJS의 Framework이 로드되면서 생성된 변수 _flyweights에 Element.prototype을 참조하는 function 오브젝트 즉 Element.fly( )를 최초 호출되면 Element.Flyweight( )는 인스턴스화 되어 이를 저장해두고 다음 호출부터는 _flyweights의 저장된 객체에 dom 메소드만 변경하여 반환하게 됩니다.

일반적으로 DOM 오브젝트를 JavaScript로 제어하려고 할 때 일관된 메소드를 제공하는게 프레임웍의 기본 방향인 것 같습니다.  하지만 경우에 따라서는(거의 없겠지만) Image, Script의 DOM 오브젝트에는 일관된 메소드보다 확장된 메소드를 제공하고 싶은 경우거나 반대로 불 필요한 메소드를 제공하지 하지 않아야 하는 경우라면 위와 같은 패턴은 비효율적일 수 있겠습니다.

참고 :
Pro JavaScript Design Patterns [ Ross Harmes and Dustin Diaz ] 179page ~ 195page
http://en.wikipedia.org/wiki/Flyweight_pattern
http://extjs.com/forum/showthread.php?p=140648





책/잡지 | Posted by Rhio.kim 2008/09/11 20:44

JavaScript 에 관한 고찰과 책 소개


JAVASCRIPT

  근 한달 동안 소중한 책들이 연달아 시리즈로 출판되었습니다.  책들의 소개에 앞서 웹 개발에 대한 트랜드가 과연 어떻게 흘러갈까? 라는 생각을 문득하게 됩니다.  RIA 에 맞춰 다양한 언어에서 강력한 인터넷 어플리케이션을 만들 수 있도록 방향을 잡고 변화하고 있고 그에 MS, SUN, Adobe 에서도 다양한 방법과 기술을 제시하고 있습니다.
사용자 삽입 이미지


  MS, SUN 과 Adobe의  RIA 기술은 닷넷 프레임웍이나 SDK와 같은 Runtime 환경을 위한 배포의 정책을 함께 가져야 한다는 것이 단점이 될 수 있습니다.  배포라는 부분은 아직까지는 무시 못할 부분중에 하나이기 때문이죠. 허나 자바스크립트에 비하면 그 기술과 기능은 분명 월등합니다.  반면 자바스크립트는 그러한 부분이 전혀 없고 단지 브라우저가 지원하는 ECMAS262 표준과 각 브라우저의 JavaScript 엔진에 따라서 손쉽게 동작하고 있습니다.

그렇기 때문에 현재 국,내외를 불문하고 많은 사이트에서 자바스크립트 프레임웍을 사용하고 있습니다.  서로 나아가야 할 방향은 틀리기 때문에 서로 비교하는 것이 오류일 수도 있지만… ^^;

한가지 더 언급하면 MS, SUN, Adobe에서 제시하는 기술은 너무나 다양한 사용자의 환경, 인터넷 인프라에서 원활히 많은 기능을 충족 시키기에는 아직은 어려움이 있어 보입니다.  RIA의 모든 기능적 조건을 만족하기 위해서는 그만큼의 시스템 환경과 인터넷 인프라가 구축되어야 하지만 반면 국외의 경우 아직도 매우 낙후한 환경이 많이 존재한다는 것입니다.  
이에 경량의 자바스크립트 프레임웍은 낙후된 환경에서도 현재보다 진보된 기술과 기능을 제공하도록 발전해 가고 있습니다.  다가오고 있는 인터넷 환경의 Rich Application에 필요한 기술을 모두 갖출 수 있도록 발전해 나갈 수 있으리라 봅니다.


JavaScript 로 Ajax/Rich UI 실무와 연구(?)를 꾸준히 해오면서 힘들었던 것은 대부분의 자료가 외국 자료였고 자주 접하게 되는 프레임워크의 레퍼런스조차 국내화 되어있는 것이 턱없이 부족했었다.  이에 2006년 김영보선생님의 Prototype 프레임워크를 분석한 “Ajax Prototype.js 완전정복” 이라는 책을 시작으로 JavaScript의 관심도는 무척이나 높아졌던 것 같습니다.(개인적인 생각)

그 이후 꾀 오랜 시간이 흐르고 최근에 줄줄이 발간된 ‘JavaScript 완벽가이드’, ‘Prototype & Script.aculo.us’, ‘Pro JavaScript Techniques’, ‘jQuery in Action’ 자세히 보면 인사이트 출판사에서 웹이 나아갈 방향 아니 미래를 읽었을까?  



자바스크립트 완벽 가이드 상세보기
데이비드 플래너건 지음 | 인사이트 펴냄
웹 2.0과 Ajax 시대의 중심에 있는 자바스크립트의 기초부터 고급까지! 이 책은 프로그램 언어인 자바스크립트를 체계적이고 심도 있게 다루었다. 자바스크립트에 대한 깊이 있는 설명, 자바스크립트답게...

  연이어 출간된 서적들의 흐름을 보면 JavaScript의 원론을 파악할 수 있는 JavaScript 완벽가이드라는 책.  이는 JavaScript에 대해서 심도 있는 부분까지 알고 싶어했던 개발자라면 원서로 이미 접했을 만한 책이다.   또한 이 서적은 최근 5판까지 개정판이 원서로 나왔었고 3판까지 번역서가 출간된 이래 5판의 원서가 출간되지 꽤 오랜 후에 번역되었는데 원서를 보며 어려움을 겪던 개발자들에게 분명 단비와 같은 역할을 할 것이라 생각합니다.
  그리고 “오해가 깊은 자바스크립트”의 오해의 골을 풀어주지 않을까 생각하고 늘 바이블과 같은 역할을 해줄 것이라 믿습니다.



프로 자바스크립트 테크닉 상세보기
존 레식 지음 | 인사이트 펴냄
테크닉! 이 책은 JavaScript의 고급 테크닉을 다룬다. 너무 기초적인 문법이나 문장 구조 같은 기본적인 사항들을 배제하고, 곧바로 자바스크립트에서의 객체지향이라는 개념과 테스트를 위한 도구, 배포와...

Pro JavaScript Techniques 는 초급을 넘어선 자바스크립트를 이용한 Ajax/Rich UI 개발을 해보았거나 jQuery, Prototype와 같은 프레임워크를 이용하면서 이들에 대한 기술적 의문을 갖었던 것들의 많은 부분을 해소시켜줄 수 있는 책이다.  

이 책의 서두 2부까지의 내용은 JavaScript의 가장 기본이며 자바스크립트에 대한 오해 즉 JavaScript 개발자가 갖는 오해의 많은 분들을 풀어줄 수 있는 내용을 담고 있습니다.  번역서가 나오기 전 원서를 통해서 내용을 접할 때는 확실한 의미 전달이 되지 않았었는데 이번 번역서를 계기로 명확한 의미를 이해할 수 있는 계기가 되었던 것 같습니다.

그리고 jQuery의 창시자인 존 레식(John Resig)은 본인이 갖은 노하우를 거침없이 독자(자바스크립트 개발자)에게 모든 것을 공유할 마음을 갖고 있는 것 같습니다.  그의 블로그를 통해서도 느낄 수 있지만 늘 열심히 새로운 기술에 대한 공유를 선두하고 있고 저 같은 경우에도 그런 열정을 많이 배우고 있습니다.  (각설하고)

책의 모든 내용을 설명으로 일관할 수 없지만 실무에서 JavaScript를 이용한 Ajax/Rich 개발을 하고 있는 분이라면 이 책을 38,939,392,391,382번 읽어 보시길 권장드립니다. (그 만큼 많이 읽어 보면서 의미를 되새길 만한 내용들이 매우 풍부합니다.)


프로포타입과 스크립타큘러스 상세보기
크리스토피 포트누브 지음 | 인사이트 펴냄
이 책은 자바스크립트 개발에서 필수적인 라이브러리가 된 프로토타입(Prototype)과 스크립타큘러스(script.aculo...프로토타입(Prototype)은 동적인 웹 애플리케이션 개발을도와주는 자바스크립트 라이브러리다....

  다음 소개할 책들은 아시는 분들은 아시겠지만 위의 책들의 내용이 지식으로 선행된다면 좀더 쉽게 다가올 수 있는 내용입니다.  ‘Prototype & Script.aculo.us’ 는 앞서 설명한 책들의 기술(자바스크립트의 다양한 기술)과 더불어 DOM, CSS 에 대한 지식이 함께 필요로 하는 책에 가깝습니다. 
  흔히 생각하는 레퍼런스 서적에는 조금 거리가 있지만 그 안에 숨어있는 사상과 특징들을 쉽게 파악하여 프레임웍 자체의 큰 그림을 그릴 수 있는 내용들로 이뤄져 있습니다.  또한 DOM, CSS에 대한 궁금증과 기술 학습에 절실함을 느끼게 될 지도 모릅니다.  Prototype을 통해 Script.aculo.us는 탄생한 것 처럼 Prototype을 이용해 ExtJS와 같은 Grid 프레임웍도 탄생할 수도 있는 확장성까지…

간단히 레퍼런스 가이드 역할을 넘어서 자바스크립트를 이용한 Ajax/Rich UI Application을 만드는데 큰 도움을 줄 것입니다.


프로그래밍 JQUERY 상세보기
베어 바이볼트 지음 | 인사이트 펴냄
『프로그래밍 jQuery: jQuery in Action』은 숙련된 웹 개발자가 되려 하는 초보 웹 개발자들을 위해 유용한 클라이언트 측 도구인 jQuery를 소개한다. jQuery의 설계 철학을 충실히 다룬활용서이다. iQuery의...

jQuery in Action이라는 책은 읽어 보지 않아서 모르겠지만 국내에서 이미 jQuery 프레임웍을 사용한 서비스들이 곳곳에 있고 관심있는 개발자들도 상당한 것으로 알고 있다.  존 레식의 JavaScript의 노하우의 결정판이기 때문에 이를 통해 JavaScript와 DOM, CSS의 모든 기술적 이해를 위한 윤활유 역할을 분명 해줄 것이라 판단한다.  또한 책이 번역되기 위해 인사이트 출판사에서 뒷받침하고 있기 때문에 더욱 믿음이 간다.

이미 많이 나와있지만 레퍼런스가 없는 프레임워크(Dojo, Mootools, ExtJS 등)가 많습니다.  그에 반해 Prototype과 jQuery에 대해서는 국외를 포함 국내에도 많은 자료들을 얻을 수 있는 기회가 많아 졌습니다.  하지만 프레임워크을 이용하고 접근하는 것에 있어서 사상을 먼저 이해하려는 접근법이 매우 좋은 좋은 것 같습니다.(김영보 선생님께서 해주신 말입니다.)

자리잡아가고 변화하는 과정의 자바스크립트의 “Unobtrusive JavaScript” 번역하기 힘든 수식어 처럼, “오해가 깊은 언어”라는 관례적인 이해의 탈바꿈 과정에서 위의 책을 포함한 다양한 서적들이 많은 도움을 주리라 생각됩니다.  
  또한 JavaScript와 관련된 좋은 서적들이 더 많이 출간되었으면 좋겠습니다.



'책/잡지' 카테고리의 다른 글

JavaScript 에 관한 고찰과 책 소개  (13) 2008/09/11
좋은 생각  (0) 2008/04/22
javascript 책 소개  (0) 2008/04/14
올해 읽어 볼 전공 관련 서적!!  (5) 2008/02/14
원서를 읽어야할 이유  (6) 2008/01/04
마음에 양식 - 1日 30分 외 3종  (0) 2007/12/11
JavaScript | Posted by Rhio.kim 2008/08/31 18:11

Unobtrusive JavaScript 에 대한 고찰

프로포타입과 스크립타큘러스 상세보기
크리스토피 포트누브 지음 | 인사이트 펴냄
이 책은 자바스크립트 개발에서 필수적인 라이브러리가 된 프로토타입(Prototype)과 스크립타큘러스(script.aculo...프로토타입(Prototype)은 동적인 웹 애플리케이션 개발을도와주는 자바스크립트 라이브러리다....

인사이트 출판사에서 Prototype and Script.aculo.us 라는 책을 출간하면서 던졌던 Unobtrusive JavaScript에 대한 질문!!

많은 분들이 고심했지만 모든 분들이 딱히 어색하지 않고 만족할 만한 번역어를 찾지 못했습니다.
굳이 번역을 해서 국어로 표현할 필요는 없지만 그 의미를 확실히 알면 더 좋지 않을까 해서 이곳 저곳의 자료를 모아서 정리해봅니다.

사용자 삽입 이미지

Unobtrusive 라는 의미를 찾을 수 있는 사진 <실: HTML> <바늘 : JavaScript>



2008-03-06  Simon Willison
+ A set of principles for writing accessible, maintainable JavaScript
+ 쓰기 쉽도록 하고 계속 유지할 수 있는 자바스크립트를 위한 일련의 원리들
+ A library that supports unobstrusive scripting (jQuery)
+ unobstrusive 스크립팅을 지원하는 라이브러리

http://www.slideshare.net/simon/unobtrusive-javascript-with-jquery

2003 Steven Champeon and Nick Finck

Progressive enhancement (점진적인 향상)
Rather than hoping for graceful degradation PE builds documents for the least capable or differently capable devices first, then moves on to enhance those documents with separate logic for presentation, in ways that don't place an undue burden on baseline devices but which allow a richer experience for those users with modern graphical browser software…

요약> 위의 slideshare.net 에 있는 자료가 unobstrusive JavaScript에 대해서 가장 잘 설명하고 있는 것 같습니다.

2007-12 matt aimonetti - SDRuby
http://railsontherun.com
+ behavior oriented JS with (graceful degradation) progressive enhancement
+ 점진적인 향상(우아한 성능 저하)을 갖는 습성 지향적인 JavaScript

Wiki
http://en.wikipedia.org/wiki/Unobtrusive_JavaScript

  "Unobtrusive JavaScript" is an emerging technique in the JavaScript programming language, as used on the World Wide Web.
  "Unobtrusive JavaScript"는 JavaScript 프로그래밍 언어에서의 기술을 말하는 것이다.

  Though the term is not formally defined, its basic principles are generally understood to include
  일반적으로 정의되지 않았지만 그것의 기본 개념은 일반적으로 이해하는 다음의 것들을 포함한다.

  + Separation of functionality (the "behavior layer") from a Web page's structure/content and presentation
  + 웹 페이지의 구조, 콘텐트 그리고 표현으로 부터 기능("습성 레이어")의 분리
 
  + Best practices to avoid the problems of traditional JavaScript programming (such as browser inconsistencies and lack of scalability)
  + 고전적인(예전의 방식) JavaScript 프로그래밍의 단점을 피하기 위한 가장 좋은 예제이다. (브라우저 호환성 불일치와 확장성의 더딤과 같은)

+ Graceful degradation in browsers where the advanced JavaScript functionality will not work as desired
+ 고급 자바스크립트 기능은 브라우저에서 우아한 성능 저하로 원하는 만큼의 동작하지 않을 것이다.
 
  Best Practices
    Though the essence of unobtrusive JavaScript is the concept of a separate behavior layer, advocates of the paradigm generally subscribe to a number of related principles, such as:
    
    Strict adherence to the W3C DOM and event model, and avoidance of browser-specific extensions.
    More generally, JavaScript best practices often parallel those in other programming languages, such as encapsulation and abstraction layers, avoidance of global variables, meaningful naming conventions, use of appropriate design patterns, and systematic testing. Such principles are essential to large-scale software development, but have not been widely observed in JavaScript programming in the past; their adoption is seen as an essential component of JavaScript's transition from a "toy" language to a tool for serious development.

사용자 삽입 이미지

Unobtrusive 라는 의미를 찾을 수 있는 사진 <자물쇠: HTML> <바늘 : JavaScript>


JavaScript의 태생은 1995년 ‘웹 페이지에 생명을 불어넣기 위한’ 일환으로 넷스케이프 웹 브라우저에 공식 채택되었다. [Pro JavaScript Techniques인용 – 인사이트 출판사]

출시 당시만 해도 단지 웹 페이지의 좀더 강한 기능과 동적인 처리만을 위해서 쓰여졌기 때문에 HTML과도 섞이고 CSS와도 섞이는 단지 HTML의 <head> ~ </head>내에 존재하는 일부분으로 여겨져 왔습니다.

또한 HTML 태그안에서 잠재적인 인라인(inline) 스크립트로 기생해 왔습니다.

이렇듯 HTML 문서 내 다양한 곳에서 HTML과 CSS와 함께 뒤섞여 동작을 해오다 최근 다양한 프레임웍(Dojo, jQuery, Prototype, mootools, etc : 이것들은 unobstrusive의 가장 적합한 예제)이 나오면서 더 이상 HTML 문서 내에서는 JavaScript 소스를 찾아볼 수 없게 되었습니다.

단지 연관되어진 <script src=””></script> 하나를 제외하고는 말이죠.
이렇듯 이런 변화를 위에서 언급한 기사들처럼 국외 개발자들에 의해서는 "Unobtrusive JavaScript" 라는 합성어로 탄생하게 되었습니다.

이는 우리나라의 사전적 의미로는
un•ob•tru•sive〔              〕 a. 주제넘지 않은; 조심성 있는, 겸손한, 삼가는[naver 사전]
와 같은 의미를 갖습니다.

하지만 “주제넘지 않은 자바스크립트”, “조심성 있는 자바스크립트”, “겸손한 자바스크립트”, “삼가는 자바스크립트”  이 모두가 조금은 연관성이 있지만 완벽에 가까울 의미 전달은 어려워 보입니다.

Prototype and Script.aculo.us 라는 책의 역자이신 박영록님께서는 고심 끝에 “나대지 않는 자바스크립트”라는 표현을 사용하셨습니다.

 “나대지 않는” 이라는 단어가 함축하고 있는 의미를 살펴보면 여러가지 의미를 내포하고 있기도 합니다.   나대지 않는 다라는 것은 겸손하다라는 의미도 있고 주제 넘지 않는 이라는 의미도 지니는 것 같습니다.  

어떤 의미에서 JavaScript가 나대지 않는 다고 표현할 수 있을까요?  바로 상호 의존할 수 밖에 없는 HTML문서와 JavaScript의 역할에 있어서 비춰보면 될 것 같네요.  이에 HTML 문서는 JavaScript가 활동할 수 있는 Field 역할을 해줍니다.  그럼에도 불구하고 JavaScript가 웹 페이지의 동작에 관여를 하고 웹 페이지 소스 내에서 무자비하게 프로그래밍 되어있다라고 한다면 “HTML 입장에서는 JavaScript가 너무 나댄다” 라고 말할 수 있겠습니다.

짧은 소견으로는 나대지 않는 이라는 표현을 잠깐 사용했지만 프로그래밍적인 해석과는 어색하게 느껴집니다.  
여기에 사전적으로 남의 것에 참견하지 않고 방해하지 않으며 JavaScript의 주요 기능만 수행을 하는, 기술적으로 Behavior layer(습성 레이어) 를 완벽하게 분리하려는 목적을 충족하는 함축할 수 있는 의미가 무엇이 있을까 생각했습니다.

일단 의미 중 “JavaScript의 주요 기능만 수행”이라는 것은 무의미 하다고 가정합니다. 어떤 언어나 자신의 주요 기능만을 수행하는 것이 당연하며 JavaScript에서 이런 의미가 출현한 것은 고전적인 스크립팅 방식에서 탈피하는 과정에 있어서 나타난 의미일 수 있다고 생각을 하며 현재에는 ECMAS4가 발표되었고 완벽한 객체 지향 언어로서의 모습을 갖췄다 라고 볼 수 있기 때문입니다.

이에 주요 기능을 수행하는 의미는 퇴색되며 웹 페이지(HTML)과 JavaScript간에 동작하면서 간섭하지 않는 다라는 의미 즉 HTML과는 습성이 틀린 JavaScript가 상호 참견하지 않고 완벽히 분리되어 동작하는 것이 가장 강하게 표현되어야 한다고 생각해봅니다.

최근 발표된 프레임웍들 또한 이런 의미와 목표를 두고 개발되어진 것이 아닌가 생각해봅니다.  나대지 않거나 겸손하다는 것은 어떤 대상에 대해서 그러한 상태를 나타내는 것이기에 프레임웍이나 자바스크립트를 이용한 Rich UI를 개발하는 개발자들에게는 Behavior Layer의 분리에 좀더 중점을 두지 않았을까 생각해 봅니다.

그래서 저는 생각끝에 “Unobtrusive”를 “비간섭 혹은 비간섭적인” 즉 비간섭 자바스크립트 라고 정리해 봅니다. (발음 : 어넙트러시브 자바스크립트)

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.   &nb