\ay diary

Typo 5.3で使っている自作のFlickrプラグインで写真を引っぱれなくなった。「Flie does not exist」という例外が起きている。ファイル?

追ってみたところ、vendor/flickr/flickr.rbで使っているXmlSimple.xml_inの中での起きている例外だった。xml_inは与えられた文字列がXMLっぽかったらXMLとして、そうでなければファイル名として処理しようとする。えぇー、と思ったが、まあそれはおいていおく。

実際にアクセスしているURLを取り出してwgetしてみたところ、きちんとレスポンスが得られる。けれどもxml_inには空文字列が渡っている。おかしいなと思い、flickr.rbではどのようにアクセスしているか見てみるとNet::HTTP.get_responseを使っていた。それではと同メソッドでアクセスしてみると302が返ってきていることがわかった。なるほど。

では302が返ってきたらそれを追いかけるように書き換えて、などとしかけたのだが、open-uriでよいではないかと思いとどまった。こんな感じ。

def http_get(url)
#  Net::HTTP.get_response(URI.parse(url)).body.to_s # 元のコード
  open(URI.parse(url)) {|i| i.read}
end

とあるきっかけから、監訳者の一人の橋本さんを通してオライリーさんからRailsデプロイ[rakuten]をいただいた。Railsプログラミングがひと通りできるようになった、常用しているマシンの上で動作させてきた、自分以外の人々に向けたサービスをこれから始める。本書はそんな人々を助けてくれるだろう。

プライベートに運用するアプリケーションを除くと、普段は自分がログインすることがほとんどないようなマシンがアプリケーションを動かすための場になる。そのようなマシンは一つだけではなく、用途ごとに複数のマシンを並べて動作させることが多い。このようなマシン環境下でアプリケーション群を正常動作させ続けるには、いつも使っているマシンでアプリケーションを運用するのとは異なった視点・手法・作業が求められる。

たとえば、アプリケーションを動かすのに必要なハードウェア環境…… はともかくとしても、ソフトウェア環境を整えなければならない。それはRubyのインストールから始まるかもしれないし、もしかするとRubyをインストールするための環境作りから始まるかもしれない。また、HTTPサーバを設定しなければならないだろうし、複数あるマシンがうまく連携できるようにもするだろう。アプリケーションのリリースは複数のマシンが対象となる。マシンの用途が違えば作業も違う。そして、マシンを増やすことがあればそのたびにそれらすべてを行う必要がある。いきなりなにもかもやろうとすると大変だ。

本書を読むと、手元で動かす→他のある程度整備されたホストで動かしす→VPSを借りて動かす→専用ハードを借りて……、といった具合にじょじょに規模を拡大していく工程をひと通りながめることができる。その内容は単に「Railsアプリケーションをリリースする」というだけではなく、複数のマシンでサービスを運用するための機能分散の方法や負荷分散をするためのリバースプロキシの設定など広い範囲をカバーしている。

そのうえ、複数のデータベースを運用するためのMySQLの設定とアプリケーション側での対処、チューニングのためのベンチマークやプロファイルの取り方、キャッシュの使い方とキャッシュ乱用への注意など、アプリケーションをサービスとして運用するのに必要な領域についても実践的に解説する。そのような点から、アプリケーションを作れるようになり、さあこれからデプロイしようといったストーリーの入口で本書は活躍するだろう。

少々残念なのは、今この時期にPassengerが扱われていない点。もちろん出版時期などからいたしかたないところではあるのだが、カバーしている範囲の広さからすると実におしい。また、Railsからはやや離れたところでの説明や表現にはいくつかひっかかる点もあった。一つあげると125ページの「Linux上でRailsアプリケーションを動作させるためには……最低限でもCやC++のコンパイラ……が必要」といった記述で、これはRMagickなどをRubyGemsで運用することなどを前提にしているのであるが、できるならコンパイラは避けたいところと考える人も少なくないはずだ。(他のものも含めて出版社の方に伝えておいた。)

