computer

그동안 수년동안MoinMoin을 써 왔는데, 블로그도 Zope 기반으로 옮기고 할 겸해서, 위키위키도 덩달아서 Zope기반의 위키 중 대표적인ZWiki로 옮기려고 잠시 시험해 보았습니다.

한 2년 전쯤이었나요.. 썰렁해서 뭐가 있는지도 잘 모르겠던 그 ZWiki가 이제 뭔가 기능이 있어 보이는게, ZWiki가 많이 발전했거나, 제가 zope식의 간단한 프로그램에 익숙해졌거나 둘 중의 하나일 것 같군요;; 예전에는 글을 어떻게 추가하는지도 참 막막했는데, 이제 메뉴가 모인모인보다도 더 간편합니다. 흐흐~

모인모인 문법도 지원!

전에는 reStructuredText로 위키를 작성하려면 참 막막했는데, 이제 시대의 조류에 맞게 모인모인 문법도 지원하는군요! 그래서 ZWiki 최근 버전에서는 이런 문법이 지원됩니다.

• StructuredText

• reStructuredText

• HTML

• Plain Text

• WikiWikiWeb문법

• MoinMoin문법

약간 링크를 사용하는 데 있어서는 모인모인과 다른 것이 있긴 한데, 테이블 같은 것이 쉽게 지원되는 것만 해도 정말 감지덕지입니다.~ 몇 개를 시험삼아 Zwiki로 옮겨 봤는데, 깔끔하게 잘 보이는 것이 금방 다 옮길 수 있을 것 같더군요.

국제화 지원

모인모인 1.3의 장점으로 거의 이제 정점에 다다른 국제화를 꼽을 수 있는데, ZWiki도 모인모인 1.3을 많이 벤치마크해서 국제화에 신경을 많이 쓴 듯 합니다. 이제 페이지 이름, 링크, 문법 등에서 한글을 쓰는데 거의 문제가 없네요~ 그리고, 메시지 국제화도 신경쓰고 있는데, 아쉽게도 아직 한국어 번역은 들어가 있지 않습니다. 이제 ZWiki도 깔았겠다, 번역을 슬슬 해 봐야겠군요.. 크크..

Zope에서 메시지 번역을 써 보기는 처음이긴 한데, 방법이 제법 어색했습니다. 처음에는 Localizer와 iHotFix, itools를 깔라고 써 있길래 다 깔았더니만, 자꾸 Zope가 세그폴트가 나서 파이썬의 스택 사이즈를 올려서 컴파일도 해 주고 했습니다. 그랬더니 이제 거의 무한루프 수준으로 iHotFix쪽 코드가 빙글빙글 돌면서 제대로 동작하지 않았는데, 가만히 구글 검색을 해 보니까PlacelessTranslationService라는 것도 깔라고 해서 깔고 해 봤는데, 결국은PlacelessTranslationService를 깔고, Localizer랑 다른 모듈들은 모두 제거하니까 번역이 모두 깔끔하게 올라오는 것입니다. 흐흐 시험삼아 번역해 본 한국어 단어도 몇개 보이고 좋군요~

ZWiki도 첨부 파일이 지원되지 않는 등 기능은 모인모인에 비해 다양한 편은 아니지만, 간단하게 쓰기에는 모자라지 않고 써 볼만 한 듯 합니다. 이제 스킨 바꾸는 방법만 터득하면 오픈룩도~

원래 애플 에어포트 스테이션을 장호언니께 빌려서 사용하고 있다가, 에어포트 스테이션의 고질적인 몇몇 문제로 인해 결국은 그냥 공유기를 하나 사게 되었습니다. 흐흐. 화장실에서 마비노기도 하고 쇼핑몰도 둘러보고 코딩도 하고 하는 것의 유혹은~~ +_+

뭐가 좋을지 한참 고민을 하다가 결국 삼콤과 링크시스 사이에 고민을 하게 되었습니다. 그러다가 링크시스가 아무래도 공유기 경험은 더 많고,”A division of Cisco Systems”라는 후광 효과로;; 결국은 링크시스를 골랐습니다. 가격은 10만 5백원. 다나와에서 찾아보니 9만8천원 정도까지도 파는 곳이 있었습니다.

링크시스 WRT54G와 트리쯔 TZ3220E

