20日から22日までの3日間、東京ビッグサイト 会議棟にて「YAPC::Asia Tokyo 2015」が開催されています。本日は2日目、最終日。本稿では、この2日目の模様を随時レポートしていきます（注：すべてのセッションをレポートするわけではありません⁠）⁠。

コーヒーやオレンジジュースなどのドリンクが、7階国際会議場横で提供されています。本日17時半頃までの提供予定とのこと。

Nathan LeClaireさん「PolyglotのためのDocker - 我々はどこから来てどこへ向かうのか」

@upthecyberpunksさんことLeClaireさんは、開発者が複数のプログラミング言語を触るという観点でDockerがどのような問題を解決できるのかといった内容を話されました。

近年、デベロッパを取り巻く開発環境の変化がますます激しくなってきています。つい最近までAngularJSが主流となると思われたJavaScriptの世界でも、今ではReact.jsに注目が集まってきているなど本当に目まぐるしく変化が起きています。

このような状況で、開発に興味がある人が多いのに、開発環境を整えることは大変であることが機会損失になっているとLeClaireさんは指摘されました。例えば、OpenRestyというnginxとluaを使って高速なアプリケーションを開発ためのツールをビルドにするには、エラーメッセージを見ながら必要な依存関係を正しくインストールしていかなければなりません。また、開発者側にとっても、Stack Overflowなどでできあがるビルドができないという質問に対して、質問者の環境を正しく予測しない限り適切な回答をすることができません。Dockerでコンテナを作っておけば、このような問題を解決することができます。

LeClaireさんはDocker Machineの開発リーダーであるため、会場からはDocker Machineについての質問も挙がりました。LeClaireさんによると、今はDocker Machineを導入する移行期にあたる時期で、Docker社でもまだBoot2dockerが主に使われているとのことでした。もちろん、LeClaireさんはDocker Machineを使っています。

Yosuke FURUKAWAさん「どうしてこうなった？ Node.jsとio.jsの分裂と統合の行方。これからどう進化していくのか？」

Node.jsユーザーグループ代表やio.js collaboratorも務める古川陽介（@yosuke_furukawa）さん、node/io.js技術委員会の唯一のメンバーの大津繁樹（@jovi0608）さんが、過去、現在、そしてこれからのNode.jsについて話します。

まずは古川さんの発表から。Node.jsの歴史、成立背景となるc10k問題とそれが現実になっていったWeb 2.0以降の流れを紹介します。人気とJoyentの下での開発、BFDL下でのリーダーの変遷など黎明期のNode.jsが現在に近い形になるまでがわかります。

さて、そんな現在のNode.jsはどうなっているのか。代表的な例を挙げていきます。socket.ioなどリアルタイム性を重視するアプリケーションへの利用、gulpなどフロントエンドツールとしてのnpmエコシステムの人気、エレクトロンはじめデスクトップアプリケーション、AWS Lambds、さらにはIoTなどとサーバサイドに限らず広く使われるようになったそうです。

安定とcutting edge（最新）を求めるエンジニア間の溝や開発の停滞から、2014年にNode forward projectが発足し、Node.jsを停滞から脱却させるために動きます。この団体から、io.jsが2015年1月13日に生まれました。io.jsの開発では、BFDLモデルからの脱却が大きな変化の1つです。io.jsはTechnical Committee（技術委員会⁠）⁠、Working Group、Semantic Versioningに立脚して運営されます。

最新と安定の対立についてはLTSサポートの登場、次期バージョンであるnextブランチと現バージョンのmasterブランチなどで解消しています。リリース後1年半はちゃんとメンテナンスされ、移行期間を設け運用しやすさを向上させます。今年の9月（もしくは10月）にリリースされる4.0も多くの新機能を含み、es6互換性の向上などを果たしました。

Node.jsのコアに対してやれることは以前よりも増えてきた、貢献の仕方がバグレポートやプルリクエストだけではなくなったので興味があったら是非貢献してほしい、と発表を閉じました。

発表の最後には大津さんとのディスカッションです。

Node.jsの魅力、なぜ開発に参加したのかという議題では、大津さんは2011年ごろ（Node.jsのコミュニティ発足は2010年ごろ⁠）⁠、開発がピークのころに参加し始めました。開発が活発だったこともあり毎朝テストの通っていない個所を直すということを続けていったと言います。勢いのある中、開発に参加することの刺激を語ります。一方で古川さんは最初はJavaScriptの学習も兼ねてNode.jsに触れ、Node.jsユーザグループの代表を務めることになりました。緩い言語なのにハイレベルからプリミティブなところまで刺されるのが魅力と言います。その後、io.jsとNode.jsの分裂の混乱を減らしたいと思い、APIが壊れるような両者の分断を防ぎたくio.jsの開発に参加したと言います。

またforkのある種の騒動についての当事者としてどうだったかという議題について、大津さんは当時はネガティブなフィードバックを気にしたと言います。コミュニティを大事にする文化とJoyentが管理していたころはそれに反する部分があり、forkというドラスティックな部分が出ました。fork後は、やはりお家騒動をどうするか、混乱をなくしていくことが大事だったので、圧倒的な開発を見せることでユーザがio.jsをサポートしてくれて短期決戦で統合というところを目指して進めたそうです。

