reshout.com

이 글은 다음 URL을 참조 및 보완하여 작성되었습니다. 

Android의 debuggerd의 코드를 읽던 중 재밌는 이름의 함수를 발견했습니다!

안드로이드폰 개발 프로젝트에서 일하기 시작한지 어느덧 3달이 다 되어갑니다. 순수 소프트웨어를 개발하다 스마트폰개발 분야에 뛰어드니 처음에는 어리둥절하고 용어도 익숙치 않았습니다. 대기업의 프로세스도 적응이 잘 되지 않았구요. 

아주 오랜만에 새 컴퓨터를 조립했습니다. 지금까지 조립한 컴퓨터는 대체로 가성비 위주의 저렴한 구성이었죠. 듀론, 애슬론XP 1800+ CPU를 사용했습니다. 인텔 제품을 사용하여 조립하는 것은 이번이 처음!

컴퓨터로 EBS 라디오 듣기에 대한 포스팅에 이어, mp3로 녹음하는 방법을 소개해 드리고자 합니다. 거원제트오디오와 같은 별도의 어플리케이션을 설치해야 될 줄 알았는데, 다음 팟 플레이어로 간단히 되더군요. 

2010년의 소박한(?) 목표는 다음과 같습니다.

루비를 제대로 공부하진 않았지만, 언어가 간결한 덕분에 여러가지 상황에서 유용하게 사용하고 있습니다. 그 동안 만들어서 사용했던 몇 가지 루비 예제 코드를 소개합니다. 여기에 소개하는 코드를 조금만 수정하면 다양한 경우에 활용할 수 있을 것 같네요.

1. 소스코드에서 32자 이상의 심볼을 사용한 라인을 찾아 출력하기

HITACHI 메인프레임 C 컴파일러가 32자 이상의 심볼을 지원하지 않더군요. 일일이 찾기 힘들어서 이를 찾기 위해 작성한 프로램입니다. 현재 디렉토리에 존재하는 소스코드를 읽어 32자 이상의 심볼을 찾은 경우 해당 라인을 라인번호와 함께 출력합니다.


2. 파일의 라인 뒤집기

매년 말 블로그에 독서 리스트를 정리할 때 사용하기 위해 작성한 프로그램입니다. 티스토리에서 목록을 뽑아 파일에 저장한 후 이를 뒤집어 독서 리스트를 읽은 순서대로 뽑아냅니다.


3. 프로그램 수행 및 stderr, stdout 얻기

루비에서 다른 프로그램을 실행하고 stderr, stdout을 추출하는 예제 코드입니다. 루비를 사용하여 배치 스크립트를 작성 할 때 유용할 것 같네요.

요즘 회사들어와서 처음으로 제품 메뉴얼을 작성하고 있습니다. XML 형태로 작성되는 메뉴얼 파일은 SVN을 통해 형상관리 되고 있는데, 윈도우 비스타에 설치한 TortoiseSVN가 자꾸 commit 할때마다 죽어서 대안을 찾던 중에 Slik SVN이라는 것을 발견하게 되었습니다.


간단히 설치만 하면 윈도우 cmd에서 svn 관련 커맨드(svn, svnadmin, ...)를 사용할 수 있습니다.

http://www.sliksvn.com/en/download

이런 복잡한 상황을 맞이할때마다 유닉스 기반의 Mac OSX가 그리워지는군요...

dlopen()으로 shared object를  로딩하는 과정에서 에러가 발생하여 dlerror() 함수를 통해 에러의 원인을 확인해 보았습니다.


구글에서 에러 메세지를 이용해 검색하다가 해결의 실마리를 찾았습니다! file 명령어로 파일의 타입을 확인해 보니 executable과 shared library의 파일 타입이 다르더라구요.

C프로그래밍을 하다보면 memory leak에 대한 걱정 때문에 메모리를 동적으로 할당(malloc)하는 것이 부담스럽습니다.

만약 동적으로 할당한 메모리가 함수내에서만 사용된다면 함수 끝에서 free할 필요 없이 malloc 대신 alloca로 메모리를 할당해 사용하면 됩니다. alloca를 사용하면 activation record(stack)에 메모리가 할당되거든요.

회사에서 제가 사용하는 개발 환경을 소개합니다. 제가 하는 일은 프로그래밍 언어의 compiler, interpreter, traslator를 개발하는 것 입니다. 주로 사용하는 툴은 gcc, flex, bison, subversion, vi, eclipse 등등 이구요.

한동안 console + screen + vi 환경을 고집하다 eclipse + vi plugin으로 넘어온지 몇달 되었습니다.


자주 들여다보는 flex, bison description의 syntax highlighting이 안된다는 것을 제외하고는 매우 만족스럽습니다. 특히 eclipse를 사용할때 가장 좋은 점은 Refactor > Rename 기능을 제공하기 때문에 변수, 함수 등의 이름을 바꾸기가 편리하다는 것 입니다.

제가 사용하는 컴퓨터에는 Vista가 설치되어 있고, VMWARE 환경에서 Ubuntu를 부팅해 놓고 개발환경으로 사용하고 있습니다. 2GB의 메모리를 할당해서 개발환경으로 부족함 없이 잘 동작합니다. 이렇게 설정해 놓은 덕분에 윈도우와 리눅스를 아주 편리하게 동시에 사용하고 있습니다.

console 환경에서 기본적인 툴을 다루는 능력이 뒷받침 된다는 전제하에, 다양한 개발 도구, 개발 환경에 대하여 열린 자세를 지니는 것은 개발자가 가져야할 중요한 덕목이라고 생각합니다. 좀 더 효율적으로 일할 수 있는 방법에 대한 끊임 없는 고민이 우리의 퇴근 시간을 앞당겨 줄 수 있을테니까요.

맥을 사용하면서 가장 불편한 것은 바로 마우스의 움직임 입니다! 가속도가 적용되는 방식에 적응하기가 쉽지 않네요. 더군다나 회사에서는 윈도우, 리눅스를 쓰고 집에서 잠깐 맥을 사용하다보면 맥의 마우스 방식이 너무 불편하게 느껴집니다.

