노스모크모인모인/제안

user profile의 비밀번호 암호화 ¶

혹시나 해서 찾아봤는데, user profile의 비밀번호가 암호화되지 않고 그대로 plaintext로 저장되어 있습니다. 이렇게 되면 관리자가 의도하게/의도하지 않게 전체 회원들의 비밀번호가 그대로 눈에 보이게 됩니다. 이 부분에 대해서는 전체 회원들에게 미리 문제를 알려주는 것이 필요하다고 생각됩니다.

암호화라는 것이 항상 안전하지는 않지만, 그래도 암호화되지 않은 비밀번호가 돌아다니는 것보다는 훨씬 낫다고 봅니다. --Aragorn

[edit]

인터페이스 ¶

RefactorMe

페이지 맨 아래에 '맨 위로' 보내는 걸 넣는게 어떨까요? 긴 페이지를 읽고 나서 한번만 누르면 페이지의 맨 위로 갈 수 있게요. 스크롤바 한참 올리는게 불편하더라구요. --김선주

그것보다 키보드양손항해를 하시길 권합니다. 특히 alt-z,x. --김창준

(아, 여기다 쓰는거구나) 인터페이스 관련해서 궁금한게 있었는데, 예전에 엉뚱한 곳에 써놓고선 답을 기다렸나 봅니다. "제목" 이란 말을 두 곳에서 보게 됩니다. 첫번째는 "주메뉴"에 있는 것으로서 그것을 누르면, 모든 페이지가 보여집니다. 두번째는 모든 페이지의 "페이지제목"이지요. 간혹(?) 자주(?) "분류페이지"를 들어갔을 때 "전체를 보시려면 제목을 클릭하십시오." 뭐 이런말을 종종 보게 됩니다. 근데 전 분류페이지에서 나오는 제목을 누르라는 말에서의 "제목"이 진정 어느 제목을 말하는 건지 아직도 잘 모르겠습니다. 처음에는 분류페이지의 안내문을 볼 때마다, 해당 분류의 "전체 글을 보려면"으로 알아듣고, 주메뉴에 있는 "제목"을 클릭하고선, 매번 실망을 했었더랍니다. 지금에야 전 두가지의 제목이 서로 역할이 다름을 알게 되었지만. 진정으로 분류페이지 속에 적혀 있는 안내문의 "제목"이 무엇인지를 명확히 알고 싶습니다. 그것이 "페이지제목"을 의미하는 것이라면 주메뉴의 "제목"이란 텍스트를 바꿔야 하지 않을까 생각합니다. 아니라면, 안내문을 모두 제거 하던가 해야겠지요. --bullsajo

그런점이 있으리라고는 생각을 못했군요. 항해막대기의 "제목"을 그냥 삭제하는 것이 좋겠습니다. --김창준

에.. 저는 그거 많이 이용하는 편인데요... 항해막대기에서 '제목'을 없앨 것이 아니라 분류페이지마다 있는 "제목"을 "페이지이름" 정도로 바꾸면 되지않을까요? (물론 한번에 다 말고 차근차근히..) 항해막대기의 '제목'이 의미가 명확하지않은 문제는 "인덱스" 정도로 바꾸면 될 것같고요..(굳이 안바꿔도 괜찮고 만일 바꾼다면요..) --우산

항해막대기에선 빼버리되, TitleIndex 페이지는 그대로 남겨두고 다른 페이지에서 링크 건다든지 해서 활용하는 건 어떨까요? 항해막대기에 있어야 할 정도로 많이 쓰이나요? 페이지 숫자가 늘어날수록 TitleIndex 페이지 사용횟수는 계속 줄어들 것이라고 생각합니다만. ("인덱스"는 좋은 아이디어 같습니다.)

