YAPC:: Asia 2014 1日目レポート［更新終了］

本日28日から30日までの3日間、慶應義塾日吉キャンパス協生館にて「YAPC::Asia Tokyo 2014」が開催されています。本日は1日目。本稿では、この1日目の模様を随時レポートしていきます（注：すべてのセッションをレポートするわけではありません⁠）⁠。

受付でもらえるパスカード。その名刺には、参加者の皆さん自らが名前を書く形になっています。

オープニング

オープニングの挨拶は、JPA director／YAPC::Asia 2014実行委員長の和田裕介さん（@yusukebe）です。テーマは「There is more than one way to enjoy it!」とのこと。YAPCではトークを楽しみ、スピーカーと交流してほしいと言います。そのために、無限珈琲、かき氷、Red Bull（ Girls）などの飲み物等も用意したそうです。

また、注意事項のほか、ベストトーク賞の投票を忘れないでほしいこと、イベント用のハッシュタグは#yapcasiaであること、ブログを書くまでがYAPC::Asiaであることを紹介しました。

Abigailさん「Releasing perl⁠」⁠

Perlのリリースマネジメントについてのトークです。以前、PerlのリリースはPumpkingと呼ばれる限られたPerlのコア開発者たちによって行われていました。Pumpkingの仕事は非常に困難で、成し遂げたあとは燃え尽きてしまう人もいたほどだったそうです。特に、Perl 5.8がリリースされてから、Perl 5.10がリリースされるまでには5年以上もの月日が必要だったとのこと。その頃には誰もPumpkingの仕事をやりたがらなくなってしまったそうです。

その後、Perlのリリースを定期的に行うことが提案され、開発リリースは一ヶ月に一度、メジャーリリースは一年に一度というスケジュールで行われるように変わったそうです。さらに、Pumpkingにリリース関連の多大な作業をする必要がないように、ツールやドキュメントを整備したとのこと。その結果、現在では以前に比べて作業にかかる時間も大幅に減り、様々なプラットフォームでのテストもスムーズに行えるようになったと述べていました。

現在では、直近5年間で計74回のリリースが行われ、その間に燃え尽きてしまったPumpkingはいないそうです。

Satoshi Suzukiさん「インフラエンジニア(狭義)は死んだ」

studio3104さんこと、Satoshi Suzukiさんの話したテーマは、インフラエンジニアがプログラミングとどう向き合っていくべきかということでした。Suzukiさんは新卒の頃にC++やJava、PHPなどのプログラミングに挑戦したのですが、馴染めずに一度挫折したそうです。しかし、今では色々なOSSのプロダクトに向き合い、コードも積極的に書いているそうです。

ところで、インフラエンジニアとは一言でいうとどのような仕事でしょうか。Suzukiさんによれば、一口でインフラエンジニアと言っても電源から物理サーバ、データベースまで含めて多岐にわたるため、一概に定義することはできないと言います。また、最近はデータホテルやハートビーツ、AWSなどの仮想化技術が充実しており、データセンターに行かないインフラエンジニアも増えているそうです。

そのような状況の中、「⁠おぺかじ！」というイベントを自ら主催され、そこでSuzukiさんが得た教訓が「自称が自意識に影響を与える」というものでした。これは、自分をインフラエンジニアと呼ぶことで、無意識のうちにプログラミングを避けていないかということです。そこに気がついたSuzukiさんは、業務やプライベートでとにかくコードを意図的にたくさん書くようになり、OSSへpull-requestを送ったりするまでになったそうです。

また、コードを書けるようになる秘訣として、仲間を作ることを挙げていました。Suzukiさんの周りには有名なOSSのプロダクトの開発者が多数いて、色々なアドバイスをもらって自身の糧としてきたとのこと。最後に、インフラエンジニアでもアプリケーションエンジニアでも、これはやらなくていいという仕切りを設けずになんでもやることが大切と、自身の経験から得たことを参加者に伝えていました。

マコピーさん「Perl meets Real World ～ハードウェアと恋に落ちるPerlの使い方～」

もともと電気工学を学んでいたというマコピーさん。しばらくハードウェアからは遠ざかっていたそうですが、昨年仕事で調べてみて最近のハードウェアの進歩を知って学習を再開したそうです。

まずはこの分野で代表的なハードウェアであるRaspberry PiとArduinoを紹介しました。

Raspberry Piはもともと発展途上国向けのIT教育を目的として作られたハードウェアですが、比較的性能が高く普通のLinuxが動くほどだそうです。Linuxが動くため、もちろんPerlも動きます。クレジットカードサイズとコンパクトで4,000円程度と安価であり、初心者向けにも環境が整っていることもあり広く活用されています。

いっぽうArduinoはRaspberryPiとは違い、電気を扱うことに特化していて、CPUなどの処理性能は非常に低いそうです。四則演算ぐらいが精一杯だそうで当然Perlは動きません。ハードウェア単体では非力ですがエコスシステムが強力で、専用のIDEやライブラリ・Arduinoを前提としたキットがたくさんあるとのこと。

普段はこれらを組み合わせて使うことが多く、Raspberry Piはエンコードなどの重たい処理を行いたい場合に、Arduinoは自作の電子部品を使いたい場合やライブラリがある場合、高速なPWM制御を行いたい場合に利用するなど、使い分けているそうです。

続いて、オープンハードウェアを紹介しました。ハードウェアの世界ではソフトウェアのソースコードにあたるものとして、ファームウェア・回路図・部品情報・基盤配置図があります。オープンハードウェアとはこれらが公開されているもので、Arduinoもその一種です。これにより、小型化されたものなど、多数のクローンが公開されていると言います。自作したものでもArduinoの仕様にしたがっていればエコシステムに乗ることができるため、ハックをうながす素晴らしい仕組みと述べていました。

その後、Perlを使ってArduinoを制御する方法を解説しました。マイコンとPC間をやりとりするFirmateというプロトコルがあり、これを使うことでPerlからArduinoに簡単にデータを送ることができます。ここでWebアプリからArduinoで制御された初音ミクにネギを振らせるデモが行われる予定でしたが、トラブルにより省略しました。

