오늘 소스포지에서 메일이 하나 왔는데 마치 개인메일처럼 와서 자세히 읽어 봤습니다. 내용을 보니 소스포지 관리자가 C 카테고리에 들어있는 프로젝트 어드민 전부에게 1:1로 보낸 내용이군요 --;;

내용은 IBM이 총 170개의 iPod mini를 소스포지 개발자들에게 준다는 내용입니다. (행사 URL) 단, 아무나 주는 것은 아니고 다음 조건을 만족해야 하는군요. 흐흐

• 결정을 하는 12월 초에 LinuxPPC 플랫폼을 지원하는 프로젝트일 것.

• 현재 이미 LinuxPPC에 포팅된 프로젝트면 불가능.

• 자바 또는 스크립트(php,python,perl,ruby...) 기반이면 안 됨.

• 서버 기반 프로그램일 것. (인스턴트 메신저 같은 데스크탑 기반이면 안 됨)

• 소스포지 약관에 동의할 것

• 9월 24일 자정(미국 동부시간)까지 신청한 프로젝트에 한해 12월 초에 결정을 하게 됨.

저는 이 조건들을 만족하는 프로젝트가 소스포지에 1개 (openseed) 밖에 없어서 아직 고민 중입니다. --; openseed는 버린지 3년 넘은 프로젝트인데 -ㅇ- 으흐흐 조건을 만족하는 분들은 한 번씩 해보세요 +_+

Sun Microsystems에서는 최근에 솔라리스 10에 탑재될 새로운 파일 시스템인 ZFS에 대한 대폭적인 정보를 메일링리스트와 웹 페이지를 통해서 제공하기 시작했습니다. ZFS의 Z는 zsh의 z처럼 마지막이라는 뜻이라는군요. 지금까지 아주 다양한 파일시스템들이 왔다갔다 했던 다른 운영체제들과는 달리 계속 FFS/UFS계열의 파일시스템을 사용해 왔었는데, 이번에 ZFS로 옮겨감으로써 한꺼번에 다른 파일시스템들의 기능/성능/확장성 모두를 뛰어넘으려고 하는 모양입니다.

우선 가장 독특한 특징은 엔디안 중립적인 구조를 많은 부분에서 채용해서, 스팍에서 쓰던 디스크를 바로 x86에서 쓸 수 있다고는 하는데, 엔디안 마크를 일일이 쓰는 것인지, 한 엔디안으로 통일한 것인지는 잘 모르겠군요. 그리고, 현재 대부분의 파일시스템들이 32비트 또는 64비트 기반인 반면에, ZFS에서는 128비트 주소를 사용하기 때문에, 논리적으로 현재의 시스템들보다 160억배 크기까지 확장될 수 있다고 합니다. 128비트 기반을 하는 것에 대해서 freebsd-hackers 메일링리스트에서 논평이 몇 있었는데 재미있는 평으로 "Populating 128-bit file systems would exceed the quantum limits of earth-based storage. You couldn't fill a 128-bit storage pool without boiling the oceans." (128비트 파일 시스템은 지구 기반의 스토리지의 퀀텀 한계를 초과할 것이다. 바다를 다 끓이기 전까지는 128비트 스토리지를 다 채우지 못할 것이다) 라고 엄살을 떠는 사람도 있는데, 사실은 지금까지 생산된 어떤 트랜지스터 속의 원자수도 2128개를 넘고, 웬만한 박테리아도 그정도 원자 수는 넘는다고 다른 사람이 꼬집어 줬습니다. 흐흐흐. (아니 그럼 원자 단위로 저장을 하자는 말이냐! =3) 그런데 128비트 스토리지를 찾아댕기려면 어떻게 해야하느냐, 배드섹터 체크하다가 10년 가는 것 아닌가 뭐 이런 잡다한 얘기가 나오긴 했는데, 대체로 언젠가는 128비트가 쓸모가 있을 날도 올 지도 모른다... 난 결론으로 간 듯 합니다. 흐흐;

