ziguzagu.org

2009 迷走 〜 2010 脱出

あけましておめでとうございます m(_ _)m

2009 年は迷走を続け不甲斐のない 1 年でした。
2010 年はその迷走から抜け出すべく頑張りたいと思っています。

具体的には....、何もないのでまだ迷走中.... orz。

WEB+DB PRESS Vol.53

通勤電車でドラクエ９はじめたら読むのをすっかり忘れてしまっていたけどようやく読み終えた。ドラクエはクリアもしたし、クリア後の世界は収集癖のない自分には若干苦痛になってきたのでもうやめる。

WEB+DB PRESS Vol.53

WEB+DB PRESS編集部

技術評論社 2009-10-24

by G-Tools , 2009/12/13

以下感想（書いていないところはほぼ読み飛ばしている可能性（短い記事以外））。

• モダン設計入門
  • JavaScript / Flash / HTML5 と、自分にとっては苦手とも言えるフロントエンド分野のお話。
  • ５章立てで、４章までは実際にコードの例があったりしてフムフムと読んでいたものの、最後の締めの第５章が純粋に「設計」だけでコードはいっさいなくビビる。ていうか、設計がテーマだからね！
  • イベントドリブンな考え方が未だちゃんと身に付いていないのでもろもろ大変参考になった。
• ヤフオク構築・運用ノウハウ
  • ヤフオクの歴史をシステム構成で振り返る。
  • 商品データを RDBMS 使わずファイルにして mmap にのせるとか（後にやめるけど）、すげーなと思った。
• 速習サーチエンジン
  • 今号のハイライト。
  • サーチエンジンに使われている技術をぎゅっとひとまとめに、読んだ後は作れる気になる（いつものこと）。
  • 非常に面白かった。なんどか後で読み直すことになるであろう。
  • 数学的な話題もおおく検索技術の世界はなんだかアカデミックで妙なあこがれを抱いてしまう。
• Developer's Perspective : Paul Graham
  • 『ハッカーと画家』とかのPaul Graham のインタビューとエッセイ１本。
  • おもろいおっさんだ。
• JavaScript 活用術 : Google API を JavaScript から活用する
  • へー。使ってみる。
• 大規模 Web サービスの裏側
  • DB 運用の実運用の話。
  • mixi では writeback 使ってるのか（最近はどこもそうなのかしらん？）
  • MySQL の設定こまかなところもなるほどなるほど。
• Practical Ruby Programming!
  • Perl モジュールの移植に挑戦するってことで、Ruby でコードを書いたことがないけどなんとなく書けるようになったきにさせてしまう、ある意味人を（自分）をだめにしてしまう記事だった....。
  • Ruby もなんとなく読めるようになりたいねぇ....。
• Recent Perl World
  • サーチエンジンのところと同じく脳内インデックスに投入。
  • 算術符号 / Range Coder / 有限文脈モデル / PPM / BWT。
  • 聞いたこともないものがほとんんどだけど「なぜ圧縮できるか？」という解説が理解を助けてくれた。

やっぱコードかかなきゃただの豚だなと思った。

CSS::Parse::Packed 0.05

CSS::Parse::Packed モジュールについて、RT 経由で、perl 5.6.2 でテストとおっとらんけん、perl のバージョンの dependencies 書いたらどうや（スーパー意訳）、と報告もらったので、5.6.2 でも（たぶん）テストとおるようになった 0.05 をリリースしました。

あと、CSS モジュールにもバージョン依存があったので（1.08 じゃないと動かない）Makefile.PL 修正したり。

もういっこどうでもいい変更として、ShipIt::Step::Twitter つかって shipit をつぶやくようにも変更してみたりしました。手間がひとつ減った。

ということで既に利用されてる人にはなんの影響もないです。

CSS::Parse::Packed 0.04

CSS::Parse::Packed モジュールについて、mi さんより warning メッセージが変、との報告をうけましたので、修正した 0.04 をリリースしました。

というか、使ってる人がいてうれしかったです （自分以外つかってるひといないであろう、とおもっていたので ;）

モジュールの紹介は旧ブログでやってたりします。どうぞよろしくです。

WEB+DB PRESS Vol.52