将来的な懸念について、大津さんは今後ちゃんと開発を続けるために、コラボレーターを増やし、新陳代謝を機能させることなどを掲げました。Node.jsとio.jsの今までとこれから、そしてこれからNode.jsをより良いものにするための発表でした。Node.jsの特徴、OSS運営モデルの1つのありかたなどを学ぶことができました。

songmuさん「Mackerel開発におけるScalaとGo、そしてPerl」

データストアの気持ちを考えながらコードを書くのが好きというsongmuさんは、現在開発に関わっているMackerelで用いられている技術について発表されました。

Mackerelはサーバ管理・監視ツールをWebサービス化したもので、もともとははてなの社内ツールでした。現在はエンジニア6人、デザイナ1人、インフラ1人というチームで2週間スプリントのスクラム開発をされているそうです。開発にはさまざまな言語が使われており、メインのWebアプリケーションはScala、データを収集するエージェントにGo、そしてビルドやデプロイの自動化などにPerlと使い分けているそうです。以降それぞれの言語についてどういった理由で選択されたのかと、その良し悪しについて説明されました。

まずはScalaについてです。サーバサイドの開発で使われていてフレームワークはPlay Frameworkを採用されています。Scalaは型安全で大手企業での採用実績も多く、クリティカルなサービスへの利用に向いているとのことです。静的型付け言語ですが表現力が高いのでLLに近い柔軟な記述ができて楽しいそうです。ただコンパイル速度が遅いのが欠点でメソッド単位の細かいテストを書いては動かすという開発方法だとストレスが高めで、シナリオ単位など大きめの粒度でテストを書くようにマインドチェンジの必要性も感じたそうです。Perlとは共通点が多いと感じられているそうで、アンダースコアがいろいろ出てきて省略可能であったり仕様が複雑な点がPerlと似ていてかわいいとおっしゃっていました。

つづいてGoについてです。ユーザのホストにインストールする常駐プロセスのmackerel-agentはGoで書かれており、OSSとして公開されています。ここにGoが良かった点としてシングルバイナリが生成できるためユーザがセットアップするのが簡単であり、かつ常駐プロセスとして重要なメモリフットプリントの小ささを挙げられていました。そのほかコマンドラインツールやURL監視用のクローラもGoで開発されているそうです。Goは型があるにもかかわらずコンパイルが高速で実行速度もそれなりに速く、並列処理が言語組み込みな点が良いそうです。実用言語として割り切られており言語仕様がシンプルなため素朴に書くことが強制されるあたりが、最近シンプルなモジュールが好まれる傾向にある日本のPerlコミュニティとも相性が良いと感じられているとのことでした。

そのほかPerlやRubyの使いどころについても話されました。Perlはベターシェルスクリプトとして最適でスクリプトにテストも同梱できるので、ビルドやデプロイといった規模が大きくなってくると負債化しやすい部分にもテストを書いて対応できるので良いそうです。だいたいどんな環境にも入っているのも利点で渋い脇役として活躍できます。変更の多いWebアプリケーションのフロントエンドにも使いたいとのことでした。Rubyはfluentdやchefなどのエコシステムに乗るために使っているそうです。

最後に特性によって言語を使う分けると楽しいし、なにより便利と締めくくられました。

Kazunori Satoさん「Google Cloud Platformの謎テクノロジーを掘り下げる」

Google, Inc.のKazunori Sato（@kazunori_279）さんは、Google Cloud Platformの裏側で動くGoogle独自のクラウド技術について発表しました。

まず、ビッグデータについては、MapReduceはもう古い技術だとして、BigQueryの内部で使われている高速並列分散処理のコア技術「Dremel」を紹介しました。また、Cloud Dataflowの内部技術「FlumeJava」「⁠MillWheel」の特徴を述べました。

次に、コンテナ技術については、Googleの多くのサービスが昔から「Borg」という独自のコンテナ管理技術の上で稼働していることを話しました。KubernetesはBorgのコンテナ管理技術を参考に、OSSとして開発が進められています。また、ストレージサービスNearlineもBorgの技術の恩恵を受けています。

そして、ネットワークについてはGoogleがハードウェアから自社で開発していることや、GCE Load Balancerの特長について解説しました。

最後に、将来への展望としてDeep Leargingについて話しました。Deep Learningの技術はAndroidの音声認識やGoogle Photoの裏側で既に利用されており、「⁠The Future is Now（未来はもうそこまで来ている⁠）⁠」という形で、発表が締め括られました。

Masahiro Naganoさん「ISUCONの勝ち方」

ISUCONでこれまで2回出題者を経験し、2度優勝を経験してきたというNaganoさんは、ISUCONで勝つための様々な手法を紹介してくださいました。ISUCONはWebアプリケーションのパフォーマンス向上を競うコンテストで、これまでに4回開催されてきました。今年5回目の開催が決定しており、予選の登録が始まっています。ISUCONから生まれたツールが実際に勤め先のWebサービスで使われている例もあるそうで、かなり実際的なコンテストだそうです。

ISUCONは2人か3人で参加が条件となっており、1人では参加できないとのことで、互いにできることがわかっている同僚とチームを組むことが望ましいそうです。時間が限られているのでコミュニケーション環境やリポジトリの事前準備、当日の作業の流れを事前に打ち合わせておくことが大事だと語られました。

また、解析に有用なツールやコマンドについても紹介があり、使い方まで丁寧に説明してくださいました。ネットワーク、DB、CPUなど各レイヤーで何を見るべきか、どう見るべきかを説明して、「⁠何もしないアプリケーションに如何に近づけるかが大事」と述べられました。

