Web of Think

안녕하세요. "생각의 웹"입니다.

지난 포스트에서 말씀드린 바와 같이 이번 글에서는 객체에 의미를 부여하기 위해 객체 정의 이후 객체의 속성과 메소드를 추가하는 법에 대해 설명드리려고 하는데, 이에 앞서 지난 번에 생략하고 지나간 Web IDL에서 제공하는 형(type)들에 대해 먼저 언급하고자 합니다.

1. Web IDL 의 기본 형들 (types)

이런 글을 읽는 분이라면 이 형이 동네에서 노는 형들을 의미하는 것이 아닌 것은 아시리라 믿지만 왕초보자를 위해 프로그래밍 언어의 가장 기초적인 내용을 말씀드리죠. 

컴퓨터는 0 과 1 외에는 알지 못하지만 수 많은 0과 1을 (2진수라고 합니다.) 엄청나게 빠른 시간 내에 처리할 수 있는 능력을 지녔습니다. 하지만 컴퓨터에게 일을 시키는 역할을 하는 프로그램을 짜는 건 사람이다 보니 2진수보다 10진수로 표기되는 정수(integer)와 실수(float point number) 그리고 문자열(string) 등에 익숙합니다. 따라서 대부분의 프로그래밍 언어는 이런 형들을 지정해주면 컴퓨터가 이해할 수 있는 2진수로 변환해 주는 기능을 합니다. 더욱이 자바스크립트 언어는 타입이 없는 (untyped language) 언어라고 불리는 데 특별히 형을 지정해 주지 않아도 값을 통해 형을 유추하는 기능을 제공한다는 의미로 보면 됩니다.

뻔한 이야기를 다시 하는 이유는 자바스크립트에서는 형을 지정해 줄 필요가 없더라도 API 입장에서 보면 상황이 다릅니다. API를 사용하고자 하는 프로그래머에게 호출하고자 하는 대상에 전달할 값의 형을 알려주어야 하기 때문입니다. 자바스크립트에서는 필요에 따라 암묵적으로 형 변환 (implicit type conversion)이 일어나지만 종종 의도치 않는 변환이 일어날 수 있기에 주의해야 합니다.

다시 기본 제공하는 형들 (primitive types)의 예약어들(reserved keywords)를 보편적으로 많이 쓰는 C/C++/Java를 기준으로 나열해 보면,

• 참/거짓 형: bool
• 정수 형: { signed | unsigned } short, int, long
• 실수 형: { signed | unsigned } float, double
• 문자 형: char, char[], char*, String

• 참/거짓 형: boolean
• 정수 형: byte, {unsigned} short, long
• 실수 형: {unsigned} float, double
• 문자 형: DOMString
• 객체 형: object  

이외에 임의의 형 (any) 등도 있으니 자세한 사항은 Web IDL spec.를 확인하시기 바라며, int 가 예약어가 아니라는 점 유의하시면 좋을 것 같습니다.

2. 속성 정의하기

[Constructor]
[Constructor(DOMString model)]
interface ArduinoBoard { 



};

이제 생성자에서 받은 model이라는 parameter를 속성으로 객체에 저장하기 위해 model attribute를 추가해 봅시다.

속성을 설계하는 문법은 다음과 같습니다.

interface 인터페이스_이름 {

attribute 속성의_형 속성의_이름;

};

[Constructor]
[Constructor(DOMString model)]
interface ArduinoBoard { 



    attribute DOMString modelName;
};

간단하죠? 이로써 멍텅구리 객체가 정보를 갖는 객체로 진화했습니다. ;-)

3. 메소드 정의하기

객체가 속성만을 지니고 있다면 소극적인 느낌이죠. 이번에는 객체에 행위를 부여하기 위해 메소드를 추가해 봅니다.

메소드는 메소드 이름, 메소드의 인자들(parameters), 메소드의 반환 형 (return type)으로 구성되어 있고 문법은 다음과 같습니다.

