Flash와 Flex에 와 함께 찾아온 RIA 기술에 발전은 MS의 실버라이트와 Oracle의 JavaFX 과 함께 시장에서의 기대치를 극대화 했었다. 하지만 현재에 이르러는 RIA 기술 전반에 걸쳐 주춤하고 있는듯 해 보인다. 

Technology Radar 2010 소개글인 "JavaScript 필수 프로그래밍 언어로!!" 에서도 발표 하였지만 RIA 기술은 채택(adopt) 에서 접근(access) 단계로 무관심해도 될 단계로 다가가고 있다.  

최근 국외 indeed.com에서 RIA 기술 Job Trend 검색결과의 추이를 살펴 보니 Adobe의 Flex의 기술보다 보다 뒤늦게 2007년에 시작된 오픈 웹 기술인 JavaScript로 개발된 Ext JS 프레임워크가 Adobe Flex를 뛰어 넘었을 뿐 아니라 시장에서의 개발자 수요가 급격히 상승하고 있다.



http://www.indeed.com/jobtrends?q=javafx,+extjs,+adobe+flex&l=&relative=1

도대체 뭐길레 뜬금없이 JavaScript 프레임워크와 Flex와 JavaFX와 비교 할까?


Ext JS의 특징
Ext JS는 오직 JavaScript와 CSS로만 이루어진 JavaScript 프레임워크로 Flex가 갖는 대부분의 기술을 구현하고 있을 뿐 아니라 Google Web Toolkit인 Ext-GWT 버전으로 Java 개발자도 웹을 통해 성숙한 UI(Tab, Toolbar, Menu, Grid, Drag & Drop,Tree, Panel, Chart 등)를 손쉽게 구현할 수 있다는 장점도 있습니다.
















뿐만 아니라 최근에 Ext Designer라는 Ext JS 전용 RAD(Rapid Application Development)를 발표하였습니다.  이 도구는 웹 상에서 데스크탑 애플리케이션과 동일한 GUI를 웹 환경으로 빠르고 손쉽게 옮길 수 있도록 지원할 뿐 아니라 일반적으로 웹에서 이러한 GUI를 구축하기 위해서는 하나의 기능만 구현함에 있어서도 상당한 양의 JavaScript나 CSS, HTML 코드가 필요하지만 예를 들어 델파이나 비주얼 베이직, C++빌더에서 처럼 Ext JS도 원시코드를 개발자가 직접 작성하지 않고 간단한 설정 만으로도 웹에서 다양한 GUI를 구축할 수 있도록 합니다.




Ext JS 2010 Roadmap
이미 예상했던 데로 Ext JS는 올해에 목표로 mobile용으로 가벼운 UI 엔진을 Ext JS 프레임워크에 탑재할 계획을 가지고 있습니다.(개인적인 추측이 였습니다.) 댜양한 컴포넌트를 추가적으로 개발하고 Ext JS 4.0에서는 HTML5 WebSocket, Offline 지원을 계획을 가지고 있고 HTML5의 가시화와 함께 HTML5에 대한 지원도 이어질 것으로 보입니다.

Appcelerator사의 Titanium 이나 nitobi.com에서 후원중인 PhoneGap과 같은 솔루션은 플랫폼(Andorid, iPhone, Symbian)에 상관없이 JavaScript만으로 Device API에 접근하여 내장(Native) 애플리케이션을 개발할 수 있도록 지원하고 있습니다.  

더욱이 이런 오픈 웹 기술은 플러그인 기술인 Flash나 Silverlight 에 비해 가볍기 때문에 데스크탑에 비해 부족한 디바이스에서도 높은 성능을 통해 사용자에게 좋은 경험을 제공할 수 있을 것입니다.


단점이 있다면
Ext JS에는 한가지 뼈 아픈 추억을 가지고 있는데 바로 초창기 유명한 라이브러리인 prototype, YUI, jQuery의 Adapter로 동작을 해왔었으나 독립적인 플랫폼으로 파생되면서 회사와 개발을 유지하기 위해서 유료화로 전환 되었습니다.

이로 인해 국내 시장에서는 단순한 JavaScript 라이브러리의 경쟁에 있어서 비교 우위를 선정하기 위한 대상 이였을 뿐 이였고 거기에 더해 유료 라이브러리라는 딱지가 붙어서인지 그간 관심 밖의 이야기였던게 사실입니다.
이로 인해 레퍼런스가 필요한 개발자들에게는 찾아보기 힘든 국내 이용 사례, 한글 레퍼런스 덕분에 전전 긍긍 Ext JS 포럼을 쥐 잡듯이 뒤져야 했습니다.


하지만 희망이 있다면...
국내의 시장에서 실상 RIA의 기술이 얼마나 요구되어질 지 알 수는 없으나 오픈 웹 기술은 날로 발전하고 기대치는 HTML5로 인해 연일 증폭되고 있습니다.  거기에 더불어 모바일도 뜨거운 감자로 그 니즈는 어디로 튀어 오를지 모른는 것입니다. 

이렇듯 웹은 링크를 기반으로한 웹 서핑과 정보의 유통이였다면 현재와 미래에는 플랫폼으로 발전되고 그 위에 오픈 웹 기술을 통한 응용 애플리케이션의 수요가 증가할 것이라는 것은 현재의 흐름인 것은 분명해 보입니다.

여기에 Adobe의 Flash, Flex의 기술보다 아직 가야 할 길이 많이 남은 MS의 Silverlight와 까마득한 JavaFX와 오픈 웹 기술인 Ext JS. 과연 그 흐름은 어떻게 될까?



신고
Posted by Rhio.kim

모델링 및 객체 지향 소프트웨어 기술 등으로 잘 알려진 Martin Fowler 씨가 속한 ThoughtWorks 와 MS가 현재의 기술 동향을 분석한 백서 “Technology Radar 2010(PDF)가 infoQ 기사로 소개되었습니다.

이 백서는 현재 어떤 기술 분야가 큰 관심을 받고 있는가 분석하여 기술(techniques), 도구(tools), 플랫폼(platforms), 언어(language)의 4가지로 분류하여 제시하고 있습니다.  

그리고 이 4가지 분야는 4개의 클래스로 나뉘어 항목을 그래프로 표시하였습니다.  각 클래스를 살펴보면 Adopt 항목은 기업의 사용을 추천한다, Trial 항목은 투자 가치는 있지만 위험이 적은 프로젝트에서 사용할 것, Assess는 사용 방법과 잠재 능력을 검토하고 배울 가치가 있는 항목 그리고 마지막 Hold는 현재 인기나 자원으로써 가치가 없는 항목을 나타낸다.

