이전 번역 문서인 JavaScript. The Core 에 이은 Chapter 1. Execution Contexts 를 번역하였습니다.

자바스크립트에서 실행 컨텍스트에 대한 이해는 매우 중요합니다.  모든 코드의 흐름(Stack) 을 이해하고 this, scope chain, closure 를 이해하는데 있어 꼭 알아야 할 개념중의 하나입니다.

원본 : http://dmitrysoshnikov.com/ecmascript/chapter-1-execution-contexts/
번역 : http://frends.kr/post/javascript-the-core/


신고

'JavaScript > Core' 카테고리의 다른 글

JavaScript. 실행 컨텍스트 이해(Execution Contexts)  (2) 2011.10.23
JavaScript. The Core  (3) 2011.10.12
JavaScript History 정리 자료  (0) 2011.06.24
jQuery의 현재 그리고 미래  (0) 2008.10.07
Posted by Rhio.kim
오랜만에 포스팅이네요.

지난 포스팅이 뜸한 시간동안 개인적으로 오프라인 활동과 대외활동을 하는데 많은 시간을 소비했네요.
또한 이직과 함께 새로운 문화에 적응하는 시간으로 많은 시간을 보냈습니다.

바로 어제 삼성동 섬유센터 이벤트홀에서 웹 앱스 퓨처 컨퍼런스가 개최되었는데요.
그중 JavaScript 분야의 하나의 세션을 맡게 되어 '2011 자바스크립트 개발자 전성시대' 라는 주제로 발표하였습니다.

몇몇 분들께서 자료 공유 요청을 해주셔서 공유합니다.

1. 웹 앱스 퓨처 컨퍼런스 2011 발표자료.
2. 베틀 테트리스 데모 영상
    : iOS 4.2 부터 지원되기 시작한 아이폰의 모션 이벤트와 HTML5 WebSocket 그리고 서버사이드 자바스크립트인 
      Node.js 를 이용한 소켓 서버로 구성된 베틀 테트리스 데모입니다.
3. 웹 기술과 Arduino 를 이용한 LED 컨트롤 데모 영상
    : 특히 발표에서 가장 많은 관심을 갖어주었던 데모인데요.  
      아두이노(Arduino) 라는 오픈 하드웨어 플랫폼의 마이크로 컨트롤러입니다.
4. 극히 개발자적이고 돈 안되는 결과물 ^-^/
    : 네이버 맵 API와 트위터 API 그리고 3번의 기술을 조합한 트위터 클라이언트 입니다.


웹 앱스 퓨처 컨퍼런스 2011 에 발표한 내용과 관련하여 ZDNet Korea에 기사가 개제되었습니다.

http://www.zdnet.co.kr/ArticleView.asp?artice_id=20110301074637


2011 JavaScript Developer Generation
신고
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
올해 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
신고
Posted by Rhio.kim

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 > Core' 카테고리의 다른 글

JavaScript. 실행 컨텍스트 이해(Execution Contexts)  (2) 2011.10.23
JavaScript. The Core  (3) 2011.10.12
JavaScript History 정리 자료  (0) 2011.06.24
jQuery의 현재 그리고 미래  (0) 2008.10.07
Posted by Rhio.kim

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 에 관한 고찰과 책 소개  (15) 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
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
Javascript Optional pattern

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

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

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

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

sample code


위 소스에서도 알 수 있듯이 사용자는 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에 대한 이해만 있다면 값의 설정을 통해서 쉽게 원하는 결과물을 얻을 수 있다.


신고
Posted by Rhio.kim
부제 : Javascript prototype은 어떤 의미를 갖는가?


MDC defined
Prototype is a property of various Javascript Objects
Prototype은 다양한 자바스크립트 오브젝트의 프로퍼티이다.

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

object

An object is a member of the type Object. It is an unordered collection of properties each of which contains a primitive value, object, or function. A function stored in a property of an object is called a method.

Object Object의 타입type맴버입니다그것은 기본적인 value이나 오브젝트object, 함수function 각각 프로퍼티의 무질서한 컬렉션입니다.

오브젝트의 속성에 지정된 함수는 메서드method라 불린다.


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

프로토타입prototype ECMAScript에서 구조structure, 상태status, 습성behavior 구현하기 위해 사용하는 오브젝트object입니다.

생성자constructor는 오브젝트를 생성할 때 그 오브젝트에 프로퍼티 레퍼런스를 가리킬 목적으로 생성자constructor의 연관된 프로토타입prototype 을 참조하게 됩니다.

생성자constructor와 연관된 프로토타입prototypeconstructor.prototype과 같이 프로그램program적인 표현expression 으로 참조 될 수 있고 native Object의 프로토타입prototype에 추가되어진 프로퍼티properties가 공유shared되어 집니다.


Constructor

생성자constructor생성create하고 초기화initialize하는 함수 오브젝트입니다각각의 생성자는 상속구현과 공유 프로퍼티 사용을 위해 연관된 프로토타입prototype 오브젝트를 갖습니다.


사용자 삽입 이미지

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

신고
Posted by Rhio.kim

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

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

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

IE Circular-Memory-leak Magration

