2008年09月

2008年09月30日

昨今の経済状況を鑑みるに

昨今の金融業界の大再編はまったくもって興味深い。価格高騰だなんだとも相まって景気が悪いような話ばかりがニュースで報じられているが、実際のところどうなんだろ。楽観的すぎると言えばそうかもしれないけど、俺は正直あんまりこれから経済が破滅的な状況にはならないだろうと思っている。

それどころか、アメリカの政権交代、2000年以降辣腕をふるってきた数々の企業の破綻、これらはなにかのパワーバランスが少しずつ変化していってるようで、逆に今ならおもしろい事ができるんじゃないだろうか。

まだ日銭は受注開発で持っている弊社endeworksだからクライアントさん達がこれからこの余波を受けてどうなっていくのかは正直不安の元であるけれども、色々な課題があがってくるにしろこれから4，5年は俺もendeworksも退屈しないだろうな、という予感がしてならない。正直ちょっぴりわくわくしている。

2008年09月28日

芋煮が恋しい

芋煮を食いたいです。10月中にそんなイベントねぇかなぁ・・・

2008年09月28日

現実逃避気味に備忘録

朝は9時すぎに起きて、近所のパン屋濱田屋へ。パンを買って、スターバックスへ。コーヒーを買って（本当はいけないんだろうが）目立たないように濱田屋のパンを食べながら新聞なんぞ読んでブランチ。今日は朝から天気がイマイチなので通りの人も少なくて、人間観察には向かない。

その足でハナマサで買い物。掃除。

昨日Buffallo Airstation WZR2-G300Nを購入。今日設定したのだが、なんか無線がぶちぶち切れる。なんとなくなんだが、さっき設定している時はちゃんとつながっていたところを見ると置いてある位置が悪いのじゃないかと思い始めている。今は本棚の下から2段目（ベッドと同じくらいの高さ）の一番端に置いてあるんだが、もう少し全体から見通しの良い本棚の一番上とかに置くべきなんかな。

とある仕事で普段使わない部分の脳を使って集中しなくてはいけないのと、物欲の神様が降りてきたのでaudio-technicaのノイズキャンセリングヘッドホンも昨日購入。ちなみにこいつは全額ポイントで買ったぜ。正直音の質だけで言ったら他のヘッドホンでもよかったんだが、ノイズキャンセリングの機能と、重さ、値段、それらのバランスでどうしてもこれが良かったのだ。今も聞きながら作業中。

で、仕事から現実逃避中。

はぁ、寒くなってきたなぁ。

2008年09月26日

プログラミングにおける英語作文的要素

プログラミングは作文に近いと思うのです。プログラムを書いている時に築いているロジックというのは、「まずこのデータをこっちにおいて、その後これに3.14をかけて、2倍にして、それを標準出力にプリント」みたいな感じで、情緒はないだけであとはまるっきり作文しているのと一緒なわけです。

でもって、作文と一緒で色んな書き方で同じ事に到達できる。さっきのは円の円周を求める式だけど、答えを出すだけなら、こういう説明の仕方もできる：「一時変数に3.14を格納後２倍にし、一変数にさらに引数としてもってきたデータを乗算し、しかるのちに標準出力に出力する」。まぁこの程度のロジックならほぼどんな書き方をしても理解できるよね。

面倒くさくなるのはオブジェクトとかがでてきたり、プログラムの流れそのものがあんまりストレートじゃなくなってきた時。これがプログラミング言語が基本的に英語を基本としているということとも絡まって、なかなか上手に作文ができなくなってくる。

学校に言ってた頃の授業で、英語嫌いでした？

そうかもしれないね。でも、プログラマになっちゃったからしょうがないね。英語、最低限でいいから、覚えよう！そして自然な文章を書くようにロジックを組むことを心がけよう！

で、多分手続き型の処理を書くときはそれほど問題じゃないと思うのです。難しいのはオブジェクト。で、これが絶対だってわけでもないけど、俺が気をつけている「ここだけは要チェック」というチェックシートを書き出してみたいと思う：

1. オブジェクトは常に S - V - O

オブジェクトは常に主語(Subject)、メソッドが動詞(Verb)、そして引数が目的語(Object)としてとらえてみてください。公文式の国語をやっていた人には簡単だね！☆

2. 目的語が必然の場合も、動詞名に加える

例えば、オブジェクトの内部を変換(convert)するメソッドを書いていて、そのメソッドが変換するする対象は１種類しかないので、引数を求めるのは面倒だった、と仮定しよう。このメソッド、なんと命名しますか？例えば...