最後に3Dプリンタの登場などハードウェアの世界もどんどん進歩しており、自作ハードウェアも簡単に作れるようになっているので、もっとハードウェアの人と繋がりたいと呼びかけていました。

Kenji Naitoさん「完成されたシステムなどない。完成された人間もいない。あるのは成長し続ける未完成なシステムと、それを支える未完成な人間だけだ」

Kenji Naito（@kenjiskywalker）さんは、Webサービスを開発・運用するために必要なこととして記録や保険、再現性、簡易性だと言及し、その理由をWebサービスが成長する過程とともに説明しました。

ハードウェアは絶対に壊れますし、人間は必ずミスをしますが、そのような場合でも元に戻せるようにしておくために記録と保険が重要で、また、スケールアップ・スケールアウトなどの変更に強いシステムにするために再現性や簡易性が重要だと言います。サービスが成長し、バッチやキャッシュ、キューなどが追加される際にも再現性、簡易性を意識し、疎結合なシステムにするべきとのことでした。

ただ、記録、保険、再現性、簡易性の精度に関してはリスクとコストに応じて、その都度判断する必要があると指摘しました。

また、「⁠The UNIX Philosophy」という書籍や式年遷宮、長屋から、変化に強くシンプルにすべきという哲学が学べるとし、インフラも変化に強くあるべきと述べていました。

発表は20分で終わったため、残りの時間は質疑応答となりましたが、良い質問が多く、後半はKenji Naitoさんのトークショーのような雰囲気でした。

Daisuke Makiさん「Go For Perl Mongers」

YAPC::Asiaを引き継ぎ会長となった牧さん（@lestrrat）のセッションでは、Perl（を含むLL）利用者がGoを利用するときにハマるポイントを自分自身の体験を元に紹介しました。

GoはLLっぽいノリで書けるCのようであると述べ、オブジェクト指向やTry/Catchに対する考え方のシフト、goroutineやchannelといった並行処理を行う上でのTipsについて紹介しました。「⁠LLのノリ」を「Goのカルチャーに合わせたノリ」にマインドシフトしなければ、半年・一年後には「Go使えない」となってしまうことを懸念したことが今回の発表のモチベーションとなっていたようです。

例えば「オブジェクト」での再利用ではなくAPI単位の細かいレベルでのコードの再利用を考えることや、goroutineはPOSIXのスレッドではないためSIGNALではなくchannelによって制御しなければならないこと、exceptionのノリでpanic()を使わないことなど、Goを使う上でLLとの違いを分かりやすく説明しました。

最後は「When in Go, Do as gophers Do（Goに入りては、Goに従え⁠）⁠」という言葉で締めくくりました。

Dan Kogaiさん「Introducing Swift - and the Sunset of Our Culture?」

@dankogaiさんはAppleが6月に発表した新言語Swiftについての話題を中心に、オープンソースやPerl文化などについて発表しました。

最初に会場の参加者にSwiftの認知度について尋ねたところ、聞いたことがあるという人はほぼ全員でしたが、使ったことがある人はほとんどいないという状況でした。

まずはSwiftの言語仕様を紹介しました。おなじみのHello Worldからです。Java・C++に代表されるコンパイル型言語ではmainのようなエントリポイントがあるのが一般的ですがSwiftはPerlなどと同様にprintln("Hello World!")だけで出力することができます。

その後はプログラマおなじみのFizzBuzzコードをブラッシュアップしていきながら、fizzbuzz[n]のようにメソッドを添え字で呼べるsubscriptや無限リストを実現できるgenerator、operatorの再定義など、Swiftの機能が紹介していきました。operatorの再定義について、最近はできない言語が多いのでお気に入りの機能だそうです。すごい新しい言語というよりは変なところなはいという印象で、参照カウントなど内部処理も似ているところがありこれはPerl6が目指した形ではないかと思ったそうです。簡単に書けて速くて静的型＋型推論がある言語として気持ちいい言語だと述べていました。

続いて、プログラミング言語の潮流についての考察を発表しました。近年はPerlやRubyのようにコミュニティベースでボトムアップ的に育ってきた言語よりも、JavaやJavaScriptなど企業が提供するトップダウン的な言語が伸びているとし、Swiftの可能性についても強調していました。現状Apple製品用の言語ということになっていますが、言語にAppple固有の機能はないため、いずれオープンソースにするのではないかと予測しているそうです。今はオープンではないため互換性のない変更を2週間で実施できる点など、あえてすぐにオープンにしないことの利点についても述べていました。

最後に、Perlが選択されなくなってきているのは認めざるを得ないが、今すぐなくなることはないし、言語は一つではないのでPerlマインドをシェアしつつ、それをシフトしていけるようにしておくことが大事だと締めくくりました。

Yusuke Yanbeさん「最近のウェブサービスの検索機能やその先の話」

はてなブックマーク開発チームに所属しているYusuke Yanbe（id:yanbe）さんは、はてなブックマークなど、はてなのWebサービスの検索機能の裏側で最近利用しているElasticSearchによる実装と今後の展開について発表しました。

はじめに、はてなブックマークに最近ついた検索機能とPressoについての紹介があり、その後、はてなブックマークの検索機能が、古き良きSQL LIKEから、Senna、Sedue、Solr、ElasticSearchに変わっていく流れをその時の状況を交えて説明しました。

ElasticSearchの良いところは、1)文書をフィールド毎に全文検索できるだけでなく、構造、文書間の親子関係も持てること、2)Search::Elasticsearchという、PerlのライブラリをElasticSearch, Inc.が公式にメンテナンスしており、すべての機能が利用できること、3)メンテナが気をつけてるらしく変な思想がないこと、4)拡張性が高いこと、5)レスポンスが単なるHASHREFで簡潔なこと、だと言います。

導入のポイントは、検索インデックスの構成とQuery DSLの自由度で技術的に難しい企画要件にも耐えられる点と、RDBMSだとスケールしにくい処理をオフロード可能な点があったことでした。はてなブックマークと、Pressoにおける具体的な利用例とともに説明していたため、とても分かりやすい説明でした。

