ミミソミミファドシ〜ミドシミミドシミミソミレミファレ〜

居酒屋で突然GN'RのRocket Queenのリフを歌い始めました。最近覚えた曲って一回弾けてもすぐどう弾くのか忘れるけど、やっぱりあの頃に毎日のように弾いてた曲はソラでリフまで口ずさめる。というわけで３０代の男二人でGN'Rを酔っぱらいつつ歌っていたのでした。

今朝家を出る時にギターを持ってみたらやっぱりすんなり弾けた。手が覚えている。すばらしい。

http://www.minico.jpをリニューアルしたよ。大分使いやすくなったと思うデス

http://portal.nifty.com/2007/10/20/a/

べつやくさんはメタルだったらしい。嬉しい。

細かいバグ修正をたっぷり仕込んだMDBA 0.01003をリリースしました。かなりエレガントな動きをするようになってきた。

本日の献立は、ポークソテー、キャベツ千切り、キャベツのコンソメスープ、マカロニサラダ、それにもずく。焦げ過ぎに見えますが、実際は問題無しですよ。最近フリマで小鉢を買ったので、さっそくマカロニサラダに使ってみました。

ポークソテーは見た目以外はとてもおいしくできましたよ！

Gunghoのログ関連機能を大分強化しました。Log::Dispatchを使うので、ファイルだろうとDBだろうとログを突っ込めるようになったよ。コンフィグの中で

log:
  dispatch:
    logs:
      - module: File::Locked
        name: file
        filename: /path/to/filename
        mode: append
        min_level: info
      - module: DBI
        name: dbi
        datasource: 'dbi:mysql:log'
        username: 'user'
        password: 'password'
        table: 'logging'

ってな感じにするとLog::Dispatchが生成されて、$c->log->debug() や$c->log->emergency()でログをどんどんと吐いて行く事ができます。

あと、これと同じ機構を使って、RequestLogプラグインも作成。こちらはGunghoが持ってきたレスポンスのログを溜めて行くもの。

それとRobotRules::Storage::Cacheがようやく完全に分散環境に対応できました。

近所の商店街を歩いていたら「秋刀魚５０円！」と言われた。今シーズンの秋刀魚は食べ尽くしたかと思ったのだが、結構いい秋刀魚だったし、なにより５０円だ。ついでにアサリが一杯１００円だったので一緒に購入。なんかそれだけだとアレなんで今日はご飯は炊き込みご飯かなーと思ってたら、次に行ったスーパーでキノコとりどり３個で２７０円だったのでキノコの炊き込みご飯決定。

アサリは味噌汁にして、もずくを一杯。あとは以前に実際どんなもんなんだろうと思って買っておいた焼き茄子を冷凍したものを（←これが実にうまかったので今後も買うと思う）。今日はちょっと秋刀魚を焦がしちゃったけど、いい感じの秋の食卓になったと思う。うまかったー。

実は「創聖のアクエリオン」、夜中に偶然本放送を見かけて、飛び飛びながらほぼ全話見てたんだな。当時からあの歌詞すげぇ、と思ってたけどまさか一位とは。

しかしストーリーにはやっぱりちょっと無理あるよ。w

Pathtraqでgunghoを使ってくれてるのですでに++しまくりなkazuhookuさんに話をしにcybozuラボさんにお邪魔してきましたよ。本当はgunghoのバグいっぱいあるんだろーなーと思って話を聞きに行ったんですが、特に問題はないそうで。えっと、特に問題はないそうで！

いやー、よかったよかった。後はSwiftyの話を聞いたりKeyedMutexの話を聞いたり。大変ためになりました！

id:zigorouさんに"Getting Your Feet Wet With XS"のプレゼンをリクエストされました。ここにあります

id:amachangさんとも初めてまともに話しました。ちなみに私と同姓同名の方がMozilla24のほうで発表されてたそうで。俺も最初にページ見た時にびっくりしたんだけどね。

id:takesakoさんもお世話様でした。今度もっと時間のある時にお邪魔します！

これは結構楽しい。PoCo::IKC→PoCo::MDBAの流れでざくざくいけそうだ。

Data::Throttlerは１マシン上でスロットルするにはいいんだけど、複数ホスト上においてはあまり意味がないのでストレージにCache::Memcachedを使ったData::Throttler::Memcachedを作ってみたよ。さきほどCPANうp