ようやく全部読んだ。のの感想。

WEB+DB PRESS Vol.52

WEB+DB PRESS編集部

技術評論社 2009-08-22

by G-Tools , 2009/09/30

• 特集１「Java プログラミングの慣習」
  • Perl だとこうだな、JavaScript だとこうだなとあてはめつつさらりと斜め読み。
• 特集２「Vim の流儀」
  • 華麗にスキップ。
  • だれか Emacs の流儀を。
• 特集３「SSD 投入 DB基本解剖」
  • これが大変よかった、本当に。
  • SSD には SLC/MLC ２種類あるというのも初めて知ったし（汗）、RDBMS ので使われる基本的な構造とアルゴリズムについての解説、そしてそれが SSD 上でうごくことになるとどうなるか、のところもろもろ理解が深まった（気になっている）。
  • ３回読み直してかなりお腹いっぱいに。
• 「マルチコア時代の並列処理アルゴリズム」
  • これもあつかった。
  • 並列処理の基本構成・概念・考え方なんかの基礎知識は、これである程度抑えられた気になっている（コードが書けるわけではない）。
• 「テラスケールのデータベース運用〜設計編」
  • mixi での仕事のやり方が垣間見えたり
  • memcached + MySQL でバランスをとるところ（なんでもかんでも memcached にのせる訳ではない）とか、対角スケールの話が激しくためになった。
• 「データ圧縮アルゴリズムの基本」
  • さらさらと。
  • 正直アルゴリズム本体についての理解はできてないけど、コレ使うとなにができるとかのポインタはたてたので心の隅に。
  • memcached に入れるときも圧縮できるものは圧縮するとメモリ節約になるかな、とか妄想。
• WebKit
  • 面白そう
  • 前回、前々回あたりを読み直そう。
  • HTML パーサーの部分だけ引っこ抜いて、いろいろ難しいところもある（？）libxml と同じようにつかえないかな、と妄想。

なんか久々しっかり読んだいい号だった。

Exporter を継承しつつ import を override するとき

Exporter を継承しているクラスで import を override するには、親（Exporter） の import を呼んであげないといけないんだけど、その呼び出し方がひと味違うらしい。

export_to_level を呼び出してやる。引数の意味は以下のとおり。

export_to_level($where_to_export, $package, @what_to_export)

ようは caller 呼び出すんですな。でも、そもそもこんなケースは特殊のような気がするので、

export_to_level(1, @_)

という決まり文句でぼんやり覚えておくことにする。

そもそもこれにたどり着いたきっかけは、テストコード用のユーティリティ集めた Utility パッケージ書いてて、テストコード本体のほうにもろもろ use を毎回閣の面倒だから sub import で import したれ、とおもって書いたところ、@EXPORT で export してた関数が Undefined subroutine になってしまったというところでした。

YAPC::Asia 2009 特別研修 - DBIx::Class と MySQL による Perl アプリのスケーリング

YAPC::Asia 2009 最終章。

特別研修 Moose 入門に引き続き、『DBIX::ClassとMySQLによるPerlアプリケーションのスケーリング術』に参加してきた。

上のページにはいくつかトピックスが書いてあるけど、大まかには３部構成（具体的にタイトルがついていたわけじゃないけど）。

つかみ

おもむろに「みなさん前に出てきてください」といって、タロットカードみたいな大きめトランプをだし、数字探しゲーム（自己紹介もなし！）。

まずは 1 人 vs 3 人で、ホワイトボードに書かれた 5 つの数字を探す。3 人チームは、 30 秒程度で全部探しあて、1人チーム（？）は、1 分 30 秒かかってようやく完了。

続いてふたたび別の数字を 5 つホワイトボードに書いて、その４人に指令。「カードをどんなルールでもいいから 30 秒（だったかな？）で並べなさい。」ちょっと相談して、その４人チームは数字ごとにまとまりを作ることに。まだそろいきってはいないものの、ほぼまとまったあたりで時間終了。

で、探し始めるのかと思いきや、ホワイトボードに書いた数字を消す！？「はい仕様変更です。いままでのは忘れてください。ビジネスにはよくあることです、はっはっは（だいぶ意訳）」と言って、カード並べを見ていた４人に指令（僕こっち）。「これから数字５つを書きますので、目をつぶってください。Go といったら数字を確認してカードを探してください。」さらさらさら。

