2014-12-19 リファレンスの使い方とかの話


これは Perl 入学式 Advent Calendar の 19日目の記事です。

こんにちは。東京のPerl入学式でサポーターをしている@tsucchiです。

昨日は papix さんのPerl入学式の歴史 〜その3 2013年〜でした。「ただいま作成中」しか書いてない気がしますが、 きっと気のせいでしょう。

本日は毛色を変えて、リファレンスの話をしようかと思います。

はじめに

さてさて、Perl入学式では第3回から「リファレンス」の使い方を学習しています。リファレンスは最大の山場の一つで、かくいう僕もきちんと理解して使える様になるまでには 結構時間がかかった記憶があります。校長も「難しい!」「たくさん書いて慣れるしかない!」と、良く言ってますよね。

リファレンスの文法的なものは、Perl 入学式のスライドや、入門書をご覧いただくとして、 ここでは「リファレンスって何に使うの?なんでリファレンスを使うと嬉しいの?」みたいな話をしようと思います。

リファレンスの使い道

リファレンスの使い道は大きく分けて 3 つくらいだと僕は考えています。

  1. 複数の配列を関数やメソッドに渡す
  2. 複雑なデータ構造を作る
  3. 関数やメソッドで引数を更新する

このうち、最初の1つだけは Perl 固有の事情で、残りは他の言語でも当てはまるリファレンス(やポインタなどの参照系のデータ構造)に当てはまる特長です。 では順番に見ていきましょう。

複数の配列をサブルーチンに渡す

サブルーチンをちゃんと作れるようになったぶつかる難問(?)の一つが、「複数の配列を引数にとるサブルーチン」です。たとえば、下記みたいな、「二つの配列を引数にとり、配列の中身が同じかどうかを 比較するサブルーチン: is_same_array()」を作るとします。

Perl の引数の制約がなければ(あるいは知らなければ)こういう風に書きたい(書いちゃう)ですよね?

# @array1 と @array2 が同じなら真を返す
sub is_same_array {
    my (@array1, @array2) = @_;
    ...
}

ですが、これはうまく動きません。たとえば、下記のようなコードを書いたとすると...

my @a1 = (1, 2, 3);
my @a2 = (1, 2, 3);
if ( is_same_array(@a1, @a2) ) {
    print "配列の中身は同じ\n";
}
else {
    print "配列の中身は違う\n";
}

「配列の中身は違う」の方が出力されるはずです。 Perl のサブルーチンの引数は配列として取り扱うため、is_same_array の第一引数@array1(1, 2, 3, 1, 2, 3)のように2つの配列をくっつけた値が入ってしまうのです。

こういう場合は配列リファレンスを渡すようにします。

# $array_ref1 と $array_ref2 が同じなら真を返す
sub is_same_array {
    my ($array_ref1, $array_ref2) = @_;
    ...
}
my @a1 = (1, 2, 3);
my @a2 = (1, 2, 3);
if ( is_same_array(\@a1, \@a2) ) { # 配列ではなく、配列リファレンスを渡す
    print "配列の中身は同じ\n";
}
else {
    print "配列の中身は違う\n";
}

今度は「配列の中身は同じ」が出力されるはずです。(is_same_arrayをちゃんと実装すれば)

複雑なデータ構造を作る

複雑なデータ構造を作るために、リファレンスはよく使われています。

Perl入学式のスライドでは2次元配列を例に説明しているので、 ここでは別の例を出してみましょう。

下記みたいなデータがあるとします。DB とか CSV とか Excel とか HTML のテーブルとかでよく見る構造ですよね?

id name age
1 Sherlock Shellingford 15
2 Nero Yuzurizaki 15
3 Hercule Barton 16
4 Cordelia Glauca 17

このデータの1行分はどういうデータ構造をつかうのが自然でしょうか?配列でもいいですが、ハッシュの方がわかりやすいので、ハッシュがいいですね。

こんな感じです。

my %row = (
    id   => 1,
    name => 'Sherlock Shellingford',
    age  => 15,
);
print $row{name}; # => Sherlock Shellingford

では、このデータ全部は、どのような構造がいいでしょうか?「配列で中身がハッシュ」(?)

