詳しいことは後日書くが、2個口で25kgくらいの梱包の機械。
昨日昼過ぎに届いてから、なんだかんだで開梱から機械部分の組み立て完了まで7時間もかかってしまった。ひとまずいったん本業に戻って、今度は電気配線関連の処理をするつもり。配線は2~3時間で終わるんじゃないかと思っている。
どれだけ世界が変わるんだろうか。楽しみだ。
月 | 火 | 水 | 木 | 金 | 土 | 日 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 | 31 |
詳しいことは後日書くが、2個口で25kgくらいの梱包の機械。
昨日昼過ぎに届いてから、なんだかんだで開梱から機械部分の組み立て完了まで7時間もかかってしまった。ひとまずいったん本業に戻って、今度は電気配線関連の処理をするつもり。配線は2~3時間で終わるんじゃないかと思っている。
どれだけ世界が変わるんだろうか。楽しみだ。
moongiftで紹介されていたエンタープライズ向けwikiであるMindtouch Dekiwikiを自社内のサーバに導入した。moongiftでは手放しで絶賛していたがその実力はいかに。
まず、導入先環境と導入した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をいくつも定義している都合でこの方法は使わなかった。
はまりどころは1カ所、/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記法の類も覚える必要は一切ない。知識のあまりない人でも低い学習コストで使い始めてもらうことが出来ることは大変ありがたい。
レスポンスがちょっと悪い(CPU負荷を食ってるのかAPI通信で遅いのかは不明)のが難点ではあるが、これも昨今のCPU速度をもってすれば殆ど気にならない程度で済む(うちではPentiumD(DualCore)/3GHzのネイティブ環境に導入)。それに加え、ページの階層を強く意識させる構造があることも、wikiを普通の人に勧めるときに困る「とっかかりがつかみづらい」問題の回避に役立つと思う。
時間切れでさわれなかったネタ:Desktop Connector、Outlook Connector、Modules。いずれもSourceForgeのダウンロードページにあるので、時間のある方は試してみていただきたく。
また何かあったらネタとしたい。:-)
前まで使えていた気がするのだが、いつからかPuTTY経由でLinux(Fedora8)に繋ぐとhome/endキーが使えず、~ という文字に置換されて表示されるようになっていた。
前置きはさておき、これを直すには、~/.bash_profileの適当な行に、TERM環境変数を書いてやればいいようだ。
export TERM=linux
ちょっと困ったが大変困るわけでもないので放置していたが、これで快適になる。