아 역시 배송을 받아보니, 뽀대가 저절로 묻어 나오는 저 디자인.. 삼콤사의 추리한 베이지색 박스보다는 훨씬 낫군요.뭔가 그냥 안 쓰고 놔두기만해도 폼이 납니다.~기본 스펙은 이렇습니다.

• 유선 공유 100BaseT 4포트

• 무선 802.11g, 11b 모두 지원

• 무선 보안 WEP, WPA, WPA/PSK 지원

• WAN측 DHCP, Static IP, PPPoE, PPTP, L2TP 지원

• DDNS 등록 기능 지원

• MAC 주소 클론 지원

• MAC 기반 무선 랜 필터링 지원

• 시간, 날짜, 요일 기반 액세스 컨트롤 (호스트, 포트) 지원

• DMZ 호스트 (모든 포트 한 호스트로 몰아주기) 지원

• QoS 지원

• NAT 로깅 지원

이야.. 역시 스펙만 봐도 다른 공유기들하고 쉽게 비교가 안 됩니다. 저는 아직 안 써보긴 했지만 L2TP와 PPTP를 지원한다는 것을 보니 잘 쓰면, VPN 라우터처럼도 쓸 수 있을 것 같군요! (회사에 연결해서 한번 써 볼까~ 흐흐) DDNS 등록 기능이나 NAT 로깅 같은 것은 정말 사소한 기능임에도 불구하고 메뉴 속에 잘 녹아서 깔끔하게 지원되고 있는 것을 보면, 일정에 쫓겨서 개발한 것이 아니라 여유를 두고 기능을 골고루 개발해서 집어넣은게 아닐까 생각됩니다~

네트워크 성능은 뭐 저희 집에서 쓰는게 ADSL Lite라서 원래 속도가 별로 안 나오긴 하지만;; 유선과 무선 모두에서 700KB/sec 정도까지도 다운로드가 됩니다. 그냥 바로 모뎀에 붙여 쓰는거랑 별 차이가 없군요~ 하나 아쉬운 점이 있다면, 한국에 수입되면서 설정 메뉴나 2페이지짜리 설정 매뉴얼조차 한국어로 번역되지 않은 점.. 뭐 이런 것 말고는 가격에 비해 아주 과분한 장비입니다. 강력 추천!

회사에서 RoundUp을 잠시 쓴 적이 있습니다. 이게 제법 유명한 것이기는 하지만, 생각보다 너무 상태가 좀 그렇습니다;; 기본 기능에 너무 충실하다보니.. 이슈 트래커 외의 기능을 전혀 갖추고 있지 않고, 이슈 트래커 기능 자체가 단순한 듯 하면서도 복잡한데 속도가 또 엄청 느려서.. 오래 쓰기는 좀 그렇더군요.

그래서, 대체품으로 요즘 잘 나가는 오픈소스 프로젝트 관리 환경인 trac을 설치한지 이제 2주가 조금 넘어서고 있습니다. 2주동안 trac으로 프로젝트를 하면서 아주 즐거웠던 것을 생각해 보면, 사람을 기분 좋게 만들 수 있는 소프트웨어 중 하나임에는 분명한 것 같아서, 다른 분들도 써 보시라고 기능을 소개해 드립니다. 🙂

Trac

Trac은 subversion과 연계된 프로젝트 관리 도구입니다. 기본 이념이 minimalist를 표방하고 있기 때문에, 대부분의 기능이 돌아가기 위한 최소 스펙으로 구현이 되어 있습니다. 사실 디자인도 minimalist였으면 좀 거부감이 있었을텐데, 디자인은 아주 깔끔한 편입니다. 하여간 기본적으로 프로그램 전체가 파이썬으로 작성되어 있는데, CGI 모드와 tracd라는 전용 웹 서버 모드를 지원합니다. 저는 CGI 모드로 사용하고 있는데, 보통의 파이썬 CGI들이 엄청난 속도로 사용자들을 당혹케 하는 경향이 있지만, trac은 엄청나게 빠릅니다! 과연 이게 파이썬인가 믿기지 않을 정도입니다. 흐흐. 아무래도 C로 작성된 템플릿 라이브러리인 clearsilver를 깔고 있어서 그런게 아닌가 싶은데, 하여간 clearsilver외에도 sqlite를 DBMS로 사용하고, 저장소에 접근하기 위해서 python-subversion이 필요합니다.

