20日から22日までの3日間，東京ビッグサイト 会議棟にて「< a href="http://yapcasia.org/2015/">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も優勝する」と意気込みを語られました。