また、検索以外でもはてなブックマークカウンターでElasticSearchを利用しており、Webサイト全体のブックマーク数を集計する部分をAggregation APIで実装しているそうです。

最後に、ElasticSearchの今後予想される展開として、集約系機能の強化、データマイニング機能、より高次の機械学習アルゴリズムのサポートが挙げられること、今後利用が見込まれそうな分野として、APIがJSONなため、Webクライアントから直接利用したり、アドテクなど高度でリアルタイムな検索集約機能を活用したBtoBサービスなどを挙げていました。

はてなブックマークのような大規模なサービスでの利用例を聞くことができ、ElasticSearchの導入を検討していたり、サービスに検索機能を追加したい方にとって大変有意義な発表だったと思います。

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

@tokuhiromさんは、Perlのテストフレームワークの歴史と、多くの既存テストフレームワークが依存しているTest::Moreから脱却した新しいテストフレームワーク「Test::Kantan」を紹介しました。

「品質担保のためには書かざるをえないが、テストは好きではない」と言及し、それを解決するために、これまでにも「Test::SharedFork」「⁠Test::Pretty」「⁠Test::Ika」などを開発してきたそうです。これらはTest::Moreが利用しているTest::Builderの書き直しであり、夢がつまった「Test::Builder2」のリリースを期待し、待つ間のワークアラウンドとして開発・利用していたそうですが、残念なことにどこかで聞いた話と同じように開発停止が決まってしまったため、このたび「Test::Kantan」の開発・リリースを行ったとのことです。

Test::Kantanは、JavaScriptのテストフレームワークJasmineにinspierされ、BDDスタイル、before_each/after_eachなども実装されており、RSpecのように書けると説明しました。Assertionも従来のokを利用できつつもコードブロックを渡せるなどの改善が加えられただけではなく、expectメソッドも提供しBDDのスタイルでのテスト作成ができるそうです。

なによりこれまでの「慣れないと読みにくい、慣れても読みにくい」テストの出力結果を「美しい色で表示することは大事」「⁠Unicodeの記号使えるとカッコイイ！」と大きく改善したそうです。

committerを募集しているそうですので、我こそはという方は利用してPerl界のテスト環境の改善に参加してはいかがでしょうか？

ランチセッション

DeNAの古川さんはQuizNowの開発や自らが代表を務める日本Node.jsユーザーグループのコンサルタントを手掛けています。今回、古川さんはQuizNowのチーム作りについて話しました。

チーム作りは、その場のノリを大切にし、思いつきを重視すること、また、万人受けするものではなく、特定のユーザーに受けて突き抜けるくらいが大事であると言います。そして、自分のスペシャリティをシェアすることを挙げました。デザイナーがプログラミングを覚えたり、エンジニアがデザインを覚えたりと、完全分業でやるよりもお互いの中間を埋め合うために、シェアすることがチーム感を高めるそうです。

また、会社で勉強会やセミナーを開いたりするそうです。それにより、知識がシェアされ全体に良いサイクルができると述べていました。

Peter Rabbitsonさん「DBIx::Class - what is it and what is it good for?⁠」⁠

DBIx::Class（以下DBIC）のメインメンテナであり、今回のゲストスピーカの一人でもあるPeter RabbitsonさんによるDBICの全体像に関する発表です。

DBICはとくに海外では広く使われているモジュールで、DBIの拡張であり、ORMであり、フレームワークでもあります。まずモジュールの構成として大きく次の4つの抽象化レイヤからなることを紹介しました。

データモデルを抽象化したフレームワーク（DBIx::Class::Schemae / DBIx::Class::ResultSource）
クエリ操作を抽象化したフレームワーク（DBIx::Class::ResultSet）
検索結果のパーサ（DBIx::Class::Row / DBIx::Class::ResultClass::HashRefInflator）
ストレージI/Oの抽象化レイヤ（DBIx::Class::Storage）

続いて、開発方針として後方互換性を重視しておりpublicなAPIを利用している限り安心してバージョンアップできることや、パフォーマンスの改善も積極的に行っていることを説明しました。

その後、ResultSetによるsearchメソッドのchainingやsubqueryの発行、search_relatedを使ったjoin、HashRefInflatorを使った高速化など、DBICのもつ様々な機能を紹介しました。

日本では昨今Tengなど軽量なモジュールが好まれる傾向にありますが、この発表を聞いて改めて今も進化を続けているDBICを使ってみようと思った人も多いのではないでしょうか。

Taiki Kawakamiさん「Perl::Lint - Yet Another Perl Source Code Linter」

moznionこと、Taiki Kawakamiさんは、Perlのコードの問題点を静的に指摘するためのモジュールであるPerl::Lintについて話しました。PerlのLinterとしては、昔からPerl::Criticと呼ばれるモジュールがありますが、これよりも高速なLinterという位置づけになります。

Kawakamiさんは冒頭で、新しいバージョンのPerl::Lintをリリースしようと試みましたが、テストが通らずに断念することになりました。とはいえ、デモでは動作しているところも見えたため、手元で試すことはできるはずです。また、Perl Lint Playgroundというサイトも作っており、こちらではWeb上でPerl::Lintの機能を使えます。このWebサービスを作った目的については、フィードバックを得やすくするためと説明していました。

Perl::Lintはプログラムを構文木に直すのではなく、Compiler::Lexerの出力であるトークン列を直接使ってコードの解析をするそうです。Compiler::Lexerはまだ若干安定していないこともありますが、時間が経つにつれて安定性は上がってきているということでした。Perl::Lint自身も、実はPerl::Lintをかけると問題点がたくさん出るという状況ですが、レビューが簡素化されたり可読性が上がったりと、静的解析をする利点は多くあるため、今後のプロジェクトの状況に注目すると良いでしょう。

Perl::LintはThe Perl Foundationの助成金によって実現されているそうです。まだ募集しているという話なので、我こそはという方は応募してみるのはいかがでしょうか。また、Perl::Lintに関してもまだまだ開発が必要な部分があり、特にドキュメント面を充実させてくれる方を募集しているそうです。

