Life Algorithm

http://kldp.org/node/96531

1주일 정도 지난 얘기긴 합니다만...
뉴스는 대표적인 국내 DBMS 업체 중 하나인 AL사에서 -_- 1원 입찰을 했다는 내용이죠.

http://kldp.org/node/94831

근데 재밌는 것은 두 달쯤 전에 AL사의 핵심 개발 간부로 보이시는 분이 KLDP에 역시 유명한 국내 S/W업체인 T사를... 한 마디로 까는 내용을 올렸습니다. 이유는 반값 입찰을 했다는 거죠 -_- 본인은 T사를 험담하려는게 아니라 건전한 IT 생태계를 만들기 위한 지적이었다고 말하지만 객관적으로 보기에는 그냥 까는 걸로만 보입니다(답글까지 다 읽어보세요 -_-).

근데 불과 두 달만에 반값 입찰을 그야말로 양반으로 만드는 1원 입찰이, 그것도 본인이 일하는 AL사에 의해 저질러 졌으니 그 분 입장은 참 난감하게 되었지요. 건전한 IT 생태계는 개뿔...-_-
솔직히 그 분은 T사에 원한이 있었든 없었든 자기 회사는 믿고 있었던 걸로 보이는데 좀 안됐기도 하군요. 자기가 1원 입찰 한 것도 아닌데...-_-;;;

여튼 답글에도 있지만...
AL사의 제품 = 1원의 가치는 물론 아닙니다. 프로그램의 가격이란게 그야말로 귀에 걸면 귀걸이 코에 걸면 코걸이가 될 수 밖에 없지요. 그러다보니 이런 극단적인 상황까지 발생하지만, 어쨌든 대외적인 가격인 list price가 책정되는 기준은 나름대로 존재합니다.

물론 S/W는 인건비를 제외하면 원가도 거의 안 들어가지만(CD값이나 포장비야 머...-_-) 카피나 라이센스당 억단위로 돈을 받기도 하죠. 제가 일했던 DB회사인 AR사는 -_- 개발 인원이 10명도 안되는 회사이지만 프로덕트 카피당 몇천~억 정도를 받습니다.
반대로 윈도우즈의 경우는 세계 굴지의 소프트웨어 회사에서 새 버전마다 아마 몇백 몇천억원씩 들여서 윈도우를 개발하지만 윈도우의 가격은 개당 비싸야 몇십만원 정도입니다.

그럼 전자의 경우 윈도우보다 원가가 적게 들었으므로 몇만원을 받고 팔아야 됩니까? -_-;
물론 아니죠. 몇 달에 하나 팔까말까 하다면 억을 받아도 회사 유지는 간당간당합니다 -_-
게다가 DB같은 제품이라면 팔기 전에도 판 후에도 유지 보수등이 꽤 많이 필요하므로 비용은 더 늘어납니다. 물론 유지보수 비용을 따로 받기도 하지만요.

결국 잘 만들든 못 만들든 판매량이 손익 분기점을 넘기기만 한다면 그 이후로는 이익이 될 수 있는 것입니다. 음... 영화랑 마찬가지? -_-
다시 말하면 소프트웨어 개개의 가격보다는 판매액의 총합이 더 중요한 셈이고, 판매량이 많은 PC용 소프트웨어라면 수많은 사람을 만족시켜야 하므로 합리적인 가격 책정이 중요하지만 상대적으로 판매되는 카피 하나하나에 노력이 많이 들어가고 판매량이 적은 서버 소프트웨어나 미들웨어는 그런 면에서 좀 더 자유로운 편입니다. list price와는 별개로 가격이 미x년 널뛰기 하는 경우가 대부분이고 -_- 결국 1원 입찰 같은 일도 생길 수 있는 거지요.