$object->convert;

これは悪い例。なぜかは、普通に文章として読んだ場合の事を考えてください。これだけだと「変換した」しかわからない。あなたが英語が得意じゃないとして、ただでさえ読みにくい英語ベースのプログラムを読み直すときに、これでバグを見つけられますか？

こういう場合もちゃんとメソッド名に書く！

$object->convert_to_floating_point();

ほら、これなら「浮動小数点に変換」ってわかるじゃない！

3. 助詞を抜かさない

2で書いた

$object->covert_to_floating_point();

ですが、これも助詞がなければなんのこっちゃわからなくなります。

$object->covert_floating_point(); # "to"を抜かした

これを日本語で書くと「浮動小数点変換」。でもそれだけだと助詞がないから「浮動小数点」と「変換」の関係性がわからない。

それって浮動小数点「から」？それとも「に」？それとも、これって、浮動小数点「を」使ってなにか変換する？

今まで見てきたソースコードの中で日本人が最もこの罠に陥りやすいと思う。というか、ラテン語ベースの言語はみんな助詞がもっと明示的な物だと認識してると思うんだよね。日本語はそのあたりが曖昧。

というわけでどんなに自明に思えても、助詞込みで書くのがおすすめ

  $object->convert_to_floating_point();  # 小数点「へ」
  $object->convert_from_floating_point(); # 小数点「から」
  $object->convert_with_floating_point(); # 小数点「で」 

とりあえず時間がないのでこれまで！

2008年09月26日

Cache::Memcached::Fast != libmemcached

違うよ、全然違うよ

http://d.hatena.ne.jp/a666666/20080926/1222368070

Cache::Memcached::Fast が libmemcached を利用した Perl のクライアントライブラリ

Memcached::libmemcached が、libmemcachedのPerlバインディング。Cache::Memcached::libmemcachedは、Memcached::libmemcachedの、Cache::Memcached互換インターフェース。

Cache::Memcached::FastはXSに直接自前のmemcache クライアントを実装してる。

環境に合えば、一番単純性能が速いのはlibmemcached。FastのほうがPerl向けにチューニングされたりしてるし、API的には多分一番親切。パフォーマンス的な差は10~20%libmemcachedクライアントのほうが速い。

2008年09月23日

野村がリーマンの一部を買収ですか

野村證券がリーマンブラザーズのヨーロッパ部門とアジア部門を買収の方向ということで。是非これまでアメリカに搾り取られていた分の利益を日本にも還元していただきたいものです。

ところで2004年、日本に帰ってきて、ライブドアに就職しました。僕がライブドアを退社し、その１年後ほどで例のお祭りがありました。その後リーマンブラザーズ証券会社に就職しました。そして今回のお祭りです。

なんかあるんですか、僕の行く先々には。

というか、きっと立地条件に何かあるんだよ。墓地かなんかたってなかったの＞六本木ヒルズ

2008年09月22日

File::Tempの使い方

元ネタはこちらから

File::Tempオブジェクトはファイルハンドルであり、同時にoverloadを使用すると文字列に見える、という妙なオブジェクトなんですね。なので、以下のコードは無用

  my $expect = 'hogehoge';
  my $out =  File::Temp->new;
  diag $out;
  open my $fh, '>', $out;  # ここ
  print $fh $expect;
  close $fh;

  my $contents < io $out;
  is $contents, $expect;

File::Temp->new()した段階ですでにFileHandleオブジェクトになっているはう。なのでこいつに直接書き込んじゃうのが吉

  my $expect = 'hogehoge';
  my $out =  File::Temp->new;
  diag $out;
  print $out $expect;
  close $out;

  my $contents < io $out;
  is $contents, $expect;

で、undefined云々はどういうことかというと、File::Tempの問題というよりは受け手のIO::Allの問題。io $outってやると、$outはGLOBなので、ハンドルとして認識してしまうのです。でもclose $outしてるからハンドルはすでに使えないわけで・・・

それだけの問題なので、ここの直し方は簡単。$outを無理矢理文字列にしてしまえばOK

  my $contents < io "$out";
  is $contents, $expect;

そしてさらに、テンポラリファイルがたまってしまうなら、UNLINKオプションをつけちゃいましょう

my $out = File::Temp->new( UNLINK => 1);

このUNLINKオプションをつけておけば、File::Tempオブジェクトがスコープ外に達したときに自動的に一時ファイルが削除されます。closeしても平気だけど、スコープ外にでちゃうと操作できないのでそこだけ要注意

2008年09月10日

IOCだDIだ

