nipotan method RSSフィード

|

2008-01-28

SoozyConference #4 が終って  SoozyConference #4 が終って - nipotan method を含むブックマーク はてなブックマーク -  SoozyConference #4 が終って - nipotan method  SoozyConference #4 が終って - nipotan method のブックマークコメント

503 Service Temporarily Unavailable

■ 参加資格

TKSK, Yappo, kazeburo, tokuhirom, ingy, Jobs, kan, otsune, amachang のうち誰かとワンホップでつながっていて、誰かが身元を保証できる人。または amachang に恐いといわれたことがある人。あるいは自分は一流のエンジニアだと胸をはっていえる人。

またはSledgeもしくはMofedgeを利用した実務経験のある方。または Encode-JP-Mobile のコミッタの方。

または手島屋社員ではない方。

手品がプロ級の方。もしくは未踏(ユース)経験者。

この参加資格には、実はひどいバグがあって、事実上


「手島屋社員ではない方」


のたったひとことで済んでしまう。

つまり手島屋という会社の社員ではない限り、ほぼ無条件に参加出来たということだ。


ちなみに、恐らく意図したところは手島屋ではなく、手嶋屋だと思われる。

なので、手嶋屋の社員も実質 OK である。

2008-01-11

Becky! のフィルタルール  Becky! のフィルタルール - nipotan method を含むブックマーク はてなブックマーク -  Becky! のフィルタルール - nipotan method  Becky! のフィルタルール - nipotan method のブックマークコメント

そういえばどこにも書いてなかった。


だいぶ昔に、初めてマック (鈴木じゃないほう) を買って、調子コいて「Windows 捨てだな!」とかホザいてた青い時期 (遠い目) があったんだけど、Windows で最も重宝していた Becky! Internet Mail から、マック (グリドルじゃないほう) 使うなら結局他の MUA に移行せざるをえない状況になってしまって、まぁ、大概の MUA は mbox 形式にエクスポートしたらインポート出来るんだけど、フィルタのルールってどれも MUA の独自実装になってて、まず移行出来ないじゃんすか


で、別の MUA に移行するために、まず MUA 別にフィルタルールを解析して…とかやらなきゃいけないんだけどさ、結局 MUA によっては「この機能はこっちにもあるけど、この機能はこっちにもない」とかそんなんばっかりで、現実味がない。


そもそも、それを Perl で利用可能なデータ構造にしにくいし、そもそもフォーマットがないわけだし…とか色々考えたら完全に作る気が失せたんだけど、うちの会社ってメールが異常に多いから、フィルタかけて、振り分けしてとかいっぱいやってて、イチイチ Becky ひらいて同じルールを追加すんのが面倒くさかったから、


nipotanさんのツイート: "Becky! の振り分けルールを perl で parse したいな"


とかつぶやいた後に、結局 parser を書くかなって気になったの。


Parse::Becky::FilteringRules

use strict;
use Parse::Becky::FilteringRules;
use Data::Dumper;

my $bk = Parse::Becky::FilteringRules->new; # $bk is not Batara!
$bk->parse('/Becky!/your_name/xxxxxxxx.mb/IFilter.def');
warn Dumper $bk;

こんなんしたらわかると思う。


ただ、これもホント、思い付きも思い付き。

and 条件の構造とかどうしたらいいかわかんなくて、すごく適当な構造 & 実装。

depth とかなくてもよろしくやってくれるほうがいいかもね。

as_string() の時につらいけど。


まぁ、Twitter での発言から add するまでの時間見てもらえばわかるけど、ものすごい勢いで思い付きをそれっぽい形にするとこまで書いただけ (これをやるのが一番重要だと思う) だから、データ構造とかがぶっちゃけイケてない。

いけてないのはわかってる。で、どうしたらいいのかなーとか思ったから、CodeRepos にうpしたんだよね。


かつてマック (Freddie じゃないほう) にスイッチした時の自分のように、parse したい!移行したい!って人がもしいたら、もうちょっと拡張していきたい (共通のデータ構造考えたり、他の MUA 用のパーサ書いたり) とこだね。


アクセサとか共通化して、別 MUA の parser に $bk の構造とか渡して as_string() するだけで、それ用のルールになっちゃうとか。


考えただけで興奮する。

2007-10-22

食べログRailsCNET 食べログと Rails と CNET と - nipotan method を含むブックマーク はてなブックマーク -  食べログと Rails と CNET と - nipotan method  食べログと Rails と CNET と - nipotan method のブックマークコメント

食べログRails 移行が完了したようです。

Rails で運営されているサイトとしては国内最大級。

http://b.hatena.ne.jp/entry/http://japan.cnet.com/news/ent/story/0,2000056022,20353871,00.htm

よく見ればわかるように、今日ニュースなのに 8/1 にエラい勢いでブクマされている。