즉 1원 입찰이란게 그 한 카피에 대해선 손해를 본다 하더라도 반드시 그 사이트를 선점하고 차후의 매출 창출을 위한 장기적인 포석이자 전략적인 선택이 될 수도 있다는 겁니다.
그러니 욕할 일이 못됩니다....라고 말하려는 건 절대 아닙니다 -_- 아무리 그렇다 하더라도 S/W 자체의 성능을 차치하고 가격으로 승부하는 건 IT 기술 발전에 당연히 해가 됩니다.
다시 말하면 업체들도 상도덕상 그러지 않아야 하겠지만 근본적으로는 최저가 입찰방식이란 제도 자체가 더 문제가 아닌가 싶습니다. S/W의 품질은 상관없이 싸면 장땡이라는 거죠. 그래놓고 실제로 들어가면 말도 안 되는 것들까지 요구하면서 배짱이죠 -_-;

정리한다면 '갑'들의 최저가 입찰을 비롯한 그지같은 관행->가격 후려치기 및 접대 위주의 영업 성행->S/W 품질의 우선순위 하락->고급 개발자에 대한 수요 축소->경력직 개발자들의 개발직 이탈->개발자들의 하향 평준화->IT 기술력의 약화, 뭐 이런 식이 됩니다.
물론 우리 나라 IT 수준이 떨어지는게 꼭 저 이유가 절대적이지는 않겠지만(정부의 무개념한 정책도 한 몫 하고, 프로그래밍이 주산 부기 배우듯 학원에서 배우면 가능하다고 생각하는 인식도 문제죠) 적지 않은 비중을 차지할겁니다. 또한 국가 경제 발전에 가장 해가 되는 것 중의 하나로 대기업의 횡포를 저는 꼽지요 -_-;

어쨌든 지금의 현실에서는... 다른 회사 욕할 거 없습니다 진짜 -_-;; 기회가 생기면 어느 회사든 저가 입찰 하고도 남을 겁니다. 대부분의 우리 나라 회사들이 그런게 영업인 줄 압니다.
제가 다니는 회사는 그럴 일이 없긴 하겠군요. 근데 그러고 싶어도 못하는거지 머 가능하다면 하고도 남을...-_- 저희 회사는.. O사죠 -_-;

앞으로 시간 남는대로 SQLite의 소스 및 구조를 분석하는 올릴까 합니다. 예전에도 관련 글이 몇 가지 있지만 앞으로는 좀 더 상세하게 파헤칠까 합니다.
이번에는 가장 기본이 되는 SQLite의 기본적인 레이어 구조와 페이지 핸들링에 대해 다루어 보겠습니다.

이 글을 관심있게 읽어 보실 분이라면 이미 SQLite를 몇 번은 다루어 보셨겠죠?
우리는 SQLite 쉘을 이용하거나 혹은 JDBC든 C API든 무언가를 통해 SQL을 SQLite에 보내게 됩니다. 이것이 좌상단의 Core레이어에 있는 Inteface입니다. 위에 말한 것들이 모두 Interface가 됩니다.

SQL문장은 우상단의 SQL처리 레이어(SQL Compiler)를 통해 SQLite Virtual DB Engine이 처리할 수 있는 OPcode로 번역됩니다.
Core 레이어 마지막의 Virtual Machine이 바로 OPcode를 받아 처리하는 역할을 합니다.
OPcode는 형태상으로 어셈블리와 비슷하며 SQL 처리 과정을 이해하기에 편한 구조를 지니고 있습니다.

Backend는 실제로 저장되는 데이터 구조를 다루는 부분입니다. Virtual Machine에서 무슨 테이블에 이거 집어넣어라, 무슨 인덱스에서 이거 삭제해라 등등 좀 더 세밀한 명령을 보내면 메모리와 디스크에 저장된 데이터를 조작하게 됩니다.
B-tree부분은 인덱스와 테이블 저장구조를 담당합니다. SQLite에서 인덱스는 당연히 B-tree로 이루어지며 일반 테이블 또한 row id를 키로 하는 B-tree입니다.
B-tree의 operation은 메모리 상에서 이루어지며 Pager(page cache)를 통해 메모리에 올라와 있던 B-tree 페이지가 디스크로 내려가고 또 불려 올라오게 됩니다.
디스크 I/O를 비롯한 부분은 OS마다 다르므로 OS Interface를 통해 각 OS마다 따로 구현되어 있습니다.

페이지 핸들링(길어서 접음)

 