配列は配列、ハッシュはハッシュなので、そのまま共存させることはできません。

ここで必要になってくるのがリファレンスです。ハッシュリファレンスであれば、配列に入れることができます。こんな感じです。

my @rows = (
    {
        id   => 1,
        name => 'Sherlock Shellingford',
        age  => 15,
    },
    {
        id   => 2,
        name => 'Nero Yuzurizaki',
        age  => 15,
    },
    {
        id   => 3,
        name => 'Hercule Barton',
        age  => 16,
    },
    {
        id   => 4,
        name => 'Cordelia Glauca',
        age  => 17,
    },
);
print $row[0]->{name}; # => Sherlock Shellingford

このように、配列の中にハッシュが入っているような構造や、配列の中に配列が入っているような構造や、ハッシュの中に配列が入るような構造を 作りたい場合にリファレンスを使います。(もっと複雑なのも作れますが、あまり複雑すぎるのも良くないので、よく考えて使いましょうね!)

関数やメソッドで引数を更新する

たとえば以下のような配列があるとします。

my @people = (
    'tsucchi',
    'xtetsuji',
    'papix',
    'ytnobody',
    ...
);

で、この配列の中身をすべて小文字->大文字に変換する、to_upper_items という関数を作りたいとします。

sub to_upper_items {
    my (@array) = @_;
    for my $item ( @array ) {
        $item = uc($item);
    }
}
to_upper_items(@people); #これで中身が全部大文字になってほしいけどNG

これはうまく動きません。関数でなければ大丈夫ですが、関数だとダメなのです。なぜかというと、関数の引数は渡ってきた値をコピーします。なので、関数に渡した @people と 関数内で使っている @array はコピーされた別物なのです。これは、関数内で不用意に書き換えるミスを防げるので一般的には望ましいことなのですが、今作りたい関数にとっては 都合が悪いです。

この場合もリファレンスを使います。リファレンスはコピーされるのはアドレスなので、関数内の実体は渡したものと同じになります。(この辺の仕組みはリファレンスをちゃんと理解しないと ピンとこないと思いますが...)

sub to_upper_items {
    my ($array_ref) = @_;
    for my $item ( @{ $array_ref } ) {
        $item = uc($item);
    }
}
to_upper_items(\@people); #リファレンスを渡せば大丈夫

このようにリファレンスを渡すと、配列の中身を書き換えることができます。これはPerl入学式のスライドでは、 「リファレンスのはまりどころ」として紹介しているのですが、意図してやりたい場合もありますよ、というお話でした。

まとめ

他にもリファレンスの便利な使用例はいくつかあるのかもしれませんが、ぱっと思いついたものを書いてみました。リファレンスは慣れるまではなかなか大変なのですが、便利なもの であることは間違いないので、使いこなせるようになるといいですね!

明日は akms さんです。お楽しみに!



2014-12-07 hachioji.pm #45 に行ってきた


昨日 12/6 は hachioji.pm #45でした。

Docker が辛い話とか、Java の話とか、例外(?)の話とか色々してた感じですね。

僕は最近割と普通な開発しかしてなくて、休日も最近はあまり時間が取れなかったこともあって、金曜の夜から慌てて モジュール書いてその話をしました。(あといつも通り全力でミルキィホームズを宣伝)

Teng::Plugin::OtogiriPluginBridge という、Otogiri のプラグインを Teng で使えるようにする邪悪なモジュールです。ネタっぽい感じではありますが、半分マジで作っているものです。Otogiri はコアが小さいので、全部のメソッドを Teng と コンパチにしてもそれほど負担にならなそうなので、やってみた感じです。スライドにも書きましたが、inflate/deflate 周りは全然確認してない上、実装がめっちゃ雑なので、 多分バグっているのでは、と思います。

用途としては、開発環境とかで、(必要に応じて Reply と組み合わせたりして)、TableInfo とか DeleteCascade とか組み合わせて便利環境にしたり、 ちょっとしたデータを作ったり消したりするときに、Otogiri のプラグインを雑に使いたい、みたいなのを想定しています。(本気で使うなら、ちゃんと移植したほうが 多分いいと思うので)。