interface 인터페이스_이름 {

    반환_형 메소드_이름(인자_형 인자_이름, ...);

};

유념할 사항 중 하나는 설계 시, 메소드 오버로딩(method overloading) 기법을 사용하게 되면 의도치 않은 오류를 일으킬 수 있다는 점인데, 이는 자바스크립트에서는 자동 형 변환이 일어나기 때문입니다. 

백문불여일견이니 예시로 문자열을 전송하는 쓰기 메소드를 설계해 보죠.

[Constructor]
[Constructor(DOMString model)]
interface ArduinoBoard { 



    attribute DOMString modelName;
    void write(DOMString msg); 
};

이 메소드는 메세지를 쓰고 결과를 반환하지 않도록 (void) 설계했습니다. 

지금까지 객체에 속성과 메소드를 정의하는 법을 설명드렸습니다. 여기까지 설명드린 것으로도 간단한 자바스크립트 API를 설계하실 수 있게 되었습니다. 축하드립니다!

하지만, 자바스크립트는 생각하는 것보다 만만치 않은 언어입니다. 조금 더 공부해 보시면 아마 곧 깨닫게 되실 겁니다. 따라서 다음 포스팅은 자바스크립트 언어의 특징을 살려서 API를 보다 상세히 설명하는 내용으로 준비해 보려고 합니다.

긴 글 읽어주셔서 감사드리며 궁금한 점 댓글로 남겨주시면 성실히 답변드리도록 하겠습니다. 행복한 하루 되시길!!!

"생각의 웹" 입니다.

지난 두번의 포스팅에서 이 글을 쓰는 배경과 관련 도구에 대해 설명드렸습니다.

이 글부터는 본격적으로 JavaScript API를 Web IDL로 설계하는 방법을 duino 라는 Arduino 제어를 위한 JavaScript API를 예제로 해서 Web IDL 기본 문법부터 차근 차근 알려드리도록 하겠습니다.

먼저, duino의 샘플 코드를 다시 보죠.

var arduino = require('duino'),
    board = new arduino.Board({
     device: 'USB0'
});

var led = new arduino.Led({
  board: board,
  pin: 13
});

led.blink();

소스 코드에 대해 간단히 설명드리면 arduino 변수에 'duino' 모듈을 불러와 Board 초기화를 수행하는 Board 객체를 board 변수로 생성하게 됩니다. 이후 Led 점멸을 위해 board 변수를 초기 입력 값으로 받는 Led 객체를 생성해 led 변수로 저장후 blink() 함수를 통해 점멸 기능을 손쉽게 수행하게 됩니다. 

먼저, require() 함수는 Node.JS에서 자바 스크립트 모듈화를 위해 제공하는 함수로 아직 자바스크립트 표준 (ECMAScript 5)으로 제공되지 않기에 Web IDL에서도 표현할 수 없기에 따라서 모듈화 함수 및 모듈화 함수를 통해 가져온 변수를 마치 namespace로 사용하는 부분(new arduino.Board(...) )은 제약사항으로 두고 생성자 함수인 new 키워드를 이용해 설계하는 부분부터 시작하겠습니다.

1. 객체를 정의하기

가장 널리 알려진 객체 지향 언어인 C++, Java 등에서는 객체를 찍어내는 틀을 클래스(class)라고 합니다만 Web IDL에서는 인터페이스(interface)라는 키워드를 사용합니다. (인터페이스는 C++, Java에서는 다른 의미로 사용하는 키워드이기에 혼동하면 안됩니다. )

인터페이스를 설계할 때의 기본 문법은 다음과 같습니다.

interface 인터페이스_이름 { 

};

여기서 인터페이스_이름에 알맞은 인터페이스 이름을 지정하면 됩니다. 이 이름은 보통 공백을 포함하지 않는 영 단어 혹은 영 단어의 조합을 의미하며 단어의 시작은 대문자로 시작하고 그 외는 소문자로 작성하는 것을 권고합니다.