메모리 누수 테스트 결과

테스트 코드

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


신고
Posted by Rhio.kim
Pro Javascript Techniques 상세보기
Resig, John 지음 | Springer 펴냄
Provides information on using JavaScript to develop Web sites.

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

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

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

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

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

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

Pro JavaScript Design Patterns 상세보기
Harmes, Ross/ Diaz, Dustin 지음 | Springer 펴냄

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

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


사용자 삽입 이미지
사실 제가 요즘 부쩍 판도라에 대한 포스팅을 자주 하는데요.
블로그 성격 이탈 현상을 보이지 않았나 생각해봅니다.

하지만 아직 몇가지 더 해야합니다.  핵심이 남아있기 때문입니다.
판도라 티비의 서비스의 Ajax 구현 Work Flow에 대해서 포스팅 할 계획입니다.
또한 멀티 랭귀지 지원Full Ajax 구현, Ajax 보안, 글로벌 서비스를 위한 Ajax의 선택,
Ajax Framework의 선택, Full Ajax의 문제점

Full Ajax Application 을 개발하면서 발생할 수 있는 이슈에 대한 전반적인
사항을 볼 계획입니다.

신고

'라이프로그 > 책/잡지' 카테고리의 다른 글

JavaScript 에 관한 고찰과 책 소개  (15) 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
Posted by Rhio.kim
Class-Based vs Prototype-Based Languages

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

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

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

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

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

클래스
1.    하나의 클래스는 포함하는 일련의 오브젝트들의 특성을 나타낼 프로퍼티Property 모두를 정의한다.  클래스는 일련의 오브젝트의 특정 맴버들에 비해 더 추상적인 것이다.  예를 들면 사원 클래스는 모든 사원들의 구성을 표현할 수 있다.

관련정보 : http://en.wikipedia.org/wiki/Class_(computer_science)

인스턴스
1.    반면에 인스턴스instance는 클래스의 인스턴스 즉 맴버중에 하나입니다.  예를 들어 사원 클래스의 인스턴스로 특정한 개개의 직원을 표현할 수 있습니다.
2.    인스턴스는 부모 클래스의 속성을 정확하게 갖고 있습니다. (그 이상도 그 이하도 아님)


클래스 정의

자바스크립트 같은 프로토타입 기반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

신고
Posted by Rhio.kim
사용자 삽입 이미지
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/
신고
Posted by Rhio.kim
부제 : garbage collection in javascript
자바스크립트 어플리케이션 메모리 관리라기 보다 가비지 컬랙션(Gabege Collection)과 클로져(closure)와 순환참조(circular reference) 의 관계에 대한 글에 가깝습니다.


중간 중간 정리하면서 가비지 컬랙션에 대한 참조한 블로그가 있었는데 까묵었습니다. ^-^;


간단 명료하게 결론부터 정리합니다.
Javascript RIA 개발 시 간과해서는 안되는 중요한 부분중에 한가지 입니다. 
바로 메모리 관리 Memory Management입니다.


  이미 여러 javascript로 RIA 개발 경험이 있는 개발자라면 뼈저리게 느끼고 있을 것입니다.
못느꼇다면 꼭 한번 브라우저를 띄우고 개발해 놓은 요소들을 메모리 테스트를 해보시기 바랍니다.

  그리고 윈도우 어플리케이션 개발자라면 이 메모리 관리에 대해서 매우 예민한 부분이 아닐 수 없습니다.  윈도우 어플리케이션도 아닌데 메모리 관리를 해줘야 한다니 그냥 웃고 넘어갈 분들도 계시겠지만 RIA 개발하려는 모든 분들께 메모리 관리에 대한 중요성을 전달해 주고 싶습니다.


가비지 컬랙션(Garbage Collection) ?
 힙heap영역에 할당된 더 이상 사용되지 않는 메모리인 가비지garbage를 가비지 컬랙터garbage collector가 다른 객체가 사용할 수 있도록 정리하는 것을 말합니다.

객체가 가리키는 참조 변수가 null이 지정되거나 객체가 더 이상 참조하지 않게 되었을 때 가비지 컬랙터의 후보가 되며 이러한 객체들은 가비지 컬랙터에 의해 메모리를 반환하게 됩니다.


가비지 컬랙션의 대상
1. 객체에 null 값이 대입되었을 때
    e.g.   var dat = new Date();
                  dat = null;
2. 참조변수에 다른 객체가 대입될 때
    e.g.   var dat = document.getElementById(‘rhio’);
                  dat = 29;
3. 메소드의 수행이 끝났을 때
    e.g.   function func() {
            var dat = document.getElementById(‘rhio’);
            //do something
          }

가비지 컬랙션과 순환참조에 대한 좋은 글  옷장수님 블로그#가비지 컬렉션의 이해

사용자 삽입 이미지
자바의 가비지 컬렉션은 자바가상머신Java Vitural Machine에서 알아서 처리하지만 개발자에 의해 직접 가비지 컬랙션을 수행 요청을 할 수 있습니다.  하지만 javascript의 경우에는 따로 개발자에 의해 가비지 컬랙션의 작업 수행 요청할 수 있는 매커니즘이 존재하지 않습니다.