何気に、はちぴーは今年最後だったのかな?(年末に予定が合えばもう一回あったりする?)一年も早いものだ。



2014-11-02 僕の perlbrew の使い方の話


僕の perlbrew の使い方の話。だいたいネットのあちこちに載ってる話なのだけど、まとめてみた

そもそもなぜ perlbrew を使っているか

OS に付いてくる Perl (System Perl) をそのまま使うのはあまり良くない、と言われているってのと、最新版とか、特定のバージョンを使いたい場合があるためです。

plenv ではなく、perlbrew なのはどうして?

基本的には lib を使いたいから。plenv もプラグイン入れると lib 使えるっぽいので、乗り換えても良いのかもだけど、めんどくさい。

perlbrew のインストールとか

ぐぐれば出てくるし、公式にも普通にのってるので、頑張って!(頑張らなくても大丈夫なはずですが)

perlbrew lib

perlbrew は lib という便利な機能があって、モジュールを入れるディレクトリを lib ごとに切り替えることができます。

こんな感じの機能です。まじ便利。

tsucchi@surreal[505]$ perlbrew lib --help

Usage: perlbrew lib <action> <name> [<name> <name> ...]

    perlbrew lib list
    perlbrew lib create nobita
    perlbrew lib create perl-5.14.2@nobita

    perlbrew use perl-5.14.2@nobita
    perlbrew lib delete perl-5.12.3@nobita shizuka

便利なのですが、がっつり使っているわけではなくて、割と単純な指針でやっています。

  • default という lib を作って、モジュールは基本そこに入れる
  • 最初に入れた perl 自体にはモジュールを入れない(し、入れられないようにする)

まず、欲しいバージョンの Perl をインストールして、default という lib を作ります。 install では --as を使って、メジャーバージョンを固定しておくのがポイントかな。 lib に必要なモジュールをインストールしていきます。

tsucchi@surreal[506]$ perlbrew install perl-5.20.1 --as perl-5.20
...
tsucchi@surreal[507]$ perlbrew lib create perl-5.20@default
tsucchi@surreal[508]$ perlbrew switch perl-5.20@default
tsucchi@surreal[509]$ cpanm iroiro-na-module

あとは、うっかり素の Perl (lib じゃない方)にモジュールを入れないように、ファイルシステムレベルでロックをかけるようにしています。 (perlbrew lib では ~/.perlbrew 以下にモジュールが入るので問題無い)

Linux の場合

tsucchi@surreal[510]$ cd perl5/perlbrew/perls/
tsucchi@surreal[511]$ sudo chattr +i -R perl-5.20

Mac の場合

tsucchi@surreal[510]$ cd perl5/perlbrew/perls/
tsucchi@surreal[511]$ sudo chflags -R uchg perl-5.20

マイナーバージョンアップ

Perl はマイナーバージョンアップ(5.20.0 -> 5.20.1 みたいな)の場合、バイナリレベルの互換性が保証されているので、モジュールを入れ直したりする必要はありません。 perlbrew に upgrade-perl というコマンドがあるので、これを使っています。

前述のように、素の Perl にはファイルシステムレベルのロックをかけているので、バージョンアップ時にはこれを外しています。(で、終わったら戻す)

Linux の場合

tsucchi@surreal[510]$ cd perl5/perlbrew/perls/
tsucchi@surreal[511]$ sudo chattr -i -R perl-5.20
tsucchi@surreal[512]$ perlbrew use perl-5.20
tsucchi@surreal[513]$ perlbrew upgrade-perl
...
tsucchi@surreal[514]$ sudo chattr +i -R perl-5.20

Mac の場合

tsucchi@surreal[510]$ cd perl5/perlbrew/perls/
tsucchi@surreal[511]$ sudo chflags -R nouchg perl-5.20
tsucchi@surreal[512]$ perlbrew use perl-5.20
tsucchi@surreal[513]$ perlbrew upgrade-perl
...
tsucchi@surreal[514]$ sudo chflags -R uchg perl-5.20

メジャーバージョンアップ

