これまで仮想化環境として VMware Server を使っていたんだけど、 PC を Windows7 + Core i3 へと新しくしたついでに Player へと移行した。 以前の Player はその名のとおりに再生専用（仮想イメージは事前に用意されたものを使う前提）で、自分で仮想環境を構築することができなかった。 その頃 (2006年の夏) は、QEMU と VMware の組み合わせで仮想環境を構築していたんだけど、 VMware Server が無償提供されるようになってからは仮想環境の管理が楽な Server を使い続けてきた。

でも、昨年の秋に公開された最新のバージョン3では Player でも仮想環境を簡単に作ることができるようになっていた。

これが起動画面。メニューに「新規仮想マシンの作成」という項目がある。

VMware Server と同じように、仮想マシンの設定は GUI で可能。 QEMU と併用していた頃は設定ファイルをエディタで書き換えていたなぁ…。

と、これだけだと Server と変わらないんだけど、驚いたのは OS をインストールしようとしたとき。 まずは Ubuntu でも入れてみるか、と iso イメージを選択したら、以下の画面が表示された。 画面の下のほうに、こんなメッセージが表示されている。

Ubuntu Server 9.10が検出されました。この OS は簡易インストールを使用します。

「次へ」をクリックすると、 Ubuntu に設定するユーザ名とパスワードの入力画面が表示される。 （Windowsの場合は、ライセンス番号の入力も要求される）

この後、ホストOS上での仮想環境のインストール先ディレクトリと、作成する仮想ディスクの容量を指定すると、もうインストールが開始される。 キーボードやロケールなどの面倒な設定は不要で、「こんなに簡単？」ってほどアッサリにインストールが終了する。

• VMwareシリーズの最新版が公開、無償の「VMware Player」に仮想PC作成機能が追加

スナップショットがないなど、一部の機能に制約があるけど、気軽に使うには便利だよなぁ。

5年前に組み立てたPCのレシートが出てきたので、昨日組み立てたPCとの新旧比較をやってみる。

5年前のPCは少しお金をかけていたんだなと分かる。だからこそ、5年経ってもブルースクリーンが発生するまでは、特にストレス無く使えていたんだろう。

そして、新しいPCが前の1/3の値段で組めたのは、ケースとディスプレイを流用したことに加えて、各パーツの部品も安くなっているから。 特に、 Core i3 は 1万3千円でビデオカードも兼ねているのでコストパフォーマンスが高い。 明らかに悪い3D性能（2年前のMacBook Proと同等かそれ以下）を許容できるのならオススメの構成だなぁ。

Windows 7 でのエクスペリエンスインデックス

5年前のPCでの値はこちら。 メモリとHDD以外は3点台。 5年前としては健闘しているかな。

現PCでの値。 Core i3 でもここまでできる。 SSDにすることで、ディスクのパフォーマンスが上がってる。 グラフィック、3D性能はCPU内蔵のため、まぁこんな程度かな。

発端

5年前に組み立てたマシンが、ここ数ヶ月ブルースクリーンが多発するようになった。

いくつか対処してみたけど、状況は変わらず。

• Windowsの回復コンソールから、ブルースクリーン発生前のバージョンに戻しても変わらず。
• OS (Windows 7) を 64bit 版から 32bit 版に再インストールしても変わらず。
• BlueScreenViewを入れて原因を確認。
  • いずれもエラー原因は MEMORY_MANAGEMENT だった。
• HDDのスキャンディスクをしても異常なし。
• CrystalDiskInfo でも異常なし。
• Memtest86+でメモリをテストしても異常なし。

確証はないけど、マザーボードの故障と推測。 性能的には全然不満を感じていなかったけど、もう5年も使い続けてきたし、思い切って買い換えることにした。

基本方針

• 基本的にはネットとメール。それから写真と音楽 (iTunes) の管理。ゲームはやらない。
• もしかしたらそのうち簡単な動画編集をやるかも。

PC でテレビを見ることもないし、メーカー系の PC は検討の対象外。 BTO で安い PC を買ってもよかったんだけど、今の PC のパーツを流用したかったので、必要最小限のパーツだけを交換することにした。 それに、こんなときじゃないとハードウェアについて勉強することもないしね。

マザーボード＆CPU選び

交換するパーツはマザーボード、CPU、メモリの3つ。ケース、電源、 HDD は流用したい。 電源が450Wしかないし、リビングに置くことを考えるとできれば静かにしたい。 一方で、せっかく買い換えるなら長く使えるようにしたい。

