'JavaScript/Technical Reports'에 해당되는 글 45건

  1. 2011.11.15 웹 소프트웨어 시장의 새로운 Role 모델, 자바스크립트 (6)
  2. 2011.05.08 자바스크립트. 그 다음 구글 Traceur (2)
  3. 2011.02.26 2011년은 자바스크립트 개발자 전성시대 (9)
  4. 2010.03.06 @kangax의 JavaScript Quiz 풀이 (8)
  5. 2010.02.11 모질라 Jetpack - GPU를 활용한 JavaScript 가속화 시도 (2)
  6. 2009.08.31 TestSwarm Alpha 버젼 공개. (4)
  7. 2009.04.15 JSARToolkit 테스트 영상 (2)
  8. 2009.02.05 Browser sniffing - using JavaScript (자바스크립트만을 이용한 브라우저 스니핑) (2)
  9. 2009.01.17 Flash 10 에서 클립보드 카피(Clipboard Copy)에 대한 이슈
  10. 2008.12.31 IE 에서 JavaScript 를 가속화(DOM 접근) 하는 방법 (8)
  11. 2008.10.11 JavaScript Injection Attack
  12. 2008.10.07 Practical Functional JavaScript in Ajax Experience 2008 (4)
  13. 2008.09.18 JavaScript 패턴 - Flyweight Pattern
  14. 2008.08.31 Unobtrusive JavaScript 에 대한 고찰 (4)
  15. 2008.06.20 Javascript Optional pattern(pre-configured Pattern) 옵셔널 패턴 (3)
  16. 2008.04.29 Prorotype in javascript (ECMAS 262-2 spec) (7)
  17. 2008.04.15 Ajax 개발 시 자주 발생하는 순환참조 메모리 테스트 결과 (2)
  18. 2008.04.12 Class-Based vs Prototype-Based Languages
  19. 2008.04.10 JavaScript has staying power; Used in Stargate (6)
  20. 2008.04.10 Super Mario in 14kB Javascript
  21. 2008.04.09 Javascript Application(RIA) Memory Management (2)
  22. 2008.03.17 Closure in javascript (자바스크립트에서 클로져는 무엇인가?) (18)
  23. 2008.03.14 Data Caching Structure in Ajax(XHR) Pattern (2)
  24. 2008.02.27 Opera - Slice method of Array Object too bad -_-^ (4)
  25. 2008.02.12 javascript simple data type change ^-^ (4)
이번 kth 에서 진행하는 H3 컨퍼런스에서 어떤 이야기로 풀어나갈까...

지난 5년 자바스크립트와 함께 지내오며 많은 경험들을 토해내려고 무척 고민중입니다.
하지만 짧은 시간에 디테일을 모두 보여드릴 수가 없는게 실정입니다.

그래도 다행인건 제가 우주로 나간다거나 IT 를 떠날 것은 아니기 때문에
이번 컨퍼런스가 끝이라고 생각하지는 않습니다. :-) 


웹 소프트웨어 시장의 새로운 롤 모델, 자바스크립트



이번 '자바스크립트의 새로운 롤 모델'이라는 주제에 포함된 내용들입니다.

큼직큼직한 내용들이 꾀 많네요. 

- JavaScript History and Standard trend  이야기만 하더라도 벌써 40여 페이지가 넘어가네요.

물론 다른 내용들도 그만큼 되거나 더 많겠죠.  책을 써도 될 분량입니다.
몇가지 내용을 먼저 소개하려 합니다.

네스케이프의 짐 클락과 마크 앤드리슨



이번 제 발표에는 자바스크립트 계에 유명인사들이 총 출동됩니다.  물론 나오지 않는 분들도 계시죠. '스티브 사우더스' 를 꼭 모셔오고 싶었으나 워낙에 기술적인 곳에 치우치다보니 이런 자료에 나오고 싶지 않다는 의사를 표하셨습니다. ;-)

ECMA-262 4th 가 중단된 이유가 무엇일까?



왜!!!!! 자바스크립트 4번째 에디션은 중단에 이르게 되었을까요?
표준화 워킹 그룹에서 무슨일들이 있었을까? 
그리고 크락포드는 왜 열을 내고 있을지....

Next JavaScript 를 위한 Ruby 와 Python 그리고 Haskell 영향을 받은 CoffeeScript



자바스크립트의 어머니이자 모질라의 CTO 인 브랜든 아이크가 전하는 자바스크립트 소식들도 있습니다.

Node.js 창시자가 말하는 Node.js 는 무엇일까?



인터넷 서버 시장의 4번째 아키텍쳐의 변화에 대한 기대치를 공유하고 그에 큰 영향을 미친 Node.js 를 개발한 라이언도 모셨네요.  Node.js 와 관련해 서버측 자바스크립트를 살펴보는 시간도 갖을 예정입니다.

그외에도 여기에 다 소개드리지 못한 내용들이 굉장히 많습니다. 
이 포스팅으로 소개드리지 못한 내용들은 오셔서 함께 들어보세요. 

 - 플랫폼화가 되기 위해 준비해왔던 지난 Web 2.0
 - 모바일 시장을 삼켜버린 웹
 - 브라우저의 신기술 구현 전쟁과 성능 경쟁
 - 웹 소프트웨어 개발 체계화를 위한 발전


행사일은 11월 30일 / 사전 등록은 11월 21일 부터입니다.
그리고 가장 중요한 세션의 크기를 결정하는 관심 세션 투표입니다.  
투표 : http://h3.paran.com/vote/

신고
Posted by Rhio.kim
TAG H3, JavaScript, KTH

구글과 자바스크립트


차세대 자바스크립트라는 글을 쓰기에 앞서 구글에 대해서 간략히 정리가 필요하다.

구글은 ECMA-262 4th 스펙 표준화에 참여하였고 다른 브라우저 벤더들도 참가하였다.


이때의 ECMA Technical Committe 39(TC39)가 진행한 ECMA-262 4 번째 스펙

(이때의 ECMA Technical Committe 39(TC39) 가 진행한 프로젝트 명은  Harmony!)


브라우저 벤더들이 대부분이였고 Adobe도 참여하였었다.  많은 이야기가 메일링으로 오갔으며 스펙의 분량은 점점 넓어지고 많은 부분의 사양을 재 작성하는 상황에 이르렀고 결국 실패로 돌아가게 되었습니다.  하지만 어느 정도의 뼈대가 갖춰졌었는지 Adobe 는 최종 권고가 나지 않는 스펙의 일부를 ActionScript 에 적용하였고. ActionScript 3.0 으로 2.x 이하 버젼보다 좀더 객체 지향적인 언어로 탈바뀜하게 되었습니다.


이때 즈음 구글은 ECMA 활동뿐 아니라 HTML5 의 주도적인 표준화에 참여하였고 JavaScript 의 표준 사양인 ECMA-262 표준에도 공헌하였다.
 

물론 이는 앞으로의 웹 시장에 굉장히 중요한 역할을 할것이라는 것을 충분히 알았고 자사의 다양한 플랫폼 유지, 개발을 위한 Go, Python 과 같이 기본 언어가 될 것이기에 나름 철학을 담아 노력을 해왔던 것이다.


(비록 실패로 돌아갔던 Harmony 프로젝트이지만 구글은 변화의 필요성을 알고 있고, 그때의 불 필요한 기업간의 의견 마찰을 피하고 좀더 나은 방식을 택한 것이라 보여진다. ) 
비록 실패로 돌아갔던 4번째 표준안은 stritc mode, native JSON 이 추가되어 ECMA-262 5th 로 발표하게 되었고 4번째 표준안에서 나온 이야기는 harmony 라는 프로젝트로 최근까지 논의되어 왔다.   


구글도 다음 세대의 자바스크립트 표준안을 위해 개발자 커뮤니티의 의견을 수렴하기 위해 오늘 소개하려는 Traceur프로젝트는 진행하고 있다.


자바스크립트는 오픈 웹 기술의 일부이고 이젠 커뮤니티의 힘으로도 충분히 표준안을 정립해 갈 수 있다고 생각한 것이다. 


사실 개인적인 잡담이고 더글러스 크록포드도 이와같이 이야기 했지만 ECMA 표준 재단은 정신을 차리고 열의를 보였으면 한다는 말을 하고 싶다.
 