メジャーバージョンアップというか、新しいメジャーバージョンが出た場合は、基本的には新規インストールと同じです。 旧バージョンから、入れてるモジュールをリストアップして、新バージョンに移行したりしています。

5.18 -> 5.20 にあげる例だとこんな感じ。

tsucchi@surreal[512]$ perlbrew use perl-5.18
tsucchi@surreal[513]$ perlbrew list-modules > /tmp/modules.txt
tsucchi@surreal[514]$ vi /tmp/modules.txt
...
...(もう使ってないモジュールを消したりとか)
...
tsucchi@surreal[515]$ perlbrew install perl-5.20.1 --as perl-5.20
...
tsucchi@surreal[516]$ cd perl5/perlbrew/perls/
tsucchi@surreal[517]$ sudo chflags -R uchg perl-5.20
tsucchi@surreal[518]$ perlbrew lib create perl-5.20@default
tsucchi@surreal[519]$ perlbrew switch perl-5.20@default
tsucchi@surreal[520]$ cpanm < /tmp/modules.txt

list-module を使って新しい Perl にモジュールを移行するのはワンライナーでかっちょよくやるのも可能なのですが、 僕は変なモジュール使ってないか確認したりしてるので、上記のような愚直な感じにしています。

素の Perl を残しておくのはなんで?

あんまりないのだけど、あるモジュールが壊れてインストールできなくなったりした場合に、検証する場合とかに、モジュールが全く入ってないPerlがあると早いんですね。 (依存関係がぶっ壊れてる場合の調査とか)。こういう時は、test って lib を作って調査します。

tsucchi@surreal[512]$ perlbrew lib create perl-5.20@test
tsucchi@surreal[513]$ perlbrew use perl-5.20@test
tsucchi@surreal[514]$ cpanm nanka-hennna-module
...
...(ログとかエラーメッセージを見て調査)
...

終わったら lib を戻して、消しています。

tsucchi@surreal[515]$ perlbrew use perl-5.20@default
tsucchi@surreal[516]$ perlbrew lib delete perl-5.20@test

参考にしたサイト

いろいろあるけど、下記は読んだことないなら一読しておくと良いと思います。

以上、他にも色々ある気もするのだけど、とりあえず思いつくものはだいたい書いた感じです。



2014-11-01 hachioji.pm #44 に行ってきた


表記のイベントに参加してきましたよー、と、いうことで。

今回のはちぴーは、立川の肉フェスと合同っぽい感じだったのですが、僕は昼過ぎくらいまで用事があったので、 夜から参加しました。前回の参加は#41らしいので、なにげに3ヶ月ぶりだ。

あんまりネタらしいネタがなかったので、最近作ってたもののお話をしました。



2014-10-25 Otogiri::Plugin::TableInfo 0.02 をリリースしました


気がつけば一ヶ月以上更新してなかった。お久しぶりです。

表記の通り、Otogiri::Plugin::TableInfo 0.02 をリリースしました。 Otogiri::Plugin::TableInfo というのは、このへんに細かい話を書いておりますが、 MySQL でいうところの、show tables とか show create table っぽいデータ(つまりテーブルの一覧と、テーブル定義)を見れる感じの物体です。

今回のリリースでは、show_create_viewというメソッドを足しています。名前の通り、View の定義が見れる感じになっております。

CPAN はこちら -> Otogiri::Plugin::TableInfo

Enjoy!



2014-09-03 Rejectcon で Otogiri の話をしてきました


YAPC::Asia 2014 で OtogiriというORMっぽいものの話をしようと思っていたのですが、Reject されてしまいました のリベンジみたいなお話。

Reject con というイベントで、あずまさんOtogiri の話をしてきました。

元々 YAPC::Asia 2014 の本編として応募していた内容なのですが、残念ながら不採用となってしまったので、泣き寝入りしかけていたのですが、 Reject con というイベントで発表の機会をいただいたので発表してきました。

資料はこちら

Reject con めっちゃ楽しかった。てつじさんのやつとか、門松さんの LT とか普通に本編と全く遜色ないというか めっちゃ面白かった。

僕としても、発表できなかった内容をちゃんと供養できたので大満足でした。 あと、ハッカドールのシールもらえたのが地味に嬉しい。