맥에서는 마우스가 같은 거리를 움직이더라도 빠르게 움직이면 포인터가 많이 이동하고, 느리게 움직이면 적게 이동합니다. 윈도우의 경우에는 빠르던지 느리던지 동일하게 이동하기 때문에, 이런 습관대로 맥에서 마우스를 움직이면 정교한 컨트롤을 하기 어렵고 손목이 아파옵니다.

게다가 기본적인 마우스 속도도 굉장히 느립니다. 덕분에 24인치 아이맥 화면을 기본 마우스 설정으로 돌아 다니다 보면 속에서 천불이 나죠! 그래서 마우스 속도를 높이고자 주로 사용되는 프로그램이 MouseZoom 입니다. 그러나 여전히 가속도를 반영하는 움직임으로 인한 불편함은 해결되지 않죠. 이 때 이와 같은 문제를 어느정도 개선해 주는 프로그램이 바로 SteerMouse 입니다.

http://www.apple.com/downloads/macosx/drivers/steermouse.html
약간의 설정을 해주니 윈도우랑 별차이를 못 느끼겠군요. 맥에서 마우스 사용에 불편함을 겪고 계신 분이라면 꼭 한번 설치해 보세요.

NHN에서 프로그래머를 위한 나눔고딕 코딩글꼴을 배포하였습니다! 회사에서(Vista) 집에서(Mac) 나눔고딕을 사용해왔는데 코딩글꼴까지 나와서 정말 반가웠습니다.

http://dev.naver.com/projects/nanumfont

백문이 불여일견! 다양한 환경에 적용된 스크린 샷을 보여드리겠습니다.




윈도우 환경에서는 지금까지 Dina를 주로 사용했습니다. 그래서 그런지 Putty에서 나눔고딕 코딩글꼴을 적용해 보니 비교적 선명하지 않은 느낌이 들어 아쉬웠습니다. 그러나 리눅스나 맥의 경우에는 아주 만족스러웠어요. 당분간은 이 폰트만 사용하게 될 것 같습니다. 그러나 약간의 문제가 있습니다.

리눅스의 경우, 그놈 터미널에 적용했을때 커서가 두글자 크기로 잡히면서 다음 글자를 가려버리는 현상이 발생하더라구요. 해결 방법은 다음 URL에 잘 정리되어 있습니다.
http://dev.naver.com/wiki/nanumfont/index.php/TroubleShooting

맥의 경우, 터미널의 Preference에서 나눔고딕 코딩글꼴로 설정한 후 터미널을 완전히 종료하고 다시 실행하면 다른 폰트로 설정이 바뀌어 있습니다. 그래도 맥에는 Monaco라는 예쁜 고정폭 글꼴이 있어서 그리 아쉽지는 않네요.

Putty에 적용했을때를 제외하고는 대체로 매우 만족스럽습니다. 프로그래머라면 한번 사용해 보세요.

본격적으로 iPhone 어플리케이션을 개발해 보려고, 기초가 되는 Objective-C 언어를 공부중입니다. 컴파일러팀에서 일하다보면 다양한 언어를 접하게 되는데 이녀석도 만만찮게 독특한 개성을 지니고 있는 듯 합니다. 특히나 Smalltalk에서 가져온 복수의 파라메터를 가지는 메서드의 정의 및 호출 방식은 굉장히 독특하네요.


Objective-C를 공부하면서 본격적으로 Xcode를 사용하고 있습니다. vi 에디터 기능을 쓸 수 없다는 것을 빼고는 훌륭합니다! 화면에 노란 줄이 Warning 메세지 입니다. 소스코드에 바로 Error, Warning을 표시해 주네요. 블로그에 공부한 지식을 정리할 수 있는 수준히 되도록 틈틈히 부지런히 공부해야겠습니다.

저는 주로 해피해킹프로2 키보드를 사용합니다. 이 키보드는 일반 키보드와 키 배열이 조금 다른데, Caps Lock키 자리에 Control키가 위치하고 있습니다. 일반 키보드에 왼손을 가만히 가져다 놓으면 아래에 위치한 Ctrl키보다 가운데 위치한 큼직한 Caps Lock키를 새끼 손가락으로 누르는 것이 훨씬 편하다는 것을 알 수 있습니다. 해피해킹 키보드를 사용하면서 습관이 되서 그런지 저는 일반 키보드에서도 Caps Lock키를 Ctrl키로 바꿔서 사용하곤 합니다. 실제로 훨씬 편하기도 하구요. 각 운영체제 별로 그 요령을 알아보도록 하겠습니다.

맥

System Preferences > Keyboard & Mouse에 가셔서 Keyboard 탭의 아래쪽을 보시면 Modifier Keys... 버튼이 있습니다. 이걸 누르시면 Caps Lock, Control, Option, Command Key에 대한 키매핑을 수정할 수 있습니다.  Caps Lock을 Control로 매핑해 주시면 설정이 완료됩니다!

리눅스

일회성 방법
쉘에 다음 내용을 입력하세요.

영구적인 방법
~/.Xmodmap에 다음 내용을 추가하세요.
참고: http://efod.se/writings/linuxbook/html/caps-lock-to-ctrl.html

윈도우

첨부파일을 열어보시면 2개의 레지스트리 파일이 있습니다. 하나는 Caps Lock키를 Control키로 매핑하고 다른 하나는 원래 상태로 돌려 놓습니다. 실행시키고 재부팅 하시면 설정이 완료됩니다.

Eclipse 에디터에서 vi의 기능을 사용할 수 있는 플러그인을 소개합니다.

http://www.satokar.com/viplugin/

이 플러그인은 15유로를 주고 구입해야 합니다. 저는 그나마 환율이 상식적이였던 시기에 구입했습니다. 꾸준히 업데이트 되고 있어 믿을만 하고, Help > Software Updates에서 손쉽게 설치 및 업데이트를 할 수 있습니다.

