사실 이런 구성이 된 건 예전에 Dell UltraSharp U2407 을 얻어서 사용했는데, 이게 맛이 가면서 삼성 SyncMaster 2343BWX (TN 패널) 을 받게 되어서 임. 이거 하나랑 17” 두 개 쓰다가 17” 하나를 동일한 23”로 바꿔서 현재까지의 상태가 된 것.

프로그래머는 막눈이라고 – 적어도 일단 나는 – 그냥 저냥 쓸만한 모니터 같긴 한데, 이젠 눈이 나빠서인지 삼성 2343BWX가지곤 오래 집중하기가 힘들더라. 그런 의미에서 삼성 SyncMaster 2343 BWX 의 가장 큰(?) 단점: 도트 피치가 작다 – 사람에 따라선 선호할 수도 있음; 여기서는 VS 2010 전체 화면 모드로, 2048 by 1152 해상도에서 16pt 폰트를 쓰면 한 화면에 두 개의 에디터 창(80 column)을 볼 수 있음. 하지만 도트 피치 문제로 10pt~14pt 정도에선 집중하기 힘들더라; 두통이 찾아오는 지라(…).

게다가 해상도 가지고 계산해 보면 알겠지만 16:9 비율이다. 이것도 취향문제일진 모르겠지만, 에디터에서 위 아래 길이가 짧은 건 꽤나 불편하다. 그렇다고 이 크기의 모니터를 회전 시켜서 쓰는 것도 좀;;; (TN 패널 자른 방향 때문인지 세로로 쓰면 색 왜곡도 심하다)

그래서 새해 지름으로 – 그러니까 내 돈으로 – Dell UltraSharp U2412M (이하 U2412M)두 대를 질렀다. 이걸로 17" 한 대와 23" 한 대를 대체했음. 개발 머신 용 설정으로 이 두 대를 수평으로 이어서 쓰게 되었다. 대략 다음과 같은 구성:

해상도는 1920 by 1200으로 줄어들었지만, 폰트 크기는 15pt로 줄여서, 수직으로 더 많은 내용을 볼 수 있는 건 내 취향임. 폰트 크기를 줄여도 실제 글자 크기는 거의 동일하다. (도트 피치 0.249 vs. 0.270) 비슷한 이유로, 수평 해상도는 살짝 줄어들었지만 폰트 크기 역시 줄어서 수평 공간도 80 column 기준으로 오히려 약간 남게 바뀐다.^[1]

게다가 이 모니터는 의자 위치에 따라 색이 바뀌진 않아…

그래서 Samsung SyncMaster 2343 BWX 랑 Dell U2412M을 비교한다면 난 전적으로 후자의 손을 들어주겠음 – 적어도 내가 프로그래머인 한은 말이다… 어떤 의미로 비교대상은 고가 모델인 Dell U2410 쪽인데, 집에서 쓰는 이 모델이랑 비교하자면 이렇다:

• 입력 단자 수가 적다. DVI도 하나 뿐이고, VGA, DP 로 끝.
• SD 카드 리더도 없고…
• 설정 버튼도 훨씬 촌스럽고(…) 불편하다.
• 색 재현 율이 다르다고 하지만 이건 내 능력 밖의 얘기라 (먼산)
• 더 가볍다 (포장 기준으로 거의 3Kg 차이)

집에서 쓴다면 XBox360도 연결하고 쓴다거나 하고, 편의 기능 (DVI가 2개라거나; SD 카드 읽기라거나) 도 있어서 굳이 U2412M을 사진 않겠지만, 두 대 사서 구성할 생각이면 U2412M도 훌륭하다고 생각한다. (일단 가격이 절반임; 양쪽 다 IPS 패널임에도…)
물론 금전적인 여유가 있다면 U2410 두 대 구성도 가능하지만, 그 돈이면 그냥 U3011 사세요 (…). 얘는 HDMI도 2개임…

PS. 델 4:3 모니터인 UltraSharp 2007FP는 왜 이렇게 비싼가요? 36만이라니 이거면 U2412M 사고도 돈이 남는다고…

1. 오른쪽 모니터에 떠 있는 에디터의 색상 테마는 solarized임. 흰색이 아니다

정부의 절전시책인가 뭔가로 회사에서 냉방기 — 난방기 아님 – 사용을 금지하고, 공조 시설 가동을 최소화 한단다.
그 결과가 뭐냐하면, 이 한겨울-_-에 28도까지 올라가서 일하기 괴로운 사무실.

심심하신 분은 고성능 CPU/GPU의 면적당 발생하는 열량을 계산해보시기 바람. 항성 표면(…)에 준하는 수준임…
이런걸 2~3개씩 달고 있는 PC를, 사람마다 k개 (2~5?), 그리고 팀 별로 공용 장비로 들고있는 것 까지 생각하면 발생하는 열은 좀 삭막한 수준; 

이 정부가 친환경 성장 정책에 전혀 관심이 없다고 느껴지는게,

• 전기가 모자란 것 일단 사실이 아닌 것 같고 — 발전소 가동률을 볼 때
• 산업용 전기료를 인상할 생각은 없는듯 함; 가정용 수준으로 올리거나, 가정용처럼 누진제를 적용해야 함
• 상대적으로 온실 가스 방출량이 적은 기업에도 전기 사용량 제한

정도?

재작년엔가 여름에 27도 제한했을 때도 미치는 줄 알았는데, 겨울에도 이런 꼴을 보게 해주다니 아주 짜증나 죽겠다.
 

그래서 오늘은 창문을 열어놔 봤다. 대략 25도?까지 떨어지긴 하던데,

• 테헤란 로를 달리는 차들의 경적 + 기타 소음
• 매연
• 가끔 찬 바람이 직접 닿기

…를 경험하고 나니 Orz.

정말 꿈도 희망도 없어…

Sometimes, the terms “astral plane” and “astral characters” are used informally to refer to the planes above the Basic Multilingual Plane (planes 1–16) and their characters.

(강조는 내가 넣은 것)

아스트랄 플레인이라니!! 사실 슬레이어즈는 유니코드 문자셋의 앞쪽 코드 포인트들이 뒷쪽 코드 포인트(아스트랄 플레인)를 사용한 암투인 것.

관련 글:

1. 패킷 직렬화 / 핸들링 라이브러리

• C++
• Python
• C#
• JavaScript
• SQL
• Lua
• Go

C++

우선 주 언어로 쓴 C++. 내년에 공개될 모 서버를 작성했다. 사내 테스트까지 나간 것 중 C++11을 사용한 것으론 처음일듯.
그리고 옮겨간 팀의 서버 역시 C++로 작성하고 있다. 크래시 보고 도구도 밑 단은 C++…

내가 주목한 특징을 꼽자면,

• 바위에 끌로 새기는 것 같이 작업함 – 집중해서 빡쎄게;
• lambda로 이전에 boost 쓰는 걸 대체 – C++11 만세!(…)
• 괜찮은 성능 – 내가 사용하는 모든 언어 중 가장 월등한 성능을 자랑한다
• Bare metal 위에서 돈다 (위랑 같은 의미?)
• 원하는 수준만큼 저 수준에서, 원하는 만큼 세밀하게 제어할 수 있다

