sh’s words

오래 전에 써놓은 글인데, 일단 묵혀두기가 좀 그래서 포스팅을 한다. 스스로에게 자극을 줘서 계속 쓰게 하려는 이유가 크다:)

—-

DB_DataObject 의 세팅과 사용.

DB_DataObject는 일단 앞으로의 과정에서 SQL을 직접 다루는 일이 거의 없도록 도와준다. DBDO는 내부적으로 PEAR::DB 패키지를 통해 DBMS를 다루는데 최근 버전에서는 옵션을 통해 PEAR::MDB를 사용할 수도 있다.

DBDO를 사용하려면 우선 몇 가지 작업을 해줘야 한다.
앞서 밝혔듯이 DBDO는 RowDataGateway 패턴을 구현한 것인데, 하나의 객체가 테이블상의 한 로우(=레코드)를 다룰 수 있다는 뜻이다. 따라서 각 테이블의 Row를 표현하는 클래스를 정의해야 한다. 다행히도 이 작업은 자동화되어있다.
PEAR 하위의 DB/DataObject/createTables.php 라는 스크립트를 이용하면 DB의 각 테이블에 1:1로 대응하는 클래스 파일들을 자동으로 생성해준다. createTables.php 를 실행하기 전에 (more…)

작년 찬바람이 불기 시작하던 즈음부터는 매일 야근하느라
11월엔 그 일 대강 마무리 하자마자 일본 나들이 다녀오느라
12월엔 바로 이어진 스노-보드 시즌에 보드장 다니느라
1월엔 이사할방 알아보러 금천구 일대 누비느라
2월엔 이사하고 차 팔고 사고 하느라

블로그에 신경을 못 썼다.

그 동안 어떤 진보를 했는지는 전혀 모르겠지만 지난 주말에는 파마를 했고 (작년 초의 조금은 충격적인 첫 파마와는 사뭇 다른 후훗) 잘 어울리는 것 같아 마음에 든다. (이대 앞 주노1의 여진선생님께 감사^0^)

그 동안 책도 여러 권 샀는데, 솔직하게 말해서 허영만의 ‘식객’을 제외하고는 끝까지 읽지를 못했다. 아참, ‘남자들의 몸 만들기’라는 살짝 마쵸적인 제목의 헬스/피트니스 안내서랑 ‘와인, 알고 마시면 10배 즐겁다’ 그리고 새로 산 카니발의 사용자 설명서도 읽긴 했지.

실용서로만 손과 눈이 가는걸 보면 지식과 행동의 천칭이 지식쪽으로만 너무 기울었나 보다. 아는 걸 써먹질 않으니 썩어가는게야… 하지만 지난 주에 펼치기 시작한 ‘애드 버스터‘는 감동적이다. 몬스터디자인을 통해서 알게 된 책인데 어제 홍대앞에서 약속시간을 기다리느라 30분 정도 읽으면서 내내 감동을 받았다고나 할까! 이 책은 다 읽은 후에 꼭 꼭 좀 더 자세히 소개를 할거다.

그리고 지난 주부터 (more…)

# User들의 level 나누기

Beginner
	- Terminal에 대한 개념도 없다.
	- vi를 배우고 있다.
	- 디렉토리 개념이 없다.
	- 명령 끝에서 리턴키를 누르는 것을 까먹는다.
Novice
	- ls가 디렉토리 listing이라는 것을 안다.
	- editor를 사용한다.
	- C를 들어보긴 했지만 사용해 본 적은 없다.
	- rm 명령을 막 쓰기 시작했다.
	- mail을 일고 싶어한다.
	- 다른 사람들이 왜 unix를 좋아하는지 궁금해 한다.
USER
	- vi, nroff를 힘겹게나마 써 봤다.
	- regular expression에 대해 들어봤지만, 사용한 적은 없다.
	- 고정 길이 string search를 할 때 egrep을 사용한다.
	- 디렉토리를 옮기는 방법을 궁금해 한다.
	- C로 프로그램을 짜보려고 했지만 실패하고, 파스칼이 좋다고 우긴다.
	- dbx를 오디오의 상표라고 생각한다.
	- news를 읽고 싶어한다.

Knowledgeable User
	- nroff를 문제없이 사용할 수 있고, tbl, eqn도 배우기 시작했다.
	- fgrep이 fast grep이란 것을 유추해 낸다.
	- mv명령이 디렉토리를 옮긴다는 것도 이해한다.
	- '도움말'이 도움이 되지 않는다는 것을 배웠다.
	- C 프로그램 작성하는 법을 배웠다.
	- 텍스트 치환하는데 sed를 한 번 써봤다.
	- 남이 dbx를 사용하는 것을 봤다. 하지만 본인은 사용하지 않는다.