最後に、初期状態を残しておいていつでも戻れるようにしておくことと、前日にしっかり睡眠を取ることの大切さについて触れ、「⁠今年のISUCONも優勝する」と意気込みを語られました。

Ricardo Signesさん「Perl 5.22 and You」

現在Perl 5のメジャーリリースは毎年行われるようになっています。そのリリースマネージャ（パンプキン）を務めるrbjsさんからは、最新の安定バージョンであるPerl 5.22の話を中心に、次期バージョンのPerl 5.24についても触れられました。

まずはPerl 5.22で廃止になった機能から紹介されました。今まで警告対象だった@array->[0], %hash->{key}やdefined @array, defined %hashなどはエラーとなります。その他標準モジュールからModule::BuildとCGI.pmが外れたそうです。

つづいてPerl 5.22の新機能です。Perlでよく使われるダイヤモンド演算子（<>）はとても便利ですが、'rm -rfv* |'などパイプ付きの文字列を渡してしまうとコマンドを実行してしまうという危険な面もあります。新しく導入されたダブルダイヤモンド演算子（<<>>）ではこれらは正しくファイル名と解釈されます。その他正規表現のあたらしい記法や()でのキャプチャを抑制するn修飾子、%hash{'a','b'}でhashの一部をsliceする方法などが紹介されました。

また実験的な機能としてreference aliasingが紹介されました。今までarrayやhashリファレンスを扱う場合は$refなどスカラーで受けてarrow演算子で参照する必要がありましたが、\ my %alias = \ %hash という構文を使うことで通常のhashと同じように参照できるようになります。この機能はuse experimental 'refaliasing'で有効になるそうです。

さらに次期安定バージョンとなるPerl 5.24についても発表がありました。Perl 5.24ではUnicode 8.0がサポートされ、Perl 5.20で実験的な機能であったPostfix Dereferencingが正式機能となるようです。これは実験的な機能が正式な機能となる初めてのケースとのことでした。

質疑応答ではダブルダイヤモンド演算子についてなぜ新しいオペレータを加えたのかという質問がありましたが、後方互換性を壊さないためにそうしたとのことでした。

アルパカ大明神[▮▮▮▯▯▯▯▯▯▯]さん「Docker３兄弟について」

@toritori0318さんにより、Dockerをゆるふわに利用するためのDocker 3兄弟として、Docker Machine、Docker Compose、Docker Swarmの3つが紹介されました。使いはじめる際には、Docker Toolboxと呼ばれるGUIツールが適しているという説明から入り、実際にkitematicを用いた実演が行われました。

まず、Docker Machineですが、任意のプロバイダ上にあるDockerサーバを操作する為のツールであり、バックエンドは、AmazonやGoogle等、様々なところがサポートされています。

次に、Docker Composeにより、複数のDockerコンテナから構成される１サービスが、YAMLファイルのみで構築・管理が可能なことが説明されました。

そして、Docker Swarmは、Dockerホストのプールを抽象化し、単一のDockerエンジンとして実行するためのツールです。Swarm Masterが各ノードに振り分ける為、透過的にスケールさせることが出来ることが述べられました。

本セッションを通して、Docker 3兄弟により、開発環境ではDockerが充分利用可能であること、本番環境では課題が多いがロードマップがあることが示されました。また、GUIツールも将来的には連携に組み込まれるのではないかという予想にも触れられました。

Daisuke Muraseさん「サーバーサイドエンジニア(特にPerl)のためのiOSアプリ開発入門」

まずiOSアプリのトークをやろうと思った理由として、Xcode 7では無料で実機に転送できるようになったことや、Swift 2.0のリリースが近いことを挙げ、今がiOS開発を始めるタイミングとしてちょうど良いことが述べられました。

Perlと比較して文法を紹介し、リファレンスカウント方式などの共通点があることが紹介されました。また、実際にデモとしてXcode 7のベータ版を使ってアプリケーションを作る手順をライブコーディングしながら説明していました。Xcodeでは画面遷移が簡単に用意できると言い、ボタンを押すと"Hello, YAPC"と書かれた画面に遷移するデモアプリを実装しました。

また、最後にポイントとして「最初から完璧なものを作ろうとしない」ことなどが述べられました。クライアントサイドで楽をするためにサーバサイドエンジニアとしての能力を駆使してサーバサイドで頑張ることなどがコツだそうです。

Kenji Naitoさん「我々はどのように冗長化を失敗したのか」

「我々はどのように冗長化を失敗したのか」というタイトルでKenji Naitoさんが発表されました。

障害発生時に冗長化したものが正常に切り替わらないことがよくあるという背景の元、式年遷宮のように平常時であっても常に冗長構成のアクティブスタンバイを切り替えることによって、異常時の正常動作を担保しようと試みた話をされました。Redis、MySQL、Consulを利用していかにして冗長化を達成するか。そして、それぞれの構成で使用したツール（Redis Sentinel、mysqlfailover、consul-template）で実際に起こった問題点などを紹介され、最終的に自動化を断念した話をされました。

最後に性能試験や使用する道具への理解の大切さを説き、稼働率のために今後も挑戦を続けるという決意とともに次回作への予告をして締められました。

さいけんさん「MySQLで2億件のシリアルデータと格闘したチューニングの話」

