Catalystでバックエンドに１回アクセスしてキャッシュ、Catalystはそのままにしておいて、バックエンドのmemcachedを停止→再起動、そしてもう一度同じURLにアクセスしてcache->getすると

[[email protected]] mcm_buf_read():361: read(2) failed: server unexpectedly closed connection

となってプロセスが落ちる。おっとーーー・・・次のサーバーにfailoverしろよぅ。

http://pgfoundry.org/projects/pgmemcache/

メモ。ロジックはトリガーで自分で書く、というのがいいなぁ。

WiiのリモコンのイベントをJavascriptっぽく扱わせてくれるライブラリ。いいんだけど、setupHandlers()って呼ぶとデフォルトで使えるスクロールとかが全部効かなくなる。勘弁してくれ。というわけで、その部分だけ書き直してみた。

wii.setupHandlers = function() {

  var o_onkeypress = document.onkeypress;

  document.onkeypress = function(e) {

    var keyCode = e.which;

    var controllers = wii.controllers_;

    var returnValue = true;

    for (var i = 0, len = controllers.length; i < len; ++i) {

      var controller = controllers[i];

      if (!controller.handleKeyPress(keyCode)) {

        returnValue = false;

      }

    }

    if (! returnValue) {

      return o_onkeypress(e);

    }

    return returnValue;

  }



  var o_onclick = document.onclick;

  document.onclick = function(e) {

    if (e.which != 1) {

      // not the left mouse button

      return;

    }

    var returnValue = true;

    var controllers = wii.controllers_;

    for (var i = 0, len = controllers.length; i < len; ++i) {

      var controller = controllers[i];

      if (!controller.handleMouseClick()) {

        returnValue = false;

      }

    }

    if (! returnValue) {

      return o_onclick(e);

    }

    return returnValue;

  }

}

pcreを入れ、glibcを入れ、pkg-configを入れ・・・色々やってみて、fastcgiも動かしはじめたところ、１リクエストで落ちた。

http://trac.lighttpd.net/trac/ticket/1137

あああぁぁぁぁ・・・・・・

今までずっとLoaderで動的にスキーマを読み込んでた。スキーマ変更をちょくちょくしてたのもあったし。でも最近開発が急ピッチで進んでるところで皆同時にDBIC::Schema::Loader->connection()とかやり始めるとすごい遅くなるから、皆が大好きmake_schema_atを試してみてるんだけど、これがうまく動かない。特にrelationship系のところがメタメタ。search_related()とかやると、"can't call select() on an undefined value" とか言われる始末。なんでやねん。これがコマンドラインからだと動くんだけど、なんかCatalystからだと動かないというのがさらにいけない。あと、別ディレクトリに自分の拡張を入れて行くのはいいんだけど、これを入れてmake_schema_atする時に他の自分のモジュール（例：lib/MyApp/Util.pm）を使おうとするとlibをパスに入れなくてはならず、そこでlib/MyApp/Schemaを認識させないために妙な事をしなくちゃならんし・・・・

俺がなんか変な事してるのかなぁ。なんとなく、MyAppとは別にMyApp::Schemaを編集／管理するべきな気がしてきたよ！

private IPに関してのフィックス、03_liveがこけてた件を直した。なんかそろそろAPIを固定してもいいのかと思い始めてきた。

あー、超久しぶりにバグ直した。0.05うp

今日は麻婆茄子。ニンニクとネギをごま油で炒めて、そこに豚肉を投入して一緒に炒める。ちょっと酒も。香りがたってきたら一口大に切った茄子を入れて炒めて、後は水に溶かした味噌、酒、極々少量の醤油と砂糖、それと豆板醤で味を調整。一番最後に香り付けのための胡麻油をたらしてできあがり。

付け合わせはレタスの中華風スープ。中華スープの元をベースに味を付けて、ベーコンの細切り少々、タマネギ少々。とき卵を落として、最後にレタスを投入。食べるちょっと前にこれも少し胡麻油を。

いつもの鍋炊きご飯もおいしくできた。うまうま。

とうとうこらえきれずに小笹寿司に行ってきた。ここに引っ越してきたくらいから「実はすごい近くに住んでるんじゃねーか？」とずっと思っていて、先週は店の前まで行ったのに、休日でしまってやがったので、やっと行けた、という感じ。今日はとにかく湯引きされた鯛がすっっっっっっごいうまかった。あとアナゴがたまらん。しかも想定していた値段より６０００円も安かった。またいくぞー。

なんか富士の裾野のあたりをまわる旅で、ブラジル食料品店が！わーーー、しかも作り立てのパステルが食える！いいなあああ！パステルとグァラナで週末の軽いブランチとかやりたいなぁ。