예를 들면 올바른 인터페이스의 이름으로 Board, ArduinoBoard, Led, LedLamp 와 같이 명명할 수 있습니다.

2. 객체를 생성하기

기존 객체 지향 언어들과 다르게 Web IDL에서 정의한 인터페이스에 대한 객체를 생성하기 위해서는 [Constructor] 확장 속성을 지정해 주어야 합니다. 이 확장 속성은 생성자 함수가 가지는 인자(parameter)들에 대해 설명해 줄 수 있습니다.

앞서 정의한 인터페이스에 별다른 인자가 없이 생성 가능한 객체를 정의하려면 다음과 같이 설계하면 됩니다.

[Constructor]
interface 인터페이스_이름 { 

};

상기와 같이 설계할 경우, 객체를 다음과 같이 생성할 수 있게 됩니다.

var myObj = new 인터페이스_이름();

생성자 함수에 인자가 필요할 경우, 다음과 같이 설계합니다.

[Constructor(인자의_형식 인자_이름)]
[Constructor(인자의_형식 인자_이름, 인자의_형식 인자_이름)] 

인자의_형식은 또다른 인터페이스의_이름이거나 추후 설명할 ECMAScript의 기본 형식 등이 될 수 있으며, 인자_이름은 소문자로 시작하는 영 단어나 복합 단어입니다. (복합 단어일 경우, 두번째 단어부터는 공백없이 대문자로 시작하는 단어로 표기하는데 이걸 낙타 모양을 닮았다고 해서 보통 camel case 라고 부릅니다.)

마지막으로 [Constructor] 확장 속성은 여타 객체 지향 언어의 생성자 함수처럼 여러 번 지정이 가능합니다. 예를 들면, 

[Constructor]
[Constructor(DOMString model)]
interface ArduinoBoard { 

};

위와 같이 설계할 경우, 다음과 같이 두 가지 형태로 객체를 생성할 수 있습니다.

var board1 = new ArduinoBoard();

var board2 = new ArduinoBoard("ArduinoNano");

지금까지 객체를 정의하고 생성하는 법에 대해 설명드렸습니다. 아직 객체에 아무런 정보가 없기에 생성한 객체로는 아무 일도 할 수 없습니다. 다음 글에서는 이 객체에 속성(attribute)와 메소드 (method)를 정의하는 법을 설명드리도록 하겠습니다.

알고 있는 지식을 꾸준하게 글로 적어 가는 습관이 잘 들지 않아 관심가지고 계속 구독해 주시는 분들께 죄송할 따름입니다. ^^;

늘 행복하시고 해피 코딩하시기 바랍니다.

"생각의 웹"입니다.

 "Web IDL로 JavaScript API를 설계하기" 시리즈의 첫 번째 포스팅에서 이 작업의 당위성에 대해 말씀드렸으니 이제는 도구를 설치하고 사용해 보기로 합시다.

지난 번 포스팅에서 소개해 드린 widlproc 도구는 Web IDL로 작성된 설계 문서를 XML 형태로 변환할 뿐만 아니라 연계된 도구를 통해 해당 xml에 대한 dtd와 xslt 문서를 통해 html 문서를 생성해 줍니다. 다시 말씀드리면, Web IDL로 설계한 사항에 대한 문법 적합성(문법 오류 및 완결성 등)를 검증(validation) 해서 이상이 있을 경우 해당 위치를 알려주고 문제가 없을 시 XML 문서로 내뱉어 줍니다. 이 XML를 이용해 사람이 읽을 수 있는 HTML 문서를 생성할 수 있으며 또한 이 정보를 기반으로 해당 API에 대한 코드 템플릿(stub code)을 생성하여 개발 생산성을 향상시킬 수 있습니다.

그럼 도구를 받아 설치해 보도록 합시다.

