Sangil Jung - humbroll's twitter

브라우저에는 same origin policy 라는 것이 있습니다.
악의적인 자바스크립트 코드로 부터 보호하기 위하여 어떤 영향을 받는 문서(document)와 다른 도메인을 가지고 있을경우 메시징 자체를 막아버리는 정책입니다. 보안상 제약이기 때문에 필요악이긴 합니다만, 실제 개발을 해 나가게 될때는 여간 불편한게 아닙니다. 예를들어 가젯들이 한페이지 내에 iframe으로 여러개 존재하고 이 가젯들끼리 통신을 하고자 한다면 어떻게 해야 할까요. 이럴 경우 same origin policy때문에 문서간 스트립트 메시징(cross document messaging)이 불가능 합니다(IE에서는 브라우저 옵션 설정을 통해 이 제약을 해제할 수는 있습니다만, 위험합니다). 그래서 서버단으로 콜을 날리는 식으로 다소 비효율적으로 사용해 왔던게 사실입니다.

HTML5에서는 이에 대한 대안이 포함되어 있습니다.
현재 working draft로 진행되고 있는 HTML5 스팩의 7.4 Cross-document messaging 부분에 설명이 잘 나와 있으며, 저 스팩에 나온 예제 소스코드를 보면 단번에 알 수 있습니다.


주의할 점이 하나 있습니다.
IE8과 Firefox3에서 이 메소드를 지원합니다만, 두번째 아규먼트인 targetOrigin 가 IE8에서는Optional이고 Firefox3에서는 Required입니다. 다음 링크를 참고 하세요.
- IE8 postMessage
- Firefox3 postMessage

oauth 메일링 리스트에 James Manger의 현재 oauth스팩에 대한 한계점과 그에대한 proposal을 하는 스레드 6월 24일자로 있어서 간단하게 정리해 봅니다. oauth 차후 버전에 꼭 있었으면 하는 부분들이 제안에 있어서 반갑기까지 하네요.ㅋ 직역하여서 어색한 부분 있더라도 양해 바랍니다. 문맥상 이상한 부분 있는데 댓글로 검수해주시면 정말 감사히 고치겠습니다.^^
그러고 보니 바로 오늘(08/6/26)이 OAuth summit이 열리는 날이네요~ 좋은 결과 있기를~.


Disentangling delegation and authentication

OAuth가 인증 메커니즘을 위임하는데 있어서 의존도를 더 적게 명시할 수 있다면, 더 이해하기에 좋고, 구현하기 좋으며, 확장하기도쉬워질 것이다. 곧 있을 OAuth summit에서 OAuth 1.1혹은 2.0에서 이슈가 될 것을 기대해본다.

OAtuh 1.0은 4개의 튜플로 이루어진 핵심 데이터 모델을 가진다 :
그리고 3개의 인증 알고리즘을 지원한다:

이러한 구성 요소들이 다음과 같이 적시적소에 쓰인다면 전혀 문제 될 것이 없다 :    

Request(with 4-tuples) --> [algorithm] --> authentic request

그러나, 여러가지 예외사항들이 발생할 수 있다.

1. request token을 요청했는데 아무런 token 혹은 token secret이 없을 때
2. 사용자를 서비스로 리다이렉트 시킬 때, 사이닝(signed)이 되지 않은 요청일 경우
3. PLAINTEXT 알고리즘은 항상 token과 token secret을 함께 보내는데, 한개의 item만 갈 수가 있다(즉, token secret은 없이 token만)
4. RSA-SHA1 알고리즘은 token secret을 무시한다.
5. RSA-SHA1 알고리즘은 별도의 consumer private RSA key가 있어서 consumer secret 이 필요가 없다.
6. desktop app 나 javascript widget은 많은 사용자의 컴퓨터에서 돌아감에 따라 주어진 consumer secret을 보호하기 어렵기 때문에 그것을 사용할 수 없다.
7. 등록을 취소한 app는  consumer key 혹은 consumer secret을 가지지 않는다.
8. app와 service간에 어떤("2-way") 트랜잭션은 사용자에게 속한(behalf)것이 아니므로 token이나 token secret이 없다.
   

위에 제시한 각각의 예외사항은 충분히 일어날 수 있다. 그러나 이렇게 많은 예외를 위해 필요사항을 모델에 제안하는 것은 틀리다. 우리는 이러한 문제를 현명하게 나누지 않았다. 

대안은 어떤 standalone 인증 알고리즘을 정의하는 것이다.

OAuth-RSA
서버는 401 응답에 다음과 같은 헤더정보를 넣은 OAuth-RSA를 지원하도록 지시할 수 있다:
 

WWW-Authenticate: OAuth-RSA realm=...
    how=uri,header,body what=header,body

클라이언트는 header 그리고/혹은 body의 RSA private key로 사이닝을 할 것이고, Authorization header나 query params혹은 body에  signature등을 넣어야할것이다.

OAuth-PLAIN
서버는 401 응답에 다음과 같은 헤더정보를 넣은 OAuth-PLAIN을 지원하도록 지시할 수 있다:

  WWW-Authenticate: OAuth-PLAIN realm=...
    how=uri,header,body

클라이언트는 Authorization header 혹은 query params 혹은 body에 oauth_secret파라미터를 포함시켜야 할 것이다.

OAuth-HMAC
서버는 401 응답에 다음과 같은 헤더정보를 넣은 OAuth-HMAC를 지원하도록 지시할 수 있다:

  WWW-Authenticate: OAuth-HMAC realm=...
    how=uri,header,body what=header,body

클라이언트는 headre 그리고/혹은 body에 message authentication code(MAC)을 계산하고, Authorization header 혹은 query params 혹은 body에 MAC등을 넣어야 할 것이다.

["what" indicates what parts of the request to sign;
"how" indicates how to incorporate the result into the request;
both could list all supported options]

이렇게 정의된 알고리즘은 특정 위임에 대한 것이 아니다. 이는 어떤 HTTP 요청에 대해서도 사용될 수 있다.

OAuth는 다른 알고리즘을 효율적으로 정의한다: 하위 요청을 통해 MAC을 계사하는데 사용되는 한개의 응답에 secret을 제공하는 것. 이는 특이한 메커니즘이다. 이처럼 동작하는 어떤 인증 스킴도 알지 못하지만, 이는 몇몇 보안상의 잇점을 제공한다. 이것에 대해서 생각하는 가장 좋은 방법을 찾았는데, 그것은 'crypto cookie'이다. 이는 하위 요청에 사용되어지는 일부(blob) 서버 응답의 표준 쿠키와 유사하다. 그러나 blob을 포함하는 것 대신에 그것을 직접적으로 노출하지 않고 당신이 blob을 알고 있음을 증명하는데 사용되는 MAC을 포함할 수 있다. 이러한 방식으로 우리는 4번째 인증 메커니즘을 정의할 수 있다.

OAuth-Crypto-Cookie
서버는 401 응답에 다음과 같은 헤더정보를 넣은 OAuth-Crypto-Cookie를 지원하도록 지시할 수 있다:

  WWW-Authenticate: OAuth-Crypto-Cookie realm=... secret=...
    how=uri,header,body what=header,body

클라이언트는 MAC key로 secret을 사용하고 OAuth-HMAC당 인증 요청을 해야할 것이다.

마지막으로 OAuth 전체적인 관점에서의 위임(delegation)이 있다.
나는 위임(delegation)에 대한 HTTP 인증 메커니즘을 분리하여 접근하는 것을 좋아한다.