여기서 관심 과는 분야들에 대해서 요약해봅니다.


도구(tools) 차트 


노란 영역에 표시된 “IE6 end of life” 는 기업에서 받아들여야 할 Adopt 클래스에 있습니다.  이 자료는 MS가 현재의 기술을 동향을 분석한 것인데도 불구하고 IE6 도구로써의 생명은 끝났음을 알리고 있습니다.

그리고 버전 관리 툴인 Subversion은 후퇴하고 반대로 분산 버전 관리(Distributed version control)은 전진하고 있고 백서는 “Git과 Mercurial과 같은 분산 버전 관리도구가 최근 몇 년간 큰 주목을 받기 시작하였고 분산된 환경의 버전 관리를 요구하는 엔터프라이즈 시장에서 추진제 역할을 하고 있다고 설명하고 있습니다.


프로그래밍 언어 차트



JavaScript는 1995년에 등장했지만 최근 2~3년 사이에 Prototype, jQuery, Ext JS, Dojo와 같은 라이브러리가 등장하면서 개발자에게 풍부한 웹 애플리케이션 개발을 위하여 JavaScript를 사용하는 것을 백서에서 추천하고 있습니다. 

아래의 그래프로만 보더라도 JavaScript는 무관심에서 현재에 이르러서는 가장 주목할 만한 트랜드로 변화된 것이 틀림 없음을 나타냅니다.

또 하나는 Java의 움직임 도 Assess 단계이지만 Java의 진화는 더디고 새로운 버전이 나오려면 거의 3년에 가까운 시간을 기다려야 한하지만 Java VM 위에서 동작하는 새로운 언어 Groovy, JRuby, Scala, Clojure 등이 새로운 혁신이 될 것이라 기록하고 있습니다.


플랫폼 차트


그 중 가장 두드러지는 웹 브라우저에 Firefox와 언어 분야에서 언급했던 JVM 위에서 동작하는 새로운 언어들이 새로운 혁신에 앞장설 것이라는 것입니다.

모두 중심으로 향하고 있는 반면 유일하게 Rich Internet Applications 만이 바깥쪽을 향하고 있습니다.

이번 백서에서 가장 흥미로운 것은 JavaScript의 관심과 IE6가 도구로서의 생명이 끝났으며 Java와 JVM 그리고 JVM을 기반으로 하는 새로운 언어들의 기대되는 혁신입니다.


출처 : http://www.infoq.com/news/2010/01/ThoughtWorks-Technology-Radar


신고
Posted by Rhio.kim

모델링 및 객체 지향 소프트웨어 기술 등으로 잘 알려진 Martin Fowler 씨가 속한 ThoughtWorks 와 MS가 현재의 기술 동향을 분석한 백서 “Technology Radar 2010(PDF)가 infoQ 기사로 소개되었습니다.

이 백서는 현재 어떤 기술 분야가 큰 관심을 받고 있는가 분석하여 기술(techniques), 도구(tools), 플랫폼(platforms), 언어(language)의 4가지로 분류하여 제시하고 있습니다.  

그리고 이 4가지 분야는 4개의 클래스로 나뉘어 항목을 그래프로 표시하였습니다.  각 클래스를 살펴보면 Adopt 항목은 기업의 사용을 추천한다, Trial 항목은 투자 가치는 있지만 위험이 적은 프로젝트에서 사용할 것, Assess는 사용 방법과 잠재 능력을 검토하고 배울 가치가 있는 항목 그리고 마지막 Hold는 현재 인기나 자원으로써 가치가 없는 항목을 나타낸다.

여기서 관심 과는 분야들에 대해서 요약해봅니다.


도구(tools) 차트 


노란 영역에 표시된 “IE6 end of life” 는 기업에서 받아들여야 할 Adopt 클래스에 있습니다.  이 자료는 MS가 현재의 기술을 동향을 분석한 것인데도 불구하고 IE6 도구로써의 생명은 끝났음을 알리고 있습니다.

그리고 버전 관리 툴인 Subversion은 후퇴하고 반대로 분산 버전 관리(Distributed version control)은 전진하고 있고 백서는 “Git과 Mercurial과 같은 분산 버전 관리도구가 최근 몇 년간 큰 주목을 받기 시작하였고 분산된 환경의 버전 관리를 요구하는 엔터프라이즈 시장에서 추진제 역할을 하고 있다고 설명하고 있습니다.


프로그래밍 언어 차트



JavaScript는 1995년에 등장했지만 최근 2~3년 사이에 Prototype, jQuery, Ext JS, Dojo와 같은 라이브러리가 등장하면서 개발자에게 풍부한 웹 애플리케이션 개발을 위하여 JavaScript를 사용하는 것을 백서에서 추천하고 있습니다. 

아래의 그래프로만 보더라도 JavaScript는 무관심에서 현재에 이르러서는 가장 주목할 만한 트랜드로 변화된 것이 틀림 없음을 나타냅니다.

또 하나는 Java의 움직임 도 Assess 단계이지만 Java의 진화는 더디고 새로운 버전이 나오려면 거의 3년에 가까운 시간을 기다려야 한하지만 Java VM 위에서 동작하는 새로운 언어 Groovy, JRuby, Scala, Clojure 등이 새로운 혁신이 될 것이라 기록하고 있습니다.


플랫폼 차트


그 중 가장 두드러지는 웹 브라우저에 Firefox와 언어 분야에서 언급했던 JVM 위에서 동작하는 새로운 언어들이 새로운 혁신에 앞장설 것이라는 것입니다.

모두 중심으로 향하고 있는 반면 유일하게 Rich Internet Applications 만이 바깥쪽을 향하고 있습니다.

이번 백서에서 가장 흥미로운 것은 JavaScript의 관심과 IE6가 도구로서의 생명이 끝났으며 Java와 JVM 그리고 JVM을 기반으로 하는 새로운 언어들의 기대되는 혁신입니다.


출처 : http://www.infoq.com/news/2010/01/ThoughtWorks-Technology-Radar


신고
Posted by Rhio.kim
작년 한해는 JavaScript가 재평가 받고 더 발전하는 한해아니였나 생각해봅니다.  

국내의 변화
국내에서도 자바스크립트에 대한 인식의 변화가 가장 컸던 한 해가 아니였나 생각해봅니다. 
수 많은 웹 서비스에 다양한 오픈 소스들을 이용한 성숙한 UI와 UX를 제공하기 위한 노력들이 매우 많아졌습니다. 


