2008년 3월 27일 목요일

적응형 소프트웨어로서의 웹 어플리케이션

다양한 브라우저에서 "동일하게 보이고 동일하게 동작하는" 웹 어플리케이션을 만들기란 쉽지 않다. 브라우저라는 환경이 너무나 다양한 탓이다. 다양한 환경을 다루는 솔루션은 단일한 환경을 다루는 솔루션에 비해 복잡해지기 마련이다.

같은 이유로 적응형 소프트웨어를 만드는 것도 어려운 일이다. 사실, "다양한 환경에서 제대로 기능하는 것"이 적응형 소프트웨어의 목표라고 할 때, 웹 어플리케이션은 브라우저라는 다양한 환경에서 제대로 동작하려고 애쓰는 적응형 소프트웨어라고도 할 수 있다.

여러 개의 솔루션을 종합해서 하나로 만든 솔루션은 복잡하기 때문에 유지보수가 어렵다. 다음 예를 보자.

#sidebar {
padding: 10px;
border: 5px solid black;
width: 230px; /* for Internet Explorer */
voice-family: “\“3\””;
voice-family: inherit;
width: 200px; /* real value */
}

html>body #sidebar {
width: 200px;
} /* for Opera */

이 코드는 인터넷 익스플로러와 오페라, 기타 브라우저에서 모두 똑같은 모양의 웹 페이지를 보여주기 위한 CSS 코드이다. 인터넷 익스플로러가 너비 값을 해석하는 방식의 차이 때문에 인터넷 익스플로러를 위한 너비값을 먼저 지정한 후, voice-family 속성을 사용해 인터넷 익스플로러가 선언이 끝난 것처럼 인식하게 하고, 그 후에 다른 브라우저를 위한 너비 값을 선언한 것이다. 하지만 오페라 브라우저도 인터넷 익스플로러처럼 voice-family 속성을 만나면 해석을 멈추기 때문에 아래 쪽에 오페라 브라우저만을 위해 추가적인 선언을 해 주었다. 이 코드는 서로 다른 브라우저 환경에서 동일한 모양을 보여준다는 목표를 달성하기 위해 일종의 CSS 트릭을 이용하고 있다. 이런 방식은 코드를 복잡하게 만들 뿐 아니라 브라우저들의 버전이 바뀌어 CSS를 해석하는 규칙이 변한다면 더 이상 유효하지 않게 된다. 하지만 CSS 기법을 담고 있는 많은 책들이 서로 다른 브라우저 문제를 해결하기 위해 이와 비슷한 트릭들에 의존하고 있다.

위 코드를 주석 없이 본다면 사실상 어떤 부분이 인터넷 익스플로러를 위한 부분이고 어떤 부분이 나머지 브라우저를 위한 부분인지, 맨 아래 오페라를 위해 삽입한 코드는 왜 들어가 있는건지, 알기가 어렵다. 하지만 각각의 CSS 코드를 분리해서 상황에 맞게 로드할 수 있다면 다음과 같이 될 것이다.

/* Internet Explorer */
#sidebar {
width: 230px;
padding: 10px;
border: 5px;
}

/* the others */
#sidebar {
width: 200px;
padding: 10px;
border: 5px;
}

이 편이 코드를 읽기는 훨씬 쉽다. 따라서 환경에 대응하는 각각의 솔루션을 분리하는 것이 복잡도를 줄이는 방법이다. 하지만 S라는 솔루션을 Sa, Sb, ... Sz 으로 분리했을 경우, 요구사항이 변하거나 다른 해결 방법을 사용하고자 하여 Sa가 Sa'으로 변경되면 Sb, ... Sz 도 같이 변경해 주어야 한다는 번거로움이 생긴다.

따라서 이상적인 방법은 Sa와 나머지 솔루션 사이의 차이를 Vab, Vac, ... Vaz로 정의한 다음, Sa만을 변경해 나가고 나머지 솔루션은 Sa에 Vab ... Vaz를 적용해 자동으로 생성하는 것이다.