ZFS의 또 다른 멋진 기능으로 RAID를 무색케하는 스토리지 풀 기반의 볼륨 관리 시스템(GEOM이 아예 파일 시스템 레이어로 내려간 듯한 느낌이..)과 fsck, newfs 등의 파일 시스템 관리가 전혀 필요 없이 스스로 관리한다는 점. (구체적으로 어떤지는..) 데이터 무결성을 위해 완전히 데이터가 커밋(sync)되기 전까지는 절대로 이전의 정보를 덮어 쓰지 않는 것이나, 심지어 파일시스템 주제에 롤백까지 지원한다는군요. 아무래도 저널링 파일 시스템들과 유사한 혜택들을 저널링없이도 충분히 괜찮게 구현을 하려는 것이 목적인 듯 합니다. 그동안 유독 엄청나게 느린 파일시스템으로 사용자들을 괴롭혀 온 Solaris가 10에 이르러 이제 극락으로 변신할 수 있을지 릴리스가 기대가 됩니다.

으흐흐. 요즘 집 컴퓨터가 게임방 컴퓨터화를 거듭하고 있습니다. 온갖 게임에 메신저에 -ㅇ-; 아이고 ;_;

어제는 토끼군의 소개로 DJ Max라는 게임을 했습니다. 예전에 날리던 BM98류의 온라인 게임인데 전에 어디선가 온라인화를 한번 시도했다가 말아먹고 그 뒤로는 온라인 리듬비트게임이 별로 안 나오다가 이제 새로 나왔군요. BM98을 잘 하는 건 아니지만 그래도 아주 좋아하며 했었기 때문에 이거 참 정말 재미있습니다. +_+

흐흐 예전에 리듬비트류 게임 만드는 아르바이트를 했을 때 곡들이 참 좋았는데 게임도 못 뜨고 사장돼서 참 마음이 슬펐는데, 이 게임들 곡들도 역시 비트가 단순한 것이 아주 마음에 듭니다. (에.. -O-) 특히 "아침형인간"과 "Funky Chups"는 아주 발랄한 것이 좋습니다. 이히히. 옛날 기억들이 새록새록 나는군요. 멀티플레이를 하는 경우에는 자기 화면 옆에 쪼그맣게 다른 사람 화면들도 나오는데, 어제 같이 게임을 했던 토끼군과 토끼군의 동생은 어찌나 잘 하는지 난이도 7짜리를 MAX로 .. 역시 게임은 선천적인 뭔가가 있어야.. ;_;

리듬비트아케이드 팬들이라면 해보면 꼭 좋을 듯 합니다. ^^;

그동안 "URL을 항상 UTF-8로 보냄을 끄시오." 이런 류의 불친절하고 무식하기 짝이 없는 문구를 여러 사이트에서 보아 왔습니다. 이제 더 이상 주소창에 한글을 쓰기 위해서, 최종 사용자가 인코딩을 신경써야 할 필요가 없습니다!

원래 URI에서는 US-ASCII외의 문자는 사용이 전혀 금지되어있습니다. 따라서, URI에는 한글을 못 쓰는 것이 당연한데, 이를 퍼센트 이스케이프를 사용해서 EUC-KR이나 UTF-8로 인코딩해서 보내 왔습니다. MSIE의 디폴트 옵션과, 모질라 계열 브라우저에서는 UTF-8을, Safari와 맥용 MSIE, 국내의 많은 사이트에서는 EUC-KR로 인코딩한 것을 쓰고 있어서, 사실 여러 인코딩의 난무에 제대로 보이게 해 주기가 곤란했고, 가장 심각한 경우가 블로그 trackback의 초기 스펙에서 GET으로 보내는 바람에 자기 사이트와 상대 사이트의 인코딩이 같아야만 트랙백이 깨지지 않고 보내는 문제까지도 발생했었습니다.

곧 RFC에 등록될 draft-duerst-iri-09에서는 이 문제를 해결하기 위해서, IRI를 소개했습니다. 이 작업은 W3C의 주도로 이뤄지고 있는데, Microsoft 직원도 공동 저자로 표기되어있는 걸로 봐서 MSIE에서도 곧 지원하지 않을까 합니다. (물론 CSSv3같이 자기가 만들고 자기가 지원 안하는 경우가 있을지도 모르겠지만 --;)

