IdeA thinKING

진정한 프로, 최고의 아키텍트 류춘수 선생님 프로는 작품으로 말한다 라는 말이 너무 와닿습니다. 물론 작품을 만들기 위한 과정이나 태도도 모두 프로다워야 하겠죠. 유난히 저의 회사 생활에 대해 반성이 되더군요. 올해를 돌아보고 내년 계획을 세우고 있는데 올해는 쌍둥이들이 태어나서 잘 커준 것 외에는 개인적인 전진이 없었던 것 같습니다. 내년 계획을 세울때 이 말이 많은 도움이 될 것 같네요.

이전 To be better programmer 글은 Visual Studio는 IDE(Integrated Development Environment)로써 너무 많은 작업을, 잘못된 방법으로, 개발자를 위해 하기 때문에 better programmer가 되는데 방해가 된다라는 내용이었습니다. Emacs도 하나의 환경에서 코딩, 컴파일, 디버깅, auto indentatation, diff, merge, shell 작업등을 모두 할 수 있기 때문에 IDE라고 할 수 있습니다. 하지만 emacs는 better programmer가 되는데 도움이 됩니다.(물론 제 생각에) 둘 사이에는 어떤 차이가 있을까요. 가장 큰 차이는 emacs는 개발자가 원하는 것, 필요로 하는 것 이상의 작업은 하지 않는다가 아닐까 합니다. Emacs는 뒤에서 개발자 몰래 무엇인가를 하지 않습니다. 또한 원하지 않는 작업을 짐작해서 수행하여 주지도 않죠. ((가장 좋은 예가 Microsoft Word의 첫글자 대문자로 만들기 기능이 아닐까 싶네요. 매번 Ctrl+z를 누르게 만드는.)) 다르게 말해, emacs는 개발자 손의 확장이 되려고 하지만 Visual Studio는 개발자 머리의 일부가 되려고 하는 것 같다고나 할까요? 따라서 개발자로서 emacs는 그냥 사용하면 되지만 Visual Studio와는 같이 작업을 해야 합니다. 살살 달래가며 말이죠. :-)

Does Visual Studio Rot the Mind? , Charles Petzold 벌써 일년도 넘은 글인데 이제야 보게 되었습니다. 저자는 Visual Studio의 IntelliSense나 Code Generation, Interactive Design과 같은 도구들이 우리를 faster programmer로 만들어주기는 하지만 better programmer로 만들어준다고 생각하진 않는다고 얘기합니다. 또한 덕분에 우리의 노동력을 싸게 만든다고. :-( 스스로의 경험으로 100% 공감 가는 얘기더군요. 제대하고 회사에 입사하기 전에는 주로 Windows NT상에서 프로그래밍을 했었습니다. 물론 그전엔 DOS였고 Windows 95가 나오던 시기엔 군대에 가 있었죠. 군대에서 몰래 구해 읽었던 책이 Inside Windows NT 초판이었는데 너무 멋진 내부 디자인설명에 NT를 최고의 OS로 생각했습니다. ((운전병이어서 몰래 책도 읽을 수 있었습니다. :-) )) 마침 연구실에서 제가 하던 프로젝트들도 거의 NT 기반이었죠. 이 당시엔 거의 못하는 것이 없었습니다. MFC(Microsoft Foundation Class), COM(Component Object Model), DCOM(Distributed COM), ATL(Active Template Library), ActiveX에 NT device driver까지. NT 내부에 대해서도 누구보다 많이 안다고 생각했습니다. 심지어 이땐 Visual C++ 6의 에디터가 너무 손에 익어 일반 text 파일을 편집할 때도 썼을 정도입니다. 그러다 회사에 들어와서부터는 Unix(Solaris, Linux)들을 사용하기 시작했습니다. 어느정도 익숙해지고나서 들었던 생각이 위의 Petzold의 글과 비슷합니다. 학교 다니면서 열심히 공부해서 개발했던 것들이 그저 Microsoft에서 만들어준 블록들을 조립했던 것은 아니었는지. MFC, ATL, device driver 코드들을 작성할 때 내가 했던 작...

Textpattern, 어렵군요. 일단 Feedburner and Textpattern 에서 도움을 얻어 feedburner에 연결했습니다. Sidebar랑 이것저것 만져보고 있는데 Wordpress와 비교해 봤을때 사용하기가 많이 힘드네요. 대신 내가 모든걸 제어한다는 느낌이 있는것 같습니다. 굳이 프로그래밍에 비유하자면 Textpattern은 DOS, Wordpress는 Windows에서 하는 프로그래밍같네요. 내가 시스템을 통째로 마음대로 제어하는 느낌과 OS와 나눠쓰는 느낌이랄까? :-) 하나의 예를 들자면, TatterTools에서는 "Post"를 작성할 수 있습니다. Wordpress에서는 이 "Post"에 더해서 "Page"를 제공합니다. Textpattern에서는 이런 것들을 Section이라는 개념으로 개수 제한 없이 만들 수 있습니다. 물론 각 Section별로 다른 style을 사용할 수 있고요. 물론 이런 flexibility에는 사용이 어렵다는 단점이 따른다는... OTL