POE::Component::Client::HTTPでHTTP::Response::OnDiskを使おうと思ったら何個かメソッドが抜けてた。この中でもcontent_refとdecoded_contentはキツい。というわけでただいまdecoded_contentがちゃんと動きつつもメモリフットプリントが最小限に抑えられる方法はないか模索中。

追記：模索した。HTTP::Responseの中で使われているCompress::*系のモジュールはとかく効率が悪いのでIO::Uncompress::Gunzipとか、IO::Uncompress::Bunzip2とかに置き換えて、テストテスト。とりあえずPOE::Component::Client::HTTPにパッチを当ててHTTP::Response::OnDiskで動かしたらエラーは出なくなった。このバージョンはHTTP::Response::OnDisk 0.02としてアップロードした。

POE::Component::Client::HTTPに関してはHTTP::Responseオブジェクトもさることながら、$request->[REQ_BUFFER]に対するメモリの書き出しを制御せにゃならんので、POE::Component::Client::HTTP::RequestFactoryへのパッチと同時にしないとな。

http://www.youtube.com/watch?v=F0cuLoWK2Jk

一瞬紋章がジオン軍かと思った。

http://d.hatena.ne.jp/kdaiba/20070523

こういう感じ、いいと思います。Gunghoはアプリケーションロジックをgungho本体から完全に分けれるようにしたかったので、providerとhandlerの部分は正直かなり薄いレイヤーでFacadeを使って、アプリケーション特有のロジックにさっさとコントロールを渡すのがいいと思います。

ちなみに地震っていつも起こってるんですねぇ。

ドキュメントに何がどうほかのモジュールと違うのか書いた。

実際にWebサーバーにアクセスしてHTTP::Responseを作る、というアプリケーションを書く時にいっつも気になるのがこのHTTP::Responseのcontentの部分って全部メモリに乗っかるということ。one linerでサクッと一個ファイルをダウンロードするくらいならいいけど、クローラーとかで永続的にプロセスが生きている場合はこのメモリがどんどんかさばってくる。というわけで、HTTP::Response::OnDisk書きました。

API的にHTTP::Responseと互換性のあるようにしたので、使う時は今まで

  use HTTP::Response;



  my $res = HTTP::Response->new(200, "OK");

  $res->add_content(...);

とかしてたところを

  use HTTP::Response::OnDisk;



  my $res = HTTP::Response::OnDisk->new(200, "OK");

  $res->add_content(...);

とするだけ。これでHTTP::Responseの中身は一時ファイルに全部格納される。先ほどCPANにアップロード。

HTML::TagClouder っての書いた。いまさらTagCloud、しかもおれおれバージョン。でも後から色々足せるように書いたつもりだから、よければ使ってみてくださいな

http://twitter.com/miyagawa/statuses/74509652

http://tinyurl.com/yw3z7v

リンク先の情報を見る限り俺も全然問題があるとは思わないけれども、このアレルギー反応の出かたにはそういったethnic jokeに対するアメリカの歴史がすでにあって、それから来てるんだろうな、と思う。元々アメリカ人はethnic jokeに関しては相当うるさいしな。

Abercrombie & FitchのTwo Wongs Can Make It Whiteはまだ記憶に新しい。一応説明しておくと、これは架空の中国人のクリーニング屋のプリントがしてあるのだが、典型的な中国人の英語の発音に癖があり、それをネタにしてる。"Two Wrongs Can't Make It Right" （すでに何か間違い／問題があって、それに対する解決策がよくないような場合に「二つの間違いを重ねても問題は直らない」）という言い回しがあり、これが中国人アクセントだとWrong→Wong （ウォンさん）、Right→Whiteで「ウォンさん二人なら（あなたの服を）白くできます」というPR文句として使われているわけだ。これを発売しはじめた直後、東海岸、西海岸の都市部で在米アジア人を中心に「発売中止にしろ」「謝罪しろ」と世論が炎上した。

Abercrombieのヤツは正直割とセンスのいいだじゃれだと思うんだけど、ポイントは「典型的な中国人の発音が悪い」という立場の元に作られたデザインである、ということだ。アメリカでは「典型」を「全体」に当てはめる事を極端に嫌う傾向がある。例えば日本では逆に典型からジョークに発展させるのは（もちろんやりかたによるけど）ちょっと小粋に見られたりするわけなのでこの温度差が現れてるんだろうな。

ちなみに上記リンクサイトの人は正直支離滅裂だと思う。

これについてはまぁ他にも色々あるんだが、とりあえずちょこっと感想。

FreeBSD, gcc 3.4.1でText::MeCabがどうしてもウマくコンパイルできない・・・う～～～む