문서 관리 및 대문 관리 – 위키

전체보기

trac은 텍스트가 들어갈 수 있는 모든 부분에 위키 포매팅을 사용하고 있습니다. 즉, 위키 페이지를 문서화를 위해서 쓸 수 있을 뿐만 아니라, 이슈 트래커의 본문이나 심지어 subversion 커밋 로그에서도 위키 포매팅이 지원됩니다. 문법은 모인모인과 매우 비슷하기 때문에, 많은 사람들이 어렵지 않게 익힐 수 있게 되어 있습니다. 그리고 [리비전]이나 #이슈번호같은 형식의 빠른 링크를 지원하기 때문에 커밋 로그와 이슈, 위키 간의 아주 긴밀한 상호 링크가 가능합니다.

물론 위키에는 첨부파일 올리는 것이 가능해서, 문서 및 리소스 관리용으로 아주 유용합니다.

변경 사항 한 눈에 살펴보기 – 타임 라인 (시간 순 이력)

전체보기

trac은 timeline이라는 독특한 페이지를 또 제공하고 있는데, 보통 위키에서는 RecentChanges로 페이지 이름이 붙는 것과 비슷한 역할을 합니다. timeline은 위키 페이지들의 변동사항 뿐만 아니라 커밋 로그나 이슈 트래커 변동사항까지 시간 순으로 볼 수 있도록 하고 있어서 전체의 변동 사항을 한 화면에 볼 수 있어서 흐름을 파악하기 아주 좋습니다.

진행 사항 단계별 파악! – 로드맵

전체보기

trac에서는 subversion 리비전과는 별도로 version과 milestone개념을 지원합니다. milestone을 따로 나눠 둠으로서 올라오는 이슈들 중에 각 마일스톤에서 해결되지 않은 것이 얼마나 남았는지, 얼마나 급한 것인지 한 눈에 알아볼 수 있도록 하고 있는데, 바로 그 상황을 볼 수 있는 곳이 Roadmap 메뉴입니다. Roadmap 메뉴는 컴포넌트별로 각 부분의 이슈들이 해결된 것이 얼마나 되는지 한 눈에 볼 수 있도록 예쁜 그래프로 표시해 줍니다.

버그 추적에는 필수~ 소스 둘러보기

전체보기

trac은 subversion과 아주 긴밀하게 연계가 되어 있기 때문에, 자체적으로 viewcvs같은 웹 인터페이스를 지원해 줍니다. 사실 이 기능은 trac의 주 기능도 아닌 편이긴 하지만, 오히려 viewcvs보다 기본적인 기능에는 아주 충실한 편이라서 거의 불편함이 없을 정도로 잘 만들어 두었습니다. annotate같은 기능이 빠진 것은 좀 아쉬운 편이지만, 리비전 지정한 채로 왔다갔다하기, 리비전 로그 보기, 소스 하이라이트 같은 것은 잘 지원되고 있으며 무엇보다 viewcvs보다 압도적으로 빠르다는 점이…. 흐흐

새로운 문제점 등록 – 티켓 올리기

전체보기

trac에서는 다른 곳에서"issue"나"problem report"라고 부르는 것을 자체적인 용어로"ticket"이라고 부릅니다. 그게 통상적으로 사용되는 용어인지는 모르겠지만.. trac에서는 일관적으로 통일해서 티켓이라고 합;; trac의 ticket 등록은 최상위 메뉴에 있을 만큼 주요된 기능 중의 하나인데, 버그 등록자는 꼭 trac 안의 인증된 사용자일 필요 없이 자기 메일 주소를 쓸 수도 있기 때문에, 아무나 등록하게 할 수도 있습니다.

티켓을 등록할 때에는 위키 포매팅을 쓴 본문도 가능하며, 치명도, 우선순위, 컴포넌트, 버전, 마일스톤 같은 것들을 명시해 줄 수 있습니다. 물론, 티켓 올린 다음에 답글을 달면서 상태를 바꾸는 것도 당연히 지원 됩니다. 흐흐

등록된 티켓들을 검색 – 리포트

전체보기

trac에서 report의 기본적인 용도는 등록된 티켓의 검색입니다. 티켓을 나열할 수 있는 갖가지 방법 들로 기본적으로 10개 정도를 제공해 주고 있습니다. (마일스톤별, 우선순위별, 담당자별, 해결되지 않은 문제들만 보기 등등..)