「MySQLで2億件のシリアルデータと格闘したチューニングの話」というタイトルでさいけんさんが発表されました。

CPUが2コアでメモリが8G、diskが450GBという環境で2億件のシリアルデータを扱うという内容でした。負荷テストを行った際に、実際に扱うデータと違う物を用意したが為に、一定件数以降でinnodb_buffer_poolが枯渇し急激にinsert処理が遅くなると言う現象に遭遇したり、update時にシリアルキーがランダムな為、indexの再構築が発生して非常に遅くなり、想定した時間の60倍近く客先でかかってしまって大変な目にあったりした話をされ、いかにしてこれらを乗り越えたかを解説されました。

最後に負荷テストにおけるデータの質や効果計測の重要さを述べて締められました。

Tatsuro Hisamoriさん「実はホットでオープンな Microsoft Azure」

@myfinderさんことHisamoriさんは、マイクロソフトのクラウドコンピューティングプラットフォームであるMicrosoft Azureについて話をされました。AzureはIaaS、SaaS、PaaSすべてをカバーするサービス群であり、2014年に日本データセンターが開設されたことから、現在急速に利用が広まっています。

HisamoriさんはAzureを最初に触れてみるにあたって、Event hubs、Stream Analytics、Power BIを組み合わせたデータ解析を勧めていました。Event hubsは所謂Pub/Subにあたるもので、データの転送を行います。Stream Analyticsはストリーミングデータを分析するツール群で、SQLライクなクエリを使えることが特徴です。そしてPower BIはデータを可視化するツールであり、デモではオフィスの湿度計からのデータを5秒ごとに平均値を取ってグラフ化するということを見せていただけました。

その後Azureのサービスの実現方法について紹介されました。Azureの各リージョンのデータセンターはフットボール場16個分の大きさがあり、これはジャンボジェット機32個機分の大きさに相当するそうです。インターネット人口に応じてリージョンを設置しており、日本だけで東と西の2つのデータセンターがあることが特徴です。ハードウェアは全てコンテナ単位で管理しており、コンテナ内のハードウェアが壊れるとコンテナごと 交換するような運用を行っているようです。

会場からはドキュメントの在り処について質問が挙がりましたが、Azureのドキュメントの最新版はGitHub上で管理しており、間違えている部分についてはpull-reqで報告して欲しいとのことでした。Microsoft社は最近、他にもGitHubを利用していることが多いとのことで、同社のOSSに対する積極的な姿勢が表れているなと感じました。

なお、著者はこのセッションで「Microsoft Azureへの招待」「⁠できるVisualStudio2015」の2冊をプレゼントとして頂きました。ありがとうございました！

平田哲さん「ランチセッションA」

株式会社Fusic 平田哲さんより「福岡の（多分）まじめなWeb屋さんの社内事情について、あるいは社内コミュニケーションのあり方について」と題してランチセッションAが行われました。

社内システムの状況、消えた社内システムと残る社内システムの話、コミュニケーションツールの話、などについて発表されました。

kobakenさん「ランチセッションB」

株式会社モバイルファクトリー kobakenさんより、「⁠空間情報探索基礎論」と題してランチセッションBが行われました。

GeoHex v3などついて発表されました。

Ben Lavenderさん「Adventures in Refactoring」

GitHub社で内部ツールの開発を担当されているというBen Lavenderさんは、リファクタリングを進める上でのノウハウについて発表されました。

リファクタリングは「振る舞いを変えずにコードを変える」ことですが、進めるためには正しい理由が必要です。たとえばコードの一貫性を増すことや、DRYにこだわること、抽象化レイヤーを追加することなどはそれ自体良いことではありますが、これだけのためにリファクタリングをするのは正しい理由ではないと説きます。リファクタリングを進めるにはその効果を測れることが重要です。そのための指標としてコードのdiff statsやテストカバレッジ、パフォーマンスの向上といった計測しやすいものから、テストの説明性の向上や開発者満足度などを挙げられていました。そういった観点からリファクタリングを進めるための正しい理由として、開発者の満足度向上、パフォーマンス改善、技術的負債を返す、開発者の教育を挙げられました。

つづいてテクニックについてです。リファクタリングを進める際には少しずつハッピーになるようにしていきます。またスタイルガイドがあることが大事で、まずはこれを決めてそれを守るように進めて行きます。具体的なテクニックとしてはtransferのような動詞のメソッドををTransactionというような名詞のクラスにしてそのインスタンスにさまざまな状態を問い合わせるようにしたり、_でつないでいる長いメソッド名の一部をオブジェクトに切り出す（例：pull.branch_valid?、pull.branch_exists?などをbranchオブジェクトに切り出す⁠）⁠、1つのクラスからしか継承されていないクラスがある場合はまとめてしまう、といった手法が紹介されました。またリファクタリングの落とし穴として既存のバグ修正と同時にリファクタリングを行ってしまうことや、抽象化レイヤーの追加によるパフォーマンスの悪化を挙げられていました。その他、大規模なリファクタリングへの対処法としてdeprecateにして新しいメソッドを作る、Rubyだとscientistというライブラリを使う手法が紹介されました。

