甘いもの、が食べられなくなってきた :o

今週は寒かったですね :s

朝起きるのも都下の会社に行くのも仕事をするのも家に帰るのも冷たい布団に入るのも嫌になります。寒いのは嫌です。一週間よく耐えたと自分をほめたくなります。

また先週から職場が変わり、異邦者としていわれのない差別を受けているという被害妄想を抱く一方、「あれ？まだ2週間しか経ってなかったっけ？もう随分前からいるような気がするよ」と、常駐組の仲間のように扱われるというギャップ。なかなか慣れないものですね。:(

そんなつらい一週間を乗り切るために、最近は甘いものに逃げています。とりわけ、夜遅くまで営業しているミスドはありがたいです(今週だけで3回行きました(L) )。

ちょっと前までミスドやマクドの、あの入ってすぐに「ご注文をどうぞ」と言われる感覚が、優柔不断で人見知りな私には合わなくて敬遠してきましたが、最近は慣れたもので(?)、堂々と買いに行けるようになりました。

平日の夜中は結構ドーナツが残っています。どれもおいしそうです。気がつくと箱いっぱい買っています。長い箱をぶら下げて家に帰り、夜食にのんびり食べようとテーブルの上に置いておきます。風呂から出てくると既に箱が空いていて2つ3つ家族に食べられています :'( コーヒーを入れ、いざ自分が食べる時、箱を開けたときの甘い香りに心踊らせ、1つを手に取り粛々と食べます。とても幸せです。この時点で夜1時ぐらいです。

しかし幸せは長くは続きません。ドーナツ2つ目が食べられないのです。おなかがいっぱいなのではなく、1つで満足してしまうのです。10個も買ったのに、1個しか食べられません。そして次の日に帰ってくる頃には、家族に全部食べられて残っていません。それを今週3回繰り返したわけです。

もともと甘いものを食べるスピードは人の何倍も遅かったのですが、最近はそれに益々磨きがかかってきました。先のドーナツ1個でも、10～30分かけて食べます。またコーヒーも必須です。この前食べた31アイスクリームも、カップ1個にえらい苦労しました(ちなみに31に入るの初めてでした :) )。

甘いものは大好きなのですが、たくさん食べられないということはつまり、ミスドのドーナツを全種類制覇するのに多くの時間とお金がかかるということです(家族に食べられるし)。なら1個だけ買えばいいじゃないか、と思うかもしれませんが、大の大人がドーナツ1個だけという買い方はできないのですよ。まー、のんびりやればいいんですよ。逆にそれだけ長い間楽しめると思えば。

決してこのことが、年齢によるものではないと信じています。:s

バス通勤でトラブル: ICカード化の落とし穴

最近通勤にバスを使うようになって、今までにまして通勤が憂うつになりました。勘弁してほしいです :'(

バスの支払いにはSuicaを使っています。バスは定期を買わない方が得なので(20日間ぐらい使う場合)、乗るたびにSuicaでタッチしています。財布に入れたView Suicaでタッチしています。

ところがどうにも反応が悪い。2回に1回ぐらいエラーになる。私のタッチの仕方が悪いのかと思い、慎重にタッチしてみたり、長めに静止してみたりしましたが、ダメでした。。。

この件で2週間ほど苦悩しましたが、やっと昨日原因がわかりました。バスの中にあるPASMOの注意書きを何気なく眺めているとき、「他のICカードと重ねないでください」の注意書きの下の「競合するICカード」一覧の中に原因がありました。

免許証

免許証！これか！確かに去年免許更新時にICカード化したぞ。View Suica(クレジットカード)と免許証が財布の中に入っているため、タッチ時に干渉していたみたいです。試しに免許証を抜いてみたらサクッと通るようになりました。

しかしクレジットカードも免許証も、財布の中に入れておくのが普通でしょう。干渉するから一緒に入れないで下さいって、ちょっとないですよ。。。今後ICカード化するものが増えていくことを考えると、今のうちにちゃんと規格を統一するなり読み取りの精度を上げるなりしてほしいものです。ICカード化したせいで逆に不便になったことのいい例じゃないでしょうか。

ちなみに、バスではNGだったView Suica + 免許証ですが、JRの改札では問題なく通過できます。この辺に運用の歴史の差が出るんですかね。というか、Suica 2枚でNGなら分かりますが、別のカードと干渉するという時点で、明らかに設計漏れでしょうね :s