ちょっと調べてみたら、ちょうどグラフィック機能 (GPU) 内蔵の新しい Core i3 / i5 (Clarkdale) が発売されたばかりということが分かった。

• CPU に GPU を内蔵しているので、グラフィックカードが不要で省電力になりそう
• ただしマザーボードが対応している必要あり (H55チップセット)
• 対応マザーボードが安い（1万円台前半〜）
• LGA1156ソケットなので長く使える（といいな）

秋葉原のお店で H55 チップセット搭載のマザーボードをいくつか比較して、Gigabyte 社の GA-H55-UD3H にした。 CPU は Core i3 か i5 かで迷ったけど、価格差ほどの違いは感じないだろうと判断して、一番安い i3 にした。 マザーボードが1万円。CPUは1万3千円。

メモリ

特に悩むことなく、リテール品の DDR3 メモリを 2GB x 2 で購入。これも1万円くらい。 マザーボードにはメモリスロットが4つ搭載されているので、将来的にメモリを増設することで8GB〜12GBくらいまで拡張可能。

SSD

これは必須じゃなかったんだけど、 CPU とマザーボードで費用を抑えられたこともあり、SSDを買うことにした。 システムドライブに入れることで PC を静かにしたい狙い。 容量はそれほど必要ないので、一番安い Intel の X25-V Value SATA SSD にした。 40GB で 1万3千円くらい。

マザーボード, CPU, メモリ, SSD で合計で4万6千円。大切に使おう。

組み立て

古い PC からマザーボードを取り外し、中にたまった埃を掃除してから、新しいパーツに入れ替えていった。 見た目は変わらないのに、中身が変わっている不思議。

さすがに同じパーツはマウスとキーボードくらいしか残ってないので、電話での Windows 7 の再アクティベーションを要求された。 いろいろ聞かれるかと思ったけど、特に理由を聞かれることもなく終了。

PC は確かに速くなったんだろうけど、それよりも感動したのが SSD にしたことでの静けさ。 これまでのガリガリ音が無くなって、本当にPCが起動してるのかな？って思うほど。 1万3千円でこの効果は、満足度が高いな〜。

この日記はCPIのVPSサーバというサービスで動かしているんだけど、どうもサーバのリソース制限（メモリ）に引っかかっていてレスポンスが悪くなっている。 monit を使ってサービス監視していて、リソース制限に引っかかってサーバプロセスが落ちた場合でも自動的に再起動しているんだけど、アラートが頻発している状態が続いている。

なので、仮に CPI の VPS サーバから、以前設置していたさくらのレンタルサーバに戻してみた。 （CPI から mod_proxy を使ってさくら側に転送している）

サーバの応答時間

• CPI の VPS サーバ … 8852 msec
• さくらインターネット … 2622 msec

応答時間はかなり早くなったんだけど、今度は503エラーが発生するようになった。 CPUに負荷がかかっているんだろうか。

今の状況

• CPI の VPS サーバ（一番安いプラン） … メモリ不足が発生。
• さくらインターネット（スタンダード） … CPU制限が発生。

VPSサーバのメモリは180MBなんだけど、近いうちに倍に増強されるみたい。 早く安定させたいところだけど、メモリが増強されるまで様子を見るしかないかな。

追記

tDiary を 2.3.3.20090826 から svn の最新版に追従して、 ruby 1.9 をp0からp378に入れ替えたら、CPIでも応答時間が 8852 msec から 1231 msec へと劇的に改善された。 追従前後のプロファイル結果は以下の通り。

  %   cumulative   self              self     total                                                                     
 time   seconds   seconds    calls  ms/call  ms/call  name                                                              
 51.59    10.86     10.86   191735     0.06     0.08  Proc#call                                                         
 17.81    14.61      3.75        4   937.50  4812.50  Marshal.load                                                      
  8.79    16.46      1.85   191799     0.01     0.01  Kernel.respond_to?                                                
  7.13    17.96      1.50   127837     0.01     0.01  String#encoding                                                   
  5.56    19.13      1.17        3   390.00   390.00  Thread#join                                                       
  3.42    19.85      0.72   127866     0.01     0.01  BasicObject#==                                                    
  2.71    20.42      0.57    63934     0.01     0.01  String#force_encoding                                             

 %   cumulative   self              self     total                                                                     
 time   seconds   seconds    calls  ms/call  ms/call  name                                                              
 19.48     0.30      0.30        3   100.00   100.00  Thread#join                                                       
 19.48     0.60      0.30        7    42.86    80.00  ERB::Compiler::SimpleScanner2#scan                                
 18.18     0.88      0.28      212     1.32     5.38  Kernel.require                                                    
  3.25     0.93      0.05      440     0.11     0.11  ERB::Compiler#content_dump                                        
  3.25     0.98      0.05      132     0.38     3.71  Array#each                                                        
  3.25     1.03      0.05      107     0.47     2.80  BasicObject#instance_eval                                         
  2.60     1.07      0.04      933     0.04     0.04  Fixnum#>                                                          