Python

팀 내의 코드 생성기나 대부분의 스크립트는 python으로 작성한다. 올해에는 대략,

• 데이터 변환 도구; .xls -> sqlite -> (C++ internal form) 으로 몇 가지 데이터를 옮겼는데, 이 중 첫 단계는 모두 python에서 해결
• 크래시 덤프 분석 및 집계 기능. 크래시 덤프를  cdb 수준에서 분석하면 이를 토대로 다른 덤프들과 비교하고, 이에 대해서 웹에서 볼 수 있게 했다
• 덤프 수집 (web)
• 크래시 덤프 뷰어 (web)
• 빌드 도구나 덤프 관련 툴에서 메일 생성 / 알림 기능

에서 python을 주로 썼다. 물론 예전부터 쓰던 코드 생성기, 빌드 보조 도구에도 python을 쓰고 있다.

…덧붙이자면 요즘 .svg를 python으로 만드는 뻘짓을 했다. 근데 생각해보니 python-cairo를 쓰는 게 더 간단하잖아?;;;

C#

연초에 파일 전송 도구를 하나 짜야 했다. 원래 생각했던 건 python 기반으로 빨리 짜고 딴거 하고 놀자(…)였는데, 

이거 누가 유지 보수 하냐

라는 태클에 물건너 갔음. 흑흑.

그래서 실 서비스에서 써본적(…)도 없는 C#으로 짰음. 사실 태클건 사람들은 태클 걸면 C++로 짤 거라고 생각했다고…
애매하게 편하고, 애매한 수준까지만 제어할 수 있어서 개인적으로 불만이 좀 많았음. 내가 python을 안 쓴다면 모를까 Orz. 

누가 비슷한거 시키면 그땐 정말 python 쓸 테다… 일단 저거 linux에서 옮겨서 쓸 생각을 하니 눈 앞이 캄캄하기도 하고 — 누가 Mono 관련 조언 좀…

JavaScript

까놓고 말하면 js에는 완전 초보임. 그래서 python쪽에서 js를 쓰긴 했는데, 크롬에서만 돌길래(…) 포기하고 jQuery로 전부 옮겼다. JavaScript를 썼다기 보단 jQuery를 쓴 느낌이지만 (…).

CouchDB에서 map-reduce 용 언어로 js를 쓰긴하지만, 이건 그렇게까지 복잡하게 활용한게 없으니 좀 애매하다. 따지고 보면 올해는 js보다 json을 더 많이 본 것도 같다(운다).

올해 얻은 건 jQuery를 좀 더 익숙하게 쓰게 되었다 정도?

SQL

ORM하나 제대로 쓰고 싶었습니다만 꿈도 희망도 없어; 그냥 python위에서 클래스 수준으로 포장해서 하단의 데이터 스토어로만 쓴 듯.
위안이라면 MySQL / CouchDB를 선택해서 쓸 수 있게 만들었다 정도지만; 

Lua

