\ay diary

CREAMというイベントの中でMEGASTAR-IIによるプラネタリウムの上映が行われている。ワールドポーターズの向こう側(桜木町駅から見て)のあたりで開催されており、MEGASTAR-IIがあるのは11/20まで。

ちょうど、あのあたりで用事があり、プラネタリウムというものを見たことがなく、でもMEGASTAR-IIという名前くらいは聞いたことがあって引っかかりはする、というようなことで、ひとつどんなものかと見に行ってみた。

イベントへの入場は大人一人1,300円だが、プラネタリウムだけなら一人分のチケットで二人分の整理券をもらえる。つまり大人二人で1,300円。移動式の大きなエアドームがあって、その中には座布団が敷かれている。これに座って見るわけだが、まあ開演ほどなくしてほとんどの人が寝っころがっているようだった。

内容は…… 想像していたのとは違った。

イベントの性格もあるのかもしれないけれど、MEGASTAR-IIによる星空は背景で、「夜はやさしい」という詩(なのかな?)の朗読がメイン。世界各地での星空と、その地に特徴のある音や音楽が流れる。星空がどんどん変わっていくのはわかるのだけど、そもそも星空についての知識がないため「あー、映ってるなー」「またたかないのかしら」「顔に光がきてチカチカするね」などという感想に。ただの星空ならちょっと地方に行けばけっこう見られたりするし、詩(?)の内容が好みではなかったというのもある。

まあ、ともかくプラネタリウム入門者にはハードルの高い演目であった。

事前に確認しておけばよかったのだけども、プラネタリウムの演目のイメージがなかったのだった。まあ、これはこれで勉強になったので、次の機会にはもう少し理科的な演目を選んで観に行きたいと思う。ただ、ちょっとプラネタリウム熱が冷めちゃったかな。(夏ごろからプラネタリウム行ってみたいなと思っていた。)

(デジカメでフラッシュをたいて映像を撮ろうとしたおばさんがんいた。)

スイスのお菓子にRahmtäfeliというのがあるそうだ。これをCafe de Pouが日本で販売したのが「キャラメルト」。日本名(?)から連想できる通りキャラメルで、練乳とかなんとかで作られているらしい。

見ためは昔ながらのキャラメルを小さく切ったようなもので、ぐにっという感じの例の食感を予想させる。ところが食べてみると、カリッといいそうな堅さがある。でもそれはほんのちょっとした厚みしかなくって、すぐに解けて崩れるような、独特の感触を味わうことになる。

味は甘くて、練乳、なるほど。という感じがする。ごく軽い苦味があるものの、甘味のほうが断然勝っている。ただ、ひどく後味が残るということもなくて、そこがなかなかあなどれない。エスプレッソが最もあいそうだが、濃いめのコーヒーにもよくあう。(うーん、エスプレッソマシン出しちゃおうか。)

よくできたお菓子だ。

C言語のワンライナーを書くためのCというツールがある、というのをついさっき知った。

普段C言語を何かを作るということはあまりなくて、C言語といえばどちらかというと読むもの。しかも部分的に。だから「あれ、どうだったかな?」なんていうのは――「;」忘れも欠かさない私にとってはよくあること。意外と使えるかもしれない。

こういうツールで迷うのはどこにインストールするか。ちょっと使ってみるだけになるかも、と思うと/usr/localを使うのは…… という気分になる。かといってホームディレクトリにポンと置いておくだけというのも。

まあ、本当のところは迷ってはいない。ちょこちょこっとパッケージングしてしまえばいいのだ。特にこういう小さくて、サーバ的でもないツールならパッケージ化の手間もたいしたことはない。

具体的な手順はこんなところ。

$ tar xf C-0.06.tar.gz
$ cd C-0.06
$ dh_make -c gpl2 -b -s -p large-c -f ../C-0.06.tar.gz
$ cd debian
$ rm README.* cron.d.ex emacsen-* init.d.* large-c.* manpage.* menu.ex post* pre*
$ vim copyright
$ vim control
$ mv watch.ex watch
$ vim watch
$ cd ..
$ debuild -uc -us

debian/copyrightやdebian/controlはREADMEなどからのコピー&ペーストで、debian/watchもURLを調整する程度。C-0.06のような構成ならdebian/rulesに手をいれる必要もない。

実際にはlintianエラーをつぶすためにdebuildをあと二回くらいは実行したものの、全工程で15分ほど。できたlarge-c_0.06-1_i386.debをインストールして作業を終えた。

$ C -cWall -cO2 -e 'printf("hello world\n")'
hello world

2009年11月2日 - 2009年11月8日の読書メーター
読んだ本の数：3冊
読んだページ数：432ページ