다른 곳에 링크할 좋은 장소가 있으면 그렇게 해도 괜찮을 것같고요.. 페이지가 많아져서 인덱스가 로딩시간이 길긴한데 그점에 대해서는 한글제목페이지인덱스랑 영어제목페이지인덱스를 분리하는 게 어떨까 하는 생각을 했었죠, 이거 어때요? (제가 "인덱스"기능을 이용하는 건, 제 기억에서조차 잊혀진 페이지들을 다시 찾아서 문서구조조정하거나 할 때 써요..) --우산

한글과 영문페이지인덱스 분리는 좋은 생각 같습니다. 잊혀진 페이지를 찾는 것에 대해서는, 처음에 이름을 잘 지어놓아서 나중에 그런 페이지가 있는 것을 까먹었거나 아니면 전혀 모르는 상태에서 페이지를 새로 만들려고 했더니 이미 그 이름의 페이지가 (귀중한 자료와 함께) 있는 것을 찾게되는 우발적링크를 선호합니다. 하지만 꼭 찾고 싶다면 한쪽 벽짚고 돌기가 도움이 되긴 하겠죠. 전 요즘은 FindPage 기능과 LikePages만으로 만족하고 있긴 합니다만.

아니.. 제목을 까먹은 게 아니라.. (내가 오랫동안 안들어오는 동안 만들어져서 모르는 페이지라거나) 머 제목이 잘못 달렸다거나 내용이 없는 페이지가 만들어졌다거나 암튼 이런저런 실수들로 쓸모없는 버려진 페이지들이 가끔 있더라고요.. 몇번 그런 걸 찾아 지우거나 조정하는 걸 했으니 점차 그런 페이지들이 줄어들 것이고 앞으로 점점 필요없기를 바라기는 해요.. 근데 다들 페이지이름을 우발적링크가 걸리기 쉽게끔 깔끔하게 달고 있는 게 또 아니어서...

저는 항해막대기의 제목은 없어져도 된다고 생각해요. 처음 오는 사람들은 분류별로 내용에 접근하게 되어 있어요. 그룹핑된 글을 봐야 노스모크의 흐름을 알 수 있으니까요. 즉, 분류나 지도를 최대한 활용할 수 있는 길 안내가 더 절실하고요. 익숙해지면 역시 익숙한 사람으로서 필요한 일은 "키워드"만 가지고도 목적을 달성 할 수가 있지요. 익숙한 노스모키안은 TitleIndex를 "입력창"에 바로 입력하겠네요. 초심자를 위한 길 안내를 위해서는 HelpContents내의 잘 보이는 곳에 위치시키면 아무런 문제가 없을 것으로 보입니다. 어떤가요? --bullsajo

현재 노스모크와 비슷한 시스템을 ASP로 만들고/쓰고(그러니까 사용하면서 계속 개선이 되는 중에...) 있습니다. 개인적으로 동아리 사람들 간의 KMS시스템으로 쓰고 있거든요 ^^. 그것을 만들면서 노스모크의 기능을 하나하나 자세히 보게 되었는데요. 정말 놀라울 뿐입니다. UI조차 똑같이 만들어서 쓰고 있었는데 몇가지 요구 사항이 들어왔었습니다. 분류 페이지에서 전체 리스트는 제목 클릭 이라는 말이 보통 있지요? 여기서 제목 이라는 것을 그 페이지의 타이틀을 뜻하는 건데... 사람들이 제목 이라는 메뉴를 누르더군요. 해메고 있더라구요. -_-; 그래서 저는 제목 이란 이름을 INDEX라고 바꿨습니다. 노스모크는 그런 일 없나요? 저는 지금 초기 참여자가 어떻게 하면 더 빠르게 위키위키 시스템에 적응할 수 있을 까 하고 고민하는 중이랍니다. --커널0

바로 위에서 보시듯이 안그래도 최근에 논의중이었답니다. 조만간 해결이 될 것같습니다.