Javascript는 주기적으로 가비지 컬랙션의 대상에 대한 리소스 반환 작업을 수행하게 됩니다.

IE 브라우저의 경우 순환참조Circular Reference 발생과  클로져 형성으로 메모리 누수에 대한 심각한 문제가 시작됩니다.   Javascript에서의 순환참조(Circular Reference)라 함은 Javascript 객체가 DOM 객체에 대한 레퍼런스를 포함하고 그 DOM 객체가 javascript 객체의 레퍼런스를 포함할 때를 말합니다.

위의 문단이 자바스크립트에만 순환참조가 있다라는 글로 오해될 수 있을 것 같아 살짝 수정 및 아래 내용을 추가합니다.  일반적인 순환참조(circular refrenece)에 대한 설명이 더욱 필요할 것 같네요.  (옷장수님이 의견 주셨습니다.)

일반적인 순환참조(Circular Reference)란?
참고 :
    http://en.wikipedia.org/wiki/Circular_reference
    http://en.wikipedia.org/wiki/Reference_counting


사용자 삽입 이미지

위의 예제는 흔히 우리가 알고 있는 javascript의 순환참조가 발생되면서 메모리 누수현상을 단편적으로 설명할 수 있는 예시가 됩니다.

div는 DOM 객체의 레퍼런스를 담고 있습니다. 이 DOM 객체를 outerFn 가 첫번째 인자로 취하여 DOM 객체에 func라는 프로퍼티property  javascript의 익명함수anonymous function 를 참조reference하게 합니다.

이 자체가 메모리 누수라 할 수는 없지만, 위와 같은 패턴은 경우에 따라(위와 같은 작업이 반복 적으로 수행될 때) 심각한 누수 현상을 발생할 수 있습니다.  이 말은 곧 가비지 컬랙션에 의해서 메모리 반환을 하지 못하는 상황에 빠지게 됩니다.

  Javascript의 가비지 컬랙터의 경우 클로져가 형성된 것들을 관리하며 혼돈하지 않아 가비지 컬랙션에 대해 메모리 반환을 하지만 불행히 IE의 경우 DOMJScript가 관리하지 않아 위의 예시와 같은 순환참조와 클로져에 대해 몹시 둔감합니다.  그만큼 메모리 누수 현상이 매우 심각합니다.

 
이번 IE8이 릴리즈 되면서 그에 대한 마이그레이션 팁이 나왔습니다. 그 역시 DOM과 Javascript의 순환참조에 대한 이슈를 대부분 언급하고 있습니다.  그에 대한 테스트와 테스트 결과에 대해서 다음에  간단한 포스팅을 하도록 하겠습니다.


참고
http://www.crockford.com/javascript/memory/leak.html
http://www-128.ibm.com/developerworks/web/library/wa-memleak/

신고
Posted by Rhio.kim
1. 엘리먼트element

<tagName id="element" ... properties = "value">   </tagName>

어떤 면에서 보면 단지 HTML 태그에 불과합니다.

하지만 좀더 XML 관점에서 바라본다면 위의 단위를 "엘리먼트element"라 부릅니다.
하나의 엘리먼트는 DOM spec의 IDL(Interface Definition Language) 에 정의된 attributes를 취하게 됩니다.


2. 인터페이스interface

  우리는 DOM의 내부(core) 구현은 알 필요가 없이 다양한 언어(java, javascript, ect)로 오브젝트와 인터페이스를 통해 document object 에 접근을 하게 됩니다.  여기서 인터페이스라는 간단히 말해

    개발자 언어(java, javascript)와 Document Objec와의 의사소통을 담당하는 중간 매개체
    <#참고 : 위키백과 - 인터페이스>   <#참고 : Web Kit DOM>

입니다.

이 인터페이스는 FireFox에서 아래와 같은 수행을 했을 때 쉽게 볼 수 있습니다. 또한 Web Kit DOM 사이트에서도 찾아 볼 수 있습니다.

var el = document.createElement('img');
//[object HTMLImageElement]
var el = document.createElement('input');
//[object HTMLInputElement]
var el = document.createElement('div');
//[object HTMLDivElement]
...
...
위 예제처럼 알 수 있듯이 [type interface]를 취하는 것을 알 수 있습니다.  단편적인 createElement 메서드의 수행 결과이나 모든 javascript 에서 object 화 하여 취하게 되는 모든 document object 에는 고유의 interface를 제공받게 됩니다.


3.자바스크립트javascript  엘리먼트element 인터페이스interface의 관계

여기서 javascript를 이용하였을 때의 interface에 대한 관계를 설명하고자 합니다.

