모인모인문제점

FrontPage|FindPage|TitleIndex|RecentChanges| UserPreferences P RSS

1. 미해결 (및 제안)

1.1. 페이지 이름 바꾸기 버그

버그인지는 모르겠는데, C++LanguageCeePlusPlus로 바꾸려고 하니까 에러가 나네요. pagename에 특수문자가 들어가서 그럴지도 모르겠습니다.

1.2. 달력 매크로

를 만들어서 특정 페이지에 누가 날짜와 이벤트 내용 등을 기입하면 달력 매크로가 자동으로 해당 페이지의 내용을 정리해서 깔쌈한 달력으로 보여주는 기능

1.3. 기존의 페이지가 New page 로 바뀌는 문제

이건 페이지별 복본들이 주기적으로 지워지기 때문입니다. 노스모크는 역사를 저장하지 않습니다. 아니 못합니다. 하지만 페이지별 최초 탄생 시점을 기록해서 이 점을 수정할 수 있을 것입니다.

1.4. 수정시 있던 글이 삭제됨

Q: 최근에 사람들이 어떤 페이지를 수정하다가 별다른 이유없이 페이지의 내용의 일부가 지워지는 일이 자주 발생하는 걸 목격하는데 이건 왜 그런 걸까요? 버그가 뭔진 잘 모르지만 아무래도 이게 버그라 불리는 것의 일종이 아닐까..?

A: 몇 분이 수정하다가 그런 일이 발생한 걸 목격하곤 다시 복구시켜 놓았습니다. 페이지에서 특정 지점 이후의 글이 모두 지워져 있더군요. 참 곤란한 것은, 위키위키를 가장 오래 사용해 온 사람은 이제까지 이런 현상을 전혀 겪을 일이 없었다는 겁니다. 전에 아말감씨가 겪었던 "이상한에러"를 연상케 하는군요. 모든 버그는 (과학적 방법론처럼) 기본적으로 특정 조건 하에서 동일하게 재생산가능(reproducible)해야 추척/박멸이 가능합니다. 한번 관찰해 보도록 하죠. --김창준
제 경우에는 이렇더군요. 에디트 후, 'Save Changes'버튼을 누르고 나서 계속 상태바만 쪼금씩 늘어나면서 오랫동안 멈춰 있습니다. 계속 기다리면 결국 페이지를 찾을 수 없다고 나오구요.. 그러고 나서 다시 그 페이지를 보면, 텍스트가 잘려져 있습니다. 이상한 것은 페이지를 돌아다닐 때는 딜레이 없이 아주 잘 된다는 것이죠. 아마 페이지 내용을 저장하다가, 중간까지만 저장하고 마는 것 같습니다. 변화가 모두 다 반영되던지, 아예 안되던지 하는 기능이 있으면 어떨까 생각합니다. All or Nothing. --지원

1.5. IsbnMacro 자동화/국제화

이 기능에 작은 제안을 합니다. 우선 E와 K의 구분을 국제 표준인 국가코드를 넣어 us/kr/jp/fr/uk 등을 넣는 것이 어떨까요? 국가 코드는 도메인 이름 등에 쓰이므로 친숙하리라고 봅니다. 영어 책은 아마존, 한글 책은 알라딘으로 연결하는 듯 싶은데, 일본 책이라면 아마존 재팬, 프랑스 책이라면 아마존 프랑스 등으로 연결하는 쪽이 더 낫겠죠. (영국 책은 아마존 UK도 있고요..) (이건 InterMap과 같이 위키를 통해 리얼타임 설정/수정/추가할 수 있게 바꿀 수 있겠죠. 그런데 많은 나라 지원이 얼마나 의미가 있을지...(복수 서점 지원은 몰라도) FeatureEnvy or BDUF? )

또 ISBN의 첫 두 글자가 89라면 한국에서 찍힌 책입니다. (다른 나라는 모르겠습니다.) 언어를 생략했을 때, 89로 시작하는 책은 우리나라에서 찍힌 책으로 자동으로 인식하도록 하는 건 어렵지 않으리라 봅니다. 일본의 경우 ISBN이 4-로 시작합니다. (제가 가진 책(망가:))의 경우엔요.)
그렇군요! ISBN 자체에 국가 코드가 있으니까.. 고맙습니다. 한번 생각해 봐야겠습니다.)


그렇지만, IsbnMacro 없이 InterWiki 기능만으로도 거의 비슷한 효과(이미지 링크는 안됨)는 볼 수 있습니다. 예컨대, ISBN:0345340426 처럼. --이상 김창준

