뭐, 이름은 거창하게 프레임워크라고 붙였지만 사실상 아무것도 아니다. 최근 KDE 번역을 다시 시작하면서 통계를 내 줄 무언가가 필요해서 파이썬 CGI 기반의 웹 페이지를 짰다. 디렉터리를 찍어 주면 po 파일을 돌면서 통계를 내는 것이다. 그런데 그것을 짠 것이 느낌학상 왠지 화근이 된 것 같다. php 기반의 페이지와 파이썬 기반의 페이지가 섞여있는 것이 못마땅했던가 결국 모두 파이썬 기반으로 갈아엎고 말았다.

비록 내가 Django를 배워 보려고 했지만 튜토리얼을 한 번 보고 좌절해 버려서 내 목적에 맞는 소형 웹 프레임워크를 만들기로 했다. 이름하여 발로만든™ 파이썬 프레임워크. 제작하는 데 들어간 시간은 얼마나 걸렸는가 모르겠지만 결과물은 시간에 비해서는 만족스러웠다. 맨 먼저 한 작업은 현재 홈페이지의 레이아웃 중에서 공통되는 부분을 빼내는 작업이었다. 아래 그림을 보자.

뼈대 레이아웃

$로 둘러싸인 부분은 파이썬의 string.Template이 사용할 부분으로 여기에 실제 내용으로 대체된다. INCLUDE_로 시작하는 부분을 한번에 처리하고, string.Template을 여러 번 쓰는 것을 방지하기 위해서 공통되는 부분을 묶어서 하나의 파이썬 파일에 묶었다. 그 다음 제목과 내용만 써 주면 문서가 만들어지는 함수를 만들었다.

자. 파이썬 CGI를 만들면서 했던 가장 큰 실수 중 하나가 HTTP 헤더를 엉터리로 보내는 것이었다. Content-type 헤더를 보내지 않으면 브라우저가 어떻게 처리할 지 알 수 없기 때문에 text/html을 꼭 날려 주어야 한다. 실제로 이것 때문에 왜 웹 페이자가 안 나오는가에 대해서 엄청난 고민을 하였다. 알고 보니 헤더 문제였던 것을 알고 엄청 난리를 피웠던 적이 있다.

하여간 이 common.py는 공개하기 너무 민망할 정도로 간단해서… 그래서 이름이 발로만든 프레임워크가 되었다. 제작하는 데 썼던 힌트들은 다음과 같다.

• 파이썬 CGI 모듈
• 파이썬 string 모듈

이제 이 발로 만든 프레임워크를 살찌우는 일만 남았다.

나는 리눅스와 윈도의 파폭 책갈피를 동기화시키기 위해서, Google Browser Sync라는 확장 기능을 사용한다. 비록 파폭에서만 동작한다는 한계가 있지만 나는 나름대로 만족하고 있다. 그런데 어느 날. 하드디스크가 125MB밖에 남지 않는 난감한 사태가 오는 바람에 Filelight를 켜고 디스크에서 어떤 부분이 공간을 많이 잡아먹는지 탐사하고 있었다. 다른 것들은 예상대로인데, .mozilla 폴더가 1.7GB를 먹고 있었다. 어라?

들어가 보았다. 내 프로필까지 가 보았다. 어라? browserstate-logs 폴더? 의심이 가서 열어 보니까 Google Browser Sync가 남기고 있는 파일이었다. 나는 이 파일들이 왠지 수상해서, 한 번 정체가 무엇인지 확인해 보았다. 일단 그 파일들의 용량이 어느 정도 되는지부터 확인해 보았다.

psj@cluster-0:~/.mozilla/firefox/uyh1wxlr.default/browserstate-logs$ ls -lah
합계 293M
drwx——  2 psj psj 4.0K 2007-12-12 11:47 .
drwx—— 10 psj psj 4.0K 2007-12-12 11:47 ..
…. 중간 생략 ….
-rw-r–r–  1 psj psj 208M 2007-12-11 20:49 log-20071211-171756-507.txt
…. 중간 생략 ….

이것은 최근 다시 출력을 얻은 것으로, 하드디스크 정리할 때만 해도 400MB 이상의 파일이 있었다. 그런데 어라라? 어라라? 왜 파일 하나가 수백 MB씩 잡아먹지? 의아해하고 있었다. 아니 책갈피 데이터가 수백 MB를 차지할 이유가 없는데… 하면서 파일들은 열어 보았다. 그랬더니… 자바스크립트 콘솔의 오류 정보, 브라우저 히스토리, 등등등의 기록을 엄청 공간 낭비가 심해 보이는 형식으로 기록하고 있었다. 덜덜덜.

그래서 미련없이 그 파일들을 다 지워 주니 디스크 공간이 많이 빠졌다. 넵 구글 무섭군요. 책갈피 동기화를 위한 도구를 바꿔야겠습니다.

오늘자 KDE 4 번역 상태. 전번에는 5000까지 갔는데...

요즘 힘이 없어서 KDE 4 번역도 전만큼 의욕적으로 하지 못하고 있다. 카이스트 1차 발표가 오늘 났는데다가 여기저기서 들려오는 흉흉한 소문들. 그 덕분에 요즘에는 무언가를 손에 잡기도 싫어졌다. 그러나 마지막 중간고사가 다가오고 있고, 성균관대 면접(20일) – 중간고사(22~25일) – 정보과학회 발표(26일) – 리츠메이칸(29일~11월 5일) – SAC(11월 7일~10일)이 기다리고 있기 때문에 그 이전에 무언가를 해 두고도 싶다.

