KLDP에 매일 한 번 이상씩 들어오긴 하는데, 이상하게 글은 잘 안쓰게 됩니다.

예전에 활기차던 KLDP가 그립습니다.

막상 글을 쓰려니 쓸 글도 없는게 문제네요..ㅠㅠ

회사에서 일 하다가 모르는게 있어서 구글 검색을 하니, 제가 모르는 문제의 답이 제가 오래전에 쓴 KLDP의 강좌에 있는걸 보고 예전에 알았던 것을 지금은 왜 모르는가...

하는 철학적 고민을 하다 갑자기 KLDP에 글 하나 쓰고 싶어졌습니다...^^;

KLDP에 강좌를 연재한건 2008년이고 그 강좌가 OS 책으로 나온건 2009년이네요. 책이 나온지도 5년이 지났습니다. 강산이 반쯤 변했겠군요.

그래서 마음먹고 2판을 쓰고 있습니다. 한 달 정도 지났는데요. 2009년에 나온 책에서 다루지 않았던 내용들을 모두 포함해서 쓰려고 계획중입니다. 물론 무슨 출판사랑 계약이 되고 이런건 아니고요. 일단 다 쓰고 나면 출판사 알아봐야죠. 2009년에 나온 책도 그렇고 지금 쓰고 있는 것도 그렇고 이게 뭐 얼마나 팔리겠어요? 출판사에 손해나 안끼치면 다행이지요.

이곳 KLDP에 '컴퓨터를 만듭시다. 참쉽죠' 라는 제목으로 아주 오래전에 연재 했던 글이 책으로 나왔습니다.

라면 받침으로 아주 좋아요~^^

http://www.yes24.com/24/goods/7859338?scode=032&OzSrank=1

그리고 절판이 될지도 모르는 아주 오래된 제 첫 번째 책도 관심있으시면 봐 주세요~^^

http://www.yes24.com/24/Goods/3337559?Acode=101

=3==3

-분할 정복-
디바이드 앤 컨쿼를 번역해서 분할 정복이라고 책에 많이 써 있다. 디바이드앤 컨쿼라는 영어 단어를 그대로 직역한 것이다. 어떤 커다란 계산이 필요한 문제가 있을 때, 이 문제를 잘게 쪼개서 개별적으로 계산한 다음 그 계산 결과를 합쳐서 최종 결과를 만들어내는 접근 방법의 통칭이다. 쉽게 말해 각개격파하는 것이다. 한 덩어리로 계산하면 땀나고 빡센 문제를 작게 쪼개서 빨리 빨리 계산함으로써 전체적인 효율을 높인다는 전략이다. 아주 좋은 전략이고 실제로 효과도 있다. 하지만 컴퓨터 프로그램을 만들면서 마주하는 많은 문제들을 모두 디바이드앤 컨쿼 전략으로 해결할 수 없다. 디바이드앤 컨쿼가 되는 문제가 있고 안되는 문제가 있다. 다행이도 지금 계속하고 있는 팩토리얼 문제는 디바이드앤 컨쿼 전략에 아주 잘 어울린다. 사실 디바이드앤 컨쿼 하려고 일부러 팩토리얼을 골랐다. :-)

지난 글을 쓰고 댓글에 python도 gmp를 쓰면 빠르다라는 댓글이 있었다. 뭐 그런 댓글이야 당연히 달릴 수 있다고 생각한다. 난 파이썬은 빅넘버를 지원하니까, gmp가 라이브러리로 따로 있으리라고 생각 자체를 안했으니까.

그런데 그 댓글의 말투(어투? 글투?)가 아주 기분 나빴다. 아니 기분 나쁜 정도를 떠나서 예의가 없었다. 아무리 우리가 전산쟁이고, 실력이 중요한 사람들이라지만 실력에 앞서 예의가 가장 중요하다. 욕을 한바가지 하고 싶었으나 참았다. 나도 같은 수준이 되기 싫어서.

그래서 아예 그냥 이 글을 때려 치우고 말아버릴까 싶었지만, 이왕 시작한 글이고, 또 재미있게 봐 주시는 분들도 있으니 느리긴 하지만 끝까지 써보려 한다.

제가 쓰는 글이 완전할 수는 당연히 없습니다. 전 아는 것도 없고 실력도 없는 하수니까요. 댓글에 본문의 부족한 부분을 지적하고 채워 주시는 것은 아주 좋습니다. 그렇게 하여 글이 더 풍부하고 완전해 지니까요. 하지만 글을 쓸 때 최소한의 예의는 지켜주시길 부탁드립니다.