Expert
	- 필요할 때 주저없이 sed를 쓴다.
	- vi의 매크로를 쓸 줄 알고, 필요하면 ex도 사용한다.
	- 포스팅을 한다.
	- C shell 스크립트를 가끔 작성한다.
	- vi로 C 프로그램을 작성하고, cc를 이용해 compile한다.
	- &&, ||이 뭐하는 것인지 안다.
Hacker
	- sed, awk를 완벽히 구사한다.
	- vi의 undocumented feature까지도 사용한다.
	- cat 명령으로 C 프로그램을 짜고, '!cc' 명령으로 compile한다.
	- source-level debugger를 믿지 못하므로 adb를 사용한다.
	- 자신만의 nroff 매크로를 작성한다.
	- Bourne shell 스크립트를 작성한다.
GURU
	- m4, lex를 쉽게 사용한다.
	- cat 명령으로 어셈블리어 코드를 작성한다.
	- 시스템이 loading되어 있는 동안에도 kernel에 대해 adb를 돌린다.
	- 유틸리티 source를 patch해서 customize를 한다.
	- 심심할 때 device driver source를 읽는다.
	- 몇 개의 명령이 필요할 경우에는 make를 이용한다.
	- security 홀을 알지만 크랙을 시도하지는 않는다.
Wizard
	- cat 명령으로 device driver를 작성한다.
	- binary를 직접 patch해서 bug를 수정한다.
	- 묻기 전에 답을 해준다.
	- 자신만의 troff 매크로 패키지를 작성한다.
	- 그의 first name은 Dennis, Bill, Ken 등이다.

—-
sed를 써본 적은 있고 vi, ex명령어를 알지만 nroff는 잘 모르는걸 보니 Knowledgeable User와 Expert중에 KU에 가까운 축인가 보다.

XML-RPC는 XML을 통한 RPC다. 나는 다른 종류의 RPC에 대한 경험은 없으며 나와 비슷한 수준의 사람을 위해 조금 설명하자면, RPC란 Remote Procedure Call라는 이름에서 알 수 있듯이 네트워크를 통한 함수 실행방법이라고 생각하면 된다.
procedure와 function라는 두 용어는 같은 뜻으로 사용되는 경우가 많지만 문맥에 따라 선택되어지며 precedure가 조금 범위가 넓다고 이해하고 있다.

XML-RPC는 RPC의 메세지 프로토콜로 XML을 사용한 것이다. 이것과 유사한 기능을 하는 프로토콜로 SOAP을 들 수 있는데, 나는 SOAP을 통해 구현한 경험은 역시 없다. 그러나 문서상의 스펙으로 둘을 살펴보면 SOAP쪽이 확장성이 뛰어나지만 XML에 대한 지식이 좀 더 필요하다. XML-RPC는 namespace따위는 고려할 필요가 없고 몇 가지 정해진 Data-type만 교환할 수 있지만 SOAP는 이런 것들에서 자유롭다.

XML-RPC는 userland라는 회사에서 (더 정확하게 말하면 userland의 CEO인 데이브 워너의 주도하에) 개발되었지만 그 구현 및 사용은 오픈소스로 자유롭다. http://www.xmlrpc.com 에서 XML-RPC와 관련된 더 많은 정보를 얻을 수 있다.

XML-RPC는 서로 다른 머신간의 데이터 교환에 아주 유용하다. 우리 회사에서는 전통적으로 HTTP POST를 이용한 서버간의 데이터 교환을 자주 사용했다. 그런데 이 방식은 간단하게 구현할 수 있기는 하지만 PHP의 magic_quotes 기능과 더불어 복잡한 문자열을 보내거나 할 때 까다로운 문제점을 자주 만들어낸다. 언젠가 서버간에 HTTP를 통해 상품 목록을 보내는 기능을 구현하는걸 지켜봤는데, DB에서 목록을 읽은 후 csv로 변환을 한 다음 POST로 전송하는 방식을 썼다. 그런데 이게 참 볼만하더라… csv 변환을 할 때도 안정된 라이브러리를 사용한게 아닌데다, PHP는 POST로 전달받은 변수에 addslashes()를 해버리는 멋진 기능 - magic_quotes이 default로 on이라 원치않는 변환이 일어나기도 하는 것이었다.