1.6. WikiName

모인모인의 CVS 버젼엔 !MoinMoin이라고 치면 MoinMoin처럼 보이지 않고 MoinMoin처럼 되도록 하는 패치가 있습니다. (세줄인가 네줄 짜리.. 간단하죠.) 이 기능이 노스모크엔 아직 없는 듯 싶군요. 이 기능도 옮겨주세요.
CVS버젼에 normalword 기능이 추가되었다고 하셨는데, 어디 CVS를 말씀하시는 건지? sourceforge의 적통 MoinMoin CVS에는 없던데요? 저도 메일링 리스트를 보고 있습니다만 위르겐 허르만이 승인한 적도 없었고...
parser/wiki.py에 _notword_repl로 들어가 있습니다. config.py에 bang_meta 값을 1로 설정해 주면 동작하도록 되어 있습니다. 즉 기능은 들어가있지만 활성화는 안 되어 있는거죠.
아, 그랬군요. OP가 올린 patch로 하지 않고 config로 설정하게 바꿔서 넣었군요. 역시 보수적인 허르만.. 크..

1.7. 역링크 cache 문제

때때로 OrphanedPagesWantedPages의 업데이트가 제대로 되지 않는 상황. Shell을 통해 직접 wiki파일을 지울 때에 발생. 역시 손으로 cache 디렉토리를 다 지워주면 해결됨.

1.8. 제목을 통한 역인덱스

제목 부분을 눌러 검색할 때에 한글 WikiName은 복잡하게 정규식이 보이는군요. 깔끔하게 할 수 없을까요? -- 까리용
YouArentGonnaNeedIt에 입각해서 만든겁니다. 그걸 아무도 문제삼지 않더군요. 그거보다 더 중요한 문제도 많고. 하지만 이건 페이지이름 인덱싱(및 역인덱싱)을 하는 과정에서 자연스래 해결될 겁니다.

1.9. 역인덱스 문제

역인덱스를 구할 때에 fullsearch action macro를 이용하는 대신에 getPageLinks(Page.py에서 정의된 함수)를 이용해서 구현한다. 위의 정규식 문제를 깔끔하게 해결할 수 있다.

1.10. ID 표시하기

UserPreferences에 들어갔을 때, 이미 로그인이 되어 있다면 직접 자신의 홈페이지로 가는 링크도 보여주는 게 어떨까요? 물론 북마크 등으로 해결할 수도 있겠지만, 최소한의 click으로 자신의 홈페이지로 접근할 수 있을테니깐요. 양손항해 시나 특히 한손항해를 하는 경우에 편리하리라 봅니다. (참고로 전 한손항해시에 한 손은 마우스에, 다른 한 손은 안 쓰거나 필요에 따라 space bar와 TAB에 놓고 놉니다.)
고형화로 다가갈 수 있어서 피하고 있습니다. 오래 사용해 보시면 아시겠지만 대부분의 사용자들이 가장 빈번히 보는 곳은 RecentChanges입니다. OriginalWiki에서도 이런 기능을 요청하는 사람들이 많았는데, 한결같은 대답은 "브라우져의 북마크 기능을 써라" 였습니다. 제 경우 자주 가는 페이지는 ctrl+alt+1 등으로 윈도우 데스크탑에 바로가기 핫키를 설정해 두고 사용합니다.

또다른 방법으로 [[LoginId]] macro는 어떨까요? login된 상태면 loginid를 WikiName으로 표시하고, login되어 있지 않으면 UserPreferences를 표시하도록 하면요. 그렇다면 대문등에 "내 홈페이지로 가기 [[LoginId]]" 식으로 쉽게 꾸며넣을 수 있을 듯 싶군요.
이건 재미있겠군요. --김창준
RandomPage 마크로를 응용하면 될 듯 싶네요.

1.11. 노스모크모인모인의 개발 방향

제가 생각하는 확장성은 일단은 실제 사용자 중심이고, 두째는 개발자 중심(modularity, reusability, etc., etc...)입니다. 그리고 노스모크모인모인은 철저히 DTSTTCPW의 원칙에 의거해서 만들어 집니다. 프랑스 사람이 쓸 거 생각 안하죠. 대신 코드 디자인의 질을 높여서 원하면 쉽게 바꾸게 할 겁니다. 그리고, IMDB도 현재 InterWiki에 걸려 있습니다. E/K를 en/ko로 바꾸는 것 등 모든 설정은 위키를 통해 누구나 다 바꿀 수 있게 할 겁니다. 까리용씨나 누군가가 en/ko/ja 등을 써서 멋진 "전세계 서점 링크표"를 만들 수도 있겠죠. -- 김창준