• 警視庁: 運転免許証がICカード化されました

Google Chromeが速いわけ: スピード狂のあり方

@ITにGoogleのブラウザ「Chrome」に対する開発者のスピード狂ぶりを綴った記事が出ていました。

• Chromeはなぜ速いのか

この記事によると、Webサービスにおいては0.5秒遅いだけでユーザが離れていくそうです。その教訓から、Chromeには徹底したスピードへのこだわりを終結させており、その結果としてあの素晴らしいレスポンスが得られるようになったわけだそうです(私が使っているような低速なPCではそれほど激早というわけではないですが)。

個人的にはプロセス分離やドメイン先読みはやりすぎなような気がしますが、他のブラウザがやらない(できない)ことをしている、という点では面白いと思います。

開発者は皆、多かれ少なかれスピード狂です。私はそれほどスピード狂ではないですが、応答性を高めるためにスレッドを分けるとか、ファイルからのI/Oを極力減らすとか、データの先読みをする、という点は常に気をつけるようにしています。

一方でメモリ使用量も抑えるように色々考えています。スピードとメモリ使用量はトレードオフですからね。例えば10万パケット入っているキャプチャファイルに対して、全てのパケットの開始位置(uint)をリストにするだけで400KB必要です。タイムスタンプと発着IP/Portも一緒に保存したら3MBぐらい必要になります。

スピードのためにメモリを大量確保するのか、それともスピードを犠牲にしてメモリ使用量を抑えるのか、もしくは両方とも折り合いのつく着地点を探るのか、開発者はいつでも葛藤しています。Googleの中の人は相当苦労したと思います。それともノウハウたくさん持っているからそれほど苦労せずに見通しが立つのでしょうかね。うらやましい。。。

[WireWhale]激早!! FileStreamのPosition、Length→自前で保持

今までキャプチャファイルの読み込みはFileStreamからPositionプロパティを使ってせっせと読み出し、Lengthプロパティの位置まで来たら止める、という方法をとってきました。これだと50MBのキャプチャファイルを読み出すのに大体10秒ぐらいかかっていました。

Wireshark(というかcapinfo.exe)でキャプチャ情報を読み出すのも大体それぐらいかかっているので、それが普通かなと思っていました。が1ファイル開くのに10秒も待っていられない! 何とかならないものかと試行錯誤していました。

そんな中、CodeProjectにFast Binary File Reading with C#という、ストリームの読み込みの手法毎の性能比較の記事があったの でWireWhaleもチューニングしてみました。具体的には、Position、Lengthプロパティの使用を極力減らし、値は変数で保持、Positionを移動するときはSeekを使うようにしてみました。

結果、、、びっくり!!! 何と50MBのキャプチャを開くのに5秒かからなくなりました!!! プロパティ内で何してるんでしょうね!?

やっぱりこういう細かい調整が性能を大きく左右するんですね。とても参考になりました。

参考

Fast Binary File Reading with C#

Web2.0(Ajax)時代の標準文字コードはUTF-8？

今から3年ぐらい前、Web2.0なんて言葉が出始め、Ajaxはまさに黎明期、Google Mapsとかにみんな驚き、JavaScriptが威厳を取り戻しつつあった時代がありました(そんなに昔の話じゃないですよ。3年前の話ですよ)。私もご多分にもれずそれに感化され、卒研では意味もなくXHTML+JavaScript+PHPをAjaxでつないでいました。

その頃は若かった(?)ため、HTMLに当たり前のようにUTF-8を使い、サーバとのやり取りもすべてUTF-8で行っていました。若い時は「XMLはUTF-8がいい」なんて聞いたら、それ以外を使うのはすべて悪であるかのような錯覚をしていたので、特に違和感もありませんでした。

しかしそれから3年が過ぎ、ふと別件でAjaxについて(今更)調べる中で「decodeURIComponentはUTF-8しかデコードできない」という事実を知り驚きました。それってつまり、HTMLもUTF-8にしなきゃならないってこと?

と思ったら、なぜかデコード後の文字列は、HTML自体がShift_JISの場合はShift_JISになる！ どういうこと？