1. 먼저 아래 github에서 widlproc를 다운로드 받습니다. 
   (https://github.com/dontcallmedom/widlproc)
   git clone 하거나 해당 페이지에서 다운로드 받을 수 있습니다.
   
   
2.  해당 페이지에는 마치 windows에서 동작하는 것처럼 가이드되어 있으나 리눅스를 사용하시길 권장합니다. 윈도우즈 상에서 cygwin을 까느니 virtualbox 기반 ubuntu를 사용하는게 속 편하실 겁니다. XML 관련 도구들이 대부분 리눅스에서 제공되는 것들이기 때문입니다. 저는 아래와 같이 virtualbox에 ubuntu 14.04 LTS를 설치하여 작업했습니다.
   
   
   
   
3. 다운로드 받은 파일이 존재하는 경로에서 Makefile 을 확인한 뒤 make 명령을 수행합니다. 빌드를 위해 필요한 라이브러리가 있다는 메세지가 나오는 경우, apt-get install 명령을 통해 설치하도록 합니다.
   
   
4. 빌드가 정상적으로 완료되면 해당 경로 아래 obj 폴더가 생성되고 이 경로에 widlproc 이라는 실행 파일이 존재하게 됩니다.
   
   
5. 도구의 사용법과 Web IDL 문법 및 documentation rule에 대한 정보는  /doc/widlproc.html 파일을 참고하시기 바랍니다.
   
   
6. 간단한 테스트를 위해 함께 제공하고 있는 샘플 Web IDL 문서를 가지고 widlproc 도구를 실행해 봅시다. /examples 경로에 가면 *.widl 문서가 있습니다. 미리 알려드릴 사항은 이 문서들은 현재 widlproc 도구에서 더 이상 허용하지 않는 Web IDL 문법을 포함하고 있다는 점입니다. 따라서, 수행 결과 문법 에러 화면을 보시더라도 크게 놀라지 않으시기 바랍니다. (저는 놀랐거든요;;)
   
   
7. *.widl 문서를 바로 *.html 문서로 생성해 주는 Makefile이 /examples 경로에 있습니다. 해당 파일을 열어 경로가 제대로 되었는지 확인합니다.
   
   
   
   
8. make 명령을 수행하여 widl 문서를 html 문서로 변환합니다. 필요한 모든 도구가 설치되어 있다면  module ... { 으로 시작하는 라인에서 오류가 있다고 알려줍니다. (혹시 도구가 필요하다고 나오면 해당 도구를 apt-get install {도구 명} 명령으로 설치합니다. ) 여기까지 하시면 모든 작업을 제대로 수행하신 겁니다.

여기서 발생하는 오류들은 예제로 제공되고 있는 bondi.widl, filesystem.widl를 작성한 시점 이후에 Web IDL 문법은 많은 개정이 있었기 때문에 이에 맞춰 widlproc 코드는 업데이트 된 반면 예제 코드는 업데이트 되지 않아 발생한 문제입니다. 

따라서, 다음 포스팅은 지난 arduino JavaScript API 관련 포스팅에서 간략히 정리했던 Web IDL로 HTML 문서를 생성한 사례을 들어 Web IDL로 설계하는 법을 소개하도록 하겠습니다.

오늘 포스팅은 여기까지 입니다.

관심 가져주셔서 감사합니다.

늘 행복한 하루 되시길...    

안녕하세요. "생각의 웹"입니다.

이번 포스팅부터는 제목과 같이 Web IDL로 JavaScript API를 설계하는 방법을 여러분들께 공유해 보고자 합니다. 

먼저, 여러분에게 JavaScript API를 설계해야 하는 당위성과 그리고 Web IDL이 무엇인지에 대해서 설명드려야 하겠죠.

우선 첫번째 JavaScript API를 설계해야 하는 이유부터 말씀드리겠습니다.

• JavaScript는 스크립트 언어라는 특성 상 type 선언 없이 변수를 생성하고 유연한 형 변환(type casting)을 통해 컴퓨터 언어의 지식이 부족한 초급 개발자들도 쉽게 사용할 수 있을 뿐만 아니라 함수형 언어의 특성을 갖는 객체 지향 언어로서 확장성과 유연성이 좋아 고급 개발자에게도 유용한 언어입니다.
  
  
• 웹을 지원하는 모든 형태의 기기에서 동작하는 클라이언트 앱 외에도 Google이 만든 V8 엔진을 이용해 만든 Node.JS라는 서버 프레임워크에서도 동작하는 서버 앱 그리고 Mongo DB라는 NoSQL DB에서도 사용 가능한 매우 범용적인 개발 언어입니다.
  
  
• 웹에서 동작하는 앱은 대부분 브라우저의 개발자 모드 (F12 키)를 통해 JavaScript code를 살펴 볼 수 있고 이런 수고가 아니라도 구글링을 통해 다양한 라이브러리 혹은 코드 조각 (code snippet)를 검색할 수 있습니다. 원하는 기능의 대부분을 단순히 복사 & 붙여 넣기로도 구현할 수 있습니다. 
  
  
• 이렇게 코드를 훔쳐 사용하기 쉬운 구조 때문에 어차피 훔쳐 사용할 거라면 이걸 하기 위해 분석하는 수고를 덜어주는 마음씨 착한 개발자의 도움으로 인해 재사용하기 쉬운 형태로 만든 라이브러리가 매우 많이 있습니다. 물론 대부분 공짜구요. 이때 좋은 라이브러리는 API만 알아도 기능을 사용할 수 있도록 사용자에게 제공합니다. 코드를 모두 읽어 봐야 한다면 '복사 & 붙여넣기'보다 나은게 없으니까요.
  
  
• API는 Application Programming Interface의 약자로 말 그대로 앱을 프로그래밍하는 인터페이스, 즉 앱에서 수행될 기능을 짜는 방법이라고 볼 수 있습니다. JavaScript 앱을 작성할 때 API의 도움을 받으면 적은 노력으로 원하는 기능을 구현할 수 있습니다.
  
  
• API에 이용해 앱을 짜는데 자신감이 붙었다면 (게다가 혹시 개발 비 명목으로 돈도 벌었다면) 라이브러리가 제공하지는 않지만 앱을 짜는데 필요했던 기능을 API로 설계해서 추가해보면 어떨까요? 이런 너그러운 마음씨가 당신이 했던 수고를 반복하지 않고 당신이 알지 못하던 새로운 기능을 개발할 수 있도록 도울 겁니다. 당신이 사용했던 라이브러리를 개발한 원 저자가 그랬듯이 말입니다.
  
  
• 좋은 앱은 많은 사람들에게 유용한 기능을 제공해 주지만 모든 사람들을 만족시켜 줄 수 없습니다. 사람들의 취향이란 사람들의 숫자 만큼이나 다양하니까요. 그들에게 DIY (Do It Yourself) 할 수 있도록 해 준다면 메일 함에 쌓이는 다양한 수정 요구사항에서 조금은 해방될 수도 있습니다. (그렇다고 버그에서 해방되는 걸 의미하지는 않습니다.)
  
  
•  미래는 API의 시대가 될 것이라고 예견하는 사람들이 있습니다. (당연히 저도 그런 사람 중 하나입니다.) 소프트웨어 교육이 보편화 되고 있기에 대부분의 사람들이 프로그래밍을 할 수 있게 되리라고 보기 때문이죠. 따라서, 머지않아 단순히 API를 활용해 앱을 짜는 것은 더 이상 신기한 일이 되지 않겠지만, 새로운 기능을 제공하는 API를 만들어서 제공하는 역할은 여전히 전문가의 영역에 남아 있을 것입니다.

쓰다 보니 길어져서 한줄 요약하면 다음과 같습니다.

JavaScript는 시장이 크고 유용성이 높은 개발 언어로 API를 설계할 줄 알면 전문가로 대접 받을 수 있다. - 웹 오브 띵크

동기 부여가 되는 이야기를 한건지 모르겠지만 혹여 여기까지 읽으셨다면 필자는 여러분들이 API를 설계하기로 충분히 세뇌(?) 되었다고 생각하고 두 번째인 Web IDL에 대해 설명드리겠습니다.

일단 Web IDL 에 관련된 문서가 있는 아래 링크를 한번 방문해 보시죠. 

http://www.w3.org/TR/WebIDL/

영문으로 된 문서는 무조건 번역기를 돌리다 보니 무슨 소린 줄 모르시겠다는 분들과 영어에 자신있으나 배경 지식이 없어 이해가 안가시는 분들을 위해 요약 (abstract)을 한글로 번역해 보았습니다.

이 문서는 Web IDL 이라는 인터페이스 정의 언어를 정의하는데 웹 브라우저에서 구현될 것을 의도한 인터페이스들을 설명하는데 사용될 수 있다. Web IDL은 웹 플랫폼에서 사용되는 공용 스크립트 오브젝트들의 동작을 보다 읽기 쉽도록 명세화하기 위한 수많은 기능들을 가진 IDL의 변종이다. Web IDL로 명시된 인터페이스들이 어떻게 ECMAScript 실행 환경 내에서 구성되는 지에 대해서도 상세화 되어 있다. 이 문서는 이미 배포된 스펙 문서를 어떻게 구현할지에 대한 가이드을 개발자에게 제공하고 새로 배포하는 스펙 문서의 인터페이스의 구현체가 서로 호환되도록 보장하기 위해 참조하기 위함이다. - W3C Web IDL Abstract

등장한 용어들에 대해 간단히 설명 드리면 다음과 같습니다. 또 의아한 용어가 있다면 댓글로 남겨주시기 바랍니다. :-)

• "정의" - Justice가 아닌 Definition 입니다. 전 공대 출신이니까요. ;-)
• "웹 브라우저", "웹 플랫폼" - 모두 여러분이 웹 세계를 탐험하는 도구(앱)를 의미하나 브라우저는 사용자 관점에서 플랫폼은 개발자 관점에서 바라보는 겁니다.
• "오브젝트" - 한글로는 객체라고 번역되나 프로그램에서 기능을 수행하는 단위라고 이해하면 됩니다.
• "ECMAScript" - 여기서는 JavaScript와 동의어라고 이해하면 됩니다.
• "스펙" - 대학이나 취업 시 적어내는 이력서가 아니라 정의한 내용을 적은 규격서입니다. 
• "구현체" - 코딩을 완료해서 동작하는 프로그램을 의미합니다. 