1.12. 모인모인의 성능과 확장성

근데 이런 것들보다 더 큰 문제는 performance, scalability (가상적인게 아니라 현재 닥친) 입니다. 제가 알기로는 노스모크가 그 규모로는 세계에서 가장 큰 모인모인인데(1000페이지 넘는 곳도 거의 없습니다), 요즘 들어 접속수가 한 달마다 두배씩 증가하고 있어서 장난이 아닙니다. 엊그제인가는 호스팅업체에서 서버 Load가 너무 올라갔다고 주의까지 주더군요.. 지금은 이런 문제랑(python cgi의 한계일런지도..), 현재 코드를 ReFactoring하는게 급선무입니다. --김창준
그런데 최근의 급작스런 접속량 증가가 해킹 시도가 아닌가 하는 생각이 드는군요. 특정 IP에서 무의미한 접속을 거의 24시간 내내 시도하고 있습니다.

1.13. LikePages의 한글 지원 강화

지금의 노스모크처럼 제목을 붙여쓰는 경우엔 LikePages가 무용지물입니다. WikiName을 처리하던 것처럼 단어를 기준으로 자르기가 애매하기 때문이겠죠. 한글일 경우엔 글자수를 기준으로 자르면 어떨까요? 예를 들어 미용사의철칙이라면 "미용.."과 "..철칙"을 검색하는거죠. 미용패션분류, 미용패션지도와 함께 발사의철칙이 검색되겠죠. 물론 스트라빈스키를 검색하면 "..스키"에서 니진스키시베리안허스키가 검색되겠지만요. :) 대충 한글 한 글자는 너무 짧고, 세 글자는 너무 길 듯 싶네요. 두 글자를 기준으로 검색한다면 꽤 유용한 결과가 얻어지리라 생각됩니다. 잘릴 때에 한글 반자가 남는 경우를 조심해야겠죠. -- 까리용

좋은 발상입니다. 여유가 되시면 까리용님이 해결해 주셨으면 하는데... (페이지이름 목록은 지원되는 인터페이스(wikiutil.getPageList(config.text_dir))를 사용하시면 노스모크모인모인과 충돌 없습니다.) --김창준

1.14. 확장된 WikiName 지원

OriginalWiki 식의 WikiName을 확장한 MetaBall에서 쓰는 방식은 어떨까요?
((대문자 소문자+){2,}) 대신에 (대문자+ 소문자+ 대문자 (대문자|소문자)*)로요.

1.15. 행 분할이 제대로 되지 않는 문제


this is
'''bold'''
text
를 넣으면
{{|
this is
bold
text
|}}
식으로 보입니다.

this is Smile :)
test
를 넣으면
{{|
this is Smile :) test
|}}
식으로 보입니다.

this is higlighted
then and so on
에서 highlighted가 highlight되면,
{{|
this is highlighted then and so on
|}}
식으로 보입니다.

1.16. 수정내용 Coloring/Highlighting

특정 페이지를 관심있게 지켜보는 경우가 많은데, 이때 어느 부분이 수정되었는지 표시가 되지 않아 답답한 경우가 많습니다. 개인별 profile을 이용해 마지막으로 그 페이지를 본 이후에 어느 부분이 추가, 수정, 삭제되었는지 표시해주었으면 좋겠습니다. 북마크 기능이 수정된 페이지, 새로 만들어진 페이지를 표시해주기는 하나 전체 페이지에 대한 정보만 담고 있기 때문에 충분하지 않습니다. 개인별 profile로 이러한 정보를 관리할 경우, 회원수n x 페이지수m 만큼의 정보를 기록해야 하는 문제점이 있지만, 각 회원별로 기억하는 페이지수를 적절히 조절할 경우 큰 문제는 없으리라 생각됩니다.