이와 같은 생각을 웹 어플리케이션에 적용해보자. 하나의 브라우저에 대해서만 CSS나 자바스크립트 코드를 작성한 후 브라우저 사이의 차이를 정의한 룰을 적용해서 다른 브라우저들에 적합한 CSS와 자바스크립트 코드를 생성해내는 것이 가능할 것이다. 일단 각 브라우저에 적합한 코드들을 만들어 냈다면, 리퀘스트의 정보를 살펴보고 해당 브라우저에 맞는 코드를 로드하게 만드는 것은 쉬운 일이다.

솔루션 사이의 차이를 어떻게 기술할 수 있을까? 필요한 것은 코드에서 "관심의 대상이 되는 부분"을 정의하고 그 부분에 "규칙에 의한 변화"를 가해서 다른 솔루션을 만들어내는 것이다. AOP의 pointcut과 advice가 의도는 다를지언정 이와 비슷한 역할을 한다고 할 수 있다. 따라서 솔루션 사이의 variation을 정의하기 위해, pointcut과 advice 같은 형식을 이용할 수 있다.

이와 같은 생각을 variation-applier라는 도구로 구현해보았다. 이 도구는 CSS 파일을 대상으로 한다. 사용 방법은 기본 솔루션에 해당하는 디렉토리와, variation 룰들(IE.var opera.var 등등)이 들어 있는 디렉토리, 솔루션들이 생성될 디렉토리를 지정하고 apply를 누르면, variation 룰 당 하나씩 새로운 솔루션이 생성된다.


variation rule은 pointcut과 advice의 개념을 사용했지만 최대한 CSS 문법과 비슷하게 기술하도록 하였다. 사용 예는 다음과 같다.

/* base file */
#sidebar
{ width: 200px; margin: 0;}

case 1
/* var file */
#sidebar
{ width: ((calculate + 30px)); }
=>
/* result file */
#sidebar
{ width: 230px; margin: 0; }

case 2
/* var file */
#sidebar
{ width: ((before border 5px) (calculate * 1.1 + 10) (after padding 10px)); }
=>
/* result file */
#sidebar
{ border: 5px; width: 230px; padding: 10px; margin: 0;}

case 3
/* var file */
global
{ width: ((around border 0)) margin: ((delete)) }
=>
/* result file */
#sidebar
{ border: 0; }

기본적으로 selector가 같을 때만 variation 규칙이 적용되지만 variation의 selector를 global로 선언한 경우에는 selector에 관계없이 모두 적용된다.

variation-applier는 Common Lisp으로 작성되었으며 weblocks 웹 프레임워크 위에서 실행된다. 실행을 위해서는 Common Lisp과 weblocks를 설치하고, 소스 코드의 build-and-test.lisp 파일을 SLIME으로 로드(ctrl+c ctrl+l)한 후, SLIME에서 (variation-applier:start-variation-applier)를 치면 된다. 브라우저의 주소창에 localhost:8080 을 쳐 넣으면 입력 화면이 나타나는 것을 볼 수 있다.

Blogger에는 파일을 첨부할 수가 없기에 티스토리 블로그에 소스 코드를 올려놓았다.
소스 코드 다운로드

2008년 3월 22일 토요일

프로젝트 만들기

매번 패키지 설정을 하는 것이 귀찮아서 자동으로 폴더와 파일을 생성하는 함수를 짰다.