「Go Go Go !! 」（ジョジョじゃないよ）

あたふたしつつも、あらかた並んでたのでなんとか 20 秒くらいで捜査完了。

そんなこんなで、ようやく着席。そして質問。

「この結果からわかることをあげてください」

• 1人より複数のほうが速い
• 同じ人数でも、あらかじめ並んだものから探す方が速い

「そのとおり。これは、データベースも一緒です。」

こんな幕開け そしてようやく自己紹介と今日の簡単なアジェンダ紹介

まずは 前半に知識、後半はテーブルごとに（今回は３つ）前半で覚えたことを生かして簡単なアプリを作る、という２部構成。

知識

まずは参加者に、スケーラビリティを確保するためにいままでやったことと、そしてそのときに起きた問題を聞かせてくださいと質問。で、やったこととして、でてきたのが、

• レプリケーション
• キャッシング
• パーティショニング

うむ。みんなわかってるよねってことで、小休憩を挟んでここから怒涛のレクチャー。メモ垂れ流し。

• MySQL のストレージエンジンについて
  • MyISAM
    • トランザクションなし、行レベルロックできない
    • Readonly もしくはほとんどが Read なものであれば速い
  • InnoDB
    • これ以外の選択肢はあまり考えたことがない
• Replication (MySQL)
  • Master - Slave
    • DBIC でサポートしているの使える
    • そんなに難しくない
  • Multi Master
    • DBIC ではサポートしていない
• Profiling
  • DBIx::Class::QueryLog 使ってパフォーマンス計測
  • export DBIC_TRACE=1 を使って実際に発行される SQL とか確認
• ResultSet
  • Query の発行をできる限り抑える
  • fetch したやつはすべてオブジェクトつくっちゃう
    • HashRefInflator 使おう
  • colum でとってくるカラムをしぼれる
    • join とあわせて使うと、場合によっては大量の query を発行してしまう可能性がある
    • 代わりに prefetch を使う
  • join か prefetch か
    • 常に prefetch を使えばいいというものではない
    • prefetch は "データ" が欲しいときのみ
• primary key
  • auto increment はデーターベース単位なのでスケールしない
  • UUID を使おう（UUID でかすぎと思う場合は YUID がいいよ、という 6A プロダクト宣伝しとけばよかったか。）
• job queue
  • schwartz / gearman だね
  • job queue として EC2 とかのクラウドを使うっていうのはいいね
• CDN
  • client の接続速度のばらつきを吸収してくれる
  • 同時接続数をおさえることができる
• 使えるツール紹介
  • ab
  • mytop
  • nagios
• CPAN モジュール紹介
  • Catalyst::Model::DBIC::Schema の
    • Catalyst::TraitFor::Model::DBIC::Schema::Caching
    • Catalyst::TraitFor::Model::DBIC::Schema::Replicated
  • MySQL::Sandbox
  • Test::DBIx::Class

DB のスケールに特化した講義というよりは、Web アプリ自体をスケールするという話もあったり。『DBIx::Class をつかった』という部分は実は決して多くはなかったので、ちょと想定してきたイメージと違った。とはいえ DBIC ででき（う）ることがわかったのと、知らないモジュールも使い方もでてきて勉強になった。

あとモジュールなるべく最新版をこまめにバージョンアップして使うことをおすすめしていた。Query の最適化具合とかが結構違うとか。Catalyst も 5.8 で使うのがおすすめとのこと。（Moose）の Traits でモジュール指定する（+ちょっと設定）だけでもろもろ使えるのがらくちん、とのこと。

実践

3 つのグループにわけてテーマを決めてアプリ作り。各グループで、

• Replication
• Caching
• Job queue

から最低どれか 1 つの技術を選んだ後、DBIx::Class の機能のうち

• HashRefInf
• Prefetch
• QueryLog（だったかな）

のどれかを混ぜつつなにがしかのアプリを作ること。