var el = document.getElementById('element');

  우리는 HTML Document에서 엘리먼트의 고유한 id 프로퍼티가 'element' 인 엘리먼트 오브젝트를 넘겨줍니다.  간단하게 본 el에는 object type의 엘리먼트를 취한다고 봅니다.  또한 el을 통해서 위에 명시했던 엘리먼트의 속성을 접근하거나 이벤트 핸들링을 하거나 style을 변경하거나 할 수 있다 라고 봅니다.

  이러한 하나의 엘리먼트에 어떤 프로퍼티의 속성에 값을 지정하거나 삭제를 하거나 하는 다양한 처리를 통하여 엘리먼트에 원하는 결과로 설정합니다.

  여기서 el을 얻기 위해서 사용하는 document는 자바스크립트 엔진 런타임 시에 도입되는 window의 하위 오브젝트로 window.document 입니다.   이는 또한 DOM(Document Object Model)에 접근하기 위한 가장 상위 인터페이스(DOM 관점에서 볼때) 혹은 오브젝트(자바스크립트 관점에서 볼때)입니다.


좀더 자세한 예제를 통해서 DOM HTML Spec에서의 interface에 접근해 보도록 하겠습니다.

우리는 HTML document에 표현되지 않고 랜더링 되지 않는 엘리먼트 오브젝트를 생성할 수 있습니다.

var el = document.createElement('img');
var el = document.createElement('div');
var el = document.createElement('input');

이렇게 createElement 메서드를 통해서 image 엘리먼트를 생성하였습니다.

이때도 알 수 있지만 el에는 image object가 담겨져 있고 이것은 image가 갖는 attribute를 제공받습니다.
createElement 수행 시 생성된 엘리먼트에는  아래의 interface를 제공 받습니다.

interface Element,
interface HTMLElement:Element,
interface HTMLImageElement:HTMLElement
interface HTMLDivElement:HTMLElement     
interface HTMLInputElement:HTMLElement     

간단한 예제 코드로 interface HTMLImageElement가 취하게 되는 attributes를 보겠습니다.
var el = document.createElement('img');
var DOM_ATTRIBUTE = [];
for(property in el) DOM_ATTRIBUTE.push(property);

more..


위에서 보셨던 많은 attributes는 interface HTMLImageElement 에 의해서만 제공받은 attributes는 아닙니다. 상속 계층에 있는 모든 interface에서 제공되는 attributes를 제공받습니다.
<#참조 : Web Kit - interface HTMLImageElement> <#참조 : Web Kit - HTMLImageElement IDL>

아래의 다이어그램과 같이 javascript에서는 window.document에 의해서 얻어진 Document Object는 DOM interface의 계층에 따라 상위 인터페이스를 제공받습니다.  달리 말하면 상위 interface에 의해서 HTMLImageElement 을 제공받게 됩니다.
사용자 삽입 이미지


4. 요약
javascript 는 window.document 즉 interface document 에 의해서 document object 에 접근합니다.
window.document는 javascript runtime 시 도입되는 interface 역활을 합니다.

javascript에서 접근하는 모든 document object는 자신만의 interface를 제공받으며 또한 상속 계층에 있는 상위 interface 또한 제공받게 됩니다. 이를 통해 개발자 언어를 통하여 document object를 제어, 획득 할 수 있게 됩니다.

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

우렁 아가씨가 다녀갔다

어제도 이런 저런 자료를 보다가 새벽 2시 즈음에 잠이 억지로 들었었는데...

다 못보고잔 "NorthCast - Christian Heilmann - YUI! javaScript Evolved.avi"

내용이 퍽 궁금하지는 않지만 빨리 보고 싶다..

외국에는 저런 개발자들의 커뮤니티가 자연스럽게 형성되는 것 같은데 늘 국내의 개발자 커뮤니티에 대해서는 불만이다..

앗참.. 우렁각시...

점심밥 먹고 와서 너무 피곤해서 의자에 파뭍혀 잠을 청하고 있었는데..

너무 깊숙히 잠들었었나 보다.. 누가 다녀간지도 기억도 소리 조차 없었는데..

일어나서 한참을 코딩하고 있는데 어디선가 자꾸 "아메리카노" 커피 향이 코구멍을 간지럽혔다..

블로그에 누가 왔었나 한번 보려고 했는데 주위를 잠깐 살펴봤더니 달력옆에 놓여진 커피~~

이런 사랑스러운 사람들... 누군지 모르지만 확 사랑해버리고 싶다 ㅋㅋㅋ..


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

요건 머에다 쓰는 물건일까요?
같은 그림 찾기에 사용할 이미지 입니다.. ^-^;

TFastClick 에 이은 불후의 고전 게임 -_-?

prototype 만들어 보았습니다.
@import prototype.1.6.0.2


신고
Posted by Rhio.kim
사용자 삽입 이미지
ALC 에서 YUI를 스터디할 멤버를 모집합니다.
현재 스터디는 진행 중입니다.
cafe : http://cafe.naver.com/requirements.cafe


스터디 라이브러리

사용자 삽입 이미지

+ YUI 2.4.0


스터디 방향
  + YUI를 기능 중심으로 분석
  + 개인별로 분석할 소스 코드를 분담하고, 샘플 코드를 작성하여 이를 발표 및 설명

신청자격
  + (X)HTML, DOM, CSS, JAVASCRIPT를 포함하여 전산 개발 경력 4년차 이상이신 분
  + 매주 토요일 4시간 참석 가능한 분