SQL이면 뭐든! – 사용자 지정 리포트

전체보기

trac의 기본 목표를 정말 완벽히 실현하고 있는 곳이라면 바로 사용자 지정 리포트 부분입니다. 사실 위에서 언급한 리포트도 모두 기본으로 세팅되어 있다 뿐이지, 사용자 지정 리포트와는 구분이 없습니다. 모든 리포트는 SQL 퀴어리와 제목으로 구성되어 있습니다.즉, SQL 퀴어리만 수정해 주면 페이지가 동적으로 마구 바뀐다는 말씀! 기본적인 trac의 데이터베이스 스키마만 파악을 하면 아름다운 리포트 페이지들을 번거로운 HTML 템플릿 작업 없이 SQL 만으로도 만들 수 있습니다. 위의 스크린샷은 제가 그냥 샤샤샥~ 해서 만든 커밋 로그에서의 사용자 이름 순위입니다. 흐흐 정말 간단!

이제 grep은 번거롭다! – 검색

전체보기

흐흐 또다른 trac의 진짜 매력 포인트. 바로 검색입니다. 이 검색은 위키 페이지나, 이슈 트래커 본문에서만 검색이 되는 것이 아니라, 커밋 로그나 각 수정사항(위키 페이지, 이슈 등)의 짧은 커멘트에서 까지도 검색이 되기 때문에, 사실상 프로젝트와 관련된 대부분의 곳에서 검색을 해 주기 때문에, 뭔가 특별한 함수가 언급된 모든 곳을 찾고 싶다~ 할 때 grep으로 찾으며 고생하지 않아도 됩니다.

피할 수 없다!

이미 오픈소스 커뮤니티 들을 둘러 보면 trac을 도입하고 있는 곳이 엄청난 속도로 불어나고 있으며 오픈소스가 아닌 부분에서도 굉장히 많이 사용되고 있는 것을 발견할 수 있습니다. 파이썬에는 전혀 관심 없었던 사람들이 갑자기 파이썬을 깔다가 패키지 패치를 올리기도 하고, bittorrent에 이어서 또 다른 파이썬의 프로모션 소프트웨어가 될 것 같은 예감..

최근 python-dev에 올라온한 강사의 메일에 따르면 다음 학기에 버클리에서 파이썬 수업이 하나 있는데, 단순히 파이썬 문법을 가르치고 끝나는 것이 아니라, 실제 파이썬 프로젝트에 올라와 있는 버그를 분석해서 버그 패치를 만들고 버그 패치가 실제로 적용되기까지 파이썬 개발자들과 토론도 하다가 적용되는 것까지 실습해 볼 예정이라고 합니다.

이 글을 올린 강사는 기존의 파이썬 개발자들이 흥미를 못 느껴서 고치지 않은 간단하거나 번잡한 문제들을 추천을 해 주면, 학생들에게 시켜볼 예정이라고 합니다. 사실 엄청나게 활발하게 일하던 사람이 몇달 열심히 활동하다가 갑자기 사라지는 것들은 아무래도 열정적인 개발자들의 상당수가 이미 익숙해져서 지루함이 느껴지는 작업들은 하기 싫어서 미루다보면 쌓여서 그런 면이 큰데, 아직 오픈소스 프로젝트에 실제 참여해 본 적이 없는 전공 저학년 학생들이라면, 배우면서 입문하는 과정이다보니, 숙련된 개발자들이 하기 힘든 지루한 작업도 할 수 있지 않을까 싶군요.. (그리고 학점도 달려 있고!) 그리고, 물론 허구헌날 며칠 밤 새서 크리스마스에도 실습실에 모여 밤새며 열심히 프로젝트해서 만들어 봐야 조교한테 보여주면 쓰레기가 돼 버리는 학교 프로젝트들을 하는 것보다, 진짜 오픈소스에 불과 몇 줄 안되는 패치라도 기여가 된다면, 보람도 있고 젊음을 낭비하는 느낌도 훨씬 적게 들 것 같아서 아주 좋은 아이디어 같습니다.