그래야 나같은 자바스크립트를 주로 하는 프론트앤드 기술자들이 플레이 그라운드를 좀 누빌것 아닌가?





다음 세대의 자바스크립트


이번 JSConf 2011 에서는 차세대 자바스크립트에 대한 제안하는 세션들이 몇가지 선보였다. 그중에 CoffeeScript 에 대한 이야기와 구글의 Traceur 를 제안하었다. 

그리고 몇일전 구글은 트레이서 컴파일러 프로젝트를 발표했다. 물론 google code 를 통해 오픈 소스 기반으로 진행된다.  


내용을 살펴보니 차세대 자바스크립트라는 명목하에 ECMA-262 4th 표준 마련이 실패로 돌아가 그때 협의된 결과를 가지고 커뮤니티의 힘을 빌어 새롭게 진행하고자 하는 것이 살짝 엿보인다.


일단 목표는 자바스크립트 언어의 새로운 기능들이 추가되고 좀더 향상시켜 브라우저에서 직접적으로 컴파일 될 수 있고 또한 이로써 속도를 향상 시키는데 있다.


그럼 Traceur를 약간 살펴볼까 한다.
 


Getting Started


간단히 hello world 를 특정 엘리먼트에 표시하는 데모는 다음과 같다.


<html>

  ...

  <body>

    <script type="text/traceur">

      class Greeter {

        new(message) {

          this.message = message;

        }


        greet() {

          let element = document.querySelector('#message');

          element.innerHTML = this.message;

        }

      };


      let greeter = new Greeter('Hello, world!');

      greeter.greet();

    </script>

    ...

  </body>

</html>


위의 코드에서 평범하지 않는 ECMAScript 가 두군데 있다. 그것은 class 정의와 let 변수 설정 부분이다. 또 하나 특별한게 있다면 script 태그의 type 이 text/traceur 이라는 것이다.


Compiling


<html>

  <head>

    ...

    <script src="http://traceur-compiler.googlecode.com/svn/branches/v0.10/src/traceur.js"

        type="text/javascript"></script>

  </head>

  ...

</html>


컴파일을 해보고자 한다면 위와 같이 traceur.js 를 text/javascript 형태로 추가를 해주어야 하며 traceur.js 는 트레이서 자바스크립트 컴파일러 의 진입점이고 이 라이브러리 자체만으로는 아무것도 할 수 없고 bootstrap.js 를 함께 추가해야 traceur 코드를 컴파일할 수 있게 된다.


<html>

  <head>

    ...

    <script src="http://traceur-compiler.googlecode.com/svn/branches/v0.10/src/traceur.js"

        type="text/javascript"></script>

    <script src="http://traceur-compiler.googlecode.com/svn/branches/v0.10/src/bootstrap.js"

        type="text/javascript"></script>

  </head>

  ...

</html>



Language Features


트레이서에서 제공하는 모든 분법은 ECMA-262 4th 스펙에서 모두 논의되었던 내용을 기반으로 하고 있다.

부연 설명은 없고 제공하는 스펙 문서를 통해 습득하기를 권장한다.


Traceur Language Feature : http://code.google.com/p/traceur-compiler/wiki/LanguageFeatures

ECMA-262 4th proposal : http://wiki.ecmascript.org/doku.php?id=harmony:proposals



앞으로


국외 커뮤니티에서는 자바스크립트의 새로운 이름이 필요하지 않겠냐는 이야기(JavaScript needs a new name. What should it be?)도 오가기도 하고 있고 구글의 이런 실험은 다음 자바스크립트에 어떤 변화를 가져다 줄지 기대되고 개인적으로는 단순히 실험에서 끝나지 않고 많은 공헌자에 의해서 발전되고 개발자들에게 친근한 언어로 많이 갖춘 언어로 발전하였으면 한다.


가장 중요한건 표준 사양이 되어야 하고 스펙 문서도 좀 발전되었으면 한다는 것. ^-^/



Reference
 

 - http://code.google.com/p/traceur-compiler/ 

 - JSConf 2011 : http://traceur-compiler.googlecode.com/svn/branches/v0.10/presentation/index.html#1

 - Traceur Demo : http://traceur-compiler.googlecode.com/svn/branches/v0.10/demo/repl.html



See More


글을 올려는 시점에서 국외에서도 포스팅이 있어 함께 읽어보면 좋을 것 같다. http://www.i-programmer.info/news/98-languages/2395-javascript-creator-talks-about-the-future.html

이 친구 이번 JSConf 2011에서 차세대 자바스크립트(CoffeeScript)에 대한 제안을 했다.

그리고 차세대 표준화에서 실패를 번복해서는 안된다고 글의 마지막에 제안하고 있다. 동감하는 바이다.


이런 변화를 보니 ECMAScript 3번째 스펙에서 5번째 스펙이 나오기까지의 기간보다 더 빠르게 6번째 사양의 표준화는 빠르게 진행되리라 예상되어진다.

2011.5.10 추가.

The Future of JavaScript is in Your Hands : http://www.readwriteweb.com/hack/2011/05/developers-the-future-of-javas.php 

신고
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
짧은 코드의 문제였지만 꾀 오랜 시간을 들여서 풀이을 해봤습니다. 
@kangax가 블로그에 기재한 14개의 문제를 풀기 위해서 이해해야 할 부분 이외에 더 많은 내용을 알 수 있는 좋은 기회가 된 것 같습니다.  

 간편하게 프린트해서 볼 수 있도록 따로 PDF를 올려봅니다.



문제

( function( ) {
return typeof arguments;
) )( );


설명
일반적으로 arguments는 코드 블록 내에서 사용할 때에는 함수에 전달된 인자를 배열처럼 접근하게 되지만 arguments는 Array가 아닌 length와 index(0, 1 … n-1, n)를 속성으로 갖는 개체입니다.

function() { 
alert( arguments instanceof Array); //false
} )( );


사양
1. ECMA-262 5th 
A. 10.6 Arguments Object
B. 11.1.6 The Grouping Operator

정답
“object”





문제

var f = function g( ) { return 23; };
typeof g( );


설명
Function 생성자, 함수선언(FunctionDeclaration), 함수표현식(FunctionExpression), 함수 호출에 대한 정확한 이해가 선행되어야 한다.  아래의 4가지에 대한 구별하기 위한 문제이기도 하다.

1. Function 생성자에 정의된 sum변수에 할당함수
var sum = new Function( “x”, “y”, “return x + y;”);
2. sum으로 명명된 함수의 함수선언
function sum( x, y ) { return x + y; }
3. sum 변수에 할당된 익명함수 함수 표현식
var sum = function( x, y ) { return x + y; }
4. sum변수에 함수 표현식 plus이 할당되었다라고 명명
var sum = function plus( x, y ) { return x + y; }

위의 4가지는 거의 같은 역할을 하지만 아주 조금씩 다른점이 있다.

함수선언은 선언과 동시에 함수의 이름과 동일한 이름의 변수를 VariableEnvironment의 Environment Record에 생성한다.  따라서 함수 표현식으로 정의된 것과는 달리 함수 선언에 정의된 함수는 정의된 범위 내에서 이름을 사용할 수 있게 된다.
(MDC 와 ECMA-262 인용)

즉 아래의 코드는 함수의 선언으로 자동으로 g라는 변수가 생성되고 이 변수는 g 함수를 가리키게 된다.  (ECMAS-262spec 59p – 10.5 Declaration Binding Instantiation )

function g( ) { … }

하지만 문제에는 함수의 선언이 아닌 var 구문을 이용해 f 라는 변수를 선언하고 변수에 ‘함수표현식’ 즉 함수 리터럴을 할당한 것으로 함수 선언이 없다.  그래서 g 함수를 가리키는 변수는 존재하지 않게 된다.

var f = function g( ) { return 23; }

그런데 g 함수를 호출을 시도하기 때문에 undefined 인 g를 함수로서 호출하려고 하기 때문에 ReferenceError: g is not defined 이 발생하게 된다.


사양
1. MDC

2. ECMA-262 5th 
A. 10.5 Declaration Binding Instantiation
B. 11.2.5 Function Expressions
C. 13. Function Defintion


정답
Error





문제

function ( x ) {
delete x;
return x;
) ) ( 1 );