모집인원
  + 3명
  + 신청하신 자료를 보고 제 나름대로의 기준으로 선발하겠습니다.
    ( 선발이 안되더라도 넓은 이해를 부탁드립니다. 여기서 "제" 는 리오가 아닙니다.
      "Ajax Prototype.js 완전정복" 저자인 김영보님 이세요. )

신청기간
  + 2008년 2월 28일까지

신청 방법 및 기재 사항
  + 이벤트에게 메일로 신청 :
tonextday골뱅이gmail.com
  + 성명, IT경력, 핸드폰 번호, 사용가능 언어

진행 방법
  + 리더 : 이벤트
  + 매주 토요일 4시간 이상 오프라인 미팅을 통한 스터디
  + 2주에 한 시간씩 스터디한 내용을 발표 (시간은 준비 자료에 따라 1시간 미만 그 이상 자율적입니다.)

스터디 기간 및 장소
  + YUI 전 모듈 스터디를 완료할 때까지
  + 장소 : 맴버분의 회사에 공간이 있어 그곳을 사용합니다.( 오목교역 행복한 세상 백화점 13층)
    
http://www.dial070.co.kr/company/serome_info_5.html?submenu=05 

회비
  + YUI 및 DOM, javascript, CSS, (X)HTML 에 연구에 대한 열정

 

기타:

우리 스터디는 의무감이 매우 강합니다. 하시려는 분은 단단한 각오를 하셔야 합니다.

중도에 그만 두시려면 신청을 삼가해 주세요. 참여한 다른 사람들에게 피해를 주게 됩니다.



사용자 삽입 이미지
리오의 한마디 : 많은 분들이 신청하셨으면 좋겠습니다.
사실 YUI 가 국내에서는 그렇게 크게 알려지지 않았고 다른 오픈 프레임웍이 많이 나와있고
공부할 수 있는 라이브러리들이 상당히 많습니다.

사용자 삽입 이미지
하지만 현재 나와있는 프레임웍으로는 가장 안정적이고 기술적으로 인정하고 싶습니다.
(베타가 많지만 ^^;;)  알고 있는 Prototype, jQuery, Dojo 등등의 다양한 프레임웍이 있지만 YUI는 대형 포털(Yahoo.com)에 적용되어 검증된 기술들입니다.

사용자 삽입 이미지
YUI를 사용하기 위한 스터디 일 수 있지만 개발자들이 거기에서 멈추지 않죠.
내부적인 구조적 설계 부분 javascript UI 개발을 위한 CBD, TDD 개발 방법론을 직접적으로 제시해 주고 있습니다

또한 프레임웍의 설계적, 기술적, 보안적인 부분을 면밀히 살펴보고 공유할 수 있는 자리가 될것입니다.

사용자 삽입 이미지
그리고 현재 나와있는 프레임웍 중에 Description 이 가장 잘 되어있습니다.
이로 javascript 의 겉모습 뿐만 아니라 코드에 대한 이해도를 높혀 상당히 빠르게 습득할 수 있습니다.


꼭 Yahoo!! 개발 관련자 같이 말했군요... 
신고
Posted by Rhio.kim
사용자 삽입 이미지
Ajax 와 DOM 스크립팅에 현재 가장 이슈가 되는 것은 아무래도 고성능을 낼 수 있는 웹 어플리케이션을 만들 수 있느냐라고 생각합니다.

웹 자체는 가벼우면서 사용자들에게 손쉽게 다가갈 수 있고 사용자들에게 가장 쉽게 어필 할 수 있는 것 역시 웹(web) 입니다.

최근 RIA 개발에 Ajax가 가미되면서 Client-side 와 Server-side 가 완전히 분리되고 Client 에서는 UI에 전념할 수 있게 되었습니다.

하지만 이에 "대화형 웹 어플리케이션"을 위한 Ajax와 DOM 스크립팅이 그 만큼 중요하게 되었는데요.

크로스브라우징, 사용자 리소스 최적화 등의 이슈가 되고 있습니다. 그렇게 좀더 가볍고 저사양에서도
또한 글로벌 스탠다드가 되기 위하여 최고의 퍼포먼스를 낼 수 있는 RIA 설계가 중요하게 되었습니다.

우리는 IE, FF, Opera, Safari 의 크게 4가지의 브라우저를 기본으로 크로스 브라우저에 대응합니다.
이에 몇가지 브라우저별 퍼포먼스를 비교해봅니다.


DOM 스크립팅 퍼포먼스 (HTML DOM Operation Performance)
                                        IE7             FireFox            Safari       
HTML DOM Operation Time(ns) % Time(ns) % Time(ns) %
Change text using innerHTML 469.0 9979% 234.0 6000% 109.0 7032%
Create a text node on HTML Dom 1093.0 23255% 156.0 4000% 110.0 7097%
Change the class name of an element 422.0 8979% 47.0 1205% 109.0 7032%
getElementById 86.8 1846% 15.7 401% 3.9 252%
getElementsByTagName("div") 153.1 3257% 18.0 462% 5.5 352%
getElementsByName 93.8 1995% 44.6 1142% 4.7 303%
placeDiv.getAttribute("id") 29.7 632% 46.8 1200% 5.5 352%
placeDiv.attributes["id"] 31.3 665% 225.0 5769% 6.3 403%