이에 대한 답변으로 파이썬 개발팀의 마틴이자신의 경험을 얘기해 줬는데, 마틴도 비슷한 수업을 지금 진행하고 있다는군요. 아이러니컬하게도, 파이썬의 핵심 중의 핵심에 속하는 마틴의 수업을 듣는 학생들은 정작 PHP를 하고 있다고 합니다. (역시;;) PHP외에도 모질라 프로젝트에도 역시 관심을 가지는 학생들이 많아서, 그 두 프로젝트를 중점적으로 하고 있는 듯 한데, 아무래도 수업을 받는 학생일지라도, 자기가 관심이 있는 것을 하는게 능률이 훨씬 오르겠죠.. ;

마틴의 수업을 듣는 학생들은 실제로 진행에서 수업 3번째 시간부터 리뷰를 하기 시작했고, 36시간 이후에는 최종 리뷰를 하고, 곧 모질라가 코드 프리즈 기간이라 들어갈 수 없다는 이유를 설명할 정도가 됐다고 합니다. 그리고 그 이후에 코드 프리즈가 끝난 이후에는 실제로 반영이 되었고, 수업 프리젠테이션으로 그 과정을 설명하였다고 합니다.

하나 문제가 생길 수 있는 것은 아무래도 수업과 관계없는 사람들이 프로젝트에 많이 관여되어 있는 관계로 다른 개발자들이 학생들이 보고 있던 버그를 먼저 고쳐서 집어넣어 버리면, 힘이 빠져서 할 맛이 안 나지 않겠느냐 이런 문제를 지적하고 있는데, 아무래도 문서화쪽 버그만 열심히 잡으면 (또는 문서를 쓰면) 절대로 기존 파이썬 개발자들과 겹칠 일은 없지 않을까 싶군요. 크크크 (-_-;;;;) 그래도 코드 버그가 더 재미있는데 흐흐;;

하여간, 이런 식의 수업 진행은 정말로 재미있는 것 같습니다. 지난 번 7월의 코드페스트 1회 때 파이썬 버그데이를 한번 시도해본 적은 있었지만, 아무래도 평일 내내 회사 업무로 시달리던 사람들이 주말에 와서 하루 밤새면서 일하는 것은 생산성의 한계가 있어서 오히려 그냥 집에서 따로따로 몇시간 하는게 더 효과적일 정도였습니다. 그런데, 수업은 주요 일과중의 하나이고 한번만에 연속적으로 하고 끝나는 게 아니라 중간 중간 여유가 충분히 있으니까, 오픈소스 개발 과정을 생산적으로 배우기는 아주 좋은 방법이 아닐까 합니다.

저도 내년이면 3학년으로 복학하는데.. 졸업하기 전에 이런 수업 안 생기려나요.. –;;;

요즘 업무 상 한글 파일 이름을 첨부로 받는 메일이 많아지면서, gmail로 받는게 좀 불편해서 한번 말로만 들어 왔던천둥새를 설치했습니다. 천둥새 아.. 역시 소문대로 아주 좋네요. 스팸 메일 처리하는 것이 특히!spamassassin에 피드백 넣기가 정말 불편했었는데..

그런데, POP으로 받으려니 집 데스크탑, 바이오, 아이북, 회사 데스크탑 4대에서 다 따로따로 메일이 받아지니, 메일이 어디로 갈 지도 모르고 메일함 관리도 안 되고 상당히 불편해서 IMAP을 설치해 보려고 마음을 먹었습니다. 예전에 설치해 봤던 courier-imap은 가장 기본적인 서비스만 쓰는데도 데몬이 10개가 넘게 뜨니.. 부담스럽기가 한이 없어서, 다른 것을 찾아보던 중에BincIMAP을 찾았습니다. 이놈은 qmail을 좋아하는 사람이 qmail 스타일로 만든 것이라 상당히 모듈라하게 만들어서 courier-imap같지 않게 그냥 daemontool이나 xinetd에서 서비스당 1개씩만 뜰 수 있도록 되어있어서, 리소스 절약에 큰 도움이 될 것 같은 예감이!

