移転先は、こちら。
→http://d.hatena.ne.jp/pooza/
近日中に、vCardレンダラーの実装に対応。
＃レンダラーだけでなく、パーサーも必要？
我慢しきれなくなってベータ版を利用しているけど、もう十分に安定している。
ベータ版だから人にお勧めするたぐいのものではないけど、AdiumとTwitterの両方を利用している人は、是非試して欲しい。
ベータ版に興味がある人は、ググればすぐ見つけられるはずのなので、ご自由にどうぞ。
無論、Your own riskで。
Facebookで知り合った、蒲田在住のひとの紹介。
曰くこのお店、蒲田の中華ではイチオシとのこと。
そんなわけで、これが金春オススメのエビチリと、なんとなく好みで頼んだザーサイ炒め。
＃ 映っている手は、同行してくれた友人のもの。
事前にぐるなび等を調べたところによると、おこげ, 小籠包, 餃子あたり、とくに餃子がオススメとのことだったので、一通り平らげてきた。
近いうち、また行こうと思ってるところ。
ところで、ほかにも何枚か写真撮ったんですけどね。
紹興酒とかですっかり出来上がってたんでしょうかね。手ぶれがひどいですわ。
↓そんな写真でもよかったら、こちら。
蒲田金春の写真
追記
おこげは海鮮と五目があります。
五目おこげはメニューになかったのですが、お店の人に聞いたら出てきました。
＃自分、中華おこげ好きなもので。
「...いつまで待っても落ちてこない。」
まず、Subversionパッケージのビルド手順を疑った。
Neonのリンクを忘れて、DAV非対応の設定でビルドしちゃったかな〜、なんて。でも、どうも違うらしい。
> svn --version svn, バージョン 1.6.2 (r37639) コンパイル日時: May 13 2009, 16:36:01 Copyright (C) 2000-2009 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). 以下のリポジトリアクセス (RA) モジュールが利用できます: * ra_neon : Neon を利用して WebDAV (DeltaV) プロトコルでリポジトリにアクセスするモジュール。 - 'http' スキームを操作します - 'https' スキームを操作します * ra_svn : svn ネットワークプロトコルを使ってリポジトリにアクセスするモジュール。 - Cyrus SASL 認証を併用 - 'svn' スキームを操作します * ra_local : ローカルディスク上のリポジトリにアクセスするモジュール。 - 'file' スキームを操作します * ra_serf : serf を利用して WebDAV (DeltaV) プロトコルでリポジトリにアクセスするモジュール。 - 'http' スキームを操作します - 'https' スキームを操作します
そう、特におかしいところはない。
最初、耳慣れないra_serfなるモジュールを疑ったが、特に関係ない様だ。
無駄とわかりつつ、何度かチェックアウトを繰り返すうち、気づいたことがあった。
「チェックアウト出来ない」というのは微妙に違っていて、正しくは「ダウンロードがとても遅い」のである。MacPortsのsvnコマンドは、チェックアウトそのものは異常なくこなしていたのである。
この時点で、クライアント側をシロと判断。ではサーバか？イヤな予感がする。
サーバ上のSubversionパッケージや、リポジトリをホストしているApache 2.2に対し、オプションを変更しながらビルドを繰り返すが、状況は変わらない。
この時点で深夜。リポジトリサーバがこの調子では、週明けからの業務に著しい支障が出る。急遽、事務所に1台だけある「固定アドレスを持ったホスト」（いわゆる「自宅サーバ」）に、Redmineと共に移した。取り急ぎ、リポジトリだけを緊急避難することは出来た。
翌日、日曜日（5/17）。
影響はSubversionにとどまらず、scp, rsync, ftp等々、あらゆるネットワークトラフィックに及んでいることがわかった。想像以上に深刻な状況ではあったが、一方でSubversionやApacheの無実は確定。
思いついたのはOS上の問題と、経路上のいずれか（サーバが置かれているデータセンターか、事務所で利用しているISPか）で行われている帯域制限。
可能性は絞られてきたが、いずれも厄介だ。
「帯域制限を受けている」という可能性について、身におぼえがあるかどうかは、微妙なところ。
職業柄、人並み以上にパケットを飛ばしていることは大いに認めるが、一方、この手の帯域制限が取り締まりの対象としてる「P2Pのヘビーユーザー」には劣るだろう。
この日は日曜であり、果たして自分が帯域制限の該当者なのかどうか、 ホスティング業者にもISPにも確認が取れない。こちらの可能性は一旦保留、もう一つの可能性であるOSのほうを検証することにした。
OSが原因であるという可能性にも、一応心当たりはある。サーバのOSを、FreeBSD 7.1から7.2にアップグレードしていたのだ。
でも、まさかねぇ。7.1から7.2へのアップグレード（freebsd-updateを使用）はこのサーバ以前に2台ほど経験しており、いずれも問題は起きていない。
手始めに全てのports（パッケージ数は250ほど）を再ビルドするも、効果なし。やはり、FreeBSDのバージョンを7.1に戻すしかないのか。
OSのダウングレードだが、その手順が問題だ。
freebsd-update一発、というわけにはいかないだろう。freebsd-updateにそんなことが出来るのかどうか怪しいものだし（manにそれらしき記述がないし、ググっても事例が見つからない）、仮に可能であるとして、少なくともリスクは高い。
そう考えれば、たとえ面倒でも「ソースからmake world」という手順が妥当だが、手元にソースコードがない。STABLEの追っかけをやめてfreebsd-updateに移行した時に、ソースコードを破棄していた為だ。usrパーティションが大きくないという、レンタルサーバ側の事情もある。
では果たして、これほどの手間をかけて、その上リスクまで負って、OSのダウングレードをする価値はあるのか。
翌日、月曜日（5/18）。週が明けてしまった。
結局やるしかない様だった。
/usr/srcをhomeパーティション上の/home/srcに移し、シンボリックリンクを通す。
csupでOS全体のソースコード（RELENG_7_1）をダウンロードし、一気にビルドするも、make buildworld途中でエラーを吐いて停止。原因はusrパーティションの容量不足。
/usr/srcを移しただけでは不足だった様で。/usr/objもhomeパーティションに移し、再度ビルド。インストールの後、再起動。
結果的にこの処置は正解だった様で、ネットワークのパフォーマンスも無事復旧。「帯域制限を受けている」という懸念は杞憂だった。
どうやら7.2のカーネルが問題を起こしていたらしい。では他のサーバで、このカーネルは問題を起こしていないのだろうか？
たとえ日本に限っても、相当数のユーザーがfreebsd-updateでOSをアップグレードしているはず。にも関わらず、いくらググっても事例は見つからないし、自分自身も過去に2台のサーバで、同様のアップグレードを成功させている。いや本来、成功と言うほど大層な作業でもないし。
今回、このサーバだけに現象が発生した、大本の原因がまだつかめていない。FreeBSD 6.0の頃から、おそらく5年くらいは利用しているサーバだが、思い当たるのはそれくらい？
今ではほぼ同じ月額で、Core 2 Duoを積んだサーバに乗り換えることも出来る。もちろんFreeBSDのまま。
初期料金は発生するものの、「この機会にサーバを新調するのは、悪い考えじゃないな」と思った。
新しいサーバをいじり回すのは楽しい。
ぼくは車には乗らないが、新車を乗り回す気分とは、きっと似たものだろう。
ごく近所で生まれ育ったこともあって、改めて訪れる機会はあまりなかったが、久しぶりに足元から見上げてみるとなかなかの迫力だ。
それにしても驚いたのは、観光地としてすっかり垢抜けたこと。出店している店舗も総入れ替えしたかのようで、まるで別物。
小学生の頃、大のゲーム好きだった自分にとって、東京タワーはゲーセンのひとつだった。
ゲーセンの上のフロアにはNECのショールームもあって、当時展示されてたキャプテンシステムに未来を感じたりしたものだった。
ああ、東京タワーよ。思い返せば案外、ぼくの人間性や将来にも影響を与えていたのだなぁ。
観光スポットとしてより洗練された東京タワーを、地元民の一人として誇らしく思いつつ、今と変わらずヲタだった少年時代を、ノスタルジックに回想したのだった。
「テンプレートエンジンの役割を考える」という発表が、身近な話題ということもあって、共感するところが多かった。これについては、近々別エントリーで考えてみたい。
繁忙期に放置気味だったことは仕方がないとしても、いつまでもペット日記が続く状況もアレなので、ぼちぼち復帰していこうかと思っているところ。
]]>