개인별로 북마크를 이용한 "마지막으로 접속한 이후 수정 사항 표시"는 줄 단위에서는 현재 지원되고 있습니다. 글자 단위로는 아닙니다. 한 때 구현을 했다가 속도가 느리고 크게 필요성을 못느껴서 빼버렸습니다. 북마크사용법을 읽어보세요.
빨강파랑 색안경 아이콘의 Diff기능이 그것인 모양이군요. 저는 이 기능이 그냥 마지막 수정내용을 보여주는 것이라 어림짐작을 했었네요. 제 아이디어는 페이지를 기본적으로 보여줄 때 변화부분을 표시해주는 방식입니다. 예를 들어 지금의 경우에도 모인모인문제점이라는 긴 글에서 특정 부분만 수정되고 있는데 이 부분이 어디인지 잘 몰라서 헤매기 때문입니다. 혹시 빠뜨리고 넘어간 부분은 없는지 한번 더 찾아보게 되고요.
선글라스가 아니고, RecentChanges에서 초록색 업데이트 아이콘을 누르면 됩니다. 그리고, 기본 화면에 델타를 보여주는 것은 http://clublet.com/ 에서 그 기능을 지원합니다. 새로 추가된 줄은 옆에 노란 막대기 표시가 되죠. 노스모크모인모인에도 이 기능을 추가 했다가, 별 활용도가 없어서 빼버렸습니다. 위키 철학에 위배되는 면도 있고요.
한가지 기존의 북마크와 다른 점이라면 북마크 표시 링크를 따로 눌러주지 않아도 되는 장점이 있습니다. 그 사람이 글을 읽는 것 자체로 조회정보가 업데이트되는 것입니다. RDB의 Scheme으로 보자면, 회원id, 페이지id, 마지막조회일시 정도의 column으로 구성된 table을 사용하여 각 이용자의 매 페이지별 조회일을 기억하는 것이죠. 지금의 북마크 버튼은 전체의 조회일을 모두 동일하게 간주하는 방식이어서 순서없이 대충 읽다보면 어느 글을 읽어야 하는지 헷갈리는 감이 있습니다.
제 경우는, 북마크 시점을 제가 직접 선택하는 것이 더 편한 경우가 종종 있더군요. 그리고, RecentChanges 목록에서 한 방향으로 읽어나가다 보면 제 경우 글 읽는 순서가 헷갈릴 일은 별로 없었습니다. --김창준
지금 노스모크모인모인에서 가장 속도가 느린 부분은 RecentChanges 로 생각되는데, 현재 모인모인이 어떻게 구현되어 있는지 잘 모르지만 RecentChanges에서 보여주는 글목록 정보를 개별파일들에서 읽어들이지 않고 하나의 인덱스파일로 관리하여 한번에 읽어들이게 되면 체감속도가 수십배 이상 빨라질 것으로 예상되네요. 지금은 5~6초 이상 시간이 걸리는 경우도 있는 것 같습니다. 이렇게 되면 속도 문제는 조금 덜어버리실 수 있을 것 같고요. :)
조언 감사합니다. 현재 RecentChanges는 editlog라는 로그파일 하나만 읽어와서 생성됩니다. 이걸 HTML로 만들어내는 과정에 좀 오버헤드가 있습니다 -- 페이지가 존재하는 지 검색, 접속자의 북마크 반영 등. 캐싱을 하면 좋겠지만, 접속자별로 다른 정보가 섞여있어서 그렇게 쉽지는 않더군요. 하여간 RecentChanges 속도 증진이 현 노스모크모인모인의 중요 관건 중 하나입니다.
DeleteMe 이 thread는 내용이 옆으로 새고 있어서 더 길어지면 따로 분리해야할 것 같네요. RecentChanges의 overhead가 여러가지가 있는데, 일단 페이지 존재여부를 확인하는 stat system call이 상당한 부담으로 보이고, 접속자의 북마크 반영을 위해 마지막 수정일을 확인하는 것도 큰 문제로 보입니다. 이것들이 모두 한 페이지에 2~3번 이상의 system call을 요구하게 되고, 전체적으로는 한번에 2~300페이지를 보게 되므로 대략 7~800번 정도의 system call을 호출합니다. 이 system call이 모두 file system과 관련된 것들이기 때문에 상당히 무겁고 사용자가 조금만 많아져도 5~6초 이상 시간이 걸리는 것이 당연합니다. 근본적으로 이 문제를 해결하기 위해서는 system call을 없애야 하고, 그렇게 하려면 데이터파일들을 모두 RDBMS와 같은 storage system으로 옮기는 것이 불가피합니다. RDBMS를 쓰게 되면 physical disk io, system call호출이 대폭 줄어들게 되고, RDBMS의 disk caching 효과가 상당히 큽니다. 튜닝만 제대로 하면 웬만해선 physical disk io가 발생하지 않을 수도 있습니다. 지금과 같이 파일시스템에 직접 개별적으로 데이터파일을 저장하는 방식에서는 뾰족한 수가 없습니다. 위키위키와 같은 시스템이 개발자 입장에서 효율적으로 design해 내기가 상당히 어려운 애플리케이션이로군요. DeleteMe 창준님이 이미 알고 계시는 문제이리라 짐작되지만 다른 분들께 참고가 되실까하여 적습니다.