OAuth
서버는 401 응답에 다음과 같은 헤더정보를 넣은 OAuth를 지원하도록 지시할 수 있다:

  WWW-Authenticate: OAuth realm=... authz=... access=...
    how=uri,header,body

클라이언트는 authz URI로 사용자를 리다이렉트 시켜야 할 것이다(선택적으로 callback URI를 포함).  클라이언트는 Authorization 헤더, 혹은 query params혹은 body에 oauth_token을 포함시켜야할 것이다.

OAuth는 OAuth-PLAIN, OAuth-RSA, OAuth-HMAC, OAuth-Crypto-Cookie, 혹은 어떤 다른 인증 메커니즘(HTTPS와 함께 클라이언트 확인(certs); app에 대한 OpenID ...)과 묶여질 수 있다. OAuth는 oauth_token을 지원한다: 위임을 구별하기 위하 서버로부터 사용되는 blob. 그것은 요청의 여타의 요청에 사이닝 될 수 있다.

만약 token이 자동으로  일정기간마다 갱신될 필요가 있다면, "WWW-Authenticate: OAuth"헤더에 "token=..."어트리뷰트를 추가할 수 있다. 만약 "token"이 현재형이고, "authz"는 그렇지 않다면, 단지 존재하는 모든 oauth_token을 새로운 값으로 교체하면 된다. 만약 "authz"가 현재형이면, 사용자는 리다이렉트되어야만 할 것이다.

컨텐트 서버로부터 보안서버가 분리된 프로바이더는 위임(delegation)혹은 갱신이 요구될때면 언제든지 컨텐스 사이트에서 보안 서버로의 요청을 리타이렉트 시킬 수 있다. 보안 서버는 어떤 OAuth[-*] 메커니즘을 사요앟ㄹ 수 있고, 따라서 컨텐트 사이트로 돌려서 요청을 리다이렉트 한다.

어떤 자세한 사항들이 겉보기에 그럴듯 하더라도, 어떤 인증을 풀어내는 컨셉과 위임(delegation)이 명료하기를 희망한다.

- James Manger

본 내용은 Javascript The Definition Guide 5/E의 내용을 발췌, 요약한 것으로 부분적으로 제가 이해하기 쉽게 적은 커맨트들이 있습니다^^;

자바스트립트에서는 Java, Ruby, C++등의 객체지향 언어에서와 같이 클래스를 지원하지는 않지만(javascript 2.0에서는 클래스가 지원된다고 합니다), 자바스크립티의 객체에는 고유의 프로퍼티집합을 가지고 있는데, 이를 이용해서 모조 클래스(pseudoclass,이하 클래스)를 만들 수 있다고 한다. 이 클래스는 프로토타입 객체나 생성자 함수를 사용하여 구현할 수 있다고 한다.

생성자

1. new Obejct();
2. var array = new Array(10);

new를 사용하는 방식은 아무 프로퍼티도 없는 객체 생성 후에 new 뒤에 있는 함수를 호출하게 되는데 이 함수 안의 this를 새로 생성된 객체가 가리키게 된다.

1. function Rectangle(w, h){

2. this.width = w;

3. this.height = h;

4. }
5. var rect1 = new Rectangle(2, 4);
6. var rect2 = new Rectangle(8.5, 11);

생성자 함수는 일반적인 객체지향에서 그렇듯이 반환값(return)값이 없다.

프로토타입과 상속

자바스크립트에서 메소드는 객체의 프로퍼티이자 호출 가능한 함수이다. 메소드 내의 this는 그 메소드를 소유하고 있는 객체를 참조한다. 객체지향적으로 구현을 한다면?

1. var r = new Rectangle(8.5, 11);
2. r.area = function(){ return this.width * this.height; }
3. var a = r.area;

하지만, 이는 객체 r을 위한 메소드일 뿐 클래스 Rectangle이 가지고 있는 메소드가 아니기 때문에, 객체향적으로 한다면 다음과 같이 생성자 안에 그 함수를 선언하는 것이 더 맞겠다.

1. function Rectangle(w, h){
2. this.width = w;
3. this.hegith = h;
4. this.area = function(){ return this.width * this.height; }
5. }

하지만, 이게 제일 좋은 해결책은 아니라는 것. 이렇게 할경우 객체 3개를 생성하면 3개의 area함수가 각각의 객체에 있기때문에 비효율 적이다. 단지 width와 height가 다를뿐 그 안의 연산은 동일하기 때문.

이를 해결하기 위한 것이 자바스크립트의 모든 객체가 가지고 있는 프로토타입이라는 또 다른 객체를 내부적으로 참조할 수 있다는 것을 이용하는 것이다. 객체는 프로토타입의 프로퍼티들을 자신의 프로퍼티로 가져온다. 즉, 자바스크립트 객체는 자신의 프로토타입에 있는 프로퍼티들을 상속 받는다. 프로토타입에는 기본적으로 constructor라는 프로퍼티를 가지는데 이는 프로토타입이 연관되어 있는 생성자 함수를 가리킨다.

1. var d = new Date();
2. d.constructor == Date ; // true 반환
3. var o = new Objec();
4. typeof o == "object"; //true 반환 typeof는 constructor프로퍼티 값을 사용한다.

프로토타입 프로퍼티를 이용한다면

1. //생성자 함수는 각 인스턴스의 프로퍼티가 다른 값이 되도록 초기화시킨다.
2. function Rectangle(w, h){
3. this.width = w;
4. this.hegith = h;
5. }
6. //프로토타입 개체는 각 인스턴스들이 공유해야하는 프로퍼티나 메소드를 정의한다.
7. Rectangle.prototype.area = function(){ return this.width * this.height; }

Rectangle.prototype은 생성자 Rectangle(w, h)와 연결되며 이 생성자를 통해 생성되는 모든 객체는 프로토타입이 가진 모든 객체를 그대로 상속 받는다.

이말은 프로토타입 객체가 메서드나 상수같은 프로퍼티를 위치시키기 좋은 장소임을 의미한다. 프로토타입 객체를 사용함으로서

• 각 객체가 프로토타입의 프로퍼티를 상속받기 때문에 이들이 필요로 하는 메모리를 절약 해주며
• 프로토타입에 새로운 프로퍼티가 생성되면, 이미 생성된 객체에도 이 프로퍼티를 그대로 상속받는다

상속받은 프로퍼티의 읽기와 쓰기

모든 객체가 가지고 있는 프로토타입이 상속을 가능하게 해주는 원리가 무엇일까? 그것은,

객체 o의 프로퍼티 p를 읽는다고 한다면, o에 p라는 프로퍼티가 있는지 검사 후에 없을 경우 o.prototype에 p가 있는지 검사하는 식이다.

자바스크립트는 기본적으로 각 객체에서 프로타입의 프로퍼티를 쓰지 못하게끔 한다. 그것을 가능하게 한다면 부모클래스의 프로퍼티를 자식클래스의 객체가 바꾸어버려 결국 모든 객체의 프로퍼티를 바꿔버리게 하는 최악의 결과를 만들 수 있기 때문이다. 따라서

프로퍼티 상속은 프로퍼티를 쓸 때가 아닌 읽을 때만 일어난다.

