本日28日から30日までの3日間、慶應義塾日吉キャンパス 協生館にて「YAPC::Asia Tokyo 2014 」が開催されています。本日は2日目、最終日。本稿では、この2日目の模様を随時レポートしていきます（注：すべてのセッションをレポートするわけではありません） 。
イベントホールの後方には、書籍販売ブースがあります。また、水やかき氷もあるのでぜひ受け取ってくださいとのことです。
Daisuke Makiさん「オープンソースの開発現場 - Perl 5.20 のSubroutine Signaturesが来るまでの奮闘の軌跡」
lestrratさんこと、Makiさんのセッションでは、Perl 5.20で実装された関数シグネチャの機能の開発の経緯をスタディケースに、老舗のOSS開発ではどのようなことが起こるかを学ぶといった内容でした。Perl5.20では本セッションの題材である関数シグネチャの他、後置のデリファレンスやレガシーモジュールの削除といった変更も行われました。
Perlに関数シグネチャが欲しいという要望は、昔からありました。しかし、実装や既存の機能との調停が難しかったりといった理由で、ずっと実現されずにいました。そのような状況で現れたのがMartini氏です。Martini氏は、OSSでよくある欲しい機能や気に入らない点を書くだけで自分では手を動かさない人とは違い、初めから自分で作るからPerlに関数シグネチャを入れたいと提案しました。そしてその数ヶ月後、宣言したとおりにプロトタイプ実装を開発してp5pメーリングリストへ投稿しました。
ところが、Martini氏の提案に興味を持っていた人が多過ぎて、プロトタイプ実装に対してあまりにも多くの意見が集まってしまいました。その中には、「 今までの中で最悪のシグネチャの実装だ」とか「次はもう少し使えるパッチが書けるんじゃないかな」などと言った中傷や、「 これができるならこういうこともできるよね？」といった本筋とは関係のない変更を促す投稿など、Martini氏のやる気を削ぐのではないかという返信が多数含まれていました。
Makiさんは、この時点で関数シグネチャは実装されずに終わると思ったそうです。しかし、Martini氏は中傷は受け流し、必要な変更は取り込みながら仲間を増やしていきました。こうして関数シグネチャの開発はMartini氏の努力によって粘り強く続いていたのですが、そんなこの機能にさらなる試練が襲いかかります。Martini氏の書いたコードをすべて捨て、書き直されたコードがPerlのコアに採用されたのです。そのため、引数の個数のチェックは静的ではなく動的チェックとなってしまい、Martini氏が実現したかったDesign by Contractは実現されませんでした。
Makiさんによれば、この件についてMartini氏は「関数シグネチャの構文がコアに入ることが重要で、実装は後からでも変えられる」と評価しているそうです。Martini氏は静的解析に必要となるprototype周りの変更も実は裏で進めており、自身のゴールをまだ諦めていないように思えます。今回のセッションを聞いて、OSS開発に関わるときは明確なゴールを持って政治的なことも含めた判断を粘り強く下していくのが大切だと感じました。また、このような人々の影での努力があってOSSが成り立っていることも、忘れてはなりません。
Yuichiro SAITOさん「突然ITインフラを任された人のための…監視設計入門」
「Webアプリエンジニア養成読本」の著者の1人である、ハートビーツのYuicihro Saito（@koemu）さんの発表です。なぜ監視するのか、何を監視するのか、閾値をどう決めるのか、障害通知が来た時の連絡体制はどうするのかについて話しました。
監視をする理由は、とにかくユーザに迷惑をかけないためで、いち早く対応を始め、いち早く復旧するためだと言います。
監視の設計の流れを、確認、設計、構築、運用に分け、デモ環境をもとに説明しました。監視の設計を行う際はシステムをサーバ、リソース、デーモン、外形の4つのレイヤーに分けて考えると良いそうです。サーバはサーバの生死、リソースはサーバのリソース、デーモンはミドルウェアの生死、パフォーマンス、外形はユーザの利用を想定した監視です。実際に、デモ環境で監視の設計を行っていく様子はとても参考になりました。その中で、監視サーバは別のデータセンターに置かなければならないということで、自宅のRaspberry Piを利用していました。業務では利用できませんが面白いと思いました。
全体的に監視の基本をわかりやすく説明しており、タイトルの通り、これから監視の設計を行わなければならない人にとって、とても良い発表だったのではないでしょうか。
Masahiro Naganoさん「Dockerで遊んでみよっかー」
Masahiro Naganoさんは、コンテナ管理ツールDockerについて発表しました。最初に「遊ぶ」というタイトルにしたことについて、Dockerはこれから洗練されていく技術であるとして、すぐに業務で使えるわけではないが、今のうちに手を動かして学んでみる＝「真剣に遊ぶ」ということが大事なのでと説明しました。
DockerはNaganoさん曰く「アプリケーションの開発・配布・実行のためのオープンなプラットフォーム」で、アプリケーションの共有と配布を行うDocker Hub、アプリケーションのパッケージングを行う際に参照するDockerfile、アプリケーションの実行を担うDocker Engineからなるとのこと。
Dockerは一見するとVMに似ているように見えますが、VMがその数だけOSも起動するのに対し、Dockerのコンテナはアプリケーションレベルで起動するため、リソースの無駄が少ないとのこと。Dockerを利用するにはLinux Kernelが必要で、Macなどで使う際には仮想マシンを入れる必要があるそうです。Naganoさんは仮想環境構築ツールVagrantを使うことを推奨していました。
それから、Dockerfileの基本的な書き方や、Dcokerイメージの選び方、VagrantでDockerのインストールを自動化する方法などについて、それぞれ説明しました。
うずらさん「半端なPHPDisでPHPerに陰で笑われないためのPerl Monger向け最新PHP事情（5.6対応）」
うずらさん（@uzulla）はPerl Monger向けに今日のPHP事情を発表しました。何かと槍玉にあげられることの多いPHPですが、今日のPHPは必ずしもそのイメージ通りのものではありません。
PHPはHTMLに入れるのが楽で、かつてはテンプレートエンジンとして活躍しました。PHPの存在がMySQL人気に少なくない影響を与えていると、うずらさんは考えています。
今まではだいぶ事情が変わり、規約を頑張って導入しようとしており、オブジェクト指向プログラミングも可能で普通のプログラミング言語のように書けます。また、packagistを中心とした豊富なパッケージもあります。このように今日のPHPは意外と怖くない言語になっています。もちろん、IDEによる補完やシンタックスエラーチェックもしっかりと効きます。PHP 5.6の解説も行い、安全な暗号化やジェネレータが話題になったことを挙げました。
PHPには主に3つの処理系があります。そのうちの一つ、Facebookが開発したHHVMは高速でhackの実行もできるという特徴を持っています。HHVMはPerlとのベンチマーク比較を行い、想像以上のPHPの速さに会場を沸かせました。
PHPの残念な面についても触れました。PHPが出自からも初心者が入門しやすい言語であり、かつWAFがなくても書けてしまうために、初心者がレールを外れてしまう危うさも持っていると言います。ゆるふわ暗黒PHPなどPHPの暗黒面を垣間見せる部分もあり、PHPの長所と短所を端的に示しました。
全体を通して、もはやテンプレートエンジンではない、現在のPHPの姿が明らかになりました。
Naoya Itoさん「Google BigQuery で DWH 構築」
Naoya Itoさんは、「 120億行を5秒でフルスキャンできる」というGoogle BigQueryについてどのようなものか、またKAIZEN platform Inc.でどのように使っているかを発表しました。
Google BigQueryは巨大なデータへのSQLなどを数秒で実行するクラウドサービスです。元々はGoogle社内で使われていたものがサービス化したもので、ログ解析やDataware Houseに活用できるそうです。速さは分散処理によって実現されているそうで、1TBのデータを1秒でリードできるI/Oが使われているとのことです。
同様の（あるいは似たような）サービスとしてMapReduceやPrestoなどがあり、Google BigQueryだけが特別ではありませんが、Google BigQueryはとても安くコスト面のメリットが大きいそうです。
KAIZEN platform Inc.では、Google BigQueryをログの保存、解析やABテストの有意差判定に利用していると紹介しました。一般的なRDBなどと異なり、集計を意識したテーブル設計が不要であることや、fluentdを経由した大量のログ送信ができるという利点があると述べていました。
Naosuke Yokoeさん「Perl Mongersのためのstrace入門」
Naosuke Yokoeさんは、プロセス内で発行されているシステムコールをトレースするためのツール、straceに関して発表しました。
最初にWebアプリの仕事を、HTTPリクエストを受けてHTTPレスポンスを返すところまでとして、それをシステムコールレベルまで順に変換しつつ説明しました。そこから実際にWeb Serverを立ち上げてstraceのデモを行いました。
その後、straceを読むときの基本的な読み方、fdに注目することでファイルの生存期間やソケットの生存期間などの判明すること、さらにMySQL, memcacheなどのport番号をあらかじめ知っておくことで調査をport番号からfdを知って追うことができるといったことを実例を踏まえて紹介しました。また、調査を行う際は人の記憶やアプリのログ、アプリのコードではなく、starceやtcpdump, gdbといった嘘をつかないツールに頼ったほうが良いとのこと。そして、thundering herd問題についても取り上げ、こちらも実例を交えて調査の方法を紹介しました。
最後に、straceは万能ではありませんが、使えると便利で、Webアプリの気持ちがわかるようになるのでお勧めであると述べていました。
Kazuho Okuさん「JSON SQLインジェクション脆弱性と、そこから学ぶセキュアプログラミングの原則」
Kazuho Okuさんは、JSON SQL インジェクションによる脆弱性に関して発表しました。多くの言語にライブラリとして提供されているSQL Query Builderは、アプリケーションからDBにアクセスする際のクエリを生成するためのものです。SQL Query Builderは値がスカラか配列かハッシュかなどを見分けて、クエリを生成してくれます。
JSON SQL インジェクションは、JSON形式のデータをSQL Query Builderに渡す際に想定と異なる型が渡されることによって起こる可能性があります。スカラの値が入力されることを期待している箇所にハッシュ値などが入ることで、開発者の想定していないデータが取得されてしまうかもしれません。これはPerl固有の問題でなく、他の言語でも起こり得るそうです。
この問題に対応するために、クエリの生成に配列やハッシュを使うのではなく、関数を用いるSQL::QueryMakerを開発して対応したとのことです。またSQL::Makerにも、配列やハッシュが使われるとエラーを返すstrictモードを追加したそうです。
Okuさんはこの問題から得た教訓として、「 入力値を検証すること」が大切だと述べていました。値だけでなく型もチェックし、その上で検証が不足しても情報が漏洩しないよう、SQL::QueryMakerやSQL::Makerのstrictモードのような実装を用いていくことが望ましいとのことでした。
ランチセッション
2日目のランチセッションは@yu_loveperlさんによる発表です。DNPデジタルコムにおける開発風景やソリューションの実績などを紹介しました。Perlがどのように使われているかを示したのですが、これらのPerlの構成が古いそうで、今どきのものに改善していきたいと述べていました。
地域.pmミートアップ 2014
イベントホールでは、全国各地からHokkaido.pm, Hachioji.pm, Fukuoka.pm, Kansai.pm, Kyoto.pm, Niigata.pm, Yomitan.pm, Mishima.pm, Hachioji.pm, Yokohama.pmの計10団体の代表者を招いて、パネルディスカッションが開催されました。各団体の現状の紹介や今後の野望など、活発に議論が交わされていました。
Sawyer Xさん「Plack for Fun and Profit (But Mostly Profit)」
ゲストスピーカーの一人であるSawyer Xさんからは、Plack/PSGIの概要とビジネス視点の重要性について発表がありました。Sawyer XさんはDancer2というフレームワークの作者でもあります。
まずはPSGIについてです。環境変数を引数にとってArrayRefを返すサブルーチンという最も基本的な形から、Delayed PSGI response、Streaming PSGI responseのパターンが紹介されました。
つづいてPSGI toolkitとしてのPlackについてです。WebサーバとPSGIアプリケーションをつなぐHandler、PSGIアプリケーションを実行するRunner、PSGIアプリケーションをラップしてレスポンスを変更できるMiddleware、Middlewareを有効にするためのDSLとしてのBuilder、PSGIアプリケーションのTestingなどが紹介れました。
このようにPSGIは便利でクールだけど、それで十分ですか？という問いかけからビジネス面への考察へと展開していきます。
Sawyer Xさんが所属するBooking.comは宿泊施設の予約サイトで、53万の宿泊施設、3,500万件のレビュー、42カ国語サポートなど非常に大規模なサイトです。コードベースは百万のオーダーに達し8000以上のパッケージからなります。歴史も長く1996年から運用しておりMasonやmod_perl、Class::DBIなどといった今となってはレガシーなコードベースもたくさんあります。これらのコードは今も利益を生み出しており簡単に消し去ることはできないものです。2日かかる機能改修をリファクタリングすれば10分でおわるけどリファクタリングに2ヶ月かかるといった場合、後者を選択することはビジネスでは現実的ではありません。したがってこれらのコードともうまく付き合っていく必要があるのです。
この問題を解決するために複数のPSGIアプリケーションを組み合わせる事例を紹介されました。それぞれの環境ごとの違いを吸収するPSGIアプリケーションを用意し、それをさらにdispatcherの役目を果たすPSGIアプリケーションで統合しているそうです。
レガシーコードをモダンなコードにリファクタリングしたい思いに駆られるのはエンジニアとしてよくあることだと思いますが、Sawyer Xさんの発表を聞いて考えなおすきっかけになった人も多いのではないでしょうか。
kobakenさん「ほんとにあったスキーマの話 「ソーシャルゲーム」」
kobakenさんは、スキーマについて発表しました。
スキーマとは何かという定義から始まり、ゲームとしての特徴、Webサービスとしての特徴などをあ挙げ、ソーシャルゲームでのというコンテキストでスキーマ定義について話しました。
代表的なスキーマの例としてユーザ、カード、称号、バトルをあげ、それぞの定義とその変更、そして変更から得られたパフォーマンスやパラメータ変更への修正への強さなどを実際に使用されたスキーマを例に紹介しました。
最後には発表者から会場の方へ逆に質問をするという面白い趣向もみられるセッションでした。
あらたまさん「モバイルアプリとAPIのありかたを考える2014」
あらたまさんは、モバイルアプリとAPIのありかたにについて発表しました。
iOSやAndroidのモバイルアプリの開発ではありがちな、1アクションのたびに通信中、似たようなバックエンドを毎回作っているといった問題を解決する必要があります。そのために、モバイルアプリのバックエンドをまとめて面倒を見てくれるMBassSの代表格のParseというサービスと、JSONを一度の通信で複数回メソッドの実行を行い通信コストを下げることのできるJSON-RPC 2.0 Batchを紹介しました。
これらを使用することにより、サービス・プロダクトにフォーカスして開発でき、一度にリクエストをたくさん送ったり、分析のログを送りやすくなるとのこと。また、その結果、理想とするユーザ体験を最大化するためのアーキテクチャーに近づくことができると述べていました。
最後に、JSON-RPC 2.0 Batchに対応したiOSのAPI Clientを、GitHub上で近日公開する予定であると述べていました。
Perlあるある
@lestrrat, @takesako, @miyagawa氏をゲストに迎え、あらかじめ質問しておいた内容を題材にしたトークセッションでした。主催の株式会社オモロキからは@yusukebeさん、@kamadangoさんが登壇しました。
最初の質問は「このCPANモジュールがすごい」で、登壇者の経験からすごいと思ったモジュールを紹介しました。Web::Scraper, DBI, Jcode.pm, Carp::Always, awstatsの名前が挙がりました。Web::Scraper, DBIは実用性はもちろんですが、特にその実装がPerl的な変態コードになっているそうです。ただ真似するのはお勧めしないということでした。Jcode.pmはPerl4時代のjcode.plからみてとてもイケていたということ、Carp::Alwaysは単純に知ってると便利ということでした。awstatsは古くからあるPerl製のアクセス解析ソフトで、10万行ほどの1cgiファイルのみというレガシー構成にもかかわらず、今でもメンテされているそうです。また、RubyでDSLが流行ってるというとPerlプログラマもやりたくなるといった、Perlあるあるも紹介されました。
「コーディングに欠かせない飲み物と食べ物」では、飲み物はコーヒー食べ物は不要という方が大半でしたが、Background Videoが捗るといった面白いスタイルもありました。
「その昔勘違いしていたこと」では、POEをポエと呼んでいた（ポーと呼ぶそうです）ことや、YAPCをワイエーピーシーと呼んでいた（ヤップシーが一般的）など読み方についての話題が多めでした。
「大切にしている言葉」では、「 コードを書くのに許可はいらない」「 コードも作文と同じ」「 基礎が大事」「 Done is better than perfect」といったそれぞれ印象深い言葉を紹介していました。
最後の質問「エンジニアになって良かったこと」に対しては、食いっぱぐれないという現実的な意見から、趣味を仕事にしているので毎日が休日といったポジティブな意見、自分の生活だけではなく世界を良くすることができるといったスケールの大きい意見まで様々な視点が語られて終了となりました。
Perl入学式 in YAPC::Asia Tokyo 2014
プログラミングに興味がありつつも未経験の著者が初めてプログラミングを学ぶため、Perl入学式に参加しました。
Perl入学式とはプログラミング初心者が、1年間Perlについて学び、最終的に簡単なWebアプリを作成できるようになることを目的とした勉強会です。YAPCでは過去にも開催されており、今年も開催されました。
今回のテーマはBotで、2時間半で基礎的な部分を学んだ上でBotを作成しました。しかし、先に述べたように著者はプログラミング未経験者です。何をどうしたら良いかサッパリ分からなかったのですが、サポーターの方がマンツーマンでついてくれたので非常に心強かったです。
さて、肝心の内容ですが、最初は基礎を学びました。変数、スカラ変数、変数の出力、文字の入力、配列、forループなど。聞いたこともない言葉がたくさん出てきました。時間の都合上、駆け足での説明でした。
一通り説明があった後に、用意されていたコードを用いて練習問題を解きました。printを使うと変数を出力できる、sortを使うと配列の並び替えができるのだなと、部分的にぼんやりと分かりましたが、もちろん全く解けず、解説を聞いても分からず、サポーターの方に聞いても分からなかったのですが、とりあえず分からないながらも話を聞き、手を動かし、サポーターの方についていただき練習問題を解くということを繰り返しました。この時点では全く解けず、本当に落ち込んで来て諦めて帰ろうかと思ったくらいでした。
基礎の学習と練習問題を終え、今回のテーマであるBotの作成です。まずはBotの仕組みを学び、練習問題を解いた上で簡単なBot作成できるようになるのが最終目的です。BotとはTwitterで自動的で呟くアカウントで、とても馴染みがあります。Botが動く仕組みは、入力を待ち、入力に応じてあらかじめ指定された動作をするというものであり、それを繰り返すというものです。Botは馴染みもあるせいか、取り組みやすかったです。Botのベースコードを用い、おみくじ機能を追加して、おみくじBotを作りました。これは、「 おみくじ」と入力すると、「 大吉」「 中吉」「 小吉」とランダムに出力する仕組みです。ランダムな値は乱数といい、randを使うことで表現できることが分かりました。
また、Perlのモジュールを使えば、Twitter用BotをはじめSkype用Botを作れることを知りました。
最後は校長の@papixさんがデモンストレーションを行い、Perl入学式は無事終了しました。
感想としては、コードは残念ながら書けるようにはならなかったものの、Botに関しては仕組みを理解し、コードのほんの一部ですが書けるようになり、本当に嬉しかったです。最初は全く分からず、ついていけなかったのですが、諦めないで本当に良かったです。プログラミングは奥が深く面白いものだと実感しました。次回もPerl入学式に参加したいです。また、自分でも勉強しつつ積極的に勉強会に参加しようと思いました。
Andy Delcambreさん「Changing the tires on a moving car: a case study in upgrading legacy architecture」
GitHubのAndyさんは、GitHub内のgitのデータにアクセスする処理の改修の変遷について発表しました。GitHubではPerlは数百行しか使われていませんが、とは言え、Perlで書かれているもので重要なものも多数あるそうです。
GitHubでは27台のファイルサーバで100TBのデータを扱っており、これらのデータに高速にアクセスするのは重要なタスクとなります。初めのうちは、GritというRubyのgitのラッパーと、Smokeという分散ファイルアクセスを行う仕組みを用いてこれを実現していたそうです。しかし、Chimneyという管理サーバがボトルネックとなり、この仕組みはスケールしないことから作りなおす必要が出てきました。
また、Gritにもgitの最初の実装が共有ライブラリとして実装されていないために例外処理に問題があったり、ライセンスに難点があったりしていました。そのため、libgit2というライブラリを一から作り直し、これをラップしたRuggedというライブラリも用意しました。PerlにもGit-Rawというlibgit2のラッパーがあるそうです。さらにSmokeの問題を解決したGitRPCという仕組みを使った、新しいシステムを作成しました。
しかし、作った新システムを旧システムに差し替えるのに、すべてを一度に差し替えることはできません。Andyさんは両システムを並列に走らせ、状況をきちんと計測しながら切り替えていくのが大切だと述べていました。最後に残った数％の利用については、丁寧にtracingをして対応していくのが大切だとして、トークを締めくくりました。
karupaneruraさん「Perl5 meta programming」
karupaneruraさんは、サブルーチンやパッケージを動的に定義したりするプログラムを生成するプログラムであるメタプログラミングについて発表しました。
メタプログラミングを使うことでDRYなコードやInnerDSL, PreProcessingを手に入れることができますが、自由度の高い世界を手に入れる代わりに使い方を間違えると酷い目に遭います。そこで、その危険性を回避するために、テストを書く、既存のモジュールで解決する、シンプルに作れという方法論を説明しました。
その後、string eval, UNIVERSAL, symbol table, AUTOLOAD, Package::Stash, B.pm, Class::Inspector, Class::Method::Modifiers, Mo[ou]se, Mooという具体例を、デモを交えつつそれぞれの特徴などを分かりやすく解説しました。
gfxさん&ninjinkunさん「Mobile Application Development for Perl Mongers [ninjinkun x gfx]」
モバイルアプリの開発ノウハウについて、1) Client-Frontend、2) Client-Backend、3) フリートークという3部構成でninjinkunさん、gfxさんの2名から発表がありました。
ninjinkunさん「Client-Frontend」
ninjinkunさんはアプリのUIデザイン、状態管理、OSSについて発表しました。
まずはエンジニアがUIデザインに参加することを推奨しました。そうすると標準UIの知識を活かせたり、コスト感が分かるなどのメリットがあります。UIデザインの手法としてはペーパープロトタイピングをお勧めしていました。また、ユーザテストに参加すると機能の必要性を納得して開発がすすめられて良いとし、プロセスの中心においているとのことです。
続いて、状態遷移についてです。アプリのデータは非同期に更新されることが多く、データの更新とビューの同期が問題になりがちです。それをスマートに解決する方法としてMVVMモデルや、Reactive Programmingに期待しているそうです。
オープンソースの分野も活発になってきており、CocoaPodsやGradleといったツールチェインも整備され、多くのUI部品も公開されていると言及していました。貢献したければOSアップデートのタイミングや端末固有のバグなど、チャンスも多いとのことです。
gfxさん 「 Client-Backend」
gfxさんはアプリのリリースを支える、開発プロセスを中心とした発表をおこないました。
まずはチーム構成の変遷について紹介しました。もともとモバイルチームがアプリ部分の機能開発をすべて担当していましたが、ネイティブ部分が増えてくるにつれて回らなくなったので、サーバサイドエンジニアがアプリの機能も開発していく形にシフトしていっているそうです。
続いて、リリースサイクルの話がありました。Webアプリケーションでは一日に何度もデプロイするのはあたりまえですが、ネイティブアプリではリリースサイクルがそれよりも長くなります。そのためgithub-flowをベースとしたフローではマッチせず、git-flowをベースにしたスタイルにしたそうです。具体的にはQAの前にcode freezeを行ってリリース候補のブランチを作り、そこでリリースに必要な不具合修正のみをおこなってマスターにマージというフローで進めていると説明しました。
CIの話題ではテストでAppiumなど使ってはいるがまだまだで、リリースも手作業になることが多いそうです。Google PlayはAndroid Pubisher APIがあるので自動化していきたいということでした。
「フリートーク YAPC.fm」 10分弱のフリートークでは、テストはまだまだだけどiOSのbotsには期待していることや、ViewModelを進めてテストをしやすくしていきたいこと、うっかり作るとほぼすべてシングルトンになったりするのでMVVMに期待しているということ、JavaやObjective-Cといった言語よりはフレームワークのほうが重要でUIフレームワークはiOSのほうが簡潔にできていることなど、短い時間でしたが様々な話題が展開されました。
最後に、コミュニティについて、アプリ界隈ではYAPC規模のイベントはまだないのでPerlの文化を持ち込んでいけけたらと述べていました。
Tatsuro Hisamoriさん「YAPC::Europe 2014 に行ってきました」
去る8月22日から24日に、YAPC::Europe 2014がブルガリアにて開催されました。先月ベストトーク賞で2位を獲ったmyfinderことHisamoriさんは、賞品としてこのカンファレンスに参加していました。本発表はそのYAPC::Europeへの体験記となります。
ブルガリアはビールが安く、100円以内で缶ビールが飲めてしまうそうです。カンファレンスに到着後、しばらくは誰ともコミュニケーション取れずにいたHisamoriさんですが、TwitterでのMakiさんの協力もあり、最終的には多くの海外のhacker達と交流することができたそうです。
日本のエンジニアが海外に出るにあたり一番心配しているのは英語かと思いますが、欧州は英語が母国語ではないエンジニアも多く、英語がそこまで得意ではなくてもなんとかなるとHisamoriさんは説明していました。来年はスペインのグラナダという観光地で開催されるそうなので、みなさんも新しいキャリアへの第一歩としてYAPC::Europeへ参加してみるのはいかがでしょうか。
hitode909さん「Perlの静的解析入門とPerlリファクタリングツールApp::PRTのご紹介」
Javaのコードをリファクタリングする場合、IDEの持つリファクタリング機能を使うのが普通です。しかし、Perlの場合はこのような便利なツールはあまりありませんでした。hitode909さんの開発したApp::PRTは、IDEが備えるようなリファクタリングの機能を実装したコマンドラインツールです。
PRTはPerl Refactoring Toolの略です。PPIというPerlの構文解析器を使って実装されており、まずはその解説から入りました。PPIを使うとPerlのプログラムの構文木を作ることができるため、例えば、数値リテラルだけを2倍にする、といったソースコードの変更が簡単にできるようになります。
App::PRTをインストールするとprtというコマンドが使えるようになり、このコマンドを使うとクラス名の変更やメソッドの定義位置の移動などを簡単に実行できます。デモとして、今回のトーク用に作った小さいソースコードやPlackのコードを実際にリファクタリングしていました。grepやsedの置換だけでは実現できない精度の高い変更が可能であるため、使い始めると手放せないツールになるのではないかと、筆者には感じられました。
tagomorisさん「そんなにビッグでもないデータ処理手法の話」
TAGOMORI Satoshi（@tagomoris）さんの発表です。データ処理の流れには、データを集める、パースやクリーンアップ、保存、処理、可視化がありますが、今回は処理の部分についての発表でした。また、データを処理するには、データサイズについて考える必要がありますが、実際のデータサイズではなく、1度のクエリで処理されるデータサイズを考慮すべきとのことでした。それが、数GBのデータであればRDBMSで十分で、PB以上のデータはHadoopやStormを使うべきだそうです。今回はその間の数十GBからPBオーダーのデータサイズでの処理が対象です。
データ処理には、検索や集約、リコメンド、異常検知などがありますが、何をしたいかによってアーキテクチャが決まってくるため、何をしたいのかが重要だと言います。分散処理フレームワークにはMapReduce v1、MapReduce v2、Apache Spark、Apache Tezなどあり、新しいものはMapReduceの10倍速いなどと言われていますが、まずは比較的安定しているMapReduceからやるのがお勧めだそうです。MPP（Massively Parallel Processing）エンジンにはApache Drill、Cloudera Impala、Facebook Prestoなどがあり、DSL（SQLが多い）でクエリを書けます。ストリーム処理は、ストレージがいらなくて便利ですが、とてもスループットの高いデータ処理以外にはお勧めしないそうです。これには、Twitter StormやNorikraがあります。
Hadoopには関連するプロダクトが多数ありますが、すべてがHadoopと述べ、会場を沸かせていました。その際にスライドに表示されていた画像も大変印象的でした。また、BigData as a Serviceについても触れていましたが、ここでは詳しく説明しませんでした。ビッグデータの処理では、Perlは使いませんが、それはJVMに支配されているからだそうです。CPANモジュールもほとんどなく、書き放題とのことでした。
最後に、ノウハウや意見、考えていることを共有しましょうと述べ、セッションを締めくくりました。
Lightning Talks Day 2
2日目のLightning Talksです。
Yappoさん
WEB+DB PRESSのPerl Hackers Hubの連載の執筆者の募集でした。興味のある方はTwitterなどでコンタクトを取ってみるのはいかがでしょうか？
tatsuro.hisamori@facebookさん「YAPC::Asia Europa 2014に行ってきました 超濃縮版」
YAPC::Europe 2014の体験談でした。今年はYAPC::Asiaでも無限コーヒーが提供されていますが、YAPC::Europeでは無限朝食もあったことや、ビールが41円という現地の様子、発表中もどんどんつっこんでくる日本とは違う点などを駆け足で紹介しました。英語はできなくても大丈夫なので、ベストトークをもらった人は是非いきましょうと呼びかけていました。
Yudai Suzuki@facebookさん「TDD」
テスト駆動開発ではなく、Twitter Driven Datsu-Syosinsyaについてのトークでした。Twitterでスキルの高いエンジニアをフォローしていたことで、Suzukiさんのレベルも知らないうちに上がっていたそうです。「 有名な人をフォローしたほうがいい」と自身の体験から勧めていました。
libitte@twitterさん「画像ファイルに色名を割り当てたいときに便利なモジュールのご紹介」
既に数十万件あるアイテムを色名で検索するというニーズに答えるために作ったImage::ColorDetectorというモジュールを紹介しました。RGBではなく人間の感覚に近いHSV色空間を使って判定したり、まだら模様の曖昧な画像は色成分の割合でむりやりつけるなどの工夫を説明しました。最後に、今後はもっと高速化したいと展望を語っていました。
タケウチさん「脱北者より怒涛の研修日誌」
新人研修で開発したGeekDojoの紹介と、この開発で経験したことを発表しました。GeekDojoについて、地方で開催される勉強会よりも都内で開催される勉強会では人同士の関わりが薄いことを問題として挙げ、その弱点を補完することができると述べていました。
issm@twitterさん「初めてリリースしたCPANモジュールのおはなし」
String::IncrementalというCPANモジュールを初めてリリースしたという発表でした。これは文字の集合とフォーマットを指定してインクリメントしていけるモジュールです。CPANにアップしたところ、良いアイデアだというコメントももらえたそうです。issmさんの誕生日にリリースしたそうですが、CPAN上では時差の関係で1日前になってしまい、世界は厳しいというネタで笑いを呼んでいました。
hoto17296@twitterさん「運用で爆発四散しないためのメタプログラミングとの付き合い方」-
メタプログラミングの便利な点と気をつける点について話しました。メタプログラミングはその強力さが故に設計が大事であること、また、上手に適用することによって言語の理解が深まることを利点に挙げていました。
glkame@twitterさん「I began perl」
初心者大歓迎ということでLTに応募したというglkameさん、Perlは一度挫折したそうですが、勉強会を検索してPerl入学式に参加したことをきっかけにPerl面白いと思うようになり、挫折を乗り越えることができたそうです。さらにGeekDojoにも参加しPerl入学式で学んだことを試して、それを入学式に持ち帰るという良いサイクルになっていると話していました。簡潔でしたがperlコミュニティの温かみが感じられるトークでした。
zakzakzak333@facebookさん「フィリピンでCTOを名乗り始めて焼く2年が経った」
フィリピンで働いて経験したことについての話でした。フィリピンは平均年齢が若く、スマートホンの普及率が高いことが特徴だそうです。英語についても、元々ネイティブではないためにみな寛容で、比較的馴染みやすいそうです。
Sawyer Xさん「YAPC::Asia」
ゲストスピーカーのSawyer Xさんが開発しているフレームワークDacner2について紹介しました。とても簡潔に記述できるsyntaxやXslateなどの様々なテンプレートエンジンをサポートしていることのほか、Dancer2の特徴をマシンガントークで発表していました。英語での発表でしたが随所にpapixさんのアイコンが使われるなど、今年のYAPCネタも盛り込んだ終始大爆笑なトークでした。
941@twitterさん「5分でわかる！技術系イベント運営のコツ」
昨年までYAPCの運営に携わっていた941さんは、その経験を元に技術系イベントを成功させるコツについて話をしました。抑えるべきポイントを抑え、準備をしっかりすることがポイントのようです。理想的な技術系イベントYAPCを挙げるのかと思いきや、ISUCON4を挙げたところで時間切れとなりました。
sojiro14@twitterさん「PERLで世の中の問題を解決するぜ」
捕鯨問題や議員モラル低下問題などの時事ネタをPerlコードで表現して、それをコードで解決するというジョークトークでした。笑いの絶えない楽しいトークでしたが、最後は「PERLで世の中を良くしていきましょう！」という良いメッセージで締めくくりました。
nekokakさん「YAPC::Asia Ramen Challenge」 -
nekokakさんは、昨日bayashiさんに指名された#yapcramen チャレンジを完了しました。次の挑戦者として3名を挙げ、このチャレンジが来年のYAPCまで続けようと呼びかけていました。
Daisuke Muraseさん「エンジニアとして生きる」
キーノートです。昨年独立した村瀬大輔さん（@typester）は、エンジニアとしての自分の生き方が「特殊なのでそのまま参考にするのは難しい」としつつも、キャリアのあり方について話しました。
最初に、就職してからの経歴について紹介しました。新卒で入社した会社では主に受託開発の仕事と自社サービスの開発の両方に携わっていました。また、新規事業開発チームに所属された際には、速いサイクルで様々なWebサービス、スマートフォンアプリを開発していました。受託開発の経験やWebサービスを量産していた経験が、独立した現在の仕事につながっているとのことです。
仕事とは別に、就職して2年目に参加したShibuya.pm Tech Talkでは、内容もさることながらスピーカーたちが楽しそうにしている様子に感銘を受けたと言います。自身のことをシャイだという村瀬さんはスピーカーたちの輪に入っていけず、「 次はスピーカーとして参加する」と決意したとのこと。そして翌年にはYAPC::AsiaやShibuya.pm Teck Talkでスピーカーとして発表しました。
仕事やコミュニティでの活動を経て、自分がやりたいことを考えたという村瀬さんは、「 人生を賭けないこと」よりも「人生を賭けること」に人生の多くを使っていきたいと結論づけたそうです。そのために、自分が得するアプリやサービスを作っていきたいとのこと。エンジニアは自分が得するものを作っていくことで社会貢献ができるため、同じように考えるエンジニアを増やしていけば、世界がもっとよくなると述べていました。
村瀬さんは、好きなことだけをやって生きていくために、自社開発のみでなく受託開発も継続しているそうです。受託開発をやめない理由として、新しい技術に出会えること、新しい人脈ができることなどを挙げていました。ただし、受託開発を楽しく進めていくためにはスキルが必要とのこと。突出したスキルを活かした自分にしかできない仕事という強みがあれば、受託開発も楽しくできると指摘しました。
最後に、20代の方々に「20代でしたことがその後のベースになる」とアドバイスし、エンジニアとしてのロールモデルを見つけて、様々なことを吸収していくことが大事だと強調しました。「 一度の人生楽しまなきゃ損！」だから好きなことを仕事にする。エンジニアにはそれができるのだ、と力強く締めくりました。
クロージング
和田裕介さんによるクロージングです。毎年YAPCが終わるまで夏が終わらないイメージだと「The summer is over」という言葉から始まりました。
今年の来場者は1,361人（昨年は1,131人）だったと発表し、世界で一番大きなYPACであることを強調しました。
続いて、ベストトーク賞を発表しました。1位にはYAPC::NAまたはYAPC::Europeへの派遣が副賞として与えられます。次の上位3人を順次発表し、壇上に上がってもらい目録を渡しました。
1位：うずらさん「半端なPHPDisでPHPerに陰で笑われないためのPerl Monger向け最新PHP事情（5.6対応） 」
2位：tagomorisさん「そんなにビッグでもないデータ処理手法の話」
3位：tcnksmさん「コマンドラインツールについて語るときに僕の語ること」 受賞した発表者の皆さんは、自分に投票してくれた方々に謝辞を述べていました。1位のうずらさんの謝辞の後には拍手とともに「PHP! PHP! PHP! 」という、かけ声が沸き起こっていました（次の写真はうずらさんの謝辞の場面です） 。
最後に和田さんは、スポンサーを読み上げ感謝を伝えました。また、会場ネットワーク回線を担当したCONBU、当日スタッフ等を壇上に呼び、イベントを裏で支えてくれたことに感謝しました。参加者の皆さんはそれを拍手で称えました。
そして来年のYPACについて、たぶん開催されることを告知しました。運営の協力者も募集しているそうです。
2日目のレポートは以上になります。
最後までお読みいただきまして、ありがとうございました。