アルパカ大明神さん「作られては消えていく、泡のように儚いクラスタの運用話」

TVと連携するためのサイトやシステムを構築している@toritori0318さんは、24時間365日運用するサービスとの共通点・相違点について紹介しました。

TVの連携システムは案件によって違いはありますが、放送時間がすべてであり一発勝負なので本番は非常に怖いそうです。想定するユーザ数や想定するシナリオで負荷の検証も行っていたそうですが、この恐怖に対する備えをより強固にするために、Punisherというツールを開発し、シナリオを本番環境と限りなく近くすることで、想定した負荷箇所以外の負荷を発見し、解消することができたとのことです。

タイトルにもあるように、本番後はシステムを削除し作りなおすため技術的負債の返済しやすい環境ではあるそうですが、反面、インフラ設定のコストが相対的に高いことが課題となっていたと言います。デプロイの仕組みやスケール管理はスクリプト化はしているものの手順はバラバラであり、これに対してほとんどを@toritori0318さんが見ていたためSPOFとなっていましたが、現在はVagrant + Chef + CloudFormation + AutoScalingを利用することで、運用手順の共通化・インターフェイスの統合などを行い、改善しているそうです。そこで利用している多くのRakeコマンドを多数紹介し、とても参考になるものでした。

システムの構築・運用はやはり案件ごとに異なっており、24時間365日に則したものもあれば、今回のTV案件のように使い捨てのシステムに適したものもあります。銀の弾丸はないとは思いますが、目の前のTV案件への向き合い方とその改善の仕方は共通するものであり、とても勉強になるセッションでした。

QuizNow!

発表はランチセッションに引き続きにDeNAの古川さんが、QuizNowを開発した際に苦労した点や工夫した点について発表しました。

QuizNowとはクイズとコミュニティの総合サイトであり、クイズで競いながら好きなものを思う存分語る場を提供するサービスです。

開発にあたり、苦労した点はエンジニアとデザイナーお互いのイメージが異なり、イメージの共有化ができていなかったことだと言います。それを解決するために工夫した点は、イメージを静止画ではなく動画にしてエンジニアとデザイナーのコミュニケーションミスを無くしたとことでした。他に工夫した点として、WebのSingle Page Aplicationにしつつ高速化を行うことでネイティブアプリとWebの遜色をなくし、HTTPをPOSTする際のコネクションを繋ぎ直すミリ秒をかせぐたにめにWebSocketでクイズの早押し要素をサポートしたと述べていました。

hakobeさん「Scala In Perl Company : Hatena」

Scala in Perl Companyというタイトルでhakobeさんが発表しました。

まず、はてなではこれまでほぼすべてのプロダクトをPerlで実装してきたことを挙げ、なぜ会社がPerlを選択したのかについて、naoyaさんのブログを紹介しつつ、少ない記述で多くのことができること、CPANライブラリの存在が大きいこと等があって採用したことを説明しました。それから現在10年の歳月が流れ、その間にWeb技術の進化等で取り巻く状況が変わってきた中で、プロダクトの追加機能やパフォーマンス改善、リニューアルなど、価値を生み出し続けるためには継続的なソフトウェア進化が必要です。そのために、テストやレビュー、段階的リリースなど安全にコードの追加や変更をするための工夫を行ってきたそうです。その一方、Perlで開発していると思ってもみない原因のエラーやテストのカバレッジへのコストなど、エラー検知の努力の限界も見えてきていて継続的なソフトウェア進化が難しいという部分も見えてきたと言います。

そのような中で、はてなの新サービスのmackerelが立ち上がりました。スケジュール管理しやすい等の理由で新言語を投入する機会となり、表現力の高い静的型システムのある言語を投入することになったそうです。そして、記述の柔軟さ（フィボナッチ数の例にとってでPerlとScalaで比較してそこまで記述量が変わらないことを紹介⁠）⁠、豊富なライブラリ（Javaで実績のある特にDB向け等のライブラリ⁠）⁠、社内にかける人が割といるなどの理由でScalaを採択したと紹介しました。

実際にScalaを使用してみて、コンパイル時に様々なエラーを検出できること、レビューする側が変更機能に集中してレビューできること等の良い点と、コンパイル時間が長いこと、学習コストがそれなりに高いこと等の悪い点を挙げていました。セッションではPlay2による開発の紹介を予定していましたが、時間の都合で駆け足で省略となりました。

はてなの規模の会社が実際に別の言語を選択する時の理由や投入してみての知見などが得られる発表でした。

motemenさん「Git を使ったツール開発」

これまでにGitを使ったツールとして、ghqやgit-browse-remote、git-pr-releaseなどを開発してきたmotemenさんは今回、ツール開発にGitを活用する話ではなく、Gitを使ったツールの開発を発表しました。「⁠.git以下を見ない」「⁠libgit2を使わない」でツールを開発していく上で、Gitに用意されているgit-*コマンドを活用しているそうです。

具体例として、ツールを作る際に注意すべきこととして引数の扱いについて取り上げました。引数がない場合の挙動は、ユーザが想定する最も標準的なものにすることや、引数を解釈する際にはGitにあわせて様々な方法で引数を記述できることが大事だとし、Gitにおける様々なリビジョンの指定方法を紹介しました。

その他、git rev-parseを用いてリポジトリのトップディレクトリの絶対パスを取得する方法や、git configをより有効に活用する方法などを解説しました。

ライブコーディング 2014

イベントホールでは、songmuさんによるライブコーディングも行われました。実況と解説はmoznionさんです。今回は1時間という限られた時間の中で、誰かがTwitterアカウントでログインして「Ya」とツイートすると、「⁠Ya」という音声を流すWebサービスを作成しました。