追記：もうちょいテストしてからGunghoもD::T::Memcached対応したバージョンでアップする。

Catalyst::Model::Adaptorがリリースされていたので早速使ってみた。

それまでもなるたけ全てのロジックをモデルにいれようとしてたんだけど、モデル自体がCatalystにべったりで嫌な感じだったのでどうやって分けようかと考えてきた。例えばCatalystに載せたくない（メモリを食う割に、別に非同期でバッチ処理すればいいものとか）もmodelにしか生き場所がないのにCatalystから分離できないという妙な状態だったりした。

そこでCatalyst::Model::Adaptorです。Minicoの現在の開発版ツリーはそんなところからAdaptorで実装をリファクタリングしてみた。

多分ケースバイケースなんだろうけど、俺の場合は以下の数点を考慮しながらやったらいい感じになってきましたよ：

• Minico::Business::Model::*以下にモデルを移動
  
• C::M::Adaptorは一応コンストラクタとかあるからOOにしたいところだけど、そこは敢えてインスタンスを作らない
• $cは基本的に使わない
• $cから得られるものに関しては初期化時に保存
  
• Modelの中から入れ子に呼んでいたほかのモデル（$c->model('Hoge')->method()）をクラスベースで呼び出す( Hoge->method()）

これであとはわりと普通にうまく動いた。

それと同時にCache::Memcached::Managedを使い始めた。

CPANのバグ報告システムはとてもいいと思うのだが、新規バグが報告された時にメールで通知が来る時と来ない時がある。なんでだろうなぁ。

というわけでmiyagawaさんのブクマからXML::RSS::LibXMLのバグを発見。先ほど修正して0.3002をアップロードした。

昨日開発版コードを見てたら、検索結果がおかしいのでよく見てみたらLudia 1.3.0でにした際それまでの1.1.0で動いていた SELECT * FROM table WHERE fts @@ '*D+ hogehoge'という検索が"sen_query_scan failed(1)" というエラーで落ちるようになっていた。これがまた静か〜〜〜に落ちて、ただ結果を返さないという仕様なためしばらく気がつかなかった。ludia-1.3.0からsenna-1.0.8を使うようになっていて、ここでsen_query_scanが初めて使用されている。1.0.8は一回差し替えされたといういわくつきのリリースなので、念のためもう一度入れ直しても症状は同じ。

なのでsenna-1.0.5+ludia-1.1.0にダウングレードしたら問題も解決した。

senna+ludia/tritonnは実際使っててスピードや利便性に関してはなんの文句もないけれども、エラーが起こった時に何をしたらいいのか全くわからないのが運用上ひじょうに不安。senna.logに吐き出す事はできるだろうけど、senna.logは内部構造的な情報がほとんどで中身に精通してない（別にしたくない）人には不親切。例えば今回のエラーに関してはsen_query_scanは多分クエリーをパースするものだろうから、そこでエラーがあるんだろうけどSTDERRかどこかに"failed to parse query hogehoge: XXX details of the error XXX"くらい書いてくれてもいいんじゃないかと思う。まぁこれはsenna本体だけではなくludiaの問題でもあるんだろうけど。

ちなみに1.3.0でなぜ＊一部＊のクエリーだけにこの問題があるのかは不明。←全部がつぶれるんじゃなくて、一部だけが答えを返してくれないので発見が遅れた。

アップグレードする度にどきどきするわ。

http://labs.cybozu.co.jp/blog/kazuho/archives/2007/10/perl_mp.php#more

こちらで言及されている件に関してはごもっとも。スライドにはメモリフットプリントとか書いちゃったけど、本当の意図は「イベントドリブンなGunghoの中でクロール以外の処理してるとクロールが遅くなるよ！」って事でした（でもそもそもいらないモジュールをプロセスの中に読み込むのはどちらにしろ嫌いではありますが）。

実際Xangoの中でDBにアクセスしてたら、当たり前なんですがすげぇスループットが落ちて悲しかった記憶があります。それでEasyDBI使ったら今度はメモリーリークですよ。もう今は直ったようですが

（そんな経緯でPOE::Component::MDBAはPoCo::Genericに辿り着いた）

あとは奥さんも書かれている通りDBとか、それ以外のしょうもない処理でクローラーに落ちてほしくないとか、まぁ色々。そんなわけで僕は基本的には機能別にプロセスを分ちたい派なのであります。