JavaScript 프레임워크의 발전
그리고 국내 JavaScript 라이브러리도 NHN의 Jindo 에 이어 NHN의 nagoon97 님이 개발하여 대표적으로 Naver 스마트 에디터에   적용 개발되어진 Husky 프레임워크 그리고 김영보 선생님께서 개발중인 One Object 아키텍쳐를 근간으로 하여 메소드 체이닝 메커니즘을 특징으로 하는 MethodChain까지 국내에서도 고급 자바스크립트 기술을 위한 오픈 소스들이 발표되고 있습니다.

또한 메이저 라이브러리의 기술을 점점 더 발전해 가고 있을 뿐아니라 그 영역을 모바일까지 확장해 가고 있습니다.  또한 데스크탑 애플리케이션에서 경험할 수 있었던 것과 동일한 경험을 할 수 있도록 성숙한 UI 프레임워크로 발전해 가고 있습니다.



ECMAScript 의 변화 그리고 JavaScript 2.0
또한 이런 변화는 ECMAScript 5를 좀더 빨리 발전시키는 촉진제 역할을 하였고 올 9월에 표준안이 발표  되면서 브라우저 밴더 및 산업 전반에 걸쳐 JavaScript를 적용되어가고 있고 최근 ECMA Script 262 5th 이 지난 12월 15일 ECMA International에서 논의되고 최종 승인 발표를 하였습니다. 

이 ECMAScript 5는 JavaScript의 일반적인 명칭인 JavaScript 1.5 ~ 1.7와 같이 JavaScript 2.0이라고 칭하게 될 것 입니다.  사실 초기 ECMAScript 4의 기대와는 다르게 5th 에서는 설계상의 큰 변화는 없었습니다. 그중 가장 눈에 띈 것은 Native JSON 지원이라는 점입니다.  

현재까지(브라우저 밴더들이 적용하기 전)도 JavaScript JSON 형식의 데이터를 처리할 수 있습니다.  그러나 JSON은 데이터를 사용하여 검색하는 기능 때문에 잘못된 명령이 데이터에 있는 경우 보안 문제를 일으키는 원인이 될 우려가 있었습니다.   

JavaScript 2.0 JSON 지원은 JSON 데이터를 실행하고 평가하는 것을 지원하기 때문에 보안에 대한 걱정이 없어집니다.


속도경쟁
또한 올 한해 각 브라우저 밴더들의 속도 경쟁도 상당했습니다.  JavaScript에서 일어나고 있는 가장 큰 변화는 JavaScript 2.0의 변화보다 Web 브라우저에서 전개되고 있는 속도 경쟁일 것입니다.

올 Chrome는 V8라는 JavaScript 엔진을 탑재하면서 엔진의 속도를 설명하기 위해 다양한 실험에 대한 증명을 Chrome Expoeriments  를 통해 해주고 있습니다.  그외 Firefox의 경우 3.5에서 새로운 TraceMonkey 엔진을 탑재, Safari에 기반에 Webkit에서는 SquirrelFish JavaScript 엔진을 개발하고 있습니다.  Opera의 경우에도 Carakan 을 속도 경쟁하고 있습니다.



JavaScript 의 영역의 확대

출처 http://en.fotolia.com/id/11626485

자바스크립트의 영역은 인터넷이 생기고 웹 이라는 것은 HTML을 이용하여 문서(Document)를 표현하고 링크를 통해 또 다른 문서로 이동하거나 간단한 폼 전송을 통한 서버와 클라이언트의 커뮤니케이션을 가지고 있었습니다.  여기에서 JavaScript의 영역은 극히 제한적이였습니다.  아니 제한적일 수 밖에 없었습니다.

하지만 점차적으로 발전하면서 현재에 이르러는 인터넷의 문서에 제한되지 않고 애플리케이션을 위한 플랫폼으로 발전해 나가고 있습니다.  이에 자바스크립트는 DOM 제어와 AJAX를 활용한 가벼운 인터넷 애플리케이션 개발 언어로 새롭게 해석됩니다.  
뿐만 아니라 JavaScript 프레임워크의 발전은 성숙한 UI를 지진 Ext JS나 YUI와 같은 RIA 개발을 위한 도구로도 사용되는데 손색이 없을 정도입니다.  Ext JS의 경우에는 이미 국외에서는 Ext JS를 사용한 솔루션이 조금씩 개발되어 판매에 이르렀습니다.

하지만 그 영역은 Web2.0의 시대와 함께 찾아온 개방과 함께 Open API가 방대해졌고 그것을 이용한 기본적인 API들이 JavaScript로 개발되어졌습니다.  이를 통해 다양한 Mash-Up 애플리케이션이 개발되어졌고 이렇게 발전해온 JavaScript의 영역은 올 한 해에도 그 영역을 Server Side 개발을 위한 Jaxer, 모바일 영역, 데스크탑 애플리케이션 개발을 위한 도구로 관심의 영역을 넓혀갔습니다.

이에 도움을 준 요소들 또한 많습니다.  일단 가장 큰 이유중의 하나는 웹 표준의 발전일 것이고브라우저 밴더들의 속도 경쟁, 다양한 오픈 소스 프레임워크의 발표, 개발도구의 진화 또한 보탬을 하였습니다.

최근 iPhone의 발표로 국내에서도 엄청난 열기를 더해가고 있는데 Web2.0 Expo의 론치패드에서 극찬을 받은 PhoneGap 이라는 솔루션은 HTML, JavaScript, CSS 를 이용하여 iPhone 뿐만 아니라 Android, Blackberry 등 크로스 플랫폼 모바일 애플리케이션을 개발할 수 있는 플랫폼을 제공한다는 것입니다.  


JavaScript의 영역과 변화 요소



  
JavaScript 의 미래
이처럼 지난 한해는 언어로서 성장하고 JavaScript가 웹 브라우저에서만 사용할 수 있었던 것이 그 영역이 브라우저 밖으로도 유용하게 활용 될 수 있도록 되었다는 것입니다.

또한 2010년에는 Chrome OS와 같은 넷북을 기반으로 할 운영체제, 다가오는 모바일 웹 애플리케이션 시대에는 웹 표준과 함께 JavaScript의 지배력이 좀더 높아질 것입니다.
http://www.youtube.com/watch?v=AusOPz8Ww80
http://www.readwriteweb.com/archives/web_vs_native_mobile_apps.php

 

