はえええええええええええええええええええ。はえええええええ。はええええええええ！

ジーザス。速い。PowerBookが古代の遺物に見える。

Mさん、ありがとうです。

http://lists.sourceforge.jp/mailman/archives/ludia-users/2007-April/000040.html

なんてタイムリー。

AI::Categorizerで日本語を読み込んでみたら全然動かなかったので30分Hack。以下をAI::Categorizer::Documentが読み込まれた後に読み込むと一応動く。３０分hackなのであまり信用しないように。

package AI::Categorizer::Document;

use strict;

use warnings;

use Text::MeCab;



sub tokenize_ascii {

  my $self = shift;

  my @tokens;

  while ($_[0] =~ /([-\w]+)/g) {

    my $word = lc $1;

    next unless $word =~ /[a-z]/;

    $word =~ s/^[^a-z]+//;  # Trim leading non-alpha characters (helps with ordinals)

    push @tokens, $word;

  }

  return \@tokens;

}



sub tokenize

{

    my $self = shift;

    if ($_[0] =~ /[\P{ASCII}]/) {

        my @ret;

        my $mecab = Text::MeCab->new();

        for(my $node = $mecab->parse($_[0]); $node; $node = $node->next) {

            push @ret, $node->surface;

        }

        return \@ret;

    } else {

        return $self->tokenize_ascii(@_);

    }

}



1;

知り合いのサイトを見てて、いちいち内容に関係ないコメントがつくのを見てて正直気持ち悪い。つきまといはこわいぞぉ。

QN.N。朝：無し。昼：魚力のサバ味噌定食。おやつ：シフォンケーキ。夜：和布蕪と刺身にサントリースーパーブルーx１

魚力は実は結構久しぶり・・・