만약 객체 o가 프로토타입으로부터 상속받은 p라는 프로퍼티에 값을 넣고자 한다면, o객체의 p프로퍼티를 새로 생성하여 거기에 값을 넣는다. 그리고선 프로토타입의 p를 상속하지 않는다. 이를 "o에 p프로퍼티가 프로토타입의 p프로퍼티를 가렸다(shadow)혹은 숨겼다(hides)라고한다."

내장형타입의 확장

사용자 정의 클래스에는 프로토타입 객체가 존재하지 않는다. 내장형(built-in)클래스에는 모두 프로토타입객체가 존재하며, 이로서 built-in클래스에 새로운 메소드를 정의할 수 있다.

1. String.prototyp.showLength = function(){
2. alert(this.length);
3. }
4. var msg = "hello";
5. msg.showLength();

이것이 바로 내장형 타입의 확장이다. 하지만 이러한 방식은 코드의 가독성을 해칠 수 있으므로, low-level의 자바스크립트 프레임 워크를 제공할 목적이 아니라면 내장형(built-in)타입에 재정을 하는 것은 삼가는 것이 좋다.

자바스크립트의 클래스 따라하기

자바스크립트는 '객체'라는 것을 제공하기는 하지만, '클래스'를 제대로 표현할 수 있는 방법을 제공하지는 않는다. 즉 다른 객체지향언어는 '클래스'를 통해서 객체지향을 지원하지만, 자바스크립트는 프로토타입을 통하여 객체지향을 가능케 한다.

자바스크립트에서는 클래스의 이름을 만들때 첫글자가 대문자로, 객체는 첫글자가 소문자로하는 것이 일반적이다.

자바의 클래스에는 네개의 기본타입이 있다.

• 인스턴스 프로퍼티 : 자바스크립트에서의 프로퍼티는 기본적으로 인스턴스 프로퍼티이다. 하지만, 객체지향적인 모양새를 유지하기 위해서는 생성자에서 프로퍼티를 생성하고 값을 할당하는 것이 좋다.

• 인스턴스 메소드 : 인스턴스메소드라고 해서 모든 객체가 이 메소드의 사본을 가지고 있다는 의미는 아니다. 자바스크립트에서의 인스턴스 메소드는 생성자의 프로토타입 객체에 정의된 함수를 의미한다. 따라서 모든 객체는 이 프로토타입에 있는 함수를 상속하여 공유한다. 인스턴스메소드에서는 호출객체나 인스턴스를 참조하기 위하여 this를 사용하는데, 이는 자바나 C++과 차이첨이 될 수 있다. 자바나 C++에서는
  return width * height;

  가 될 수 있겠지만, 자바스크립트에서는 반드시
  return this.width * this.height;
  가 되어야만 한다.  이것이 귀찮다면 다음도 가용하다.
  with(this){ return width * height;}

• 클래스 프로퍼티 : 모든 객체가 공유하기 위해서 생성자 함수의 프로퍼티로 정의하여 사용할 수 있다.
  Rectangle.UNIT = new Rectangle(1,1);
• 클래스 메소드 : Date.parse()가 그 예이다. 클래스메소드에서 사용되는 this는 특정 인스턴스나 객체를 참조하지 않으며, 생성자 함수 자체를 참조한다.(다만, 일반적으로 클래스 메소드는 this를 참조하지 않는다). 자바스크립트에서 클래스 메소드를 정의하기 위해서는 생성자 함수의 프로퍼티로 연결시키면 된다.

private 멤버

자바스크립트에서 encapsulation은 어떻게 할까?  자바스크립트에서는 closure를 통해서 이를 흉내낼 수 있다.

http://www.crockford.com/javascript/private.html 참고.

1. function Rectangle(w, h){
2. //생성자의 프로퍼티에 w,h를 대입하는 것이 아니라, w,h에 접근할 수 있는 메소드를 정의한다.
3. this.getWidth = function(){ return w;}
4. this.getHeight = functino(){ return h;}
5. }
6. Rectangle.prototype.area = function(){
7. return this.getWidth() * this.getHeight();
8. }

공통적인 객체 메소드

여기에서는 자바스크립트 클래스를 정의할때 유념하고 정의해야할 메소드에 대해 다룬다.

 toString()

하나의 클래스를 정의하면 그 안에는 반드시 인스턴스 메소드로서 toString()을 정의해야만 한다. 문자열을 객체로 바꾸는 parse()메소드를 정의하는 것도 생각해볼 수 있다.

1. Rectangle.prototype.toString() = function(){
2. return "width:" + this.getWidth() + ",height:" + this.getHeight();
3. }

valueOf()

기본타입에 존재하는 클래스를 정의할 경우에만 정의하면 된다. 여기서 기본타입은 자바에서의 기본 변수 타입을 말한다. int, float, long, double, char, boolean 등이 그것이다.

비교 메소드

자바스크립트에서의 동등메소드는 서로 동일한 객체를 참조하고 있는지를 검사한다. 자바에서는 객체가 (그 안의 컨텐츠가) 동일한지 검사하기 위하여 메소드를 정의하는데(equals) 자바스크립트에서도 객체에서 equals 함수를 정의하는 것이 좋다. 물론 equals함수는 자신의 객체(this) 외의 객체를 인자로 받아서 비교를 하는데, 이 비교는 개발자에게 전적으로 달려있다. 객체 a와 b 각각에 존재하는 프로퍼티 p의 값이 10 이하면 동일한 것으로 간주하고 싶다고 한다면 그렇게 하면 되는 것이다. 클래스에서 비교 연산자 메소드를 정의하고 싶다면 자바에서처럼 compareTo()를 정의하면 된다.

1. a < b | a.compareTo(b) < 0
2. a <= b | a.compareTo(b) <= 0
3. a > b | a.compareTo(b) > 0
4. a >= b | a.compareTo(b) >= 0
5. a == b | a.compareTo(b) == 0
6. a != b | a.compareTo(b) != 0

compareTo메소드를 정의해 놓으면 이 클래스의 객체로 이루어진 배열을 정렬하고자 할때 sort매소드의 closure안에서 유용하게 사용할 수 있다.

1. ary.sort(function(a,b){ a.compareTo(b); });
2. // 간단하게는 Rectangle의 메소드 파라미터를 넘겨주는 식으로도 가능하다.
3. ary.sort(Rectangle.compare);

경우에 따라서는 equals()메소드와 compareTo()메소드의 결과가 다르게 나타날 수도 있는데, 그럴 경우 찾기 힘든 버그를 발생시킬 수가 있다. 따라서 equals()메소드와 compareTo()메소드가 동일한 의미를 가지도록 부여하는 것이 좋을 것이다.

슈퍼클래스 와 서브클래스

자바스크립트에서도 프로토타입 객체를 이용하여 자바나 C++과 같이 슈퍼클래스와 서브클래스 구조를 흉내낼 수 있다.

자바스크립트에서 최상위 클래스는 Object이다. 객체는 생성자 함수의 프로토타입 객체에 있는 프로퍼티들을 상속받는 다는 것을 기억해보자. 그런데, 여기서 집고 넘어가야 할 것이 있다.

프로토타입도 객체로서 Object() 생성자를 사용하여 만들어진다. 이말인 즉, 프로토타입 객체 또한 Object.prototype 프로퍼티들을 상속받는다. 그렇다면 Rectangle클래스의 객체 r에서 프로퍼티를 찾고자 할때, 그 순서는 다음과 같이 이루어진다.

1. 객체 r의 프로퍼티에서 찾는다
2. Rectangle.prototype 객체의 프로퍼티에서 찾는다.
3. Object.prototype 객체의 프로퍼티에서 찾는다.