출처 http://almaer.com/blog/the-development-circle-of-life



신고
Posted by Rhio.kim

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를 첨부합니다.

신고
Posted by Rhio.kim
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의 특정한 개발을 위한 방법론에 가깝다고 봐도 무방합니다.  또한 개인적인 경험에 의한 정리이며 일반적인 시스템 설계에서 말하는 패턴의 정의와는 상이하거나 다른 의미를 갖을 수 있습니다.

신고
Posted by Rhio.kim
사용자 삽입 이미지

<< 일반적인 디자인 패턴 >>

이 그림을 보고 과연 어떤 팁일까?
이해하지 못하시는 분들도 이해하시더라도 보잘것 없어 보일 수도 있겠습니다.
하지만 좀더 깊게 생각해보면 다양한 이점이 숨어있습니다.

위의 그림을 구현하는 것은 매우 간단해 보입니다.
하나의 영역에 로그인 화면과 로그아웃 화면에 함께 표출 되도록 디자인을 하고 display 값을 통해서 로그인 상태, 로그아웃 상태를 볼 수 있음을 의미합니다.

만약 서버 사이드 개발자라면 이런 경우 if문을 통해서 사용자가 로그인한 경우라면 로그인 된 상태의 HTML 소스를 표시하고 그렇지 않는 경우 로그인 할 수 있는 화면 소스를 표시할 것입니다.

그리고 디자이너라면 로그인 된 HTML 파일, 로그인 되지 않는 HTML 파일로 각각 디자인을 처리하는 경우가 많을 것입니다. (꼭 그렇지 않는 경우도 있습니다.)

이런 방식은 Web1.0 방식의 전형적인 방식으로 Ajax 개발 시에는 좀더 웹 표준을 준수하고 사용자의 경험을 존중해줄 수 있는 HTML Design 설계를 해야할 것입니다. 

그에 있어 위의 그림은 기본적인 화면 설계 방법중에 하나일 것입니다.


요약해보면 크게 아래와 같은 이점이 있습니다.

첫째
디자이너와 개발자 모두 하나의 페이지에서 다양한 액션을 프로토타입핑 손쉽게 해볼 수 있습니다.


둘째
하나의 페이지에서 일어나는 액션과 사용자 경험에 대한 것을 모두 담고 있기 때문에 관리할 페이지가 줄어듭니다.  (예를 들어 여러 페이지에 적용되어있던 css가 변경되어질 경우가 불 필요한 작업량이 줄어든다.)


셋째
Ajax/Rich UI 개발자들에게는 엘리먼트의 CSS class name 통해서 원하는 처리를 손쉽게 할 수 있다.



디자이너에게도 Ajax/Rich UI 개발을 위한 기술적인 이해와 사용자 경험(User Experience)에 대한 요구 사항을 디자인 단계에서 부터 적용시켜야 한다는 것입니다.


사용자 삽입 이미지

<< 사용자 경험과 Ajax/Rich UI를 위한 디자인 패턴 >>


로그인 UI에 관한 부분을 위에서 설명한 부분을 추가해 다시 한번 그려 보았습니다.

네모단 박스는 모두 div이고 로그인 실패 알림 영역과 인디케이터 부분까지 표시를 한다는 것
기획자와 디자이너, 퍼블리셔, 디벨로퍼까지 모든 부분에서 사용자 경험(user experience)에 대한 부분에 관심을 갖고 기획하고 디자인을 하고 퍼블리싱을 하고 개발을 해야하지 않을까 생각해봅니다.

각 분야에서 자기만의 업무 분야도 중요하지만... 하나의 본질은 웹 서비스를 사용하는 사용자에게 장애없이 원한할한 서비스로서 만족감을 느끼게 하기 위함이니 늘 서로가 고민해야할 부분인것 같습니다.


신고
Posted by Rhio.kim

Design by Design Pattern정의


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

목적 및 장점 :
1.    HTML로 구성되어진 레이아웃을 ( HTML 파일 자체를) 개발자에 의해서 추가되거나 수정되지 않는데 목적을 둡니다.  즉 디자인과 개발의 완벽한 분리를 꾀하는데 목적을 둠
2.    유지보수에 있어 디자인과 개발의 업무량을 최소화 하기 위함
3.    초기 접속 시 불필요한 동적 렌더링을 피할 수 있다.

조건 :
1.    디자인 시 거의 모든 부분이 Div 구조로 디자인 되어야 한다.  Table과 같이 다른 특성을 가지고 있는 영역끼리 하나의 Layout으로 연관되어 질 경우 개발자에 의해서 처리되는 로직이 매우 복잡해진다.
2.    디자인 시 특징이 다른 Div Element에는 유니크 한 ID를 부여할 수 있어야 한다.
3.    개발자가 ID를 부여할 경우에 개발 설계에 의한 최소한의 ID만 부여해야 한다.
4.    부분적으로 Table 을 사용해야 할 경우 개발자의 협의가 필요할 수도 있다.


제약 :
1.    개발자뿐만 아니라 디자이너도 DOM 에 대한 기술적 이해가 필요하다.

단점 :
1.    HTML의 구조가 변경되면 구조에 맞게 javascript개발 부분도 변경되어야 한다.
즉 HTML 버전관리와 Javascript 버전관리가 함께 이뤄져야 합니다.
2.    페이지 접속 시 디자인 레이아웃의 흐트러짐 현상이 있을 수 있다.


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

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


Aptana Jaxer: An interview with the Aptanians from Dion Almaer on Vimeo.

Paul Colton, Uri Sarid, Kevin Hakman 와의 인터뷰 내용입니다.
  • Jaxer "server isde Ajax framework" 는 어떻게 생각해냈는지..
  • server side Javascript framework과 Jaxer 의 차이점
  • Jaxer의 작동 원리
  • Jaxer 사용시 부작용
  • 개발자들의 사용법
  • Jaxer를 사용한다면 아키텍쳐의 변경 방법
  • Javascript 2에 관해
  • Jaxer의 향 후

media link : http://www.vimeo.com/698776/
신고
Posted by Rhio.kim
사용자 삽입 이미지

크로스 도메인 Ajax 가 파이어 폭스(firefox 3) 에서 지원을 하게 되었습니다.
W3C 표준에 Access Control working draft 에 대한 기사가 있는데요.

파이어폭스 3에서는 이부분을 벌써 적용중이네요.










php code