一方、本筋とやや離れたところでちょっと感心したのは、Apache HTTPサーバの設定作業の中で、a2enmodやa2dismodなどに触れている点だった(本書ではUbuntuを主な環境としている)。この種の特定のOS環境(この場合はDebian/Ubuntu)に独特な手順というのはともすれば流されてしまいがちである。もちろん明確な方針があって別のやり方で運用するのは構わない。だが、マシンはいつか自分の手を離れるものであるとすると、理由がなければできるだけその環境の流儀に従っておいたほうがよいと思う。考えてみればRailsだってそうなのだから、環境整備でも同じようにしたってよいだろう。

追記(2009-07-24)

読んでいてひっかかった点は編集さんに送ったが、そのうち正誤表に載っていないものや載らなそうなものを以下に挙げておく。

• 56ページ15行目「コマンドラインに関する知識と何でもGoogleで検索してみる」
  • 「知識を何でも」?
• 67ページ下から10行目「インストール中にどのような種類の設定を行うか聞かれたら"Internet site: ... "(メールはSMTPを使って直接送受信される)という選択肢を選んでください」
  • 他のところでメール関連のことを扱っているのかなとも思ったのだけど特別に前提条件はなさそうなので、本文の記述に従うと外部からアクセス可能なSMTPサーバをたてるということになりそう
  • となると、一般的な選択という点ではローカルホストのみで動作させるくらいにして、必要に応じてそのような設定をしよう、というような書き方のほうがよいのでは
• 106ページ囲み
  • ファイルを/etc/init.dにコピーするだけでよいように読めるが一般にそのようなことはないはず
  • Debian系であればupdate-rc.d、Red Hat Linux系であればchkconfigでの操作が必要になる
• 107ページ囲み「flexとbisonそしてbyaccをインストールしましょう」
  • flex、bison、byaccのうちのいずれか、ではないのかな
• 110ページ15行目「Linuxシステムでは、initは/etc/init.dに置かれるすべてのスクリプトの実行を担当しています」
  • initはすべてのプロセスの祖先ですから間違いとはいえないが、 ここでいおうとしているinitの用法と /etc/init.d(より正しくは/etc/rc*.d)以下のファイルの運用はまた別だといっても差し支えないと思いう
  • /etc/init.d(略)以下のファイルにより起動したサービスは /etc/inittabで管理されるプロセスとは違ってinitにより再起動されることは通常ない
• 110ページ訳注「sudo update-rc.d monit remove」
  • /etc/init.d/monitが残っている場合、update-rc.d -f monit removeとする必要がある
  • そうでなければrm /etc/init.d/monitした上でupdate-rc.d monit removeとする
• 110ページ下から4行目「Monitを使ってMongrelを管理するようになったら…mongrel_cluster/recipesを使う必要はなくなりました」
  • mongrel_cluster/recipesが唐突に出てきている…… ような気がする
  • 読み落としてしまっただけかも(検索可能な何かがあればなあ)
• 111ページ下から4行目「FastCGIのゾンビプロセス」
  • 「なぜか居残り続けてしまう、仕事をしないfastcgi管理下のプロセス」にすぎず、UNIX一般にはこのようなプロセスをゾンビとは呼ばないように思う
  • 実際、reaperはfastcgiプロセスに対してシグナルを送っているわけだけど、本来の意味でのゾンビプロセスはそもそもシグナルを受け取れる状態にない
  • 参考: プロセス - 終了状態
• 117ページ15行目「ハートビート」
  • 外部から動いていることを確認すること自体をハートビートとはあまり呼ばないような気が
  • 一般的には生存証明を自らするようなものをそう呼んだり、あるいは、HAクラスタなどでサービスが動作していることを待機系とで情報交換するような仕組み全体を指すことはあると思う
  • いずれにしても本文で説明されているのはNagiosなどがするような監視であって、死活監視などと呼ぶほうが一般的ではないだろうか