Mac OSX 환경에서 Eclipse에 이 플러그인을 설치해보니 CommandMode 창에 글씨가 보이지 않아서, 홈페이지에 어줍잖은 영어 실력으로 문제를 호소했더니, 몇일 후에 패치가 올라왔습니다! 사용자를 위한 세심한 배려에 감동했죠.

오랜기간 사용해 본 소감을 말씀드리면 부족함을 느끼지 못할 정도로 vi가 제공하는 대부분의 기능을 사용할 수 있습니다. 최근에는 Eclipse + CDT + viPlugin을 사용하여 파싱 기반의 정확한 assist를 받으면서 vi의 기능을 활용하여 작업을 수행하고 있습니다.

맥미니, 맥북, 아이맥 사이에서 방황하다 결국 미친척 하고 아이맥 24인치를 구입해 버렸습니다! 회사에 들어온 이후로 제 자신에게 가장 큰 선물이 되겠네요. ^^; 다소 성급한 구매였지만 몇일 사용해본 결과 매우 만족스럽습니다. 


작년에 맥북을 사용했던 전력이 있기 때문에 mac osx에 금방 익숙해 질 수 있었습니다. mac osx의 사용자 인터페이스가 워낙 훌륭하기 때문이기도 하겠죠. 넓고 선명한 화면도 훌륭하지만, 가장 만족스러운 부분은 소음이 거의 없다는 것입니다. 얼마전에 처분한 조립PC는 정말 시끄러웠거든요! 컴퓨터로 음악을 듣는게 바보스럽게 느껴질 정도로...

Objective-C 공부 후에, mac 어플리케이션 혹은 iPhone/iPod Touch 어플리케이션을 개발해보려고 합니다. 어느정도 진행이 되면 블로그에 관련 글을 쓸 수 있겠죠. ^^

