2008詳しいことは後日書くが、2個口で25kgくらいの梱包の機械。昨日昼過ぎに届いてから、なんだかんだで開梱から機械部分の組み立て完了まで7時間もかかってしまった。本業に戻って、今度は電気配線関連の処理をするつもり。配線は2~3時間で終わるんじゃないかと思っている。どれだけ世界が変わるんだろうか。Dekiwikiを自社内のサーバに導入した。moongiftでは手放しで絶賛していたがその実力はいかに。Cooke)のソース版。こちらからダウンロードできる。導入自体はチュートリアルやあちこちのサイトに書いてある通りで殆ど苦労せず。mono関係もFedora8であればmono1.2.xが入るので問題ない。mono-*.x86_64という結構乱暴なことをしているところが反省したいところだ。repositoryがあるのでそれを定義した設定ファイルを/etc/yum.repos.d/以下においてyumで入れる、という手があるとのこと。うちの場合は更新時面倒なことになるのがイヤなのと、VirtualHostをいくつも定義している都合でこの方法は使わなかった。Pathでいうところのscript/action/config/pathの規定値。これが正しい内容になっていなかったせいでAPIが正しくコールされず、下記のエラーが出てしまっていた。404pathの値は、APIコールされる先(規定ではttp://localhost:8081/deki/@about)の下線部をいれておくのが正しい。うちでは規定通りにしたかったので、deki、と書き直して旨く動かすことが出来た。いくつか問題が・・これでひとまず動いたdekiwikiだが、階層構造が閉じている状態のとき、クリックしても何ら反応してくれないという問題に出くわした。falseしていることが原因の模様。php側のソースをさらってみたものの、それっぽいコードは見あたらない。c#ソースのほうに原因があるとすれば結構根っこが深い問題なのでどうしたものだろう。(追記:フォルダをいくつか作っているうちに解決した。キャッシュか何かが影響していた可能性もあるので、同じ現象が起きたら再度追跡してみたい。)さらに、添付したファイルが開けないという問題もあった。logに下記のようなエラーが出る。LoadModule.これはdekiwikiの問題ではなく、apacheの設定が不足していた。調べてみると、mod_proxyだけでなく、mod_proxy_httpもLoadModuleしておく必要があったようだ。httpd.confを修正して再起動することでこの問題は解決した。wikiとしての評価インストールに手間がかかるといってもわかればさほど難しいものでもないし、社用で使うには他のwikiの追随を許さないくらい使いやすい。ユーザをグループとして管理する機能は社用では必須といっても過言ではないだろうし、独自wiki記法の類も覚える必要は一切ない。知識のあまりない人でも低い学習コストで使い始めてもらうことが出来ることは大変ありがたい。レスポンスがちょっと悪い(CPU負荷を食ってるのかAPI通信で遅いのかは不明)のが難点ではあるが、これも昨今のCPU速度をもってすれば殆ど気にならない程度で済む(うちではPentiumD(DualCore)/3GHzのネイティブ環境に導入)。それに加え、ページの階層を強く意識させる構造があることも、wikiを普通の人に勧めるときに困る「とっかかりがつかみづらい」問題の回避に役立つと思う。Connector、Modules。いずれもSourceForgeのダウンロードページにあるので、時間のある方は試してみていただきたく。何かあったらネタとしたい。いう文字に置換されて表示されるようになっていた。前置きはさておき、これを直すには、~/.bash_profileの適当な行に、TERM環境変数を書いてやればいいようだ。TERM=linuxちょっと困ったが大変困るわけでもないので放置していたが、これで快適になる。