만약 자신이 정의한 클래스의 서브클래스를 만들고 싶다면? 생성자 체이닝(chaining)을 사용 할 수 있다.

1. function Rectangle(w,h){

2. this.width = w;

   this.height=h;

3. }
4.  
5. function SubRectangle(x,y,w,h){
6. //width와 height를 초기화 할 수 있도록 새로운 객체의 수퍼 클래스 생성자를 호출, 초기화될 객체의 메소드로 생성자를 호출하도록 call메소드를 하용
7. // 이 방식이 바로 생성자 체이닝(chaning)이다.
8. Rectangle.call(this, x, y);
9. this.x = x;
10. this.y = y;
11. }
12. //상속구조를 만들기 위하여 명시적으로 SubRectangle의 prototype객체를 Rectangle클래스의 인스턴스로 연결시킨다.
13. SubRectangle.prototype = new Rectangle();
14. 
    //SubRectangle.prototype은 상속을 위하여 Rectangle()로 설정하였지만 실제 width와 height는 Rectangle에 있는 것을 쓰지 않을 것이므로 다음과 같이 프로퍼티를 제//거해준다.
15. delete SubRectangle.prototype.width;
16. delete SubRectangle.prototype.height;
17. 
    //현재 SubRectangle.prototype.constructor는 Rectangle을 참조하고 있기 때문에, 명시적으로 수정해주어야 한다.
18. SubRectangle.prototype.constructor = SubRectangle;

생성자 체이닝(chaining)

자바스크립트의 서브클래스에서 수퍼클래스의 생성자를 명시적으로 호출해주는 것을 생성자 체이닝이라고 한다. 위에서의 방법이 다소 번거롭다면 다음과 같이 가독성을 높일 수도 있다.

1. SubRectangle.prototype.superclass = Rectangle;
2. function SubRectangle(x,y,w,h){
3. this.superclass(w,h);
4. this.x = x;
5. this.y = y;
6. }

이렇게 함으로서 번거롭게 call을 호출하는 것을 피할 수 있다.

call 메소드에 대해서 간단히 집고 넘어가면, 특정 객체에서 일회용 메소드를 쓰는 것이라고 생각하면 쉽다.

1. f.call(o,1,2)
2. //위의 코드는 다음과 같이 생각하면 된다.
3. o.temp = f;
4. o.temp(1,2);
5. delete o.temp;

재정의된 메소드 호출하기

보통은 수퍼클래스에 있는 메소드를 하위클래스에서 재정의하지만, 때로는 재정의가 아닌 "확장"을 할 때가 있다. 이럴 경우 수퍼클래스의 메소드를 호출할 수 있어야 한다.

1. Rectangle.prototype.toString = function(){
2. return "[" + this.width + "," + this.height + "]";
3. }
4. SubRectangle.prototype.toString = function(){
5. // 상위클래스에 체이닝
6. return "[" + this.x+ "," + this.y+ "]" + Rectangle.prototype.toString.apply(this);
7. }

만약 Rectangle.prototype.superclass 를 정의 하였다면 다음과 같이 할 수 있다. 이렇게 하는 것이 가독성에 좋을 것이다.

1. SubRectangle.prototype.toString = function(){
2. return "[" + this.x+ "," + this.y+ "]" + this.superclass.prototype.toString.apply(this);
3. }

상속 없이 확장하기

자바스크립트는 함수들을 복사하거나 빌려(borrow)갈 수 있기때문에, 위에서 설명한 방법 말고도 다른 방식으로도 상속구조를 구현할 수 있다.

즉 수퍼클래스의 모든 메소드를 서브클래스의  프로토타입 객체에 복사하는 것으로 가능하다.

1. function borrowMethods(borrowFrom, addTo){
2. var from = borrowFrom.prototype;
3. var to = addTo.prototype;
4. for(m in from){
5. if(typeof from[m] != 'function') continue; //함수가 아닌 것은 무시
6. to[m] = from[m];
7. }
8. }

보통 자체적으로는 특정 작업을 하지는 않지만, 메소드들을 다른 클래스나 메소드에 포함시켜서 유용하게 사용되어질 수 있는데, 이런 목적으로 만들어진 클래스를 믹스인(mixin)클래스 혹은 믹스인이라고 한다.

1. function genericToString(){}
2. GenericToString.prototype.toString = function(){
3. var props = [];
4. for(var name in this){
5. if(!this.hasOwnProperty(name)) continue;
6. var value = this[name];
7. var s = name + ':';
8. switch( typeof value){
9. case 'function':
10. s += 'function';
11. break;
12. case 'object':
13. if(value instanceof Array) s += 'array';
14. else s += value.toString();
15. break;
16. default:
17. s+=String(value);
18. break;
19. }
20. props.push(s);
21. }
22. return "{" + props.join(", ") + "}";
23. }

위의 믹스인 클래스는 다음과 같이 사용될 수 있다.

1. function Rectangle(x,y,w,h){
2. this.x = x;
3. this.y = y;

4. this.w = w;

   this.h = h;

5. }
6. Rectangle.prototype.area = function(){ returne this.width * this.hegith; }
7.  
8. borrowMethods(GenericEquals, Rectangle);

생성자를 포함한 메소드를 빌려올 수도 있다.

1. function colored(c){ this.color = c;}
2. colored.prototype.getColor = function(){return this.c}
   
   function ColoredRectangle(x,y,w,h,c){
3. this.superclass(x,y,w,h);
4. Colored.call(this, c);
5. }
6. ColoredRectangle.prototype = new Rectangle();
7. ColoredRectangle.prototype.constructor = ColoredRectangle;
8. ColoredRectangle.prototype.superclass = Rectangle;
9. 
   borrowMethods(Colored, ColoredRectangle);

객체 타입 판단하기

가장 대표적으로 typeof를 사용할 수 있다. 혼란스러울 수 있는 부분이 있는데, typeof undefined => 'undefined'이지만 typeof null => 'object'이다. 그리고 배열은 'object', 함수는 객체이긴 하지만 'function'으로 정의되어 있다.

instanceof와 constructor

어떤 값이 기본 타입이 아닌 객체라고 예측할 수 있다면 instanceof를 통해서 타입을 검사할 수 있다.

1. x instanceof Array

만약 f가 함수라고 한다면 다음은 모두 참이다

1. typeof f == 'function
2. f instanceof Function
3. f intanceof Object

만약 명확하게 어느 클래스에 속해 있는지 알고 싶다면? instanceof를 사용한다면 해당 클래스의 수퍼클래스 모두에 대해서 true를 반환한다. 이럴 경우에는 constructor 프로퍼티를 검사하여 해결할 수 잇다.

1. var d = new Date();
2. d instanceof Object //true
3. d.constructor == Object //false

오티 타이핑

"어떤 클래스가 정의한 모든 메서드를 구현하면, 그것은 그 클래스의 인스터인 것으로 간주한다."로 설명될 수 있다.

학술용어로 동질이형성(allomorphism)이라고 한다. 오리 타이핑은 다른 클래스에서 메소드를 빌려오는 클래스들 연결할 때 유용하다.

이 글은 스프링노트에서 작성되었습니다.

opensocial conference 2008에 다녀왔습니다.

