YAPC::Asia Tokyo 2008 に行ってきた
YAPC::Asia Tokyo 2008に参加してきました。
相変わらずすごく盛り上がっていて、家族的で同窓会的な雰囲気があるすばらしいカンファレンスでした。あれほどの大規模なカンファレンスを準備して滞りなく運営した実行委員会の皆様はGJにもほどがあると思いました。
今年は3つの部屋でセッションが同時進行だったので、参加するセッション選びがすごく難しかったですが、見れなかったものは後ほどあがるであろう動画を楽しみにしたいなと思います。僕の力量不足で正直付いていけなかったセッションもたくさんあったのですが、2日間参加して印象に残ったものを書き留めておこうかなと思いたちました。今東北本線の電車内でパンフレット見ながら書いていて、まわりから怪しまれてないか心配です。
Perl Black Magic (Jose Castro)
Perlの文法規則と特殊変数、様々なtrickを使って、絶望的に読みづらいコードを書くという悪魔の講座。
s### のように置換のセパレータをわかりづらいものにかえたり、特殊変数とシンボリックリファレンス(変数名をダイナミックに決定する)を使い倒して、普通のコードを変態的なコードに解体していく過程はかなり痛快でした。もう最後の方は宇宙からの暗号みたいになっていて、セッション中に笑いも起こり盛り上がりました。
個人的には、-ne スイッチを }{ で破壊するというネタがかなりツボでした。
perl -ne (STDIN行指向処理モード)は実際には以下のように単純に置換するだけらしく、
-n assume "while (<>) { ... }" loop around program
}{ を入力することで、whileを切ることができます。
bash-3.2$ ls -1 | perl -ne 'print " - $_"'; - Desktop - Documents - Downloads - Library - Movies - Music - Pictures - Public - Sites - htdocs - packages - wallpaper - yapc bash-3.2$ bash-3.2$ bash-3.2$ ls -1 | perl -ne '}{print " - $_"'; - bash-3.2$ bash-3.2$
だからなに、といわれればもうそれまでなのですが。ほかにも面白い話がたくさんあったのですが、凄まじいスピードで進んでいったので途中理解できなかった箇所もちらほら。この辺はあとで復習して、業務に生かしていき、同僚を悶絶させたいなと思いました。
Perl Testing Basics (Daisuke Maki)
(メモ)
自分のためにテストを書こう。その方ががんばれるし、実際そうだよ。
テストは全自動じゃないと意味がないよ。黙視とかだと、漏れるし完璧に同じテストはできない。
どんなケースのテストを書くか
- 正常系
- 異常系
- 限界値(正常系と異常系の境界をテストする)
- 特殊値
Web Application のテスト
- テストの80%はwebサーバを通さずにすむはず
- データ処理を切り離そう
- モデルをテストする。APIをテストしていると考える
- UIと切り離す
Webレイヤー(フロント)のテストだと以下のようなものもある
- Catalyst だと Catalyst::Test
- mod_perl なら Apache::Test
- (Apache::TestMM の perldoc を読んでいてこの辺ちょっと聴いてませんでした)
Tips
- やりすぎない
- regression
- バグを再現コードを残す
- portablity (File::Spec, Path::Class)
- どのプラットフォームでも動くように書こう
- 環境変数を使おう
ENDブロックで後片付けをしよう
- テストで作ってデータの削除等
- テストが途中で終わっても大丈夫
- テストの最初でやってもOK
Test::MockObject が便利
テストの細かい技法というよりは、「気持ちはわかるけど、自分の身を守るためにも、テスト書いた方がいいよ」というアドバイス的な内容で且つ、やりづらいwebアプリケーションのテストをどうするかというお話でした。
webアプリケーションの開発であったとして、ちゃんと設計されていれば裏のロジックのテストをwebサーバを介さずにほとんど出来るはず、という話は本当にそうだなあと思いました。テスト書くのこれメンドクサイなあと思ったらまず自分の設計が変だったりしないかを疑ってみるべきですね。
Apache::Test はかなり面白そうなので要調査。
Parrot Compiler Tools (Kazutake Hiramatsu)
perl6実装(rakudo)が、どのような環境で開発されているかの解説。ツールを使ってプログラム言語のスケルトンを作成して、言語ルールの定義/実装をこういう風にやっていくよ、という内容でした。「オレオレ言語」の道を開く(しかもかなり大部分自動化される)画期的な内容で、途中ちょっとついていけなかったものの、ちゃんと勉強すればかなり面白そうな領域ですね。
Lets play on the perl %^H (Kazuhito Osawa (Yappo))
hinthash の使い方とスコープについての解説。dan.pm がどうやって文字列の評価に割り込んでいるのか調べたい(encoding関連?)。前にソースを読んだときどうしてこうなるのかまったくわからなかったので再挑戦しよう。
Moose (Yuval Kogman)
今大流行のムース解説。中くらいの広さの教室だったのですが、超満員でしたね。いかにみんなの関心が高いかがわかります。僕自身まったく使ったことがなかったので、朝 installして、セッション中にperldoc見ながら少しだけ書いてみました。
package TestRole; use Moose::Role; has 'test_attr' => ( is => 'rw', isa => 'Str', default => 'default string', ); package MooseTest; use Moose; with 'TestRole'; has 'name' => (is => 'rw', isa => 'Str'); has 'id' => (is => 'rw', isa => 'Int'); # "has" is same as: __PACKAGE__->meta->add_attribute( 'bar' => (is => 'rw', isa => 'Int') ); sub say_name { my ($self) =@_; print $self->name; } before 'say_name' => sub { print "my name is "; }; after 'say_name' => sub { print ".\n"; }; package main; use strict; use warnings; my $mt = MooseTest->new(); $mt->name('foo'); $mt->id(123); $mt->bar(456); print $mt->name, "\n"; print $mt->id, "\n"; print $mt->bar, "\n"; print $mt->test_attr, "\n"; $mt->say_name(); warn $mt->meta->name;
セッションを聴きながらperldocを見ながら自分で書いてみるということがいかに難しいかを痛感しました。。肝心のセッションの内容が後半ほとんど頭に入ってなかったのであとでスライド見直さないと。
Moose は Class::MOP をベースにして作られたオブジェクトフレームワークで、本格的なオブジェクト指向プログラミングをするための仕組みがいろいろと実装されているのですが、Class::Accessor の拡張として使うだけでも以下のようなすばらしいメリットがあります。
- 簡素でわかりやすい書式
- フィールド毎のread/write設定
- フィールド毎の型指定(Moose::Util::TypeConstraints)、型変換
メソッド呼び出しの前後に別の関数をフックできるのも面白いなと思いました。というか色々な仕組みがありすぎてちょっと見た感じだと全貌がわからなかったというのが正直なところですが、おもしろそうなのでいろいろいじってみたいですね。
むしろ、こうやって書き方そのものを大きく変え、言語仕様を拡張するかのようなモジュールが書けてしまう perl の柔軟さが素晴らしいなと思いました。
DBIx::Moco (Naoya Ito)
hatena で使っている O/R Mapper, DBIx::Moco の解説。全体的にやりすぎてなくて(抽象化しすぎてなくて)すごくいいなと思いました。O/R Mapper としての便利さを取りつつ、込み入った部分ではSQLを直接書けたりする大人な感じもいいなと。named place holder も便利そうで、prepare後のexecuteで配列の順番ミス、みたいな悲しい事故が防げそう。
Build Domain Specific Languages (Casey West)
Perl でDSLを作成するためのノウハウをseleniumのテスト定義を例にして解説。基本的な戦略としては、
Value Of 'form1' should be 'hoge';
みたいな文章の各単語(Value, Of, should, be)を関数定義していくのですが、「shouldn't」の実装が無理やりすぎて素晴らしいなと思いました。
package shouldn; sub t {} package main; sub It {} sub be {} It shouldn't be 'foo';
その他
聴いた全部のセッションが面白くてとても全部はかけないのですが、聞き逃したセッションも含めて、動画があがってくるのを楽しみに待ってまた見たいなと思います。スピーカーの方は皆さん輝いていて素敵でした。僕もいつかは話す側にまわれればいいなあ。来年の京都開催(?)までに実力をつけてとっておきのアイディアを暖めおこう!
あと、直接関係ないけど気になったこと
macbook大杉
とにかくmacの多いこと多いこと。かくいう僕もmacbook(白)なのですが、やっぱりmacbookが一番多かったですね。次に macbook Pro / macbook Air で、その次が thinkpad / Let's note って感じでしょうか。最近 macbook Pro が欲しくてしょうがないのですが、世界の有名hacker達がmacbook(白)を使っているのを見て、しばらくこれで行こうと思いました。
電源性能重要
3時間しか持たないのでつらかった。紙のノートにメモではスピードが追いつかないし、メモを取らないと(僕がバカなので)終わった後に何も思い出せない。
東京工業大学恵まれ杉
東急目黒線大岡山駅というちょっぴり行きにくいところにはあるのですが、都会の真ん中にもかかわらず敷地もすごく広く、緑も多くて素晴らしいキャンパスですね。広い芝生で学生だけでなく子供連れの奥様がサンドイッチを食べていたりして、いい環境だなあと思いました。