IRI에서는 그냥 인코딩을 UTF-8로 쓰는 것이나 사실 비슷하긴 한데, 오른쪽에서 왼쪽으로 쓰는 언어를 위한 BiDi 지원에 대한 고려를 좀 추가하였고, 정규화를 NKFC또는 NFC로 명시해서 웹서버를 좀 더 편하게 해 주고 있습니다. 단, IRI는 URI를 기존에 쓰던 위치에서는 그대로 못 쓴다고 명시를 하고 있는데요. 즉, 아직 "URI"를 쓴다고 표시하고 있는 표준에 대해서는 그 위치에 IRI를 바로 쓰는 것이 아니라 IRI를 URI로 변환한 다음에 쓰도록 하고 있습니다. 하지만, IRI를 URI로 변환하면 사실상 정규화와 BiDi를 제외하고는 거의 그냥 UTF-8에 퍼센트 인코딩만 추가한 것이나 비슷한데, "항상 UTF-8로 URL을 보냄을 끄시오."하는 우리나라 웹 실정과 맞을 지는 의문입니다. --;;

파이썬의 urllib{,2}에서도 draft-duerst-iri-09가 RFC에 등록되자 마자 바로 지원을 할 예정입니다.

이제 슬슬 기나긴 솔로 생활도 탈출하고.. 정상인으로 돌아가기 위한 계획의 일환으로 몸무게 정상화 작전을 조금씩 해보려고 생각을 하고 있습니다. 그래서, 좀 더 과학적인 모니터링을 위해서 rrdtool로 몸무게 그래프를 만들었습니다.

이 그래프를 이용해서 심각하게 분석을 해 보니까, 회사에서 밤새는 날 집중적으로 체중이 불어서 그 이후에 슬금슬금 내려오다가 또 밤새면 팍~ 오르고 그런 패턴이군요.. 결과적으로는 회사에서 밤을 안 새던가.. 밤새면서 뭘 먹지를 말던가 해야겠습니다. ㅠ.ㅠ

아직은 직접 몸무게를 재서 rrdupdate를 수동으로 해 줘야 하지만.. 앞으로는 크론으로 하루에 한번 자동으로 자는 사이에 몸무게와 체지방을 재서 기록해주는 날이 오기를~ 혹시 관심있는 분은 OpenLook CVS에서 다운 받아서 설치해 보세용~

요새 IRC의 jiwon님이 VM 관련 수업을 들으시면서 이것 저것 많이 알려주셔서 VM 관련 논문을 여럿 읽고 있습니다. 어제는 퇴근길(일요일!)에 뭐 볼 만한 것 없을까 찾다가 Are CLI-based Virtual Machines Suitable for High Performance Computing？이라는 논문을 읽었습니다.

이 논문은 주로 대규모 수치연산이나 데이터 처리에 사용되는 환경으로 직접 C나 Fortran처럼 네이티브 코드를 생산하는 컴파일러를 사용하지 않고, Java나 CLI같은 가상 기계 환경을 사용하는 경우도 쓸만한가에 대해 논하고 있습니다. 사실 그런데, 이 얘기를 듣기 전까지는 그 비싼 기계를 네이티브 코드로 안 돌리고 VM 코드로 돌릴 사람이 있을까 생각하긴 했는데, 진지하게 Java로 돌리고 그러는 커뮤니티도 있고 그렇군요 -ㅇ-;

처음 몇 섹션에서는 CLI와 CLI구현들에 대한 소개를 하고 있는데 상당히 일반적인 소개라서, HPC에 관심이 없는 사람이라도 읽어볼 만합니다. 그 다음에는 본격적으로 Java, CLR, SSCLI, Mono 넷을 벤치마크 하고 있습니다. 주요 수치 연산들과 알고리즘, SciMark등을 선보이고 있는데, 이 논문이 쓰여질 당시 (작년)에는 아직 mono가 최적화가 완전히 진행되지 않아서인지, 정수 연산, 기본 수학 연산에서 Sun JVM과 CLR에 한참 뒤져 있고, CLR이 대체로 Sun JVM을 약간씩 앞서는 퍼포먼스를 내고 있군요. SSCLI은 예상외로 선전을(..;)해서 mono하고 비슷하군요. 흐흐 사실 SSCLI는 그렇게 느려서 쓸 사람이 있을까 생각을 했는데..; 성능을 테스트할 수 있는 여러가지 수학적 알고리즘을 수행하는 SciMark에서는 IBM JVM이 제일 앞서고 근소한 차이로 MS CLR이 간혹 몇군데에서는 앞서기도 하고 있습니다. Sun JVM은 많이 차이나는 것도 있고 비슷한 것도 있고 그러고 있고, mono는 마냥 느리군요. -ㅇ-; 그런데, 상당히 놀라운 것은, SciMark의 FFT 시험같은 경우에는 IBM JVM, MS CLR은 C로 구현된 것보다 더 빠르기도 하고, 상당수의 알고리즘들이 70%정도는 유지하고 있다는 것입니다. VM이라고 엄청나게 느린 것은 아니군요..