mstがcatalystについてのインタビューで次期CatalystでMooseだけじゃなくてIoC (Inversion of Control) とか (DI) Dependency Injectionとか使うような事を言っているよ！

IoCとかDIってJava界隈ではよく聞くけど、Perl界ではあまり聞かない。自分がちゃんと人に説明できるようにするついでにメモ：

まず、IoC はほぼDIと同じ物。なんか時々細かい差を強調する人もいるが、一般的には同じでOK。あと、この二つのコンセプトは別に新しくない。少なくともCatalystを使ったことのある人ならすぐ分かるはず。例えば、以下のよく見るコード：

my $model = $c->model('Hoge');

Catalystが先に'Hoge'というモデルを作成し、保存（Inject)しておいてくれたおかげで、上記のように我々はアプリケーション内のどこからでもHogeというモデルに名前だけアクセスすることができる。これがなかったらどうなるかというと、ただ単純に自分でそのモデルを作成することになる：

my $model = MyApp::Model::Hoge->new();

これはこれでいいけど、同じモデルを使い回したい場合にはあちこちで毎回同じような事をする必要がある。それだと「つか、このコンポーネントは一回作って、あとは使い回したいんだよ！」って時にいらいらしますね。

DIはそのようなアプリケーション内で使うコンポーネント及びその依存関係を別途先に作る事を指す。Catalystの場合は、MyApp->setup()段階でこのコンポーネント作成が行われ、アプリケーション内部ではその初期化等をほぼ気にすることなくすぐに使えるわけだ。だからCatalystにおいてはCatalystフレームワークそのものがDIの役目を担っている。

DIだけだと先に作るだけで、実際に使う時になんかパッケージ変数とかでその値にアクセスしなくてはいけなくなる。こんなイメージ：

   package MyApp;
   our $MyApp::HOGE_MODEL = MyApp::Model::Hoge->new();

   package MyApp::Whatever;
   sub foo {
       my $model = $MyApp::HOGE_MODEL;
   }

それは汚いし危険なので、コンポーネントの呼び出し用にService Locatorというのを使うわけです。Catalystだと$c->model()とかがそれに近いわけです。

これで一通りの仕組みができあがり。っていうか、こういう仕組み、わざわざ名前をつけないでも使ってる人は多いんじゃないか。この夏かかりっきりだったプロジェクトも実はこっそりそういう機能が入ってたしね。

ちなみにPerlだとBread::Boardとかがそれに使えそうです。

IOCだDIだ名前にとらわれすぎずに、より自分が楽できる方向に向けてアプリケーションを作ればいいと思う今日この頃でした。

2008年09月07日

ブラジリアンな週末

金曜日は定期的にやっているスタッフ＆それぞれの相方を交えた食事会。今回も強い要望により表参道のBarbacoaでシュラスコと相成りました。今回初参戦の33rpmは相変わらずよく食います。33rpmに飯を奢るときは食い放題以外はやばいという認識をより強くもったのであります。

それはともあれ、この日のBarbacoaはちょっと肉の回転がよろしくなかった。Coracaoが全然頼んでもこねぇ。業を煮やした僕は土曜、日曜のブラジリアンフェスティバルに期待をかけることにしたのです。

土曜日はとりあえずのそのそと起き出して（理由：前の晩シュラスコの後一人で結構飲んだから）、ちょっぴり遅めのランチを代々木八幡のダージリンで。その足でテオブロマを偵察して、別項で書いたミレー展に。そしてその後代々木公園でやっていたブラジリアンフェスティバルへ。

そしたらまあ規模は小さいものの、結構混み合っている。かなり列も長いし・・・。絶対ブラジル風にだらだらと接客しているからだと思う。人は多かったけどそこまでじゃなかったもの。まぁ、ともあれ、インド料理も食べててそんなにおなか減ってないので、この日は退散。秋刀魚を買って帰った。

そして日曜、今度はフェスティバルの開始時間11時に到着！やった！列が短い！ってことでPastel de Queijo/Carne、Coxinha、Coracaozinhos、それにFeijoadaを堪能。この手のもの、本当毎日食べてたのでまさにソウルフード。感涙に噎びつつ、堪能しました。あ、飲み物はもちろんGuaranaです。Feijoadaとか、本当日本で言うご飯と味噌汁と漬け物みたいな、3種の神器なわけですよ。最高です。金曜のリベンジでcoracaoもしっかり食いました。正直Barbacoaの焼きすぎのヤツよりうまかった・・・・（ちなみにですが、coracao = 鶏のハツは、ブラジル風にやるなら、ビールと塩胡椒でつけ込んでから焼くとおいしくできます）