일단 우산씨의 아이디어를 따라 항해막대기의 "제목"을 "인덱스"로 고쳤습니다. 그리고, 어떻게 하면 초기 참여자가 빨리 적응할 수 있을까 하는 문제에 대해 제가 얻은 교훈은 기술적인 문제보다도 인간/문화적인 문제가 더 크다는 것이었습니다. HowToBuildaWikiCommunity의 자료들이 도움이 될지도 모르겠습니다. --김창준

도움말 감사드립니다 올때마다 배워가는군요

--커널0

[edit]

다이어그램, 그래프 ¶

공대생이나 자연대생에게 유용할 것 같은 gnuplot을 이용한 [http]

PlotMacro와 Graphviz를 이용한 [http]

GraphvizMacro. 왠만한 레포트는 위키만으로 만들 수도 있을듯. 쓸일이 없어서 얼마나 유용할지는 아직 모르겠지만 쓸모가 있을 듯. --응주

PhpWiki cvs 버전에서도 VisualWiki Plugin이 생겼습니다. Graphviz를 이용

gnuplot이라면 moinmoin-1.0부터 지원하기 시작한 processor의 기능을 이용하는 방법도 있습니다. See

ProcessorMarket ko모인모인에 들어갔더군요. --고무신

[edit]

수식 표현 ¶

PhpWiki cvs 버전에서 [http]

TexToPng 를 이용하여 표현. 이건 Tex을 Png 파일로 변환하네요. 여러모로 쓸만할듯.

latex도 processor를 이용해서 만들어 보았는데

ProcessorMarket에 있습니다. -- 고무신

잘 만드셨네요. 수식을 많이 쓰시는 분들에게 참 유용하겠습니다. --김창준

[edit]

미리보기 ¶

노스모크모인모인에는 미리보기 기능을 넣지 않는건가요? 무슨 특별한 이유가 있는지요? 로드가 걸린다던지... 기타등등. 모인모인 사이트에는 미리보기 기능이 있던데요.

큰 필요를 느껴 본 적이 없습니다. 자원자가 있으시다면 미리보기 기능을 만들어 주시면(혹은 모인모인의 그것을 import해 주시면) 참 고맙겠습니다. --김창준

미리보기기능은 "모인모인SisterWiki버전"에 집어넣었습니다.

저도 미리보기가 절실합니다. 노스모크에서 자주 페이지를 고치는 것은 아니지만, 어쩌다 고치게 되면 손에 익은 다른 위키엔진과 너무 달라서 계속 저장하고 다시 고치기를 반복해야 합니다. ㅠ,.ㅠ --Raymundo

[edit]

노스모크 엔진 업데이트 ¶

모인모인-1.0(개발판은 1.1)까지 나왔는데, 현재의 노스모크의 기능보다 좋아진 것들이 많습니다. 그중에 processor의 기능이 첨가된 것이 가장 큰 것인데 (moin-0.11에는 없던 기능) 많은 기능의 확장 가능합니다. 노스모크 엔진을 천천히 1.0(혹은 1.1)로 바꾸는 것은 어떤가요 ? -- 고무신

모인모인으로의 머지는 저번 오프모임에서도 제가 이야기를 꺼냈었죠. 브랜치 오프 상태에서 다시 머지해 들어가는 것이 쉽지는 않을 겁니다. 많은 노동력을 필요로 하죠. 충분한 인력 확보만 된다면 하는 것이 좋겠죠 -- 문제는 자원자가 없다는 겁니다. 또 한편으로는 지나친 feature envy는 아닐까 우려가 되기도 합니다. 사실 모인모인 1.1보다 노스모크 모인모인이 30% 이상 빠릅니다. 현재는 여력만 된다면 기능을 덧붙이는 것보다 현재 가진 기능을 더 빠르게 하는 데에 치중하고 싶습니다. 위키를 접한지 오래되지 않은 분들은 간혹 "이런 이런 기능을 위키에 덧붙이자"는 이야기를 많이 하는데, 이에 대해 WardCunningham은 늘 "난 위키에 무엇을 덧붙일지보다 무엇을 뺄지에 관심이 있다"고 말하더군요. 재미있는 건, 대부분의 애플리케이션에 있어서 가장 많은 "기능 요구/수정"을 원하는 사람들은 그 애플리케이션을 제일 많이 적극적으로 사용해 본 사람들인데, 위키에서는 그게 반대인 경우가 많은 것 같습니다. --김창준