発表後の質疑応答では、「⁠リファクタリングと機能追加の優先順位判断は機能追加に自信が持てるか。なければリファクタリングする」「⁠デザインパターンに従いすぎるとコードがテストにフィットするようになりがちなのであまり好きではない。良いテストは良いコードの結果であるべき」といった興味深い回答を聞くことができました。他にもたくさんの質問が行われ、リファクタリングについて課題意識を持っている開発者が多いことを感じさせられました。

Miki Horiuchi Kabeさん「Perlでゼロから作るコンテナ」

ポーリーマーティ（@maokt）さんと堀内美希（@nukamu）さんによるコンテナに関する発表です。Docker以降注目を集めるLinuxのコンテナ技術。発表者2人が所属するゴールドマンサックスもコンテナ関連のプロジェクトに参加していると言います。

Dockerはかっこいいが必ずしもすべての機能が必要とは限らない、たとえばクリーンな環境が使いたいだけならLinux Containerで充分、また自作して技術詳細を理解することができブラックボックスなしで使えると判断しお2人はコンテナの調査をしたそうです。Dockerコンテナを大型の貨物コンテナ、より薄いコンテナを段ボール箱にたとえ、必ずしもDockerにたとえる必要はないことを説明します。コンテナは外の世界から中身を守ることができ、逆に外の世界はコンテナ内から守るものです。

多くの標準システムコールはPerlから直接使用可能で、直接使えないものもsyscall関数で利用することができるため今回はPerlのコードを使って解説していきます。

コンテナの理解に必要となるLinuxの前提知識として、プロセスやケーパビリティ、ファイルシステムなどについて解説したのちにコンテナの構成について解説します。今回のコンテナを作るうえで重要だったのはマウント名前空間（Mount namespace）とユーザ名前空間（User namespace）とunshareです。マウント名前空間とユーザ名前空間の組み合わせによる、通常ユーザでのコンテナの利用など2つの名前空間でできるコンテナの仕組みがわかりました。

Masahiro Nakagawaさん「データ分析基盤を支える技術」

このセッションにおいては、1からデータ分析基盤を作るまでの一連の流れが@repeatedlyさんによって説明されていました。

まず紹介されたのは、シンプルなRDBMSです。シンプルでエコシステムが充実しているので、スタートアップ等の小規模では充分に活躍可能です。しかし、大容量のデータでは破綻することが述べられました。

この破綻を防ぐのがParallel RDBMSです。列指向と分散処理により、分析クエリに特化しています。しかし、データモデリングとクエリの設計にノウハウが必要なこと等、種々の問題を持っていました。

ここで登場するのが、Data Lakeという概念です。大きなストレージ、例えばHDFSに生のデータを保管し、そのデータをHadoop等によって処理することで、データモデリングや負荷の差異を吸収するというものでした。

そして、バルクロードやストリーミング等、データ保存の為のサービス、RDBMSやHadoop等、データストアを選ばないMPP query Engine等、様々なサービスが紹介されました。

これらを組み合わせて運用するのは、かなりコストが高いため、Amazon、Google、Treasure Data等、各社から便利な物が提供されるようになりました。エッジな分析がサービスの肝でない限り、これらクラウドの波に乗るほうが有利であり、目的にフォーカスして選択して欲しいとのことでした。

SHIBATA Hiroshiさん「3分でサービスのOSを入れ替える技術」

SHIBATA Hiroshi（@hsbt）さんは、GMOペパボで運営するサービスにおけるサーバ構築・運用プロセスを改善し、非常に短い時間でWebアプリケーションサーバのBlue-Green Deploymentを実現するに至りました。

まず、サーバセットアップ作業を高速化するにあたり、cloud-initやPuppetによって、OSの初期設定やミドルウェアのインストール・コンフィギュレーション作業の自動化を行いました。

また、サーバイメージの作成を2段階で行うことで、サーバ起動からサービスインまでの時間を大幅に短縮しました。最小限のイメージを基に、Webサーバやアプリケーションサーバについて、すぐにサービスイン可能なイメージを作成するようにしました。イメージのビルドにはPackerが使われています。

一方、アプリケーションのデプロイについては、Rails bundleによってアプリケーションをパッケージ化したものをS3のようなオブジェクトストレージにアップロードし、各アプリケーションサーバから最新のパッケージを取得する「Pull型デプロイ」の仕組みを構築しました。

Jonathan Worthingtonさん「Parallelism, Concurrency, and Asynchrony in Perl 6」

Perl 6の新しいバックエンドであるMoarVMの作者であるJonathan Wothington氏の発表です。混同されることが多い並列処理、並行処理、非同期処理について、Perl6ではこれらをどうやって扱っているのかを解説しました。

Perl 6にはPushモデルのイベント処理であるSupplyやgather-take（ジェネレータ）の非同期版であるwhenever-emit、効率的な排他制御を行うクラスを定義するためのOO::Monitors、OO::Actorsのようなモジュールなどが用意されていることを紹介しました。特にOO::MonitorsなどのモジュールはPerl 6の特色の一つでもあるメタプログラミングを駆使しており、おどろくべきことに外部モジュールながらたった50行程度で実装されているそうです。

Perl 6では、様々なシチュエーションに対応するためにいろいろな選択肢を提供する方針だといいます。ただし実装の複雑な部分はインフラの中に隠蔽してしまい、プログラマが難しいコードを書かかなくても済むようになっており、保守性、可読性、診断性を確保できるようなコンセプトになっていることを述べました。

鎌田武俊さん「【特別企画】YAPCあるある（仮）」