ううん…。 Rubyが古かったのが原因なのか、tDiaryが古かったのが原因なのか、その両方なのか。 でも、これで安定するといいなぁ。

リソース制限内に収まるようになったので、さくらに戻すのはやめて、CPIで引き続き動かすことにした。

追記

プロファイルの結果を見ていると、改善前はProc#call, Kernel.respond_to?, String#encodingが20万回 (!) も呼ばれている。 昔からこうだったとは考えにくいので、 tDiary や Ruby のバージョンじゃなくて変に大量のデータがたまっていたのかもしれない。

年末に新宿の伊勢丹へ出かけたついでに、ちょっと奮発して美味しいスイーツ（笑）を買ってきた。 伊勢丹の地下にあるJEAN-PAUL HEVINという名前の、チョコレートがメインのお店。 隣には「飲むチョコレート」を楽しめるカフェも併設されている。

パッケージもチョコレート色。 青いラインがワンポイントになってる。

箱を開けるとケーキが2つ。 直前まで冷蔵庫で冷やしていても、表面のチョコレートはもう溶け出しているくらい柔らかい。

それでもなんとか形を崩さずに箱から取り出す。 手前がドウジャで奥がカラカスというケーキ。 どっちもかなり濃厚な味。 ちなみに2つのケーキを6人で分けて食べた。1人あたり1/3しかないけど、予想どおりこれだけでちょうどいいと思えるほどの濃厚さだった。

もう一つの箱にはマカロンが。ほとんど同じ色に見えるけど、実はぜんぶ違う味。 こっちも美味しかった。

というわけで、今年最後の贅沢だった。 ごちそうさまでした。

週間予報にでてくる温度のマークが、顔文字に見えてしかたない。

左側の（℃）の部分、ね。天気にビックリしているみたい。

M-1も終わっていよいよ年末が近づいてきた。 そろそろ年賀状の季節。 だいたい毎年はプリントサービスを使っていたんだけど、今年はマックを使ってみることにした。

最初に思いつくのは iPhoto を使うことだけど、文字を自由に入れられないので年賀状には不向き。 カレンダーなんかは簡単にできるのにね。 筆まめみたいなソフトを買うのもなんだかなーと悩んだ末に、 Keynote を使えないかと思いついた。

「keynote 年賀状」で検索してもほとんど事例がでてこないので不安だったけど、やってみたら意外と簡単かつキレイに作れたよ。

マックと Keynote で年賀状を作るメリット

• 高価なソフトを買わなくていい（iWork をすでに持っている場合）
• 影や写真のデコレーションが簡単かつキレイ！
• 写真や文字の配置が直感的に操作できる
• ヒラギノフォントが使える

Windows の場合は PowerPoint 2007 を使ってもいいと思う。 PowerPoint だとワードアートも使えるしね。 ただ、2007より前のバージョンだと、影やデコレーションがちょっと面倒。 僕は2007を持っていないので、今回は Keynote にした。