と、言うわけで、僕の YAPC::Asia 2014 は完全に終了ですね。 お疲れ様でした。

追記(2014-09-04)

デモに使ったもの一式を置いておきました。 https://github.com/tsucchi/tsucchi.github.com/tree/master/slides/yapcasia/2014-rejectcon/demo



2014-08-30 YAPC::Asia 2014 に行ってきました(ふつかめ!)


オープンソースの開発現場 - Perl 5.20 のSubroutine Signaturesが来るまでの奮闘の軌跡

最初のトークはどれを見ようかめっちゃ迷った。インフラも僕結構好きだし、Perl の話ももちろん好きだし。つーわけで、表記のやつを見たのですが、本当に面白かった。 技術的ってよりは、人間ドラマみたいな感じで、冗談半分で、

こんなtweetしたけど、これは半分本心でもある。

半端なPHPDisでPHPerに陰で笑われないためのPerl Monger向け最新PHP事情(5.6対応)

僕は PHP 全然書いた事無いのだけど、うずらさんの話は Hachioji.pm で何度も聞いてて、いつもとても面白かったので聞いてみた。前半は普通の PHP の話で、後半は闇っぽい話で、 どちらも本当に面白かった。内容も面白かったけど、見れなかった人は動画で見るのが良いと思う。(内容もガチで面白いし、うずらさんの話し方が上手くて、とても面白いので)

Perl入学式 in YAPC::Asia Tokyo 2014

今年も Perl 入学式のサポーターをしました。 結構駆け足な内容だったけど、一応受講生の皆様も最後まで完走できたっぽい感じで、よかったんじゃないかなー、と思います。

#yapcasia の tweet とか、連日の LT とか見てると、Perl 入学式、だいぶバズってて、やばいなぁとか、いや、これはめっちゃ良い事で、 Perl 入学式、とても良い勉強会なので、もっといい感じで進化していけると良いなぁ、と若干運営側の自分は思っています。

YAPC::Europe 2014 に行ってきました

昨年のベストトークのフィードバック。海外の YAPC の参加報告でした。面白かったし、ヨーロッパの YAPC、行けるものなら行ってみたいなぁ...

Perlの静的解析入門とPerlリファクタリングツールApp::PRTのご紹介

ひとでくんさんのプレゼン、独特のテンポでとても面白くて、内容もちゃんとしたガチな静的解析でとても面白かった。 App:PRT は今まで使って無かったのだけど、Perl だとクラス名変えるのとか、普通にめっちゃめんどくさいので、使ってみよう、と思った。

全体的な感想とか

今年は、トークするつもりで応募したんだけど、落ちてしまったので、割とゆるふわな感じで、目一杯楽しもう、と思って参加しました。去年位から、 知り合いも大分増えてきて、懇親会もぼっちじゃなくなったし、最初から最後まで本当に楽しめて良かったなぁ。

毎年思うのだけど、YAPC::Asia って、本当に楽しくて、最高の Perl のお祭りだと思います。来年こそ、トーク採択されるように日々精進しないとアカンよね。 明日から、がんばろう。



2014-08-29 YAPC::Asia 2014 に行ってきました(いちにちめ!)


ことしもついに始まりました。YAPC::Asia 2014

今年は発表もないので(落ちちゃったからねぇ...)、Perl 入学式のサポーター以外は ゆるく参加できるので、あまり悩まず楽しもうと思って参加しております。

さてさて、昨日(コレは8/30に書いてます)見てきたのは、こんな感じ

Perl meets Real World 〜ハードウェアと恋に落ちるPerlの使い方〜

ハードウェアの話はあまり知らないので、興味深く聞く事ができました。本番では「ネギを振る」デモは見れなかったけど、あとでイベントホールで見せてもらいました。 LED 光った所で爆笑しました。ハードウェアはなかなか難しそうだけど、こういうの見ると、「自分もやってみたい」と思えて良いですね。

このトークの後、イベントホールで Booking.com の方から謎のお菓子をもらったり、ネギ振るのを見たり、駄弁ったりしてた。

お待たせしました。Perl で BDD を簡単に実践する最高にクールなフレームワークができました

