kiyoka.2007_06_21 RSSPLAIN

Related pages: !kiyoka.blog.list !kiyoka.blog.2007_06
555555555555555555
5

[Wiki] Wikiエンジンのデザインで悩み中...

5

参考にしているWikiエンジンはhowmEXTBitChannelEXTkahua-webEXTKamiwikiEXTです。

5

今、Geekと非Geekの両方を満足させるという非常に難しい問題に挑戦しようとしています。無謀かな...

5

Emacsからはhowmのような感覚でバリバリ編集し、Webからはちょっとした編集を簡単にやれるようなシステムを考えています。

5

なるべくWiki文法は減らす方向で考えています。

5

これだけWikiCloneがあるのに新しく作らなくても...と思うんですけどやっぱりいろいろ実験してみたいんですよね。

5

WiLiKi:Design:OriginalEXTでshiroさんも同じような事を書いておられます。

5

引用:『WikiCloneの中にはこれらのいくつかを解決した非常に高機能なものもありますが、いろいろ実験するのに便利なので結局スクラッチから書いてしまいました。』

5

そんなわけで、ユーザービリティの本をまったり読みながら毎日悩み中です。

5

 

5

 

5

COMMENTたかや

LILO でお会いしましたたかやです.

こんばんは.

同期出来ると僕は嬉しいです.

ばりばりEmacsで書いちゃって,オフラインでも検索と追記ができ,Webで書いたものも,同期で問題なく処理出来るのが欲しい.

楽しみにしてます.

5

COMMENTkiyoka

たかやさんコメントありがとうございます。

たかやさんのお望みの通りのものを考えています。

ただ『同期で問題なく...』という部分が非常に難しいんですよね。

Subversionで並行編集を許すと、必ず保存時のコンフリクトを人間が解決する必要があります。

かといってロックしてから編集する方法を選ぶと、他人の編集が終わるまで待ってもらわないといけないのです。

オプションでどちらかを選んでもらうというのも、設計できていないということと同義なので避けたいです。

何かブレイクスルーがないかなぁーと、ぼんやり考えています。

5

COMMENTYABUKI

Kiyokaさん、こんにちは

一つ、アイディアです。

最近、あるところでgitを強く推されています。たしかにいい所があります。分散コミットができるので、コミットとコンフリクト解決の分離が行えます。svkやgitなどを学んでみてはいかがでしょうか。

5

COMMENTkiyoka

YABUKIさん、コメントありがとうございます。

svkとgitを調べてみました。

どちらも、分散コミットが出来てGeekには良いかも知れませんね。^_^

今回のWikiエンジンでは、反映時のコンフリクト解決の敷居を下げる事に力点を置くので、大量のコンフリクトが発生するシチュエーションを考えた場合、分散コミットは本質的な解決にならないかもです。

せっかく教えていただいたのにすみません。

情報ありがとうございました。

5

COMMENTYABUKI

なるほど、それだとSCM(Software Configuration Manager)単体では解決できない問題ですね。問題を分割統治するという方法で、コミットとリポジトリへの更新が分かれるだけでは解決にならない。

むしろ、コンフリクトが起きないような解法が必要そうですね。(少なくとも、*大量*には発生しないしくみ) Ajaxとかで編集している所が他人にも明示的に判るとかでしょうか。

編集者同士で日本の企業文化の一つである「根回し」みたいなことができているとコンフリクトが減りそうですね。システム的なサポートをどうしたらいいのかは思い付きませんけど。

5

COMMENTkiyoka

> [YABUKIさん]

> むしろ、コンフリクトが起きないような解法が必要そうですね。

そうですね。多くのWikiエンジンはコンフリクトが起きる可能性のある『自動マージ』という道を選ばず、先にコミットしたものが勝つ(先勝ち)にしているものが多いですね。

理想はAjaxによるリアルタイムのフィードバックなのでしょうが、かなり実装が難しそうです。(ExcelのBook共有のイメージです。)

このあたりを考えるのが難しくもあり、自分で作る醍醐味ですね。

5

...comment disabled...