javascript
신고
Posted by Rhio.kim
몇일 전 Julien recomte 씨가 Yahoo! 에서 발표한 고성능 Ajax Application 자료입니다.
다룬 내용은
  • Developing for high performance
  • High performance page load
  • High performance JavaScript
  • High performance DHTML
  • High performance layout and CSS
  • High performance Ajax
  • Performance measurement tools
ppt 자료 :




신고
Posted by Rhio.kim
사용자 삽입 이미지
Ajaxian 의 2007 Ajax tool 투표 결과입니다.

올 한해 다양한 Javascript Library 들이 출시 되고 출시되었던 라이브러리들도 기능 강화와 OOP 개발이 가능하도록 라이브러리화 되었습니다.

Prototype 의 강세는 여전하네요..
다만 jQuery가 그 뒤를 바로 뒤쫓아오네요..

Ext JS 가 3위에 등극했다는 것은 상당히 !!

외국에서는 그리드 형식의 Ajax 어플리케이션을 선호하나봅니다.

웹 상에서 구현하기 힘든 그리드 형식의 어플리케이션 개발이 한결 수월해졌기 때문인데요.

아마 웹 기반 CRM 같은 개발 혹은 관공서나 국가 기간같은 디자인적인 부분을 많이 신경 쓰지 않고 기능 위주의 인터페이스에서 아주 효율적인 어플리케이션 개발이 가능하다는 것이죠.

상당히 발전할 수 있어 보입니다.

Script.aculo.us 는 Prototype을 모태로 상당히 많은 유저층을 이루고 있습니다.  둘이 함께 이용한다면...
60% 정도를 장악하고 있네요.  하지만 이제 jQuery와 interfaceElement 까지 나와서 내년 2008년은 어떻게 바뀔지 모르겠네요...

내년은 아무래도 더 많은 javascript library가 발표 되리라 예상됩니다.

또한 UI 라이브러리인 Mootools와 Yahoo 인터페이스에 최적화 되어있는 YUI 아주 많이 사용하고 있네요..
Mootools 는 깔끔한 UI 처리가 가능하고 Effect 별 모듈러를 지원해 필요한 UI 모듈만 따로 모아 js 라이브러리 파일을 생성해서 사용할 수 있습니다.

YUI는 야후의 javascript 아키텍쳐인 douglas crockford 씨의 개발 설계가 숨어있고 Yahoo라는 대형 서비스에서 검증된 실로 Prototype 못지않게 공부해 볼만한 UI 라이브러리라 생각되어집니다.

하지만 단점이라면 Yahoo에 최적화된 라이브러리이고 국내 정서에 자신의 사이트에 Yahoo라는 라이브러리를
써야한다는 자존심 괘난 자존심도 생기게 되구요.!!   다른 이유도 많이 있겠죠...

마지막으로 여전히 자체 개발한 Ajax Tool을 사용한다는 것..
어쩌면 내년에는 더 많아질지 모르겠다는 생각이 입니다.

사실 그랬으면 좋겠습니다.
좀더 많은 소스타입의 다양한 형태의 라이브러리가 많이 출시 되었으면 좋겠습니다.
신고
Posted by Rhio.kim
Ajax 브라우저별 HTTP Connection 에 대한 테스트 및 고찰!!
그동안 Ajax 통신은 Wininet.dll (Window 32 Internet API) 로만 통신을 하는 줄 알았습니다.

FF에서 Ajax 최대 커넥션 및 HTML document component 병렬(parallel Downloads)다운로드 테스트 하다가
알게 되었습니다.

사용자 삽입 이미지







각 Ajax 요청에 따른 서버 모듈은 PHP 입니다.

<?php
  sleep(5);
  echo "{ complete : 'ok' }";
?>

즉 단지 5초 동안 대기 한 후 결과값을 반환합니다.

테스트한 결과에 대해 살펴 보겠습니다.


Internet Explore 의 경우

사용 모듈 wininet.dll 을 사용합니다.
그리고 Max-Connection 개수는 아래의 레지스트리 값을 참고합니다.  따로 레지스트리를 건드리지 않은 상태라면 아래의 dword 의 값은 00000002 입니다.

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
  "MaxConnectionsPer1_0Server"=dword:00000002
  "MaxConnectionsPerServer"=dword:00000002

기본 적으로 Ajax 통신은 2개의 커넥션만 가능하게 됩니다.

위의 테스트 할때 커넥션이 몇개 만들어지는지 TCP/IP 커넥션 개수를 보겠습니다.
사용자 삽입 이미지

좌측에서 보는것과 같이
3개의 커넥션이 맺어집니다.

제 레지스트리이에는
00000040 으로 설정되어
있습니다.

16진수로 64개의 커넥션을
허용해 놓은 상태입니다.

그래서 기본적으로 권고하는 2개의 커넥션보다 더 많은 Ajax 요청을 허용하게 됩니다.

Ajax 통신이 완료되면 자동으로 커넥션은 close 됩니다.












이때 과연 어떤 window 모듈을 사용할까요...
사용자 삽입 이미지
좌측에서 보이는 것 처럼 IE에서는 WININET.dll을 사용합니다.















FireFox 의 경우

network.http.max.-persistent-connections-per-server
사용자 삽입 이미지
좌측은 firefox의 config 정보 입니다. IE에서의 레지스트리와 동일한 일을 하는데요.

firefox 의 경우 주소 부분에 "about:config" 라고 입력해서 이동하시면 좌측과 같은 창이 보입니다.  필터 부분에 "network.http.max" 라 입력하시면 IE 의 레지스트리 부분과 유사한 기능을 하는 부분이 보입니다. 위 이미지에서는 파랗게 처리된 부분이 그 부분입니다.

저 같은 경우는 값이 2로 셋팅되어있습니다. 예제 페이지에서는 3개의 Ajax 요청을 합니다.


사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지





























































































위의 이미지 처럼 순차적으로 2개가 완료되고 나면 나머지 1개를 처리하게 됩니다.
당연한 이야기죠..

이어서 과연 Firefox도 Wininet 을 사용하지 않습니다.
사용자 삽입 이미지
mswsock.dll 을 사용해서 Ajax통신을 하게 됩니다.

사실 여기까지만 테스트를 하려고 했으나

혹 Opera 나 Safari 도 궁금할까 해서 간단하게 내부적으로 어떤 모듈을 사용하는지 찾아봤습니다.








Opera의 경우
역시 Opera 도 브라우저에 Config 를 따로 지원합니다. 당연히 브라우저기 때문에 브라우저에 설정 기능이 있어야 하는데.. IE 만 유달리 윈도우 레지스트리에 종속적으로 움직이네요...  별로 싫어집니다..