下のエントリのCatalyst Modelでホゲホゲしてたら、HTML::FormFuの生成時間が気になってきた。レンダリングと同じくらい時間がかかりやがるので、これをキャッシュしたらいいんじゃね？と

  my $form = $cache->get($form_file);

  if (! $form) {

    $form = HTML::FormFu->new( ... args ... ); # <- ここはちょっと注意必要

    $form->populate( get_config($form_file);

    $cache->set($form_file, $form);

  }

  $form->process( $c->request );

  return $form;

こうすると同じHTML::FormFuオブジェクトでprocessをリクエスト毎に呼んで、効率的。生成時間は俺の開発サーバーで約４分の１。Micro optimizationかもしれんけど、ついでだったので色々変更してみた。

これが落ち着いたら、HTML::FormFuのMLでCatalyst::Model::FormFuを本格的に提案してみようっと。

あ、ちなみに昨日も今日もLudiaのインデックスがぶっ壊れました。今の段階では正直意味不明。デバッグもできん・・・

皆CatalystのModelってどう使ってるんだろう？最近今まで結構Controllerに入れてたロジックをModelに移行しつつあるんだけど、Modelって

  $c->model('Hoge')->some_method(@args);

と

  $c->forward('Model::Hoge', 'some_method', \@args);

と二つ呼び方があるじゃないですか。ずっと前者を使ってたんだけど、$c->forward()の使い方がようやくわかってきたので全部$c->forward('Model::Hoge')にしようかと思ってコード書いてみたら、$c->forward()の時だと引数に$cが入ってきて、いままで動いてたコードがいきなりぶっ壊れたりするわけですよ。

これってただ好みの問題かな。引数が変わってくるのめちゃくちゃむかつくんだけどなぁ・・・ちなみにforward()使おうと思った理由は

.----------------------------------------------------------------+-----------.

| Action                                                         | Time      |

+----------------------------------------------------------------+-----------+

| /admin/area/begin                                              | 0.032550s |

| /admin/area/load_area                                          | 0.104095s |

|  -> Hoge::Model::Area->find                                    | 0.006322s |

|  -> /admin/area/not_found                                      | 0.000128s |

| /admin/area/end                                                | 0.001169s |

|  -> /admin/area/render                                         | 0.000317s |

'----------------------------------------------------------------+-----------'

こういうのが見れるから。Chainedディスパッチャーとforwardをうまく使うとControllerのデバッグがすげぇ楽なのでModelでも使いたいんだけど・・・

朝：VIRONのパテ・ド・カンパーニュのサンドイッチ、昼：ねばたまうどん（中）、夜：塩ラーメン（ただし６割サイズの小）。お酒。

エレビッツ

• 出版社/メーカー: コナミデジタルエンタテインメント


• 発売日: 2006/12/02


• メディア: Video Game

すこーしずつ進めていたElebits、やっとストーリーモードをクリアしました。ストーリーモードをクリアすると「称号」が与えられるのですが、俺の場合は「破壊王」でした。どこのプロレスラーやねん。

最初、なんでデコードとパフォーマンスが関係あるねん、とすごい考え込んでしまったが、俺らへのリンクは話の枕だったのね。おれがDISられたのかと思って憤慨したエントリ書くところだった。

http://blog.livedoor.jp/dankogai/archives/50816853.html

POEは確かにLWP::UserAgentに比べたら明らかにメモリ食います。１リクエストを発行するだけのためにPOEを立ち上げるためのプログラミングと時間／リソースのオーバーヘッドを考えると単純なGETを比較的遅めの間隔で行うのにはあまりおすすめできません。

POEやDanga::Socketのような非同期なフレームワークを使い始める真のメリットは多分１）半永久的に２）大量のURLを３）同時に 処理しつづける、という条件が揃ってる時だと思います。この点、POEとかは単純な"scraper"にはそれほど向いてない。あちこちのURLを取りに行く"crawler"ならいける。

あ、ちなみにGunghoはKeepAliveを効率よく使います。まぁPOEがkeepaliveに対応してるからなんだけど。

  my $keepalive = POE::Component::Client::Keepalive->new(%$keepalive_config);

  ...

  POE::Component::Client::HTTP->spawn(

    Agent             => "Gungho/$Gungho::VERSION",

    %$client_config,

    Alias             => &UserAgentAlias,

    ConnectionManager => $keepalive,

  );

なんか知らんけど昨日帰り際にふと気づいたらキャッシュカードがないでやんの。ということで今日は朝から銀行に行った。通帳記入を見る限り別に誰かに使われた形跡もないので、多分ATMに食われたか、俺の部屋の片隅の目に届かないところで眠っているんだろう。ちっ。

ところでカードを再発行してもらおうと思ったのに印鑑を持ち歩く習慣がないため、今日はできず・・・明日にもちこし。

朝：ご飯、納豆、和布蕪。昼：姫竹蕎麦。夜：ビール、シェリー、カルバドスとアサリのオイル煮と小さめの黒パン

今日は朝飯食ってる暇がないな・・・ってことで行ってきます。

SennaのPostgreSQL組み込み用ライブラリのLudia。こいつ、かなり速いし好きなんだけどひとつ問題が。毎日更新のある某DBにこれを突っ込んでおいたところ、毎日インデックスがぶっ壊れる。例えばほんの１０分前まで動いていた、１個だけエントリーを抽出できてたSELECT文が急になにも返さなくなる。すると全部の全文検索を含むSELECT文が動かなくなるのです。今はまぁ一般公開してないからほぼ毎日のようにpsql -f rebuild_index.sqlってのを走らせてるのだけれども、常駐しているWebアプリがキャッシュされているステートメントハンドルを持っている場合は、同じインデックスを使ったクエリを発行しようとしてCan't locate relation with OID XXXXとか言われてしまうのでそのプロセスも止めないといけない。DBが落ちる訳ではないので微妙なんだよなぁ。

tracをちゃんと動かそうと思って色々やった結果、認証をちゃんと動かすためには今までのサーバー構成では駄目だと分かってApacheとおさらばする事にしました。今までは何個かレガシーなmod_proxy + mod_perlなアプリケーションが有ったのだけれども、Catalystベースの開発に移行してからはFastCGIが気持ちよくなってしまってめっきりmod_perlのアプリがなくなって行ったのです。で、そんなこんなしてる間にtracの件がでてきたのでもうApacheいいや、と。

というわけで移行。とりあえずまだ使ってみた事なかったから、というだけの理由でApache2.2を入れて（ここらへんが我ながら無駄）、lighttpdで作業している間に「ただいまメンテナンス中」を表示しておいてもらって、その間にlighttpdをポート9000で動かしつつ動作確認。最初は全然なんだかわからんかったけど、とにかくうごくようになったところで問題勃発。FastCGIとベーシック認証を一緒に動かすと止まる。なんじゃこりゃ。

もう書き方が悪いのかと思ってこれで２時間はまった。ところが正しい答えは単純：

  server.modules = (

      mod_fastcgi

      mod_auth

  )

は駄目で、

  server.modules = (

      mod_auth

      mod_fastcgi

  )

にすればいいだけの事。あとはちょこちょこやったら動いた。あー、疲れた。

追記：SVNだけはApache必要だったーーーーー。2.2でmod_dav_svnをバックエンドにして、lighttpdをフロントにしてみたよ。

おお、毎度ありがとうございます。

http://labs.cybozu.co.jp/blog/kazuho/archives/2007/04/poco_patch.php

Devel::StackTrace をprereqに足したくないので、以下のようにしてとりこませてもらいます！

  use constant SKIP_DECODE_CONTENT 

  BEGIN

  {

    if (SKIP_DECODE_CONTENT) {

      eval <<'        EOCODE';

        no warnings 'redefine';

        sub HTTP::Response::decoded_content {

          my ($self, %opt) = @_;

          my $caller = (caller(2))[3];

          if ($caller eq 'POE::Component::Client::HTTP::Request::return_response') {

            $opt{charset} = 'none';

          }

          $self->SUPER::decoded_content(%opt);

        }

      EOCODE

    }

  }

rev 63でいただきました。

前回書いた、Gunghoのアーキテクチャの変更について。

http://d.hatena.ne.jp/lestrrat/20070421#1177116589

Gungho->newは全面廃止、いきなりGungho->run($config)とかでオッケーにした。Componentはこれ以降Gungho本体がオブジェクトではなく、ただのクラスであることを分かりつつコードを書く必要がある、ということにします。

rev 64で変更済み。

おつまみ―お酒に合う料理478品

• 作者: 柴田書店


• 出版社/メーカー: 柴田書店


• 発売日: 2007/02


• メディア: 大型本

先週末買ったので時々眺めてます。