제가 잠깐 테스트 해 본 결과 (잠정적 결론으로) python/python2의 차이인데 어떤 경우 두배 가까이나 python1.5x가 빠르더군요. moin-0.10 / moin-1.1 모두 python2로 돌리면 (-O)줘도 별로 차이가 없고요. (제가 테스트 한 바에 의하면, 노스모크0.1은 python2로 하면 moin-1.1과 비슷한 수준이더군요(0.05초 차이 미만) 물론 제 환경은 여기 환경과는 틀리지만요.) -- 고무신

파이썬 1.5*와 2.* 버젼대의 속도차이는 이미 널리 알려진 것입니다(특히 RE 부분). 2.*대에 와서(특히 2.2 이후) 빨라진 부분들도 있긴 합니다.

동일 서버에서, 모인모인 1.1(CVS 개발판)과 노스모크 모인모인의 차이를 ab -n 100 -c 10으로 측정해보았습니다(프로세스 워밍업은 제했습니다). 동일 페이지에 대해(편의상 WhyWikiWorks를 택했습니다), 전자 경우 약 2.5 rps, 후자 경우 약 3.3 rps가 나옵니다.

--김창준

[edit]

노스모크 배포 ¶

WikiSeed.tar
정기적으로 백업을 해서 data/text/*를 배포하는 것은 어떨까요 ? 마치 메일링리스트에서 메일링리스트의 메일박스를 압축해서 ftp에 올려놓는 것 처럼 말이죠. -- 아무개

노스모크 위키 전체를 배포하는 것보다 현재 노스모크 배포판에 들어가 있는 노스모크WikiSeed에 해당하는 페이지들을 배포하면 좋겠군요. --김창준

[edit]

동일인 수정에 대한 히스토리 병합 ¶

수정을 한 사람이 기존 마지막 수정자와 동일인이면, 그 기존 수정본은 삭제하는 기능은 어떨런지요. 적용에 시간제한(5분 이내에 재수정된 것만 적용한다던가)을 둘 수도 있겠습니다. 동일인이 같은 페이지에서 반복적으로 수정을 하면 그만큼 히스토리가 쌓이는데 좀 낭비라는 느낌이 들기도 합니다. 저도 맞춤법 틀린 것을 발견하고 딱 한글자를 고치는 일이 가끔 있거든요.

phpBB에는 BBCode라는 커스텀화된 태그 형식을 쓰고 있더군요. 직접 태그를 안 쓰는 형태라는 점에서는 위키와 유사한 점이 있는 것 같습니다. 그런데 이 BBCode를 쉽게 사용하기 위해 상단에 메뉴바가 있더군요. 이러한 형태를 노스모크모인모인에 추가하는 것이 어떨까 합니다. --씨엔

하단에 있는 WikiFormattingRule의 설명을 한글화 하면 될일인가요 ? 아니면 그 설명으로 부족하다는 말씀이신가요 ? --아무개

[edit]

WantedPages를 빠르게 ¶

WantedPages의 로딩 시간이 너무 길다라고 생각 됩니다. RecentChanges처럼 WantedPages리스트 사이즈를 제한해서 보여주는 것이 어떨까합니다. 혹은 RecentWantedPages 같은 시간적인 순서를 도입하는 것도 좋지 않을까하는 생각입니다.

[edit]

Link 마크업을 더욱 간단히 ¶

영어 페이지에 대한 링크를 붙일 때는 PageName 형태로 쓰면, 자동적으로 페이지이름에 대한 링크가 생기는데, 한글은 대소문자 구별이 없으므로, 한글 이름으로 된 페이지에 링크를 걸려면 반드시 [ ] 를 사용해야 합니다. 두 글자나 더 써줘야 한다는 게 약간 억울(?)하여, 공백을 [ 로 간주하고, 페이지 이름 뒤에 ] 만 써주면 링크가 생기는 방법을 생각해 보았습니다. 즉, 페이지이름] 이라고 써주면, 페이지이름이 생기는 거죠. 별로 좋은 아이디어는 아닌 듯 하지만, 생각난 김에 씁니다. --나를잊어줘

YoriJori가 _문자를 써서 비슷한 연결방식을 쓴다고 합니다.

[edit]

RecentChanges 에서 이전/다음 페이지 ¶

RecentChanges 페이지에서 일반 게시판처럼 이전/다음 페이지로 이동할 수 있는 링크가 있었으면 좋겠어요. --나를잊어줘

ChronologicalTitleIndex로 전체 목록을 볼 수 있긴 한데(OriginalWiki에서는 지난 몇 달의 과거 기록을 볼 수 있습니다), 기본적으로 위키에서는 ForgiveAndForget 주의와 WikiIsAnEternalNow 주의를 택하고 있습니다. 노스모크가 어떠해야 한다는 발언이 아니고, 어떤 기능이 없다는 것 자체가 의도된(디자인된) 것일 수 있다는 말씀을 드리고 싶습니다. --김창준

알겠습니다. RecentChanges와 ChronologicalTitleIndex 사이의 기능을 하는 페이지가 하나 있으면 어떨까해서 써본 겁니다. --나를잊어줘

어떤 이유에서 이전/다음페이지를 원하시는지는 이해할 수 있습니다. 탭 브라우징이 되는 "진짜 브라우저"를 쓰세요.

저는 (다른 분들도 그러리라 생각하지만) 일반 게시판에서도, 아직 읽지 못한 글을 전부 새 탭으로 띄우고 하나씩 닫아가면서 읽습니다. 결국 이전/다음페이지 기능을 쓸 일이 없더군요. --서상현

서상현님이 말씀하신 이전/다음 페이지는 RecentChanges에 표시된 페이지들 간의 이전/다음을 말하는 거 같은데, 맞습니까? 제가 위에 쓴 이전/다음 페이지는 more/less recently changed 페이지 목록을 말합니다. 즉, 지금부터 어제까지 바뀐 페이지 목록이 RecentChanges에 나왔다고 하면, 다음 페이지는 그제부터 엊그제 사이에 바뀐 페이지 목록이 나오는 거죠. 저도 서상현님이 말씀하신 대로 브라우징 하고 있습니다. --나를잊어줘

흠, 그렇군요. 생각해보니 그런 것이 필요할지도 모르겠어요. (실은 제가 탭 브라우징을 알기 전에 제가 위에 적은 식으로 불평을 했기 때문에... 그렇게 답을 달았던 겁니다 ^^) --서상현

[edit]

페이지이름 표시 ¶

페이지이름에 공백 없이 포함된 단어들을 모두 붙여쓰니 가독성이 상당히 떨어지네요. 어떤 단점에서오는장점이 있겠지만, 상당히 불편하다고 생각합니다. 그래서, 페이지이름을 쓸 때는 공백을 포함하되, 생성되는 페이지의 파일명에는 공백을 제외하는 식으로 해서, 화면에 내용이 보여질 때는 공백을 포함하여 나타나게 하는 건 어떨까요? 가령, [페이지 이름]이라고 하면, "페이지이름"이라는 페이지를 가리키지만, 화면에는 "페이지 이름"으로 표시되는 거죠. 영어도 PageName 이라고 쓰면, 화면에는 "Page Name"과 같이 표시되구요. --나를잊어줘