오페라의 경우도 주소줄에 opera:config 라고 입력하면 뜹니다.
사용자 삽입 이미지
















위의 값 중 Max Connections Server 값입니다. Opera의 경우 기본 값이 8입니다. FF와 같이 동일합니다.

사용자 삽입 이미지
Opera 의 경우도 mswsock.dll 을 사용하여 Ajax 요청을 처리하고 있습니다.














Safari의 경우
Safari 는 Info.plist 파일에 정보를 가지고 있다고 해서 찾아 열어봤지만 어떤 파일인지 찾지 못했습니다.
ㅠ.ㅠ 아무튼 유사한 방식으로 Max Connection 을 설정하고 있습니다.
Safari의 경우도 8정도로 설정되어 있는 것 같습니다. Ajax 요청을 한꺼번에 3개를 요청했는데 이상없이
3개를 동시에 처리 하더군요...

사용자 삽입 이미지
Safari 역시 mswsock.dll 을 사용하여 Ajax 요청을 하는 걸로 들통 났습니다.

















그런데 왜 굳이 IE는 지금 시스템을 고치려 하지 않을 까요?
Window 에서 돌아가는 브라우저들이라 해서 IE는 윈도우 깔면 자동으로 깔리는 임베디드형 어플리케이션이라서 W3C에서 권고한 DOM Standard도 따르지 않고 레지스트리에다가 설정하고 Wininet.dll 을 사용하고

기본 설정이 왜 2여야만 하는지 좀 다른 브라우저하고 표준에 대해서 Standard 에 대해서 논의 해보고 좀 맞추면 안되나?? 
신고
Posted by Rhio.kim
신고
Posted by Rhio.kim
원본출처 : http://developer.yahoo.com/performance/

웹 개발 / 웹 UI 개발자들이 꼭 알아야 할 부분입니다. 이런 부분까지 자세히 모른다면 점점 코더로
전락하는 길입니다.

최적화된 퍼포먼스를 통해서 유저에게 최적의 UI를 보여주는 역활을 할 수 있구요.
Yahoo 개발자 네트워크게 가보면 다양하고 유용한 정보들이 참 많네요...

High Performance Videos

Yahoo! performance chief Steve Souders joined with Plaxo's Chief Platform Architect Joseph Smarr to reprise a couple of talks they gave at OSCON this year. These presentations are now available on YUI Theater.

Rules for High Performance Web Sites

The Exceptional Performance team has identified 13 rules for making web pages fast. Each rule is discussed in the Developer Network Blog articles listed below.

  1. Make Fewer HTTP Requests
  2. Use a Content Delivery Network
  3. Add an Expires Header
  4. Gzip Components
  5. Put CSS at the Top
  6. Move Scripts to the Bottom
  7. Avoid CSS Expressions
  8. Make JavaScript and CSS External
  9. Reduce DNS Lookups
  10. Minify JavaScript
  11. Avoid Redirects
  12. Remove Duplicate Scripts
  13. Configure ETags
신고
Posted by Rhio.kim

YUI compressor 이 릴리즈 되었네요 오랜만에 봐서 몰랐는데..


I implemented a few enhancement requests and fixed a bug in this new version of the YUI Compressor. Let me know if you encounter any issue with it.

Update (9/27/07): YUI Compressor version 2.2.2 is now available. It fixes a lot of bugs that have been reported recently. By the way, I really appreciate all the bug reports, so keep them coming!

Update (9/28/07): New bugs have been reported and fixed in version 2.2.3 now available for download (check out the CHANGELOG file in the download page) And keep these bug reports coming!

Update (10/1/07): A few more minor bugs have been fixed in version 2.2.4. Thanks for the bug reports!


사용법 1 : java -jar yuicompressor-2.2.jar -o output.js input.js

사용법 2 : java -jar yuicompressor-2.2.jar --type js < input.js > output.js


Download version 2.2.4 of the YUI Compressor

신고
Posted by Rhio.kim
원본 출처 : http://www.rockstarapps.com/samples/performance/

javascript 다양한 로우레벨 퍼포먼스 테스트를 한 사이트가 있네요.
자주 사용하는 부분이 Array와 HTML! 부분인데 사용에 따라 1초 이상 걸리는 경우들도 있네요.
클라이언트 사양에 따라 많이 다르겠지만 저는 이런 테스트 결과가 나왔네요.

ARRAY
Description Total Time (ms) Per/Call (ms)
Array access
Array index value change
Empty Array index value change
Empty Array add three values
Empty Array with set size
Empty Array using constructor

Push element onto an Array x5000
Pop element of an Array x5000
Push element onto an Array x5000
Shift elements off the front of an Array x100
Join the array into a string (4900)
Push element onto an Array x100
Sorting of an Array x1000

Math.max(7.25,7.30)
Math.min(7.25,7.30)
47
63
125
140
157
140

31
954
31
172
15
94
78

63
78
0.00235
0.00315
0.00625
0.007
0.00785
0.007

0.0062
0.1908
0.0062
1.72
15
0.0047
0.078

0.00315
0.0039

HTML!
Description Total Time (ms) Per/Call (ms)
Change text using innerHTML (1000x)
Create a text node on HTML Dom (1000x)
Change the class name of an element (1000x)

getElementById
getElementsByTagName("div")
getElementsByTagName("spa")
getElementsByName

placeDiv.getAttribute("id") x20000
placeDiv.attributes["id"] x20000
var atts = placeDiv.attributes; atts["id"].name x20000
var atts = placeDiv.attributes; atts.id.name x20000
188
141
265

1406
2531
2407
1453

453
485
187
172
0.188
0.141
0.265

0.0703
0.12655
0.12035
0.07265

0.02265
0.02425
0.00935
0.0086


This application tests the performance of many different low level calls. Knowing how each browser will perform on basic functionality will allow developers to create best practices for code in their JavaScript library.

You will be amazed at how fast you can make your application go by understanding the basic performance characteristics of the JavaScript language. Also it is important not to just run these test on Firefox, but on all browsers to see the difference between them. Feel free to modify the code to test other things that you may have found to be problematic.

The absolute times are not important and will vary from run to run. What is important is the difference in times between browsers and between two different ways to do the same thing. Performance tuning you application will take time, you can use the jsLex project to help out when you need to quickly find a bottleneck in your code..
신고
Posted by Rhio.kim

원본 출처 : http://www.vulgarisoip.com/2007/06/21/minify-your-external-javascript-and-css-with-php/