• 127ページ下から二行目「CNAMEレコードはAレコードのエイリアス(別名)のようなものです。対象のAレコードは自分のものでも他人のものでもかまいません」
  • DNSの「リソースレコード」と「名前」が混同されているように思える
  • CNAMEレコードでは名前に対応する正しい名前を定義する
  • CNAMEレコード全体をもってエイリアスと表現するのは間違いとまではいえないが、CNAMEレコードの対象がAレコードというのは表現としておかしいのではないか
  • 実際、CNAMEレコードを持つ「名前」に他のリソースレコードを付けてはならないことになっているはずで
• 129ページ10行目「大きな値(例えば7日)を指定すると、ブラウザなどのクライアントソフトウェアがDNSに問い合わせを行う回数を削減でき」
  • 「クライアントソフトウェアがDNSに問い合わせを行う」というのはリゾルバの動作で、リゾルバの動作にはTTLはリゾルバの動作に影響を与えない…… のではないかしら
  • MS-Windowsなど、ある種の環境ではDNS問い合わせについてのキャッシュ機構があるようだが、それらを考えにいれたとしても実装依存というのがやっとだと思う(MS-Windowsの機構はキャッシュサーバの一種なのではないかしら?)

藤堂あきとさんのパーツのぱ[rakuten]を読んだ。

全体的に電気街だったころの秋葉原の雰囲気を持ち続けるパーツショップでのあれやこれやを猫いている。見開きで一話。軽いテンポながらも業界裏話のドロドロが見え隠れする。

秋葉原にはつっこんで通ったことはなかったのだけども読んでいるとなんだかなつかしい。なんていうか、あーっていう感じ。部品を選んで探して、なんてもう何年もしていないが、そうして組むのもよいかもな、なんて思った。(思っただけだけど……。)

あるときgit pullしたら以下のようなエラーが返ってきた。

remote: Counting objects: 39, done.
remote: Compressing objects: 100% (27/27), done.
remote: Total 27 (delta 19), reused 0 (delta 0)
error: unable to create temporary sha1 filename .git/objects/96: File exists

再試行しても状況が変わらない。どうしたものかと調べたところ.git/objects/96のオーナーが他のユーザになっていたためだった。どうやらsudoのオプションを間違えたことがあったようだ。

同様にオーナーが違っているディレクトリが他にもあったので修正。再びgit pullして今度はいつも通りに動作していることを確認できた。

数年ぶりにめがねを買うことになった。近くのお店をいくつかまわったのだがピンとくるものがない。石川町駅の近くにあったまるや眼鏡店で見て気にいっていたKamuroを思い出し、どうせならと南青山まで足をのばした。

都内に出るのはおっくうだったが行ってみれば、他のブランドではなかなか見られないデザインながらも奇抜なところがなく、すごくバランスがよい。もちろん似合うかどうかは別問題なので、そのうちのいくつかにしぼり込んで悩むことしばし。外に出て外光で見たり、サイズが合うかどうかを見てもらったり、詰めることも可能かどうかなんてことを確認してもらったりして一つに決定した。

というのは実は私のめがねではなかったりする。ただ、本音を言えば自分でも欲しい一品だったりもするので、自分ではかけられない(サイズが違うし)ながらもそこにあるうれしさはあったりしてよい気分になった。近くのめがね屋では扱いのあるブランドがごく限られることもあり、やっぱり都内にも出てみるものだななどと現金なことを感じていた。

レンズの在庫があったので一時間ほどで調整できるとのこと。その間、適当なカフェにでも入って待っていようかとうろうろし始めたところで蔦珈琲店のことを思い出した。数年前に行ったことがあり、禁煙ではないのだけどおいしかったなと。

記憶をたよりに入ってみれば今も変わりない…… 気がする。一度行っただけだったからあまり確かなことはわからない。でもカウンターにテーブルがいくつかという小さなお店の感じは覚えていた通り。そうそう秤があったんだった、なんてことを考えながらコーヒーをいっぱい。シュークリームを一つたのんで(主観的には)長の旅の疲れを癒しつつ、時間を過ごした。