2005-01-19

まとまらないまま情報共有、協調作業ツールをメモる

情報共有について考えていたときに ML と RSS を使うのはよさげな方法だと思った。

qwikWeb のような ML + Wiki であればわざわざ RSS を別に使う必要はないかなという気もするが、qwikWeb が Wiki の変更をメールに逐一流すかどうか分からないし、流れてこない方が ML が汚れないという判断もあるような気がする。

要するに目的は作業スペースからの更新情報と、作業スペースより上位のフレームでの議論を手軽にシームレスに扱いたいということだ。これを思いついたのは Thunderbird が RSS リーダを内蔵しているから。1Wiki の変更を補足しつつ ML で内容や方針の議論を行う。これはとてもよい方法だと思う。2blog を書くことだけにフォーカスしていない RSS リーダーの使い勝手は重要だな。今でもよほど感度の高い人でないと RSS なんて使ってないんだよなぁ。blog や技術ネタのサイトばっか見てると全然分からないことだけど。

qwikWeb は特定の WikiEngine にバインドされるから、Wiki 側で様々なユーザー認証を pluggable に実装し、なおかつそれが汎用のフレームに育ってくれるといいのかな? ML マネージャを別なものにしたいと思う人もいるだろう。難しいなぁ。

実現性を無視して、ほしいツールは「proxy付きWeb付箋(wema3?) + reStructuredText で書ける Wiki + ML」なのかな。ただ、ML も Wiki も案外普通の人には使いこなすのが難しいものだってのがネックだけど。

  1. RSS リーダ用のアカウントを作る必要あり。しかし OPML などでのインポート/エクスポートはできないとつらいよなぁ。 

  2. できれば reStructuredText で Wiki ができていれば snapshot を ML に流すのもとても簡単で違和感なく行える。 

思いつくままほしいというか面白げな Wiki を書く

  • 「ページ」をフラットなテキストではなくヘッダとボディに分け、「オブジェクト」として機能するページを構成する
    • ZWiki を使ったことがある人には分かりやすいかな?
  • こうしておけば認証の設定やページの親子関係、カテゴリなどの情報を簡単に保持できる。もっと簡単な例で言えば alias や URI として現れるページ名と実際のページタイトルを分ける、なども思うまま。(ただしインターフェイスが難しいけど)
  • テキストファイルをストレージにする場合はヘッダを YAML とかにすればいいかな? テキストファイルをストレージにするのは以下のメリットがあると考えている。特に3番を考えると XML 化しちゃうのはなんか邪魔くさいだけのような気がする
    1. DB が壊れて全部オジャンという事態を避けられる
    2. バックアップを差分で取るのも簡単にできる
    3. テキストツールでガリっと内容変更できる
  • 記法もストレージも認証方法なども自由に選べると嬉しい
    • CMS としての利用を考えると汎用 DIV コンテナを生成できると嬉しい
    • もいっちょ静的 HTML の吐き出しも普通にできるとチョーいい
    • 現在も Wiki によっては複数の記法をサポートしているけど

Wiki原理とは異なると思うけど、このように思うのは技術ドリブンでいたずらに複雑にすることが目的ではなく、one resource, multi use を志向した結果。要するに「ページ」の持つ情報に冗長性がほしいということ。Wiki はとても便利だが、Wiki 上の情報を Wiki にアクセスしない人間にも提供したいという要求には simple なだけでは応えられない。

ついでに Wiki ベースのユーザーによる編集を想定しない CMS は

Wiki 単体で考えるのではなくリバースプロキシ込みで考えるべきだと思う。やっぱ Wiki って重いんで。

分かりやすさ

例によって textfile.org 経由で わかりやすさは、ただの表現技術の問題ではないのだ。

わかりやすさは器用な解説屋さんの小手先テクニックじゃない。もっともっと本質的なものだ。

はいここテストに出しますよ。勝手に言い直すとばか丁寧に書いたって決して分かりやすくはならない

※ 自分の中でこの日記は「自分が分かるために書く」ものなので、書かれたものは決して分かりやすくはありません。

時間とか将来の設計とか

すぐに何かするわけじゃないけど @IT 自分戦略研究所よりメモ。

About

例によって個人のなんちゃらです