글쓴이의 평가에서 Mono가 MS CLR에 비해 이렇게 느린 결과가 나온 것은 IL 코드와 생성된 x86 어셈블리 코드를 비교해 보면 Mono는 거의 1:1로 변환되어 최적화된 흔적이 아주 적은 반면에 MS CLR 코드는 상당히 많이 최적화되어 있어서 IL코드와 x86 어셈블리 코드가 1:1로 매칭이 잘 안 되는 정도라고 합니다. 그래서, 결론적으로는 과학 계산에 결정적인 영향을 미치는 것은 C# -> IL 사이의 최적화라기 보다는 IL -> native 사이의 최적화가 결정적인 영향을 미친다는 얘기인 듯 합니다. native 코드로 JIT 번역은 사실 parrot이나 DotGNU의 libjit, GNU lightning같은 경우만 보더라도 그냥 바이트 코드 읽어서 1:1 emit 하는 경우가 대부분이라, 사실상 최적화를 안 하고 있는 것이나 마찬가지인데 앞으로 JIT 디자인에서 좀 더 도전해 볼만한 요소인 듯 합니다.

며칠 전 블로그에서 김창준님의 추천으로 Enforcing Strict Model-View Separation in Template Engines이라는 논문을 봤습니다. 이거 웹 프로그래밍으로 논문까지 쓰고.. 역시 연구하는 사람은 어디든 있군요~

그동안 써본 템플릿 엔진 albatross, DTML, HTML::Template::Sigma, Quixote PTL 이 다섯은 처음 쓸 때는 아주 신세계가 열린 듯한 기분이 들었다가도 쓰다보면 금방 답답함을 느꼈습니다. 그 이유를 대충 정리해 보자면,

• albatross: HTML 태그 형태로 명령을 지원하는데 태그와 본문 간의 간격을 줄이기 위해서 어트리뷰트를 더 쓴다던지 하는 아주 지저분한 트윅이 필요하고, 특히 루프 돌릴 때 루프 변수를 조작하기가 매우 까다로워서 템플릿에 코딩까지 해야할 정도.

• DTML: 알바트로스보다는 훨씬 깔끔한 루프 변수를 지원하고, 여러모로 디자인이 잘 된 HTML 태그 모양의 템플릿이긴 하지만, 템플릿 쪽에서 제어 코드를 넣어야지만 처리가 가능한 경우가 너무 많다.

• HTML::Template::Sigma: 아주 단순한 블럭, 인클루드를 만을 지원하는 언어라, 진짜로 템플릿에는 데이터만 들어갈 수 있도록 만들어 주기는 했지만, 너무 단순해서 에러 보고가 제대로 안 되는 바람에 에러가 나면 제대로 잡기가 거의 불가능. -O- 일일이 하나하나 다 바꿔가며 디버깅을.. ㅠ.ㅠ

• Quixote PTL: 템플릿 언어계의 반항아! 다른 템플릿 언어들과는 완전히 다른 위젯 개념으로 코드가 템플릿을 감싸 안는 방식을 채택했다. 굉장히 혁신적이고 신선하긴 하지만, 아무래도 템플릿에 코드가 덕지덕지 붙은 이상은 디자이너들한테 쓰라고 하는 것은 불가능한터라, 개발자가 만들어서 개발자들만 보는 관리 프로그램등에나 쓸 수 있을 듯.