Web FrameworkにAmon2を採用し、amon2-setup.plを使って雛形を作成するところからスタートしました。次に雛形から今回は不要なDB関連の実装や設定を削除して、必要なものだけがある綺麗な状態にしました。ここから、TwitterのOAuth認証を用いたログイン機能、ツイートの投稿機能、連投してもTwitterにはじかれないような対策、音声ファイルの再生処理と、怒涛の勢いで実装が進みました。

途中、HTTPステータス500のエラーが出たり、ツイートが上手くいかなかったりと、実際の開発でもあるような躓きもありましたが、最後にはぴったり1時間で実装を終え、観客から盛大な拍手が贈られました。

tcnksmさん「コマンドラインツールについて語るときに僕の語ること」

「CLIツールにもUI/UXが存在する」という言葉が印象に残る「コマンドラインツールを作るときの注意点/意識している点」というタイトルの@deeeetさんの発表です。

世の中のCLIツールには良いツールとそうでないツールがあり、それらの違いは単純で、その単純な約束を守っているかいないかであると言います。これらの7つの約束はスライドをご覧ください。

発表では、特に次の4つの点で「自動化」「⁠ユーザの利便性」「⁠メンテナンス性」を重要視していると感じる内容でした。

1) よく使われているCLIの慣習に合わせる
2) cronなど他のスクリプトから利用された後でわからなくならないようにロングオプションを用意する
3) README -> USAGE -> MANPAGEという順に利用頻度に合わせたドキュメントを用意する
4) 適切なデフォルト値を持ち、設定もできるようにする

7つの約束を紹介した上で、実際にツールを作る際に行っている方法も紹介しました。「⁠ツールがほしい！」という初期衝動が発生してから、まずはREADME（注：GitHubのリポジトリを開くと見ることができる最初のドキュメント）を書き始める「RDD（README Driven Development⁠）⁠」⁠ を実践しているそうです。この方法のメリットはドキュメントを書くことで、「⁠なにを実現するものなのか」「⁠どのような使い方（インターフェイス）をするのか」など、開発者目線ではなく利用者目線で整理することが可能になり、それによって「なんとなくツールを作っているうちに機能が増えてしまう」「⁠ほんとに欲しかった機能がなくなってしまう」「⁠使い方が複雑になってしまう」などを抑制する効果があるそうです。また、ツールを作ったことで満足してしまいREADMEを書かずに放置してしまいがちな状況を、最もテンションが高い時に書くことで抑制することができると述べていました。

最後にご自身が作った「cli-init」「⁠ghr」とgolangのクロスコンパイラである「gox」というツールを使い、GitHubにアップするところまでのデモを行いました。

私自身ツールを作ることも多いので、ためになる話を聞くことができました。

Atsushi Katoさん「継続的翻訳活動をささえる技術」

Atsushi Katoさんの発表です。まず始めに、2002年頃からのJapanized Perl Resources Project（JPRP）などで行っている翻訳活動について、活動グラフを交えて紹介しました。そもそもKatoさんが翻訳活動を始めったきっかけは、Perlが好き、英語の勉強になる、好きなモジュールの紹介したい、仕事がキツいと他所事をしたくなるという理由だと言います。特に2013年はよく翻訳活動に勤しんだ（＝仕事がキツかった）と述べていました。最近は余所事すらしづらいぐらい、忙しいとのことです。

次に、実際にPerlの翻訳活動で何が大変なのかという点を紹介しました。CPANからのファイルの取得、ファイルの展開、ソースコードからのPodの取得、メタファイルなど、翻訳をしたいという目的だけを考えると、そもそも翻訳作業に行き着くところに大変な手間がるそうです。他にもディレクトリ構造、Perlのソースダウンロード、コアモジュールかそうでないか、更新への追随等も大変だと言います。これらの問題に対応するために、2010年あたりからtranを開発していることを紹介しました。tranを使った翻訳のワークフローを取り上げて、更新の際のmergeの仕方や、内部構造で最初はCPANを使用していたが今はMetaCPANのAPIを使用しているということなどを説明しました。

最後にデモの他、VCSへ勝手にコミットする機能やメール送信等の機能といったTODOを挙げていました。

Kentaro Kuribayashiさん「いろんな言語を適材適所で使おう」

HUBで飲み過ぎてしまい、若干酔っ払っている状態という、GMOペパボのあんちぽくんさん（@kentaro）の発表です。

まず、Webアプリケーションに要求される水準はますます高まっていくばかりですが、技術は一旦選択してしまうとなかなか変えることができないという問題意識があります。プログラミング言語などの技術はいろいろな選択肢がありますが、どういう基準で選んでいるか議論したいとのことでした。また、選択の目的は、ユーザーに提供する価値を最大化することと継続的に高い価値を提供することだそうです。

適切な言語を選択するために必要なことを言語の決定要因、決定要因に基づく評価、変化への技術的対応、組織能力を涵養する、という4点に分けて説明しました。

言語の決定要因としては、言語自体の特性、コミュニティ、エコシステムの3つの評価軸を挙げ、それらに応じて決定要因に基づく評価を行うそうです。決定要因に基づく評価では、継続的に価値を提供しなければならないため、撤退オプションも考えておくことが重要だと指摘しました。変化への技術的適応として、Microservicesを例にあげ、不確実性に対して、分散化（ポートフォリオ化）で対応することの重要さを説明していました。

組織を涵養するという話では、変化への組織的対応について説明し、組織能力には、組織が技術を受け入れるための能力と、技術やコミュニティへの影響を及ぼすことができる能力の2軸があることを紹介しました。特に、直接自分たちが使っている言語に影響力を及ぼすため、新人研修で求められるスキル水準まで伸ばすことや、OSSアクティヴィストが大事だそうです。

最後に、技術選択はシステムがユーザに提供する価値を最大化することが目的で、選択には3つの評価軸があり、ある時点で確定することはなく、時間の経過と共に何度でも選択を行うことと、将来は見えないため技術的分散、変化に対応でき、技術に影響を及ぼすことができる組織能力が大事だと述べ、話をまとめていました。

青猫さん「DeNAが歩んだデプロイ自動化への道」