株式会社オモロキのスポンサードセッションです。YAPC::Asia Tokyoでこれまで実行委員長をされてきた宮川さん、竹迫さん、牧さん、櫛井さん、和田さんの5人が集まって、これまでのYAPCを振り返りました。YAPC::Asia Tokyoは10年間で来場者が300人から2,000人に、スポンサー企業は6社から60社に、大きく規模を拡大してきました。

牧さんは充分な引き継ぎがないまま2009年のYAPCを開催することになってしまったと述べ、契約をスムーズに進めるためにJPAを法人登記したり、カメラマンに写真を撮ってもらったりと、次年度以降に繋がる活動を推し進められたそうです。その大変さから、2010年には櫛井さんを迎え、大きく体制を変更されたとのことでした。この頃から遠方支援制度など様々な企画が実行されるようになったそうです。2013年に慶応大学に移ってからは、CONBUが会場内ネットワークを担当してくれるようになったり、コーヒーを大量に用意したり、現在のYAPCに近い形になったとのことでした。

質疑応答では、10年間で印象に残ったトークやどのように新規の参加者を取り入れ規模を拡大していったかが語られました。牧さんは運営が忙しくトークは全然見れていないとのことでしたが、印象に残ったLTとして竹迫さんのマインスイーパを題材にしたLTを挙げられました。最後に、ゲスト一人一人から、YAPCが10年続いてきたのは参加者やスポンサーのおかげだと感謝の意を述べられました。

Brad Fitzpatrickさん「Profiling & Optimizing in Go」

「Go Debugging, Profiling, and Optimization」というタイトルでBrad Fitzpatrickさんが発表されました。発表は、実際に遅いプログラムを書いてそこから、HTTP、レースコンディションのテストの方法、またCPU、Memory Profilingから正規表現、メモリ最適化、データ構造の解説からの最適化、アロケーションの削除による最適化、そして最後に並列のベンチマークとカバレッジの取得方法を紹介されました。これらのデモから、最適化に必要な情報が標準で用意されたツールによって簡単に得ることができるGoの良さが伝わってきました。この良さを活かして、デモで用意されたプログラムがあっという間に修正されていくことを楽しむことができた素晴らしい発表でした。

質疑応答では、ベンチマークのツール、常駐プログラムでのメモリリーク検知ツール、GUIのツール、ご本人が気に入っているGoのtool、Goのnativeでのdaemonサポート等の沢山の質問が挙げられ、Goに対する関心の高さをうかがい知ることができました。

Satoshi Ohkuboさん「Perl で RTB の最前線を闘い抜く」

@bonnuさんことOhkuboさんは、RTBについてお話しされました。RTBとはReal-time Biddingの略で、広告表示時に表示を行う権利を賭けてリアルタイムに行われるオークションのことです。

オークションに参加して広告を表示する側であるDSPについて、@bonnuさんは「広告枠と広告を見ている人にとって、最適な広告を導くこと」がミッションであると説明されました。そのためにユーザの行動履歴をKVS上に蓄え、適切な広告を選ぶための判断を行っているそうです。

応答時間もRTBでは重要であり、レイテンシを考慮すると50msでレスポンスを返す必要があるとしました。そのため、RDBMSなどネットワークアクセスは行わずに、アプリケーションサーバ内のRAMディスクの情報のみを参照してレスポンスを返せるようにシステムを構築しているとのことでした。

CONBUさん「カンファレンスネットワークの作り方」

とうまつひろみちさんと@takano32さんによるYAPCで構築されていた無線ネットワークに関するセッションです。

CONBUはもともとLL系イベントのネットワークを構築していたチームが主体となって2014年に組織されたチームであり、カンファレンスのネットワーク構築を専門に行う団体です。CONBUはイベント開催者のニーズに応えるという目的があるのはもちろんですが、インフラ構築の技術を磨くというインフラエンジニア達の、ソフトウェア技術者で言うところの「趣味プログラミング」にあたる場とすることも目的としているそうです。

tsubasaさん「オープンソースエンジニアのための Windows入門」

tsubasaさんはOSS製品（UNIX系OSなど）を利用する開発者向けにWindows（サーバ）について発表します。これからのMSは挑戦者としてモバイルファースト、クラウドファーストで行きOSSとも協調していくと考えるtsbasaさん。

Windows OSの種類と特徴から紹介。Linuxなどに触ることの多いOSSエンジニアにはわかりづらい、クライアント系とサーバ系など、基礎的な事柄についても紹介。

Windowsサーバを導入した時もLinuxサーバとやることはあまり変わらないとして、Linuxでのこの機能はWindowsではどうやるのか、を解説していきます。設定をGUIでできるのがWindowsの強み。

WindowsとUNIXの哲学の違いから、似たような機能でも使い方や形式に差が出ることを一つ一つ解説していきました。LinuxとWindowsのパーミッション形式の違いなどにも言及し、Windowsに慣れないユーザでもWindowsサーバに入門しやすくなる情報を解説しました。TechNetの歩き方、MSの膨大な公開情報から必要な情報にたとりつくコツなど、学習リソースも最後に示してくれました。

OSS開発者にとってWindowsサーバは縁遠いところがありそうですが、今回の発表で興味を持った方も多かったのではないでしょうか。

Jxckさん「HTTP2 時代の Web」