흐흐~ 그래 웹 프로그래밍은 다 이런거야 하고 좌절을 하고 있었는데, 이 논문을 보고 원래 다 그런 건 아니구나 하고 실낱같은 희망을 얻게 되었습니다. 이 논문에서는 템플릿에서 완전히 로직을 제거하는 게 단지 이상향으로만 존재하는 게 아니라는 것을 여러가지 증명으로 보여주고 있는데, 실제로 템플릿에 마구 로직이 섞여서 결국은 디자이너들이 감히 템플릿에 손을 못 대도록 만드는 문제의 원인이 템플릿 언어들이 파워를 잃어버릴까봐 템플릿 언어 안에 코드를 섞어 쓰는 것을 허용하는 것 때문이라고 합니다. 실제로 대부분의 템플릿 언어에서는 테일러 급수로 sin(x)를 전개하는 것이 가능하다는군요. (-ㅇ-;) 그래서 머피의 법칙 “if it can be done wrong, it will be done wrong,”에 의해 결국은 마감에 쫓기는 코더들은 임시 방편으로 코드를 마구 복사해서 여기저기 템플릿에 붙여서, 다음 개발자가 로직을 고칠때 여기저기 흩어져 있는 것을 일부 고치다가 뻑나서 다같이 망하거나, 디자이너가 디자인 고치다가 로직이 같이 뻑나거나 이런 상황이 올 수 있다고 합니다. 흐흐흐;

그래서, 저자는 템플릿 언어 차원에서의 로직과 템플릿의 강제적인 분리를 이렇게 강조하고 있습니다.

• 캡슐화: 사이트 모양은 완전히 템플릿에 있고, 로직은 모두 데이터 모델 (코드)에 모두 있다. 각각은 완전한 별도의 개체다.

• 명료성: 템플릿은 HTML을 뽑아 내는 프로그램이 아니다. 템플릿은 디자이너와 코더가 바로 읽을 수 있는 HTML 파일일 뿐이다.

• 작업의 분리: 그래픽 디자이너와 코더의 개발은 병렬적으로 일어날 수 있어야 한다. 이렇게 작업이 분리가 되면 코더들이 디자인을 고치기 위해 신경 쓸 필요가 없고, 디자이너와 코더의 커뮤니케이션을 위한 비용이 현저히 줄어든다. 디자이너들은 프로그래머와 얘기하지 않고도 디자인을 마음대로 고칠 수 있다.

• 컴포넌트 재사용: 프로그래머들이 보통 명료성과 재사용성을 높이기 위해 큰 메쏘드를 작은 여러개의 메쏘드로 분리하듯이, 디자이너들도 템플릿을 여러개의 서브 템플릿으로 분리할 수 있다. 즉, 로그인 상태, 네비게이션바, 검색창, 데이터 목록 등등.. 코드가 템플릿에 얽혀있는 경우에는 리팩터링을 통해 분리하기 매우 어렵고, 재활용하기도 어렵다.

• 고칠 곳은 한군데만 (single-point-of-change): 템플릿을 정리함으로써, 디자이너들은 링크 목록, 사용자 기록 뷰같은 여러 개념적인 원소들로 템플릿들을 분리할 수 있다. 이렇게 돼서, 나중에 사이트의 공통적인 한 부분을 고치는 경우 진짜로 한 파일의 한 군데에서만 고치면 되게 된다. 이렇게 하면, 하나를 고치기 위해 여러 부분을 고치다가 뻑나는 경우를 피할 수도 있기 때문에 이것은 아주 중요하다. "관리자인가" 같은 로직은 여러개의 템플릿에서 항상 반복되기 때문에 템플릿 안에 로직을 넣는 것은 절대 피해야 한다.

• 유지보수: 사이트의 모양을 바꾸는 것은 템플릿만 바꿔야지, 절대 프로그램을 바꾸는 작업이어서는 안 된다. 프로그램을 바꾸는 것은 템플릿을 바꾸는 것에 비해 훨씬 위험한 작업이고, 템플릿을 바꾸는 것은 새로운 삶을 시작할 필요도 없다. (즉, 사용되고 있는 서버 애플리케이션을 재컴파일하거나 새로 띄울 필요가 없다.)

• 바꿀 수 있는 뷰: 몽땅 뭉쳐서 쓰는 데이터 모델에서는 디자이너들은 "스킨"이나 "테마"같은 기능을 지원하기 위해서 디자인을 직접 입힐 수가 없다. jGuru.com 사이트에서는 "그룹"이라고 불리는 템플릿 모듬이 있다. "그룹"은 단순히 색깔이나 스타일 시트를 바꾸는 정도가 아니라, 사이트의 전체적인 모양을 바꿀 수 있다. 이렇게 모양이 달라져도 단순히 코드에서는 한 가지 방법으로 데이터를 전달해 주고, 어느 템플릿을 사용할 지 정해주기만 하면 된다.