IE7의 결과는 UI 개발자의 손목에 수갑을 채우고 있습니다. 꼭 이런 문제뿐만 아닙니다.
IE8에는 많은 문제가 해결되고 표준에 의거하여 개발에 임했으면 합니다.



eval function의 수행 퍼포먼스(2번)
IE7 172ns and 94ns
FireFox 546ns and 749ns
Safari 9.4ns and 22.7ns

과연 eval은 크로스 브라우징 대응에 있어서 사용을 줄여야합니다.


Object 생성 수행 퍼포먼스
“var myObject = new MyObject (17, 250);
“var slowCar = {m_tireSize:17, m_maxSpeed:250};”

IE7 11.7ns and 8.6ns
FireFox 23.4ns and 23.4ns
Safari 3.2ns and 2.4ns

Ajax 개발 시 Server-side 에서 JSON 을 받아올 경우 Firefox의 경우 Object화 하여 사용할 경우
경우에 따라 퍼포먼스에 많은 영향을 미칩니다.


in 수행 퍼포먼스
IE7 10.3ns
FireFox 62.8ns
Safari 7.6ns


Firefox 도 Ajax 개발 시 경우에 따라 상당히 느려지는 부분을 보이고 있습니다.
하지만 IE6의 경우보다는 매우 양호합니다. IE6의 경우는 대부분의 Ajax 개발 관련 Performance 테스트에서
몇 백 퍼센트의 차이를 보이고 있습니다.
특히 IE의 경우 String 퍼포먼스에서 매우 낮은 결과를 보입니다.

DOM 스크립팅시에 우리는 DOM 구조를 일일이 생성하는 것 보다 String innerHTML을 자주하게 활용하는데요.
IE의 경우 퍼포먼스에 지대한 영향을 미칩니다.
그래서 우리는 Array 를 이용 string buffer 기능을 사용하여 효율적으로 처리하고 있지만 전체적으로 IE의
경우 String에 낮은 퍼포먼스를 보입니다.

마지막으로 Safari 의 경우 다른 브라우저들에 비해 상당히 안정되고 최고의 퍼포먼스를 자랑하고 있습니다.
역시 아직까지 다른 브라우저에 비해 기능 차이가 있기 때문입니다.

체감하는 렌더링 속도도 상당히 차이가 있음을 느낍니다.


Internet Explorer 7

      FireFox

     Safari

Description

Time (ns)

% of base

Time (ns)

% of base

Time (ns)

% of base

Normal Empty function call (Base Operation)

4.7

100%

3.9

100%

1.6

100%

Basic Function Calls







Function call using function.call(this)

5.5

116%

2.4

60%

1.6

100%

Normal Empty function using apply

5.5

117%

7.0

179%

2.4

152%

Normal Empty function using apply with 3 parameters

7.0

149%

7.1

181%

2.4

152%

Eval a function

172.0

3660%

546.0

14000%

9.4

603%

Eval an object

94.0

2000%

749.0

19205%

22.7

1461%

Basic Operations







Access Properties through a getter

13.3

282%

6.3

160%

5.5

352%

Access Properties directly

4.7

100%

3.2

81%

2.4

152%




 

 



Simple string concatenation

4.7

100%

2.3

59%

1.6

100%

Simple string compare

3.9

83%

2.4

60%

0.8

48%

Change string to upper case

11.7

249%

3.9

100%

4.7

303%

Replace string reg expression

12.5

266%

7.1

181%

9.4

603%

String concat with integer

7.1

150%

4.7

119%

2.4

152%

String concat with float

6.3

133%

4.7

121%

2.4

152%

Index of Bob in string, not found, length = 71

6.3

133%

6.3

160%

2.4

152%

Match of Bob in string, not found, length = 71

14.9

316%

25.0

640%

3.9

252%

charAt(10) in string

11.7

249%

6.3

160%

3.1

200%




 

 



Create object constructor initialized

11.7

249%

23.4

600%

3.2

203%

create simple object

8.6

182%

23.4

600%

2.4

152%



0%

 

 



Variable declaration

4.0

84%

2.3

59%

0.8

48%

Multiple variable declaration, multiple var

3.9

83%

2.4

60%

2.4

152%

Multiple variable declaration single var

3.9

83%

2.4

60%

1.6

100%

Variable declaration set to null

3.9

83%

2.4

60%

1.6

100%



0%

 

 



Variable assignment++

4.7

100%

5.5

140%

1.6

103%

Variable assignment + 1

5.5

116%

7.1

181%

1.6

100%




 

 



Four levels of property access

5.5

116%

5.5

140%

1.6

100%

Three levels of property access

4.7

100%

4.7

121%

2.4

152%

Two levels of property access

4.7

100%

4.7

119%

1.6

100%

One level of property access

3.9

83%

4.7

121%

1.6

103%



0%

 

 



Using the typeof function

3.9

83%

4.7

119%

1.6

100%

Array Operations







Array access

7.1

150%

7.0

179%

1.6

100%

Array index value change