대충 내용을 요약하자면 기본적으로 IIS나 Apache 에서 Gzip Compressor가 지원되는데요.
그것보다 좀더 로딩의 최적화를 할 수 있는 라이브러리 입니다.
Gzip된 파일을 다시한번 PHP Minify 라이브러리를 거치면 약 10%정도의 향상을 가져옵니다.

Yahoo "YSlow for Firebug" JS 항목에서 A평가를 받을 수 있습니다.

First off, I have to say that most of the work that went into this project was already done for me by someone named rgrove. You can find the original (PHP 5) version of Minify here. All I’ve done is convert the code to run on servers still using PHP 4 (download here). This article presents a justification for using Minify over other techniques, and the results of converting www.appelrouthtutoring.com to use the library.

Most modern web sites today are seperated into the three main parts: semantic HTML, presentational CSS and functional JavaScript. Any HTML page you visit can be supported by multiple CSS and JavaScript files, each one requiring it’s own HTTP connection and download. When a website starts using multiple style sheets and the latest fancy JavaScript libraries (I’m looking at you jQuery, Prototype, MochiKit, YUI, Ext, Dojo Toolkit…) mixed with their own personal scripts, things can start getting pretty slow even on the fastest connections.

One solution is caching these files, but this still requires an HTTP connection every time the browser has to check for the latest versions. You could use an expiration time far off in the future, but you better make sure your code works perfectly the first time a user downloads it. Another problem with this technique is that pages served over HTTPS will never be cached; obviously for security reasons.

A second solution used by many major sites like Google and by libraries like jQuery, is to pre-compress any JavaScript so that file downloads are quicker. Dean Edward’s packer is an excellent tool in this regard. While this is a big help to anyone stuck with dial-up, users with fast connections will not notice a remarkable difference due to the identical latency for downloading an uncompressed or compressed JavaScript file. This also adds another step to the building, testing and deployment process because you definitely don’t want to be developing a site while debugging obfuscated code.

Minify is a PHP library that automates the process of concatenating and compressing multiple CSS and JavaScript files. This is a “free” way to improve the experience for anyone visiting your site; everything just loads faster. How much faster? Before I deployed the minified version of www.appelrouthtutoring.com, I tested the average download time of the homepage with Fasterfox, a Firefox extension. I reloaded the homepage 10 times, clearing the cache every time, and found the average load time to be 3.343 seconds.

That would be a good average time for a content heavy site like www.cnn.com, but not for the super simple mostly text web site I tested. After uploading the site using my modified Minify library, the average load time dropped to 1.228 seconds. Again, that’s an average after 10 reloads with no caching. That’s a speedup of 272%(!), with absolutely no effect on the development process for the site.

I found a similar speedup on the intranet part of the site. Load time fell from an average of 4.994 seconds to 2.329 seconds (214% speedup!). While this doesn’t exactly double the productivity of employees using the intranet, it sure makes life a lot easier.

It’s code time (the exact code I use on the homepage):

[do this before writing any HTML]

require_once('minify_php4/minify.php');

// Create new Minify objects.
$minifyCSS = new Minify(TYPE_CSS);
$minifyJS = new Minify(TYPE_JS);

// Specify the files to be minified.
// Full URLs are allowed as long as they point
// to the same server running Minify.
$minifyCSS->addFile(array(
'/styles/fonts.css',
'/styles/nifty.css',
'/styles/public.css',
'/styles/calendar.css',
'/styles/navigation.css'
));

$minifyJS->addFile(array(
'/scripts/jquery.js',
'/scripts/nifty.js',
'/scripts/public.js'
));

[do this in <head>]

<style type="text/css"><?php
echo $minifyCSS->combine();
?></style>
<script type="text/javascript"><?php
echo $minifyJS->combine();
?></script>

It’s so easy, it should be a crime to load multiple external files the old-fashioned way. Let’s all make the web a better place and start cutting down those load times!

신고
Posted by Rhio.kim
사용자 삽입 이미지

javascript oop - class diagram


Javascript OOP 개발을 해오면서 과연 이 것이 OOP 일까? 아닐까?
라는 생각을 많이 했습니다.

OOP like 에서 OOP로 많이 탈바뀜 해가는 것은 확실합니다.
사실 부족한 부분도 많이 있을 것입니다.

위의 다이어 그램은 여러번의 시행착오로 javascript OOP 개발을 위해서 가장 효율적은 소스관리
OOP 개발방법, 유지보수의 간소화 등 다양한 목적을 담아서 도식화 하였습니다.

실제 MVC 개념도 포함되어 있습니다.

이는 Prototype.js 라는 오픈 프레임 워크 덕분에 실제로 OOP에 너무나도 가까운 개발을 할 수 있게
되었고 Prototype.js 가 아니였다면 위의 다이어그램에 있는 것을 포함한 다양한 클래스들이
더 많이 생성되어야 합니다.

Prototype.js 외에도 다양한 형태의 다양한 목적을 갖는 프레임워크들이 많이 있습니다.
Web2.0 방식의 개발방법을 채택하면서 웹 페이지가 아닌 실제 웹 어플리케이션을 제공할 수 있게 됩니다.

이에 javascript OOP 개발은 점점 더 절실해 집니다.

위의 다이어 그램을 간단히 설명하면.

최초 HTML document 가 요청되고 onload 가 되면 Controller 이 작동합니다.
새로운 인스턴스에 controller 가 생성되고 (이하 컨트롤러) 컨트롤러는 실제 어플리케이션을 구동시키기 위한

초기화를 담당하는  (TInitialize)에 의해서 Web Application을 구동하기 위한 준비를 합니다.

사용자 인터페이스 (TUserInterface), 사용자의 이벤트를 관리하는 이벤트 메니저 (TEventManager)가 있으며

사용자 이벤트가 발생하거나 실제로 UI에 서버의 데이터를 보여줄 UI에 뿌려주고 사용자의

이벤트가 발생하였을때 (TImplementation)는 그에 반응, 응답으로 결과를 표현한다.

이처럼 사용자의 이벤트를 캡쳐하고 그 이벤트에 해당하는 처리(서버 데이타 요청, UI의 변경, 사용자 요청에 응답) 를 대응합니다.

TModel은 각 모듈별 공동 사용 모듈을 캡슐화, 구체화, 확장하여 사용할 수 있도록 하여

확장을 통해 재 사용할 수 있고

마지막으로 TDestory에 의해서 생성된 인스턴스며 사용되지 않는 자원에 대한 리소스 반환자