以下は Keynote で年賀状を作る手順。 使っている Keynote は1つ前のバージョン ('08) なので、最新版だと使い方が変わっているかも。

スライドサイズをハガキの大きさに合わせる

Keynote を起動した直後は、スライドのサイズがディスプレイと同じ比率になってるので、まずはハガキサイズに合わせて変更する。 メニューを探してもスライドのサイズ設定が見つからないなーと思っていたら、ツールバーの「インスペクタ」→「書類」→「スライドのサイズ」→「カスタムのスライドサイズ」で設定できた。

はがき年賀状ハガキのピクセルサイズを参考にしてサイズを決定。

ハガキ用紙サイズは、mmでいうと「100×148」。基本（200dpi）で、「幅787×高さ1165」ピクセル。 通常のイラストレータ−ツールなどで年賀状などの絵を描く場合もこれでいけると思う。

ちなみに300dpiだと1181×1748。 400dpiでは1575×2331となる。

僕は200dpiでの 1165 x 787 ピクセルに設定した。

全体的なレイアウトを決める

年賀状の場合、おおむねロゴ、写真、挨拶文、住所・名前から構成されるので、これらをどういう風に配置するのかをイメージする。 といっても、僕はデザインには自信がないので、ネット上のサンプルを参考にした。 参考にする場合は、なるべくシンプルなデザインのものを選ぶのがポイント。

ロゴの素材を探す

シンプルなデザインでも、ワンポイントで絵柄（ロゴ）が入っていると引き締まるので、使えそうな素材をネットで探す。 僕は @nifty の年賀状サイトに公開されていた無料年賀状素材を使わせてもらった。 ちなみに、このサイトにはロゴだけじゃなくて年賀状のデザインも置いてある（有料のものが多いけど）。 レイアウトを考えるのが面倒な場合は、デザインごとダウンロードして、Keynoteの背景に貼り付けちゃうと楽だと思う。

挨拶文を入れる

Keynote上にテキストで挨拶文を入れていく。 フォントは「ヒラギノ丸ゴ Pro」を選択した。 Keynote だとテキストに縁取りできないのが残念だけど、影を使うことである程度は代用できる。 この場合は、文字色を白に設定し、影のオフセットを0px, ぼかしを1pxにすればOK。

写真を貼り付ける

ここが一番楽しいところ。 写真を Keynote 上に貼り付け、レイアウトしていく。

ここでのポイントは、「マスク」機能を使うこと。 貼り付けた写真を選択して、メニューの「フォーマット」→「マスク」を選択する。 すると、写真の一部だけを切り取った形で、年賀状に貼り付けられる。 画面上は切り取られているように見えるけど、実際には写真全体のデータが残っているので、あとからでも自由に写真の切り取り部分を変えることができる。

ツールバーの「インスペクタ」から、「グラフィック」→「線」→「飾り枠」を選ぶと、写真の枠を選ぶことができる。 自動で影も付くし、オシャレな枠が多いが嬉しい。 さらに「インスペクタ」→「位置と回転」を使えば、写真を斜めに配置できる。

写真を丸く切り取りたい場合は、「図形でマスク」機能を使う。 メニューの「フォーマット」→「図形でマスク」→「楕円」を選ぶと、写真を楕円形に切り取ることができる。 他にも星や吹き出しなど、いくつかの図形が選べる。 右下の風太くんも、楕円形でマスクして配置している。

PNG形式でエクスポートする

僕の場合はプリンタが Windows 機にしか繋がっていないので、 PDF でエクスポートして Windows 機に持っていった。 写真屋さんでプリントしてもらうなら、 JPEG で出力してもいい。

印刷する

最後にプリンタのフチなし印刷で、年賀状を印刷する。 ちなみに、フチなし印刷の場合は多少4隅が切り取られるので、データ作成時には4隅にマージンを持たせておくことが大切。

終わりに

手持ちのKeynoteだけで簡単に作れたので満足。 参考までにKeynote で作ったテンプレートを置いておくよ。

TV を付けたらちょうど国際千葉駅伝が始まるところだったので、せっかくなので観に行ってきた。 沿道には応援の人が結構集まっていて、あわせて大会のスタッフさんがパイロンを並べたりと準備をしていた。 交通規制を告げるパトカーが通過して数分後に、先導のパトカーとフジテレビの中継車が遠くから見えてくる。 あの中継車に竹下アナが乗っているんだなーとか、考えてた。

先頭は日本の竹沢選手。後続が見えなくなるほどの力強い走りだった。

2位争いは学生選抜とオーストラリア。

しかし、生で見るとその速さに驚く。 このペースで10kmも走るんだから、すごいよなぁ。

最近、Twitterで ow.ly というドメインの URL 短縮サービスをよく見かけるようになった。 このサービス、 tinyurl のような従来型のサービスとは大きな違いがある。 これまでの URL 短縮サービスは、本当の URL (以下、実URLと呼ぶ) へリダイレクトするだけだった。 一方で ow.ly は、画面の上部に独自のツールバー (Ow.ly Social Bar 2.0) が表示される。 実URLは、 ow.ly ドメイン上のフレーム内に描画されている。

面白いサービスだと思うけど、この仕組みはセキュリティ的にはちょっと危険。 悪用されると、フィッシングの被害を受けてしまう恐れがある。

ow.ly では実URLのアドレスが表示されない

ow.ly のリンクをたどると、アドレスバーには実URLのアドレスではなく、 ow.ly のアドレスが表示される。 そのため、フレーム内に表示されているページが、本当に正しいページであることを確認できない。 例えば、以下の画面。一見するとはてなのログイン画面だけど、アドレスバーのドメインは ow.ly になっている。 偽の「はてなログイン画面」へ誘導されていたとしても、この状態からは見分けがつかない。

これに気がついたのは、 Twitter で勉強会の案内として ATND へのリンク (ow.lyの短縮URL) が貼られたいたから。 ATND にログインしようとして、アドレスバーのドメインが ow.ly のままだったので、慌てて ID とパスワードの入力を止めた（ATNDはOpenIDでログインするため、はてなのログイン画面が表示されていた）。 もし偽サイトだったら、簡単に ID とパスワードが盗まれていた所だった。

問題点

最大の問題は、フレーム内に別ドメインのページを表示していること。 このため、セキュリティの基本である「アドレスバーのドメインを確認する」ことができない。

ただ、これを否定すると ow.ly のサービス自体を否定することになっちゃう。 だからせめて、 ow.ly のソーシャルバー上に、実URLのドメインを表示するようにしてほしい。 （ただし、内側のフレーム内からソーシャルバー上のドメインを書き換えられる危険性があるので、完全な対策じゃない）

対策1: ow.ly のソーシャルバーを閉じる

ow.ly のソーシャルバーは、右上に「×」ボタンがある。 これをクリックするとソーシャルバーが消え、フレーム内の実URLが直接表示されるようになる。ログイン画面など、重要な情報を入力する画面では、必ずソーシャルバーを閉じてアドレスを確認するほうがいい。

ソーシャルバーなんて表示されなくていい！という人（僕）のために、自動的にソーシャルバーを閉じる GreaseMonkey スクリプトを書いた。

Hide Ow.ly Social Bar

このグリモンをインストールすると、 ow.ly の短縮URLにアクセスしたときに、自動的に実URLへとリダイレクトするようになる。

対策2: ソーシャルバー上に実URLを表示する

ow.ly のソーシャルバーは使いたいという人向けに、ソーシャルバー上に実URLを表示するグリモンを書いた。

Show URL on Ow.ly Social Bar

このグリモンをインストールすると、 Ow.ly のソーシャルバー上に、フレーム内の実URLが表示される。 ただし、さっき完全な対策じゃないと書いたように、フレーム内からソーシャルバーの文字を上書きできる危険性もあるので、あくまでも参考までに使うこと。 本当に重要な情報を入力するときには、右上の「×」ボタンでソーシャルバーを閉じてからの方がいい。

まとめ

フレームを使ったサイトはフィッシングの危険があるとは、かなり前から言われていること。 それでも、いまだにこういうサービスが受け入れられているのは少し驚きだった。 フレームを否定する気はなくて、使いたいなら危険性を理解しながら注意して使えばいいと思う。 このページがそのためのお手伝いになれば幸い。

久しぶりに iTunes でアルバムを物色していたら、試聴ページから Twitter につぶやくためのメニューが用意されていることに気がついた。 ちょっと分かりにくいけど、「購入する」ボタンの右にある「▼」ボタンをクリックすると、「Twitterで共有」というメニューが表示される。

「Twitterで共有」を選択すると、（Macの場合は）Safariが起動して Twitter のページが表示される。 つぶやき欄には、以下のようにアーティスト名、曲名、iTunes へのリンクと #iTunes ハッシュタグが入っている。 ちゃんとハッシュタグが入っているところがニクい。

アトリエ・ボッサ・コンシャス - WINTER SONG - http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewAlbum?i=334822535&id=334822233&s=143462 #iTunes

これで、気になっている曲を簡単に Twitter でつぶやくことができる。 ここまでくると、本当に何でも Twitter へという流れを実感するなぁ。

曲へのリンクを Firefox でクリックすると、「アプリケーションの起動」ダイアログが表示される。 ここで iTunes を選ぶと、 iTunes が起動して先ほどの曲の画面が表示されるという仕組み。

ちなみに、購入したのは「冬ボッサ」というアルバム。 冬っぽく透明感のある曲が10曲入って、600円というお買い得価格。 カバーなので、ほとんど知っている曲ばかりなのも嬉しい。 iTunes のランキングで1位なのも納得できるなぁ。

CD はちょうど4日発売。 こちらは2,100円なので、モノにこだわらないのであれば iTunes のほうがお買い得。

発売日から少し時間が経ったけど、ようやく Wii Fit Plus を購入した。

しばらく購入を見送っていたのは、新しく追加されたトレーニングの数が少なく、あまり魅力を感じなかったから。 それでもようやく購入したのは、毎日の計測でのウィーボ君の言葉に飽きてきたから。 値段も1,700円と安いので、そんな軽い気持ちで購入したんだけど、思った以上に良くできているソフトだった。

前作からの引き継ぎユーザへの配慮

ソフトを起動すると、前作のデータを自動的に引き継いでくれる。 まぁ、ここまでは普通なんだけど、さらにデータを引き継いだ場合には、ウィーボ君が前作のユーザ向けに新機能を親切に解説してくれる。 メニュー画面では、アニメーションで新しく追加されたボタンが表示されるので、いつの間にか知らないボタンが増えてる！なんてことにならない。 よくあるチュートリアルと同じと言えば同じなんだけど、バージョンアップのためにここまで丁寧に作り込むのは、ちゃんと使う人のことを考えてる証拠。

毎日ちゃんと続けられるための工夫

無印 Wii Fit での大きな不満は、体重の測定に時間がかかることだった。 体重を記録したいだけなのに、毎回ウィーボ君に健康マメ知識を勧められ、服装を選択し、測定。 そして、重心の測定結果が発表され、その後にようやくBMI/体重の発表。最後にはバランス年齢の測定を勧められる。 時間のあるときならいいけど、毎日続けようとするとこの手間が面倒になってくる。 Plus では、この問題もちゃんと解決されていた。

あまり宣伝されていないけど、 Wii Fit Plus ではかんたん測定モードが追加されている。 これは、からだ測定のスピーディ版で、測定に本当に必要な手順だけを実施するもの。 メニューからかんたん測定を選択すると、いきなり測定。 次の画面で重心とBMIの測定結果がまとめて表示される。 感覚的には1/3くらいの時間で測定できるようになった。

毎日ちょっとした時間に続けようと思ったら、この手間の差は大きいものになってくる。 個人的にはかんたん測定だけでも、2,000円分の価値はあったように思う。

さらに、まだ試していないけど、1日の切り替え時間を従来の0時だけでなく3時からも選べるようになったらしい。 これまでは帰宅が遅くなって測定できなかった日もあったけど、これからは時間を気にせずに安心して測定できる。 他にも、マイメニューの追加により、毎回トレーニングメニューを自分で選ばなくて良くなっている。 このように、毎日続けられることを考えて、しっかり改良されている。

欲張りすぎないバージョンアップ

追加トレーニングの数が少ないことから、最初は値段に見合わないバージョンアップだと思ってた。 でも、ちゃんと毎日続けられることを考えての改良が入っていることを知って、考えを改めなおした。

普通、こういうバージョンアップの時は、売りやすいようにカタログスペックを意識してしまうことが多い。 その結果として「○○種類ものトレーニング追加」といった数に走りがちになる(GTが車種数を誇っていたように)。 でも、 Wii Fit Plus は、売りやすさを目的とした数に走るのではなく、長く使ってもらえることを目的として質の向上に力を注いでいる。 使う人のことを考えると当たり前のことなんだけど、簡単にできることじゃないよなぁ。

昨日の日記で、メソッドの呼び出し元をログに出力する方法について書いた。 それは、メソッド内で意図的に例外を発生させ、例外オブジェクトのスタックトレースから呼び出し元を知るというもの。 そうしたら、caller メソッドを使ってスタックトレースが取得できるツッコミをいただいた。 caller メソッドは知らなかったので、両者を比較してみた。

例外オブジェクトからスタックトレースを得る方法（昨日の日記より）

def some_method
  begin
    raise Exception.new
  rescue Exception => e
    STDERR.puts e.backtrace.join(", ")
  end

  # ここから関数本体
end

caller メソッドでスタックトレースを得る方法（ツッコミでのご指摘）

def some_method
  STDERR.puts caller

  # ここから関数本体
end

まとめ

どうみても caller メソッドの方がシンプル。 これだけで終わっては面白くないので、 caller の戻り値を調べてみた。 戻り値は文字列の配列で、文字列はスタックトレースと同じ形式 (ファイル名:行番号:メソッド名) になってた。

$ irb
irb(main):001:0> c = caller
=> ["/opt/local/lib/ruby/1.8/irb/workspace.rb:52:in `irb_binding'", "/opt/local/lib/ruby/1.8/irb/workspace.rb:52"]
irb(main):002:0> c.class
=> Array    # caller の戻り値は文字列の配列
irb(main):003:0> c.first.class
=> String
irb(main):004:0> puts c  # 文字列はスタックトレースと同じ形式 (ファイル名:行番号:メソッド名)
/opt/local/lib/ruby/1.8/irb/workspace.rb:52:in `irb_binding'
/opt/local/lib/ruby/1.8/irb/workspace.rb:52
=> nil

ちょっとした小ネタ。 Ruby スクリプトをデバッグするときに、あるメソッドがどこから呼び出されたのかを知りたいときがある。 普通ならデバッガとブレークポイントを使えばいいんだろうけど、 CGI で動作するスクリプトなどでデバッガが使えないときもある。

そんなときは、メソッド内で意図的に例外を発生させ、即座に例外をキャッチすればいい。 キャッチした例外オブジェクトの backtrace メソッドを呼び出せば、メソッドの呼び出し元を調べることができる。

def some_method
  begin
    raise Exception.new
  rescue Exception => e
    STDERR.puts e.backtrace.join(", ")
  end

  # ここから関数本体
end

このサンプルは CGI を想定しているので、標準エラー出力にスタックトレースを書き出している（Apache HTTP サーバの場合は、 error_log で読むことができる）。 ちなみに、改行ではなくカンマで連結しているのは、余計なデータが付与されるのを防ぐため。 改行で連結すると、スタックトレースの一行ごとに、 error_log の整形情報（日付、ログレベル、リファラ）が付与されてしまう。

キャッシュにputするデータが小さいという指摘をいただいた。 確かに数バイトでは少なかったかも…と思い、 tDiary キャッシュサイズを参考にして、 8KB のデータを put するようにした。

データサイズ8KBでのベンチマーク結果

データ数 = 10

データ数 = 100

データ数 = 1000

考察

1つのファイルに全キャッシュを格納する PStoreAdapter は、明らかに落ち込みが激しい。 データサイズを8KBにすると処理時間が10倍になった。 さらにデータ数に応じて計算量がO(n)で増加するので、大量のデータを1つの PStore ファイルのは望ましくない。

PStoreAdapter2 と MemCacheAdapter はデータサイズの増大で処理時間は2〜3倍に増加しているけど、データ数に関わらずに計算量は O(1) 。 ツッコミで指摘をいただいているけど、 tDiary くらいの規模のアプリケーションであれば、ファイル数の増加とメモリの消費のどちらを選ぶかで選択してもいいかも。

tDiary のプラグインを作っていると、ローカルにキャッシュを保存することがよくある。 flickr プラグインが取得した XML の写真情報だったり、プロフィールプラグインが取得したプロフィールデータだったり。 今は、 PStore を使って保存しているけど、 Memcached を使ったらどうなるかと思って比較してみた。

比較対象

• 1ファイルに全てのデータを保存する PStore (ファイル数 = 1) → PStoreAdapter
• 1ファイルに1データを保存する PStore (ファイル数 = データ数) → PStoreAdapter2
• Memcached → MemcacheAdapter

ベンチマーク環境

Rubyで書いた。gistにて公開。 データ数を10, 100, 1000と増やし、それぞれの書き込み時間と読み込み時間を計測した。

• Intel Core 2 Duo 2.2 GHz, 4GB memory
• Mac OS X 10.6.1

ベンチマーク結果

「full」ボタンを押すと全画面表示される。 上からデータ数10, 100, 1000での時間。ループ回数は10000回。

分かったこと

• PStoreで1ファイルにデータを詰め込むとスケールしない。
• PStoreで1ファイル1データとするとスケールする。
• PStoreとMemcachedの時間は同じくらい。
  • PStoreは、おそらくディスクのキャッシュが効いているから。ディスクIOが発生すると遅くなるのでは。

感想

tDiary のキャッシュを memcached に載せると速くなるかもと期待したけど、そう甘くはないかも。