• 보안: 블로그 사이트들에서는 이제 템플릿을 사용자가 직접 바꿀 수 있는 것이 흔한 것이 되었다. Microsoft Word에서 매크로 쓰는 것처럼 템플릿의 제한되지 않은 기능은 매우 심각한 보안 결함이다. 블로그 템플릿에서 클래스 로더를 띄워버리는 여러 보안 사건이 일어난 이후 squarespace.com은 Velocity와 StringTemplate를 사용하기 시작했다. 가장 쉽게 생각할 수 있는 공격은 무한 루프다. 모델을 뷰에서 완전히 독립하고, 페이지 제어를 금지함으로써 보안성을 얻을 수 있다.

그 외에도 그동안 생각 못했던 여러가지 이유들이 들어있습니다. 웹 프로그래밍에 염증을 느껴보신 분이라면 꼭 한번 읽어보세요. --;

sub·ver·sion [sbvn/-n] 
[명] 전복, 타도; 파괴; 파멸(의 원인); 전복시키는[파괴하는] 것.

아으아. 최근엔 빠른 속도와 파일 이동이 가능하다는 점 때문에 회사에서 subversion을 쓰고 있습니다. 그런데, 이놈이 소문대로 워낙에 잘 깨져서, 5명이 쓰는 중 거의 1명이 하루에 한번씩은 복구해야할 정도로 DB관리가 정말 허술합니다. 그래도, 뭐 recover를 해 주면 영영 데이터를 잃어버리는 것은 아니기에 그래도 고맙게 쓰고 있었는데, 어제는 그야말로 일이 터졌습니다. DB가 깨졌길래 복구하려고 했더니만, 복구 프로세스가 족족 모두 행 돼버리는 것이었습니다. 게다가 프로세스를 죽여도 좀비가 돼버리고 --; 이런.. 이거 프로젝트도 바쁜데 버전 관리 시스템까지 문제냐~ 참.. 우흐..

그래서, 우선은 침착하게 DB를 다른 디렉토리로 복사해서 복구를 해 보니까 행은 안 되고 그런대로 복구는 되는군요. 아무래도 한번 깨진 DB는 계속 깨질 것 같아서. 덤프한 뒤에 다시 로드했습니다. (리비전이 900가까이 돼서, 복구하는데만 20분 -ㅇ-) 흐흐.. 근데 자세히 살펴보니까 마지막 리비전 하나가 날아갔더군요.. 이런! 그동안은 그래도 깨졌다고 마크만 되고 실제로 날아가지는 않았는데 이제는 ㅠ.ㅠ subversion 앞으로 fsfs가 나온다고 하니 기대는 해 보지만.. 이제는 무서워서 더 못 쓰겠네요 흑흑~

요즘 python-dev 메일링에서도 subversion얘기가 굉장히 많습니다. 역시나 다들 엄청나게 깨지는 버클리DB얘기를 하고 있는데, perforce는 다 DB에 넣는데도 탄탄한데 왜 subversion은 이모양 이꼴이냐 뭐 이런쪽 얘기가 역시 주를 이루는 듯 합니다. 어서 subversion이 perforce 반이라도 따라가길 --;

프로젝트 "수정"에서 동기를 얻어, 프로젝트 "나영"을 시작했습니다. (우히히히) "나영"은 "수정"과 마찬가지로 또 다른 넘쳐나는 블로그 시스템 중의 하나로, 파이썬 기반의 MT클론을 목표로 느슨하게 벽돌쌓기식으로 개발될 예정입니다.

아직은 구조 및 기능 디자인 중이고, 회사에서 휴일에 놀게 해 주면 진행이 좀 더 빨리 될 예정입니다.

시작 기념 인터뷰~