CVS 소스 트리에는 이미 포함되어 있긴 합니다만... (http://www.sqlite.org/cvstrac/dir?d=sqlite/ext/rtree)

SQLite는 확장성에도 나름 노력을 기울이고 있는데 User Collation(텍스트 컬럼의 경우 정렬방식을 사용자가 결정할 수 있음, 예를 들면 한글 데이터와 영어 데이터가 있을 경우 이를 한글이 먼저 나오게 할 수 있음)이나 User Function(SQL function을 유저가 정의) 등이 있으며  R-tree는 Extension Loading이라는 기능을 통해 지원됩니다.
Extension Loading은 리눅스라면 dlopen() 함수를 통해 shared library를 로딩하는 방식으로 이루어집니다(dlopen()을 활용하면 실행중에도 공유 라이브러리 링크가 가능합니다).

R-tree는 B-tree랑 유사한 방식의 트리 자료구조인데 주로 위치 정보나 공간 정보를 저장하는데 쓰입니다. 구글 맵 같은 기능을 구현하고 위치 정보를 좌표로 DB에 담는다면 B-tree로 인덱스를 구성해봤자 별로 도움이 안되겠죠. 위치 정보에서 중요한건 어디가 어디와 가깝느냐 이런게 중요하겠죠. 참고로 오라클 DB도 spatial 데이터 타입을 지원합니다.
자세한 건 위키피디아를 참조하시고...-_-;;

흥미있으신 분은 사전 지식을 쌓을 겸 둘러보시고 소스를 한 번 보시기 바랍니다. 2800라인 정도니 크게 부담가는 정도는 아닌 듯...;

여튼, 이런 예를 볼 때마다 오픈 소스의 장점이 유감없이 발휘된다는 걸 느끼고 감탄할 따름입니다. SQLite 같이 잘 나가는 프로젝트는 엔진만 있어도 알아서 JDBC, Python, Ruby, PHP, ... 등등의 Binding 뿐만 아니라 이건 extension까지 수많은 사람들이 달려들어 제작을 하니까요.
이런 확장성을 톨한 불특정 다수에 의한 개발의 예는 사실 오픈 소스가 아니라도 많지요. 대표적인게 WOW 아닐까요...ㅡㅡ;

제목은 내 맘대로...ㅡㅡ;
원래 제목은 Software Development Meme입니다.

http://monac.egloos.com/1971053 에서 릴레이 합니다. 원제목의 의미는 링크에서 읽어보시길...-_-


몇 살 때 프로그래밍 시작? (How old were you when you first started programming?)

10살 때 정도였던 듯(처음 Apple II+를 구입한 시점)... 그러고보니 그 땐 우리 집이 잘 살았군요!! 지금은 왜...-_-

어떻게 프로그래밍을 시작하게 되었나?(How did you get started in programming?)

그냥 멋있어 보여서 -_-;; 초등학교 때 본 모험소설(?)중에 주인공이 해커였던 책도 있었던 거 같고... 하여튼 프로그래머를 동경했던 것 같네요. 지금도 마찬가지지만...^^;

첫번째 언어는 무엇?(What was your first language?)

물론 베이직... 8비트였으니 GW 베이직은 아니었고, 학원에서는 금성 컴퓨터였나 정확한 모델명이나 언어명은 기억이 안나는데 거기서 프로그래밍을 했고 집에서는 애플 베이직으로 했었지요(그나마 디스켓에 저장은 가능).
컴퓨터의 모든 것이 베이직으로 만들어진 줄 알았던 시절이죠 -_-;;

처음으로 짠 실제 프로그램은 무엇?(What was the first real program you wrote?)

질문이 좀 애매한데...-_-; 처음 짜 보는거야 다 Hello World 류 아닌가...
직업적으로(돈의 댓가로 -_-) 짠 첫 프로그램은 flex와 bison을 쓴 SQL 파서였던 것 같네요.

프로그래밍을 시작하고서 어떤 언어들을 다뤄봤나?(What languages have you used since you started programming?)

그나마 좀 안다고 할 수 있는 언어는 C/C++/Java/Python 정도...?
그 외에 맛이라도 좀 본 언어들은 Perl, Ruby, PHP, Prolog, VB, Pascal... 또 있나?
Hello World라도 해본 언어들은 또 추가로 10여개 있을 듯... 성격이 게을러서...ㅡㅡ;

직업적 프로그래밍의 첫번째 실패는?(What was your first professional programming gig?)

음.. SQL shell 툴을 만들 때? 기존에 있던 Embedded SQL 툴(오라클의 Pro*C 같은..)을 그대로 이용해서 만들란 지시가 있었는데 말도 안되는 지시였지만 신입이었으니 따를 수 밖에...
즉 구조는 SQL> 프롬프트가 뜨고 사용자가 SQL을 입력하면 앞에 "EXEC SQL"을 붙인 후 ESQL 컴파일러로 백그라운드에서 실행시킨 후 결과값을 popen으로 갖고 와서 다시 뿌려주는... 그런 말도 안되는 구조였습니다. SQL 엔진이 없기 때문에 생긴 일이었는데(즉 툴마다 따라 SQL 파서를 갖고 있게 되는 기이한..) 결국 유지보수가 굉장히 힘들어져서 스톱...-_-
저걸 지시했던 당시 PM 분은 아직도 자기가 회사를 말아먹는데 일조했다고는 생각 안하는 듯...

지금 아는 걸 그 때도 알았더라면 -_- 그래도 프로그래밍을 했을까?(If you knew then what you know now, would you have started programming? )

링크에 있는 Monac님 답변과 비슷한데 프로그래밍은 당연히 했겠지만 대신 일단 외국으로 가는 것부터 먼저 고려했겠죠. 그리고 프로그래밍 말고 할 줄 아는게 있어야죠, 전공도 컴퓨터인데...

그동안 겪어 오면서 신참 개발자에게 해주고 싶은 말이 한 가지 있다면?(If there is one thing you learned along the way that you would tell new developers, what would it be?)

테스트를 두려워하지 말 것, 어차피 에러 없는 프로그램은 없다.
디버깅을 싫어하지 말 것, 니가 오버이트 한 거 니가 치워야지 -_-;
잘 모르면서 비판하지 말 것...-_- 아는 만큼 보이는 법...
그리고 무책임하게 질문하지 말 것...
...한 가지가 아니군요 ㅡㅡㅋ

프로그래밍 해 오면서 가장 재밌었던 것은?(What's the most fun you've ever had ... programming?)

음... 실력이 안 되어서인지 운이 없었는지 직접 프로그래밍 하면서는 재밌었던 적이 별로 없었던 거 같네요. 물론 코딩한 코드의 결과가 나오거나 디버깅을 성공했을 때의 재미도 크지만...
오히려 재밌었던 것은 오픈 소스의 코드를 볼 때인 것 같네요. 감탄할 때가 많죠. 최근엔 특히 SQLite...^^;

다음 차레는 누구?(Who’s next?)

뭐 원하는 분이 아무나...ㅡㅡㅋ

거창한 얘기는 아닙니다.
여튼 발단은, 제 회사 제품의 모 오퍼레이션에 1.4~1.5초 정도가 걸리는데 이걸 1초에 근접한 수준으로는 만들어야 될 상황이 온 겁니다.
프로파일링도 해보고 했지만 특별히 bottle neck 이라고 할만한 부분도 없었던 터라 그냥 call time 상위권 함수들을 뒤집어 보며 오퍼레이션 타임을 줄일만한 부분을 찾게 되었습니다 -_-;

두 군데 정도 줄일만한 곳을 찾았는데 한 군데는 수정했더니 0.1~0.15초 정도가 줄어들더군요. 그리고 두 번째 부분...

int func(char *mem)
{
    char a, b;
    short c;
    int offset = 0;

    memcpy(&a, mem, sizeof(char));
    offset += sizeof(char);

    memcpy(&b, mem+offset, sizeof(char));
    offset += sizeof(char);

    memcpy(&c, mem+offset, sizeof(short));

    return func2(a, b, c);
}

대략 이런 식이었습니다. 상당히 간소화 시켰지만 패턴은 저런 memcpy를 통한 assign과 offset 연산이 반복되는 식이구요.
일단 offset 연산을 줄이기 위해 mem에 상수를 더하는 방식으로 바꿨구요.

int func(char *mem)
{
    char a, b;
    short c;

    memcpy(&a, mem, sizeof(char));
    memcpy(&b, mem+1, sizeof(char));
    memcpy(&c, mem+2, sizeof(short));

    return func2(a, b, c);
}

여기서 멈추면 섭섭하죠 -_- memcpy도 하나의 함수 호출이므로 직접 assign하는 비용이 적다고 판단했습니다. 그래서 assignment statement로 모두 변경...

int func(char *mem)
{
    char a, b;
    short c;

    a = *(char *)mem;
    b = *(char *)(mem+1);
    c = *(short *)(mem+2);

    return func2(a, b, c);
}

근데 어차피 func2를 호출할 때 넣는 값은 call by value이고 input 용도로만 쓰이므로 굳이 값을 assign할 이유도 없더군요. 그래서 직접 값의 주소로 함수 호출...

int func(char *mem)
{
    return func2(*(char *)mem, *(char *)(mem+1), *(short *)(mem+2));
}

여기까지가 대략 제가 작업한 outline이었습니다.

실제 수정 내용이랑은 좀 차이가 있긴 합니다만 어쨌든 이 작업으로 얻은 이득은.... 0였습니다 -_-;;;;;; 예, zero...-_-
md5 checksum까지는 확인해보지 않았지만, 바이너리 사이즈가 차이가 없더군요 ㅡㅡ 위의 테스트 코드는 차이가 좀 생기는 것 같은데 여튼 사이즈를 떠나서 실행시간의 차이도 없었습니다.

결론은 '저 정도는 컴파일러가 최적화 해준다'고 내려졌지요 -_-;
최적화에 들이는 노력의 90%는 쓸모없는 것이란 말을 실감했습니다. 저의 경우 90%보다는 적기는 했지만 쇼킹한 결과였지요. 여전히 경험이 일천한 프로그래머란 걸 증명한 것이고요 -_-;

하지만 최적화는 꼭 필요하다는게 제 생각입니다. 리팩토링 차원에서도 필요하고...
즉, 제 생각에는 위의 경우처럼 tricky한 메모리 핸들링에 노력을 들이는 것은 점점 사실 필요가 덜해지는 것 같구요. 말씀드린 것처럼 컴파일러가 알아서 최적화를 하는 부분이 점점 커지니까요.
반면 일면 수학적인 논리의 변경에 의한 최적화는 (할 수만 있다면) 필수적입니다. 예를 들어 짝수일때만 동작하는 코드라면 for문을 i++로 돌리는 대신 i+=2로 돌려야 되겠죠... 빈약한 예제군요 -_-;

음, 언제쯤이나 되어야 guru 수준에 이를지...-_-

파이어폭스가 버전 3 출시하는 날 800만건의 다운로드로 세계 기록을 세웠다는군요.
저에게도 메일이 날아왔습니다.

그리고 감사의 의미를 담은 pdf 파일도 만들어주는군요(이름만 입력하면 자동 생성 -_-;;).
물론 저야 다운로드를 받기는 했지만 별 상관없는 사람도 주소만 알면 얼마든지 pdf 파일은 만들 수 있습니다 ㅡㅡ

근데 3.0이 뭐가 좋은 지는 아직 잘...-_-;;;
아무리 버전 업해도 사람들 눈에 띄는 건 일단 인터페이스 밖에는 없죠. '이번 버전에서는 마우스 클릭을 연속으로 5만번 했을 때 죽는 문제가 수정되었습니다!' 해도 체감하는 사용자들은 많지 않다는 얘깁니다.

그래도 메이저 릴리즈 버전이 바뀌었는데 제가 너무 둔감한건가요? ㅡㅡ

블로그가 점점 시들해지는군요. 요즘은 블로그의 정체성이 흔들리는 것 같은 느낌이 듭니다(애초에 그런게 있었나...? -_-).
아들을 가진 일도 있고 회사 Kickoff 관계로 중국에 5박 6일 정도 다녀온 일도 있고 해서 바쁘기도 했지만 역시 의지박약과 의욕부족이 제일 문제점인 것 같군요 ㅡㅡ

어쨌든.. 구글 코드 잼이 개최를 앞두고 있어서 소개글을 잠시 올립니다.
자세한 룰은 http://code.google.com/codejam/rules.html 에서 보실 수 있고요.

방식을 간단히 설명드리면, 일단 예선 라운드는 7월 17일 08시(한국시간)부터 시작하여 24시간동안 진행되며 세 문제가 출제된다는군요. 물론 여기서 걸러진 사람들이 다음 라운드에 진출할 수 있겠죠? 느낌상 이 예선 라운드는 거의 허접 쓰레기들(..) 필터링 과정인 듯 합니다.

1라운드는 대회 등록시에 입력한 본인의 선호 시간대에 최대한 맞춰서 치러집니다. 몇 개의 서브라운드로 이루어진다고 하는데 뭐 이건 일단 진출이라도 해야 걱정할 일이고...-_-;;;
1라운드에서 상위 2520명이 2라운드에 진출하구요. 여기서 다시 상위 1000명이 라운드 3에 진출하고 다시 상위 500명을 뽑습니다.
이걸로 온라인 대회는 끝나고 500명이 각 지역의 지정장소에서 대회를 치르게 되는군요. 지역이란 건 유럽, 중동, 아프리카, 아메리카, 아시아-태평양의 5개 지역이고... 그리고 상위 100명이 결선 라운드에 진출한다고 합니다.

왠지 드래곤볼의 천하제일무도회가 생각나네요 ㅡ.ㅡ
1등 상금은 1만 달러이며 100등까지 상금을 줍니다. 100등 상금은 $250... 상금을 떠나서 100등 안에 드는 것도 대단할 듯...-_-;
그리고... 1등은 구글 사무실에서 동반 1인과 함께 점심을 10번 공짜로 먹을 수 있다고 합니다...ㅡㅡㅋ

재밌는 것은 대회 방식인데...
상당히 방어적인 프로그래밍을 하지 않으면 패스하기 힘들 것 같습니다.

각 문제에 대한 small/large input set이 있는데 각 세트에 대해 정확한 output set을 submit하는 것이 일단의 목적입니다. 즉 중요한 것은 이 답이 정확해야 하며 소스 코드 업로드는 2차적인 과정입니다.
즉 다른 프로그래밍 문제 사이트들처럼 소스 코드를 보내면 서버에서 소스를 실행해보는 방식이 아닙니다. 그러므로 프로그래밍 언어의 제한은 없습니다. 심지어 문제를 손으로 풀었을 경우는 푼 방법을 텍스트 파일로 업로드하라고도 써 놓았습니다 ㅡㅡ
즉, 엑셀을 써서 풀어도 되고 한 문제에 여러 가지 언어를 써서 풀어도 되는 룰입니다. 중요한 것은 '문제 해결 방법'이라는 철학이 잘 반영되어 있는 것 같네요.

참여할 생각은 없지만 흥미 있으신 분들은 '관객'으로도 참여 가능합니다.
문제와 참가자들의 스코어보드를 볼 수 있는 듯 하군요. 위의 룰 부분에서 'How yo be a Spectator' 부분을 참고하시기 바랍니다.

재미삼아 연습문제를 한 번 풀어보기는 했는데(http://code.google.com/codejam/contest/dashboard?c=agdjb2RlamFtcg4LEghjb250ZXN0cxh5DA) 어려운 문제는 아닙니다만(C코드로 100라인 이내, python으로는 40라인 이내로 짰습니다) 값의 범위가 상당히 큰 값까지도 들어오고 다양하게 들어오기 때문에 주의깊게 짜지 않으면 잘 해 놓고도 삽질하느라 시간 낭비하다가 문제를 틀리기 쉬울 듯 합니다...-_-

관심있는 분들은 한 번 참여해 보시길... 근데 직장인은 영 힘들 거 같네요. 시간 맞추기도 힘들고...
1000등 안에 들 정도면 회사에서 휴가 내 주려나... 근데 입상하고서 혹시 구글에 입사한다고 하면...-_-;;

또다른 흥미로운 프로그래밍 사이트를 소개해 드립니다(http://rein.upnl.org/wordpress/archives/907 에서 알게 되었습니다).
정확히는 프로그래밍 사이트라고 하기는 좀 그렇네요. 여긴 대개 정수론 관련된 수학 문제에 대한 답만 입력하면 패스가 됩니다. 단지 그 답이 대부분 프로그래밍이 아니면 구하기 힘들다는거지요...-_-

사이트 이름은 프로젝트 오일러(http://projecteuler.net/) 입니다.
일반적인 코딩 사이트들에 비해선 좀 더 수학적인 문제들에 치중되어 있다는 점이 틀립니다. 하지만 복잡한 수학 지식을 요구하는 건 아니구요. 그래서 난이도는 좀 더 쉬운 느낌입니다. 현재까지 196문제가 올라와 있군요. 저는 이제 33문제 풀었습니다...
쉽게 풀리니 오히려 재미있어서 며칠간 바짝 매달렸는데 이젠 좀 지쳐서 pending 상태입니다...-_-

간단한 문제 몇 가지를 소개하면...

• 10001번째 소수(1과 자신 외에 나눠지지 않는..)를 찾으시오.
• 2백만 이하의 모든 소수의 합을 구하시오
• 100!(팩토리얼)의 합을 구하시오
• 1^1 + 2^2 + ... + 1000^1000 의 결과의 마지막 10자리를 구하시오
  

제가 푼 문제 중에서만 뽑은 것이므로 좀 쉬운 문제들만 예시됐군요. 세번째 네번째 문제같은 경우는 python이라면 몇 라인이면 해결됩니다. 다른 스크립팅/함수형 언어도 마찬가지겠지만 네번째 문제의 경우 C/C++은 좀 까다롭겠네요.

큰 자릿수를 요구하는 문제들이 제법 있어서 C/C++은 좀 불리한 면이 있다고 생각하는데 그럼에도 불구하고 통계상 C/C++을 사용하는 사람이 제일 많습니다. 두 번째는 python이고... 저도 python을 씁니다. python shell에서 간혹 따로 코딩 안하고 해결 가능하기도 하거든요. 기본적으로 제곱 연산과 무한자릿수 타입을 지원하고...
그 외 Java나 Ruby등도 있고... Haskell을 쓰는 사람도 꽤 많습니다. 배워야지 하면서도 제대로 못 배웠던 언어인데 이번 기회에 한 번 제대로 집중을 해봐야 할 듯...-_-;
아예 수학용 툴인 매쓰매티카 등을 쓰는 사람도 제법 많아 보입니다. octave 같은 건 안 보이는 듯...

심심할 때 맘 편히 풀어 보세요. 의외로 재밌습니다 ㅡㅡ;

작년까지는 Subversion을 썼는데 svncommand 없이 어떻게 사용했나 싶었는데...
올해 회사를 옮기면서 CVS를 쓰게 되고, 불편해 하면서 그냥 쓰다가(그냥 CVS와 SVN만 놓고 봐도... 아무리 생각해도 SVN이 편합니다 -_-) 문득 생각이 나서 뒤져 봤더니 cvscommand도 있더군요.

이것들이 무엇이냐..하면, vim으로 개발하시면서 CVS 및 SVN을 쓰시는 분들께 매우 유용한 vim 플러그인입니다.
vim을 빠져 나가지 않고 각종 CVS 커맨드를 쓸 수 있어서 매우 편하고 매력적입니다. 그리고 log나 diff, annotate등을 vim의 syntax highlighting으로 볼 수 있으니 가독성도 훨씬 좋지요.

일단 다운로드는 아래에서...
svncommand : http://www.vim.org/scripts/script.php?script_id=922
cvscommand : http://www.vim.org/scripts/script.php?script_id=90

cvscommand는 현재 vcscommand로 프로젝트 명이 바뀌어서 CVS, SVN, GIT, SVK를 통합 지원하는 프로젝트로 바뀌었네요. CVS만 쓰실 분들은 저~ 아래쪽의 1.76 버전 cvscommand.zip을 받으시면 됩니다. 그리고 vcscommand는 vim 7.0이상만 지원합니다.

cvscommand의 경우 CVS[명령어]의 형태로 사용하면 됩니다. Subversion 쪽도 거의 같습니다.
몇 가지만 예를 들면,

:CVSAdd - cvs add
:CVSAnnotate - cvs annotate
:CVSCommit - cvs com