■タイム・リープ―あしたはきのう (下) (電撃文庫 (0147))[rakuten]
読了日：11月06日 著者：高畑 京一郎
http://book.akahoshitakuya.com/b/4840205590

■タイム・リープ―あしたはきのう (上) (電撃文庫 (0146))[rakuten]
読了日：11月06日 著者：高畑 京一郎
http://book.akahoshitakuya.com/b/4840205582

■SOUL GADGET RADIANT 1 (ZERO-SUM COMICS)[rakuten]
読了日：11月05日 著者：大森 葵
http://book.akahoshitakuya.com/b/4758051275

▼読書メーター
http://book.akahoshitakuya.com/

Passengerを使っていて実際にやってしまったダメーな思い出話。(けっこう前のことなので今の状況とは少し違うかも。)

間違ったキャッシュが返る

この日記にはtDiaryからTypoに移行したという経緯がある。移行のためのあれやこれの手間はかかったものの、一通りの作業を終えるとおとなしく動作していた。

ところが、ある時、ブラウザからのアクセスにatomデータを返していることに気付いた。動作を追ってみると、どうも何かの加減で間違ったキャッシュファイルがレスポンスに使われているように見える。そこで、とりあえずの回避策として、生成されていたatomキャッシュを削除した。するときちんとhtmlデータが返されるようになり、新たにhtmlのキャッシュファイルが生成されていることを確認できた。

気になって調べてみると、atomキャッシュだけが生成されているページが他にもいくつかある。先にatomへのアクセスがあれば当然このようになるわけなので、それ自体は問題ないはず。だが、これがあるとhtmlで返すべきところが返らなくなってしまうようだ。

ある期間この現象は困った謎のままであった。まったく見られなくなるわけでもなく、ともかくは動いているということもあって、場当たり的な対処を繰り返して過ごしてきた。

ここでTypoが作るキャッシュを考えてみる。Typoは生成するレスポンスによってhtml、atom、rssなどのキャッシュをファイルとしてpublic以下に作る。これらのファイルは、Passengerの通常通りの動作としてTypoが関与することなくレスポンスに使われる。したがって、問題のhtmlリクエストに対してatomデータを返している容疑者はTypoではなくPassengerかApache HTTPサーバである。ということに、かなり時間をかけた上で気付いた。

もう少し正確に言うと、ようやくそこに目を向けることができた、という感じかもしれない。となれば、まっ先に疑うべきであった点が一つ。MultiViewsだ。

ところで、前述の通り、この日記はtDiaryからTypoに移行した。tDiaryのときの設定は以下のようなものだった。

Alias /diary /path/to/diary
<directory /path/to/diary> # tDiary
  Options -MultiViews
</directory>

これをTypo+Passengerにかえた際に、/path/to/document_rootから/path/to/diary/publicへのシンボリックリンクを作成した上で、次のように変更した。(実際にはtDiary→Typo+FCGI→Typo+Passengerと設定を変えてきているため、その跡が少し残っている。)

#Alias /diary /path/to/diary/public
<directory /path/to/diary/public> # Typo
  Options -MultiViews
</directory>

気持ちの上ではMultiViewsはオフのままにしたつもり。だが、もちろん、そんなことはなく、/path/to/document_rootで有効になっているMultiViewsは/path/to/document_root/diaryでも有効になる。そしてTypoが作り出すURLには拡張子がついていない。ブラウザからのアクセスは/diary/fooに対するものとなる。この時htmlキャッシュがなくて、atomキャッシュやrssキャッシュがあれば。そう、MultiViewsの機能により(もちろん設定にもよるが)htmlではなくそれらのデータがレスポンスとして送信されてしまうのであった。

Passengerじゃない!

FastCGIで動作させていたあるRailsアプリケーションをPassengerで動かすことにした。ところが、なかなか作業がはかどらない。移行をしているせいもあって、いろいろやってみたあげく、変わらずFastCGIで動いてしまうというのを何度か繰り返していた。

と、ここで、FastCGIを動かなくしてしまえばよいではないかと思い付いた。そもそもPassengerに移行した後はFastCGIを使わないのであるから、これはどちらにしても良いことである。

さっそくそのようにしてみたところFastCGIで動作することはなくなった。

よかった、よかった。別の作業に取りかかろう。……あれ? なんだか重い? アプリケーションは動いてはいる。エラーも出ていないし、返ってくるデータにも問題はない。だけど、あれ? レスポンスがものすごく悪い?

FastCGIのプロセスがなくなったことで安心してしまったが、そういえばPassengerのプロセスは動いていただろうか。

あわてて見直してみると、Passenger配下にあるはずのインスタンスがない。では、どうやって動いているのだと追ってみれば、なんとも困ったことにアプリケーションはCGIで動いていたのだった。