Smartyのエスケープ (15:07)
「[PHP] Smartyとサニタイズ」で、なんかデジャブのような展開を見かけたんで、結局俺はどう対処することにしたのかを書いておく。なんか不便なことが多すぎるんで、default_modifiersを使うのはあきらめ、modifier.h.phpという以下の内容のプラグインを追加して、それでエスケープするようにしている。
function smarty_modifier_h($string)
{
return htmlspecialchars($string);
}
このプラグインを用意しておけば、{$foo|escape}を{$foo|h}と書ける。このくらいならばそんなに面倒じゃないから、書き忘れも減るんじゃなかろうか。modifier.h.phpの内容はもともとのescapeをコピーして使ってもいいけど、実用上はこれで十分。シングルクォーテーションもエスケープしたい人は、ENT_QUOTESをつけておけばいい。
今日のスポクラ (14:54)
マシンの負荷＋回数をちょっとずつ増やし中。今までは後に残らないように標準負荷設定×10回×1〜2セット（持ち手が2パターンあるマシンは両方やる）でやっていたんだけど、それだと楽すぎるものは負荷を＋1するか、回数を20回に増やすかしてみた。でもやっぱりそうすると結構後まで残るなー。筋肉の量ではなく速度が欲しい場合は、負荷軽めで回数を多くした方がいいんだっけ？ バイクは100W20分。本を読みながらやると時間が経つのが早いな。今までは考え事時間にしていたんだけど、バイクをこぎながらだといまいち脳みその回りがよくないから、本を読んで時間をつぶした方がよさげ。
記事の関係性ではなく、人間関係を表現するためのサイトトラックバック (09:13)
トラックバックは、記事間の言及関係を表現するために作られたものだ。いわゆる議論的な文章の関係性を表したい場合は、それで十分だとは思うが、実際にWebサイトを運営していると、議論的な関係性だけではなく、単なる人間関係を表現したい場合も多い。
つまり、ある人の特定の記事に対して言及するのではなく、単にある人に対して言及していることを表現したいことがよくある。テキストサイト系でいうところのなれ合いリンク、はてなダイアリーで言うところのreferred的なものだ*1。
しかしよく考えてみると、実際にトラックバックという規格を使って、人間関係を表現することは簡単だ。現状では記事単位でしか用意されていないトラックバックping URL（受信用URL）に追加して、Webサイト全体（＝Webサイト運営者）に対応するトラックバックping URLを用意すればいい。そこに送られたトラックバックは、特定の記事に対する言及ではなく、そのWebサイト（＝Web運営者）に対する言及として扱う。
トラックバックping URLは多くの場合、
http://example.com/blog/trackback/[entry id]
のような形式をしているが、[entry id]としてサイト全体を表すIDを新しく振るだけで、たいていのシステムでは対応できるだろう。わかりやすさでいえば、[entry id]が空の場合はサイト自体への言及として扱うといいかもしれない。
trackback auto-discoveryへの対応も、特に何ということはなく、Webサイト（blog）のトップページに、各エントリーに埋め込んであるRDFと同様のものを（トップページに関する情報として）埋め込んでおけばそれでいい。トラックバックping URLの人間向けの表示は、タイトル部にでもそれなりのスペースを確保するのが現実的だろう。
技術的には何も難しいところはない。送信側は、基本的なトラックバック送信機能さえ持っていれば、特に新しい仕組みを用意する必要はない。受信側は上記のようなちょっとした工夫程度の機能拡張で対応ができる。それだけで、記事単位ではなくサイト単位での関係性を簡単に表現できる。
ひとまずこのような機能を「サイトトラックバック」と名づけてみたが、いろいろなblogツールで対応すると、記事単位でのコミュニケーションよりも、サイト同士のコミュニケーションの方を好むコミュニティにおいては、便利に活用されるようになるのではないか。ひとまず今自分で作っているblogツールには上記のような機能を搭載する予定。
*1 はてなダイアリーではそのような言及通知機能のことを「idトラックバック」のように呼んだりしているが、実際にはトラックバックという規格とは関係のない、独自の言及通知機能だ
ハードウエア故障？ (17:56)
昨日負荷を分散した先のサーバーが、ハードウエア故障らしい。まだ原因が不明なんだけど、ハードディスク以外の部分が怪しい挙動をしているとか。で、16:00過ぎくらいから1時間ほど死んでいた。再起動を何度かトライしたところ何とか立ち上がって、現在は正常に動いているみたいだけど。
依頼すればハードウエア交換（ハードディスク以外を交換）してくれるらしいけど、念のためバックアップとかを考えなければならないんで、ひとまずは現状で運用しつつ、また同じことが起こったら交換してもらうことにした。
っつーか最近サーバートラブルが多いのは、夏のせいかなー、それともアクセス増大のせいかなー。他のサーバーには特にトラブルが起きていないから、アクセス増大が主原因＋夏だからが副原因って感じだろうか。
ひとまずそういう状況なんで、分散した負荷を再び元のサーバーに戻して様子見中。早く夏が終わらないかなー。
今日のスポクラ (13:16)
家でストレッチとシャドーピッチング左右までやってからスポクラへ。あとはいつのもメニュー。バイクは100W20分にチャレンジしてみたところ、特になんということもなかった。脈拍も140回/分台前半を最後までキープしていたし。次は110Wにチャレンジしてみるべきか。
負荷分散 (21:37)
なんか最近アクセス数の増加が激しく（サーバー死亡前はデイリー10万hit（5万ページ）程度だったのに、現在50万hit（30万ページ）くらいになっている）、せっかく気合いの入ったスペックのサーバーに移動したのに、またも負荷的に辛くなってきたので、DB回りを負荷分散してみました。重い検索系を別サーバーにレプリケーションしたDBに回すようにして、メインDBの性能の安定化を図ってみたんだけど、これでいつまで持つかなー。またサーバー増やすのは嫌だなー。
「依頼」と「待機」によってToDoリストを整理する (13:49)
GTDでは、ToDoリストを整理するにあたって、その仕事は自分以外の誰かが処理をした方が適切であると判断できた場合は、その項目を適切な誰かに任せてしまうことになる。
当たり前と言えば当たり前だが、自分で仕事を完了させることだけが仕事をこなす手段なのではなく、自分以外の適切な誰かにその仕事を任せてしまうことも、仕事の処理方法の一つであることを、きちんと認識・区別して扱うことが重要なのだろう。
ただし、自分のToDoリストから発生した仕事に関しては、他人にそれを任せてしまってそれで終わりというわけではない。
たとえば、あるプログラムを作っていて、それで使うアイコン画像が必要になった場合、そのデザイン作業はデザイナーに任せることになる。しかし、それで自分の仕事は完了するのかというとそうではなく、その次には「できあがったアイコンをプログラムに組み込む」という自分の作業が待っている。
デザイン作業の完了を時間で特定できるのならば、次に自分が行うべき「アイコンをプログラムに組み込む」という項目を、時間軸で整理しておけばいい。しかし、人に任せた作業の完了時間を特定することは難しく、デザイナーからの作業完了報告（コールバック）を待って、次の作業にかかるといった進行が現実にはよくある。
また、そのように人に任せた仕事では、適切な期間内にコールバックが返ってこない可能性もあり、そのような場合はこちらから作業状況を確認するなどといった行動を取る必要が出てくる。
そこでGTDでは、自分以外の他人の行動によって、自分の仕事が動くような項目は、「待ち」という分類によってカバーする。そして、この「待ち」と分類された項目リストを、自分の仕事を管理するためのToDoリストと同様に定期的にチェックすることにより、他人に任せた仕事の進行状況をまとめて管理する。
本家GTDでは、この「依頼」と「待機」による処理や分類に関しては、以上のような概要の説明にとどまり、あまり具体的な話は語られていなかったように思う。しかし実際に仕事をする際には、「依頼」と「待機」という要素はかなり重要だ。特に複数人で協調して動くプロジェクト的な仕事を管理する際には、この「依頼」と「待機」こそが仕事管理の肝となる。
仕様が複雑になることを厭わないのならば、「依頼」と「待機」の管理のために、それとリンクさせて使うための「人」という情報を持たせるべきだろう。ただし、いわゆるプロジェクト管理ツールのように複数の「人」の視点で仕事を管理することができるようにする必要はなく、あくまでも「自分」が仕事を依頼した第三者としての「人」が管理できればそれでいい。
また、「依頼」や「待機」での分類に対しても、「時間」や「状況」での分類は有効だと思うが、その扱いは自分の仕事における「時間」や「状況」の分類とは多少違ったものにした方がわかりやすくなるような気がする。
私の理想の仕事管理ツールを作るにあたっては、この「依頼」や「待機」を具体的にどのような仕様で取り込むべきかという点において、まだまだ検討事項が多い。懲りすぎると使いにくくなることは分かっているので、シンプルさを保ちながらどれだけ有用な機能を実現できるかが鍵になるだろう。
今日のスポ (22:55)
スポクラには土日は行かないことにしているんだけど、シャドーピッチングくらいは家でやってもいいよなということで、左右100球ずつ。左は一時期右肘が痛かった頃には結構練習したんだけど、その後肘が治ってから全然やってなかったんで、肩の回転がものすごく不自然だ。でもまあ遅いストレートくらいは投げられる程度にやっておいた方が、体の左右のバランスが取れていい気がする。
DBが落ちていました (16:25)
DBサーバーがおそらく1時間ほど落ちていたようです。16時過ぎに気付き復旧（再起動）しました。原因は調査中です。というかログに何も残ってないなー。なんだろう？
今日のスポクラ (11:18)
で、まだ背筋痛は残っているんだけど、ここで休むとずるずる行きそうな気がしてきたんで、逆療法で行くことにした。ウォームアップとストレッチをジムでやるのは時間がもったいないんで、家でストレッチまでしてからスポクラへ。黙っていると背筋痛が結構きつかったんだけど、マシンをはじめたらそんなに気にならなくなった。で、最後にまたシャドーピッチング（今日は50回）をやったんだけど、軽めにやっているうちにずいぶん背筋もほぐれた気がする。で、最後のバイクは前半10分を90W、後半10分を100Wにチャレンジしたら、後半ちょっとだけ脈拍の警告（175回/分）を越えてしまった。10Wの違いって結構あるんだな。でもやっているうちに160回/分程度に落ち着いてきたんで、これも何日か続ければすぐに体が慣れるでしょう。