질문 왜 굳이 MT나 수정같은 좋은 블로그가 많이 있는데 또 파이썬으로 만들려고 그러나요? 답 그냥 만들고 싶어서요. -ㅇ- 질문 그것 참.. 뭐 하고 싶어 하는 일이니 말리지는 않겠습니다. --; 그런데 왜 프로젝트를 BerliOS에 열으셨나요? Sourceforge도 있고 KLDP.net도 있고 좋은 곳이 많은데요. 답 그것은!! 그것은!!! BerliOS가 현재 대형 프로젝트 사이트 중에서는 유일하게 SVN을 지원하기 때문입니다. svn mv에 맛들린 사람은 아무래도 CVS로 돌아가기가 곤란하죠? ㅋㅋ 질문 아.. 그렇다면, 프론트엔드 구조는 어떤 식으로 갈 건가요? 혹시 Zope로 만들어서 자기 혼자 쓰려는 건 아닌가요? 답 프론트엔드 계층 뒤에 Quixote를 붙일 예정입니다. Quixote는 프론트 엔드에 mod_python, twisted, cgi를 모두 지원하기 때문에 당근 "나영"도 다 지원을~ 이히힝 질문 오.. 쌈빡하군요. 그럼 데이터베이스는 어디에 저장되는 건가요? 기존에 하던 대로 파일에 다 저장해버릴 심산인가요? 답 흐흐흐. 아.. 최근에 PostgreSQL을 해 보면서 RDBMS에 필을 받았습니다.;; 그래 사람들이 이런거 쓰는 이유가 있었군! 그래서, MT처럼 퍼시스턴스 계층을 추상화해서 파일DB뿐만 아니라 PostgreSQL과 MySQL, 그리고 요즘 인기가 하늘을 찌르는 SQLite도 지원할 작정입니다. 질문 아아.. 당신도 이제 성격이 많이 죽었군요. 그렇다면 페이지 테마는 어떤 식으로 지원할 예정인가요? pyblosxom이나 MT처럼 간단한 치환 정도로? 답 아뇨. 원래는 ZPT로 밀어붙일 계획이었는데, Quixote를 프론트엔드로 쓰자면 아무래도 위젯 기반으로 가게 될 것 같아서. Quixote를 쓰는 다른 프로젝트를 좀 더 연구해 본 다음에 그냥 대세를 따를 작정입니다. 흐흐흐 질문 역시 별 수 없군요 ㅎㅎㅎ. 블로그 시스템들은 대충 정적 페이지를 만들어주는 녀석들과 동적으로 서비스하는 걸로 나뉘는데, 요즘은 아무래도 동적으로 서비스하는 게 우세인 듯 하죠? "나영"은 어떤 방식을 채택할 것인가요? 답 얼마전에 MT를 깔아보고 참 감동 받은 것이 정적 페이지 제너레이션이었습니다. 제 블로그만 해도 스팸 메일 주소 긁어가는 봇들이 한번 닥치면 아주 거의 서버가 죽을 지경으로 CGI가 뜨는데.. ㅠ.ㅠ 정적 페이지라면 이런 문제가 없어질텐데 말이죠 흑흑.. 가급적이면 정적페이지로도 웬만한 기능은 동작하도록 하고, 전부 동적으로 생성할 수도 있는 MT방식 그대로를 따를 작정입니다. 질문 아아.. 대단하군요. 지금까지 들은 말을 종합해 보면 아무래도 10년짜리 프로젝트를 시작하려는 것같은 분위기가 물씬 나는데, 당신의 전적으로 과연 릴리스나 한 번 할 수 있을지 걱정 되는데요? 답 하하하.. 네.. (.. 다소곳 --;) 질문 그나저나 왜 프로젝트의 unix name이 na0입니까? 나-제로라고 읽으라는 뜻인가요? 답 nayeong 하면 아무래도 좀 길어서 mt같이 짧은 애칭을 써보자 하고 na0로 했습니다. 앞으로 홈페이지에 열심히 써 놓아야죠. 흐흐 "How to pronunciate na0?": Say, "Nah-Young"! You must remember that it's not pronunciated "Nah-Zero". .... (문법이 맞는지는 모른다 --;) 질문 예. 부디 아무쪼록 10년 안에 프로젝트를 꼭 완성하시길 바랍니다. 답 고맙습니다. (_ _)

《네 멋대로 해라》 팬이 수년동안 눈이 빠지게 기대려온 그런 드라마~ 이제 나왔네요~ +_+ 상구님이 얼마 전 채널에서 이나영씨가 나오는 드라마가 곧 한다고 그래서, 아 그래 무조건 봐야지 하고 있었는데 게다가 네멋의 인정옥 작가의 작품이라니 흐흐. +_+