3.9

83%

4.7

121%

1.6

103%

Empty Array index value change

8.6

183%

8.6

221%

6.3

403%

Empty Array add three values

10.2

216%

11.7

300%

3.1

200%

Empty Array with set size

11.0

233%

11.0

281%

3.2

203%

Empty Array using constructor

9.4

199%

25.8

662%

2.3

148%




 

 



Push element onto an Array

25.0

532%

6.3

160%

1.5

98%

Pop element of an Array

165.6

3523%

6.3

160%

249.7

16112%

Push element onto an Array

6.2

132%

7.1

181%

1.4

92%

Shift elements off the front of an Array

2030.0

43191%

5620.0

144103%

1250.0

80645%

Join the array into a string

125000

2659574%

47000

1205128%

16000

1032258%

Push element onto an Array

7.1

150%

7.0

179%

3.9

252%

Sorting of an Array

93.0

1979%

45.3

1162%

32.9

2119%




 

 



Math.max(7.25,7.30)

5.5

116%

4.7

121%

3.9

252%

Math.min(7.25,7.30)

5.5

117%

4.7

121%

3.2

203%

HTML DOM Operations







Change text using innerHTML

469.0

9979%

234.0

6000%

109.0

7032%

Create a text node on HTML Dom

1093.0

23255%

156.0

4000%

110.0

7097%

Change the class name of an element

422.0

8979%

47.0

1205%

109.0

7032%




 

 



getElementById

86.8

1846%

15.7

401%

3.9

252%

getElementsByTagName("div")

153.1

3257%

18.0

462%

5.5

352%

getElementsByTagName("spa")

142.2

3024%

18.8

481%

5.5

355%

getElementsByName

93.8

1995%

44.6

1142%

4.7

303%




 

 



placeDiv.getAttribute("id")

29.7

632%

46.8

1200%

5.5

352%

placeDiv.attributes["id"]

31.3

665%

225.0

5769%

6.3

403%

var atts = placeDiv.attributes; atts["id"].name

11.7

249%

18.8

482%

4.7

303%

var atts = placeDiv.attributes; atts.id.name

12.5

266%

18.8

482%

3.9

252%

Try/Catch







Function call using function.call(this)

7.1

150%

4.0

101%

2.4

152%

Try catch

7.1

150%

6.3

160%

5.5

352%

Try catch with throw

17.2

365%

7.8

200%

5.5

355%

Try catch finally

9.4

199%

7.8

200%

4.7

303%

Try catch finally with throw

16.5

350%

11.0

281%

6.3

403%

If statement and Date object







Create a date object

12.5

266%

10.2

260%

3.1

200%

Create a date object and call getDate()

28.1

598%

50.8

1303%

10.2

658%




 

 



The switch statement

4.7

99%

2.4

60%

2.4

152%

An if statement

4.0

84%

2.4

60%

2.4

152%




 

 



Simple if else

4.1

86%

2.2

56%

1.9

121%

turinary operator

3.9

83%

2.3

60%

2.0

131%




 

 



Compare of matching string ==

4.7

100%

7.1

181%

2.4

152%

Compare of matching string ===

4.7

100%

7.0

179%

2.4

152%

Compare of non-matching string

4.7

100%

3.9

100%

2.4

152%




 

 



Compare  TEST_INT == 5

4.1

86%

4.2

108%

1.7

111%

Compare  5 == 5

4.1

87%

2.0

52%

1.6

101%

Looping Performance Statistics







Loop through an array using in

10.3

219%

62.8

1610%

7.8

503%

Loop through an array using for (i++)

6.3

133%

10.6

273%

3.4

222%

Loop through an array using for (i < myArray.length)

6.2

133%

10.9

281%

3.1

201%

Loop through an array using for (i = 0; i < len; i++)

5.0

106%

4.7

120%

4.1

262%

Loop through an array using for (i = 0; i < len; i++)

5.3

113%

5.0

128%

4.1

262%

Loop through an array using while {i++}

5.3

113%

5.3

136%

4.7

302%

Loop through an array using while (i++ < len)

5.0

106%

5.0

128%

4.4

283%



원본 : http://www.coachwei.com/blog/_archives/2008/1/22/3480119.html
퍼포먼스 테스트 : http://www.rockstarapps.com/samples/performance/
신고
Posted by Rhio.kim

Eloquent JavaScript  [설득력있는 자바스크립트]

http://eloquentjavascript.net/contents.html

영어로 되어있지만 좋은 참고 자료가 될것 같아 소개합니다. 
챕터별로 세세한 예시와 자세한 설명을 곁들여 이해하기 쉽게 해놓았습니다.

소스 코드를 실제로 수행할 수 있는 콘솔 창까지 제공하고 있네요. 

사용자 삽입 이미지

신고
Posted by Rhio.kim
자바스크립트 싱글 패턴 스토리 - I

사용자 삽입 이미지
여담 :
   참으로 싱글이 더욱 추워지는 날씨 입니다.
   내일은 싱글은 정말 속상한 하루 입니다.

   하지만 둘 일때 느끼는 추위는 싱글이 느끼는 추위보다
   더욱 춥습니다.


   그리고 더 추운 사람들은 둘이 할 수 없는
  사람들입니다.

  그런 사람들을 위해 따뜻한 손길을 뻗을 수 있는
  연말이 되었으면 합니다.