最初は1コンポーネントから始まったMobageは発展に伴い、認証やSNSなど多くの機能を含み肥大化していってしまい、結果として変更を加えづらいシステムになってしまったそうです。この状況を解決するために、DeNAがどのようなシステムを目指し、対策を施してきたのか、そしてそれによってユーザに「安全」かつ「高速」にサービスを提供することを可能にしてきたかを@aonekoさんが発表しました。

「品質」と「スピード⁠」⁠、「⁠コスト」はトレードオフの関係にあります。しかし、これらのトレードオフを解決する方法の1つが自動化であると言及しました。また、「⁠すべては出荷のプロセスに現れる⁠」⁠、つまり出荷（リリース）のプロセスに困難を感じるかどうかがシステムの安全性の指標となっており、リリース作業の自動化を考えることが、システムの自浄作用を促すことだと言います。

自動化する際に重要なことが「環境を問わないデプロイプロセス」にすることだそうです。開発環境・ステージング環境・本番環境のそれぞれに対して異なるプロセスで行ってしまうのであれば、そのプロセスはそれぞれ独立なものとなってしまい、実際の失敗の許されない、本番環境へのデプロイプロセスの信頼性を向上させるものではなくなってしまうからです。

環境を問わないプロセスを日々繰り返し、反復することで、デプロイプロセスの信頼性を高め、本番環境へのデプロイですら「信頼度の高いプロセスのうちの1回に過ぎない」と言えるところを目指すこと。それが最初の目的である「安全かつ高速にユーザにサービスを出荷する」ことを実現につながると述べていました。

課題はまだまだ残っているとはいうものの、DeNAがMobageとして多くのサービスを生み出している背景が垣間見られるセッションでした。

Hideaki Ohnoさん「自然言語処理を支える技術～要素技術とPerlの活用～」

Hideaki Ohnoさんは自然言語処理における要素技術と、そのPerlの活用について発表しました。このセッションは、Perl中級者以上で自然言語処理に興味があるが経験がない方を対象にしています。

はじめに、自然言語処理が自動要約などに使用されている等の事例を紹介しました。そして、自然言語処理は大きく分けて、人手でルールを定義して処理をするルールベースと機械学習によりルールを導き出して統計学モデルがあるとし、それぞれの長所と短所を述べました。

続いて、自然言語処理の要素技術として形態素解析とその仕組み、そしてそ処理を行う形態素解析器の実装であるMeCab, JUMAN, KyTea, KAKASIの特徴などを紹介しました。また、そこで使用されるデータ構造のTrieやLOUDSの特徴、係り受け解析器の仕組みであるshift-reduce、全域木、実装であるChaboChaなどを紹介しました。

最後、自然言語処理におけるPerlの良い点として、柔軟なテキスト処理やスクレイピングによるリソース確保がしやすいこと等を挙げていました。

Lyo Katoさん「O2O/IoT/Wearable時代におけるWeb以外のネットワーク技術入門」

Lyo Katoさんの発表では、Web以外のネットワーク技術について紹介しました。

まず、MQTTの紹介と関連技術との比較について話しました。MQTTは、PubSubプロトコルで、省エネ、QoSやWillなどのサポート、ワイルドカードを使ったSubscriptionが特徴だそうです。また、MQTT-SNについても取り上げていました。MQTTはなぜかHTTPと比較されることが多いのですが、それが混乱を招いていると指摘し、M2MをHTTPで実装しようとしていた時代から、MQTTが生まれるまでの歴史を説明しました。その中で、CoAP/CoRE、Bonjourについても触れていました。関連技術との比較では、CoAPとの比較、AMQP、XMPP、Redis/STOMPとの比較をしていました。比較のまとめとしては、プロトコルのできた理由を調べると良い、やりたいことに応じて選択するべきと述べていました。

次にPerlのイベントということで、PerlでMQTTを利用する例を示しました。AnyEvent::MQTTというクライアントライブラリと、SangoというMQTT as a Serviceを紹介していました。

その後、BlueTooth LEとiBeaconを取り上げました。LEはLow Energyの略で、Bluetooth 4.0から含まれてるそうです。Bluetoothのネットワークトポロジ、ネットワークへの参加の仕方、iOS、Androidの対応状況、iBeaconを使った事例、ウェアラブルデバイスとの連携事例を詳しく説明していました。

最後に、BTLEは応用の余地がまだたくさんあり、MQTTはメリット・デメリットをきちんと把握した上でなら使ってもいいかもしれないと述べていました。

Hideyo Imazuさん「TWiki － Perlで書かれたプログラマブルでglueでスケーラブルなCMS」

Hideyo Imazuさんは、モルガンスタンレーでのTwikiの使用例について発表しました。

Twikiは1998年生まれでPerlで記述されています。特徴としては1つのインストールで複数のWikiサイトが作成でき、強力なマクロを持ち、そしてUTF8使用する限りにおいて日本語は問題ないことだと言います。モルガンスタンレーでの使用の経緯としては、2004年にニューヨークのインフラエンジニアがインストールしたのが最初で、2014年現在は会社内部において、1万サイト総計100万ページがあり、4万5,000人が月に一度は閲覧し6,000人が月に一度は更新しているそうです。

主な用途はITシステムの運用マニュアルや利用マニュアルで、他にはチーム内の進捗報告などに使用しているとのこと。会社内での普及要因は、運用による可用性の高さをまず挙げ、同じ地域内にデーターセンターを2つ持ち、さらにデーターセンターが2つ失われてもデータが消失しないように地域間でもデータを保存していると説明しました。これにより、2012年10月のハリケーン・サンディの時にニューヨークのデータセンターが水没したそうですが、想定通りに動き続けたそうです。

Twikiのデータ等の扱いがDBを使わずに単純にしてあることも可用性を上げているそうです。そして、この可用性の高さ故に障害対応マニュアル等がTwikiの中に設置しているとのことです。マクロも強力でサイト内の表の合計値を取得したり、APIを叩いて表示、DBへクエリを投げて結果表示などができることも支持を得られる理由の一つと述べていました。