HTTP/2は既存のHTTP/1.1の後継として今年の2月にRFC7540が登録され、nghttpやh2o、http2goなど様々な実装が進められているプロトコルです。発表者によると、HTTP/2は策定フェーズから使うフェーズに移行したといいます。

HTTP/1.1には様々な問題があり、いままではバッドノウハウを駆使することでそれを回避してきたという背景があります。しかしHTTP/2ではヘッダの内容をバイナリ化したり、一つのコネクションの中で複数のストリームを利用するなどの方法を用いて通信を効率化しています。また、現代のWebではレスポンスタイムだけで体感的な速さを計測することは難しく、そういった意味でも効率的なコンテンツの配信が行えるHTTP/2の優位性が紹介されました。

HTTP/1.1が消えることはないので、使い続ける戦略が間違っているわけではないと言います。ただし、HTTP/1.1を使い続けることが本当に低コストであるとは限らないとも付け加え、まずは「よく知らない／導入しない」から「理解した／導入しない」へのステップアップが重要であるということを述べていました。

Yuichiro SAITOさん「辛いことをやめる！から始まる業務改善とInfrastructure as Code」

組織の生産性を向上させていく仕事をしているというSAITOさんは、業務改善に2年間取り組んできた経験を語ってくださいました。サーバの構築や運用・保守を仕事としてきた中で、IaaSの台頭によってそれまでのマニュアルオペレーションが時代遅れになってしまったそうで、残業が増加し新たな仕事を受ける余裕を失って辛い状況に陥ってしまったのが業務改善のきっかけだったそうです。運用にも新しい技術を取り入れ自動化を進めることで作業時間を減らすことを目指したとのことでした。

自動化を進めるにあたって、オペレーションの安定性など心配する声も少なからずあったそうで、メリットを伝えていく必要性を感じたそうです。主張の異なる同僚と敵対せず、全員が納得したうえで変化していくことが大事だと述べられ、納得してもらうためにも作業の難易度やコストを評価してメリットを可視化することを提案されました。変化に対して皆が積極的ではないとのことで、重要な人を巻き込むこと、メリットをしっかり説明すること、疑問の声が挙がったらすぐに対応することの重要性を説かれました。他にもドキュメントを用意することや、ハンズオン勉強会を開催して実際に試してもらうことでメリットを体感してもらうことも効果的だそうです。

実際に2年やってきた結果、業務改善自体に3ヵ月程度かかったそうですが、改善による作業時間の短縮はそれ以上の効果があったそうです。効果をしっかり測定しておくことは、自身の仕事のアピールにもなるのでやっておいたほうが良い、と述べられました。また副次的な効果としてプログラミングで運用が楽になる、ということを多くの同僚に知ってもらえたそうです。最後に、変化は怖いが恐れずに変化を受け入れていくこと、変化を周囲の人にも誠意をもって伝えていくことが大事であるとまとめられました。

「Lightning Talks Day 2」

yoku0825さん「MySQL 5.7の罠があなたを狙っている」

2015年8月現在、MySQL 5.7はリリース候補版が出ています。しかし、そこには多くの罠が潜んでいました。この発表では、余計なお世話パラメータから仕様変更まで、知らなければ、業務上問題が出てしまうような数々の罠が、ジョークを交えつつ紹介されていました。

magnoliaさん「吉祥寺.pmというイベントを作った話～聞きたいトークが有れば自分でイベントを作ろう！～」

勉強会に参加しようと思っても、好きなテーマのものが自分の参加できる日程では開催されていないという問題はよく起こるかと思いますが、magnoliaさんはそれを解決するために自分で勉強会を作ってしまったそうです。開催地が近く懇親会に出ても帰りやすいことも魅力です。

Satoshi.Sさん「a good naming makes a good design」

LTは記念写真の撮影と、YAPCに対する心情の吐露から始まりました。話は本題に戻り、良い命名を作れば、自ずと良い設計が生まる、また役割を適切に分割して、命名された以外のことをさせないことが重要だと述べていました。最後に、このLT自体が、命名の話以外をしているのは良くないとして、自己言及的に命名の大切さを説いていました。

HIRATA, Satoshiさん「botになる技術」

社内でSlackなどのbotを作ることは最近のエンジニアであれば誰しも行っているかと思いますが、HIRATAさんは自分の発言ログを収集されてbotを作られてしまったそうです。botの利用目的は八つ当たりや暇つぶしなど良い内容ではありませんが、それでも「生きる」ことがbotになるために必要な技術であるとして会場の笑いを誘っていました。

zoncoenさん「モダンなクライアントサイド JavaScript に追い付くためのための小さな（しかし大変な）一歩の話」

React、Angular、WebPack、Browserify、Babel等、モダンなクライアントJavaScriptに追い付きたいというのは、誰しもが考えることです。このLTでは、1,200行を超えるCoffeeスクリプトや、jQuery 1.xのような古いライブラリ、広範囲なグローバル汚染等に対して立ち向かい、第一歩を踏み出した姿が紹介されていました。

Koji Ishimotoさん「Evaluating your stylesheets」

デザイナーやコーダーの同僚が書くCSSの品質について、誰しも疑問を持ったことはあるのではないでしょうか。Ishimotoさんはstylestatsという解析ツールを作って、実際に解析することでその疑問を解消したそうです。解析できるMetricsは30種程度あるとのこと。

Kazuhiro Osawaさん「Thank you for ${^ENCODING} variable」