웹에서의 보기 드물게 큰 이슈가 되었던 Web2.0이라는 키워드 다음으로 이제는 오픈소셜이 화두가 되고 있는 것 같습니다. 최근 0.7에서 0.8로 좀 더 낳아진 오픈소셜 스팩을 지켜보면서, 그리고 그 표준을 따르고자 하는 myspace, hi5, orkut, 그리고 아파치재단 오픈소셜 구현제 오픈소스 프로젝트인 신딕(shindig)을 보면서 느끼고 생각해왔던 것들을 이번 컨퍼런스에 참여하면서 어느정도 정리가 된 것 같습니다. 지극히 개인적인 소견도 들어간 가벼운 후기형식으로 메모한 것과 함께 생각나는대로 적어볼까 합니다.^^

키노트

키노트는  안철수연구소의 안철수 의장의 "실리콘밸리의 경쟁력과 우리가 해야 할 일"로 이루어 졌습니다.

안 철수님을 실제로는 처음 보는지라 마치 연예인을 본 듯한 느낌이 들었습니다.^^;  CLO(Chief Learning Officer)라는 약간 생소한 용어를 설명해주셨습니다. 기업에서 조직원들이 필요한 역량이 무엇인지를 정확히 파악하고 그에따른 교육에 전반사항을 담당하는 치프정도로 이해되었습니다. 이후에 말한 국내 인력의 전문성 결여와 연결될 수도 있는 이야기 인듯 합니다. "왜 국내 벤처는 성공하기 힘든가"는 명제로부터 자연스럽게 키노트 주제인 "성공한 벤처를 만들어내는 실리콘밸리의 경쟁력은 무엇인가?"로 옮겨 설명을 해주었습니다.

성공한 벤처를 만들어내는 실리콘밸리의 경쟁력은 무엇인가?

1. 전문성 : CEO가 좋은 아이디어만 있다면 어렵지 않게 전문성 있는 좋은 팀 구성이 가능. 즉, 전문인력을 구하기 좋은 환경
2. 인프라 : 대학의 교육 시스템, 능동투자(투자 후 경영에도 개입한다. 여기서 개입은 간섭이 아니며 기업의 신용도,사람,물적자원 등을 적극적으로 지원해 준다.), 구조화가 잘 된 아웃소싱업체, 정부 정책적 지원.
3. 대기업과 중소기업간의 거래 관행 : 미국 대기업은 중소기업(벤처)로부터 혁신적인 아이디어를 얻어내고,  M&A를 통한 흡수하는 등의 매우 프래티컬(practical)한 상생구조를 가지고 있음.

그렇다면 한국은?

1. 전문성 : 전문성이 떨어진다. 교육이 문제이다. 예를 들어 책만으로는 절대 아키텍트가 될 수 없다. 아키텍트는 경험과 선배로부터 배울 수 있는 것이다. 즉, 닫힌 교육이 문제.
2. 인프라 : 대학에서 전문인력 양성이 되지 않고 있다. 금융권에서 대출이 쉽지 않음, 중소기업(벤처)로부터 혁신적인 아이디어를 얻기가 쉽지 않음. 능동투자가 부재. 정부의 정책적 지원 역시 열악합.
3. 대기업과 중소기업간의 거래 관행 : 상생관계가 아닌 약육강식 구조.

이 러한 현실에서 한국의 중소기업이 성공하기 위한 방법으로 stockdail paradox 를 빌어 도출하였습니다. 즉 "살아남은 사람들은 냉철한 이성과 함께 미래에 대한 희망을 가진다."라는 결론이었습니다. 이부분이 상당히 인상깊었습니다. 컨퍼런스 종료 후에도 현재 오픈소셜의 현실과 희망에 대해 연결하여 생각할 수 있어서 좋았습니다.

세션1

" 소셜 웹과 개방화"라는 주제로 SK커뮤니케이션즈의 황현수님의 발표가 이어졌습니다. "open"이란 무엇인가라는 부분에서 openAPI, openID, open social로 나누어 설명해준 부분이 인상깊었습니다만, 프레젠테이션 자료에서 OpenID부분에 미투데이가 적혀있어서 잠시 혼란스러웠더랬습니다.^^ 미투데이는 openID 컨수머 서비스입니다. 제 생각에는 그 자리에 IDtail과 함께 myID.net이 들어가는게 자연스럽지 않았을까 생각합니다. 이어서 "open"의 국내 현황에 대해 들을 수 있었습니다.

• 네이버, 다음 등 openAPI 조회/이용률 저조
• traffic 양을 제어하기 위한 한계치 제한
• 프로그래머 부족(?)

현실적인 이야기이긴 하지만, 저는 시각을 약간 바꾸어 이렇게 생각해보기도 하였습니다.

네 이버, 다음 등 openAPI 조회/이용률 저조 -> 사실이긴 합니다만, 좀 더 개발자의 피드백을 받아서라도 서비스에서 정의하는 국한적인 openAPI가 아니라 진정으로 오픈된 openAPI를 제공한다면 어떨까요? 많은 개발자분들이 "막상 openAPI를 사용하여 무언가를 개발하려면 쓸게 없다"라고 말하는 것은 어떤 문제가 있는 걸까요.. openAPI를 선심쓴다는 느낌으로, 혹은 web2.0의 트랜드에 맞추어가기 위한 형식적인 활동의 일환이 되어버린다면, 매우 아쉬운 부분입니다. openAPI도 서비스라고 생각합니다. 그런면에서 매시업캠프를 통해 피드백으로 받고 서비스들의 openAPI들이 더 풍부해졌으면 하는 바람입니다.

traffic 양을 제어하기 위한 한계치 제한 -> 한계치를 제한하는 것은 악의를 가진 개발자들의 공격을 막기 위한 일차적인 방어막 역할이 되어야하지, 서비스 개발하기 위한 장애물 되어서는 안된다고 생각합니다. 이 부분은 긍정적인 매시업서비스에 대해서 유연한 정책정립이 가능하지 않을까 생각합니다.

소셜웹의 히스토리, SNS와 광고 등 재미있는 이야기가 많이 이루어졌었습니다. 일촌방문:비일촌방문 비율이 6:4라는 사실에 놀랐고, 남성이 여성보다 비일촌 방문 비율이 15% 더 높더라는 어찌보면 당연하고도 잼있는 통계를 들을 수 있었습니다.^^ 미니홈피 다이어리가 왜 떳는가란 이야기로 세션이 마무리되었습니다. 다음에는 사이월드가 "이런 이런것들을 'open'합니다!" 라는 반가운 소식으로 세션이 마쳐지기를 소망해 봅니다. 보통 국내 인터넷 서비스라고 한다면, 네이버, 다음, 그리고 사이월드를 말합니다. 세션에서 강조했던 'open'의 가치를 실현시키기 위해서 사이월드도 플랫폼을 오픈하고, 매시업캠프와 같은 행사를 마련한다면 웹이 더 환해지지 않을까 합니다.

세션2

이어서 야후코리아 정진호님의 "오픈 플랫폼 트랜드" 세션이 이어졌습니다.

"open platform이란 무엇인가?"라는 명제에 대해서 "모든 플랫폼 eco-system에는 개발자(재미,명성,수익 위해), 광고주(금전적이익 ), 사용자(트래픽, 경험, 가치 위해) 로 이루어져 있다."라는 부분이 꽤 명쾌하게 느껴졌습니다. 그리고 오픈플랫폼은 표준 API를 제공하는 것만이 전부가 아니며 표준, 개방 , 참여 필요하는 내용을 들었을 때는 회초리를 맞는 느낌이 들기도 하였습니다. 오픈플랫폼을 지향하고자 한다면 이 말은 가슴에 꼭 새겨두어야 하지 않을까 합니다.