僕のグループでは、Caching つかって microblog つくることに。DBIC でつかうのは...、なんだったっけ...（汗）。結果的にはアプリ自体は未完成でしたが（なぜか僕の環境でキャッシュがうまく機能してくれない）、指定方法含め DBIC の知識いくつかを得ることはできたのでよかったです。作業的にはだんとつで僕が足引っ張ってました...。

他のグループでは、

• フォームから入力された内容を、job queue を使ってメール配信
• Replication つかってのなにか（自分のことばかり気にしていてメモしてない...）

というものを作っていました。メール配信のは完成されていたようですばらしす。Replication チームは、MySQL::Sandbox をつかっての Master / Slave 環境を整えるのに一苦労でアプリの開発までは行けなかったようだけど、その苦労はそれはそれで楽しそうではあったかな。僕も今度やってみよっと。

まとめ

正直なところをいえばもすこし具体的な所の話は欲しかったかなと。Job Queue にしても、TheSchwartz がいいよ、とはいったもののコード的な説明はいっさいなかったり、POD での説明だけで終わったモジュールも結構あったので。アプリ作りするには、ちょっと知識のほうの前ふりがよわかったかなと。とはいえ、DBIC に関して教えてもらえたことは知らない内容ばかりだったのでとても勉強にった。

あと、その日たまたま同じテーブルについたひとと、突然チーム開発をはじめるっていうのはいい経験だった（自分のへたれ具合を再確認できた、という意味でも）。

そして、今回の参加者は Moose 入門よりさらにすくない 8 名...。うーむ、残念。

YAPC::Asia 2009 終了！

以上で、研修も今年の YAPC::Asia も終了。カンファレンスはもちろんだけども、今回の研修には本当に満足。自分のレベルにあた研修があったら参加しとくべきだなと。まぁ、毎回今回のようなクオリティの研修が行われるとは限らないけれども、金銭的なところだけでさけて通るにはとても惜しいなぁと思いますた。

やぁ、よかった、よかった。

YAPC::Asia 2009 特別研修 - Moose 入門

先週末の YAPC::Asia 2009 のカンファレンスに引き続き、特別研修『Moose入門、モダーンなオブジェクト指向システム』に参加してきた。

研修の内容は、Moose とはなんぞやから始まり、以下（だいたい）7 部構成の入門講座。

1. Moose Concepts : コンセプト
   • ざっと機能一通りみてみる
   • なぜ Moose なのか
2. Classes : Class の基礎から使い方
   • Moose::Object が何持ってるかとか
   • BUIDLARGS, extends, override, super の使い方
   • Moose 使ったあとの後始末 (no Moose;)
3. Role : Role の基礎から使いかた
   • Role の持つ意味
   • 使い方
   • alias で衝突回避
4. Basic Attributes : Attribute いろいろ
   • required, default/builder, lazy, clearer, predicate の使い方、使い道
   • init_arg
   • attribute の継承してみたり
   • accessor を変更してみたり
5. Method Modifires : Method Modifire いろいろ
   • before / after / around の使い方、使い道
   • Role での使いかた
   • augment / inner の使い方、使い道（あんまりないよ＞＜）
6. Types : 型制約
   • Built-in Type たち
   • 自分で subtype 作る
   • shortcuts (class_type/role_type/duck_type/enum)とか、anonymous subtype とか
   • corecion のあれこれ
   • MooseX たち
7. Advanced Attributes : もっと Attribute
   • Weak References と weak_ref => 1
   • Triggers
   • Delegation / Native Delegation
   • Traits / MetaClasses
8. おまけ
   • 有用な MooseX たちが Task::Moose のってるよ
   • MooseX::Declare
   • Extension 書くのはむずいよ

ただ解説があるだけじゃなくて、各パートごとにエクササイズが用意されていて（テストコードと、やること書いてある POD）、

• 説明きいて、考えて、質問して
• フレッシュな記憶のうちにごりごり考えながらエクササイズ
  • ちょっと実装して
  • prove
  • 直す、次の実装する
  • 以上を、すべてのテストがパスするまで繰り返し

という進め方。

はっきりいって、大充実の内容でした。１日中ずっと集中してた。解説もわかりやすかったし、エクササイズもテストコードが用意されていたおかげで、確認しながら進めれたのでとてもスムーズ。