성격상 이런 구현이 마음에 들지 않아서 살펴보다 발견한 것이 XML-RPC이다. XML-RPC는 HTTP를 통해 XML로 작성된 메세지를 전송하기 때문에 방화벽에 자유롭고 XML을 이용해 이기종간의 전송에 자유롭다.

XML-RPC는 몇 가지의 데이터 타입 - Int, String, Base64, Boolean, Array, Struct - 을 통해 데이터를 표현할 수 있고, 이렇게 표현된 데이터를 RPC를 호출하거나 결과값을 돌려받을 때 사용한다. 참고로 한글 문자열을 전송할 때 String type을 사용하는 것 보다 Base64로 인코딩해서 보내는게 편리하다. XML-RPC 라이브러리중에 xml의 encoding을 UTF-8과 iso-8859만 지원하는 경우가 많기 때문에 맘편하게 Base64를 사용하는게 좋다. 그리고 XML-RPC의 Array type은 순차배열이다. 혹시 연관배열(첨자가 문자열 등인)을 사용하려면 Struct type을 사용하면 된다.

—-
여기까지 적어둔지가 오래됐는데, 흐름이 끊겨버렸다. 글을 버리기는 좀 아깝고 해서 일단 여기까지 포스팅을 하고 기회가 되면 예제와 효용성에 대한 내용을 추가하기로 기약을 해보자.

“PDO”:http://kr2.php.net/pdo PHP Data Object는 DB Abstract Layer 객체입니다. PEAR 패키지 중 널리 쓰이고 있는 PEAR::DB, PEAR::MDB/MDB2 그리고 ADODB등과 마찬가지로 RDBMS마다 서로 다른 native API를 통일할 수 있도록 해줍니다. PDO의 존재를 알고 관심을 가지게 된 것은 올해 초 입니다. 사실 이렇게 빨리(?) 사용할 수 있게 되리라고는 생각을 못했네요.

PDO는 PEAR::DB류와는 달리 C로 구현된 것이라 속도가 빠릅니다. (.. 그렇다고 합니다. 사실 그렇겠죠?) PHP의 extension으로 제공되기 때문에 일일이 include/require 를 하지 않아도 사용할 수가 있습니다. 귀차니즘으로 한참을 미루다가, 오늘 PHP 5.1 beta3를 설치하고 PDO를 처음으로 사용해봤습니다.

$dsn = “{$APP_CONFIG[’database’][’type’]}:host={$APP_CONFIG[’database’][’host’]};dbname={$APP_CONFIG[’database’][’database’]}”;
try {
$pdo = new PDO($dsn, $APP_CONFIG[’database’][’user’], $APP_CONFIG[’database’][’password’]);
$pdo->setAttribute(PDO_ATTR_ERRMODE, PDO_ERRMODE_EXCEPTION);
} catch (PDOException $e) {
echo $e->getMessage();
}

try {
$res = $pdo->query(”SELECT * FROM pmemo_data ORDER BY reg_date DESC LIMIT 10″);
} catch (PDOException $e) {
echo $e->getMessage();
}

while ($row = $res->fetch(PDO_FETCH_OBJ)) {
array_walk($row, ‘kconv’);
echo $row->name;
echo $row->subject;
echo ‘<br />’;

}

그 동안 PEAR::DB나 DBDO 등에 익숙해서인지 아주 자연스럽게 코딩할 수 있었습니다. 다만 PDO_FETCH_OBJ 상수가 PEAR::DB에서 사용하는 상수인 DB_FETCHMODE_OBJECT와 헷갈려 PDO_FETCH_OBJECT라고 적어놓는 바람에 잠깐 삽질을 좀 하고, PDO constructor에서 사용하는 DSN의 형식이 PEAR::DB와는 달라서 역시 땅 좀 팠지만요;; finally가 없는것이 좀 의아하지만 PHP5에서 도입된 예외처리 덕분에 if 문 도배를 하지 않아도 되서 기쁩니다.
PHP5와 PDO가 하루빨리 안정화되서 실제 업무에 적용해볼 수 있기를 고대해봅니다.

그리고 앞으로 PEAR::DB/MDB 그리고 Creole 등의 유사 패키지의 향방도 궁금하군요. MDB의 경우 저자가 PDO와의 API 차이점에 대해서 어떤 의견이 있는것 같습니다만 영어로 의견을 밝히신 바람에 제가 이해를 못하고 있습니다. 찬찬히 봐서 이해가 되면 다시한번 적어볼까 합니다.