세션3

안철수 연구소의 송교석님의 오픈소셜 기반의 플랫폼 전략에 대한 세션이 이어졌습니다. 인상 깊었던 오픈소셜의 가치를 정리해봅니다.

오픈소셜의 가치
- 컨테이너로서의 가치
   - 기능 다양성 확보 : 다양한 애플리케이션은 다양한 기능이 된다.  
   - 서비스 활성화 : 하나의 킬러 app이 나왔을 때 컨테이너가 얻을 수 있는 것. 사용증가
   - 열린 웹에의 기여 : api활성에 기여
- 개발자/업체로서의 가치
   - 2억 이상의 user base 확보 : 규격(표준)에 맞게 만들기만 하면 오픈소셜 기반 서비스 어디에나 가능
   - 수익 창출 : 광고를 통한(canvas모드에서만) 수익 창출.
   - 새로운 Biz model 창출 : rockyou!의 예. 1M이상의 유저 가지는 7개 이상의 애플리케이션 확보
- 사용자로서의 가치
   - 다양한 리치 애플리케이션
   - 친구와 함께하는 게임의 재미  
   - 친구에 대한 새로운 발견
   - 다양한 커뮤니케이션 채널

물론 현재로서는 사실이 아닌 부분도 있습니다. 뒤 세션에서 3CIM의 이상석님이 '현실'을 폭로(?) 해주셨습니다만, 저 역시 그 부분을 피부로 느끼기도 하였습니다.

이부분이죠.

"규격(표준)에 맞게 만들기만 하면 오픈소셜 기반 서비스 어디에나 가능" 즉, Write once, Run everywhere.

모든 컨테이너 서비스들이 표준을 준수한다면 당연히 맞는 말입니다만, 현실적으로 그렇지 않았습니다. 다음이 약 5일 전에 제가 적어 둔 것으로 오픈소셜 스팩 0.7에 있는 몇몇 api를 각 컨테이너에서 테스트해본 결과입니다.

• requestPermission
  • shindig : notImplemented
  • orkut : 사용 가능
  • hi5 :  응답 자체가 없음
  • myspace : 응답 자체가 없음
• requestSendMessage
  • shindig : notImplemented
  • orkut : 사용 가능
  • hi5 : notImplemented
  • myspace : 응답 자체가 없음
• requestShareApp
  • shindig : notImplemented
  • orkut : notImplemented
  • hi5 :  응답 자체가 없음
  • myspace : notImplemented

이상석님의 말대로, "Write once, Run everywhere................. is not exactly true"입니다.^^;; "Write once, Run everywhere"이라고 하기엔 아직 많이 민망한 단계인 것 같습니다만, 중요한 것은 계속 개선되고 있다는 점입니다!. 얼마 전에 0.8스팩이 나왔습니다. 모든 컨테이너들이 스팩을 완벽하게 지원하는 날이 오는 것은 쉽지 않겠지만, 확실한 것은, 각 컨테이너에서 돌아가게 하는 오픈소셜 애플리케이션을 개발하기 위한 리소스가 그만큼의 유저베이스를 확보하기 위해 쓰이는 리소스보다 더 적을 것이라는 점입니다. ^^

세션 4

3CIM Korea의 이상석님의 "오픈소셜 기반 어플리케이션의 가치(Third-Party)" 세션이 이어졌습니다. 이야기가 매우 현실적이라는 점에서 개인적으로는 가장 재미있기도 했고, 오픈소셜 컨터이터 프로바이더들이 귀 기울여야할 세션이 아니었나 생각되었습니다. 가장 화기애애한 세션이기도 했고요. 오픈소셜 프로바이더가 아닌 그 안에서 개발을 해 나가는 third-party의 입장에서 오픈소셜 애플리케이션의 가치와 현재 오픈소셜의 현실, 그리고 소셜애플리케이션의 수익모델등 매우 흥미로운 이야기가 전해졌습니다. 인상깊었던 말을 적어봅니다.  

"그들(프로바이더들)이 open한다는 것은 그들이 정의하는 제한적인 데이타이지 진정한 open아니다."

"write once, run everywhere (is not exactly true)"

새겨들어야 할 말들입니다.

이 세션을 통해서 저도 틈나는대로 제대로 된 오픈소셜애플리케이션을 개발해봐야겠다는(사실 계획하고 조금씩 하고 있습니다만) 뽐뿌질을 많이 받았습니다. facebook이 플랫폼을 오픈한 이후로 15.4M의 UV가 third-party 애플리케이션을 사용하였고, third-party애플리케이션 UV가 facebook전체 UV의 평균 51%를 차지 한다는 통계치가 상당히 놀라웠습니다. 이러한 놀라움을 국내 오픈소셜 프로바이더들이 느끼게 될 날을 고대해봅니다.^^

세션5

태터툴즈 프로젝트 메인개발자로 잘 알려지시기도 한 안철수 연구소 웹2.0 서비스 플랫폼팀의 최호짐님의 "오픈소셜 기반의 어플리케이션 개발과 적용" 세션이 마지막으로 이어졌습니다. opensocial spec에 있던 익숙한 내용들이라 재미있게 들을 수 있었습니다. 오픈소셜 컨테이너로서 고심해야할 부분에 대해서도 들을 수 있었습니다. 컨테이너에서 가젯이 iframe내의 javascript로 돌아가는 만큼 Same Origin Policy문제, 악의적인 코드들, 애플리케이션에서의 정보 사용 scope 정의등에 대해서 들을 수 있었습니다. 그러한 점들이 표준 스팩에 명확하게 명시가 되어있지 않다는 점이 아쉬웠습니다. 어느정도 일반적인 정책은 오픈소셜 스팩에서 하루 빨리 정해졌으면 좋겠습니다.

오픈소셜에서 외부->내부, 내부->외부로의 원격데이터에 대한 접근 인증방식을 OAuth로 하기로 하였습니다만, access_token의 주체에 대해서도 owner로 '일단' 지정해 놓았을 뿐, 명확한 제시와 예제는 없습니다. 물론 계속 이슈가 되고 제안되고 있으니 지켜보아야 할 것 같습니다^^;

그래서 저의 작은 결론은, stockdail paradox에서 이야기한 냉철한 현실인식과 희망을 가져본다면,

"오픈소셜이 본래의 가치를 발현하기 위해서는 아직 갈길이 멀지만, 확실한 것은 그 길이 점점 좁혀지고 있다는 것입니다 "

정도겠습니다.

간만에 너무 재미있고 유익한 컨퍼런스를 다녀와서 기뻤습니다.

OAuth그룹에서의 최근 근황을 적어봅니다.

이슈 1.
Yahoo가 주최하는 OAuth Summit 2008이 6월 26일 Santa Clara, CA에서 열릴 예정이라고 합니다.

이번 행사에서는 OAuth 프로토토콜, 확장성, OAuth 구현을 했던 경험 공유, 그리고 개발자들 간의 교류를 목적으로 합니다. 적어도 OAuth 스팩에 대한 이해를 가지고 참가해야 한다고 합니다.^^