결국 포트로 설치는 했는데, 이게 포트에서는 서비스 등록이라던지 이런게 하나도 안 되어 있어서 –; 결국은 수동으로 README 문서 보면서 설치하고 나니 거의 30분이 걸리는군요. (xinetd를 한 번도 안 써봐스.. 흐흐;) 그리고 생짜 imap은 아무래도 쓰기가 껄끄러워서 SSL을 세팅하고 나니 거의 1시간이.. 흐흐.. CA도 만들고~ -ㅇ-. 그런데, 세팅하는 도중에 Bincimap의 문서에서 아주 좋은 팁을 하나 발견했는데, 보통 raw 세션은 telnet으로 간단하게 테스트를 할 수 있지만, SSL 세션은 테스트하려면 클라이언트를 만들거나 stunnel같은 걸 쓰거나 상당히 불편한 편인데, Bincimap 문서 중에 테스트하는 방법이 간단하게 쓰여 있었습니다.

miffy(perky):~% openssl s_client -connect openlook.org:993 -crlf 
CONNECTED(00000003)
depth=1 /C=KR/ST=Seoul/O=OpenLook Initiatives/CN=Hye-Shik Chang/emailAddress=perky@FreeBSD.org
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
* OK Welcome to Binc IMAP Copyright (C) 2002-2004 Andreas Aardal Hanssen at 2004-11-21 18:52:27 KST

openssl을 이렇게 쓰는 방법이 있었다니 흐흐. 앞으로 SSL 테스트하는데 꼭 써먹어야..