이전 블로그 에서 공지했던 대로 IdeA thinKING 블로그의 주소를 blog/ 에서 이곳 blog-v2/로 옮겼습니다. Wordpress대신 Textpattern 이라는 툴을 사용합니다. 아직 익숙하질 않아 그런지 WP보다 조금 어렵다는 느낌입니다. 특히 style (skin 또는 theme) 적용하는 방법은 완전 수동이군요. :-( 좋아진 점은 이전 Wordpress의 wp-dokuwiki로 인한 무거움이 없어져 이전보다 페이지 로딩 속도가 훨씬 빨라졌다는 것입니다. :-) 그리고 작년엔 글을 쓰면서 항상 그럴듯한 프로그래밍 정보를 써야 한다는 생각이 꽉 차 있어서 글 하나 올리기가 어려웠던 것 같습니다. 덕분에 글도 길어졌고요. 그래서 올해는 조금 '가볍게' 블로깅을 해 볼 생각입니다. 이렇게 저렇게 하다보면 적당한 선이 잡히겠죠? :-)

2007년을 맞아 블로깅 툴을 변경합니다. 기존에 사용하던 Wordpress 가 사용하기에 부족한 것은 아니지만 좀 지겨워지기도 하고 계속 사용하던 wp-dokuwiki plugin 의 무게에 점점 부담도 가고 해서요. 무거운 plug-in을 쓰다보니 스킨 하나 변경하기도 쉽지 않더군요. 무엇보다 블로그의 성격을 좀 가볍게 바꿔보려고 합니다. ^^ Tattertools , MovableType 등과 비교해 보다가 결국 Textpattern 으로 결정했습니다. 결정적으로 Textpattern의 한 스킨에 들어 있던 다음글에 넘어갔습니다. ^^ , if you have been using something else such as WordPress you are just going to find TXP different . There is no getting away from that fact. It doesn't look the same, it doesn't feel the same and it certainly doesn't work in the same way. It will take time for you to get used to it, but when you do, when that penny drops, you're going to wonder why all software isn't made this well. Seriously . And also remember that TXP is a CMS. It is not pure blogging software. It can be used for all kinds of different sites, even ones that don't have blogs. Yes I know. Sounds weird eh? No blog! Textpattern에는 Wordpress나 MovableType을 포함한 몇개의 블로깅 툴에서 글을 import하는 기능이 있는데 여기서...

얼마전 VMWare에서 solaris 10을 설치하고 vmware-tools를 설치하면 네트웍이 안된다는 내용 을 쓴적이 있는데 잘못된 내용이었습니다. -_-; vmware-tools를 설치할 때 나오는 내용을 꼼꼼히 읽어보면 나오는 내용이었네요. /etc 디렉토리의 *.pcn0 파일들을 *.vmxnet0 로 mv 해주면 됩니다. 매번 리눅스에서 vmware-tools 설치하면서 엔터만 쳐대는 버릇이 들어서 내용을 읽어볼 생각을 못했네요. -_-;

이전글 에서 했던 추측은 정답과는 거리가 멀었군요. c.l.c.m. 에 올린 글의 답변을 보니 제가 stream의 state에 대한 생각을 전혀 안했었네요. -_-; 문제가 되었던 g++ 3.4.3, solaris 10-x86 환경에서는 현재 imbue되어 있는 locale로는 출력할 수 없는 character set을 만나면 state의 fail bit을 셋하게 되어 있었습니다. 이후 operation들은 현재 상태가 good()이 아니므로 모두 실패한 것이었습니다. 따라서 이전글에서 보았던 다음 코드들의 결과는 다음과 같이 다시 해석되어야 합니다. wcout wcout wcout // result aaaa wcout wcout wcout // result aaaa wcout wcout cout // result aaaa cccc "한글" 문자열 출력이 실패하면서 wcout의 state의 fail bit이 set됩니다. 따라서 이후 wcout에 대한 operation들은 모두 실패하게 됩니다. 하지만 마지막 경우의 cout은 wcout과는 전혀 다른 stream이므로 문자열이 정상적으로 출력되었던 것입니다. 결과 확인을 위해 다음 코드로 확인했습니다. wcout wcout cout cout cout wcout.clear(); wcout // result aaaa cccc 1 0 cccc 예상대로 clear()를 호출하여 state를 good() 상태로 만들어주면 다시 wcout으로도 정상적으로 출력됨을 확인할 수 있습니다. stream의 state와 cout, wcout의 관계를 생각하지 못해 전혀 엉뚱한 추측을 했었네요. 부끄럽습니다. *-_-* 추가로 "korean" locale을 imbue()해서 출력을 해보려고 했는데 지원을 안하더군요. -_- 그리고 이전 글에서 한글외의 모든 문자가 정상적으로 출력되었던 Redhat환경의 경우는 한글 출력을 할 수 없더라도 fail bit을 set하지 않아 한글외의 문자들이 정상적...