Moose は、去年ひととおりチュートリアルやっただけで（しかも中途半端に）、それ以降は使うこともなく...。それが最近 Catalyst が 5.8 になったりで、アレがアレしたりで、またやらねばと思ってたところにちょうどこの研修の開催を知って、なんにも考えずに飛びついたけど（お金ないんだけど...）、大正解だった。

どうかんがえても、今日の内容は週末ちまちま勉強してるだけじゃ１日ではこなせない内容。自分で POD 見ながら try and error で使い方を見つけていく、身につけていく方法はそれはそれでためになるけど、多少のお金をはらって短時間で凝縮して、変な苦労なくスムーズに学習できるとしたら、そんなラッキーなことはないかな、と。

残念ながら参加者は 11 名とちょっと寂しい状況ではあったけど、たぶん参加者は全員大満足のうちに帰ったはず。ジャンプスタートの機会を手にした数少ない人間なので。ちゃんと復習やって、妄想してないで、作るもん作っていこう。

JPA++

YAPC::Asia 2009

YAPC::Asia 2009 に行ってきた。

聞いたセッションの中でやっぱり興味を引かれたのは非同期モノ x 3。

• Asynchronous programming with AnyEvent : miyagawa さん
• Asynchronous Programming for (A)synchronous Communication : mala さん
• Concurrent DB access with Perl : tokhuirom さん

若干自分の理解にまだ不安があるものの、使えそうなところで使っていこう。

あと、この mala さんのセッションに加え、