설명
이것은 delete 연산자(Operator)와 변수 구체화(Variable Instantiation)에 대한 이해를 묻는 문제이다.  
JavaScript의 delete 연산자는 특정 속성이 주어질 때 그 속성이 있는 개체에서 속성을 삭제한다.  하지만 이것은 모든 속성을 삭제할 수 있는 것은 아니다.  대상이 되는 객체 자신이 가진 속성이 아닌 것은 삭제할 수 없다.  

JavaScript의 모든 객체에는 prototype 체인에 의해서 외부 객체의 속성을 자신의 속성처럼 취하게 되지만 delete 연산 시에 이러한 속성을 발견하게 되더라도 제거되지 않는다.

function foo( ) { this.x = 21; }
foo.prototype.x = 12;
var o = new foo( );
alert( o.x );  //21
delete o.x;
alert( o.x ); //12

또한 개체의 속성은 ReadOnly와 DontDelete의 속성을 가질 수 있고 아래의 예시처럼 내장개체에 처음부터 존재하는 속성 중 DontDelete 속성들은 삭제되지 않는다.  하지만 내장 개체라 할 지라도 새롭게 지정하는 경우에는 DontDelete 속성이 아니기 때문에 삭제된다.

var arr = new Array(1,2,3);
delete arr.length;
alert(arr.length); //3
arr.newProperty = 21;
alert(arr.newProperty); //21
delete arr.newProperty;
alert(arr.newProperty; //undefined

이 문제를 이해하기 위해서는 delete 연산자뿐만 아니라 변수(variable)의 특징도 이해하고 있어야 한다.  var문을 사용하여 만들어지는 속성은 DontDelete 특성을 가진다.  즉 var 구문을 통해 선언된 변수는 삭제할 수 없고 함수 선언에 의해 생성되는 속성들도 같다.  함수 선언에 의해 생성되는 속성들은 함수가 실행될 때 생성되어지고 자동으로 소멸한다.  

<script>
var x = 21;
delete x;
alert( x ); // 21

function foo( ) {
var z = 12;
delete z;
alert( z );
}
foo( ); // 12
</script>

하지만 한가지 예외가 있는 것이 eval 함수를 사용하여 실행되는 코드에서 var 구문으로 변수를 생성하는 경우에는 DontDelete 특성이 없다. (만약 위의 코드를 firebug나 webinspector 에서 실행할 경우에는 DontDelete 습성이 없는 채로 생성됨)

결론적으로 인자로 넘어온 x 변수는 함수의 런타임에 x 라는 변수가 함수블록 내에 DontDelete 습성을 갖으며 생성되고 1의 값이 할당된다.  그래서 x는 삭제되지 않고 delete x; 구문은 false를 반환한다. (DontDelete 습성인 경우 false를 반환)


참고
1. MDC
2. Blog


사양
1. ECMA-262 5th
A. 11.4.1 The delete Operator
B. 11.1.6 The Grouping Operator
2. ECMA-262 3rd
A. 10.1.3 Variable Instantiation 
B. 10.2.2 Eval Code

정답
1





문제

var y = 1, x = y = typeof x;
x;


설명
이 것은 Comma( , ) 연산자와 Assignment( = ) 연산자의 조합에 있어서 연산자 우선순위에 대한 이해를 묻는 문제이다.  
MDC의 내용을 보면 다음과 같다.

Assignment( = ) 연산자는 오른쪽에서 왼쪽 (RightHandSideExpression)
Comma( , ) 연산자는 왼쪽에서 오른쪽 (LeftHandSideExpression)

Comma 연산자에 의해서 y = 1 가 코드가 선행 평가가 이루어지고 나서 x = y = typeof x; 가 평가되어진다.  그 다음 Assignment 연산자에 의해서 y = typeof x; 가 평가되고 x = y 가 순차적(right to left)으로 평가된다.  이때 y = typeof x; 는 x의 값은 정의되지 않았으므로 “undefined” 이다.  

결론적으로 ( x = ( y = “undefined” ) ) 처럼 되며 x, y는 “undefined”가 할당된다.


참고
1. MDC 


사양
1. ECMA-262 5th 
A. 11.1.6 Left-Hand-Side Expressions
B. 11.13.1 Simple Assignment
C. 11.13 Comma Operator ( , )


정답
“undefined”





문제

function f( f ) { 
return typeof f( ); 
} ) ( function ( ) { return 1; } ) );


설명
이 것은 코드를 상당히 난해하게 해놓았지만 의외로 간단한 문제이다.
함수 이름과 지역변수 이름이 같은 경우 어느 것이 우선하는 지에 대한 이해를 묻고 있다.  변수의 우선순위는 기본적으로 지역변수가 우선한다. 

x = 21;
function foo( x ) {
alert( x );
}
alert( x ); // 21
foo( 22 ); // 22

문제에서 제시한 코드는 외부 f 함수 호출과 함께 1을 반환하는 함수 리터럴이 인자로 넘어가고 이 인자는 외부 f 함수 블록 내에서 인자 f가 우선시 되어 typeof f( )는 함수 리터럴을 호출하고 1을 반환 받는다.

결국 return typeof 1; 이 된다.


사양
1. ECMA-262 5th 
A. 11.1.6 The Grouping Operator


정답
“number”





문제

var foo = {
bar: function( ) { return this.baz; },
baz: 1
};
function( ) {
return typeof arguments[0]();
} ) ( foo.bar );


설명
이 것은 처음 JavaScript 접할 때 난해한 것 중에 하나인 this에 대한 이해를 묻는 문제이다.  this 키워드는 일반적으로 다음의 세가지 형태일 때 사용되어 진다.

1. 인스턴스화 된 객체 내에서 메소드 호출(인스턴스화 된 객체가 암묵적으로 this 에 바인딩)
2. Function.call( scope, … ) 처럼 call 메소드를 통한 명시적 scope 지정
3. Function.apply(scope, …) 처럼 apply 메소드를 통한 명시적 scope 지정

위의 foo 객체의 경우에도 Object 리터럴도 변수에 할당될 때 new Object( ) 동일하게 평가된다.  그렇기 때문에 foo 는 인스턴스화 된 객체로 foo 객체가 this로 바인딩 되어 bar 메소드 호출 시 foo.baz 에 할당된 1값을 반환하게 된다.

익명함수로 foo.bar 의 함수 리터럴을 익명함수의 첫번째 인자로 넘겨 arguments[0] 에는 foo.bar의 함수 리터럴이 할당되어지고 arguments[0]( ) 는 foo.bar 함수를 실행하게 된다.

단 여기에서 주의해 할 것은 함수 리터럴의 scope(유효범위 즉 this)의 변화이다.  foo.bar( )를 호출하는 것과 arguments[0]에 담긴 함수 리터럴 즉 function() { return this.baz; } 를 호출하는 arguments[0]( ) 는 scope가 arguments로 변경됨을 알 수 있다.

결론적으로 arguments[0]( ) 는 arguments.function() { return this.baz; } 로 평가되어지고 arguments 에는 baz 속성은 존재하지 않아 할당된 값이 존재하지 않으므로 “undefined”가 반환된다.


사양
1. ECMA-262 5th
A. 11.1.1 The this Keyword
B. 11.1.5 Object Initialiser


정답
“undefined”





문제

var foo = {
bar: function( ) { return this.baz; }
baz: 1
}
typeof ( f = foo.bar )( );


설명
이것은 6번의 문제를 정확히 이해하고 있다면 쉽게 해결할 수 있는 문제이다.

먼저 f = foo.bar 를 보면 f 에 foo.bar 의 함수 리터럴이 할당된다.  그러면 ( f )( ); 로 축약된다. 이것은 다시 풀어보면 ( function( ) { return this.baz; } )( ) 와도 같고 이 함수 리터럴이 수행되는 scope는 즉 this는 window가 된다.
window 객체에도 baz가 존재하지 않기 때문에 6번 문제와 동일하게 “undefined”가 된다.


사양
6문항과 동일


정답
“undefined”





문제

var f = ( function f( ) { return 1; }, function g( ) { return 2; } )( );
typeof f;


설명
4번 문항에서도 언급했지만 Comma 연산자에 의해서 왼쪽요소에서 우측요소로 코드 평가가 진행된다.  