会場にはかわいいブラジル娘もいっぱいいたのでその辺りも堪能させていただきました。

アメリカは別にいいけど、ブラジルは帰りたいなぁ。仕事だと俺のポルトガル語では支障があるので、できれば仕事じゃなくて2，3ヶ月ぼーっとリオデジャネイロで過ごしたい。

はー、ブラジルいいなぁ、ブラジル。

2008年09月07日

ジョン・エヴァレット・ミレー

http://upload.wikimedia.org/wikipedia/commons/0/08/Sir_John_Everett_Millais_003.jpg

Bunkamuraでミレー展をやってるので行ってきた。

オフィーリアの絵はちょっと知ってたけど、ミレーって名前を聞いて完全に「落穂拾い」の人かと勘違いしてた。行く前にちゃんと調べておいてよかったよ。

個人的にはオフィーリアより、アナマリアの絵のほうが好きだったんだけど、ネット上には画像がぱっと見落ちてなかった。エロくて良い絵です。

2008年09月05日

株式会社endeworksになりました

9/5で正式に登記が受理されたので株式会社endeworksになりました。

でもまだサイトとか全部有限のままです。そのうち変えてもらいます！

2008年09月02日

memcachedになにをキャッシュするのか

激遅なレスポンスなんだけど、dormandのmemcached記事。

dormando - Should you cache?

この中でキャッシュの使い方でよく見る間違った使い方を指摘している部分があって、ここがとても重要だと思うので書いておく

Where would you think to add caching to this system? I hope I've made it too obvious.

(システムのどこにキャッシュ機能を追加するべきだろう？）

At the query layer!

Use a database abstraction class and have it memcache resultset objects and...

No no no, that's a lie. I'm lying. Don't do that.

(DBクエリーのレイヤーだ！

DB抽象化クラスを使って、memcachedに結果のオブジェクトをキャッシュして・・・

いやいやいや、ごめん、今のは嘘。それはしないでくれ）

これ、自分を含めキャッシュを使い始めようとしている人たちがまず犯す間違いだと思うんだ。俺もやったよ。やっぱりやりたくなるよね。

Do it inside that $user object.

At the highest level possible.

Take the whole object state and shovel it somewhere.

That object is its own biggest authority.

It knows when it's been updated, when it needs to load data, and when to write to the database.

It might've had to read from several tables or load dependent objects based on what you ask it to do.

(ユーザーオブジェクトのレベルでやるんだ。

最も外側のレベルでやるんだ。

オブジェクトの全体の状態をどかにキャッシュしてしまうんだ。

オブジェクト自身が自分の事を一番よくわかっている。

自分がいつ更新されたのか知っているし、いつデータが読み出されたのか知っているし、いつデータベースに書かれるべきなのか知っている。

ひとつのオブジェクトを作成するのに複数テーブルから読み込む必要があるかもしれないし、他のオ依存しているブジェクトを呼び出したりするかもしれないしね）

そういうことです。シンプルなシステムならいざ知らず、memcached を使うようなシステムではキャッシュ対象となるオブジェクトはDBのテーブル（もしくはそのオブジェクトの保存元）と1対1とは限らず、色々な依存関係が存在する。これをあまりmicro-managementすると、今度は逆にキャッシュ管理が複雑になりすぎてしまう。

例えば、$userオブジェクトが三つの部品でできていて、それぞれの部品をDBから読み込み、それぞれの部品のレイヤーでキャッシュしているとする。この場合$userオブジェクト本体はキャッシュする？したいよね。でもすると全体のオブジェクト$userがキャッシュされている間に部品Aがキャッシュから消されていたら？ん、どっちを取るの？いつ取るの？どうやってその状況をわかるの？とかとか。

それくらいだったら、細かい部品のキャッシュはとりあえず忘れて、$userというオブジェクト全体のレベルでキャッシュすればよいのだ。これなら、$user全体がキャッシュされているかどうかだけ。簡単だね！

<% for ( var i = 0; i < 7; i++ ) { %> <% } %>

<%= wdays[i] %>

<% for ( var i = 0; i < cal.length; i++ ) { %> <% for ( var j = 0; j < cal[i].length; j++) { %> <% } %> <% } %>

0) { %> id="calendar-4346346-day-<%= cal[i][j]%>"<% } %>><%= cal[i][j] %>

D-7 <altijd in beweging>

Day to day life of a Perl/Go/C/C++/whatever hacker. May include anything from tech, food, and family.