Perlの ${^ENCODING} という変数をご存知でしょうか。最近使われることは少ないですが、昔はCP932等の文字コードを扱う際に、利便性が高く重宝されていたそうです。${^ENCODING} が Perl 5.22でとうとうdeprecatedになるということで、時のうつろいに思いを馳せ、これまでの功績に感謝をしたいということが述べられていました。

moznionさん「本物の "ロック" ってやつを魅せてあげますよ - 分散排他ロック篇」

分散実行環境によって排他ロックを実現するために必要なツールとしてRedisやmemcached、RDBMSなどの選択肢がありますが、moznionさんが選んだのは電話。通話状態、通話中状態を使って排他制御ができ、かつ、1876年から実績のある非常に枯れた技術であるとしました。

Twilioを使ったデモをする予定でしたが、練習でコール回数の制限を超えたためにデモはできなくなってしまいました。

cho45さん「コミュ力あげてこ」

コミュ力を鍛えるツールのデモが始まりました。スピーカーから聞こえて来たのは、「⁠トンツーツートン……」という音。そう、電話より歴史のある、世界的で伝統的な通信手段、モールス信号のWebAudioでの実装です。情報量が少ない分、コミュニケーションのプリミティブな嬉しさを感じられる、そんなモールス信号をやろう、と紹介されていました。

Hirotaka Tajimaさん「CONBUの道具箱」

CONBUチームが今回設営したネットワークは1.6km以上のLANケーブルを使っていますが、今回はそれを1時間で設営したそうです。その証拠としてLT時間内で実際にアクセスポイントの設営と撤収を行いました。とてつもないスピードで設営も撤収も行うその手際の素晴らしさに、会場から大きな拍手が送られていました。

Kuniwakさん「Vim script静的解析の光と闇」

Vim scriptの静的解析をするうえでの闇が語られていました。redi[r]による意図しない変数宣言や、Perlの2倍である10種類のスコープ、mapによる再帰展開等、静的解析をするうえでの苦しみが描かれていました。この闇を地道に乗り越えることで誕生したvint、皆さんも使ってみてはいかがでしょうか。

Daisuke Makiさん「クロージング」

牧さんはまず「皆さん楽しんでいただけましたか？」と会場の参加者に問いかけました。

牧さんはこれまでのYAPC::Asia Toykyoについて振り返りました。YAPC::Asia Tokyoは2006年から始まり、2009年からそれまでの主催者から牧さんに引き継がれたそうです。2010年開催時は櫛井さんに表舞台に立っていただき牧さんは裏方に回り、2013年で牧さんは引退、2014年は和田さんに引き継がれました。

そして2015年に牧さんは復活しました。

YAPC::Asia Tokyo 2015は2日半まるまるのお祭りとのことです。スポンサーは60社、スタッフは約90名、LT含め約90個のトークを参加者に楽しんでいただきました。来場者は2130名とのことです。

「皆さまのおかげでYAPC::Asia Tokyo 2015を開催できました、本当にありがとうございました」と牧さんは述べました。

牧さんはスタッフのほぼ全員を集め、会場の参加者からあたたかい拍手をいただきました。

次にベストトーク賞の発表です。第3位から順にベストトーク賞が発表されました。

第3位は「HTTP/2時代のウェブサイト設計」のKazuho Okuさんです。「⁠骨付きももハム まるごと1本！」が贈られました。Kazuho Okuさんはハムを狙っていたとのことでした！

第2位は「HTTP2 時代の Web」のJxckさんです。Jxckさんもハムを狙っていたとのことですが、Apple Watchが贈られました。

そして第1位は、「⁠Perlの上にも三年 ～ ずっとイケてるサービスを作り続ける技術 ～」の趣味はマリンスポーツですさんでした。発表後はPerlコールと拍手が沸き起こりました。趣味はマリンスポーツですさんには、Surfaceなど「豪華マイクロソフト詰め合わせセット」が贈られました。

次にYAPC::Asia Tokyo 2015最後のご挨拶です。

牧さんのYAPC::Asia Tokyoはこれで終了です。

そのとき、参加者の一人が壇上に上がり、牧さんにプレゼントを贈りました。

牧さんはこれまでのYAPC::Asia Tokyoに関わってきましたが、これで終りとのことです。しかし、YAPC::Asiaの名前はだれのものでもないので、皆さまが行いたいYAPC::Asiaがあれば続けていただければ、また皆さまとどこかでお目にかかることができればと思います、とのことです。

皆さまがいてくれてこそのYAPCです、皆さまが来てくれて、皆さまが話してくれて、皆さまが拍手してくれることによってYAPCができあがります、牧さん自身は会場を提供しているだけであり、スタッフや皆さまがYAPCを作っていく、と述べました。

そして絶対に忘れないでほしいことは、YAPCについてブログを書いてください、とのことでした。

そして牧さんは、約束はしません、と何度も繰り返して述べ、スクリーン上のURLに行くとなにか書いてあります、とのことでした。また2016年は絶対になにもしません、とも述べました。

牧さんは、以上でYAPC::Asia Tokyo 2015は本当に終了、皆さん、本当にありがとうございました、と述べて、会場は拍手喝采でした。

牧さんは最後の最後に、アンコールはございません、忘れ物を持って皆さま粛々とお帰りください、として締めました。

2日目のレポートは以上になります。

最後までお読みいただきまして、ありがとうございました。