ブクマページ見ればわかるけど、元記事は

カカクコム8月1日、運営する飲食店情報共有サイト食べログ」のバックエンドシステムを刷新した。

だったんだけど、今日このニュースを見ると

カカクコム10月22日、運営する飲食店情報共有サイト食べログ」のバックエンドシステムを刷新した。

と、日付部分がかわってる。


自分の記憶では


8/1 に Rails 移行メンテ開始

とりあえず Rails にしましたプレスリリース

移行してみたら、やっぱなんか問題があってメンテ続行

CNETフライング気味に Rails 移行しました記事掲載

8/1 11:50 頃にメンテ終了

おや?Rails 版になったの?とヘッダを見てみる

Server: Microsoft-IIS/6.0

おい切り戻してんじゃん的な状態で ASP 版継続

多分、CNET に「記事さげてくれ」的な話をして

中の人ががんばる

再度 CNET誤爆されないように 10/19 にコッソリ Rails 移行

10/22 に実は Rails に移行してましたよ的ネタばらし

CNET が、同じ permalink差し替え記事を公開する嫌がらせ


サービスの開発速度向上などで定評のあるプログラミング言語Ruby」を全面採用。大規模サイトでのRuby導入はこれまで、サイトの動作処理速度に問題があるとする見方もあったが、国内外における近年の導入事例を受け、処理速度に大きな問題は発生しないと判断した。

Ruby の導入なんか問題視されてたのか?

言語自体の処理速度云々での影響なんてたかが知れてるだろうし、速度が問題視されるような言語ではないと思うんだけど。

サイト規模から考えて Rails の導入は問題視されたりすることはありそうだろうけどね。

2007-10-16

Data::ObjectDriver を使ってみて  Data::ObjectDriver を使ってみて - nipotan method を含むブックマーク はてなブックマーク -  Data::ObjectDriver を使ってみて - nipotan method  Data::ObjectDriver を使ってみて - nipotan method のブックマークコメント

最近 DBIC 人気に、ひどく翳りがあるし、Changes に名前が書かれていたりとかもあるので、とりあえず Data::ObjectDriver をちゃんと使ってみようかなと思った。

最初チョロっと使ってみた感想は、作られたインスタンス最近のゴテゴテした ORM と違ってかなり軽量。

あと、無駄にコネクションを作らない。

そういう点では非常に高速なイメージ


ただ、使い慣れてないうちに使うにはデメリットも目立つ。


一つは、ドキュメントが無さすぎること。


perldoc も熟読してみたが、使い熟すレベルまでのドキュメントは充実していない。

当然、コード嫁って話なわけだが、なかなか膨大なのと、透過的に他のクラスのメソッドを更に他のクラスから呼べるように proxy してたりするので、実装が異なる同名のメソッドが多くて混乱しがち。

一通り追ってはみたが、なかなか結構混乱する。

ついでに、色々とネットで調べても、少なくとも日本語情報はまず見付からない上に、英語情報もあまり見付からない。


二つめは、master + slave 構成を作るのが面倒な気がする。


Data::ObjectDriver::Driver::DBI に、rw_handle() と r_handle() という、読み書き用、読み用のハンドル (dbh) を返すメソッドが存在して、処理内容に応じて適宜ハンドルを選択している風なんだが、デフォルトでは r_handle() は rw_handle() のリファレンスになっている。

slave 用に自分で r_handle() を override して実装しなくてはいけない模様なんだが、r_handle() の実装方法が実に困難 (素の DBI->connect() で作ったハンドラを返せばいいっぽいが正しいかわからないw) なのと、slave が複数台数の場合に、どうラウンドロビンさせるかを考えた時に、r_handle() から slave の datasource の情報を複数使って返すメソッドを定義したりして、そういうアクセサを追加した俺様 Driver::DBI を作らないといけないっぽい。


三つめは、Driver::Cache::Memcached とかを使って、memcached と透過的に (気にすることなく) object を取ったり出来るんだけど、expire されないから、テーブルを直にいじったりすると戻せなくなったり (まぁ、それは自前で実装してもそうだけど)、なんか変な拍子で cache だけ残ったりするんじゃないかと不安になる。


四つめは、どうもパーティショニングしている構成 (PRIMARY KEY が親キーと別の値の複合キー) におけるクラスで、PRIMARY KEY の親キーじゃないほうに auto_increment 属性をつけておいて、INSERT した時 ($obj->save() した時)、採番された値 (mysql_insertid とか) を取ってきた後に、親キーのほうを上書いてしまう問題があるっぽい。

package Bar;

use strict;
use Data::ObjectDriver::Driver::Cache::Memcached;
use Cache::Memcached;
use base qw( Data::ObjectDriver::BaseObject );

