昨日昼過ぎに届いてから、なんだかんだで開梱から機械部分の組み立て完了まで７時間もかかってしまった。ひとまずいったん本業に戻って、今度は電気配線関連の処理をするつもり。配線は２～３時間で終わるんじゃないかと思っている。

どれだけ世界が変わるんだろうか。楽しみだ。

導入

まず、導入先環境と導入したDekiwikiのバージョンだが、Fedora8にDekiwiki8.05.1(Jay Cooke)のソース版。こちらからダウンロードできる。

導入自体はチュートリアルやあちこちのサイトに書いてある通りで殆ど苦労せず。mono関係もFedora8であればmono1.2.xが入るので問題ない。ただ、どのコンポーネントが要るのか不明だったことと、他の問題(後述)の原因がmonoにあると思いこんでいたので、yum install mono-*.x86_64という結構乱暴なことをしているところが反省したいところだ。もっと手軽にやりたい場合、dekiwiki用のyum repositoryがあるのでそれを定義した設定ファイルを/etc/yum.repos.d/以下においてyumで入れる、という手があるとのこと。うちの場合は更新時面倒なことになるのがイヤなのと、VirtualHostをいくつも定義している都合でこの方法は使わなかった。

startup.xmlを直す

はまりどころは１カ所、/etc/dekiwiki/mindtouch.deki.startup.xmlに記述する内容で、XML Pathでいうところのscript/action/config/pathの規定値。これが正しい内容になっていなかったせいでAPIが正しくコールされず、下記のエラーが出てしまっていた。

Site settings could not be loaded
We were unable to locate the API to request site settings. Please see below for debugging information.
HTTP Response Status Code: 404

pathの値は、APIコールされる先(規定ではttp://localhost:8081/deki/@about)の下線部をいれておくのが正しい。うちでは規定通りにしたかったので、deki、と書き直して旨く動かすことが出来た。

いくつか問題が・・

これでひとまず動いたdekiwikiだが、階層構造が閉じている状態のとき、クリックしても何ら反応してくれないという問題に出くわした。早速ゴキブリ^H^H^H^HFirebugsを出してつついてみると、一つ上位のDOMがonClickイベント時にreturn falseしていることが原因の模様。ちょっとphp側のソースをさらってみたものの、それっぽいコードは見あたらない。c#ソースのほうに原因があるとすれば結構根っこが深い問題なのでどうしたものだろう。

(追記：フォルダをいくつか作っているうちに解決した。キャッシュか何かが影響していた可能性もあるので、同じ現象が起きたら再度追跡してみたい。)

さらに、添付したファイルが開けないという問題もあった。ブラウザではInternal Server Errorの表示だが、httpdのerror logに下記のようなエラーが出る。

[Sat Jun 21 04:47:25 2008] [warn] proxy: No protocol handler was valid for the URL /@api/deki/files/1/hogefuga.dat. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.

これはdekiwikiの問題ではなく、apacheの設定が不足していた。調べてみると、mod_proxyだけでなく、mod_proxy_httpもLoadModuleしておく必要があったようだ。httpd.confを修正して再起動することでこの問題は解決した。

wikiとしての評価

インストールに手間がかかるといってもわかればさほど難しいものでもないし、社用で使うには他のwikiの追随を許さないくらい使いやすい。ユーザをグループとして管理する機能は社用では必須といっても過言ではないだろうし、独自wiki記法の類も覚える必要は一切ない。知識のあまりない人でも低い学習コストで使い始めてもらうことが出来ることは大変ありがたい。

レスポンスがちょっと悪い(CPU負荷を食ってるのかAPI通信で遅いのかは不明)のが難点ではあるが、これも昨今のCPU速度をもってすれば殆ど気にならない程度で済む(うちではPentiumD(DualCore)/3GHzのネイティブ環境に導入)。それに加え、ページの階層を強く意識させる構造があることも、wikiを普通の人に勧めるときに困る「とっかかりがつかみづらい」問題の回避に役立つと思う。

時間切れでさわれなかったネタ：Desktop Connector、Outlook Connector、Modules。いずれもSourceForgeのダウンロードページにあるので、時間のある方は試してみていただきたく。

また何かあったらネタとしたい。:-)

　前置きはさておき、これを直すには、~/.bash_profileの適当な行に、TERM環境変数を書いてやればいいようだ。

export TERM=linux

　ちょっと困ったが大変困るわけでもないので放置していたが、これで快適になる。

これまでのwordpress-meが３月で公開終了となったことと、security fixが多々出ていたことにいい加減対応せねばならないこととで、表記の移行を行った。

さらに、最近あちこちで話題になっているWindows Live Writerを使うことにしてみた。ここしばらく、Macへ移行したくてしょうがない所ではあるのだが、せめてWindowsを使い続けるからには使える便利な物は全て使っていきたい。

このポストがWindows Live Writerでの初ポストとなるが、割と使いやすいので今後しばらくはこれをメインにしてみようと思う。

面倒なのはデザインだ。元々使っていたデザインも変更したいと思っていたので良い機会と捉えて変更する予定。しばらくはこのデフォルトテーマでお許し頂きたく。