자바스크립트에서도 다양한 디자인 패턴이 가능합니다.
GoF 패턴 POSA 패턴 등 말이죠..

아마 UI 개발자 분들 중 javascript 를 이용하시는 분들은 대부분 패턴을 적용하신지 모른체 사용하고 계실꺼에요.  저도 Java 디자인 패턴 교육을 10일 동안(?) 참여했었는데요.  그 교육의 모든 예제가  Java 였습니다.  대형 프로젝트는 대부분 Java로 하니깐요..

또한 설계의 중요함을 포함해야 하는 언어이기도 하니깐요..
교육 중 다양한 패턴을 javascript 포팅을 해봤습니다. 큰 어려움은 없었습니다.






자자 서론이 길어졌습니다. 본론으로 들어가겠습니다.



위의 예제는 간단한 클래스 입니다.  foo() 를 new Operator를 통해서 foo()를 참조하는 인스턴스를
생성하였습니다.

bar와 zoo 의 constructor 는 같습니다.

하지만 인스턴스는 서로 다른 인스턴스를 같습니다.



위의 소스를 실행하보면 간단하게 알 수 있습니다.
당연히 다른 결과가 찍힐꺼라 생각됩니다.  여기서 잠시 삼천포로 빠지겠습니다.

저는 여러 예제를 봤습니다. 디자인 패턴 -> 싱글톤 도대체 이런것이 무슨 의미를 갖고 의미는 알 지언정
언제 적용해야하는 걸까? 적용해서 어떤 이점이 있을까?
또한 어떤 이점이 있고 언제 적용해야한다. ...  뭐 다양한 언어에 대해서 좋은 예시와 개념들이
많은 사이트에서 제공되고 있습니다.

하지만 몰랐습니다.  패턴이란걸 언제 쓰고 어디다 쓰고 해야하는 지!!

객체 지향에 대한 개념이 없었다는 것이었죠..  하지만 봐웠던게 도움이 많이 되었던것 같습니다.
개념을 정리하는 것이 단지 남의 예제와 예시를 보고 이해하는게 아닌 자기것으로 만드는 것
남앞에 "싱글 패턴"이 무엇이다 라고 사전적인 개념이 아닌 사전적 예시가 아닌 실제로
코드로 보여줄 수 있는 ... 역시 삼천포로 빠지는건 정리가 안됩니다...

결론은 한번 봐 놓으면 언젠간 도움이 됩니다.  아키텍쳐로 가는 것에 매우 도움이 될 것입니다.

결과는 수행해 보셨나요?

자 그러면 이해가 되지 않더라도 왜 이 글을 보고 있는지도 모르고 싱글 패턴이 먼지도 모르고 도대체
뭘 하려는 글인지 알지도 못할 지언정 "싱글 패턴이 무엇인가?" 라는 것만 꼭 올고 싶다면 위의 소스를 수행해보고 지금 이 소스를 수행해 보세요.



수행해 보셨어요?  결과는 처음 예제와는 조금 틀린 결과가 나왔네요.
당연히 new Operator 를 사용하지 않았기 때문 아니냐 라는 반문을 한다면 !!

여기서 잠깐 GoF에 나오는 싱글 패턴에 대한 소개!!
1. 접근하는 인스턴스는 오직 하나란 것이 보장이 되는 방법을 제시 해야 하며
2. 이렇게 유일한 인스턴스에 접근 할 수 있는 방법을 제공하여야 한다.

2번을 통해서 유일한 인스턴스를 제공하기 위해서 방법을 제공하였습니다.

또 하나.. 하지만 다른 누군가는 이것을 사용할때 new Operator 를 사용하면 어떻게 되느냐?
그러면 싱글 패턴이 깨지는 거 아니냐?

맞습니다. 

그렇다면 new Operator가 수행될 때 foo() 내에서 생성자를 통한 인스턴스 생성인지
아니면 싱글 패턴을 위한 방법(getInstance)에 의한 생성인지를 체크해서 new Operator를 사용할 경우에는
예외 처리를 하거나 하나의 인스턴스만 생성해 주면 되겠네요.

이 부분은 다음 시간에 다루겠습니다.

이어서 위의 소스를 잠깐 설명을 드리면 유일한 인스턴스를 제공하기 위한 메서드를 통해서
하나의 인스턴스를 생성하기 위해 new Operator 로 접근하는게 아니라

foo.getInstance() 를 통해서 접근하였습니다.
이는 foo() 의 인스턴스화 되면서 __instance__ static vairable가 설정되고 이 variable에 자신의 인스턴스가
저장됩니다.

즉 한번 생성된 foo 의 인스턴스는 null이던 this.__instance__ 에 저장되며 getInstance로 접근하게 되면
저장된 __instance__ 값을 계속해서 반환하게 됩니다.

이렇게 싱클 패턴의 조건을 만족하게 됩니다.
신고
Posted by Rhio.kim