そもそもdecodeURIComponentにUTF-8以外の文字列をエンコードした文字列を渡すと、「error: malformed URI sequence」になってしまいます。UTF-8以外はデコードできないからですね。それを回避するためにサーバはresponseTextに常にUTF-8文字列が返るように実装しなければなりません。イマドキそんな制限ないっすよ～

decodeURIComponentはRFC2396に準拠しているんですってね。そこにUTF-8以外は認めないとか書いてあるんでしょうか。そのうち勉強します。

• RFC2396 - Uniform Resource Identifiers (URI): Generic Syntax
• RFC3986 Uniform Resource Identifier (URI): 一般的構文

CDに対する愛着の薄れ

大塚愛さんの「Love Letter」を購入しました。大塚さんのステキな笑顔のアップというインパクトのあるジャケットです。グッときます。ドキッとします。:*)

思えば昔はCDを1枚買うごとに、CDプレーヤで再生しつつ歌詞カードをじっと眺め、1曲1曲をかみしめながら目と耳で楽しんでいました。もっと言えば、ジャケットの絵や写真だけでも友達と一緒にいい悪い、好きだ嫌いだと話したものです(そんなに昔の話でもないですが)。CDがバカ売れた時代(そう、小室全盛期の頃です)のようにCDという、音楽ではなく、ものをとてもありがたがる、ということを最近しなくなったなーと感じました。今20～30代の人、そうじゃないですか？

ものとしての価値を上げるため、今はDVDが付いてきたりしますが、それも当たり前になってきて、DVDが付いていること自体は特別感はあまりありません。そしてプロモーションビデオを見ても何かおまけのような感じがして、有難味もだんだん薄れてきた気がします(それでも他に合法的に入手する手段のないプロモーションビデオを見ることができるのはありがたいです)。

ファイル共有ソフト黎明期(今から5、6年前のことです)に「CDが売れなくなった」とレコード会社が騒いだこともありましたが、遅かれ早かれ、音楽が日常により近いものになり、音楽はパソコンやiPodで聞く今のような時代は来たと思います。そしてそれとともに、CDに対する愛着はどんどん薄れ、買ってパソコンでエンコードしたら、あとは棚に並べて背表紙だけが日焼けしてゆくという、何とも寂しい時代になってしまいました。

レコード会社の人、今一度ものとしてのCDを再起させるべく、何かいい案考えてください！

Excelファイルがデファクトであることの障害: プログラムとの親和性の低さ

会社で使っているデータの多くがExcelファイル。これらをプログラム(PHP, Perl等)から利用できれば、作業の多くを自動化できるのにな～と思っています。

「思っています」というのは、色々考えてみましたが、有効な方法が思い当たらないからです。

一番一般的なのはCOMを使ってVBAを外部から使う方法ですが、これはWindowsでしか使えません。そのため、私のPCでは動かすことができますが、みんなに使ってもらうためにサーバに配置する、というようなことはできません(みんなが使えるWindowsサーバがないため)。

PHPやPerlにはそれぞれExcelファイルを操作するためのライブラリが用意されていますが、Excelファイルの作成こそある程度は可能ですが、読み込みは完璧ではないようです。サーバ/クライアントシステムとして、サーバ上でデータ操作をして、最終的な出力をExcelファイルとしてダウンロードさせる、といった使い方はできそうですが、サーバ上のExcelファイルを検索して、最終的な出力をHTMLで行う、という用途には向かないようです

やりたいことはまさに上記の後者の例で、サーバ上にある試験項目表のデータ(100ファイルぐらい)を検索した結果をHTMLで表示する、ということなのです。以前Pukiwikiに検索機能を付けた時は、Pukiwikiの全エントリを全文検索して結果を表示させる、という手法をとり、2,000弱のエントリで問題なく動いるのですが、Excelを100ファイルとなると、ファイルから動的にデータを読み出して処理する、というのは難しそうです。

動的なデータ読み出しができないのなら、静的にデータベースを作るなり、XMLに分解するなりすればいいのですが、ファイルが更新されるたびにデータを作り直さなければならないという問題が出てきます。1日1回だけに制限するにしても、更新するのは結局私なんだろうな、と思うとやっぱり現実的ではない気がしてきます。

Excelファイルでデータを管理すること自体、決して悪いことではないと思うのですが、自動化させる、という点からみると何とも忌々しいものです。