이슈 2.
OAuth Core 1.0 Final이 2007년 12월 4일에 공표된 이후로, 커뮤니티에는 많은 피드백과 구현과정에서 추가적으로 필요한 제안들이 많이 올라왔었습니다. 그 이유인즉, 실제 OAuth Core 1.0에서 제시하는 바로는 실제 서비스 프로바이더와 컨수머간에 생길수 있는 여러가지고 요구사항을 충분히 수렴하지는 못했던 것이라고 생각합니다. 실제로 OAuth 컨수머와 프로바이더를 구현해보면서 앞으로 OAuth Core의 확장이 필요하다고 생각했었는데, 최근 OAuth그룹에서  Eran Hammer - Lahav가 제안한 OAuth Core 1.1 을 한번 정리해볼까 합니다.

- '리소스'와 '접근 요청', 그리고 '접근'이 가장 일반적인 질문이라고 할 수 있다. Core 1.0에는 각각의 프로바이더들이 개발해나가고자 하는 것을 배제하고 명세되어 있다.
- 명세는 다른 언어로 번역되야 하고, 더 많은 예제가 제공되어야 하며, Appendix A에 있는 전체 예제를 문서의 제일 위로 위치시켜서 가독성을 향상시킬 수 있겠다. 일반적으로 튜토리얼에서 시작하여 레퍼런스로 옮겨가기 때문.
- Core 1.0은 크리티컬한 상호운영에 대한 확실한 에러처리에 대해 부족하다.
- 확장성과 보안 부분에서 대규모 프로바이더에게 더 좋은 지원을 하기 위하여 명세를 수정해야 한다.

추가적으로, 다음과 같은 기능(feature)들이 요구되었다.
- HTTP Body signature : 페이로드(payload)데이터를 sign하는 방법 제공
- 언어 지원 : 메인 스팩에 extension을 포함.
- 2개의 플로우 : 어떻게 2개의 시나리오가 동일한 시그네이쳐 메소드를 사용하여 동작해야만 하는지에 대해 Core에 명확한 정의를 추가.(?)

다른 작은 제안들로는,
- RSA와, token secret을 제외하는 두가지 메소드들간의 보안상의 차이에 대해서 명확하게 해야함
- consumer 에 명시되어야 하는 nonce와 timestamp언어뿐 아니라 token에 명시되어야 하는 nonce와 timestamp언어 대해서도 명확히 해야 함.

Core, Extensions  어디에 포함시켜야 하는가?,
Core 1.0을 개발하면서 범위에 대해서, 그리고 그것이 core 프로토콜에 포함되어야 하는 것인지, extension에 속해야 하는 것인지에 대하여 긴 토론을 하였다. 위에 있는 모든 것이 core 명세에 포함되어야 하는 것은 아니지만, 우리가 작업한 것들이 가능한한 문서에 포함시켜야 하는 많은 이유가 있다. 현실적으로, 더 중요한 사항은 이해를 시켜주고 지원을 해주는 것이다.

Core 1.1의 범위 제안
- 에러 리포팅 : error code(URI 형식)와 사람이 읽을 수 있는 텍스트, 이 두가지 파라미터를 추가해야 한다. 일반적인 프로토콜 에러에 대한 코드의 집합을 정의해야 한다. 확장하기 쉽도록 스트링이나 숫자를 쓰는것 보다는 에러코드를 위하여 URI를 사용하는 것이 좋겠다.
- 2개의 플로우 : consumer key와 secret을 사용할때만, token과 token secret을 비워두는 경우, OAuth signature string을 어떻게 명시해야 하는지에 대한 정의
- HTTP Body signature : body의 시그내처를 지원할 새로운 파라미터 추가.(non-multi-part-bodies에 관점에 제한하여). 파라미터는 일반적인 플로우를 사용하여 인증을 받아냄.
- 언어 지원 : 스팩에 언어 제안 포함 
- RSA 보안과 nonce limitation에 대한 언어 수정
- 위에서 제안한 것을 기반으로 한 토큰 어트리뷰트에 대한 뼈대를 추가. 기본적으로 키/밸류 한쌍의 파라미터. 서비스프로바이더가 명세할 수 있는 것과 최소한의 키들의 집합 정의

references
- http://groups.google.com/group/oauth/t/808e4a98193de671?hl=en
- http://groups.google.com/group/oauth/t/b4d71abb0ac81e60?hl=en

꽤 오래 전부터 바이크를 사고싶어 했었지만, 여러 환경적인 요인들로 미루어져서
약 2주 전에나 줌머를 구입하게 되었습니다.
고유가시대에 휘발유 1L 로 40km를 가는 줌머는 날씨도 괜찮은 요즘 꽤나 매력적인 모델입니다. 물론  개인적인 취향이긴 합니다.^^
제 줌머는 07년식 화이트입니다.




줌머에 대한 간단한 소개를 하자면,
일본 혼다에서 2001년 6월에 첫 출시되었으며, 50cc 스쿠터입니다. 특이한 점이 몇가지 있습니다만, 가장 중요한 엔진에 대해서 적어봅니다.(아래 내용은 네이버의 줌머홀릭 카페에 있는 자료입니다.). 보통 스쿠터는 2행정인데 비해 줌머는 4행정입니다.
왼쪽 이미지는 4행정 사이클 엔진의 작동 CG입니다.
중앙에 있는 것은 점화플러그입니다. 가스레인지에서 점화를 할때 불꽃을 만들어내는 것과 같은 역할을 해줍니다. 엔진에 시동을 걸때 여기서 스파크가 일어나 시동이 걸리는 것입니다.

왼쪽에 있는 것은 연료분사노즐입니다. 08년식부터는 이 부분이 카브레이터 방식에서 인젝션분사방식으로  기존의 카브레이터방식과는 달리 컴퓨터(IC)와 센서로 엔진상태를 측정해 적당한 혼합기를 제어해 연료를 분사하는 방식으로 연비와 가점화 온도의 폭이 더 넓다는 장점이 있습니다. 제 줌머는 07년식이라 카브레이터방식이긴 합니다만, 혼다의 카브레이터방식의 기술력은 경지에 닿아 있는 상태라 사실상 인젝션 방식과 연비면에서는 큰 차이는 없다고 합니다. 다만 가점화 온도에서 차이가 나서 인젝션방식은 추운 겨울에도 시동이 잘 걸린다고 합니다. 가운데에서 상하운동을 하고 있는 것이 엔진의 핵심이라고도 할 수 있는 피스톤입니다. 분사된 휘발유에 점화가 되어 그 폭발력으로 바이크가 움직이죠. 이 실린더의 직경을 넓이는 작업을 '보링'이라고 하는데, 이로서 더 많은 휘발유를 모아서 더 큰 출력을 낼 수 있다고 합니다. 줌머는 아쉽게도 일체형 실린더라 가공이 불가능하다 합니다. 실린더 양쪽에서 상하 운동을 하는 것이 밸브인데, 좌측이 흡기, 우측이 배기 밸브입니다. 심장의 좌심실, 우심실이 생각나네요.ㅋ 좌측에서 필터링 된 공기를 가져오고, 연료 연소후 가스를 배기밸브가 배출합니다. 생각보다 복잡하지 않네요~

줌머는 다른 스쿠터들보다 튜닝파츠가 유난히도 많아서, 정말 다양한 모양새의 줌머들이 존재합니다. 모두 멋집니다. 감상해 보세요~