팀 내에서 사용하는 서버 용 부하 테스트 툴은 (NDC에서 ipkn이 발표한 내용은 http://ipkn.upnl.org/ndc.html 을 참조) lua를 스크립트 언어로 쓴다.
그런 의미에서랑, 몇 가지 도구에서 lua를 썼다. 이쪽에선 내가 발전이 전혀 없는듯… 

Go

연초에는 좀 만졌지만 — 위에서 C#/Python으로 헀던 일 중 일부는 원래 Go로 하려던 건데 — 그 이후엔 망했음.
과연 내년에는 나의 야망(…)대로 Go로 돌아가는 서비스를 만들 수 있을까;

일단 올해에는 회사 안에서 / 실제 서비스에서 linux 기반으로 해도 된다는 건 확인했으니, 내년을 기약합시다(…). 

요약:

• C++/python을 여전히 많이 쓰고 있다.
• C#은 안 편했음; 내년에는 아마 다른 선택을 할 듯.
• 웹 질(…)로 JavaScript/SQL을 좀 만졌다. 내년엔 기약 없음…
• Go. linux 기반 서비스를 좀 더 해도 될 것 같으니 내년을 기약 

관련 글:

1. 이번 주 팀 세미나: NDC 2011 마영전 서버 세션 정리
2. C# 잡상: 2011-03-04
3. C#이 예전 기억만큼 편하지 않다

• 매일 매일 얼마나 많은 덤프가 나오는지,
• 가장 많이 발생한 원인 (WinDbg의 버킷 비슷한 것) 은 뭔지,
• 같은 원인으로 죽은 덤프는 어떤지,
• 각각의 덤프 별 콜 스택 플랫폼 정보 (OS 버전, 각 모듈 별 버전) 는 어떤지

가 나오는 페이지를 만들었다.^[1] 아니 근데 생각지도 못했던 문제를 만났다;

여름에 서버를 설치한 후, 총 3개 팀이 사용하게 했고, 이에 따라 차근차근 크래시 덤프가 쌓여간다. 최근 덤프가 좀 무섭게 쌓여서 (…) 디스크 사용량을 추적해봤더니 대략 이런 결과가; (8월 중순 쯤 서버를 리셋했고, 그 이후의 디스크 사용량)

팀 + 1개 팀 상태에서는 참 완만하게 올라갔는데 (…), 좀 덩치 큰 다른 팀까지 적용했더니 순식간에 하드디스크가 차고 있다; 게다가 기울기가 더 올라가서, 현재 Doomsday는 다음 달 중순까지 당겨진 상태 Orz. 개발 중인 프로그램에 적용한 것이고, 개발 팀만 접근 가능한 위치라 전체 메모리 덤프를 받게 했더니 정말 저장 공간을 왕창 잡아 먹더라; 이건 내 예상 실패라고 밖엔;

HDD 가격 올랐다고 구매 신청해도 안 사줄 기세던데 이를 어찌 해결하는가; 일단 같은 콜 스택 + 같은 모듈 (이름; 버전; 체크 섬) 인 것들 지워서 지난 주 후반에 40 GiB 쯤 확보했는데, 그럼에도 불구하고 (…) 이미 216 GiB 쯤 쓴 상태. 사진은 2주 전 상태임.

저 서버를 설정할 때만 해도, 연말까지 300 GiB 정도는 넉넉하리라 생각했다^[2] 하다못해 HDD 하나 추가하는 건 별 큰 일 아니라고 생각했다. 하지만 태국 홍수 덕에 구매 팀에서 HDD 가격 비싸다고 장비도 안 사주는 마당이니, 망한 상황인 듯. 아마 1월부턴 90일 정도만 남기고 – 어차피 개발 중인 프로그램들 용으로 덤프 받는 서버라 버전 정보가 휙휙 올라가는지라; – 다 지워버리던가 해야.

사실 내가 궁금한 건 이거다; 과거의 덤프가 남아있다면 뭐가 좋을까? 그냥 간단한 텍스트 정보 – 크래시 한 상황에 대한 OS 정보, 콜 스택 정도가 있다면 충분할까? 아니면 전체 메모리 덤프가 다 있다면 오~래 가는 버그를 좀 더 쉽게 잡을 수 있을까?

원래 목적이던 “자주 발생하는 버그를 빨리 잡자”는 어느 정도 되어가는 것 같은데 – 일주일쯤 피크 치는 버그는 대충 잘 잡히는 듯? – 오래된 버그를 잡는데 도움이 되려면 어느 정도 범위를 가지고 있어야 할지;;;

PS. iPhone 4 렌즈 수차 정말 망이네; 화면 위 아래 수평선의 기울기를 비교해보면 Orz (…).

1. 실제 페이지 구현은 회사에서 만든 부분이라 여기서 공개하는 건 무리
2. 즉, 한 달에 50 GiB 이상은 안 나오겠지 정도로…

관련 글:

1. Egloos 이오공감/밸리에서 특정 블로그 무시하는 플러그인
2. 리뷰: 셜록 홈즈 미공개 사건집

운영 팀에서 "서비스와 데스크톱 상호 작용 허용" (allow service to interact with desktop) 설정을 켰음 – 이유는 모르겠지만, 대부분의 개발팀이 이 설정을 요구한다고; 계정은 로컬 시스템 계정 (local administrator) 였고; 여하튼 이 설정이 켜져서 문제가 된 부분은 대략 이렇다:

• 개발 편의성을 도모하고자, 1개의 바이너리가 서비스 혹은 콘솔 창 모드로 동작함
• 이 두 가지를 Environment.UserInteractive 값을 가지고 구분했다
• "서비스와 데스크톱 상호 작용 허용"이 체크되어 있으면, Environment.UserInteractive가 true로 설정된다
• …그리고 내가 작성한 서비스는 콘솔 창을 띄웠다 (…)

Orz.

부연하자면, 서비스는 세션 0에서 실행되기 때문에^[1] 사용자가 터미널 접속한 경우, "이런 이런 서비스에서 창을 띄우려고 합니다"란 메시지를 받게 된다. 그리고 그런 유저가 없으니 – 서비스는 보통 sc \\host-name start blah-blah-service 명령이나 관제 툴로 띄운다 – 서비스는 더 진행하지 못하고 사망. 일정 시간 안에 서비스를 시작하지 못하면 서비스 매니저는 그 서비스를 죽여버린다(…).

결과:

• 일단 그 날 저 체크 박스 꺼버리는 걸로 문제 해결.
• Environment.UserInteractive 말고도 SessionID를 확인하도록 코드 추가. (세션 0이면 서비스로 뜨게)

.NET을 잘 모르고 써서 생긴 문제긴 한데, 내가 운영 매뉴얼?을 좀 만들었으면 괜찮았을지도 모르겠다. 으으.

1. Session 0 isolation 참고

관련 글:

1. TLS, DLL, 그리고 Legacy Windows
2. Python으로 Windows Service 제작해보기
3. On Windows 7

• 팀이 바뀌었다
• 모 게임의 서버를 새로 짜는 작업을 하고 있다
• 회사에서도 linux 서버를 만지기 시작

첫 번째 일과 두 번째는 사실 한 몸이고; 나머지에 대해서 기록;

저 linux 서버 위에 예전에 짰던 크래시 덤프 수집하는 녀석을 올렸다. Windows + IIS + MSSQL Server + WSGI  (isapi 사용) application 이던 걸 linux + apache2 + MySQL (or CouchDB) + WSGI (mod_wsgi) 로 옮겼다. 실제 서버는 아마 nginx proxying + gunicorn 같은 애를 쓰게 되지 않을까 싶지만;

저기로 옮기면서 페이지도 페이스 리프팅. 원래 좀 중구난방이던 크래시 덤프 보기 페이지에 시간 대 별 보기라거나, 카테고리 기능이라거나, failure bucket id (windbg 얘기) 로 분류하기 등등을 넣었다. 덕분에 거의 0이던 jquery 프로그래밍 경험치가 충전된 듯 (…).
아무래도 이건 혼자 쓸 것만 만들다가 Firefox / Chrome이 아닌 웹 브라우저에서도 동작하게 해서 그런 거지만;

내가 처음 짠 코드의 문제가 CherryPy 에서 html 코드를 직접 토해낸다는 점. 간단한 건 그냥 문자열 혹은 문자열의 list로, 좀 복잡하면 문자열 yield return으로 때웠는데, 코드가 좀 길어지니까 감당이 안되더라. 일단 이걸 내가 계속 진행할 수 있는 처지가 아니라서 – 요약 1 참조 – 다른 프로그래머에게 넘겨주게 생겼는데 얘기하다 나온 게

• 유지 보수가 가능한가? Python을 중점적으로 쓰는 나와 ipkn 말고 유지가 가능한가?
• 굳이 linux 서버를 쓸 이유가?

이 두 가지. 그래서 목표가 "다른 프로그래머가 적응하는 시간을 줄이자", "문서를 최소한만 쓰자"로  데, 이건 대략 만족한 듯. 만약 이걸 asp.net 으로 옮긴다고 해도 로직 / 화면 두 가지만 분해되어 있으면 어떻게 될 거라고 믿기로 하고 (하략). 매우 저 수준으로(…) html을 직접 토해내던 WSGI application을 좀 분해하기로 했다. ipkn의 조언에 따라 – 그리고 손에 든 것만으로 문제를 푸는 나의 나쁜 습관을 가까스로 극복하고 – 템플릿 언어를 하나 골라서 써 보기로 했다. 그래서 flask 쓸 때 잠시 봤던 신사 (jinja2; http://jinja.pocoo.org/ )를 써봤다..

홈페이지의 첫 예제를 여기 가져와보자면,

정도인데; layout.html의 내용을 상속하고, (아마도 이중 일부인) body 블록을 override하는 예제. {{ }} 안의 내용은 print, {% %} 안은 제어문이 들어간다. 대략 있을 건 다 있음. 제대로 만든 PHP 같다고 누가 얘기했는데 누구였는지 까먹었다. 참고로 저 for 문 마지막에 : 찍어도 된다 (…). 레이아웃 코드에 제어문이 있는 걸 싫어하는 사람도 있지만 난 PHP도 싫어하지 않는 성향이라; 이 정도면 오히려 적절한 조합이 아닌가 싶다.

html 템플릿 파일 쪽만 봐도 내용을 어느 정도 알 수 있고, 중복 제거도 쉽고, python 쪽에서 미리 데이터를 구워(?)두기도 편한 편. 극단적으로 말하면 2000년 즈음의 VBA의 생산성을 다른 형태로 살렸다고도 할 수 있다.^[1]

경험담:

• python 코드 크기 절반으로. 기능도 추가했는데! (…)
• Jinja의 템플릿 언어가 python과 비슷하다. 적응하는데 5분이면 충분함.
• 페이지 레이아웃을 python 함수로 표현하는 건 무모했다. 적당한 hook을 만들기가 영; Jinja2의 템플릿 페이지 상속 기능으로 다 대체하는 편이 편했음.
• vim 용 문법 강조 파일도 제공함.
• JSON 응답도 템플릿 처리가 가능; 텍스트 형태의 응답이면 대부분 쉽게 될듯함.

라서 매우 편하게 작업했다. 팀 동료 몇 명에게 보여줬는데, 반응도 나쁘지 않았음.
내가 전에 작업했던 얘길 했더니 팀 동료 한 명은 이렇게 표현했음:

"이 생퀴 python으로 CGI 프로그래밍하지 마라"

Orz. 하..하지만 나 C로 CGI짜본 남잔데! (어이)

요약(?)

• 새 도구 좀 빨리 씁시다
• 머리가 나쁘면 손발이 고생

1. DB –> UI 로 넘기는 형태의 프로그래밍에서 작업할게 거의 없다

관련 글:

1. URI 삽질
2. Google Go on Android/nacl?
3. Adobe FlashSocketPolicyDaemon (python) 코드의 버그

VisualStudio 2010에서 포스트모텀 디버깅^[1] 할 때 심볼 서버, 소스 서버를 이용해서 디버깅하는데, 얘가 소스 서버에서 파일을 안 가져온다. 그래서 내가 추적한 순서 (…)

svn.exe 가 있는가 – 없으면 svn.exe cat … 이 실행 안될테니

심볼 서버 접근이 잘 되는가 – 안 그러면 .pdb 에서 소스 리스팅을 못할테니

.pdb에 소스 정보가 없는가 – …없으면 못 찾아올테니

…여기까지 했으니 전부 아니었음. .pdb도 잘 가져오고, 거기에 소스 인덱싱된 것도 있고, 거의 똑같은 설정의 다른 머신에선 디버깅 잘 되더라고 Orz

관리자 모드로 VS 2010을 재실행하고 나니 원인이 보이더라. 유저 홈 디렉터리를 d:\Users로 옮겼는데, 소스 서버 데이터를 c:\Users\rein\AppData\… 에 저장하는 것. 이전에는 일반 유저 권한이라 c:\Users 밑에 뭔가 못 만들어서 svn.exe cat이 실패한 모양. 이유는 모르겠지만, VS2010은 저 설정이 거의 하드 코딩되어 있거나, 홈 디렉터리 위치를 c:\에서 d:\로 바꾸려고 레지스트리에서 바꾼게 불충분한 모양.

좀 더 이유를 아시는 분은 설명 좀 (굽신굽신)

1. 혹은 사후 디버깅. 크래시 덤프를 가지고 진행하는 디버깅

관련 글:

1. rein’s world 2010 통계
2. C++ 0x 와 VS 2010 관련해서
3. VisualStudio 2010 체험(?)기

여기서 그의 명복을 빌어본다.

지난 주의 스티브 잡스 사망도 슬픈 일이지만, 개인적으로는 데니스 리치의 사망이 더 임팩트 큰 일.

간단히 말해서, 우리가 현재 쓰고 있는 SW의 가장 밑 바닥을 지탱하는 기술과 개념이 데니스 리치 손에서 태어났다.

• 시스템 프로그래밍의 가장 널리 쓰이는 C 언어의 창시자다; 우리가 쓰는 linux, Windows는(아마?)는 C 기반의 커널로 되어 있다. 대표적인 웹 서버 (아파치나 nginx) 역시 C로 만들었다. 그리고 이 C로 Unix를 재 작성(!)해서 `앞으로 OS를 어떻게 만드느냐’에 관해선 사실 상 결론을 내려버렸다.^[1]
• 내가 가장 사랑하는 *nix의 일관성 – 간단한 텍스트 기반 I/O의 프로그램을 연결해주는 파이프.
• 현대적인 개념의 C-runtime IO 방식을 고안.
• 내가 읽어 본 가장 간결하고 군더더기 없는 프로그래밍 책 – The C Programming Language의 저자.

좀 더 쓰자니 그냥 여길 링크: http://j.mearie.org/post/11385959754/rip-dennis-ritchie 에 더 잘 정리되어 있다.

1. 더불어 이 두 업적으로 1983년에 켄 톰슨과 함께 튜링 어워드를 받았다

관련 글:

1. 파일 대신 SQLite 쓰기
2. NDC 참관기: 마비노기 영웅전 자이언트 서버의 비밀
3. Gccgo in GCC mainline

• i7 2600 (7.6)
• intel 80G ssd (320 series) + sata hdd 500G (7.7)
• ddr3 1333MHz 4G (4G * 4 따로 달고 기존 달린 건 딴 머신으로) (7.6)
• nVidia 450 GTS (7.2)

우왕ㅋ굳ㅋ. 여기에 ㅊㅊㅅ 님이 "256G SSD + GTX 560ti" 주는 곳 있음! 이라고 츳코미를 날렸지만 뭐(…).

어제는 32 bits OS가 깔린 채로 와서, 밀고 새 OS 깔고 퇴근. 이 아래는 오늘의 삽질기.

드라이버 디스크를 집에서 만들어왔으나, 정작 이걸 묶어서 (.tar.gz) 가져왔다가 망함. gzip은 .NET의 System.IO.compression.GZipStream 으로 풀었으나 tar가 Orz. 여하튼 이건 꼼수로 넘어가서 각종 드라이버 설치. (여기까지 대략 오전 10시)

(사이에 모종의 사내 서버 문제가 풀리는 걸 확인…)

intel DP67BA 보드가 PS/2 슬롯이 없는지라, 이걸 위한 젠더 케이블을 링코 코엑스 점 가서 사와야 했음. 어차피 연필도 사야 하는 상황이라 겸사겸사 (…). 11시가 넘어서 네트워크에 연결 완료. (mac address 등록까지 걸리는 시간이…)

본격적으로 프로그램 설치 시작. 대략 VisualStudio 3종 세트^[1] – 이게 바로 라이브러리 개발자의 위용 – 와 기본적인 개발 도구를 설치 했음. 대략,

• 소스 컨트롤 3종 셋: p4, svn, git
• viemu / gvim
• perl + Debugging Tools for Windows
• python 및 내가 쓰는 패키지 일부
• 7-zip
• putty
• Google Chrome
• mRemote

정도를 설치. 여기서 p4, git, vim, putty, mRemote는 설정 파일과 registry도 이전;

점심 쯤 추가 DRAM 도착. 설치하고 ram-disk 4G 할당. 이제 스크래치는 전부 여기로^[2] 옮기게 설정. 근데 이 때 케이스 외곽에 꽂혀있는 드라이버 디스크 발견. 아침엔 무슨 삽질을 한 것인가…

소스 저장소에서 파일을 못 가져와서 뭐가 문제일까 고민했는데, 대략 회사 보안 정책 / 보안 도구 문제 ;; 이거 해결하고 마지막으로 (대략 오후 3시?) 설치된 프로그램 테스트. C# 프로젝트들은 빌드 되는데, C++ 프로젝트는 빌드가 안되네? CL.exe 실행하는 MSBuild task들이 예외를 던지더라…확인 결과 TEMP, TMP는 드라이브 루트면 안됨; MS 파일 시스템의 권한 설정 상 루트가 특이해서 생기는 문제인 듯. (thanx to Azyu)

OS 설치할 때 USB 키보드를 생각 없이 꽂아서 했더니 키보드 타입이 101key, type 3가 아닌 101 key type 1으로 잡혀버림; 망했다를 외치고 레지스트리를 고쳤다 Orz. 평소 하던 데로 ctrl, win key도 caps lock, ctrl 자리로 보냈음.

여하튼 이렇게 하루가 끝. 4시부터 대략 2 시간 동안은 크래시 덤프 디버깅하는 운명에 처하긴 했지만 말이다…

대략 빌드 속도는 프로젝트마다 차이가 있지만 1.5~3배 정도 빨라짐. 스크래치 디렉터리 옮기고 + CRT는 SSD에서 읽고 + CPU 파워가 올라간 덕택인 듯…

1. VS 2005, 2008, 2010; 그리고 각각에 속한 SP와 일부 hotfix 설치
2. TEMP, TMP, Windows\Temp, Windows\tmp, 그리고 VS의 C++ 메타 파일도 전부 이전

관련 글:

1. intel tbb 2.2 released
2. 프로그래머의 일상: OS 재설치
3. 가상화 서버 체험기

확인해보니 번역판에서 “제인”과 “잰”으로 처리한걸 확인. (전자는 제인 세이건, 후자는 마젤란 호의 선장임)
실제 발음은 모르겠지만 — 아시는 분은 제보 좀 (…) — 적절한 처리인 듯?

요 장난꾸러기가 태어난지 벌써 2년! 간간이 아플 때도 있긴 했지만 매우 건강히 크고 있다.

앞으로도 이 아이가 언제나 밝고 건강하게 자랐으면 한다.

관련 글:

1. 아들이 세상에 나온 지 벌써 200일!

• 팀장 권한으로 새 머신을 신청할 수 있다는 사실을 확인했고,
• (이를 이용해서) 4. 6년된 머신 대신 새 머신을 하나 받기로 했고
• 대략 원하는 스펙^[1]의 머신을 받게 될 듯 (예정?)

여하튼 대략 이러한 상황이 되었음. 이젠 내 머신에서도 릴리즈 빌드가 할만해질듯.

엄하게 팀장님 디스하는 상황이 (사내에서) 되어버린 건 좀 많이 죄송하지만 (……..)

댓글란에 적어준, 혹은 트위터 멘션으로 보내준 의견/사연들을 놓고 생각하면 소위 IT 업계란 곳도 프로그래머 생산성, 좁게봐서 하드웨어 공급면에 그다지 신경쓰지 않는 듯 하다. 일단 48개월 주기의 교체 일정에 대해선 사람들 반응이 매우 안 좋다.

교체 주기가 24개월 이하인 곳은 규모가 있는 한국계 회사 중엔 1개 (NHN)인 듯 하다. 나머지는 24개월, 36개월, 내가 있는 곳은 48개월(…).
기껏해야 연봉의  1~2% 수준인^[2] 수준일 머신 비용에 너무 신경 쓰는 건 너무 피곤하지 않은가.

뭐 국내 굴지의 모 기업에선 `이미 효과가 상당부분 인정되는 듀얼모니터‘를 절전이란 이유로 자제하라고 한다니 말 다했지.

혹은 모 금융 공기업 전산직은 연차 순(…)으로 좋은 머신을 주고, 5+년된 머신으로도 개발한다는데야…

원인은 뭘까? 내 나름대로 정리하자면,

• 프로그래머 연봉이 아직 낮은 축이라 생산성이 아니라 소요 비용에 신경쓴다
• 조직이 커지면 개발 부문 이외, 사무나 회계 등의 연간 목표도 중요하다
• 비슷하게, 상대적으로 컴퓨터 성능에 영향을 덜 받는 부문에서는 이런 얘기에 귀 기울이지 않는 듯

1. i7 2600, RAM 8G, SSD/HDD 듀얼 구성, …
2. 이번 모회사 공채에 신입사원에게 준다는 기준선이라던 연봉 3000만원 기준으로 150만원짜리 머신을 2년 쓴다면 대략 2.5%. 여러가지 부대 비용이 들어가는 걸 생각하면 대략 총비용을 2 년치로 나눠서 1.25%다 겨우… 연봉이 높아지면 이 비율은 더 작겠다

Joel on Software의 Joel Test 9번째 항목은 이러하다.

9. (예산이 허용하는 범위 내에서) 가장 좋은 툴을 사용하는가?

9. Do you use the best tools money can buy?

현재 내 상황은 이 항목에 대한 답이 `No’다. 나는 지금 939일 (2.6년) 된 장비와, 1689일 (=4.6년) 된 개발 장비 쓰고 있는데.<sup>[1]</sup> 연초에 교체 대상 컴퓨터를 조사해 갔던 것 같은데, 이 중 후자만 바꿔준다고 해놓고 교체없이 3Q가 끝나간다면 문제가 많지 않나. Workstation을 쓰고 있는 것도 아니고 지극히 일반적인 의미에서의 개발용 데스크 탑 쓰고 있는데 4+년의 교체 주기는 `회사가 생산성에 관심이 없거나’, `내 가치가 이런 것도 오래 걸릴 정도의 평가를 받고 있거나’가 아닐까.

혹시 SW회사에서 개발 장비 교체 문제에 감가상각 같은 정신 나간 기준을 들면 그 회사에서 나가야 한다는 강력한 신호인데 말이지.^[2] 아오.

나와 같이 일하는 동료들, 혹은 IRC나 기타 SNS 미디어를 통해 얘기하는 사람들은 잘 알고 있겠지만, 나 스스로 올해 정해놓은 시한이 하나 있다:

2007년 2월에 입사하면서 받은 개발 머신을 올해 말까지 계속 써야만 하는 상황이면 다른 회사를 알아보거나 창업하기로

적어놓으니 뭔가 하드웨어 구걸하는 꼬락서니긴 한데. 지금으론 슬슬 `내가 왜 이런 걸로 고민해야 하는가’의 한계선인 듯. 어차피 회사 다니는 것도 단순한 계약일 뿐,

내가 얻는 이익 (돈, 안정감, 일의 만족) > 내가 받는 피해 (짜증, 귀찮음, 시간 소모)

이 부등식이 만족되지 않으면^[3] 별로 더 연장할 이유가 없다. 연초에 연봉 왕창(~2x%?) 올려주면 뭐하냐.

얼마 전에 사람이 필요해서 학교 후배들이랑 열심히 이 사람 저 사람 알아보다가 좀 시들해진 것도 이거 탓이 꽤 큼. 4년 넘는 장비를 쓰는 회사로 `내가 후배를 데려오는 것’에 대한 도덕적인 거부감이 – 즉, 엔지니어에 대한 적당한 대우가 아니다 – 이유다. `반짝 반짝한’ 후배들 중 상당 수가 대학원에 묶여 있거나^[4] 이미 다른 회사를 다니면서 이직할 생각 없다고 말한 것도 이유이긴 하지만… 여하튼 Joel Test 9번 항목과 영 안 맞는 상황이니 내가 짱짱한 후배를 데려오기엔 죄책감이 든다.

1. 심지어 전자의 장비는 후자의 장비가 너무 느려서 퇴사자 컴퓨터 받아온 것
2. 물론 시중에는 개발을 랩탑에서 하는 이상한 곳도 있다. 데스크 탑 / 랩탑 선호로 선택하거나 둘 다 지급 하는 게 아니라 랩탑에서… 워크스테이션과 노트북과 테스트 용 서버(…)를 지급하는 회사도 있던데…
3. > 대신 >> 가 와야 맞겠지
4. 석사 학위 없으면 병역 특례 자격이 없으니

관련 글:

1. 내 생산성의 장애물
2. 난 아직도 커맨드라인이 더 편하다
3. 내가 원하는 test-runner 의 조건

내 조야한 이해 수준에도 불구하고, 책은 매우 즐겁게 읽었다. 얇지 않은 책이지만 대략 이틀 만에 다 봄. “엘리건트 유니버스”를 읽고 나서 LHC가 만들어진다는 점에 대해 꽤나 관심이 있었는데, 여기에 더 궁금하게 만들고 `왜 중요한지’에 대해서 설명해준 덕에 LHC에 대한 관심이 더 커진 듯.

아래는 약간 방향이 다른 리뷰(…). 사실 이건 제가 책 내용에 대한 기반 지식이 부족해서 그렇습니다 Orz.

1. 책의 전체 방향이랑은 조금 다른 얘기지만, 중간에 인용된 글 한 토막을 여기서 다시 인용해본다. (강조는 저자 분이 한 것)

패스토어 (로드 알랜드 주 상원의원): 이 프로젝트가 소련과 경쟁 관계에 있는 우리에게 제시하는 바는 없습니까?

윌슨 (페르미 랩의 설립자): 오직 장기적인 관점에서의 기술 발전에 있어서만 그렇습니다. 그 외에는 가속기는 이런 것들과 관련이 있습니다. 우리는 좋은 화가인가, 좋은 조각가인가, 훌륭한 시인인가와 같은 것들, 제가 말씀 드리는 것은 이 나라에서 우리가 진정 존중하고 명예롭게 여기는 것, 그것을 위해 나라를 사랑하게 하는 것들 말입니다. 그런 의미에서, 이 새로운 지식은 전적으로 국가의 명예와 관련이 있습니다. 이것은 우리나라를 지키는 일과 관련 있는 것이 아니라, 이 나라가 지킬 만한 가치가 있도록 하는 것과 관련이 있습니다.

지금 한국과, 한국의 사회를 구성하는 사람들은 “한국을 지킬 만한 가치가 있는 나라”로 만드는 부분을 늘리고 있는가? 이런 생각을 하니 굉장히 가슴 한 켠이 서늘해지더라. 정말 지킬 가치가 있는 나라인가?

2. LHC의 건설 비용과 운용 비용에 관한 것. 건설에 CERN이 사용한 비용은 6조 3000억 원. 그리고 검출기와 기타 시설 비용까지 추정하면 대략 10조 원 수준이라 한다.^[1] 운영비는 연간 약 2250억 원, 각 실험 팀의 실험비가 약 400억 원 정도로 예상된다고 한다.^[2] 내가 국가 규모의 예산을 이해할 능력이 없긴 하지만, 이 비용이 정말 큰가? 특히 내가 이 글의 1에서 인용한 내용을 생각하면 정말 큰가? 사대강의 올해 예산이 10조 원이란 주장도 있는 걸 생각하면 말이다…^[3]

예산을 더 들일수록 아마 그 기대 이익이 감소할 (수확체감; law of diminishing returns) 도로나 항만, 공항 같은 기반 시설에 돈을 계속해서 쓰는 게 유의미한가? (물론 기존 인프라를 유지 보수하는 비용이야 어쩔 수 없다고 해도) 과학과 문화에 대한 `사회 간접 자본’은 만들 생각이 없는가? 하다 못해 건물만 번드르르 지어놓은 도서관에 책이라도 채워 놓아야 하지 않을까.

3. LHC의 데이터를 처리하기 위한 시스템 구성에 더 관심이 가는 건 어쩔 수 없나(…)

1. 물론 책의 내용에 따르면 LEP 실험 때 이미 다음 세대의 가속기를 생각해서 터널을 파놓았기 때문에 그 부분의 비용은 추가로 들지 않아서 이런 거라곤 하지만
2. 책 446~447 페이지에 나온 내용
3. 한겨레 신문의 보도 참조; http://www.hani.co.kr/arti/society/society_general/428782.html

어제 Steam에서 구매한 (발매 일은 8/16)^[1] 게임. 가벼운(?) 게임 플레이를 제공하는 아기자기한 2D 게임을 원하던 터라 주저 없이 구매. 19.99 (이하 USD)를 할인해서 14.99던가에 판매하더라.. 다만 OST 합본 팩을 안 산걸 조금 후회… OST를 따로 사니 추가로 $5쯤 추가로 들었다 Orz.

전형적인 2D, 쿼터 뷰, 핵&슬래시 장르라고나 할까…
게임 배경이 배경이니 좀 음울하긴 하지만 색조는 화사(?)한 편에 가깝다. 2D에서 좀 더 보여주기 쉬운 색감이랄까.

화면 중앙 왼쪽의 다리 난간이 좀 이상하게 보일 거다. 던전(?)에 들어가면 일부 지역만 보이고/이동가능하고, 특정 경로로 이동하면 화면에 타일들이 `떠오른다’. 저 다리 난간도 떠올라서 생기는 중(…). 적도 그렇게 생긴 화면에 턱 하고 나타나는 경우가 있어서 나름대로 긴장감 유지에 좋음.

정말 좋았던 부분은 음악 + 해설(?). 주요 등장 인물 중 한 명이 주인공의 행동을 서술하는 형식인데. 이게 음성으로 낮게 깔려 나옴. 일부 동작 – 예를 들어 새로 얻은 무기로 열심히 물건들을 부순다거나, 추락한다거나, … – 에 반응해서 그에 대한 설명을 하기도 한다. 시작하자마자 떨어지고 나서 나오는 해설에 잠시 멍해지더라(…).

무기가 다양하게 나오는데 – 망치, 바셰티, 창(할버드?), 활, 저격소총, 샷건, 박격포, …이건 뭐라 설명할 수 없는 로켓포(?), 화염방사기 등… – 이에 대한 업그레이드 재료 + 돈으로 이 무기에 추가 옵션을 달아서 게임 플레이가 꽤 변한다. 로켓포 최종 업그레이드 같은 경우 자동 추적(…)옵션이 달리기도. (무려 범위 무기에 궁극 무기라 한 방에 거의 다 잡는데…)

스크린 샷에서는 터렛에 맞아가며 박격포를 조준하는 장면. 무기마다 컨트롤이 확연히 다른 것도 재미요소. 활은 오래 겨냥하면 더 세게 나가고, 저격 소총은 오래 겨냥하면 더 정확히 나가고… 박격포는 더 오래 겨냥해야 멀리 나가고(…). 일부 근접 무기는 오래 누르면 던진다거나 하기도; 그리고 무기 마스터 던전도 존재한다. 각 무기에 맞는 특정 미션을 수행하면 수행 수준에 따라 보상을 달리 주는 곳(…).

사원이란 시스템으로 난이도를 조절하는 것도 괜찮았음. 사원에 특정 신상을 활성화하면 특정 조건의 몹이 특정 형태로 더 강해지거나 하는 게 생김 – 물론 돈과 경험치도 더 줍니다… 그래서 별도의 난이도 시스템이 외부에 preset으로 주어지는 게 아니라 유저가 알아서 잘(?) 하면 되는 구조… 요즘처럼 게임이 대중화 된 상태에선 난이도에 대해 호 불호가 극명하기 때문에 이건 꽤 괜찮은 선택으로 보인다.

보너스: Steam 판매용 버전에만 있다는 깨알 같은 포탈 패러디. 특수 스킬을 고를 수 있는데 Gel Canister란 녀석이 있다(…). 이거에 대한 NPC들의 반응도 깨알 같다(…). 일단 `Who Knows Where’클리어 할 때 매우 편하다.

한 번 클리어한 던전에 또 진입할 수가 없는데, 대신 `Who Knows Where’라는 모드가 있다. 게임이 전체적으로 3종류의 던전 배경이 있는데 그 각각에 대해 몬스터의 웨이브가 k번 반복되는 그런 반복 던전. 돈은 여기서 모으면 됩니다. 어차피 스토리를 이해하기 위해선 꼭 한 번 씩은 가야 하니…

마을은 왼쪽에 보이는 노란 아이콘 (검은 배경) 같은 상점(?)류가 총 6곳 있다. 처음엔 0곳이지만 스토리를 진행하다 보면 늘어나고, 각각이 지원하는 기능이 다름. 하지만 마을은 큰 의미가 없는 게임이라(…).

전체적으로 올해 나온 게임 중엔 가장 맘에 듬. 짧다는 것만 빼고(…). 시작해서 엔딩 볼 때 까지 실 플레이 시간은 5시간 미만?. 물론 두 번 엔딩 봐야 하고(…), 업적도 채워야 하니 그보다 더 걸리긴 함. 일단 가격도 그다지 비싸지 않으니 추천. 이 게임 분류가 인디긴 하지만 무려 HD 해상도도 지원하고 / 그래픽 / 사운드(!!) 모두 나무랄 곳이 없다.

PS. 여기서 잠시 스포일러 성 멘트 하나. 게임 엔딩 선택지가 commit or rollback이다. 이런 공돌이들 같으니(?).

1. XBox Live Arcade를 통해서는 지난 달에 발매되긴 했다.

관련 글:

1. 게임물 등급 심의 제도에 관한 생각
2. Project DarkStar 는 왜 실패했을까?
3. Tomb Raider: Underworld

현재 상황은 대략 망해가는 프로젝트인 것 같다.

마지막 stable version이 작년 12월에 릴리즈. 다운로드 수는 누적으로 70회;

마지막에 등록된 티켓(trac issue)이 올해 2월.

위키 최종 편집 시간이 6월^[1] 포럼에만 활동이 약간 있는 정도. 이 정도면 거의 활동없는 프로젝트라고 봐야하나?

(실질적으로) 사용하는 곳이 없고 / 개발 팀도 응집되지 않은 듯 하고 (커밋한 사람 수를 보면…) / 앞으로 비전이 있는 프로젝트는 못 될듯 하다.

1. 그 이전에 올해 들어와서 수정된 페이지가 6개 , 그리고 각각 1번씩만 수정

관련 글:

1. Project DarkStar 는 왜 실패했을까?
2. Project Dark Star 개발 중단 및 오픈 소스화

• 유닛 테스트(혹은 기능 테스트)를 돌렸는데 끝이 안난다거나
• 컴파일러 메시지가 쭉 뜨고있거나 혹은 링커/코드 생성 메시지에서 끝이 안나고 있다거나
• 빌드 서버에서 끝없이 노란 불(=빌드 중)이 들어가 있거나
• 안티바이러스 스캐닝이 하드 디스크를 긁고 있거나^[1]

여하튼 이런 일에 신경이 쓰이면 뭔가 발이 잡힌 것 같고, 집중이 퍽하고 깨진다.

개인적으로는 이거에 대해 약간의 우회책을 넣어 대처하고 있다(=성격 나빠지고 있다).

우선 빌드 속도와 테스트 케이스 실행 속도.
google test 를 써서 작성한 테스트인 경우 실행 파일 생성 시간이 바뀌면 자동으로 테스트를 실행하고 실패하면 화면 오른쪽 아래에 커다란 빨간 팝업을 뜨게 했다. 클릭하기 전에는 안 사라지는 그런 팝업임.

대충 여기 화면 오른쪽 아래에 나오는 식.^[2] 반대로 모든 테스트가 성공하면 쬐끄마한 녹색 팝업을 수 초쯤 띄우고 사라지게 했다. 이전에 빨간 팝업이 있었으면 그것도 지우고…
상대적으로 좀 덜 기다리고 (문제가 생기면 알려주고) 다른 작업을 할 수 있게;

이전 포스팅에서 말했던 원래 문제(긴 테스트 시간)도 약간은 견딜만한 문제정도로 바꿨다. 다만 이 방법도 항상 통하는건 아니다. 코드 작성 -> 빌드 -> 실행 -> 보고의 한 싸이클이 너무 길면 큰 도움이 안된다. 테스트가 다 돌기도 전에 다음 싸이클의 코드 작업이 끝나고 빌드 버튼을 누르면 이미 실패. 엄한 링크 오류나 보게 된다.

그덕에 직전 포스팅에 나온 작업에 착수. 테스트 실행시간을 줄이고나니 어지간해선 — 멍청한 안티바이러스라거나가 빌드 시간을 잡아먹지 않는다면 — 견딜 수 있는 범위 내로 어떻게 어떻게 되더라.

빌드 서버 결과기다리는 것도 예전엔 상태 보면서 기다렸는데, 요즘은 신경 끄고 딴 일하다 실패 팝업 뜨면 그 때 보기는 방식으로 가고 있다. 문제는 내가 고친 프로젝트 말고 다른 사람 프로젝트 깨지면 그것도 신경쓰게 된다는 거지만;

하지만 이런 짓하면 성공적으로 전진하는 경우야 좋지만 실패했을 때의 페널티가 크다. 내가 뭘 생각하고 있었나도 돌아봐야하고, 문제를 풀고나서도 다시 원래있던 곳으로 사고를 돌려야하니…

여하튼 세 줄 요약

• 작업 싸이클에 드는 시간이 짧아야 집중해서 일할 수 있다
• 특정 단계가 너무 길다 싶으면 비동기로 바꾸고, 보고할만한 내용이 있으면 눈에 잘 띄게 알려주자(소리나 불빛 덜 방해되는 영역의 팝업)
• 이래도 안되면^[3] 하드웨어에 투자해야. 뭐 난 그게 안되서 테스트 코드를 최적화했다만(…)

1. 물론 이 경우에는 정말 아무 것도 할 수 없기 때문에, 수단과 방법을 가리지 않고 안티 바이러스를 종료한다. 안 꺼지면 파워 버튼을 연타
2. 화면 오른쪽 아래 좀 탁하게 찍힌 화면이 그것. 화면 해상도가 2048 by 1152 임을 감안하고 보실 듯
3. 사실이게 제일 싼 방법 같은데

관련 글:

1. VisualStudio 2010 체험(?)기
2. svn tag만들 때 svn:externals 리비젼 고정하기
3. 서버 설치 기록 post-mortem

원래의 구현은 엑셀 파일(.xls)을 서버 시작시점에 읽어서 특정 시트를 각 시트에 맞는 데이터 타입으로 바꿔서 저장하는 것. 이를 위해 Microsoft Office용 일부 dll (MS Visual Studio 2010 Tools for Office Runtime, AccessDatabaseEngine_x64)을 필요로 함. 이걸 써서 OLE로 값을 읽는다. 그리고 좀 엄하게도(…) 일부 셀은 리스트, 그것도 구조체 비슷한 것의 리스트를 적당한 토큰으로 구분해놨다. 이 부분은 문자열로 읽고 정규 표현식으로 분리해서 메모리에 올린다.

개인적으로 이 구현은 굉장히 맘에 안들었다. 문제라고 생각하는 부분은 두 가지. 일단 속도. 백 개 정도의 테스트 케이스를 실행하면 140초쯤 걸린다. 교체 대상인(…) 내 Q8400에서 약 140초쯤 걸림. 물론 콘솔 출력을 날려버리면 (> nul) 8x ~ 9x초 수준까진 줄어든다. 느린 부분이,

• OLE로 데이터 가져오는 부분(700ms)
• regex 로 데이터 언마셜링하는 부분(500ms).

물론 기능 테스트에서만 전체 데이터를 로드하는 거지만 전체 테스트가 느려지는 건 스트레스.  그리고 60% 이상의 케이스가 기능 테스트이고, 이 때마다 서버 런타임 전체를 초기화 하기 때문에 여기 들어가는 시간이 매우 스트레스였다.
일단 OLE에서 데이터 읽는 부분은 처음 읽을 때만 사용하고, 이 때 데이터를 텍스트 형태로 메모리에 올린 후, 그 이후 테스트 케이스에선 이걸 읽게 했더니 꽤 빨라지긴 했지만(140초->100초) 여전히 남은 정규 표현식 Orz. 그리고 이건 데이터 늘어나면 더 느려질게 뻔하니…

두 번째는 외부 의존성. 서비스하기 위해 추가로 설치해야 하는 외부 프로그램이 있는게 좀…

그래서 (a) SQLite 테이블로 바꾸는 스크립트, (b) SQLite 테이블에서 데이터 읽는 코드 이렇게 두 가지를 만들었다.

우선 엑셀 파일(.xls)로 되어있는 데이터를 SQLite 테이블로 변환하는 코드를 작성했다. python xlrd 팩키지로 특정 시트를 읽고 여기 있는 첫 번째 행에 있는 데이터를 열 이름으로 처리하고 나머지 행에서 셀 데이터 타입을 받은 후 여기서 빈 셀이 아닌 것의 주요 타입을 열 타입으로 고름. 다만 정수/실수 선택은 적당히 실제 셀 값을 뒤져서 골랐다. 근데 SQLite에 문자열로 넣고 실행시간에 select한 후 읽는 쪽에서 고르는 게 나을지도 모르겠다. 이 테이블에 개별 행을 하나 씩 읽어서 삽입.  (INSERT ?, ?, … , args)로 끝.

마지막으로 이전에 정규 표현식으로 처리하던 부분을 python에서 해석하는 단계에서 별도 테이블을 생성하게 바꿨다. 나중에 유효성 검사할 걸 생각하면 역시 단계가 하나 더 있어야 하고, 이걸 여러 번 할 이유가 없거든…

SQLite에서 데이터 읽는 부분은 흔히 하는 sqlite3 open, prepare(SELECT 구문), 데이터 다 나올 때 까지 step k번으로 해결. OLE로 읽는 거 보다 당연히 빠르고 텍스트로 캐싱한 것 읽는 거보다 조금 늦은 수준으로 끝나더라.

이제 외부 의존성은 없고(sqlite.c가 추가되지만) 테스트 케이스 실행은 50초 수준까지 줄었다. nul로 콘솔 출력 보내면 20초 미만…

여하튼 이거 오늘 git에서 메인 스트림으로 보내버리고 딴 버그 잡고나니 하루가 지나가긴 했다. (상당 수의 작업은 금요일에 했음)

1. 링크에 적어놓은 말 자체는 Hacker News 페이지의 제목이고, 실제로 연결된 페이지는 SQLite 사이트의 화이트 페이퍼 페이지다

관련 글:

1. 평범하지 않게 파일 복사하기
2. TLS, DLL, 그리고 Legacy Windows
3. 당신 역시 초보일 수 있습니다

MS Windows에서 글 쓰는 거라면 Windows Live Writer가 워낙 훌륭해서 되거나 말거나 크게 신경 안 썼는데, 요즘 Windows 부팅하는 시간이 너무 적어서 결국 불편함을 못 견디고 재설치했다.

설치는 다음과 같은 순서로 진행했다.

1. 기존 디렉터리 백업 (blog 디렉터리를 백업 디렉터리로 변경)
2. 새로 설치 (svn checkout 으로 통채로 blog 디렉터리에 가져다 설치)
3. 기존 설정 파일 복사 (wp-config.php, wlwmanifest.xml, .htaccess)
4. 기존 테마 파일 복사 (wp-content/theme 디렉터리를 백업에서 blog로 복사)
5. 기존 플러그인 복사 (wp-content/plugins 디렉터리를 백업에서 blog로 복사)
6. 기존 이미지 파일 복사 (wp-content/uploads 디렉터리를 백업에서 blog로 복사)

만에 하나 있을지 모를 문제 때문에 캐싱 플러그인 (wp-super-cache는 비활성화 했음)

혹시 깨진 링크, 깨진 이미지, 비정상 동작하는 부분이 발견되면 댓글로 알려주시면 감사하겠습니다(…).

관련 글:

1. 일반 사용자용 제품에 당연히 기대해야 하는 것
2. Blog 이사 아닌 이사
3. Blog 도메인 이전 및 기타 등등