テーマ増量＋カレンダー折りたたみ (17:35)
MM/Memoのユーザーページで選択できるtDiaryテーマを増やしました。
ついでに、ユーザーページのヘッダ部に表示しているカレンダー（日付単位）を、年単位で折りたたむようにしました（過去・未来メモを書いている人以外にはあまり関係ない機能だけど）。
って久しぶりにMM/Memoをいじったな。
カレンダーは月まで折りたたむようにしました
まだちょっと改行処理が完全じゃないけど。
久しぶりに仕様書の原文を見たら (15:06)
__mode=rssに関する記述が消えていた。すでにobsoleteだったのね（ver.2で同様の機能を復活させる予定らしいけど）。あと、昔見た仕様書と違って、ちゃんとした仕様書文章になってるじゃん。文字コードはcontent-typeヘッダで指定したcharsetを使うのが正式な仕様になってたんだね。
PHPでやるなら、
$charset = 'auto';
foreach (getallheaders() as $header) {
if (preg_match('|content-type.*charset=(.*)|i', $header, $matches)) {
$charset = $matches[1];
break;
}
}
// $charsetからinternal_encodingに変換
なんて感じかなー（動作確認してない）。
今日のスポクラ (11:25)
今日も軽めに。最後のバイクで100kcal/15分を目指してみたんだけど、結構きつい。アベレージで100W以上の負荷を維持しなければならないとなると、足にかかる負担もそれなりに大きいし、ちょっと一生懸命やるとすぐ脈拍の警告範囲（170回/分以上）に達してしまう。ジョギングで100kcal/15分ならばそんなに辛くなかったんだけどな。よほど体力がつくまでは、バイクで100kcal/15分はあきらめるか。
Rast＋php_rast試し中 (21:09)
プチはまりその1。
- icuを有効にしないとUTF-8が使えない
- というのを忘れて、Rast、php_rastをコンパイルした。
- 後からicuをインストールして、Rastをicu有効でコンパイルし直した。
- php_rastもコンパイルし直さないと、php_rastからUTF-8が使えなかった
プチはまりその2。
- 検索インデックスを保存するディレクトリを作成し、書き込み可能にしておく
- そのディレクトリに対して、rast_db_createを実行。しかし失敗する（FALSEが返る）
- 特にエラーメッセージやエラーログも出ないので、理由が分からず悩む
- インデックスを作成するディレクトリを削除して実行したらOKだった。ディレクトリもrast_db_createが作成するってことだった
で、ひとまずインデックスに登録したり、削除したり、検索したりを一通り動かしてみた。
ちなみに、一度登録した文書が更新されたときに再登録するためには、前回登録した文書をdoc_idを使って削除しなければならず、そのためには何らかのユニークなキー（doc_id以外）を付与しておいて（Web系の検索ならばURLとか）、それを使って検索して既存文書を削除しなければならないんだね（登録時にdoc_idの方をドキュメントにひもづけておいてもいいけど）。最初ユニークキーを持たせずにインデックスを作成・登録していって、登録済みのドキュメントのインデックスを更新しようとして困った。更新される可能性があるドキュメントを登録するときにはインデックス作成時に注意。
次はある程度の分量のドキュメントを登録して、一般的な検索機能を試してみて、それでよさげだったら大量ドキュメントの登録・検索を試してみようかな。
曖昧なつながりと実行時解決によって、コンピュータ＋ネットワークを実用的な道具にする (18:10)
というのが、現在起こっていることなのではないか、と思った。
従来のコンピュータアプリケーションは、かっちりとした枠組み（仕様）の中で、自前で持っているきちんと意味づけされたデータ群を使って、あらかじめ決められた機能（サービス）を実現しようとしていた。それはそれで有用だったけど、規模が大きくなるとシステムを構築することや仕様（現実）の流動的な変動に追随することがとても大変だった。
それに対して最近流行っているアプリケーション（というかサービス）は、もっといい加減な（人間が扱いやすい）データを、いろんな形式であちこちに分散して持ちつつ（というかネットワーク上に存在することを前提に）、自前で持っていないデータはネットワーク経由でかき集め、必要に応じて必要なデータを必要な解釈（フォーマット）で取り込みつつ、それらを使って機能（サービス）を実現しているものが多い。
そういうやり方では、各要素レベルでの信頼性というものは高いとは言えないんだけど、人間が普段使う道具としては、それでも十分使い物になっている。というのは、もともと人間の普段の生活では、従来のコンピュータアプリケーションが担保していたほどの正確さは求められていないから。
というアプローチで考えていくと、何か新しい便利な仕組みが思いつくかもしれない。
一応書いておくと
もちろんそういうアプローチによって、従来型のかっちりとしたシステムを否定しているわけではない。というか、そういうものは今まで通り必要な場所で使われていくだろうし、そういうものがなくなったら困る。
ただ、今まではかっちりとした仕様に落としきることができず、システムとして構築できなかった雑多な案件について、今回挙げたようなアプローチを使えば、それなりに実用的な道具（コンピュータアプリケーション）を作ることができるし、しかもそれは従来よりも手軽に実装できる。
みたいな趣旨ですよ。コンピュータ＋ネットワークのコモディティ化は、こういうアプローチによって実現されていくのではないか、とか。
今日のスポクラ (11:26)
だいぶ疲れが出てきているけど、まだ体に無理が利くならば、ここで続けてやっておいた方が体が慣れるのが早いはず。というわけで今日も軽めに。
- ウォーキング 5分
- ストレッチ 5分
- マシン 10分
- ジョギング or バイク 15分
なんて感じだと1時間以内に終わっていい感じだな。
連想配列かどうかを判別する (06:43)
うわー、知らなかったよ。PHPであるarray型が連想配列かどうかを調べるのに、
return array_keys($array) === range(0, count($array) - 1);
なんてことができるのか。っつーか、arrayって===で比較できたのか。
うが
tDiary Wikiスタイルで===を書こうとしたら、打ち消しになっちゃうよ。ひとまずプラグイン記法でエスケープしておこう。
有望なライブラリはどれ？ (14:15)
現時点でPHP＋Ajaxなライブラリで一番有望なのはどれなんだろう？ なんかいろいろ見かけたけど、結局どれ一つとしてまともに使っていないんで、今から自分で判断するのは辛いなー。ひとまず、
あたりをながめてみるか。
初スポクラ (14:23)
台風が来ているっつーのに、午前中に初スポクラに行ってきた。
しばらくの間、基本メニューは
- ウォーキング 10分
- ストレッチ
- マシン適当（背筋と肩を中心）
- バイクかジョギング 20分
といった感じでいこう。できれば1時間以内で一通り終わらせたいところだけど、1時間半くらいかかっちゃいそうだな。
初めてなんでマシンをいろいろ試していたら、思ったよりも筋肉が疲れてしまった。午前中から疲れ切っても困るから、マシンの負荷は軽めにすることにしよう。
あと、週2くらいのペースで行こうかと思っていたんだけど、思ったよりも疲れずに済みそうだから、これだったらできるだけ毎日行った方が良さそうな感じ。