#1. 시퀀셜
난 사실 리컬시브니 디바이드앤 퀀커니 하는 이런저런 기법과 알고리즘을 잘 못한다. 머리가 나빠서인게 가장 큰 이유이고 오류가 없는 코드는 가장 단순한 코드라는 확실한 믿음 때문이다. 코드의 특정 부분에서 성능 최적화를 '반드시'할 필요가 있을 때에나 이런 저런 시도를 하면서 코드에 여러 기법들을 적용해 보지만 어지간해서는 기본적인 문법과 기본적이고 직관적인 코드 이상은 잘 작성하지 않는다.

프로그래밍 언어론에서 프로그래밍 언어의 요소를 구분할 때 일반적으로 반복문, 제어문, 산술문 정도로 구분한다. 그중 반복문은 전체 프로그램의 성능에 가장 큰 영향을 미치는 부분이다. C언어라면 대표적으로 for문과 while문이 있다.

문법에서 제공하는 반복문을 사용하는 방법 말고 반복(루프, loop)을 구현하는 다른 방법으로는 리컬시브가 있다. 이 글을 읽는 사람들 중 리컬시브가 뭔지 모르시는 분들은 얼른 공부하고 오시길 바란다. 리컬시브로 구현한 50000!은 다음 시간에~^^

재미있는 놀이: C, Python, Erlang으로 50000! 해보기
#0. 동기, 그리고 삽질.

-프롤로그-
나는 1996년부터 C언어를 사용했고, 2001년부터 파이썬을 사용했다. 그리고 2011년 12월 17일부터 얼랭(Erlang) 책을 읽기 시작했고, 2011년 12월 20일에 얼랭으로 처음 코딩을 해 봤다.(얼랭이라는 언어를 안건 2009년 즈음이다.) 이 글을 쓰고 있는 현재 나는 얼랭이란 언어를 본격적으로 공부해야겠다라고 다짐한지 3일이 지났다.

정리해보면, 이 글을 쓰고 있는 현 시점 기준으로

* C언어: 15년
* Python: 10년
* Erlang: 3일

의 경력을 가지고 있다.

#1. ARM 아키텍처 소개 Part.1

ARM. [암]이라고 읽는다. 뛰어난 성능과 저전력을 무기로 모바일과 임베디드 시장에서 거의 절대적 시장 지배자 위치를 차지하고 있다.

내가 ARM을 처음 접한 것은 2003년 쯤에 우연찮게 구입한 "C, C++로 작성하는 임베디드 시스템 프로그래밍(한빛미디어, 2000)"이라는 책에서였다. 당시 책에서는 Acorn Risk Machine이라는 이름으로 초창기 ARM에 대해서 설명을 하고 있었다. 물론 아키텍처에 대한 설명같은 것은 없었다. 다만 초창기 ARM 기반 개발 보드였던 Acorn 보드에서 펌웨어 개발을 어떤식으로 하는지에 대한 설명만 있었다. 우습게도 당시에 나는 그 책을 읽으면서 그 책에서 기반으로 삼고 있는 Acorn Risk Machine이 지금의 ARM인지 한참이 지나서야 알게 되었고, 책을 읽으면서도 임베디드 컨트롤러의 아키텍처에 대해서는 별 관심이 없었다.

xNIX 바닥 개발자들을 구분하는 많은 기준이 있겠지만, 그 중 선호하는 에디터 기준으로 나누는 방법이 있다.

VI(M) vs. emacs

나는 이맥스를 잘 쓰고 싶어하는 VIM 사용자이다. 이 바닥에서 학생시절부터 코딩질을 십년 넘게 하면서 VIM만 사용해 왔다. 한 때 이맥스를 쓰고 싶어 잠시 사용해보기도 했으나 이내 VIM으로 돌아왔다. 아~ 정말 이맥스를 잘 쓰고 싶다.

어떤 프로그램을 잘 다루고 싶을 때 가장 먼저 하는 일은 인터넷에서 해당 프로그램에 대한 howto 문서나 강좌를 찾아보는 일이고 그 프로그램이 꽤나 유명한 것이라면 서점에서 책을 사서 책을 보고 실습해 보며 익힌다.

국내서만 기준으로 인터넷 서점에서 검색해 보면, VI(M) 관련 책은 세 권이 나오고, 이맥스 관련 책은 두 권 나온다.

그누 이맥스 시작하기

8. 오브젝트 도출
이번 편을 쓰기 전에 제목을 무엇으로 해야 하나 약 1분간 깊은 고민을 했다. 제목을 정하기 위해 구글 검색을 할 정도였다. 이번 편에 작업하고자 하는 내용은 단순하고 명확하다. 지난 글에서 분석한 명사와 동사를 기준으로 데이터 베이스의 테이블과 코드 로직의 메소드, 코드 로직의 자료 구조등을 도출해 내는 작업이다. 나는 이것들을 통칭할 수 있는 용어로 "오브젝트"라는 용어를 직관적으로 떠올렸다. 하지만 바로 이어서 "엔티티"라는 용어가 치고 올라왔고 내 머릿속은 복잡해 졌다.