bincimap은 메모리도 SSL 세션에서 4메가도 안 쓰고, 평소에는 그냥 xinetd만 떠 있어서, courier-imap에 비하면 정말 있는둥 마는둥! 그리고 기본 기능도 크게 떨어지는 것도 없어서 좋습니다~. awkn`n님 말씀에 의하면 데비안에서는 설치도 간단하다니 좋군요.

토끼군에 못지 않게 이런 저런 삽질을 좋아하는 옥균이의 재미있는 프로젝트Paper Cup이 열렸군요.

Paper Cup은 msnm에서 익명으로 아무나 연결해서 대화를 할 수 있는 중계 봇인데, 앞으로 용도가 대충 예상은 되지만.. 상대 성별을 지정할 수가 없어서.. =3=33

papercup

(구현은 jmsnlib 기반이라고 합니다~)

흐흐 오랜만의 노는 주말이라서 밀린 빨래하고 방청소하고 그러니 정신이 없군요. 세탁기를 3번 돌렸더니만 빨래를 널 곳도 없고;; -O- 역시 집을 청소하고나니”그래, 이것이 사람의 삶이구나!”-O-

밀린 메일을 읽던 중에 PSF 내부 메일링에서 ASF얘기를 봤습니다. 내용은 ASF가 흔히 오픈소스 재단들이 받는 기부금 외에중고차를 받는 다는 얘기를 듣고서는 PSF에서도 그와 비슷한 것을 해 보면 어떤가 하는 얘기였습니다.

ASF에서는Car Program LLC라는 기부 중계 전문 기업을 통해서 받고 있는 듯 한데, 직접 처리하면 세금도 들고 처리하기도 힘들고 한데, 여기를 통해서 기부하면 세금도 없고 물론 다른 과세에서 면제도 되고 쉽게 처리할 수 있어서 좋다는군용~ 많은 재단들이 실제로 기부금을 받아 봤자, 개발자들 자신이 기부하는 게 반이 넘는 실정에서 이렇게라도 기부를 받아 보려는 ASF의 노력이 참 애처롭군용. -O- 앞으로는 중고 노트북이나 중고 책같은 것도;; 흐흐

그러나, PSF쪽에서는 이게 실제로는 회사에만 이익이 엄청나게 가고, 재단이 갖게 되는 수익은 극히 일부에 불과하기 때문에, 거의 사기라는 의견이 대세라서, 이런 방법을 채택하게 되지는 않을 것 같습니다. 멤버 한 명은 진짜로 구세군에 중고차를 기부해 봤는데, 실제로 자기가 중고차를 팔면 받을 수 있었을 만한 돈보다 아주 적은 돈이 기부되었다고.. -O-

바이오에 어제 들어온 GNOME 2.8.1을 깔았습니다! +_+

므흐흐. 이상하게도 1280×768이 안 잡혀서 한참 고생하긴 했는데, 웹을 좀 뒤져 보니 카드 자체의 문제라서 펌웨어 패치를 해 줘야한다는군요 -.- 그래서 패치를 해서 띄워줬더니 계속 1024×768로 나오다가 1280×768로 나오니 어찌나 멋있던지

GNOME 2.8에서 가장 눈에 띈 것은 빨리 실행 아이콘을 만들 때 인터페이스가 무척 친절해 졌고, 웹브라우저에서 압축파일을 다운 받으면 바로 fileroller가 떠서 압축파일 안에 들은 파일들을 다른데다 끌어다 놓을 수 있다는 점! +_+ 아 정말 좋네요!

요즘OpenLook을 대폭 개편하려고 짬짬이 Zope위에서 이것 저것 고쳐보고 있습니다.coreblog는 꽤 잘 만들어져 있어서, 고치고 놀기에도 정말 재미있네요. 회사에서 하는 PHP노가다가 이렇게 재미있었으면 무지 좋았을텐데 아쉬워요.. 흐. -o-

외부 에디터 없던 시절의 Zope질..

그런데, 아무래도 웹에서 textarea에서 dtml 길고 여러 파일에 나뉘어 있는 것을 고치려면 무리라서.. 일단은 mozex로 vim을 textarea로 불러다가 어느정도 하는 걸로 만족을 했습니다. 그런데, 이런 방법의 문제점은 꼭 저장을 하고 에디터 종료하고 또 textarea를 한 번 클릭해 주고 (안 하면 적용 안 됨;;) 그리고 Save를 눌러야 해서.. 한 번 테스트를 하려면 기나긴 여정이.. 게다가 동시에 에디터를 여러개 열어놓고 수정할 수도 없어서, 1줄 고치고 테스트하고 뭐 이런 식으로 하는 것이 정말 어려웠습니다. ㅠ.ㅠ

eclipse

그러다가 생각난 것이.eclipse! 요즘 가장 진보된 기술들을 가득 담아서 나왔다고 들어서.. 해 봤습니다. 역시나 WebDAV 플러그인도 있고! 그래서 잔뜩 기대를 하고 100메가 가까이 되는 걸 다 설치를 했는데. 으흐흑 Zope에서는 인증 안 된 사용자는 PROPFIND를 허용하지 않는데, eclipse에서는 인증 정보를 아무리 넣어 줘도 인증 정보 없이 PROPFIND를.. 그래서 이를 악물고그래 해볼테면 해보자!하고 Security에서 Anonymous의 WebDAV 접근을 허용하고 했는데.. 결국 돌아온 것은.. 두둥 ..Internal Error.. ⓞTL

HTMLKit

좀 더 검색을 하다보니, 윈도우 전용으로HTMLKit이라는 것이 아주 좋다는 메일을 발견했습니다. 아 그래, 공짜인데 나쁠 것 없지~ 하고 다운 받아서 설치를 했는데, UI도 아주 깔끔하고 괜찮았는데, DAV가 지원되지는 않았습니다. 그래도 FTP 지원이 상당히 좋아서, FTP 사이트를 연결해도 거의 로컬에서 에디트 하듯이 리스트도 보이고 좋았습니다. 탭 전략 조절도 아주 자유롭고.. 거의 이 정도면 완벽이 아닐까 싶었는데.. 헛!! 이런!! 인코딩 지원이.. 쏙 빠져 있는 것… 거의 20개에 달하는 환경 설정 탭 여기저기에 숨겨 놓음직도 한데.. 왜 인코딩 변경이 안 되는 것인가! … 웹에서 찾은 대답은.. 지역화 지원 패키지는 유료라는군요.. -o-;;;

자연으로 돌아가자 –; cadaver

그래.. 그냥 커맨드 라인이라도 편하기만 하면 괜찮지 하고 자연으로 돌아와 버렸습니다. (윈도우는 왠지 아파트 같고, 유닉스는 숲속의 통나무집 같은 기분이 알게 모르게 느껴지는.. 흐흐;;) 커맨드 라인으로 유명한 것이cadaver라는 것이 있는데, 이게 아무래도 webdav.org 사이트에서 직접 호스팅 되는거라 그런지 품질은 아주 좋은 느낌이.. 마침 포트에도www/cadaver로 등록이 되어있어서, 딱 좋군요~ 흐흐 그래서 딱 띄워 보니까, 오우!!

miffy(perky):~% cadaver http://openlook.org:8080/wiki/ 
Authentication required for Zope on server `openlook.org':
Username: perky
Password:
dav:/wiki/> ls
Listing collection `/wiki/': succeeded.
Coll:   images                                 0  Oct 31 22:40
Coll:   methods                                0  Oct 25 23:28
... 중략 ...
dav:/wiki/> edit index_html
Locking `index_html': succeeded.
Downloading `/wiki/index_html'to /tmp/cadaver-edit-cuYxET
Progress: [=============================>] 100.0% of 28561 bytes succeeded.
Running editor: `/usr/local/bin/vim /tmp/cadaver-edit-cuYxET'...
(vim이 뜸)
dav:/wiki/> help
Available commands:
 ls         cd         pwd        put        get        mget       mput
 edit       less       mkcol      cat        delete     rmcol      copy
 move       lock       unlock     discover   steal      showlocks  version
 checkin    checkout   uncheckout history    label      propnames  chexec
 propget    propdel    propset    search     set        open       close
 echo       quit       unset      lcd        lls        lpwd       logout
 help       describe   about