(make-project 'hello)
=>
./hello/
./hello/src/
./hello/test/
./hello/build-and-test.lisp
./hello/hello.asd
./hello/hello-test.asd
./hello/src/hello.lisp
./hello/test/hello-test.lisp

적당한 테스트와 소스 코드를 추가한 후 build-and-test.lisp 파일을 SLIME으로 로드(ctrl+c ctrl+l)하면 빌드 및 테스트가 이루어지고 결과가 표시된다.

아래 코드를 보면 짤린 것처럼 보이지만 긁어서 붙여보면 제대로 보인다; 후.. 블로거에서 코드 들여쓰기를 제대로 보이게 하려면 pre 태그를 쓰는 수밖에 없는데 이마저도 코드가 길어지면 짤려 보이니, 참 난감하다. 누구 블로거에서 코드 제대로 보이게 하는 방법 아시는 분 메일로 알려주시면 정말 감사하겠습니다. ^^;

(defun make-project (project-name)
(let ((name-string (string-downcase (symbol-name project-name))))
(ensure-directories-exist (make-pathname :directory (list :relative name-string)))
(ensure-directories-exist (make-pathname :directory (list :realtive name-string "src")))
(ensure-directories-exist (make-pathname :directory (list :relative name-string "test")))
(with-open-file (build-and-test (make-pathname :directory (list :relative name-string)
:name "build-and-test"
:type "lisp")
:direction :output :if-exists nil)
(format build-and-test
"(push (make-pathname :directory (pathname-directory *load-truename*)) asdf:*central-registry*)~%(require '~A-test)~%(~A-test:~A-test)~%(format t ~A)~%(quit)"
name-string name-string name-string "\"~%\""))
(with-open-file (asd (make-pathname :directory (list :relative name-string)
:name name-string
:type "asd")
:direction :output :if-exists nil)
(format asd
";;;; -*- Mode: Lisp; Syntax: ANSI-Common-Lisp; Base: 10 -*-~%~%(defpackage #:~A-asd~% (:use :cl :asdf))~%~%(in-package :~A-asd)~%~%(defsystem ~A~% :name \"~A\"~% :depends-on ()~% :components ((:module src :components ((:file \"~A\")))))"
name-string name-string name-string name-string name-string))
(with-open-file (test-asd (make-pathname :directory (list :relative name-string)
:name (concatenate 'string name-string "-test")
:type "asd")
:direction :output :if-exists nil)
(format test-asd
";;;; -*- Mode: Lisp; Syntax: ANSI-Common-Lisp; Base: 10 -*-~%~%(defpackage #:~A-test-asd~% (:use :cl :asdf))~%~%(in-package :~A-test-asd)~%~%(defsystem ~A-test~% :name \"~A-test\"~% :depends-on (\"~A\" :lisp-unit)~% :components ((:module test :components ((:file \"~A-test\")))))"
name-string name-string name-string name-string name-string name-string))
(with-open-file (main (make-pathname :directory (list :relative name-string "src")
:name name-string
:type "lisp")
:direction :output :if-exists nil)
(format main
"(defpackage #:~A~% (:use :cl))"
name-string))
(with-open-file (test-main (make-pathname :directory (list :relative name-string "test")
:name (concatenate 'string name-string "-test")
:type "lisp")
:direction :output :if-exists nil)
(format test-main
"(defpackage #:~A-test~% (:use :cl :~A :lisp-unit)~% (:export #:~A-test))~%~%(in-package :~A-test)~%~%(defun ~A-test ()~% (run-all-tests :~A-test))"
name-string name-string name-string name-string name-string name-string))))

2008년 3월 10일 월요일

MacPorts 사용법

MacPorts는 DarwinPorts의 새 이름으로 리눅스의 apt-get과 비슷하게 각종 소프트웨어의 설치를 쉽게 해 준다. MacPorts 홈페이지에서 dmg 파일을 받아 설치하면 되는데, 설치 후 port 명령이 매뉴얼대로 되지 않는다면, 경로 설정이 안 되어 있어서 그런 것이다. 홈디렉토리(~)에 .profile 파일을 만들어서 다음과 같이 경로를 추가한다.

export PATH=/opt/local/bin:/opt/local/sbin:$PATH

'port search 프로그램이름'(e.x. port search buildbot)과 같이 하면 port를 통해 설치할 수 있는 프로그램들을 찾아볼 수 있다. 원하는 프로그램 이름을 찾으면 'sudo port install buildbot'과 같이 인스톨하면 된다.

Common Lisp 가이드

사실 리습을 처음 공부하려면 막막하다. 어떤 책으로 시작해야 할지, 수 많은 구현 중에 어떤 구현을 사용해야 할지, 쓸만한 라이브러리나 웹 프레임워크는 어떤 게 있는지.. 알기가 어렵다. 국내에 도움을 얻을 만한 책도, 활발한 커뮤니티도 없다. 그래서 내 경험을 바탕으로, 매우 주관적인 가이드를 써 보고자 한다.

1. 구현(Implementation)
리습은 구현이 여러 개다. 언어 자체를 규정하는 Common Lisp ANSI specification이 있고, 그 specification에 맞게 누구나 커먼 리습을 구현할 수 있다. 많은 구현 중에 SBCL을 사용할 것을 추천한다. 오픈 소스이고, 빠르고, 멀티 스레드를 지원한다. 오픈 소스 중 그 다음으로 추천할만한 구현은 OpenMCL(현재는 Clozure CL로 이름을 바꿨다)정도이다.

2. 설치
리눅스, 맥, 윈도우즈 사용자인데 간편한 설치를 원한다면:
LispBox를 다운받아 설치하는 것이 간편한 방법이다. 윈도우즈 사용자일 경우 Clisp 버전을, 리눅스나 맥 사용자일 경우는 SBCL 버전을 다운받는 것을 추천한다. Clisp은 멀티 스레드를 지원하지 않기 때문에 웹 개발 같은 데 사용하기는 어렵지만, 학습 용도로는 아무 문제가 없다.

맥, 윈도우즈 사용자인데 IDE를 사용해 보고 싶다면:
Lispworks Personal Edition이라는 상용 IDE를 몇 가지 제약과 함께 무료로 사용할 수 있다.

맥 사용자인데 간편한 설치와 좀 더 맥 친화적인 환경을 원한다면:
ReadyLisp이 제격이다.

리눅스나 맥 사용자인데 일일이 직접 설치하기를 원한다면:
리습 작업환경은 사실 Emacs + 리습 구현 + SLIME 이라는 세 가지를 설치한 후 연동해 주는 것이다. Emacs와 리습 구현 자체는 apt-get이나 MacPorts를 통해 쉽게 설치할 수 있을 것이고, SLIME은 내려받아 압축을 푼 뒤 별도의 설치 없이 연동만 하면 된다. 설치방법은 리눅스나 맥이나 거의 동일하다. 다음 글들을 참조하면 된다.
http://onlisp.blogspot.com/2007/12/common-lisp-emacs_12.html
http://onlisp.blogspot.com/2008/01/sbcl-thread.html

3. 에디터
Emacs. 사실 vi나 이클립스를 사용하는 방법도 존재하긴 하지만, 리습의 에디터로는 Emacs가 거의 절대적이라고 생각해도 무방하다.

4. 책
속성으로 아주 기본적인 내용만 빠르게 흝고 싶다면:
http://onlisp.blogspot.com/2007/12/2-ansi-common-lisp.html
http://www.cs.gmu.edu/~sean/lisp/LispTutorial.html
http://psg.com/~dlamkins/sl/chapter03.html

사실 위의 내용만 봐서는 리습을 다른 언어와 차별화하는 특성이 어떤 것인지 알기 어렵다. 리습을 제대로 공부해 보고 싶다면 다음의 책들을 추천한다:

ANSI Common Lisp - Paul Graham
간명하고 재미있게 씌어진 책이다. 다만 온라인에 공개되어 있지 않다는 단점이 있다. 구할 수만 있다면 시작하기에 제일 좋은 책이긴 하다. 일부 챕터의 번역이 인터넷에 올라와 있다.

Chapter 1~4
http://xeraph.com/ => Article/프로그래밍 언어

Chapter 2, 10
http://onlisp.blogspot.com/2007/12/2-ansi-common-lisp.html
http://onlisp.blogspot.com/2007/12/10-ansi-common-lisp.html

Practical Common Lisp
매우 친절하고 자세하게 기술되어 있는 책이다. 온라인에 모두 공개되어 있다는 점도 좋다. 현 시점에서는 가장 추천할만한 책이 아닌가 생각된다. 다만, 저자가 뭐든지 늘여쓰는 경향이 있고, 책 분량이 꽤 되기 때문에 보다가 포기할 가능성도 있다.

Successful Lisp
역시 온라인에서 모두 볼 수 있다. 내용이 그리 많지 않아서 금방금방 볼 수 있고, 유용한 팁들도 꽤 있다.

On Lisp
리습이 가진 최고의 장점이라고 할 수 있는 매크로의 모든 것을 다룬 책이다. 링크한 홈페이지에서 무료로 다운받을 수 있다. 리습에 관한 기본적인 내용을 어느 정도 익혔다고 생각될 때 보는 게 좋다.

5. 커뮤니티
공부하다가 모르는 것에 대해 질문을 해야 할 필요가 있다면 구글 그룹이 좋다. Planet Lisp이라는 곳에서 리습에 관련된 글과 뉴스들을 볼 수 있다.

6. 라이브러리
대부분의 리습 라이브러리들은 Cliki라는 곳에서 찾아볼 수 있다. 다음 라이브러리들을 추천한다.
라이브러리들의 쉬운 설치를 위해: asdf
C와 C++ 라이브러리들을 가져다 쓰려면: cffi
테스팅 프레임워크: lisp-unit
웹 프레임워크: weblocks
웹 서버: hunchentoot
Database: CLSQL
정규식: cl-ppcre

7. 커먼 리습 레퍼런스
언어 자체에 대한 레퍼런스를 보고자 한다면 Common Lisp HyperSpec이 좋다(Emacs에서 slime이 로드된 상태일 때 코드 위에서 ctrl+c ctrl+d h 를 누르면 바로 해당 HyperSpec 페이지로 이동한다). 또는 CLTL2를 참고해도 좋다.

유용한 SLIME 명령어들

사실 코드를 읽다가 repl로 돌아가야 할 경우가 많은데, 그럴 때마다 ctrl+x b로 버퍼를 전환하는 건 여간 귀찮은 일이 아니다. 그럴 경우에 slime repl로 돌아가려면:
ctrl+c ctrl+z

slime을 종료하고 재시동 해야 할 때가 있다. slime 종료는:
, quit

lisp 코드를 읽다가 특정 리습 심볼에 대한 common lisp hyperspec을 보고 싶다면:
ctrl+c ctrl+d h

프로그램을 읽는데, 함수나 변수의 정의된 부분을 살펴보고 싶다면:
meta+.
(meta는 보통 alt. 단 해당 정의부분이 탑레벨에 로드되어 있어야 한다. 예를 들어 define-test 라는 매크로의 정의가 lisp-unit 이라는 라이브러리에 되어 있다면 해당 매크로의 정의를 보기 위해서는 (asdf:operate asdf:load-op 'lisp-unit)과 같이 해당 라이브러리가 로드되어 있어야 한다.)

정의부를 살펴보고 다시 원래 코드로 되돌아가려면:
meta+,
(meta+. 의 반대라고 할 수 있다.)

함수 하나를 컴파일하려면:
커서가 함수 위에 있을 때 ctrl+c ctrl+c

파일을 로드하려면:
로드하려는 파일의 버퍼에서 ctrl+c ctrl+l

파일을 컴파일하고 로드하려면:
컴파일하려는 파일의 버퍼에서 ctrl+c ctrl+k

repl에서 약간의 오타 때문에 거의 똑같은 표현식을 다시 치는 것은 귀찮은 일이다. 입력했던 표현식들을 거꾸로 탐색하려면:
meta+p
반대는:
meta+n

슬라임 쪽 버퍼에 있을 때는 tab만 눌러도 자동완성이 되지만 코드 쪽 버퍼에 있을 때는 meta+tab 이 자동완성.

함수의 caller들을 보고 싶다면:
ctrl+c <
함수의 callee들을 보고 싶다면:
ctrl+c >

슬라임 명령어는 아니고 Emacs 명령어지만 적어본다.
Undo:
ctrl+_
Redo:
ctrl+x z