역활을 담당합니다.

아시다시피 IE나 FF나 모든 브라우저에서는 리소스(이벤트, DOM오브젝트 등)관리를 소홀히 했다가는

메모리 누수에 헤어나올 수가 없어집니다.

좀더 좋은 내용을 포스팅 하고 싶었는데 아직 배워가는 상태라 부족함이 많습니다.

글 가운데 오탈자나 잘못된 내용이 있으면 알려주세요...
신고
Posted by Rhio.kim

DOM 레벨 0의 이벤트 핸들러
1. 동일한 객체의 동일한 이벤트에 대해 여러 개의 이벤트 핸들러를 지정하더라도 마지막으로 지정한 함수만 유효하다.
2. 모든 브라우저에서는 인라인 이벤트 처리 방식을 지원하지만 가급적 사용하지 않는 것이 좋다.
3. 이벤트 처리 함수에서 false를 반환하면 기본 처리 방법이 실행되지 않는다.

이벤트 객체
1. Event 객체는 모든 이벤트와 관련이 있다.
    - IE에서는 Event가 window 객체의 property이다.
2. 여러 브라우저에서 공통으로 사용 가능한 Event property
    - altKey, clientX, clientY, ctrlKey, keyCode, screenX, screenY, shiftKey, type
3. 기능은 같지만 브라우저 마다 다른 Event property
    - IE: fromElement, toElement
      NE: relatedTarget, currentTarget
    - IE: srcElement
      NE: target
4. cross browser
    - var src = theEvent.target ? theEvent.target : theEvent.srcElement;


이벤트 버블링
1. 여러 개의 중첩되는 엘리먼트(페이지에서 동일한 위치를 차지하는 객체들의 집합)에 이벤트 발생 시 이벤트가 쌓여있는 엘리먼트의 맨 위에서부터 아래로 전달된다.
2. 이벤트 중간에 해당 이벤트 버블링을 취소할 경우
    - IE: cancelBubble -> (boolean)
      NE: stopPropagation -> (function)
    function stopEvent(e) {
        if(e.stopPropagation) {
            e.stopPropagation();
        } else {
            e.cancelBubble = true;
        }
    }



DOM 레벨 2의 이벤트 모델
1. 특정 이벤트 핸들러 property에 의존적이지 않다.
    - 하나의 이벤트나 객체에 다수의 이벤트 핸들러를 등록시킬 수 있다.
2. 메소드
    - addEventListener, removeEventListener, dispatchEvent
    - IE: attachEvent, detachEvent
3. addEventListener 구문형식
    - obj.addEventListener('evnet', eventFunction, boolean)
        세 번째 인자는 이벤트 처리 방식이다. false면 bubble-up, true면 cascade-down
4. IE에서 고려해야 할 사항
    - 각 이벤트 핸들러마다 메모리가 할당된다. 따라서 unload 이벤트를 캡처하여 detachEvent로 설정된 이벤트를 제거해야 한다.

신고
Posted by Rhio.kim
http://ajaxchess.pragmaticlogic.com/
똑똑한 Ajax 장기

http://www.janis.or.jp/users/segabito/JavaScriptMaryo.html
슈퍼마리오

최근에 javascript, flash, dhtml로 구현한 알카노이드를 봤는데..
잘 구현했다고 생각했었는데.. 이젠 슈퍼마리오, 장기도 나오네요...

간단하지는 않지만...
고스톱, 기타 그래픽적인 요소가 많은 게임을 제외하곤 Javascript로도 충분히 다양한
게임을들 구현할 수 있겠네요..

Application보다야 더 유연하게 작동되지는 않겠지만
그래도 잠깐잠깐 즐길만한 게임은...
신고
Posted by Rhio.kim

EventManager.js

JavaScript/News 2007.05.18 19:45
/*
* EventManager.js
* by Keith Gaughan
*
* This allows event handlers to be registered unobtrusively, and cleans
* them up on unload to prevent memory leaks.
*
* Copyright (c) Keith Gaughan, 2005.
*
* All rights reserved. This program and the accompanying materials
* are made available under the terms of the Common Public License v1.0
* (CPL) which accompanies this distribution, and is available at
* http://www.opensource.org/licenses/cpl.php
*
* This software is covered by a modified version of the Common Public License
* (CPL), where Keith Gaughan is the Agreement Steward, and the licensing
* agreement is covered by the laws of the Republic of Ireland.
*/

// For implementations that don't include the push() methods for arrays.

if (!Array.prototype.push) {
    Array.prototype.push = function(elem) {
        this[this.length] = elem;
    }
}


var EventManager = {
    _registry: null,

    Initialise: function() {
        if (this._registry == null) {
            this._registry = [];

            // Register the cleanup handler on page unload.
            EventManager.Add(window, "unload", this.CleanUp);
        }
    },


    /**
     * Registers an event and handler with the manager.
     *
     * @param  obj         Object handler will be attached to.
     * @param  type        Name of event handler responds to.
     * @param  fn          Handler function.
     * @param  useCapture  Use event capture. False by default.
     *                     If you don't understand this, ignore it.
     *
     * @return True if handler registered, else false.
     */

    Add: function(obj, type, fn, useCapture) {
        this.Initialise();

        // If a string was passed in, it's an id.
        if (typeof obj == "string") {
            obj = document.getElementById(obj);
        }

        if (obj == null || fn == null) {
            return false;
        }


        // Mozilla/W3C listeners?
        if (obj.addEventListener) {
            obj.addEventListener(type, fn, useCapture);
            this._registry.push({obj: obj, type: type, fn: fn, useCapture: useCapture});
            return true;
        }


        // IE-style listeners?
        if (obj.attachEvent && obj.attachEvent("on" + type, fn)) {
            this._registry.push({obj: obj, type: type, fn: fn, useCapture: false});
            return true;
        }


        return false;
    },


    /**
     * Cleans up all the registered event handlers.
     */

    CleanUp: function() {
        for (var i = 0; i < EventManager._registry.length; i++) {
            with (EventManager._registry[i]) {
                // Mozilla/W3C listeners?
                if (obj.removeEventListener) {
                    obj.removeEventListener(type, fn, useCapture);
                }

                // IE-style listeners?
                else if (obj.detachEvent) {
                    obj.detachEvent("on" + type, fn);
                }
            }
        }


        // Kill off the registry itself to get rid of the last remaining
        // references.

        EventManager._registry = null;
    }
};

신고
Posted by Rhio.kim