最後に、このようにマクロで色々できてたくさんのサイトを収容でき、落ちず長期運用されるコンテンツ管理システムがあると、仕事が幸せになるのではないかと述べ、セッションを締めていました。

cho45さん「ウェッブエンジニアのローレベルプログラミング」

「なんかドライバなかったから書いた」という言葉によって様々なレベルで解放されていく、 @cho45さんによる電子工作の世界に飛び立つための誘いとなる発表でした。

「生まれた時からLLがあった」という@cho45さんが上の言葉を元にアセンブリを学び、作成するものに選んだのはWebエンジニアらしくブログシステムでした。環境変数の取得や、ファイルの走査などを実現するために普段使っているコマンド（getenv、ls）を、アセンブリで実行するためには様々な処理が必要であることを知り、その結果、高級言語の解放が実現できたことを説明しました。

その後、RasberryPiを購入し、GPIO（general purpose input / output）の端子をプログラムから操作することで、温度計や気圧計、ジャイロなどI2C（Inter Integrated Circuit）対応機器を操作する方法を学習しました。これにより、I/Oからの解放が実現できたと言います。

次の段階として、Rasberry Piの対抗として購入したArduinoを操作する上で、OSなしで直接CPUに命令セットを記述する「bare metal」と呼ばれる手法を獲得しました。いままでWebエンジニアとして「CPUを使い切るようなコードを書いていた」のが「いかにCPUを使わないように書くか」という新鮮さを味わっていると言います。また、USBデバイスなども操作できるようになり、「⁠震えるマウスポインター」などを作成したことを紹介しました。周辺機器も自由に操作できるようになり、完全に解放できたと述べました。

しかし、まともな周辺機器を作るためには電子工学の知識が必要です。OSとか人の作ったルールが電子の動きを含めた物理世界のルールになっただけだと指摘し、完全解放への道はまだ遠いと、話を締めていました。

Kenichi Ishigakiさん「Get a kick out of CPAN」

charsbarこと、Kenichi Ishigakiさんは、CPANの現在の状況の分析とそれに対してどのようなアクションをすべきか、に関して発表しました。

CPANの日本人Authorの数や、それぞれのリリースしているモジュールの数などを分析したところ、日本人のCPAN Authorは欧州全体よりも多いのにも関わらず、実際にモジュールをアップしているのは66％に過ぎないという結果でした。また、モジュールを複数登録している人はもっと割合が少なくなり、CPAN Authorとして登録した後の障壁が意外に大きいようでした。

そのことについてIshigakiさんは、フィードバックが得にくいのが原因ではないかと分析。Gamificationを導入することで、この状態を改善できるのではないかと考えました。ただ、先日行われたCPAN DAYにおいて、モジュールのアップロードが過剰に発生するという問題が発生したことを挙げ、Gamificationを導入する場合はその設計が難しいということを話していました。

他の改善案として、RTの残っているチケットについて進んで貢献することや、メンテナンスが滞っているモジュールのメンテナンスを引き受けたりと、フィードバックを得やすい方法を提案していました。会場からも活発に意見が交わされ、特に、GitHubにモジュールを上げているだけで止まっているユーザをなんらかの後押しする必要があるのではないかという意見が複数出ていました。

この発表を聞いてもらった上で、IshigakiさんはRTの状況を調べて地方pmなどの機会で貢献者を発表しようとしているそうです。YAPCに参加してPerlのコミュニティへ貢献をしたいと考えている方、これを機にIshigakiさんの提案される方法にしたがってRTを見直してみるのはいかがでしょうか？

Kazuhiro Osawaさん「Java For Perl Mongers」

Kazuhiro Osawaさん（@Yappo）は、Perl Mongerの自分が実際にJavaを使ってみた経験や感じたことを発表しました。

最初にコードを示して、このコードがどの言語で実装されたか、という質問を観客に投げかけました。コードは一見するとJavaのもののように見えましたが、実際には工夫次第でPerlでも動くことを説明しました。

その後、実際にJavaを使った経験から、悪いとされている点、良いと言われている点について言及しました。JVMが重いといった根本的な話から、コードが冗長になりがちといって話まで取り上げ、問題の大半はメリットの裏返しであったり、IDEを活用することで解決できると説明しました。また、書ける人が多いことやORMの効果が高いことなどのメリットについても解説しました。

最新のバージョンであるJava8については時間の都合で少ししか触れませんでしたが、Stream APIやlambdaといった新しい機能を紹介しました。

大西康裕さん「開発合宿！！！！」

最近、はてなのサービス開発本部長になったという、大西康裕さん（@yasuhiro_onishi）が、はてなでの開発合宿について発表しました。

開発合宿という言葉は、Wikipediaに2007年に記載されたようですが、はてなでは2005年から行っているため、はてなが始めたのではないかと思っているそうです。はてなブックマークも少人数の開発合宿から生まれ、2005年2月5日に合宿の企画し、次の日から合宿を開始、2月10日にはベータリリースまで行ったことを紹介しました。

最近では、数人で1つの新サービスをつくるという形式から複数チームでコンペという形式に変わってきたそうで、基本フォーマットは2泊3日で、初日にチームビルド、開発開始、最終日に成果発表会と投票を行う形式になっていると言います。

開発合宿の良い点は、普段とは非連続な開発ができること、普段の業務を離れて集中できること、普段と違う人と開発できること、お祭り感があること、非日常感、モチベーション向上があり、良くない点は、回線が良くないこと、大画面モニタがないこと、椅子が良くないこと、飲み過ぎること、寝ないで開発し続けて体調崩してしまうことを挙げていました。

また、実際に開発合宿をやるために必要になる、準備、宿選び、機材、飲食、企画のそれぞれについて説明しました。

はてなでは開発合宿にバリエーションがあるとし、合宿ではないですがオフィスでアイデアソンを行ったり、オフィスと宿など複数会場で開催したり、成果発表会に合宿非参加者も参加してもらったり、と例を挙げました。ただ、家族・彼氏彼女も参加OKにした回では、子供が大暴れして、大変だったそうです。また、複数会場で開催する際に1時間に1回、合宿新聞を出していて、宿にいる参加者にインタビューした内容を載せていたのですが、深夜になり誰もいなくなってしまったため、椅子にインタビューしたとのこと。会場では笑いが起きていました。