발췌한 요약문에서 빨간 색 밑줄친 부분은 주의 깊게 봐주셨으면 합니다. 제가 Web IDL로 JavaScript API를 설계하는 데 사용하는 이유를 말해주는 대목이니까요. 이 내용에 대해 이후 포스팅에서 좀 더 자세하게 설명드리겠지만 먼저 간략히 말씀드리면 JavaScript 언어의 유연성에 대한 부작용으로 인해 API를 구체적으로 명세하기 어려운 점이 발생합니다. 이렇게 API의 동작을 명확하게 알려주지 못한다면 사용하는 사람 뿐 만 아니라 API를 구현하는 사람에게도 혼란을 초래하기 때문에 구체적인 명세화 방식이 꼭 필요합니다.

게다가 이외에도 Web IDL를 사용하면 추가 이득을 얻을 수 있는데 그것이 바로 API 설계 검증 및 문서화에 대한 자동화입니다. 아래 링크의 widlproc이라는 도구를 통해 설계자는 설계의 유효성을 검증하고 손쉽게 문서를 생성할 수 있습니다. 이 방법 역시 추후 포스팅으로 설명드리겠습니다.

widlproc: https://github.com/dontcallmedom/widlproc  

이번 포스팅은 여기까지 입니다.

감사합니다.