사실 KDE 4 번역 작업이 멈춘 것처럼 보인 이유는 이제 간단한 번역 작업은 다 끝났기 때문이다. HSL에 있었던 소스 파일들을 가져오는 작업도 진행 중이긴 하지만, KDE 4에만 있는 KWin의 컴포지팅 같은 부분들 같은 경우에는 새로 번역해야 한다. 또한 긴 옵션들 중에서도 번역이 안 된 것이 너무 많기 때문에 번역자는 쓰러져 가고 있다. 다행히도 오늘 Konqueror의 HTML 보기 설정 부분을 다 끝냈고 이제 좀 만만한 것들만 남기 시작했다.

가장 큰 이유는 오늘 아침에 받은 VirtualBox 1.5.2 버전이 나오니깐 문자열을 정비해 달라는 안내 메일을 받고 나서였다. 그것 덕분에 충격을 받고 그 동안 너무 방치해 왔던 번역을 다시 가다듬어야겠다는 생각을 하게 되었다. 그래서 낮 시간 동안 버닝해서 파일 하나를 접수하고 밤 쯤에 몇 개 더 정비해서 커밋할까 생각하고 있다.

어쨌든 KDE 4 가 나오기 전까지 목표 40%는 꼭 달성하고 말 것이다. 그 이전에 중간고사나 어떻게 끝내 주기를… 라멘.

추석 때 노트북을 들고가는 모험을 해 보았다. 당연히 내 사촌형들의 아이들이 걱정되었지만 뭐 쟤들을 떨어트릴 수 있는 무기가 있었다. 다른 사촌형이 들고 왔던 NDSL에 혼이 빠졌고, (이럴 때는 리눅스 만세!!!) 덕분에 내 노트북에 자연스레 손이 안 가게 되었다. 그러나 NDSL의 배터리가 다 떨어지는 것에서 고생이 시작되었다. 자 푸규루, 가랏!

내가 오래 전에 긁어 두었던 푸규루를 꺼냈다. 저 페이지에서도 알 수 있겠지만 푸규루는 정말 개념이 없는 애니다. 내가 아는 한 사람의 평은 “새로 디스플레이를 설치할 때 테스트용으로 좋다”는 것도 있었다. 또한 양모씨는 “카이스트 면접 끝나고 나서 보려고 내 PMP에 넣으라”고 시켰다가, 내 V43에서 재생이 실패하는 바람에 나중에 전편을 감상했다. 그리고 한 술 더 떠서 푸규루 엔딩곡(이것도 에피소드마다 다르다)을 꺼내서 “햏력 증진에 좋다”는 평을 했다.

자, 이제 내 사촌형들의 아이들을 대상으로 실험해 보겠다. 실험 대상은 모두 초등학교 1학년 이하의 어린이들이다. 1화와 2화는 정말 단순해서 쉽게 넘어갔다. 다행히도 화면에 계속 눈을 대고 있어서 안심할 수 있었다. 진짜 문제는 이 다음부터 시작한다. 3화부터는 정말 손에 땀을 쥐기 시작한다. 거기서부터 주위가 산만해지기 시작한다. 비슷한 장면들과 비슷한 이야기를 계속 보다 보면 그 어느 누구도 나중에 가면 정말 정신이 멍해지기 시작할 것이다. 실험 대상들이 멍해지는 시점은 대략 8화 주변이었다.

9화 부터는 아주 “이거 언제 끝나냐!” 하면서 나를 보채기 시작했다. 결국 10화, 11화, 12화를 거쳐서 13화로 다 가니까 실험 대상들은 노트북에서 떨어져 나갔다. 그 덕분에 나는 KDE 번역에 집중할 수 있게 되었다. 낄낄. 내 사촌형의 아이들에게만 통할지는 잘 모르겠지만, 주변에 어린 애들을 떼어 놓는데도 푸규루가 효과가 있는 것 같다는 게 실험 결과이다.

과거에 생각하고 있었던 삽질을 포함해서 결국 오늘 아침 TextCube로 업그레이드를 단행했다. 아주 오랜 옛날 Drupal을 쓰던 시절의 글 번호는 “100”으로 시작했고, 잠시 tistory를 쓰던 시절의 글 번호는 “1”로 시작했다. 설상가상으로 내 서버로 다시 들어왔을 때 글 번호도 꼬여 버렸다. 그걸 해결할 수 있는 유일한 방법은 DB를 찌르는 것이었는데, 그렇게 하기는 귀찮아서 백업 파일로 내보낸 다음 복원해야만 했다.

백업 파일을 내보내니까 70MB 정도 되어서, 웬만한 편집기로는 열지조차 못하는 양이 되었다. 결국 VirtualBox 상의 UltraEdit를 사용해서 글 ID가 꼬이지 않았는가 다시 한 번 살펴보았다. 이 과정에서 과거에 ID로 걸렸던 외부 링크들이 문제가 되는데, 이 때는 검색을 해서 다시 들어오기 바란다. 또한 절대 주소들을 새로 작성해 주었다. 그렇게 삽질을 해 가면서 xml 파일을 일단 만들었다.

그 다음 깨끗한 TextCube를 설치했다. 특별히 더 해 줘야 할 삽질 같은 건 없었다. 그리고 관리자 모드로 들어가서 기존의 백업 파일을 다시 올려 주었더니 끝났다. 공지 글이 문제긴 하지만 꼬였던 글 번호도 다시 풀리고 입력해 준 절대 주소도 잘 작동하고 있다. 기존 스킨에 있었던 Last.fm 사이드바는 만들기 귀찮아서 일단 빼 두었지만, 나중에 시간이 나면 만들어 볼 작정이다.

번호들을 푸는 건 삽질이지만 풀었을 때 장점은… 그냥 삽질한 게 좋다는 것. ㅍ