var x = ( 1, 2, 3 ); 
alert( x ); // 3;
var y = ( alert( 4 ), 5, function z( ) { return 6; } )( ); // 4
alert( y ); // 5

위의 예시로 알 수 있듯이 Comma 에 의해서 코드 평가가 좌에서 우측으로 진행되면서 alert( 4 ) 가 수행되는 것을 알 수 있다.  문제에 제시된 코드 역시 g 함수를 취하게 되면서 2를 반환하게 된다.


사양
4번 문항과 동일


정답
“number”





문제

var x = 1;
if ( function f( ) { } ) {
x += typeof f;
}
x;


설명
이 것은 2번 문항의 ‘함수선언(FunctionDeclaration)’ 과 ‘함수표현식(FunctionExpression)’에 대한 문항과 같다.  조건문에 함수표현식이 들어가 있기 때문에 true가 된다.  true가 되는 이유는 함수표현식의 경우에도 클로저(closure)를 반환하게 된다. (ECMA-262 5th 98p 참조)

그러므로 if( closure ) 는 만족하게 된다.  다만 함수 표현식은 함수의 선언과는 다르게 자동으로 동일한 이름의 변수가 생성되지 않는다.  그래서 x 는 숫자형 1 과 typeof f 의 문자열 “undefined” 의 += 연산자에 의해 x 값은 “1undefined”


사양
2번 문항과 유사


정답
“1undefined”





문제

var x = [typeof x, typeof y][1];
typeof typeof x;


설명
이 것은 이전 문제에 이어서 혼동을 유발하기 위해서 ( ) 에서 [ ]로 변경하였고 Comma 연산자 처럼 느끼도록 했다. ( 개인적인 느낌일 수도 있음 -.-a ) 이것은 Array 리터럴로 x 값에는 배열의 1 위치에 있는 typeof y 가 할당되게 된다.  y는 아무런 값이 할당되지 않았기 때문에 결국 x 는 “undefined” 가 된다.  

관건은 typeof 인데 typeof 의 경우 오른쪽에서 왼쪽 코드(right to left) 평가를 수행한다.  type of value  즉 “값 의 형태” 라고 해석하듯이 생각하면 쉽다.

결론은 typeof typeof x; 는 x는 문자열의 “undefined” 가 할당되어 있음으로 다음과 같이 풀어 쓸 수 있다.

typeof typeof “undefined”;
//typeof “undefined” == “string”
typeof “string”;
//typeof “string” == “string”


참고
1. MDC


사양
1. ECMA-262 5th 
A. 11.1.4 Array Initialiser
B. 11.4.3 The typeof Operator


정답
“string”





문제

function( foo ) {
return typeof foo.bar;
} )( { foo : { bar : 1 } } );


설명
이 것은 Object 리터럴에 접근을 묻는 문제로 함수 표현식을 호출할 때 넘기는 Object 리터럴 { foo : { bar : 1 } } 는 foo 인자값으로 지정되었기 때문에 foo.foo.bar 로 접근해야 한다.

문제에서는 foo.bar 로 접근하였기 때문에 “undefined”가 반환된다.


사양
1. ECMA-262 5th 
A. 11.2.1 Property Accessors


정답
“undefined”





문제

function f ( ) {
function f( ) { return 1; }
return f( );
function f( ) { return 2; }
} )( );


설명
이 것은 JavaScript 함수선언(FunctionDeclaration)에 오류가 아닌 함정이 숨어있다.  

TIP 컴파일 타임과 런타임
인터프리터에 의해서 해석되는 언어의 특징은 소스코드를 직접 실행하는 것인데 이 과정에서 코드의 해독단계와 실행단계로 나뉜다.  이것은 구문들의 표현식 검증, 소스 코드를 효율적인 중간 코드로 변환하거나 일부 시스템에서 이미 정의된 저장 코드를 수행하기 위해서이다. 

그렇기 때문에 중간에 코드상의 오류가 있는 경우 선행 코드조차 실행되지 않는다.  예를 들어 아래의 코드처럼 function 구문 자체(즉 함수표현식)가 잘못되었을 때 alert(‘12’) 조차도 수행되지 않는다.

