YAPC::Asia 2015 良かった…

YAPC::Asia 2015 に行ってきた．今まで参加した中で IT 関係で過去一番参加者が多いイベントな気がする．Perl はほとんど書いてないものの，ラリー・ウォールや Matz の講演もあって楽しそうだったのでチケットを迷わず購入して有給取った．

トーク良かった

朝10時から夕方までびっしりセッションが組まれていて，めちゃくちゃ密度が濃かった． ここでは特に良かったトークについて感想書いていきます．

メリークリスマス

Perl の作者のラリー・ウォールの発表だった．（良く知られている写真ぐらいでしか姿を見たことがなかったので思っていたよりおじいちゃんだった．）

トールキンが大好きらしく，Perl5 = ホビットの冒険，Perl6 = 指輪物語 に例えて Perl6 について語っていた．指輪物語はホビットの冒険から（舞台設定など）改善したところがたくさんあるらしく，Perl6 もそれになぞらえていた．Perl6 では演算子が自由に定義できるっぽく，それを利用して構文を拡張するようなことができるらしい．演算子の宣言の時点で Perl6 の処理系はその演算子を知っているので，演算子の定義を自身を使って再帰的に書くことができる．正規表現はパターンと呼ばれる機能に進化（？）しているらしいけれど，これは説明を聞いただけではよく分からなかった．あと型周りもすごくなってるらしい．

Perl6，どうやら15年開発してきたらしく，発表の中にあった「うまく失敗することができた」という言葉にもある通りかなり山あり谷ありな開発だったと思うし，それでもここまで開発続けてリリースが見えるところまでこぎつけられるというのはすごいコミュニティの力だと思う．「クリスマスにリリース」と言われ続けてきて，ついに今年のクリスマスにリリースらしいので楽しみ．

TBD

Ruby の作者の Matz の発表だった．突然ネタが切れたと言って Ruby をディスり始めたあたりがめっちゃ面白かった．曰く，大きく3点あって

• Perl の影響 : 特殊変数
• Lisp の影響 : Fixnum と Bignum の区別があるところとか String と Symbol の区別があるところ
• マルチコア対応 : 「試しに GIL を外してどれだけプログラムが壊れるか見せてやろうか？」

らしい．Perl のカンファレンスなのにすごい．ただ，Symbol はプログラム中で Enum 的な感覚で使っているので，String と Symbol は違うんじゃないかなぁとか思った．

また，アーキテクチャの流行り廃りが振り子式になっていることとか2次記憶がどんどん速くなるんじゃないかみたいな話があって，満を持して Streem の話になった．

Streem について覚え書き：

• Ruby の反省を生かしつつ，マルチコアを使ってパイプラインでつないだ処理を並列に行う
  • シェルスクリプトに着想を得て設計（文字列以外もパイプで渡したい，プロセス立てるのは重い）
  • パイプラインの各段階は別 CPU で実行されるっぽい
  • echo server の定義が面白い（ストリームは双方向なのでサーバのストリームを開いてストリームから同じストリームに繋げるだけ）
• データが変更できないようになっている．（パイプの途中でデータが変更できるようになると困る）
• エラーになったら無視する（つらそう）
• 数値は小数点数・整数区別なし（さすがに整数と小数は区別したい）
• データ構造はすべて配列でハッシュのように使いたい場合は要素にラベルを付けられるようにする（内部構造どうなるんだろう）

ストリームの振り分けをうまく表現できる構文があるのなら，エラー処理は成功した場合のストリームと失敗した場合のストリームに分かれるようにするのが良いのかなと思ったけれど，ストリームが分岐するようなうまい構文は特に思いつかなかった．

しょぼいながらも僕も俺言語コンパイラをつくっていて，小難しいことはわからないけれどプログラミングの色々なこと（気持ちとか）を考えながら機能や構文を決めていくのは面白くて，「言語デザインは楽しい」というのにめっちゃ共感できた．あと，初めて Hello World が出せた時に感動するというのもすごい分かる．

せっかくなので質問してみた．Ruby の構文は端々に細かい直感的でないと感じるエッジケースがあったりして（主にメソッド呼び出しで括弧を省略できる辺りで生じる），構文をどういう感じに設計してるのかなと思ったので聞いてみた．構文的に気持ち悪くても，ユーザ（プログラマ）が直感的と感じられる範囲なら OK みたいな感じらしい．Ruby っぽいなという感じもする．

esa.io (\( ⁰⊖⁰)/)

前々からタイムラインではちょくちょく見かけていた esa.io をつくっている人のトークだった．今までロゴがかわいいぐらいの認識しかなかったけれど，ゆるく情報を整理・共有するサービスらしい．