__PACKAGE__->install_properties({
    columns     => [qw(id foo_id bar timestamp)],
    datasource  => 'bar',
    primary_key => ['foo_id', 'id'],
    driver      => Data::ObjectDriver::Driver::Cache::Memcached->new(
        cache    => Cache::Memcached->new({servers => ['127.0.0.1:11211']}),
        fallback => Data::ObjectDriver::Driver::SimplePartition->new(
            using => 'Foo',
        ),
    ),
});

1;

これの id が auto_increment になっている。

ちなみに、Driver::SimplePartition を使っているので、Foo クラスが抽象化している foo テーブルには、partition_id というカラムがあり、その値を元にパーティションされた datasource を取ってきて driver を返すようにしている。

package main;

use strict;
use Foo;
use Bar;

my $foo = Foo->lookup(801);
my $bar = Bar->new(
    foo_id => $foo->foo_id,
    bar    => 'jitensya',
);
$bar->save;
warn $bar->id;

こうやると、$bar->id は undef になってしまう。

そのかわり、$bar->foo_id に auto_increment で採番された id の値が入ってしまう。

この例で言えば、希望としては、$bar->foo_id は 801 を返し、id が採番された値を返して欲しい。


Driver::DBI では、一応、これでいいのか的にコメントが書いてあるので、バグになりうる可能性自体は認識されている様子?

        my $pk = $obj->primary_key_tuple; ## but do that only for relation that aren't PK-less
        my $id_col = $pk->[0]; # XXX are we sure we will always use '0' ?
        my $id = $dbd->fetch_id(ref($obj), $dbh, $sth);
        $obj->$id_col($id);

でも、Driver::SimplePartition のドキュメントには、

Your primary key should be a complex primary key (arrayref) with the simple key of the parent object for the first field.

と書いてあって、実際にその通りにしないと、Driver::SimplePartition の中で

my $col = $class->primary_key_tuple->[0];

こうやって PRIMARY KEY の最初のキーが親 (パーティショニングの大元になる情報) としているから、順序を変えると driver が取れなくなってしまう。


このように要求と実装が矛盾しているような状態で、ここで言えば、そもそも $pk->[0] のカラムに auto_increment の 値を入れてしまうのは間違いなんじゃないかと思ってしまう。


じゃあ、パーティショニングしている側では save() した時に都度上書けばいいだろ的な BK しか思い浮かばない。



ということで、Data::ObjectDriver はデフォルトではあまり使い勝手はよくなく、すごく時間がかかりそうです。

というか、何にしてもノウハウの蓄積が欲しいとこです。

2007-10-12

MML  MML - nipotan method を含むブックマーク はてなブックマーク -  MML - nipotan method  MML - nipotan method のブックマークコメント

適当に。


というか、こんなの流行るんかな。

一応 wikipedia とか、他の人が書いてるやつとか見て、シンタックスを覚えて途中まで手で打ち込んでみたけど、途中でテスト出来なかったりするし、とにかく面倒くさすぎるね。



t100l16 @3 o5
d8e8f+8g8a8b-8 bbbrbrb4g8 <e4.e-4.e4.r>gab<cd
e4.e-4f8e2. d4.c+4.d4.r>gab<cc+
d4.>g4<f8e2. g4.g4.g4.g8ar8g
f4.f4.f4.f8gr8fe4.>a8b8<f8eee8.>bc4.
;

t100l16 @3 o5
r8c+8c8>b8<c8c+8 dddrerf4. g4.f+4.g4.r4.
g4.f+4b8g2. f4.e4.f4.r4.
f4.r4b8g2.<e4.d4.c+4.c+4.
d4.c+4.c4.>b4.g4.f8g8b8 bbb8.fe4.
;

t100l16 @3 o4
r1 grg4. <c8>gr<cr>b8grbr <c8>gr<cr>err4
<c8>gr<cr>b8grr8<c8>gr<cr>ergr<cg d8>grbr<c+8>f+rb-r<d8>grbrbrr4
<d8>grbrb8grr8<c8>gr<cr>>gr<gr<dg<c8>gr<er>b8gr<dr>b-8gr<c+rc+8r8e8
r8>ar<frr8>ar<fr r8>ar<fr>b8r8<fr >c8>gr<er>g8g8g8<fff8r>b<c4.
;

secondlifesecondlife2007/10/12 20:30http://svn.coderepos.org/share/lang/javascript/jsmml/trunk/examples/textarea_play.html
使って作ると楽かも。MML のフォーマット自体は打ちやすく無いからねぇ…。SMF で MIDI なファイル作ってコンバートして適当に調整が楽かも。

secondlifesecondlife2007/10/12 20:45http://d.hatena.ne.jp/Untouchable/20071012/1192187270
こんな便利なのも!しらなかった!

nipotannipotan2007/10/13 20:20なるほど。色々ツールがあるのかぁ。
普通に手で書いちゃった。。

|