제 줌머 튜닝 내역은
-  PIAA혼 : 아무래도 도로를 달리다보면 줌머 순정 혼은 차소리에 묻히기 쉽니다. 안전을 위함입니다.
-  볼케이노스피커 : 이부분은 사실 별로 쓸데가 없어서 제거할까 생각중입니다.
-  옆면에 LED : 야간도로 주행에 전후방 빛으로는 부족할때가 있습니다. 이 역시 안전을 위함입니다.
-  텐덤발판 : 텐덤은 뒤에 사람을 태우는 것을 말하는데, 사실 줌머는 1인 승차용으로 나온 것이라 텐덤은 비추하고 있습니다. 혼자 탈 때 텐덤발판에 발을 올려놓는게 더 편하더군요.
-  할로겐라이트 : 사실 멋이긴 합니다만, 야간주행시 안전에 도움이 더 됩니다.
-  사각미러 : 줌머랑은 사각미러가 제일 잘 어울리는 것 같습니다.
-  튤레패드 : 텐덤을 할때 뒷사람을 배려하기 위한 것이 본래 용도이기는 합니다만, 사실 데코입니다.^^;
-  라이트망 : 돌이나 기타 물질로 라이트가 깨지는 것을 막아줍니다. 물론 멋도 있구요.
-  휠테잎 : 안전을 위합입니다. 반사지라 야간주행시 빛이 납니다.

어제는 집에 있는 공구장비 들고 마당에서 완전 분해(?)를 해보려다가 실패를 했네요. 정비 공부를 좀 해볼까 합니다.

뭐니뭐니 해도 가장 중요한 것은 "안전운전"입니다!~

기름값도 오르고, 환경보호차원에서라도 줌머 추천합니다.

References
많은 내용을 네이버의 줌머홀릭에서 참고하였습니다. 체계적으로 정비방식이 정리되어있지는 않습니다만, 꽤 많은 고수 분들의 노하우가 흩어져 있습니다.
- 네이버 줌머홀릭
- 다음 I Love Zoomer

SOA 자바 웹서비스로 통하는 서비스 지향 아키텍처 책이 나왔습니다.^-^/




짝짝짝~!

지난 OAuth 포스팅에서 공유하였던 OAuth 컨수머 루비 예제 코드는 루비OAuth 라이브러리 0.0.1을 사용했기 때무에 문제도 많아고 코드도 지저분 했었습니다.

  이 컨수머를 더미로 사용하면서 문제가 너무 많은 듯 한 나머지 현재 OAuth 루비 라이브러리 최신버전인 0.2.2를 사용한 컨수머 애플리케이션코드를 공유합니다.

기본적으로 인증 센터는 APICenter로 되어 있으며 openid(MyID)기반의 메시징 서비스인 Whisper의 OpenAPI를 사용하는 예제입니다. (Whisper에 가입이 되어 있다는 전제 하에 동작이 되도록 하였습니다.)

조금이라도 도웁이 되었으면 합니다.





참고 URL
- http://stakeventures.com/articles/2008/02/23/developing-oauth-clients-in-ruby
- http://oauth.rubyforge.org/

대학생활의 2년을 쏟아 부었었던 '춤(street dance)'이라는 것.
지금 생각해도 전혀 시간낭비라고 생각되지 않는다.
내가 나를 깨우치게 해준 그 것. 열정이 무엇이지 알게 해준 그 것.
지금의 나를 있게 해준 그 것.

아무리 슬픈 영화를 봐도 눈물 한번 글썽여본적 없지만, 열정만으로 자신을 채찍질 해온
언더그라운드 댄서들과 비트와의 향연은 극도의 감동과 함께 나의 눈에
눈물을 글썽이게 했었다. 지금도 다를게 없다...

지금은 지금 내가 하는 일에 빠져있듯이 그 때는 그 것에 빠져있었다.

클럽에서 밤새도록, 땀이 온 몸을 적시도록 이름도 모르는 이들과 함께
춤을 추기도 했었고, 공연이란 공연은 모두 찾아다니면서 관람한 적이 있었다.

혹자들은 춤은 젊었을적 한 때의 객기일 뿐이라고 한다. 내 주위에도 그 '객기'만을
부리다가 조용히 사라지는 친구들이 많았으며 지금 많은 후배들도 그 객기를 배우고 떠난다.
하지만, 정말 젊은 피를 모두 받치는 이들도 있다. 이 사회에서 열정만을 따라가는 이들이 정말 용기있는 자들이라고 생각했었다.

절제된 곡선 발레, 파도치는 선율과 스탭 탱고, 곡선의 미학 한국무용..
모두 존중한다.
춤이라는 것에는 '격'이라는 것이 없다. 비싼 옷, 비싼 신발, 비싼 관람료... 이런 것들을 보고
사람들은 '격'이 놓은 춤이라 생각한다. 춤에는 그런 것이 없다고 배웠다...
단지,
몸짓, 음악, 혼이 있을뿐이라고 했다...

이런말들을 할만큼 잘 추지는 못하지만, '춤을 즐긴다는 것' 은 잘 안다고 자신한다.


그래서 말인데... 운동이란 핑계로,,, 춤 다시 시작할까 고민중이다..ㅡ,.ㅡ;;
땀은 흘리고 싶은데... 헬스는 지루하고... 주말반이라도 알아봐야겠다. 같이 다닐 사람 없나 물색해봐야지...

안녕하세요. 오픈마루 오픈플랫폼팀의 정상일(humbroll)입니다.

현재 웹 서비스들의 사용자 데이터 흐름이 서비스중심에서 사용자중심으로 움직이려는 모습을 보이고 있으며, 이는 매우 고무적인 현상이라고 생각합니다.

이를 위해서는 여러 서비스들에 흩어져 있는 사용자의 중요한 데이터들을 주고 받을 수 있는 그 무언가가 필요합니다. 현재 그 것을 위해 각 서비스 벤더들은 나름의 인증방식을 제공하고 있지만, 각 서비스마다 정의하는 바가 조금씩 다르고, 이에 따라 개발이 어려운 것이 현실입니다. '표준'의 부재가 가장 큰 문제이죠. 이를 해결하기 위하여 서비스와 서비스간의 사용자의 데이터 통신을 위한 인증의 표준화를 목적으로 OAuth(Open protocol Authorization)가 제기되었습니다.

차후 OAuth의 공식 한국어 페이지를 운영할 계획입니다만,

(현재로서 OAuth를 이해하기 위해서는 OAuth공식페이지나 김승현님의 OAuth에 대한 블로그 포스팅 을 참고하시면 되겠습니다.)

이에, 3월 중으로

앞으로 OpenAPI를 제공하는 많은 서비스들이 이 OAuth를 적용하여 진정한 의미의 '사용자 중심의 웹'이 실혔되었으면 하는 바람입니다.

OAuth의 공식 홈페이지에 가보시면 각 언어들에 대한 라이브러리를 제공하며, 프로바이더와 컨수머 샘플코드도 어렵지 않게 찾아볼 수 있습니다. Ruby의 경우 프로바이더와 컨수머 구현을 위해서 oauth-plugin이나 oauth4r 이 제공되고 있지만 실제 세팅을 좀 더 해야하기때문에, oauth4r 에 있는 소스코드를 적용하여 '돌아가는' 샘플 코드를 공유합니다.

프로바이더 소스코드 : oauth_provider.tar

컨수머 소스코드 : oauth_consumer.tar

rails버전이 2.0 이하일 경우는

• gem update --system

로 rails환경 전체를 업데이트 하거나 이것이 여유치 않으실 경우는

• svn co http://dev.rubyonrails.org/svn/rails/tags/rel_2-0-0_RC1/ 프로젝트경로/vendor/rails

하셔