イベントホールでしばらく遊んでたので、途中から見学。

テストフレームワークは実際に使ってみないと評価は出来ないと思うけど、トークを見る限りでは使いやすそうで、試してみたいと思った。少なくとも subtest 的なものに、 setup/teardown を付けれるだけでも十分良さそうだし。

DBIx::Class - what is it and what is it good for?

DBIC は勉強した事はあるけど、仕事で使った事は無いので、使ってみたいと思った。

チューニングしていて、まだ速くなる余地があるらしいし、JOIN が必要なめんどくさい SQL をちゃんと作ってくれるのは素晴らしいと思う。 同時通訳が本当に素晴らしくて、僕は同時通訳があっても、途中で、「これはひどい。英語で聞いた方がまだマシ」となることが多いのだけど。 今回は全く違和感を感じなくて、本当に凄いと思った。

Scala In Perl Company : Hatena

Perl の会社がScala をどうして使うことになったのか、というお話。Scala は静的型の良さと割とゆるふわっぽく書けるところを 併せ持ってるから、前から気になっていたけど、勉強して使ってみたいなぁ、と思った。

ライブコーディング 2014

ライブコーディング、楽しいです。そんむーさんのライブコーディングを見るのは Yokohama.pm に続いて2度目でしたが、今回はトラブル もあって大変そうでした。Internal Server Error になってるのに、ログにほとんど何にも出ない、とか自分だったら絶対死んでたなぁ...

WHERE狙いのキー、ORDER BY狙いのキー

割と知ってる内容なのですが、面白かった。DB の仕組みを教育用するのにこの資料とかトーク(まだ動画は出てないと思うけど)は 凄く良いんじゃないかなぁ。

Get a kick out of CPAN

どうやったら CPAN が活発になるか、というお話。僕も質問というか、意見を話させてもらいました。 (「github 止まりにしちゃう事がおおいけど、そういうのも上げちゃった方が良いのかなぁ」、とか 「Prepan あるけど、 有効活用されていないかも、というか知られていないのかなぁ」、とか)

Prepan は perldoc のモジュールの所に記載がある、とか、metacpan で github アカウントと PAUSE がひも付けできる、とか 知らなかった(metacpan は知らなかったけど、最初にログインしたときに僕は設定してたらしい...)

初心者が Web エンジニアのコミュニティに触れてみて感じたこと - ゆとりエンジニアの成長戦略

blog 書く、とか勉強会に行ってみる、とか、僕と同じような意見だったのが興味深かった。

以上。めっちゃ雑な感想文だけど、そろそろ日吉に着きそうなので、ここでおしまいにします。



2014-07-17 YAPC::Asia 2014 で OtogiriというORMっぽいものの話をしようと思っていたのですが、Reject されてしまいました


トーク採択及びスケジュール決定について / Talk schedule is now available! - YAPC::Asia2014

と、いうわけで、今年の YAPC::Asia のトークが出揃ったらしいです。

僕はあずまさん(@ytnobody)と一緒に Otogiri の話をしようと思って、 「これはORMですか?いいえOtogiriです」というトークを 応募しておりましたが、力及ばず、Reject となってしまいました。

トークの応募締め切り直前に、YAPC で話す、ということというポエムを投稿した所、 思いのほか沢山の方に見ていただいて、大変嬉しかったです。

が、PVは沢山いただいたものの、トークページのソーシャルボタンの数はほとんど伸びず、トークの応募が異常に増える結果に(ポエム関係ないと思うけど)。 結果的にはコレ、自分の首を締めただけだったのでは???、と若干暗い気持ちになったりならなかったり...

つーことで、もし「あのポエムみて応募したのです」って方がいたら声をかけてもらえると、大変喜びます。(そういう方いるか分からないけど...)

ソーシャルボタンなどで応援してくださった方々ありがとうございました。せっかくなので、Reject になったトークの内容はいつかどこかで発表できたらいいな、と思っています。 その際はまたココに記事を書きますのでよろしくです。



2014-07-03 YAPC で話す、ということ


コレはおそらく、3年前の自分に向けたポエムである。

YAPC::Asia というイベントが8月に行われる事や、そこで Otogiri とかの話をするかも、ってかしたいという 話は以前書きました。