이전글 의 마지막에서 언급했던 문제는 XMLCPP 라이브러리의 문제는 아니었습니다. 정확한 이유는 아직 찾지 못했지만 내용은 대략 다음과 같습니다. C에서 각 stream들은 orientation이라는 것을 가지고 있습니다. 어떤 stream에 대해 처음 사용된 I/O 함수의 타입에 따라 그 stream은 byte-oriented나 wide-oriented가 됩니다. 일단 orientation이 적용되고 나면 다른 타입의 orientation용 I/O 함수는 적용되지 않습니다. ((C99 7.19.2.4)) 이 orientation을 바꿀 수 있는 함수는 frepoen과 fwide 두개뿐입니다. cin, cout, wcin, wcout과 같이 predefine된 C++ standard stream들은 위와 동일한 규칙을 따릅니다. 간단히 말하자면 char 버전과 wchar_t 버전의 함수들은 섞어서 쓸 수 없다는 얘기지요. XMLCPP 에서 발생했던 문제는 wcout만을 사용하는데 ascii 범위를 벗어나는 문자를 출력하면 그 문자뿐 아니라 그 이후 아무 것도 출력되지 않는 문제였습니다. 이 경우 exception도 발생하지 않고요. -_-; 다음과 같은 코드로 문제를 재현할 수 있습니다. (g++ 3.4.3, solaris 10-x86) wcout wcout wcout // result aaaa 비슷한 코드로 좀 더 시험을 해보았지요. wcout wcout wcout // result aaaa wcout wcout cout // result aaaa cccc 이 결과를 가지고 제가 해석한 원인은 다음과 같습니다. 먼저 wcout으로 L"aaaa"를 출력할때 wide-가 아닌 byte-oriented C function을 사용합니다. 이로 인해 내부 file(여기서는 stdout)의 orientation은 byte-로 셋팅됩니다. 일단 내부 file의 orientation이 byte-로 정해졌으므로 이후 모든 wcout 은 거부되고 c...

정말 오랫만에 글을 쓰네요. XMLCPP 라이브러리 만드는데 재미를 붙여서 잠시 글쓰기를 안했더니 금방 글쓰기가 귀찮아지네요. 아니면 두려워진건지도... -_-; 최근에 했던 일은 XMLCPP에 autoconf를 적용하는 것이었습니다. autoconf란 소스 코드 패키지를 다양한 Posix-like 시스템에서 build할 수 있도록 도와주는 shell script를 만들어주는 도구입니다. 보통 소스 코드로 된 패키지를 구하면 하는 configure, make, make install의 과정이 대부분 autoconf가 만들어준 것들입니다. 왠지 configure하는 패키지들은 멋있어 보여 저도 한번 써보고 싶었는데 기회가 그간 없었지요. 일단 책을 보고 따라하기 하여 뚝딱뚝딱 적용을 했습니다. 이걸 적용하는데도 꽤나 까다로웠지요. 다음은 책에 나온 예제들에는 없어 헤맨 몇가지 사항들입니다. $includedir 이 아니라 $includedir/xmlcpp 디렉토리에 헤더 파일을 install 하고 싶다. make dist시에 tests 디렉토리 밑의 *.xml 파일도 tar되어야 한다. 하지만 install되진 않아야 한다. make check시에 boost_unittest_framework으로 작성한 unit test가 수행되어야 한다. --with-iconv 옵션을 추가한다. boost 라이브러리 존재 여부를 검사해야 한다. 그래도 여기까지 작업 하고 나서 configure 실행시키면 쭈욱 올라가는 check list들을 보니 뿌듯하더군요. 이제 다음 단계로 제가 코딩한 Ubuntu 환경이 아닌 다른 환경에서도 정말 동작하는지 확인하기로 했습니다. 먼저 Redhat. 정말 다를게 없어보였습니다. 같은 리눅스라 그냥 되려니 생각했는데 make test하니 에러가 와장창 나더군요. ㅜㅜ 차이점은 gcc 버전... 검색해보니 특정 버전의 libstdc++.a 에 버그가 있더군요. fstream에 있는 버그인데 이로 인해 StreamCharDec...