아아 그런데, 역시 요즘 맨날 회사에서 야근에 밤샘의 중첩이라.. 본방송 때 못 보고~ 아이고 ;_; 결국은 다운 받아서 보게 되었습니다. 내용에 대한 얘기는 전혀 안 듣고, 여전히 '네멋'처럼 상당히 매니아틱하다는 소식만 들었는데, 아아 역시 들은대로! 역시! 이나영씨의 바로 그 말투 "(목을 좁혀서 콧소리와 함께 톤을 약간 높게 해서)네에?" "(두번째 음절에서 내려가는 톤으로 던지듯이)안 맞아요!" "(차분한 말투로)내가 불쌍해서 좋은가요 아니면 좋아서 불쌍한가요?" 등등.. 정말 정겹군요. 고향집에 온 기분.. (;;) 그.. 렌즈 끼는 사람이 렌즈 안 꼈을 때 멀리 있는 것 보는 듯이 눈을 작게 뜨고 턱을 올리고 이리 저리 보는 것을 남자 주인공도 따라하고.. ㅎㅎ;

처음 제목을 들었을 때는 Island인 줄 알았는데 Ireland였네요. IRA단원이 북아일랜드에서 받는 분위기를 설정에 넣고 있는데, 그래서인지 배경 음악으로 Cranberries같은 아일랜드 가수들의 곡들이 많이 깔리고 있네요. 퍼키도 고등학교 때 Enya, U2, Cranberries, The Corrs, Sinead O'Conner등을 거의 다 따로따로 알고 무척 좋아했었는데 알고보니 다들 아일랜드 사람들이라 깜짝 놀란 적이 있어서 무척 반갑습니다.

《아일랜드》 아직 1, 2화만 했지만서도 벌써부터 넘쳐나는 같은 얘기 꼬아놓은 드라마들로부터 차별적인 분위기를 충분히 만들어 내고 있습니다. 김민정씨도 '네멋'에서의 공효진씨 못지 않은 개성있는 연기를 잘 보여주고 있고.. 아참. 드라마를 볼 때는 이나영씨의 극중 이름이 "이중화"라고 들렸는데 아아.. KT가 늘 강조하는 그 HA를 위한 이중화인가.. 흑흑.. 하고 생각하고 있었습니다. 그런데, 다행히 홈페이지를 보니 "이중아"군요 -O-;

평소에 지하철 역 같은데서 누가 옆에서 부를 때는, 대충 "학생~"과 "아저씨~"가 반반 정도 됐었습니다. (아이고 ;_;) 엊그제는 목이 뒷머리에 찔려서 자꾸 불어나서 머리를 오랜만에 짧게 잘랐는데, 마무리해주는 분이 가르마를 안 만들고 그냥 앞머리를 다 앞으로 내려버리더군요. 호옹 그래 젊어보여서 좋다 하고 나왔는데 아.. 그때부터 갑자기 광고전단 돌리는 아줌마나 길 물어보는 아줌마나 다들 "학생~" 하고 부르는 겁니다. ㅋㅋㅋㅋㅋ -ㅇ-;

"아 그래 이게 내 스타일이야!" 하고서는 필을 받았는데, 오늘도 여지없이 지하철역에서 길 물어보는 아줌마 둘을 만났는데 (워낙 만만해 보이는지 항상 길 물어보는 사람이 많은 편 --;) 아아 역시 "학생~" ㅋㅋㅋㅋㅋ (... 감동의 도가니탕..)

--; 앞으로 좀 나이들어 보여도 웬만하면 "학생~" 하고 불러줍시다 -ㅇ-;

-O-; 마비노기 캐릭터 퍼키냥이 드뎌 환생했습니다. AP (Ability Point)의 부족으로 자주 환생할 수 밖에 없는 시스템 상.. 흑흑~

환생 전 까만 퍼키냥~ 환생 후 하얀 퍼키냥~

흐흐.. 까만 피부를 선택할 때는 러브 히나의 스우짱을 따라해 보려고 했지만.. 시간이 지날 수록 나이를 먹을 수 밖에 없다는 걸 깨닫고 그냥 하얀 피부로 --; (근데 대체로 주위 사람들 평은 환생 전이 훨 낫다는 반응이 -ㅇ-)

사실은 이 외에 다른 서버에도 캐릭터가 있긴 한데.. 그냥 묵혀두고 있습니다. 읏흐;

테스트 서버의 파페 골렘 서버의 아시알르

으음 아 얼른 마비노기를 끊고 다시 열혈 코딩을 해야할 텐데.. 이게 참 --;;