今、応募されているトークはこんな感じでして、いつも通りのような、いつもより Perl の話が少ないような、 そんな気がしています。(今日結構 Perl のトークがサブミットされたから、Perl の話だいぶ増えた)

ちょっと前だと、40ちょい応募があって、Perl の話が 20 くらい、みたいな感じだったのですが、この状況を 3 年前の自分が見たら、いったいどう思っただろうか? と、ふと思ったのでした。

3年前の当時、トークしようかどうか、めっちゃ悩みながら、手を震わせながら、初めて応募したのでした。当時はテストの話をしようと思っていて、 ちょうどテストの話があまり無かったから、「これはいけるかも」「いやー無理かなー」とか、毎日緊張しながら YAPC のページをリロードしてました。

で、翻って、今のトークのページを見ていると、当時の自分だと、「なんか良くわからないけど、凄い人たちが Perl じゃない話をしようとしてる、なんだこれ???」 と思うんじゃないかなぁ。んで、「どゆこと?普通の Perl の話じゃだめ?面白くない?」とか相当ビビったんじゃないかなぁ。当時の自分が今年のトークリストだったら、 応募するかどうか、怪しげだなぁ、と思います。(テンション高い時期だったら、「よっしゃ、Perlの話少ないからワンチャンありそうだ」とか思うかもしれないけど、どうかなぁ)

んで、コレは今だから言えるけど、これはこれで悪くなくて、Perl と Perl コミュニティの多様性なんですよね。なので、もし3年前の僕みたく、「初めて YAPC で喋ってみようと思ってるんだけど、 大丈夫かな?」って思っている人がもしいたら、「大丈夫だから、やってみようよ!」って思います。

例えば懇親会とかで、だれかと喋るとしても、初対面で色んな人と仲良くするとか、普通の人間にはできません。もちろん僕も。でも、「明日喋るんですよー。 見に来てくださいよー」とか言えると、それはそれでネタを一つ持ってる事になりますよね。

あと、「誰かが自分の話を聞きたくて、そのために来てくれる」って、一度経験するまで知らなかったのだけど、コレ、めっちゃ嬉しいです。僕の例だと、最初にしゃべった 2011年は 「スイーツエリア」という本編のトークじゃない場所で、正直どれくらい人がくるのか凄く不安だったのだけど、本当にビックリする位来てくれて、初めての発表だったのでだいぶテンパって しまった所もあったかもだけど、とにかく嬉しかった。翌年は裏番組が超豪華(宮川さん、弾さんで、LTソンでgfxさんが発表してた)で、「これ下手したら1人も来ない可能性もあるなー」と 思ってたけど、実際には沢山見に来てくれた人がいて、これは本当に嬉しかった。

とかまあ大体そんな感じで、あんまりまとまっていないですけど、YAPCで話すといい事あるかもね。というお話でした。

仕事とかで、ある程度一生懸命やっていた事って、必ずネタになって、そこそこ面白い話になると思うんですよ。んで、もしダメそうなら運営が選考から外してくれるだろうし、 応募するかどうか迷っていて、ちょっとでも「これいけるかも」ってネタがあるなら、応募してみると幸せになれるかもしれません。締め切りは明日 7/4 17:00までらしいので、 お早めに。

最後に宣伝。前回も書きましたが、今年はあずまさん(@ytnobody) と2人で Otogiriの話をしたいです。

こういう話をするっぽい。

  • Otogiriとは [ytnobody]
  • なぜOtogiriを作ったか [ytnobody]
  • どのように使っているか [ytnobody]
  • Otogiri::Plugin [tsucchi]
  • REPL(Reply)との合わせ技 [tsucchi]
  • さらに深いHack [tsucchi]
  • 対談 "Otogiriの今後" [ytnobody / tsucchi]
  • 質疑応答

つーわけで、「聞いてみたい」とか「ちょっと興味あるかも」という方は、上記のトークのページの SNSボタン(はてブとかtwitterとかFBとか)を ぽちぽちしてもらえると嬉しいです。

おまけ

ちなみに 3年前の資料とか感想とかはこちら。