• PSGI / Plack (miyagawa さん、tokuhirom さん）
• Building a desktop app with HTTP::Engine, SQLite and jQuery : miyagawa さん

の３つのセッションは、未来を作ろうとしてる感があって印象的だった。 すごいなぁ、と関心しているばかりではいけないんだけども...。

その他には、

• Catalyst な話がいろいろ聞けてよかった。
• perl-completion.el / antything-projects.el 使う。
• Perlbal、MogileFS とかって単語がぽろぽろ聞こえてきたりして、意外と普通に使われてるんだなぁ。
• なんのかんので Moose だ。
• WAF 作ってみたいなぁ。あ、TypeCast か。

とかとか。

最後に大いなる反省点。

2日間朝から終わりまでずーっといたにも関わらず、面識のある数名と挨拶程度の会話をしたのみ...。ひたすらセッションを聞き、こうしたらあれに使えるかなぁとか妄想を繰り返し、休憩時間は紹介されたモジュールの POD 読んだり、ソース眺めたり...。だめだなぁ、人見知り...。

とはいえ、僕なりに本当に楽しい２日間でした。

スタッフの皆様おつかれさまでした。 あ、まだ来週の研修ありますね。

僕は、Moose と DBIx::Class のやつに参加申し込みしています。これも楽しみ。 （DBIx::Class はずいぶんとさわってないので少し予習しておこう...）

まだまだ YAPC 気分。

DDLockd 使ってみた

複数サーバーで同時実行される可能性のあるスクリプトの排他制御を実装するのに、DDLockd をつかってはどうかというアイデアをいただいたので、DDLockd について調べてみた（なんかロックするやつ、ぐらいのことしかしらなかった）。

DDLockd とは

Danga Distributed Lock Daemon の略で、まさに今回やろうとしていた複数サーバーで実行されるアプリの排他制御を行うための仕組み、みたいなのを提供してくれる daemon。Perl で書かれている。Danga の名前が指し示すとおり LiveJournal で使われている（た？）。TypePad でもほんのりつかっていたり。

コードはこのあたりにおちていた。

• http://code.sixapart.com/svn/ddlockd/
• http://code.livejournal.org/svn/ddlockd/

今回は code.sixapart.com の trunk の r46 を使ってみた。

server のインストール

daemon も Perl で書かれてる。trunk/server/ddlockd をもってきてどっか適当におく。とりあえず今回は $HOME/bin においた。依存してる CPAN モジュールは Danga::Socket くらい。

client のインストール

trunk/api/perl に一式はいっているので、svn からとってきたらおきまりの、

% perl Makefile.PL
% make
% make test
% sudo make install

でインストール。t/01_all.t のテストが localhost で daemon が動いているの前提になっているので、インストール前に、

% ddlockd --daemon

で、起動しておく。もしくは test 無視して install。Perl 以外の client モジュールはいまのところナッシング。

server 起動

起動自体は、さっきの、

% ddlockd --daemon

で、7002 番ポートを listen するやつが起動する。port オプションでお好みの port に変更可。 type オプションでロック情報をどこで持つかというのが設定できたりで、以下3つがつかえるぽい。

• internal
  • daemon プロセスのメモリ。デフォルト。
• dlmfs
  • ファイル。/dlm/ddlockd ってディレクトリに lock 名でファイルを作って管理する。
  • 実際にはここに作られるファイルがサーバー間でシェアされる必要があるのでNFSな領域とかになるかな。
• dbi
  • データベース。
  • hostname でDBサバ名を指定。ただ実際には localhost しかみていない...orz。とはいっても指定しないとエラーになる。
  • DBI->connet('dbi:mysql:dbname=sixalock', ...) と書かれているので、MySQL に "sixalock" という DB を作っとく必要がる。いやなら変更してしまう。
  • table オプションでテーブル名を指定する必要がある。
  • スキーマは定義ファイルはないけど、コードを見る限り "name" っていう 文字列型のカラムが１こあるテーブルがひとつあればいいぽい。要ユニークインデックス。

ちなむと、TypePad ではデフォルトの internal で使ってた。一番無難と思われる（LJ は知らない...）。

使い方

クライアントのほうの使い方は SYNOPSIS どおり。こんなんで確認した。

#!/usr/bin/env perl
use strict;
use warnings;
use DDLockClient ();

my $client = DDLockClient->new(servers => [ 'localhost:7002' ]);

my $Lock = $client->trylock('lock-test')
    or die "Failed to lock";
while (1) {
    print time."\n";
    sleep 5;
}

DESTROY {
    $Lock && $Lock->release;
};

telnet でいじる

memcached のように text な protocol なので telnet コマンドでもいろいろ確認できる。使えるコマンドは以下のとおり。

• status - 状態もろもろ表示
• load - よくわからん
• trylock - 指定文字列で lock を作る
• releaselock - 指定文字列の lock を解放
• locks - 保持している lock を表示（dlmfs の場合は実装がなくて使えない）

daemon を internal type で起動、先のクライアントをずっと動かしてる状態でひととおりやってみた。

% telnet localhost 7002
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
status
STATUS: OK
SUCCESSES: 13
FAILURES: 4
RUNTIME: 2987
LOAD: 1

load
LOAD: 0

locks
LOCKS:
  lock-test = Client::Internal(R): open to 127.0.0.1:48757

trylock lock=foo
OK

locks
LOCKS:
  foo = Client::Internal(R): open to 127.0.0.1:40654
  lock-test = Client::Internal(R): open to 127.0.0.1:48757

releaselock lock=foo
OK

locks
LOCKS:
  lock-test = Client::Internal(R): open to 127.0.0.1:48757

ふむ。

まとめ

ざっとさわってみて、daemontools で ddlockd を動かしておけば結構安心して使えそうな気がする。ddlockd 突然死でロックがきえるというのは "dlmfs" or "dbi" type で起動しとけば防げる。ただ、この場合ロックファイル or ロックレコードがのこったままになるので、そいつらをいったん消してあげないといけない、という問題がある。これを防ぐには client 側でがんばるしかなく、release でエラったら成功するまでひたすらがんばるとかしないといけない（ほかなんかいい方法あるかな？）。まぁこれは ddlockd 使わなくてもファイル使った排他制御やるなら同じことがいえる（はず）。

多くの daemon なプログラムが採用している .pid ファイル使った多重起動防止な仕組みの複数サバ対応版としての役割としては必要十分かなと。LJ/TypePad で長らく使ってるって実績もあるし。とかとか、いろいろ考えたりもしたけれど、結局 memcached でできちゃうのよね、多重起動防止なら...。

とりあえず今回はすでに memcached が動いてる/使える環境なので、そっちを使う方向でｗ 結局すでにあった実装を再利用できる形にした（NAS 上に File::NFSLock でロックファイルつくる）。