decNumber Library(http://speleotrove.com/decimal/)를 사용하는 코드에서 Call stack을 깨먹는 버그가 발생하여 지난 일주일동안 마음이 편치 않았는데, 결국 해결했습니다! 워낙 사소한 실수에서 비롯된 일이라 부끄럽기 그지 없지만, 유사한 버그로 머리를 쥐어뜯고 있을 누군가에게 도움이 될지도 모른다는 바램을 가지고 용기를 내어 보겠습니다!

Call stack을 깨는 코드는 다음과 같습니다.
void evaluate_arithmetic_expression(decNumber *r, ezArithmeticExpression *expr) { decNumber left; decNumber right; evaluate_expression(&left, expr->left); evaluate_expression(&right, expr->right);
이 함수가 호출되면 sementation fault가 발생하면서 프로그램이 죽는 현상이 발생했습니다. gdb에서 bt를 실행해보니 call stack이 깨졌다는 사실을 알 수 있었습니다. 곰곰히 생각해보니 로컬변수에 값을 쓰다가 activation record의 return address 영역을 엎어 쓰는 것 같더라구요. 이를 확인하기 위해 left 변수 앞에 임의로 char buf[100]; 변수 선언을 넣었더니 call stack이 깨지는 현상은 사라졌습니다.

decNumber 라이브러리를 사용하여 실제 계산을 수행하는 코드는 다음과 같습니다.
// example1.c -- convert the first two argument words to decNumber, // add them together, and display the result #define DECNUMDIGITS 34 // work with up to 34 digits #include "decNumber.h" // base number library #include <stdio.h> // for printf int main(int argc, char *argv[]) { decNumber a, b; // working numbers decContext set; // working context char string[DECNUMDIGITS+14]; // conversion buffer if (argc<3) { // not enough words printf("Please supply two numbers to add.\n"); return 1; } decContextDefault(&set, DEC_INIT_BASE); // initialize set.traps=0; // no traps, thank you set.digits=DECNUMDIGITS; // set precision decNumberFromString(&a, argv[1], &set); decNumberFromString(&b, argv[2], &set); decNumberAdd(&a, &a, &b, &set); // a=a+b decNumberToString(&a, string); printf("%s + %s => %s\n", argv[1], argv[2], string); return 0; } // main
여기서 눈여겨 보아야 할 것은 DECNUMDIGITS라는 상수(constant)입니다. 항상 decNumber를 사용해 계산을 수행하기 위해서는 decContext를 설정해서 전달해 주어야 하는데 이때 DECNUMDIGITS을 참조하게 되죠. 이 값을 별도로 설정하지 않으면 decNumber.h에서 1로 설정하기 때문에 정상적인 연산을 수행할 수 없습니다.

따라서 decNumber로 표현 및 계산하고자하는 최대 자리수를 #define으로 미리 지정해 주어야 합니다.  문제는 여기에 있었습니다. decNumber를 사용하여 계산하는 함수를 따로 분리하는 과정에서 decNumber.h를 include 하는 문장 뒤에 #define DECNUMDIGITS를 포함하는 헤더파일의 include 문장이 존재하게 되었던거죠! 결과적으로 decNumber.h가 확장될때는 DECNUMDIGITS가 기본값인 1로 결정되고, 제가 작성한 코드에서는 프로젝트 전역 헤더파일에서 정의한 값(30)이 참조되었습니다. 변수와 정의와 변수의 참조 사이에 괴리(?)가 발생했던 겁니다. 

decNumber.h를 살펴보면 문제는 좀 더 명확해 집니다.
#if !defined(DECNUMDIGITS) #define DECNUMDIGITS 1 #endif /* The number of units needed is ceil(DECNUMDIGITS/DECDPUN) */ #define DECNUMUNITS ((DECNUMDIGITS+DECDPUN-1)/DECDPUN) /* The data structure... */ typedef struct { int32_t digits; /* Count of digits in the coefficient; >0 */ int32_t exponent; /* Unadjusted exponent, unbiased, in */ /* range: -1999999997 through 999999999 */ uint8_t bits; /* Indicator bits (see above) */ /* Coefficient, from least significant unit */ decNumberUnit lsu[DECNUMUNITS]; } decNumber;
decNumber.h를 include하는 문장 앞에 DECNUMDIGITS을 정의한 프로젝트 전역 헤더파일을 include하도록 수정함으로써 문제는 간단히 해결되었습니다. 대부분의 버그가 비슷하겠지만, 문제를 찾아서 해결하고 나니 참으로 허무한 기분이 들었습니다. 한동안 제 자신이 미워지더군요. ^^;

이번 경험을 통해 얻은 교훈은 다음과 같습니다.

1. macro 사용에 유의하자.
2. 헤더파일의 include 순서에 유의하자.
3. call stack을 깨는 경우는 문자열을 비롯한 array의 잘못된 사용 및 참조로 발생하는 경우가 많다.

저희팀(TmaxSoft, Compiler팀)은 컴파일러를 개발하고 있습니다. 컴파일러를 개발하다보면 코드의 수정 혹은 추가로 인해 기존에 잘 되던 것이 잘 안되는 문제가 빈번히 발생합니다. 언어를 처리하는 프로그램의 특성상 상호의존적인 코드의 비중이 높기 때문이죠.

그런 까닭에 "실용주의 프로그래머"에서도 강조하는 회귀 테스트가 정합성을 생명으로하는 컴파일러의 개발과정에서 빼놓을 수 없는 영역을 차지하게 됩니다. 

저희팀에서 컴파일러 혹은 인터프리터의 개발과정에서 사용하는, Ruby로 작성된 회귀 테스트 장치(regression test harness) 코드는 다음과 같습니다. (Ruby의 맛만 살짝 본 상태에서 제가 작성한 조악한 코드지만, '이런식으로 회귀 테스트를 하기도 하는구나!' 정도로 이해해주시면 좋겠네요.)
ezext = "ezt" nameArray = Array.new failArray = Array.new # read list File.open("list.txt") do |file| while name = file.gets if (File.exist?(name.chomp + "." + ezext)) nameArray.push(name.chomp) else puts "file #{name.chomp}.#{ezext} not found!" end end end # run nameArray.each do |name| cmd = "ezp -i #{name}.#{ezext} > #{name}.tmp" puts cmd stdout = `#{cmd}` cmd = "diff #{name}.tmp #{name}.out" stdout = `#{cmd}` if not stdout.empty? failArray.push(name.chomp) end end # report puts if failArray.size() == 0 puts "regression test success!" else puts "regression test fail!" puts "---------------------" puts "total : #{nameArray.size()}" puts "fail : #{failArray.size()}" puts puts "fail list" puts "---------------------" failArray.each do |name| puts "#{name}.#{ezext}" end end # remove tmp files `rm *.tmp`
컴파일러나 인터프리터가 제대로 동작하는지 확인하는 가장 간단한(?) 방법은 소스코드를 사용하여 예상대로 동작하는지 확인하는 것 입니다. 일반적인 경우에는 standard output(이하 stdout) 결과를 보고 이상유무를 파악합니다. 기본적인 아이디어는 여기서 정리하고 본론으로 들어가자면...

여기서 소개한 회귀 테스트를 위해서는 2가지 작업이 선행되어야 합니다.

1. 회귀 테스트에 포함시킬 예제 파일의 이름(확장자 제외)을 list.txt에 추가 (newline으로 여러개의 파일구분)
2. 정상 동작할때 stdout을 filename.out 파일에 저장 (e.g. ezp -i filename.ezt > filename.out)

회귀 테스트 과정은 다음과 같습니다.

1. list.txt에서 테스트 할 파일 이름을 추출하여 nameArray에 저장, 이 때 존재하는 파일인지 확인
2. ezp 인터프리터 실행하여 stdout을 filename.tmp에 저장
3. diff로 정상 동작시 결과 filename.out과 현재 실행 결과 filename.tmp를 비교
4. diff의 stdout이 비어 있으면 테스트 성공! 비어있지 않으면 failArray에 추가
5. 회귀테스트 결과 출력

저희팀에서는 (당연한 이야기겠지만) 저장소에 commit하기 전에 회귀 테스트를 통과하는 것을 정책적으로 강제하고 있습니다.

Code::Blocks는 윈도우, 리눅스, 맥 환경을 모두 지원하는 오픈소스 C/C++ 개발 환경입니다.

http://www.codeblocks.org/

리눅스나 유닉스를 기반으로 하는 맥의 경우 C 프로그래밍 환경을 쉽게 갖출 수 있지만, 윈도우의 경우 로컬 시스템에 C 프로그래밍 환경을 마련하기가 애매한 것 같습니다. 윈도우를 위한 gcc환경인 MinGW를 직접 설치해야 하죠.

윈도우 환경에 Code::Blocks를 설치하는 경우 codeblocks-8.02mingw-setup.exe 파일을 다운받아 실행하시면 MinGW가 함께 설치되고 Code::Blocks의 기본 컴파일러로 등록이 됩니다. 별도의 설정없이 바로 프로젝트를 생성하고 빌드하고 실행할 수 있는 환경을 마련할 수 있습니다.

IDE 자체도 훌륭합니다. function outline, folding, debug, syntax highlighting 등등 IDE가 갖추어야 할 기본적인 기능은 모두 포함하고 있습니다. 윈도우에 C 프로그래밍 환경을 마련하고자하는 분들에게 Code::Blocks를 추천하고 싶네요.

iTunes로 음악을 정리해 듣다 보면 앨범 사진까지 깔끔하게 입혀 놓고 싶은 욕심이 들때가 많다. 작은 이미지를 구하는 것은 그리 어렵지 않지만, iTunes의 Cover Flow를 사용해도 볼만할 정도의 큰 이미지를 구하기는 녹녹치 않았다.

지금까지 사용하던 방법은 에반레코드(http://www.evan.co.kr/)에서 해당 앨범을 찾은 후, 플래쉬 화면을 캡춰하여 앨범 사진으로 사용했는데 정확히 자르기도 어려울 뿐더러 여간 불편한게 아니였다.

오늘 우연히 에반레코드의 데이터베이스를 이용해 앨범 사진을 쉽게 얻을 수 있는 사이트를 발견했다.

커버.즐즐넷
http://cover.zzlzzl.net/

이 곳에서는 손쉽게 정말 커다란 앨범 사진을 얻을 수 있다. 특히나 웬만한 클래식 앨범을 모두 찾을 수 있다는 점이 매력적이다. iTunes의 경우 사이트에서 찾은 이미지를 drag and drop으로 음악파일에 입력할 수 있어 매우 편리하다.

추가로 추천하고 싶은 사이트는,

maniadb
http://www.maniadb.com/

커버홀릭
http://www.coverholic.com/


고해상도 앨범 사진으로 음악파일을 정리한 덕분에 음악을 듣는 즐거움에 보는 즐거움이 더해졌다. ^^

맥북을 사서 즐겁게 사용하다 팔아치운지 벌써 1년이 넘었다. 메인 PC로 사용하기에는 국내 웹환경이 옳지 않아서 아쉬움을 뒤로 하고 맥라이프를 접었었는데, 요즘에는 다시 맥을 사용하고 싶은 마음이 굴뚝같아서 전전긍긍하며 지내고 있다. 레오파드도 한번 써보고 싶고, 아이폰 SDK로 어플리케이션 개발도 해보고 싶고...

그래도 가능하면 돈을 굳혀 보려고, 
우분투를 설치해 리눅스에 정을 붙여 보려고 애를 써보기도 하고...
회사에 남는 PC에 해킨토시를 설치해 보기도 하고...
나름 애를 써보았으나 맥에 대한 욕망을 접기가 녹녹치 않았다.

그리하여 싸게 맥을 구할 수 있는 방법을 고민해 보았다. 괜찮아 보이는 중고 맥미니를 사려 했는데, 연락해보니 이미 팔렸고, 새제품을 사자니 성능에 비해 비싸기도 하고, 기왕이면 아이맥으로 가자 싶기도 하고...

이래저래 찾아 다니다 애플 사이트에서 리퍼 제품을 저렴하게 구입할 수 있다는 것을 알게 되었다. 12시에서 2시 사이에 갑자기 떴다가 사라진다는...

오늘 점심 먹고 돌아와 티베로데이 관련 기사를 읽다가 심심해서 링크를 열어보니 리퍼제품이 떠있었다!
http://store.apple.com/kr/browse/home/specialdeals/mac?mco=MTE3NjY


부랴부랴 아이맥 20인치 제품을 장바구니에 넣고 결제를 시도했다! 그러나 현대카드 안심클릭 사이트에 접속이 잘 안되서 살짝 버벅거리는 사이에 물건은 안드로메다로... 오호 통제라...

절호의 기회를 놓치다니... 앞으로 매일 점심시간마다 긴장해야 하나...

집에서 회사일 및 알고리즘, 프로그래밍 공부를 해볼 요량으로 오랜만에 리눅스를 설치해 보았다. iptime 무선 랜카드 G054U-A를 사용하는 환경이라 이를 리눅스에서 동작하게 하기 위해서는 엄청난 삽질이 뒤따를 것을 감안하고 Ubuntu 8.10을 설치했는데, 놀랍게도 아무런 설정없이 바로 무선랜 카드를 사용할 수 있었다!

더욱 놀라운 것은 파티셔닝을 하지 않고 윈도우 파티션 내부에 가상 파일시스템을 구축하여 우분투를 설치할 수 있게 되었다는 것! 단 이때는 파일 시스템의 성능이 다소 저하될 수 있으며 Hibernation 기능을 사용할 수 없다. 그러나 이와 같은 방식으로 설치하고 사용해본 결과 눈에 띌만한 성능의 저하는 느낄 수 없었다. 간단히 윈도우에서 uninstaller를 실행하는 것으로 깔끔히 리눅스를 제거할 수 있다는 점도 상당히 매력적이다.


Ubuntu studio 테마를 설치하고, 네이버에서 받은 나눔고딕을 사용하도록 설정하니 윈도우보다 더 보기좋은 UI가 완성되었다! 회사 컴퓨터에도 설치해볼 계획인데, 부디 듀얼모니터 설정도 별다른 삽질 없이 마법처럼 되었으면...

필자는 국민학생이던 아주 어린시절부터 컴퓨터를 다루어오면서, 컴퓨터 및 주변기기에 대한 관심이 많은 편이였다. 게임을 하기위한 조이스틱에서부터 스캐너, 프린터, Zip 디스크 등등. 그 중에서도 프린터는 단연 나의 소유욕을 불러 일으키는 매력적인 물건이였음에도 불구하고, 부모님은 그다지 필요가 없다(?)는 이유로 사주시지 않았었는데...

바야흐로 시간은 흘러 우리가 접하는 수 많은 정보가 컴퓨터로 전달되는 문화속에 살고 있는 우리에게 프린터는 없어서는 안될 물건이 되었다. 더군다나 아직도 모니터 보다 종이로 글을 읽는게 훨씬 편안한 촌스러운 나에게는 더더욱...  이번 cp1215 이벤트 덕분에 난생 처음으로 나만의 첫 프린터를 가질 수 있게 되었다. 그 것도 컬러레이저젯 프린터! 지금부터 컬러레이저젯 프린터 cp1215의 외형, 소프트웨어, 출력 속도, 사진 인쇄 품질, 아쉬운 점 등을 차례로 살펴 보도록 하자. 

1. 외형 및 소프트웨어

워낙 cp1215가 컬러레이저젯 프린터 치고는 작은 크기를 자랑한다고 하여, 굉장히 작을 것으로 생각했으나 아쉽게도 설치 기사분이 설치할 때, 첫인상을 보니 생각보다는 제품이 컸다. ^^; 앞뒤로 길이는 회사에서 사용하는 HP 레이저젯 프린터와 비슷한 것 같았다. 대략 데스크탑의 길이 정도?

cp1215의 다지인은 개인적으로 참 마음에 든다. 간결한 디자인은 자주 보아도 질리지 않는다. 사용자 인터페이스도 매우 단순해 토너를 교환할 때, 종이가 걸렸을 때, 종이를 넣을 때 프린터를 여는 것이 전혀 부담스럽지 않았다. 한번은 프린터 위에 가방을 올려놓고 인쇄버튼을 눌러 종이가 걸린 적이 있었는데, 뒷 뚜껑을 열어 손쉽게 문제를 해결할 수 있었다.

컬러를 위한 3개의 토너와 흑백을 위한 하나의 토너가 각 색깔별로 분리되어 장착되어 있다. 각 토너의 가격은 색상마다 다른데 인터넷 최저가로 현재(2008년 10월) 4만원에서 6만원 정도 사이에서 구매할 수 있다. 각 토너당 대략 700장 + alpha 정도의 인쇄가 가능하다고 소프웨어는 안내해 준다.

펌웨어를 두번 업데이트 했음에도 불구하고 특정 카트리지의 잔량을 제대로 체크하지 못하는 점은 제품의 완성도 측면에서 상당히 아쉬움을 남겼다. 사용하는데 크게 문제가 되는 부분은 아니지만 이번 컬러체험단 이벤트를 통해 차후 양산되는 모델들은 이런 문제가 없기를 바란다.

HP가 제공하는 소프트웨어를 살펴보자. 먼저 HP Toolbox는 도움말과 장치의 상태를 상세히 제공하며, Toolbox에서는 전문가 만이 건드릴 법한 장치의 세부 설정이 가능하다. 소프트웨어의 UI는 그저 평이한 수준. 조금 더 신경썼으면 좋았을 것 같다.

이번에는 프린터 인쇄속성 창을 살펴보자. 그동안 HP 프린터를 사용해본 사람이라면 매우 익숙한 화면을 볼 수 있다. 이 리뷰를 작성하다가 처음 발견한 사실은 수동 양면 인쇄가 가능하다는 것!

2. 인쇄속도

장치를 켜둔 상태에서 흑백/컬러 인쇄 작업을 프린터에 보낸 경우 몇 초가 걸리는지 실험해 보았다. 익스플로러 8.0에서 네이버 첫화면을 한번은 흑백으로 한번은 컬러로 출력하면서 출력 시간을 비교해 보았다.

<흑백>
인쇄버튼을 누른 후 종이가 나오기 시작한 시간 : 22초 10
끝까지 인쇄가 완료된 시간 : 25초 98

<컬러>
인쇄버튼을 누른 후 종이가 나오기 시작한 시간 : 25초 81
끝까지 인쇄가 완료된 시간 : 32초 02

흑백을 먼저 인쇄하고 몇 분 후에 컬러를 인쇄했는데 약간 예열의 효과가 있을 지도 모르겠다. 개인적으로 첫 페이지를 출력하기까지의 소요시간은 이정도면 무난하다고 생각한다. 한달 넘게 제품을 사용했지만 아직까지 출력 시간때문에 답답함을 느껴본 적은 없는 것 같다.

3. 사진 출력

일반적인 용도의 인쇄 결과물은 더할나위 없이 훌륭했다. 일하다가 마주치는 pdf 문서나 스프링노트에 정리한 것, 때로는 피아노 악보를 인쇄해 보았을때 그 선명함은 완벽했다. 더 이상의 기술력이 필요 없다는 생각이 들정도로...

그래서 이 리뷰에서는 컬러레이저젯 프린터를 가졌다면 누구나 한번쯤 시도해 보고 싶어 할 것 같은, "사진 출력"을 주제로 잡아 보았다. 여행 중에서 찍은 특징적인 3장의 사진을 뽑아 모니터로 보이는 실제 사진과 인쇄 결과물을 비교하는 방식으로 리뷰를 진행하였다.

사용한 용지는 흔히 구할 수 있는, 일반적인 용도로 사용되는 Double A 80gsm. 이다. 일반 A4 용지에 컬러레이저젯 프린터로 어느정도 수준의 사진 인쇄물을 얻을 수 있는지 알아보도록 하자.

첫번째 사진의 주제는 '음식'이다. 음식 고유의 빛깔과 질감을 제대로 표현해 주는지 확인해 보고 싶었다.

김치에 묻어 있는 고추가루의 디테일 까지는 완벽하게 표현 하지 못했으나 대체로 무난하게 음식이 주는 느낌을 그대로 인쇄물에서 얻을 수 있었다. 다만 한가지 아쉬운 것은 색감이 모니터로 보는 것 보다 다소 어둡다는 것.

두번째 사진은 채도가 극명하게 대비되는 사물들이 많은 사진이다. 채도가 높은 사물들을 출력해 보았을 때 어떤 결과물을 얻을 수 있을까 궁금하여 이 사진을 선택하게 되었다. 파리에 어느 잡화점에서 찍은 사진!

이 사진을 프린트 할때 회사 동료가 옆에서 지나갔는데, 결과물을 보고 감탄을 자아냈다! 빠른 시간에 이 정도의 훌륭한 결과물을 얻을 수 있다는 것에 놀랐던 것이다. 오밀조밀한 사물들을 선명하게 표현하고 있어 결과물은 대체로 만족감을 준다. 그러나 역시나 색감은 모니터로 보는 것과 다소 차이가 있었다. 앞의 사진과 마찬가지로 다소 진하게 표현되는 경우가 많았다. 그리고 사진의 어두운 영역은 더 어두워 지면서 디테일을 다소 잃어버리는 느낌을 주었다.

마지막으로 풍경사진을 살펴보자.

전체적으로 멀리서 보면 역시나 색감의 차이가 있을뿐 무난한 결과물을 얻을 수 있다. 그러나 DSLR로 찍은 풍경사진의 묘미는 선예도에 있는데, 컬러레이저젯 프린터로 그 선예도 까지 표현해 내길 기대한다는 것은 다소 무리가 있는 것 같다. 디테일을 살펴보자.

나무와 논의 경계 부분이 사진과 확연히 차이를 확인할 수 있을 정도로 조악하게 표현되었으며, 나뭇잎 부분은 워낙 세밀한 부분이라 그런지 약간 어색한 느낌을 주었다.

색감이나 디테일 면에서 약간 아쉬움을 남겼으나 예전에 컬러 잉크젯 프린터를 사용해본 경험을 비추어 보면 상당히 만족스러운 결과물을 안겨주었다. 색감 문제는 모니터 설정의 문제일 수도 있을 것 같고, 사진 전용지를 사용하게 되면 색감이나 디테일 면에서 훨씬 좋은 결과물을 얻을 수 있을 것이다. 컬러레이저젯 프린터의 고질적인 색감문제는 차차 보완되어 언젠가는 보급형 컬러레이저젯 제품에서도 원본과 동일한 색감의 결과물을 얻을 수 있기를 기대한다.

4. 아쉬운 점

컬러 + 흑백 토너 한 세트의 가격이 프린터의 가격과 맞먹는다. 재생 토너의 유혹을 느끼지 않을 수 가 없는데... 업무용으로 사용하기에는 경제성이 다소 떨어지는 것 같다. IT 업계에서 일하는 필자는 20페이지를 훌쩍 넘는 문서를 종종 인쇄하곤 하는데  4~5만원 하는 하나의 흑백 토너로 700여장 밖에 찍을 수 없다는 것은 많이 아쉬움을 남긴다.  

인쇄를 마치고 몇분 후에 소음을 발생시킬때가 있다. 트레이 아이콘에 마우스를 가져가보면 보정 중이라는 메세지가 뜨는데, 보정 작업이 끝난 후에도 1, 2분 더 소음이 발생한다. 사무용이라면 크게 문제 될 것은 없겠지만 컴퓨터 작업을 끝낸 후에도 가끔 프린터가 소음을 내는 것은 가정용으로는 조금 아쉬운 부분이다.

5. 총평

만약 필자가 필요해 의해 컬러레이저젯 프린터를 구매해야 하는 상황이였다면 아마도 cp1215를 심각하게 고려해 보았을 정도로, 디자인, 가격, 스펙, 성능 모두 훌륭한 제품이라고 생각한다. 프린터 제품에서 HP의 인지도와 명성은 충분히 신뢰를 주고 있으며, 이번 cp1215 제품 리뷰로 인해 그 신뢰가 더욱 굳건해 진 것 같다. 

문서 인쇄, 웹 페이지 인쇄 등등 업무나 생활에서 자주 활용되는 용도로서 cp1215는 최적의 선택이라 생각한다. 더이상 바랄 것이 없을 정도로 선명한 결과물을 빠른 시간에 얻을 수 있으니... 다만 사진 출력시에 색감 문제는 다소 아쉬움을 주었는데, 가까운 내일에는 보급형 컬러레이저젯 제품으로도 사진의 그대로 색감을 표현할 수 있었으면 하는 바램을 가져본다.

회사에서 삼성컴퓨터를 새로 지급받았는데, 정품 비스타 DVD가 있길래, XP를 밀어 버리고 비스타를 설치해서 사용하고 있다. 리눅스 배포판만 수십가지 종류를 설치해서 사용해 보았고, OS/2 Warp까지 도전해 봤을만큼 OS에 대한 호기심이 큰 편이라 비스타 DVD를 그냥 지나칠 수 없었다.

프로세서: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
메모리(RAM): 4.00GB

비스타를 쓰기에 전혀 무리가 없는 환경이라 xp보다 느리다는 느낌은 전혀 못 받고 있고, 개인적으로 깔끔한 GUI에 만족하면서 사용하고 있다. 차기 OS임에도 불구하고 막상 사용해보니 별로 달라진 것이 없어서 당황스럽기도 하지만... 

Active X를 설치할 때 마다 깜빡이는 화면을 보면서, 부디 우리나라 웹환경에서 하루 빨리 Active X가 사라지길 간절히 바라는 마음을 가지게 된다. Active X가 완전히 사라진다면 다시 맥으로 돌아갈 수 있을텐데...

이클립스는 JDT라는 자바개발환경을 포함하고 있습니다. 그리고 JDT는 자바개발과 관련하여 다양한 기능을 제공(e.g. Code Formatting)하기 위해 자바파서와 AST를 내장하고 있습니다. 따라서 이 부분을 잘 뜯어서 사용하면 훌륭한(!) 자바 파서를 공짜로 얻는 셈이 되는 것이죠.

앞으로 몇부에 걸쳐 JDT에 내장된 자바파서와 AST를 활용할 수 있는 방법을 설명하려고 합니다. 1부에서는 AST의 구조를 파악하는데 도움이 되는 ASTExplorer를 실행해보도록 하겠습니다. 이 과정에서 개발환경을 설정(e.g. 클래스패스 설정)하는 방법도 함께 다루겠습니다. 질문은 덧글로 남겨주세요.

올초에 빠른 시간안에 자바 코드 읽어 다른 형태의 코드로 변환하는 프로그램을 개발해야 했는데, 여러가지 방법을 찾아 고민하던 중에, JDT에 내장된 자바파서를 활용방안을 다룬 다음 웹문서를 발견하게 되었습니다.

Exploring Eclipse's ASTParser

이 문서에서 ASTExplorer라는 예제 프로그램을 다운 받을 수 있는데, 이클립스 v3.02를 기준으로 하고 있어 다른 버전의 이클립스에 이 프로젝트를 import 하는 경우, 클래스패스에 추가된 JDT 라이브러리의 경로와 이름이 달라 에러가 발생합니다.

이 문제를 해결하는 가장 쉬운 방법은 클래스패스에 등록된 라이브러리를 지우고, eclipse\plugins에 존재하는 라이브러리를 클래스 패스에 추가하는 것입니다만 불필요한 라이브러리가 많이 추가되겠죠?

제가 사용하는 User Library를 첨부합니다. (이클립스 v3.3.1.1 기준) User Libraries에서 Import 하시면 됩니다.


첨부한 User Library를 클래스패스에 추가하셔도 JDT 버전이 올라가면서 변경된 부분 때문에 컴파일 에러가 발생할 것 입니다.

ASTMain.java의 다음 2라인의 코드를


다음과 같이 수정해 주시면 컴파일 에러가 해결됩니다.


ASTMain.java와 ASTExplorer.java 모두 main 메서드를 가지고 있습니다. ASTMain.java의 코드를 읽어보면 AST를 생성하는 작업을 정의하고 있는데, JDT 버전이 달라서 그런지 Exception이 발생하며 제대로 실행되지 않습니다.

ASTExplorer.java의 경우 실행에 문제가 없습니다. 실행해 보시면 다음과 같은 화면을 보실 수 있습니다.


이 프로그램은 JDT 내장 자바파서가 생성하는 AST 객체의 구조를 한눈에 파악할 수 있도록 화면 왼쪽에 AST의 구조를, 화면 오른쪽에 소스코드를 보여줍니다. AST에 익숙하지 않은 경우에 큰 도움을 주는 프로그램이죠.

AST에 대한 API Reference는 이클립스의 Help Contents에서 찾아 볼 수 있습니다. 웹에서 확인하고 싶으신 경우 다음 URL을 참조하세요.

http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.jdt.doc.isv/reference/api/org/eclipse/jdt/core/dom/package-summary.html

1부에서는 간단히(?) JDT에 포함된 파서와 AST를 활용한 ASTExplorer를 실행해 보았습니다. 2부에서는 자바소스코드를 읽어 AST를 얻는 방법에 대하여 설명하겠습니다. (물론 ASTExplorer 소스코드를 읽어보시면 쉽게 이해하실 수 있겠습니다만... ^^;)

팀원 4명이 함께 진행하던 프로젝트를 몇 일전부터 혼자 담당하게 되었다. 업무의 인수인계 후에 살펴보니 코드리뷰 한번 없이 각자 개발한 코드는 동일한 기능이 비효율적으로 중복되어 있는 구조를 가지고 있었다. 그리고 언어를 다루는 프로그램의 특성상 언어의 의미(Semantic)은 엄밀히 지키면서 동작해야 하는데 그렇지 않았다. 내가 작성했던 코드 역시 마찬가지...

적절히 책임감이 분산되었던 함께하는 코딩과 혼자 모든 책임을 짊어지고 하는 코딩은 다르지 않아야 하는데 달랐던 것 같다. 마치 범죄 현장을 목격하고 아무도 신고 하려하지 않았던 다수의 대중들처럼...

실장님은 거의 완성된 것으로 보고 계시지만, 실제로는 그렇지 않은 상황에서 적절한 타협점을 찾기 위해 나에게 약간(?)은 버겁지만 실장님도 받아들일만한 프로젝트 예상일정을 보고했고 그로 인해 조금(?)은 조바심을 느끼면서 일을 홀로 진행하고 있다.

4명이 함께 프로젝트를 진행하면서, 코드가 비효율적으로 작성되어가고 있음을, 언젠가 한번은 이러한 비효율적이고 명확하지 않은 구조 때문에 더 큰 비용이 발생할 수 있음을 예상하고 있었지만 일개 팀원으로서 어떤 조취를 취하는 것은 영 부담스러웠다.

어려움에 처하긴 했지만, 거대한 코드를 내가 원하는 모습으로 마음껏 리펙토링 하고 하나의 작품을 만들어 가듯 아름답게 꾸미는 작업을 마음껏 할 수 있다는 것이 즐겁다.

1년 정도 회사에서 소프트웨어를 개발해보니 소프트웨어를 개발의 가장 큰 어려움은 기하급수적으로 증가하는 복잡도(Complexity)를 관리하는 것이 아닐까 하는 생각이 든다. 언젠가 팀장이 되어 프로젝트를 관리하는 입장이 되기전에 많은 경험과 많은 생각으로 충분한 역량을 쌓아 두어야겠다는 생각이 든다. 때문에 이번 프로젝트는 나에게 도전이자 기회다.

작업환경을 완전히 리눅스로 옮겼다. 윈도우 컴퓨터에서 Putty로 셀레론 컴퓨터에 접속해서 GCC를 컴파일 하며 작업하다 듀얼 코어 컴퓨터에 리눅스를 설치하고 직접 컴파일 하니 속도가 2배 가까이 향상 된 듯한 느낌을 준다. 게다가 우분투 7.10은 설정하고 사용하기가 정말 편리하다.

빨간색을 좋아하다 보니 입맛에 맞게 글꼴과 테마를 수정했다. 그럭저럭 마음에 드는 개발 환경을 마련하는데 성공! 출근해서 저녁먹을때까지는 리눅스 환경에서 업무에 집중하자!

펄, 파이선, 루비 등의 스크립트 언어 중에 하나 정도는 알아 두는게 편할 것 같다는 생각에 이번 달에는 루비를 공부하고 있다. 책의 절반을 쭉 읽어 나가면서 코드는 한번도 작성한 적이 없었지만 언어가 간결해서 그런지 몰라도 쉽게 원하는 코드를 작성할 수 있었다.

지금 진행하고 있는 프로젝트는 코볼 컴파일러의 개발인데, 컴파일러가 생성한 코드가 정확한가를 확인하는 가장 쉬운 방법은 기존의 컴파일러가 생성한 코드와 수행 결과(stdout)을 비교하는 것.

지금까지는 급한 마음에 두 실행파일을 번갈아 실행하며 눈으로 수행결과를 비교했는데, "실용주의 프로그래머"를 보면 테스트를 포함한 프로젝트 빌드의 전과정을 자동으로 수행할 수 있도록 할 것을 강조하고 있다.

그리하여 고즈넉한 저녁에 잠깐의 짬과 약간의 용기를 내어 처음으로 루비를 사용해 간단한 test harness를 작성해 보았다.


컴파일러가 생성한 코드의 수행시간 역시 컴파일러를 평가하는데 중요한 이슈이므로, 두가지 컴파일러가 생성한 코드의 수행시간을 자동으로 비교해 주는 프로그램을 루비로 간단히 작성하는 것도 큰 의미가 있을 것 같다. 사용하기 쉬운 루비 언어를 조금 더 연습해서 프로젝트의 여기저기에 잘 활용한다면 생산성을 향상 시킬 수 있을 것이다.