最後に、開発合宿は盛り上がるが、コストもかかるということと、企画・準備をしっかりやって会社を盛り上げましょうということを伝え、発表を締めくくりました。

開発合宿の楽しさが伝わってきて、明日から合宿に行きたくなるような発表でした。

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

zoncoenさんは、Webエンジニアのコミュニティに触れてみて感じたことについて発表しました。

zoncoenさんがWebエンジニアになろうと思った経緯は、勉強会が普段から行われること、OSSが普通に使われている状況、業界で知見を共有するところ、技術力だけでなくそれを使って何をしたかと言うところが大事だとみなされているところに惹かれたことからだと言います。

そして、自分の経験を例に挙げて、初心者が成長するためにやるべきことを紹介していきました。具体的には、「⁠Titterを使って有名な人をフォローして彼らが何をしているか観察する」「⁠勉強会へ行き業界の話し等を聞いたりする」「⁠技術Blogに自分ではまったことや便利だと思ったこと、勉強会への参加報告を書いてみる」「⁠GitHubで他人のプロダクトへPull Requestを送ってみる」「⁠勉強会で発表する」などを挙げていました。

最後に、一人で成長するのは辛いので、利用できるものは利用して成長していくこと。また、目標となるエンジニアを持ったり積極的な情報発信をしたりして、いつかは刺激をもらう側から与える側になろうと述べていました。

Lightning Talks Day 1

1日目のLightning Talksです。

maka2_donzoko@twitterさん「同人活動の報告と今後の展望」

毎年恒例の活動報告で、今年はさらに大きくなったAcme大全2014だけではなく、Acme大全全巻BOXまで作成されたそうです。ただ奥様からはいつまで続けるのと言われており、たくさんあまってYAPC::Asia離婚の事例は作りたくないので皆さん買ってくださいと呼びかけていました。

charsbar@githubさん「Top 10 Kwalitative Japanese authors 2014」

日本のCPAN AuthorたちのCPANでの活躍のランキング発表でした。近年はまた新たなCPAN Authorが誕生してランキングに変動があったとのこと。今年のTOP 10には初めてランクインした方も数名いました。1位は、この後LTもするbayashiさんだったとのことです。

shoichikaji@githubさん「Relocatable Perl」

何度もビルドするのが面倒なので、ダウンロードして解凍するだけで動くRelocatable Perlを作ったという発表でした。direcotryに依存せずどこに置いても動くので、Perl製のソフトウェアも配布しやすくなります。実際にGrowthForecastをperl同梱で配布する様子をデモしていました。

papix@twitterさん「Perl入学式の中間報告」

Perl入学式の中間報告ということで、昨年と比べて変わった点などについて紹介しました。今年は新たに福岡が加わり、3都市で開催していること。また、スタッフも増え、短期講座なども開催していることを取り上げていました。今年からはJPAと連携することになったことに言及し、今後も期待してほしいと述べていました。

hiratara@githubさん「Lens : Smart setter for immutable data」

ネストしたオブジェクトをイミュータブルにあつかう場合、setterが冗長になってしまいます。それを解決するためにつくったLensというライブラリを紹介しました。これはHaskellの同名ライブラリにインスパイアされて作成したとのこと。後半は圏論関連の理論的な説明で開場の大半の人にとって難しい内容だったようです。

gugod@twitterさん「Civic Hacking」

台湾でのCivic Hackerの活動を紹介しました。1,000人を超えるという台湾のCivic Hackerたちは、政府の予算の情報や台湾の大気汚染の情報を可視化したり、政治献金の情報をデジタルデータに変換したりして g0v.tw に公開しているとのこと。紹介された中には、救急病院の待ち行列の情報や大企業の株主の傾向を示したグラフなどもありました。

shuhei.tanuma@facebookさん「OSSのりそうとげんじつ」

OSSは自分が作りたいものを作る面白いゲームで、とても楽しいものです。さらにみんなが使ってくれればとてもハッピーになれます。しかし年齢とともに使える時間も減ってくるため、取捨選択していかないといけないという現実もあります。そのような中でも楽しみながら回すために、1)うっかり業務に組み込む、2)コミュニティを育てるといった方法を紹介しました。

catatsuy@twitterさん「新卒インフラエンジニアがpixiv新社内広告サーバー構築に挑んだ話」

pixivに新卒入社されたというcatatsuyさんは、社内広告サーバを構築した経験を話しました。ホットデプロイやプロセス監視、ログローテーションを行う際に、Circusが便利だったとのことでした。また、不要なログをキャッシュの削除を行うために、Sys::PageCacheが便利だったことなども説明しました。

kazeburo@githubさん Web Framework BenchmarksとPerlの現状報告会

Web Framework Benchmarksという様々な言語のWebアプリケーションフレームワークのベンチマークを公開しているサイトの紹介で、Perlは散々な状況だったのでチューニングして高速化されたそうです。もともとActive PerlだったところをPerlをソースからビルドして最適化し、Nginx・Starletなどを使う構成にしたところPHPの半分だったスコアがPHPを超えるレベルにまで引き上げられたとのこと。このサイトはフレームワーク選定の参考になるだけではなく、実践的な設定のショーケースにもなるため、意味があることだと言います。最後に、WAFを作ったらPullReqして載せましょうと訴えかけていました。

bayashi@twitterさん

昨年のYAPC前夜祭でラーメンについて話をしたbayashiさんは、今年もラーメンについて話しました。そして、ラーメンとOSSをかけあわせて何かできないか考えた結果、「⁠YAPC::Asia Ramen Challenge」と題して、「⁠ラーメンを食べるか、OSSに貢献するか」を選んで行い、リレー形式で回していくチャレンジを提案しました。

懇親会

1日目のプログラム終了後、イベントホールにて懇親会が催されました。スポンサーの方々の挨拶と乾杯の後、たくさんの人が歓談していました。

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