趣味でつくりはじめたものが使ってもらえるようになってサービスとして売り出せるレベルまで持っていけるのはすごいなと思う．僕の場合は趣味はビジネス的なことは全然考えられなくて楽しければ良いのでお金にならないようなことばかりやってる… さすが好きなものをつくっているだけあってスループットがすごい．

Tシャツほしくなった．買った（8/24 0:18 追記）

はてなの Mackerel 開発における言語選択の話（Scala，Go，Perl など）

Mackerel 開発での言語の使い分けは

• サーバサイド Scala （Play）
• クライアントサイドバックエンド（Go）
• クライアントサイドフロントエンド（TypeScript + Angular）
• ツールとか Perl

らしい． Scala は言語機能が強力で大きい物をつくるのに向いているものの，やはりコンパイルに時間がかかるのもあってテスト回しまくるのがやりづらい．Go はビルドが速くてスクリプトで書いている時のようなスピード感でコードやテストが回せるしバイナリの配布も楽らしいので採用しているらしい（実装の都合上，クロスビルド自体はそこまで簡単ではなかったらしい）．妥当な感じだなぁという印象だったけれど，言語をしっかり使い分けて妥当な開発できるのはやはりメンバーの能力が平均して高いからなのかなという感じだった．

冗長化を失敗した話

式年遷宮，良い．

Adventures in Refactoring

GitHub の中の人によるリファクタリングの話．

リファクタリングは成功したかどうかが計測できないといけない（例えば行数が大きく減った，カバレッジが上がった，パフォーマンスが上がったなど）というのがあまり普段考えられてないなぁと痛感した．普段はとりあえず動くものを書いて，なんとなくイケてないところを直していただけだったけれど，これからはちゃんと目的持ってやろうと思う． 具体的な例も結構紹介されていて，同じようなプレフィックスがつく関数がたくさんある場合はプレフィックス部分をクラスにするというのが良かった（例：pull.branch_exists? のような関数があって，他にも branch_ プレフィックスな関数がある時は branch クラスをつくって pull.branch.exists? にする）．

大きな変更を行う場合は，変更に向けて内部をリファクタリングしてから変更を行う（大きな変更をリファクタリングとその後の実装に分ける）というのも参考になった．（例：アイテム1つを返す関数からアイテムのリストを返す関数に変更する場合，まずはアイテムのリストを取得してその末尾を返す関数にリファクタリングする）

あと，リファクタリング中にバグを見つけてもデバッグしてはいけない（エンバグした場合，リファクタリングとデバッグのどっちでエンバグしたのか分からなくなる）というのもかなりやりがちなので気をつけたい．リファクタリング対象と関係ない箇所なら別ブランチ立ててそっちでデバッグして後でリファクタリングしたブランチにマージすれば良さそうだけれど，リファクタリング対象にバグがあった時は後でちゃんとデバッグするのを忘れないようにしないといけないので，その辺りうまくやる方法を考えたい．

資料見直したくなる情報量の多い発表だった．

姿勢の話

1日の半分以上座って作業しているのに，この辺りのこと普段考えてないなぁと思って反省した．一定時間ごとに姿勢を変えて作業するのが良さそうなので何か考えたい．今は家では椅子で作業（iMac）とダメソファで作業（MBA）ぐらいしか選択肢がないのでもっと色々試してみたい．

Go のプロファイリングと最適化の話

Go 開発者の1人 Brad の発表だった．

ほとんど資料でなくライブコーディングで進める発表で，小さいウェブアプリをプロファイリング取って最適化していく話だった．とてもテンポが良くて Go のツール群の魅力がすごい説得力で伝わってきた．かっこいい．

最適化は計測するまで行ってはいけないというのは鉄則としてあるけれど，今までどの言語もプロファイリングを取るのはハードル1本ある感じだったと思う．Go のツールは標準ですごく良くできていて，そこをうまくクリアしていそうだった．Go で小さいライブラリを1つつくりたいと思っているので，そこで試す．

見てないけど気になったリスト（あとで資料よむ）

• Effective ES6
• http2.0 時代の web
• Perl6 の並列・平行プログラミング

発表以外

同時通訳がめっちゃ良かった．技術的な単語はちゃんと訳さずそのまま伝えてくれていて，普段英語のセッションは聴くのに精一杯になってしまってなかなか頭に入ってこなかったので，これはとても助かった．

あと無限コーヒーもしょぼいコーヒーサーバみたいなのじゃなくちゃんと淹れてくれていておいしかった．コーヒーゾーンとても良い匂いがたちこめていてあそこでセッション聞きたかった．ホールAに飲み物が持ち込めなかったのが（仕方ないけれど）ちょっと残念だった．

アイコンしか知らなかった人と挨拶できたのも良かった．

まとめ

初参加だったけれどめっちゃ楽しめた．かなり歴史のあるイベントらしく，今回で終わってしまうのがもったいない気がする．YAPC::Asia 2015 良かった…