<script>
var x = 12;
var y = 21;
alert( x );
function ( ) { 
alert( y ); 
</script>

즉 코드를 분석단계를 일컬어 컴파일 타임이라 하고 코드 분석이 완료되고 실제 코드를 실행하는 단계를 런타임 이라고 한다. 이것은 또한 ECMA-262 사양에 정의된 구문 수행을 위한 환경을 미리 만드는 과정이라고 할 수도 있다.

더불어 이런 특징 때문에 브라우저에서 JIT(Just In Time Compilation)을 통해 JavaScript의 속도 향상을 도모하고 있다.

함수 표현식과는 달리 함수 선언에서는 컴파일 타임에 함수명과 같은 이름으로 변수가 생성되기 때문에 다음과 같이 foo 함수가 호출된다.

<script>
foo( );
function foo( ) { alert( 21 ); }
</script>

하지만 다음의 코드는 에러가 발생한다.  왜냐하면 함수 표현식은 호출할 때 비로소 함수가 정의되기 때문이다.

<script>
foo( );
var foo = function( ) { alert( 21 ); }
</script>

여기서 알 수 있는 특징은 함수선언과 함수 표현식의 할당은 함수의 생성 시기가 다르다는 것이다.  즉 위의 코드에서는 컴파일 타임에 f 함수가 호출되고 f 함수 내에서 반환값이 다른 f 충첩 함수가 f 함수내의 지역함수로 선언된다.  하지만 동일한 이름(Identifier)이기 때문에 2를 반환하는 나중에 선언된 f 중첩함수가 덮어 씌여지게 되어 return f( )에서 f는 function f( ) { return 2; } 가 할당되어져 있다.

참고
1. The Definitive Guid, 5th Edition
A. 6.14 function
i. function 구문은 프로그램의 정적 구조를 정의하는 것뿐이다.
ii. JavaScript 코드가 구문 분석되고 컴파일 때 함수가 정의된다.

사양
1. ECMA-262 5th
A. 11.1.6 The Grouping Operator
B. 13. Function Definition

정답
2





문제

function f( ) { return f; }
new f( ) instanceof f;


설명
이 것은 new 연산자와 instanceof 연산자에 대해 이해를 묻는 문제입니다.
new 연산자는 개체를 생성하고 그것을 초기화하기 위해서 생성자(constructor) 함수를 호출한다.

function Identify( ) { … }
new Identify( arguments );

이 코드는 다음과 같은 과정을 통해 비로소 인스턴스가 생성된다.  

1. 아무런 속성이 정의되지 않은 새로운 객체를 생성한다.
2. 1에서 만든 객체 Prototype 내부 속성(__proto__ 속성)에 Identify.prototype 값을 설정한다.
만약 여기서 Identify.prototype 값에 지정할 객체가 없다면 Object.prototype값이 설정된다.
3. Identify를 호출한다.  이때 this 값은 1에서 만든 .객체로 할당되고 new 연산자와 함께 전달된 arguments는 그대로 설정된다.
4. 3의 반환값이 객체이면 그것을 반환하고 그렇지 않으면 1에서 만든 개체를 반환한다.

위의 과정을 이해하고 코드를 살펴보면 new f( )의 코드 평가의 결과는 f 함수가 호출되면서 자기 자신 function f( ) { return f; } 를 반환한다. 

function f( ) { return f; }
new f( )

결과적으로 new f( )는 f 함수가 되고 new f( ) instanceof f 는 f instanceof f 가 되며 이것은 false 이다.  자기 자신에 프로토타입 체인에 자신은 존재하지 않는다.

만약 new f( ) instanceof Function 혹은 new f( ) instanceof Object 의 경우에는 true이다.


참고
1. JavaScript Definitive Guide 5th 
A. 5.10.3 The Object-Creation Operator (new)
2. MDC


사양
1. ECMA-262 
A. 11.2.2 The new Operator
B. 13.2.2 [[Construct]]


정답
false





문제

with( function( x, undefined ) { } ) length;


설명
이것은 with 구문과 함수 리터럴에 대한 이해를 필요하는 문제이다.  
<script> … </script> 내에서 수행되는 변수, 함수등의 선언된 것들은 암묵적으로 구문 환경을 window 개체를 갖게 된다.  이 처럼 with 구문은 코드블록 내에서 암묵적인 구문 환경 개체를 지정하기 위한 것이다.

var foo = { bar : 12 };
with( foo ) {
alert( bar ); // 12
alert( zoo ); // ReferenceError: zoo is not defined
}

위의 간단한 예시처럼 with구문에 지정한 foo 개체는 코드블록 내에서 명시적으로 접근하는 것이아닌 암묵적인 구문 환경이 생성되어 진다.

즉 위의 문제는 with 구문에 주어진 함수 리터럴의 length property를 접근하는 문제인데 function literal은 Function 클래스로 생성되어지는 것이기 때문에 Function의 속성과 Function.prototype 개체의 속성에도 접근할 수 있다.


참고
1. MDC


사양 
1. ECMA-262 5th 
A. 12.10 The with Statement
B. 15.3.3 Properties of the Function Constructor


정답
2









신고
Posted by Rhio.kim

모질라는 JavaScript를 GPU의 리소스를 이용하여 과속화 시도를 하고 있습니다.  Firefox의 Jetpack 프로젝트 일원인 Aza Raskin 은 “Elevating JavaScript Performance Through GPU Power” 글을 통해 GPU를 이용한 가속화에 대한 가능성과 방법을 제시하고 있습니다.

1. 고품질의 디지털 동영상이나 음악
2. 복잡한 이미지나 음성인식
3. 자연이나 우주와 관련된 큰 사진 처리
4. 브라우저에서 대용량 로컬 데이터 처리
5. DirectX 또는 OpenGL 을 이용한 DOM 엘리먼트의 복잡한 에니메이션
6. SecondLifeOpenSim Grid와 같은 3차원 탐험
7. 실시간 오디오 및 비디오 편집
8. 브라우저에서 실행되는 통합 개발 환경

또한 이 기술을 통해 JavaScript는 웹 시장에서 더 큰 기대치를 가질 수 있을지 모르겠습니다.

이러한 웹 브라우저의 고급 처리 요구에 부응하기 위해 NVIDIA가 추진하는 GPU를 이용한 병렬 처리 아키텍쳐의 CUDA runtime 환경을 JavaScript에서 사용하는 방법을 검토하고 있다는 것입니다.


GPU 화된 JavaScript

JavaScript확장하는 방법으로 API를 확장하는 방법과 JavaScript 구문을 확장하는 방법 2가지를 제시하고 있습니다. 다음의 소스들은 CPU에서 동일한 계산 sqrFun의 복잡도 및 컬렉션의 크기에 따라 많은 시간이 걸릴 수 있는 가능성을 통해 알아 봅니다.

일반화된 코드이긴 하나 실무에서는 이러한 처리에 추가적으로 CPU의 자바스크립트 해석, 페이지 렌더링, 응용 프로그램에서 운영체제 루틴 등등 기타 잡다한 처리를 동반합니다. 

During all of these CPU cycles, what is the GPU doing?


API 확장
var numbers = new Array(), size = 1000;
for (var i  = 0; i < size; ++i)
numbers[i] = i;

var sqrFun = function(v) { return  v * v; }
for (var i  = 0; i < size; ++i)
numbers[i] = sqrFun(numbers[i]);


Jetpack.toGPU() 를 사용하여 GPU 프로세스를 명시
var resNumbers = Jetpack.toGPU( function(nums, numsSize) {
  var sqrFun = function(v) { return  v * v; }
  for (var i  = 0; i < size; ++i)
    numbers[i] = sqrFun(numbers[i]);
  }, numbers,  size);

// some job here

document.write(resNumbers);

var sqrFun = function(v) { return v * v; }
map(sqrFun, numbers);

Functional
var sqrFun = function(v) { return  v * v; }
map(sqrFun, numbers);

var resNumbers = Jetpack.toGPU(function(nums,  numsSize) {
return  map(sqrFun, numbers);  }, numbers, size);

Microsoft LINQ
var resNumbers = Jetpack.Linq.toGPU().from(numbers).map(sqrFun);

jQuery
$("div.test"). add("p.quote").addClass("blue").slideDown("slow").toGPU();


멀티코어 CPU가 일반화되어 가고 GPU도 iPhone과 같은 모바일을 포함하여 대부분의 장치에 탑재되며 클라우드의 등장으로 분산 처리가 일반적으로 되어 왔으나 현재 JavaScript뿐만 아니라 모든 프로그래밍 언어에서는 병렬처리를 효과적으로 작성하고 실행하는 방법을 모색하고 있습니다.

현재로서는 위의 예시 코드와 달리 일반적으로 프로그래밍을 하면 컴파일러와 인터프리터가 그것 자동으로 최적의 병렬처리 방식으로 처리할 수 있는 이상적인 시스템은 없기 때문에 개발할 때에 어떤 부분을 병렬 처리할지에 대한 선택권은 전적으로 개발자에게 있다는 것입니다.


요약
Jetpack 는 모질라 연구소에서 브라우저와 운영체제 Native API 연결을 통하여 브라우저의 효율과웹의 경험을 극대화 하기 위한 많은 실험과 성과를 내놓고 있습니다.  하지만 우려되는 것은 역시 표준과 동떨어진 기술이 특정 브러우저 밴더의 기술로만 활용된다면 과거의 IE의 히스토리를 그대로 반영하게 되지 않을까 하는 것이다.

하지만 현 시점에서 달리 생각해볼 문제는 HTML5를 포함한 웹 표준 기술들의 진화이다.  웹을 이루는 다양한 요소요소마다 발전된 웹 표준을 위해서 엄청난 실험과 시도들이 표준화에 참여하는 벤더들에 의해서 진행되어오고 있다.

그중 SVG, Canvas, Video, Audio 의 부분은 순수한 웹 기술만으로는 표현은 어떻게든 하겠지만 발전을 보장하지 않을 뿐더러 효율적이지도 못하다는 것이다.  점차적으로 웹에서 처리하는 정보는 하드웨어의 발전과 같이 엄청난 속도로 발전해 오고 있고 고도화 되어오고 있기 때문에 Jetpack과 같은 실험은 분명 빠른 미래에 필요한 기술이 되리라 예측해본다.



함께 읽어보세요.
JavaScript 필수 프로그래밍 언어로 !! - http://rhio.tistory.com/346
JavaScript in 2009 and 2010 - http://rhio.tistory.com/341

참고자료 : http://mozillalabs.com/jetpack/2010/01/25/elevating-javascript-performance-through-gpu-power/


신고
Posted by Rhio.kim
TestSwarm은 개발자들이 신속하게 여러 브라우저의 버전에 대한 자신이 개발한 JavaScript 코드를 테스트하기 위한 쉬운 방법을 제시하는 것을 목표로 모질라 연구소의 새로운 프로젝트입니다. 

John Resig 은 잘 알려진 것 처럼 jQuery 개발과 JavaScript 에반젤리스트로 있다가 새로운 팀의 자바스크립트 툴 개발자로 지난 4월부터 중심이 되어 프로젝트를 진행해 왔습니다.

아마 팀을 옮기고 첫 작품이라 심혈을 기울이지 않았을까 하는 생각을 해봅니다.


크로스 브라우징 JavaScript 테스팅 및 디버깅의 현재

처음이 TestSwarm은 jQuery팀을 지원하기 위한 도구로서 시작한 것인데 오늘날의 방법은 크로스 브라우저 JavaScript를 테스트를 쉽게 지원하거나 기준을 잡을 수가 없습니다.. 

최근 소개한 JavaScript Debug Tool은 실제 개발 시 디버깅할 수 있어서 개발자에게 유용하지만 완료된 프로젝트이거나 큰 프로젝트의 경우에 테스트를 위한 도구는 그간 없었고 이런 테스트는 거의 개발자나 기획자의 PC에 깔린 브라우저 종류에 의존했었습니다.

이에 TestSwarm은 JavaScript 테스트 기반의 개발을 위한 도구로서 매우 유용하게 활용되어지리라 봅니다.

참고 - 현존하는 JavaScript 디버깅 툴
 - FireBug : http://getfirebug.com/


구조
이에 미리 다양한 환경의 많은 참가자들을 모집하여 PHP와 Mysql로 개발되어진 중앙 서버에 연결된 사용자가 등록한 JavaScript 테스트를 배포하고 실행 결과를 서버에 집계하는 구조를 갖습니다.


참고로 우측에 뜨는 벤치마크 점수와는 달리 서버에서 테스트를 추진하고 그 결과를 기다려야 합니다.  현재는 로그인한 참가자의 숫자가 갖추어질 때까지 실행되지 않도록 되어있어 운이 나쁘면 테스트가 발생하지 않을 수도 있습니다.  이런 부분은 차차 개선 되리라 봅니다.


참가방법(일반 - Runner)
프로젝트가 생성되고 테스터의 브라우저가 필요한 경우라면TestSwarm 사이트에 상단에 초대장과 함께 테스트에 참여할 수 있는 박스가 나타날 것입니다. 가입 후 몇 번 가봤지만 아직까지 프로젝트가 생성된 것을 보지는 못했습니다. 

 

(2009.09.10 추가)
우연찮게 들어갔다가 테스트 하는 장면을 목격하게 되었네요.

Selector tests 수행중 정상적인 수행이 되는 경우 녹색이 표시

Ajax tests... 수행중 비 정상적인 수행이 발생되는 경우 빨간색이 표시



참여하게 되면 탭에서 바로 실행되고 자동으로 새로운 테스트를 위해 매 30초 간격으로 프로젝트 서버로 Ping을 합니다. 그러면 새로운 테스트를 연이어 수행합니다.

그 결과를 다음과 같이 보여줍니다.

 


Vimeo 에 올린 영상을 보면 자세한 운용 방법이 있습니다.  John resig 의 세미나나 발표를 보면서 느낀 거지만 앙드레김 선생님보다 좀더 빠른 말투라는 생각이 자꾸 드네요.  특히 이번 영상에서는 더더욱이   “Am~~~ JavaScript~~”, “Am~~”


지원
TestSwarm은 다양한 운영체제와 웹 브라우저를 지원하고 그에 걸맞는 많은 참가자를 원하고 있습니다.  사이트에서 가입하여 누구나가 참여할 수 있게 되어있습니다.
 
  현재 Windows XP에서 Firefox 3.5 사용자가 가장 많네요. 아무래도 모질라 랩에서 개발한 거라 사내 직원들이 많이 참여한 것이 아닌가 추측해봅니다.

TestSwarm 메인 사이트에 보면 그 수치를 아래의 그림처럼 표시하고 있습니다.
 


현재 TestSwarm은 jQuery, YUI, Dojo, MooTools 그리고 Prototype.js 를 포함한 많은 개발자들이 의존하고 있는 인기 있는 다수의 오픈 소스 기반의 자바스크립트 라이브러리 테스트를 하고 있습니다. 
TestSwarm는 오픈 소스화 하였기 때문에 원한다면 자신의 프로젝트를 위해서 직접 설치하여 활용할 수도 있습니다.

소스 다운로드 http://github.com/jeresig/testswarm/tree/master

그런데 소스상에는 있지만 아직까지 Test를 생성할 수 있는 구석은 안보이는 것 같습니다.



향후 계획
긴 안목으로 모질라의 TestSwarm 아키텍쳐로 개발자들이 만든 자신의 코드를 테스트하기 위해 좀더 쉽게 만들기 위한 계획이고 또한 수동 검사를 위한 옵션이나 사용자 상호 작용이 필요한 곳에서 실행할 수 있도록 할 계획이라고 합니다.

1. pastebin 같은 서비스에 여러분이 코드를 넣어 두고 다양한 브라우저로부터 실시간으로 되돌아 오는 결과를 볼 수 있습니다. (paste 는 붙여넣기, bin 은 실행형이니까 클릭해서 만들어 내는 서비스를 말할까요?)
2. 필요한 부분만 변경하에 보낼 수 있는 IDE 통합으로 빠른 테스트를 실시 할 수 있다.
3. 유저 인터페이스 코드의 수동 테스트, 수동 테스트 처리 절차와 함께 밀어 넣고 사용자가 실행 할 수 있도록 한다.
4. 정해진 테스트 환경이 아닌 정해지지 않는 다수의 브라우저에서 테스트를 해보기 위한 배포 (작은 iframe를 자신의 사이트에 포함시켜 두고 사용자의 표본 자료에 테스트 결과를 수집 할 수 있다.)
5. 브라우저에서 코드와 확장 기능을 실행 시켜서 테스트하는 능력


추가내용 [2009.08.31]
Test Swarm 의 구조입니다.  좀더 이해하기 쉽도록 그려보았는데요. 참고용으로 사용하세요.
(경우에 따라서 오류가 있을 수 있습니다.)

     클릭해서 보시면 편합니다.

1. Test Swarm 에서 테스트를 생성한다.
2. Job Queue 에 추가합니다.
    이와 동시에 해당 테스트가 발생하고 조건에 맞는 사용자들에게 invite 박스가 표시됩니다. (testswarm 사이트에 접속하면 우측 상단에 작은 box가 초대 박스로 바뀐다고 합니다.)
3. Join the Swarm 에 접속한 Runner 는 매 30초 마다 Job Queue 에서 자기에게 맞는 다음 테스트를 수행하게 되고
   결과를 서버로 전송하게 됩니다.
   성공 혹은 실패 등의 결과를 서버에 저장하고 6번에서 보이는 결과를 Test Swarm 에서는 볼 수 있게 됩니다.



  
  
신고
Posted by Rhio.kim
플래시 플랫폼에 FLARToolkit 을 이용하여 증강현실(Augmented reality) 구현에 대한 내용들이 많이 있는데요.

증강현실 관련 자료
위키 : http://ko.wikipedia.org/wiki/증강현실
라이브러리 : http://nyatla.jp/nyartoolkit/wiki/index.php?FLARToolKit

예시
okgosu님 : http://okgosu.tistory.com/170
비디오 구글 : http://video.google.com/videoplay?docid=6523761027552517909&hl=en


이 구현된 증강현실을 JavaScript 와의 인터페이스를 할 수 있도록 확장한 라이브러리가 있어서 소개합니다.
현재는 초기 모델인지 간단한 움직임에 대한 수치정보만 Flash 에서 ExternalInterface를 이용해 통신하는 것 같네요.

재미있어서 한번 찍어봤습니다.  뭐 증강현실에 대한 것은 Flash에서 구현된 것이지만 JavaScript와 동작할 수 있도록 한 것은 괜찮은 아아디어네요.

얼마나 실용적인지는 모르겠지만 Canvas에 Drawing 한다던가 여러가지 재미있는 일들을 만들 수 있지 않을까 싶기도 합니다.

영상이 잘 모이지 않을 수 있는데요. 부연설명을 드리자면 마커를 인식하고 붉은색 테투리를 그려서 표시하는 것은 Flash에서 처리되는 내용이고 그 하단 부분에 작지만 수치 정보가 표현되는 것이 있습니다.

그 부분이 Flash에 전달해주는 정보입니다.


출처 : http://kawa.at.webry.info/200904/article_2.html
신고
Posted by Rhio.kim

일반적이고 대부분의 브라우저 스니핑 기법은 각 브라우저에서 지원하는 DOM의 차이점을 이용하여 활용하고 있습니다.  

그리고 최근 Ajaxian.com 을 통해 소개된 기사에서는 JavaScript 만을 이용한 스니핑 방법을 소개하고 있습니다.


꾀 오래전에 Opera의 Array의 Slice 메소드가 IE, FF, Safari와 다르게 동작하여 피드백을 해놨는데 답변이 없더니 패치는 된것 같습니다.

이렇듯 현대 주(major) 브라우저의 자바스크립트는 ECMA Script 262-2 Spec을 따르고 있는데요.  이 JavaScript 역시 브라우저마다 작은 차이점들을 가지고 있습니다.  

//Firefox detector 2/3 by DoctorDan
FF=/a/[-1]=='a'

//Firefox 3 by me:-
FF3=(function x(){})[-5]=='x'

//Firefox 2 by me:-
FF2=(function x(){})[-6]=='x'

//IE detector I posted previously
IE='\v'=='v'

//Safari detector by me
Saf=/a/.__proto__=='//'

//Chrome by me
Chr=/source/.test((/a/.toString+''))

//Opera by me
Op=/^function \(/.test([].sort)

소개된 코드들은 상당한 테스트와 분석에서 나온 결과물이 아닐까 생각이 듭니다.

더보기




신고
Posted by Rhio.kim

최근에 Flash 10 패치되면서 클립보드 카피가 지원되지 않게 되었는데요.
9까지 잘되던 것이라 크게 생각하지 않고 있었는데 최근 지인이 여쭤봐서 테스트 해봤더니 모두 안되더군요. 


그래서 구굴링을 열심히 했지만 해결책은 찾지 못하고 있었는데 미국시간으로 어제 Ajaxian.com 에 Zero Clipboard라는 라이브러리에 대한 포스팅이 있었네요.   차차 알아보기로 하고 원인부터 알아봅니다.


Flash 10 으로 패치되면서 보안정책이 많이 바뀌었나 보네요.


User-initiated action requirements in Flash Player 10
http://www.adobe.com/devnet/flashplayer/articles/fplayer10_uia_requirements.html


위의 링크에 보면

 

Clipboard: The ActionScript 2.0 and ActionScript 3.0 API called System.setClipboard(), available in Flash Player 9 and earlier, now requires user interaction to write to the system Clipboard. In addition, the new Clipboard.generalClipboard object in Flash Player 10 can read and write the system Clipboard. Writing to the system Clipboard using either API requires the write to happen as the result of a user-initiated action. In addition, reading from the system Clipboard using the new ActionScript 3.0 API, Clipboard.generalClipboard.getData, can succeed only as the result of a paste event handler. Since a paste event handler can be triggered only by activating the context menu with the mouse (by right-click or Control-click, depending on operating system) or by using the appropriate keyboard shortcut for paste (Control+V or Command+V), APIs executing inside a paste handler are the de facto result of a user-initiated action. These restrictions avoid the problem of a SWF being able to set Clipboard contents unbeknownst to the user.


 

 

간단히 요약하자면 Flash 9 이하 버전에서는 System.setClipboard() 를 통해서 이용 가능했지만 지금은 유저의 상호작용이 필요하다고 합니다.


ExternalInterface를 통해서 Flash에 접근하여 Clipboard를 접근하거나 하는 것이 가능했지만 코드나 실제로 사용자에 요청되지 않는 것들에 대해서는 지원하지 않는다고 Adobe에서 발표하였습니다.

안타깝지만 전혀 없지는 않을 것입니다.  어떻게 사용자의 경험을 그대로 살리고 클립보드 카피를 지원할 것인가에 대해 또 다른 연구가 지행 되리라 봅니다.


이에 Zero Clipboard라는 JavaScript 라이브러리는 이 문제에 있어서 흥미를 갖고 가려운 곳을 긁어주려 하고 있습니다.


프로젝트 사이트 : http://code.google.com/p/zeroclipboard/


이 라이브러리의 키 포인트는 Clickjacking 이라는 기술을 사용한 것입니다.  Clickjacking 은 원래 웹 유저들을 속이기 위한 악의적인 기술중에 하나입니다.  작년 보안 취약점으로 이슈가 되었던 내용들이 찾아보니 좀 있더군요.  아래 내용을 통해서 좀더 많은 정보를 얻을 수 있구요.  이 동영상은 기사중 일부인 실제 시연 영상입니다.



위키 : http://en.wikipedia.org/wiki/Clickjacking
관련기사 : http://boanchanggo.tistory.com/363


첨부한 동영상을 본다면 Zero Clipboard 라이브러리의 기초적인 구현 방법을 이해하실 수 있습니다.  또한 Wiki를 통해서 상세한 구현 설명도 해놓았으니 참고하시기 바랍니다.

 

http://code.google.com/p/zeroclipboard/wiki/Instructions


프로젝트 위키 내용 중 가장 핵심적인 내용은 다음과 같습니다.

 

This library is fully compatible with Flash Player 10, which requires that the clipboard copy operation be initiated by a user click event inside the Flash movie. This is achieved by automatically floating the invisible movie on top of a DOM element of your choice. Standard mouse events are even propagated out to your DOM element, so you can still have rollover and mouse down effects.


바로 이미 유저의 클릭 이벤트를 가로챌 Flash를 사용자가 선택한 DOM 엘리먼트의 가장 앞쪽에 눈에 보이지 않게 띄웁니다. 그리고 표준 마우스 이벤트들은 DOM 엘리먼트 밖으로 전파된다는 점을 이용한 것입니다.  빠른 생각과 빠른 시도 매우 좋습니다. ^-^ But…


Zero Clipboard 라이브러리는 최초 시도와 기초적인 구현 방법에 대한 제시로서는 매우 좋은 자료임에는 분명해 보이지만 실제 다운로드 받아서 보니 많은 사용자 경험과 시스템적인 지원을 위해 매우 많은 기능이 들어가 있네요.  사용하기 나름이겠지만 서비스에 따라 활용도는 많이 달라질것 같습니다. 


쉽게... 클릭해서 클립보드에 카피하기를 위해 저리 복잡한 짓을 해야 할까? 라는 생각이 먼저 듭니다.
서비스에 맞게 재 구현해서 사용하는 것이 더 나을 것이라는 생각도 드네요.


신고
Posted by Rhio.kim

다음의 코드를 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

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

신고
Posted by Rhio.kim
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 공격에 대한 자료를 첨부합니다.
상세한 자료는 아니고 아웃라인(흐름)에 대한 내용입니다.


신고
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
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
프로포타입과 스크립타큘러스 상세보기
크리스토피 포트누브 지음 | 인사이트 펴냄
이 책은 자바스크립트 개발에서 필수적인 라이브러리가 된 프로토타입(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”를 “비간섭 혹은 비간섭적인” 즉 비간섭 자바스크립트 라고 정리해 봅니다. (발음 : 어넙트러시브 자바스크립트)

신고
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
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
Ajaxian.com 에 재미있는 포스팅이 있길레 퍼옵니다. ^-^;

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

사용자 삽입 이미지

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

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

신고
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
클로져(Closure) is what?
Scope에 제약을 받지 않는 변수들을 포함하고 있는 코드블록이다.

이러한 변수들은 코드블럭이나 글로벌 컨텍스트에서 정의되지 않고 코드 블록이 정의된 환경에서 정의된다.

"클로져"라는 명칭은 실행할 코드블록(자유 변수의 관점에서, 변수 레퍼런스와 관련하여 폐쇄적이지 않는) 과 자유변수들에 대한 바인딩을 제공하는 평가 환경(범위)의 결합에서 탄생한 것이다.

사실 저런 이야기 매우 어렵습니다.   그래서 좀더 어렵고 혼돈되게 책에 있는 내용을 인용합니다.

From javascript definitive guide 5th


This combination of code and scope is known as a closure (…). All
Javascript functions are closures.

When a nested function is exported outside the scope in which it is defined

When a nested function is used in this way, it is often explicitly called a closure


이 코드와
스코프의 조합은 클로져 알려져 있습니다.
자바스크립트 모든 함수들은
클로져입니다.

중첩합수가 함수 정의하는 것을 스코프 밖에서 이루어질 때 입니다.

중첩함수를 이 방식으로 사용할 때 그것은 자주 명백하게 클로져 불러지고 있습니다.


2008.10.14 추가내용

When a nested function is exported outside the scope in which it is defined

"중첩된 함수가 그 함수가 정의된 유효 범위의 바깥으로 익스포트(export)될 때다."

 (한글 번역서p.191)<낭망백수님 의견>

매우 혼동스러워 집니다.  그래서 클로져라는게 도대체 무엇인지 개념적으로 A = B이다. 라고 답을 낸 다는 것은 너무 단편적인 결론을 요구하는 것이기 때문에 클로져의 개념을 이해하는 것을 목적으로 둡니다..

좀더 빠른 이해를 돕기 위해서 그림으로 표현해봅니다.

사용자 삽입 이미지

outerFn()은 우리가 알고 있는 function입니다.   function을 수행하게 되면 var을 통해서 function 내에서만 사용되거나 설정되는 variable을 가집니다. 이는 달리 말해 function scope에서만 참조되는 변수이지만 경우에 따라 클로져(closure)에 의해서 참조가 가능해진다는 것입니다.

outerFn 내의 var closure='is Closure.'; 는 메모리에 적재를 하게 되고 이는 outerFn이 수행될때 해당 메모리를 참조하게 되고 수행이 종료되고 참조가 없어지면 자동으로 GC(가비지 컬렉션)이 일어나 메모리에서 해제되게 됩니다.

하지만 var closure = 'is Closure.'; 를 어디선가 참조를 하고 있다면 아니 그전에 다른곳에서 참조가 발생할 때 바로 클로져가 생성되면서 클로저를 통해서 해당 variable를 참조하게 됩니다.

사용자 삽입 이미지
위에서 볼때 func에는 outerFn에 의해서 반환된 function을 가지고 있습니다.  이 function은 outerFn이 가지고 있는 내부 variable를 참조하고 있습니다.  이때 outerFn이 갖은 variable을 외부에서 참조하려고 하니 쉽게 private를 public으로 참조하려고 하니 과연 되지 않아야 하지만 우리의 javascript의 유연함은 이뤄 말할 수 없을 만큼의 기능을 가지고 있습니다.

아무튼 그렇게 클로져는 이런 상태에서 private를 참조하려고 시도할 때 발상하여 해당 참조를 해야하는 function의 즉 outerFn의 코드블럭을 클로져를 통해서 참조할 수 있게 됩니다.  클로져 자체가 코드블럭이라 해도 과언이 아니겠습니다.

위의 그림에서는 클로져가 발생했고 이는 GC에 의해서 메모리 해제가 되지 않습니다.  즉 func 이 계속적으로 클로져를 통하여 var closure = 'is Closure.'; 를 계속 참조하고 있기 때문입니다.  그래서 우리는 강제적으로 클로저를 해제할 수 있는 상태를 만들어 주어야 합니다.

사용자 삽입 이미지

'조만간 Gabage Collection in Javascript 에 대한 글을 포스팅하려 준비중입니다.  그때 좀더 자세한 사항을 포스팅하도록 하겠습니다. 약속'

var func = outerFn(); 을 하고.
     func('function'); 을 통해서 원하는 결과 값을 얻었다면 var func = null; 을 통해서 클로져를 통한 참조 point를 null 시켜주게 되면 주기적으로 GC에 의해서 메모리에서 반환되게 됩니다.


결론
사용자 삽입 이미지
  Scope에 제약을 받지 않는 변수들을 포함하고 있는 코드블록이다.
그리고 이는 Javascript에서 메모리 누수를 발생하는 요인중에 하나이다.



참조 :
 1,
http://www.ibm.com/developerworks/kr/library/j-jtp04247.html
 2.
http://en.wikipedia.org/wiki/Closure_%28computer_science%29


신고
Posted by Rhio.kim
Data Caching Structure in Ajax(XHR) Pattern

웹에서는 수 많은 페이지에서 서버에 수 많은 데이터를 요청합니다.
Web 2.0 이전 방식에서는 페이지가 링크를 통해 이동할 때마다 서버에 불필요한 데이터 요청을 하게 됩니다.

예를 들어서 어느 블로그나 카페에 컨텐츠를 구성하는 요소 중 카테고리와 게시판이 있습니다.
우리는 이 게시판에서 요구하는 것은 게시글의 제목을 눌렀을 때 그 게시글에 대한 상세한 정보입니다.

누가 작성하였고 등록된 날짜와 시간이 언제인지 그리고 그 게시글의 내용이 무엇인지 하지만 이전 방식은 화면이 리로딩 되면서 게시글 보기 페이지로 이동되면서 좌측 카테고리 목록도 서버에서 다시 요청하는 쿼리가 수행되고 화면 인터페이스를 구성하기 위한 여러가지 쿼리들이 함께 수행되게 됩니다.

이는 Web 2.0 방식에 좀더 정확한 표현으로 Ajax 개발에 있어서 비 효율적임을 알 수 있습니다.
이로서 우리가 생각해야 하는 것은 데이터 캐싱에 대한 구조입니다.

Javascript를 이용한 간단한 예제를 들어보자면 아래의 그림과 같습니다.

사용자 삽입 이미지

기본적인 user interface 를 구성하는 코드들에 서버에 비동기 데이터 요청을 하게되는 XMLHTTPRequest 가 있습니다. 그리고 서버 사이드에서 이 비동기 요청을 받아 DBMS에 해당 요청에 대한 쿼리만 수행하고 그 결과를 응답해줍니다.

이때 화면이 리로드 되지 않기 때문에 우리는 받아온 데이터를 javascript 의 variable 즉 local storage에 hash( { key : value } ) 형태로 데이터를 저장해 놓습니다.  이는 저장된 데이터를 활용해 동일한 데이터 요청을 하지 않게 됩니다.

위에서 보는 것처럼 XMLHTTPRequest가 request가 발생되었을 때 var storage 에 기존에 요청한 데이터가 존재하는지 체크하여 있으면 Server-side Script에 요청을 하게 되고 이미 존재한 경우에는 요청 없이 local storage에 이미 있는 데이터를 그대로 활용하게 됩니다.

이 데이터 캐싱 구조는 Ajax 개발에 있어 매우 중요하고 Ajax Application을 개발하는 목적을 달성시켜주는 패턴중에 하나라고 말할 수 있습니다.

간단한 예제 소스입니다.

위의 예제처럼 storage에 서버에 요청했던 정보들을 저장해놓게 되면 재 요청이 이뤄지지 않고 기존 데이터를 그대로 활용할 수 있습니다.

하지만 단점은 한 페이지에서만 활용할 수 있으므로 화면이 리로드되거나 다른 페이지로 이동하게 되면 활용 할 수 없게 됩니다.

Firefox에서는 이를 session storage와 global storage로 storage 메커니즘을 지원하고 있습니다.

위의 예제는 session storage와 유사한 방식이며 global storage는 브라우저가 닫히기 전까지 사용할 수 있는 storage를 역할을 하고 있습니다.   하지만 현존하는 브라우저에서 모두 지원되는 메커니즘은 아닙니다.

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

Opera의 Array native에 문제일까??
오늘 오전 내내 삽질의 연속..

IE, FF, Safari 에서는 리스팅이 잘되는데 유독 Opera에서 오 작동을 해서 결국은..

Opera의 Array method 중
slice method에 문제가 있음을 발견했습니다.

분명 같은 스팩을 사용할텐데 왜 Opera에서만 이런 문제가 발생하는 지 모르겠군요..

다음 코드를 참고하세요.

아무것도 없는 length가 4인 array

var arr = [1,2,3,4];
var xxx = arr.slice(0,10);
     alert(arr);
     alert(xxx);
     alert(arr);

결과 ( alert(xxx)의 수행 )
     IE              FF             Opera         Safari
[1,2,3,4]     [1,2,3,4]       [1,2,3,4]      [1,2,3,4]

당연한 결과입니다.  하지만 값이 없는 배열일 경우에는 그 결과가 달라집니다.

var arr = new Array(4);  //or [,,,]
var xxx = arr.slice(0,10);
     alert(arr);
    alert(xxx);
    alert(arr);

위의 코드의 경우 Opera의 경우에만 결과가 틀립니다.

결과 ( alert(xxx)의 수행 )
     IE              FF             Opera         Safari
   [,,,]           [,,,]              []              [,,,]

오페라만 값이 넘어오지 않습니다.
arr 이 갖는 여러가지 배열에 상황에서 slice 메서드를 수행해 봤지만 slice에 의해
반환되어질 배열의 각 구성 요소의 내용이 undefined 면 반환된 배열의 length는 0으로 되어 버린다는 것..


신고
Posted by Rhio.kim
var a1 = "1";
var a2 = "123.45667";

사용자 삽입 이미지
이것을 number 형으로 형변환을 하려면 우리는 기본적으로 parseInt, parseFloat 를 생각합니다.
당연한 것이죠..


var b1 = parseInt(a1, 10);
var b2 = parseFloat(a2);

이렇게 하면 typeof b1, typeof b2 로 찍어보면 number 형으로 인식합니다.

좀더 간단하게 바꾸면 어떻게 할까요??
사용자 삽입 이미지

답 :
var b1 = a1*1; <-scratch here
var b2 = a2*1; <-scratch here
신고
Posted by Rhio.kim