Aliases: rm=delete, mkdir=mkcol, mv=move, cp=copy, more=less, quit=exit=bye

이렇게 히야.. 정말 명령도 DAV에 특화된 여러가지 명령들이 있고, 사실 유일한 필요한 기능인 ls랑 에디터가 바로 된다는 점이.. 으흐흐;; screen 안에서 cadaver로 에디터 4개 띄워놓으니 딱 편하네요. +_+ 게다가 명령행에서 readline도 먹어서 자동 완성도 됩니다~

이렇게 편하게 DAV에 들어있는 파일 수정을 하니까 어찌나 편하던지.. 웹 브라우저에서 mozex 쓰던 떄의 한 5배 속도로 작업을 할 수 있더군요;; 흐흐 진작~

이제 강태욱님 추천으로 zwiki도 깔고 이것 저것 해 보고 있는데, 아무래도 곧 openlook 안에 있는 건 다 zope 기반으로 옮길 수 있을 것 같고.. 이제 슬슬 bbs.python.or.kr도 zope 기반으로 옮길 수 있도록 봐야겠습니다~

추석동안에 소리 소문없이 슬쩍 subversion 1.1이 stable release로 나왔네요. 그동안 회사에서 “으악~~ DB가 깨졌어~~” 소리가 하루 종일 열댓번씩은 났던 것을 생각해 보면, subversion 1.1에서 나왔다는 fsfs는 정말 기대가 됐습니다.

그래서 냉큼 subversion 1.1을 깔고 레포지트리를 덤프 뜬 다음에 fsfs로 바꿔버렸습니다. 리비전이 1200정도 되는데, 워낙 서버가 느려서 한 5분 정도 걸리는군요.. 그런데 게다가 woody라서 그나마 나오는 패키지도 다 옛날 버전이고.. 흐흐흐; 그냥 간단하게 ./configure 했더니 버클리DB 없이 컴파일했다는 워닝이! 캬! 그래 이게 바라던 거였어! (subversion으로 인해 버클리DB에 쌓인 감정이 많다..;)

원래는 레포지트리/db/db.00* 와 레포지트리/db/log.00* 파일들이 흉칙하게 남아있었는데 이제는 fsfs로 하면 레포지트리/db/{revs,revprops,transactions} 밑에 숫자 1~5자리 정도로된 파일이 수백개씩 들어갑니다. 다행히 리비전 1개에 파일이 1개… (리비전 1개의 파일당 1개였으면 –;) FreeBSD 레포지트리처럼 리비전이 80000쯤 되면 디렉토리당 파일이 80000개 -ㅇ- 뭔가 대책이 필요합니다 =.=; 그런데, 처음 fsfs 말을 들었을 때 기대했던 CVS처럼 사람 눈에게도 친절한 포맷은 아닙니다. 그렇다고 완전 못알아 볼 포맷도 아니긴 하지만.. 하여간 RCS는 아니군요 (별 기대를 -ㅇ-)

속도는 특별히 버클리DB로 쓸 때보다 차이가 있는 것 같지는 않습니다. blame이 좀 느리다는 얘기를 들었는데 체감 속도로는 별 차이가 안 나는군요.. (어차피 느려서;;)

대충 아무렇게나 막 while루프로 svn에 접속시켜봤는데, 버클리DB를 쓰던 시절 같으면 금세 깨져버렸을텐데 아직 멀쩡한 걸로 봐서, 그런대로 안 깨진다는 것은 사실인 듯 합니다. 이제 마음 졸이며 DB 복구하는 시절은 갔군요. 으흐히;;