1.17. 페이지이름바꾸기 후에

바뀐 페이지로 바로 갈 수 있는 링크가 있었으면 합니다. 바뀐 후에 제대로 바뀌었는지를 검사하고 그밖에 빠진 곳을 손으로 고칠 때도 있으니깐요.

1.19. 정규표현식과 한글

이 문제는 python이 2byte언어를 제대로 지원하지 못하는 문제이긴 한데, 한글 1글자를 regular expression으로 matching하는 경우, 앞글자의 뒷바이트와 뒷글자의 앞바이트에 match되어 엉뚱한 문자열이 검색되는 문제점이 있습니다. python이 2byte언어의 regular expression을 제대로 지원하기 전에는 이 문제가 해결되기 어려울 것입니다. perl의 경우에도 얼마전까지 이 문제가 있었는데, v5.6에서 해결이 되었는지 모르겠습니다.

1.20. RecentChanges 속도 문제

현재 노스모크모인모인 뿐만 아니라 모인모인 자체의 가장 큰 단점이자 문제인거 같은데요.. 페이지가 많아지면 많아질수록 RecentChanges 속도가 너무 느립니다. 이부분을 어떻게든 해결을 해야 할 것 같습니다. 대부분의 노스모키안들이 노스모크에 와서 가장 먼저 눌러보는 것이 RecentChanges가 아닌가요? 그런데.. 너무 느립니다...-_-;; 이대로 가다간 정말로 더 큰 문제가 생기지 않을까 걱정이 되는데요.. 어떻게 해결할 수 있는 방안이 없을까요?

1.21. \highlight에서 줄바뀜 문제

가령 홍춘이가 highlight된 크로마틱 페이지를 보면 줄바뀜이 제대로 되지 않습니다.

2. 오해 및 보류

2.1. 시각이 제대로 표기되지 않는 문제

모인모인에서 기록되는 시각이 실제시각보다 9시간 빠릅니다. 서버의 시각설정과 timezone설정이 약간 꼬인 것 같습니다. 모인모인의 문제인지 서버설정의 문제인지는 잘 모르겠습니다.
UserPreferences에서 자신의 time zone을 적절하게 선택하면 됩니다.

2.2. Diffs(안경)과 Info(파란아이) 기능

Q : Diffs 가 단계별로 보여주지 않아서, Info 누른후 View 로 일일히 바뀐점을 체크하게 되는데 이것이 버그인가?

A : 이것은 모인모인의 Diffs 기능이 기록된 시간을 t1:t2, t1:t3, t1:t4 식으로 보여주기 때문이다. 이것을 t1:t2, t2:t3, t3:t4 식으로 바꿈으로써 단계별로 보여지게 할 수 있으나, WikiIsAnEternalNow 라는 관점에서 이렇게 바꾸는 것이 더 나을지는 고민해 보아야 할 사항이다.

2.3. 메뉴 바의 가나다순 정렬

아주 사소한 내용일 수도 있겠으나, 저 메뉴명을 가나다 순으로 정렬해 주시면 안될까요? 가끔씩 메뉴의 '바뀐글' 사용을 잊고 입력창에 RecentChanges 를 일일이 쳐서 사용하는 때가 많았는데, 가나다 순으로 정렬되면 좀 더 능숙한 양손항해에 도움이 될까 싶어서 요청합니다.

A: 키보드양손항해에 네비게이션 바의 순서가 저렇게 되어있는 이유가 나와 있습니다. 간단히 말씀드리면, 항목수가 7개(MagicNumberSeven)를 벗어나지 않을 때는 가나다 순서보다는 자주 쓰이는 순서가 훨씬 나은 유저인터페이스입니다. 탭과 쉬프트 탭, alt-s, alt-z, alt-x 등을 사용해 보시면 왜 이게 편한지 알게 되실 겁니다. (NosmokeProgrammer는 모든 사항을 고려하고 고민해서 결정하려고 노력합니다)

2.4. WordIndex의 한글 처리

페이지이름에 띄어쓰기를 하지 않는 현 상황에서는 거의 불가능에 가깝다. 그다지 효용이 있을 것 같지는 않다. 페이지이름별 검색이나, 텍스트 내용 검색이나 모두 지원되므로.

"; if (isset($options[timer])) print $menu.$banner."
".$options[timer]->Write()."
"; else print $menu.$banner."
".$timer; ?> # # ?>