27日から29日までの3日間、東京大学伊藤国際学術研究センターにて「YAPC::Asia Tokyo 2012」が開催されます。昨日は前夜祭で、本日は1日目ということになります。ここでは、1日目の模様を随時レポートしていきます。

※すべてのセッションをレポートするわけではないことにご注意ください。

受付が伊藤謝恩ホール前に移動しています。もうすぐオープニングです。

941さん「オープニング⁠」⁠

櫛井さんがオープニングの挨拶を行いました。今年は参加者数が過去最多となり、発表の応募も数多くあったと話します。

また今年も遠方からの参加者制度、個人スポンサーの募集（120名180口の応募があったとのこと）が行われました。今年の新しい試みとしては、ぼっちとオサラバ！できる「ランチ交流企画⁠」⁠、「⁠LT-thon⁠」⁠、物販ができないため「立ち読みコーナー」などがあると紹介しました。

そしてYAPCを楽しむために、トークを見よう、交流しよう、投票しようと呼びかけました。

Larry Wallさん「What Does Your Code Smell Like?」

オープニングトークの次はご存知Perl の生みの親であるLarry Wallさんのトークでした。「⁠おはようございます」と流暢な日本語の挨拶とともに「練習しました」とはにかみながら言うと会場が笑顔で包まれました。

「What Does Your Code Smell Like?」と題されたこのトークは、Perl5で記述されたソーティングプログラムをライブコーディング的にPerl6に翻訳しつつPerl6の構文や新しい機能の紹介するというスタイルで行われました。まず手始めに「インデントが深すぎる」としてインデンテーションの深さを改善した後に、Perl6で導入された仮引数のシステムをソースコード中に記述していました。また「Explicit Reference」として、Perl6は変数がリファレンスとして扱われるため、Perl5にあったような変数前のバックスラッシュやデリファレンスが不要になることを示しました。さらに配列の添字に対する負数は廃止されて"*-1", "*+$_" に置き換えられることや、矢印演算子 (->) はドット (.) に置き換わることについても紹介しました。

トークは関数プログラミングを強く意識した内容となっており、関数の末尾のreturnを排除できるイディオムや、gather..takeを利用した遅延評価処理の実現など、関数プログラミング的な手法についても紹介しました。

質疑応答では「Haskell のような静的型およびチェッカが導入される予定はあるのか」という質問が挙がり、それに対してLarryさんは「導入は可能ですが、Haskellのように厳格かつ難解にしてしまうとみんながPerlを嫌いになってしまうのでは」との見解を示していました。また「Perl6は最初から完璧な言語を目指すのではなく、あえて改善の余地を残して色々な人の意見を取り入れていきたい」と答えました。

Larryさんは最後に「Perl5とPerl6はこれからも共に発展してゆきます」と非常に頼もしい一言でトークを結びました。

HASEGAWA Yosukeさん「Web::Security beyond HTML5」

はせがわさんのお話はwebセキュリティ、それもajaxに伴うあまり知られていない脆弱性についてでした。

まず触れたのはcontent-typeレスポンスを無視して独自の極めて複雑なロジックに基づいて判定するIEでのみ起きる脆弱性です。この判断ロジックはドキュメント化されておらず、簡単なヒントがあるだけだそうです。はせがわさんはこのロジックを独自に分析したのですが、複雑なだけでなくパッチの影響で挙動が簡単に変わってしまうことから、マイクロソフトも全体像は把握してないかもしれないと述べていました。

さらに、ブラウザ特有の挙動やxhr2のクロスドメイン通信によって引き起こされる脆弱性を取り上げ、締めくくりにリソースの共有を厳しく制限するcspといったブラウザ側の取り組みを紹介しました。

bokkoさん「pixivのサムネイル事情」

1日あたり約2万枚のイラストがアップロードされるという巨大画像SNS「pixiv」のサムネイル生成の舞台裏を、同社のbokkoさんが発表しました．

1作品あたり生成されるサムネイルが十数枚から数百枚というpixiv。元画像と生成したサムネイルの両方をストレージに保存しているのですが、NFSは使わず、自社開発のWebDAVクライアント「ImageClient」を使用し、複数のサーバに対してWebDAVメソッドを透過的に実行しています。

ユーザーがアップロードするファイルを選択して送信ボタンを押し、画像情報入力欄に遷移する裏側でサムネイル処理のロックファイルを生成。ユーザーが情報を入力しているあいだにサムネイル処理を走らせることで、比較的時間のかかる処理を速く行なっているように見せているそうです。

サーバサイドでは、静的／動的ふたつの種類別にシステムを用意しているとのこと。

静的サムネイル生成はImageMagickを使用。高速ではないものの、生成される画質の良さから採用しているそうです。ライブラリとしてx86系CPUに最適化された「libjpeg-turbo」の使用で速度を10%向上。マルチコア向けの並列処理機構「OpenMP」を無効にすることで150-200%のCPU負荷軽減、LoadAverageを6から1未満に激減させることに成功しました。

動的サムネイルの生成においては、NHN等でも使用されている「mod_small_light」をカスタマイズして導入。URIのパラメータとしてサイズを指定することでリサイズされた画像が返り、かつよく使うパラメータに名前を設定できるため柔軟な運用な可能となっています。

画像の処理は最適化が重要と語ったbokkoさん。処理のチューニングや非同期化を積極的に行い、静的なサムネイルと動的なサムネイルと生成手段を分けることで高価なストレージ資源を節約し、またアプリケーションやサイト構成の変更に強いシステムを構築できると語りました。

Ingy döt Netさん「Acmeism, Pegex and CoffeeScript on CPAN」

紫の帽子にタトゥーという、いつも通りの素敵なスタイルで登場したIngyさん。特定のプログラミング言語にこだわらず、様々な言語でプログラミングを実現する"Acmeism"について話しました。途中でポッキーを配り出したり、Ingyさんのサービス精神も垣間見えるセッションでした。

Ingyさんは自身の考えるAcmeismについて、子供が砂場で遊ぶような感覚でアイディアを他のハッカーに分け与えることができるものであると表現しました。その中で、Perl 6 Rulesを基にしたpegexを紹介し、実際にJSONをpegexで定義する例を示しました。

他にもCoffescriptやPython、Perl、C'Dent、UniScriptなど、様々な言語が現れたこのセッションは、今回のテーマである"Take A Step Forward"に相応しい、垣根のない内容でした。

Toshinori Sato さん「Perlでデータクリーニング⁠」⁠

NHN Japanの@overlastさんによる、データマイニングを行う際に必須となる「データクリーニング」の手法についての発表です。

データが持つ2つの問題として「データ自体の問題」と「データマージ時の問題」を挙げたoverlastさん。Excelのワークシートによく見受けられるような「セパレータが値に入っている」「⁠表記揺れで別エントリとして認識されている」という問題、スキーマを用いても解決できない問題…スペルミスや重複・冗長、データ同士の矛盾、また日付など同種のデータのフォーマット違い、単位の規格化や変動するレートによる変換時の問題などを例に、構造化されていないデータの問題点を指摘しました。

これらの生データをクリーニングするときに大事なことは「ノイズデータを捨てない」ことなのだと言います。データを捨てると全体の情報量が減ってしまい、特に捨てたデータが固有のものだった場合に致命的な状況となるため、人と機械の両方で作業を行うことが大事なのだそうです。「⁠小さすぎる静的データは自明であるし、小さすぎる動的データは無意味」とoverlastさん。ノイズ削減と再現率の向上のため、データの全体量を増やすことが大事であると語りました。

「やる気が長続きする」データクリーニングの手法は「見つかった欠点は極力直す」「⁠見つかっていない欠点は無視すること⁠」⁠。「⁠汚いエントリ」を見つけたらまず理想の回答を思案し、問題を集めて現象系の傾向をつかんでテストを書くことが大事なのだそうです。

正規表現によるフィルタリングや全半角統一など文字列の正規化、またText::MeCabやJUMAN、Text::KyTeaなど、ミドルウェアの駆使によっても訂正や再処理の一貫性が向上するとのこと。機械学習の効率を上げるために回帰テストを書くことも重要であるとし、「⁠人間の判断基準は必ず言語化すること」「⁠誰かの頭の中の基準は捨て、個人の主観のみに頼る判断を徹底排除すること」が大切であると締めくくりました。

Tokuhiro Matsunoさん「Nana/Tora - Perl5 から見える未来。Perl5 と共にあゆむ Perl6 ではないプログラミング言語、それは。」

tokuhiromことMatsunoさんのセッションは、現在のPerlの問題点を踏まえ、それに対してどのような解決策があるかを考えるという内容でした。まずPerl5を長年使った経験からPerl5のよくない点を何点か挙げていました。例えば、コンテキストによって実行結果が変わったり、リファレンスの概念が面倒だったり、XSが難しかったり。

そのようなPerl5に対して、かれこれ10年以上開発が続けられているPerl6は、解決策となるのでしょうか。MatsunoさんはPerl6の問題点として下位互換性が低いため、新たな学習コストが必要となることを指摘しました。また、実行速度もまだまだ遅いそうです。

それでは、なぜPerl5は今でも使われているのでしょう。取り上げられたのは「DSL for CPAN」という側面です。つまり、CPANが使いたいがために、Perlが使われているのではないかと。それを踏まえた上で、できのよいnode.jsのnpmに着目し、「⁠DSL for npm」という方向性について模索しました。この結果、自ら開発したbetter Perl5を目指す言語Toraのnode.js実装であるkumaであったり、node.js上でPerlやRubyが動くnode-perl、node-mrubyなどをデモを交えて紹介しました。

本セッションは言語の壁を越えたセッションが多いYAPCの特徴をよく反映したものであり、Twitter上でもYAPCなのにPerl以外の話がされているのかと、話題になっていました。

Lenz Gschwendtnerさん「rapid prototyping with Mojolicious::Lite」

Lenzさんの「rapid prototyping with Mojolicious::Lite」というタイトルのセッションです。

まず最初に、「⁠小さなことから初めて、そこからコツコツと育てていく」というテーマを掲げて、「⁠少ないコードであれば変更が容易になりますし、コードベースが小さければ小さいほど作業効率が上がります。また、プロジェクト中のファイルの数が少なければ、見通しが良くなり、既存のフレームワークを使うと高速な開発が可能になります」と、プロトタイピングを行うことのメリットについて話しました。次に、"Mojolicious::Lite"や"CouchDB"、"Twitter Bootstrap"を取り上げ、これらのフレームワーク・データベースがラピッド・プロトタイピングにとても向いていることを示しました。

そしてLenz さんが開発に携わっているPlanet Express Shipいうwebアプリケーションスターターを紹介しました。Planet Express Shipは"Mojolicious::Lite"、"CouchDB"、"Twitter Bootstrap"を利用したラピッド・プロトタイピングを支援するツールであるとし、buildを実行することで、それらが依存関係を満たしてインストールされ、さらにログイン処理やアカウント関連の処理、gmailやGoogle Appsのサポートが最初から実装されていると説明しました。それにより、ラピッド・プロトタイピングを容易に実現できると指摘しました。

Twiter Bootstrapについては、Bootstrapのテーマを入手できるWebサイトの紹介から始まり、通知システムやログインシステムなどのレイアウトのテンプレートとして実装されている機能の説明や、実際の利用例の紹介など、盛りだくさんな内容でした。

なお、Planet Express Shipを活用して作成されたWebページのサンプルは、Lenzさんのtwitter (@norbu09) に掲載されるようです。

Masaru Hoshinoさん「大きくなったシステムの疎結合化への取り組み」

株式会社ミクシィに勤務されているMasaru Hoshinoさんの「大きくなったシステムの疎結合化への取り組み」というセッションです。

mixiのサービスは2004年からスタートしており、表の処理も裏の処理もPerlで動いているそうです（ただ、一時期オープンソース化した煽りでその該当する部分のライブラリは変更したとのことです⁠）⁠。2004年からサービスが提供されているため、ライブラリやモジュール群が複雑に絡まりあっており、レガシーなコードも多くなっている、というのがmixiの現状だと言います。そして「長く続いている上、開発者がたくさんいるサービスにとって、そのような状況に陥るのは避けられない」とした上で、システムの疎結合化への取り組みに関して発表しました。

取り組みの1つとしてとして、Service Procedureを取り上げました。Service Procedureはモジュール間を仲介するための擬似的なリモートプロシージャコールで、直接`use`することによって生じる依存関係をアダプタを介して利用することで、内部実装の変更を吸収することができるとのことです。

次にmixiのシステムで利用されているAPIを挙げた後、その中のCoreInternalAPIというmixi内部ネットワークのサービス向けAPI にスポットを当てて解説しました。まず、mixiの日記やコミュニティといったサービスはすべて1つのリポジトリで管理されていることを説明し、「⁠既存資産を利用することができる」「⁠開発ノウハウを共有することができる」というメリットを挙げた後に「リポジトリが肥大化する」「⁠ソースコード変更による影響範囲が拡大してしまう」「⁠新しいトライへの障壁となってしまう」というデメリットを示して、そのデメリットに対する解決方法として必要な情報のみをAPIとして提供するとのがCoreInternalAPIだと紹介しました。

ライブラリ管理にはInspectPackageという名前空間ごとのスコアを参照するツールを利用しているとのことです。このInspectPackageで表示されるスコアは名前空間の依存度・結合度であり、これを低くするためにグラフ等で可視化するなどの工夫をしていると話していました。

また、ガイドラインとレビューと題してmixi社内でのコードレビューの仕組みについて紹介しました。mixi社内ではソースコードに対してコードレビューを行うことが義務化されており、一定のコードの安定度・統一性が保たれてきたようです。従来まではコードレビュー委員会が中央集権的にコードレビューを行なっていたところを、各チームに権限移譲したということでした。これは、疎結合化が進んだことによってコード変更による影響が局所化した影響だとしました。

最後に、「⁠既存のものに引っ張られずに、悪さに歯止めをかけること」「⁠新しいものを駄目にしない」「⁠駄目なものは洗い出して直してゆく」「⁠いつか良くなるだろう、は甘え」とまとめた後、「⁠最終的にはエンジニアの手によって計画的に改善していくべき」と教訓を示してセッションを締めくくりました。

しんぺい@猫型技研さん「リアルタイム通知システムの舞台裏」

新潟でフリーのエンジニアとして活動しているしんぺい＠猫型技研さん。現在開発運用しているスマートフォン向けチャットアプリを例に、リアルタイムなpush通知システムの改善事例を発表しました。

スマートフォン向けのpush通知を実装するにあたり、当初はクライアントから通知サーバに常時コネクションを張る仕様で運用していたのですが、サーバーパンク時のフォローができないという問題点を抱えていました。その後通知サーバを増やし、アプリケーションサーバ側でユーザーごとに通知サーバを割り当てる方式に移行したものの、今度はアクティブなユーザーの多い通知サーバに負荷が集中してしまうという問題が発生。通知サーバをひとかたまりのクラスタにして抽象化することで疎結合なシステムが作れないかと考えました。

そこで導入したのが、Erlangで書かれたメッセージングサーバ「RabbitMQ⁠」⁠。フェイルオーバーができて、かつ「pub/sub」（⁠特定条件のユーザーにむけてまとめてメッセージを通知する機能）にも対応しているという利点があります。

現在はクライアントからのリクエストを受けたアプリサーバからRabbitMQにリクエストを送信し、RabbitMQが通知サーバを一元管理してユーザーにpush通知を送信する仕様となり、システムの疎結合を実現。サーバの柔軟な増減や、突発的なアクセスへの備えができるようになったと語りました。

りーお＠DeNAさん「Perl初心者が作ったサーバ運用ツール」

DeNAで運用エンジニアを務めるりーおさんは、日々の運用作業における手作業ミスを軽減する手段としてサーバーセットアップを抽象化させて管理するフレームワーク「Touryo（棟梁⁠）⁠」を発表しました。

実行コマンドをDSLとして指定したうえで一連の処理をプロシージャとして定義し、書き出し先の設定ファイルをText::Xslateによってテンプレート化。サーバをロール単位に区切って個別に処理を定義することができるなど、抽象的かつメンテナンス性の高いセットアップが行えるようになったと語りました。

KOMORI Kazukiさん「Perl Ocean - XMPP based realtime communication framework suite」

mixiのエンジニア、@lapis25さんことKOMORI Kazukiさん。XMPPプロトコルを中心とするリアルタイムコミュニケーションフレームワークスイート「Perl Ocean」について発表しました。かつてはJabberと呼ばれた拡張可能なメッセージとプレゼンスのプロトコル「XMPP」に準拠し、一般的なメッセンジャやグループチャットの機能を実現しています。今後はイベントプッシュ通知やHTTP Bindingのサポート、オーディオ／ビデオチャットの機能も追加予定とのことです。

同時接続数リミットやプロセスブロックといった問題はポーリング型プロトコルの悩みの種ですが、これを解決する方法としてPerl Oceanではgearmandをベースとしたメッセージブローカを実装。フロントノードから送られてきたリクエストをデリバリーサーバに割り振り、Webサービスとのやり取りやフロントへのレスポンスを担わせることでフロントエンドと実際の処理を担うサーバを分離。バックグラウンドで再起動などが可能なように工夫しているそうです。

Perl OceanはPerl 5.8以上で動作します。Artistic Licenceに基づいたオープンソースとなっており、GitHub上で誰でも自由にソースコードへアクセス可能です。また現在mixiにて、このPerl Oceanを利用したサービス「mixiの友人とチャット」がトライアル公開中です。詳しくはmixiのサイトをご覧ください。

motemenさん「Perlでファントムする！改め　Wight - Phtantom's new friend」

はてなのエンジニア、motemenさんの発表です。Ariya Hidayat氏開発の「PhantomJS」（⁠JavaScript API経由でWebKitを操作するツールキット）をPerlから操作するラッパー「Wight」を紹介しました。

PhantomJSは「Headless（視覚的なインターフェースを持たない⁠）⁠」というコンセプトのツールキットで、アクセスしたWebページに対して、そのページとは別のコンテキストのもと、ページの要素へアクセスしたり、キーイベントを発生させることができるという優れもの。これをPerlアプリケーション上から自由に操作できるようにすることで、Coroによる並列化やLWPによる高機能なアクセスなど、CPANモジュールの恩恵を受けながらリッチなアプリケーションが書いたり、Proveによる効率的なテストを行えるようになるそうです。

今回のセッションでは、実際にこのWightを用いたアプリケーションでtumblrにアクセスし、ブラウザでの画面スクロールをエミュレートしながら、tumblrの追加読み込み機能を利用してreblogされた画像を取得し続けるデモを披露しました。

Wightの実装にあたっては、RubyとPhantomJSで通信するライブラリ「Poltergeist」を参考にしたというmotemenさん。Perl側からWightを経由してWebページ上のJavaScriptを実行してその値を取得したり、またWebページ上のプロンプトをPerlから動的に操作することも可能とのことです。jQueryのクエリビルダも用意しており、jQueryクエリを用いてWebページを操作することもできると語りました。

今後はWWW::Mechanizeとの連携や、フレームを用いたページへの対応を検討しているとのこと。WightはmotemenさんのGitHubにて入手可能です。

まつけん@yokoninaritaiさん「GitHubを使った開発とデプロイ」

まつけん@yokoninaritaiさんのセッションは、開発体制をgithub中心にした際の経験果断でした。最初にツールとgithubの紹介の後、移行の経緯について話しました。最初はsvnで開発していたのですが、人数が増えてきてマージなどが大変になり、移行を決意したとのことです。

移行に際しては、必要な時に上司に相談して社内的な了解を得ながら進め、操作の取得は社内勉強会をおこなって乗り切ったそうです。

開発とデプロイの体制をプルリクエスト中心にすることで、大幅な省力化も果たせたとし、効果が大きかったことが伺えました。

Atsushi Kobayashiさん「Distributed Job System. Clutch」

Atsushi Kobayashiさんのセッションは自身が開発されたジョブキューシステムの発表です。

複数のサーバーdeamoontoolの管理用にwebUIを作ろうとしたところ、ちょうどいいものが無いので開発したとのことです。クライアントが直接ワーカーと槍とるるするモデルで、シンプルなのが特徴。管理や操作が容易で,フレームワーク化もされているそうです。セッション後にも熱心に質問があり、関心の高さが伺えました。

Yuji Shimadaさん「続・Mobage を支える技術」

DeNAのYuji Shimadaさんのセッションは「続・Mobage を支える技術」というタイトルで、今年春に出版された「Mobage を支える技術」でカバーしきれなかった話題を中心に行われました。

自己紹介代わりに、Shimadaさんご自身が書かれたCPANモジュールの紹介をした後、自身が勤めている株式会社ディー・エヌ・エーや「Mobage を支える技術」の宣伝などを行いました。

Mobageで利用されているWorker（本トークではMessage Queueからqueurを取り出して処理するものに相当）は、そのWorkerが担当する機能ごとに存在しており、Parallel::Preforkを利用して複数のプロセスで動作してスループットを向上させているそうです。そこで問題となってくる、「⁠kill TERMシグナルが送出されてきた時にどうするか」というWorkerでのシグナル処理の方法を、デモを交えながらステップバイステップで説明しました。

また、新しいAPI として"Remote Notification API"と"Leaderboard API"の2つのAPIの紹介をしました。

"Remote Notification API"はiPhoneやAndroidの端末にプッシュ通知を実行できるAPIであるとのことでした。一旦モバゲーのサーバがリクエストを受け付けてそれをWorkerが処理し、各スマートフォンに合った形でメッセージを送信するという一連のプロセスを、APNsやC2DM、GCMといった各スマートフォンに対応するプッシュ通知サービスの説明とともに解説しました。

"Leaderboard API"はその名の通り、ソーシャルゲーム等で利用されるランキングをリアルタイムで作成できるAPIとのことでした。データベースにはKey-Value 方式のRadis を採用しており、これはANSI Cで書かれていることで多くの環境で動作し、さらに色々なデータ型をサポートしているため使いやすいと話していました。このAPIの特徴として、アプリケーションごとに複数のランキングを生成できることや、ランキングの詳細の取得ができることを挙げていましたが、その一方で同一スコアのものを同じ順位に設定することができないという欠点も言及していました。

最後にDeNAのエンジニアの求人とともに「3割打てば年収1億円！」として野球選手の求人も行い会場を沸かせていました。

Kazuhiro Osawaさん「位置情報系処理のお話 a.k.a 続・自文書抽出日本的住所」

NHNのエンジニアであるKazuhiro Osawaさん位置情報技術全般に関わるセッションです。

まず「位置情報は妥協が大事でありやることに見合った精度が大事」と述べた後、NHNのサービスであるロケタッチのバックに使われている技術をperlモジュールを中心に説明しました。

測地系の違いを吸収するモジュールやフィーチャーフォンの携帯測地系の違いを吸収するモジュール、範囲検索に使用しているgeohashモジュールがあるそうです。geohashはz-orderingという手法を用いて空間をメッシュに分割した結果をハッシュとして表現する手法ですが、メッシュの境界付近の検索が弱いという弱点があり、それを補うために対象メッシュの周辺のメッシュも検索時にモジュールが自動的に含めてくれるそうです。

その後はOpenSrtreetMapのコンベンションに参加した経験や、北陸や熊本の地番の特殊性に触れた後で、ますます重要性をます位置情報について話しました。NHN内部のサービスでも位置情報がからむものが多く、改善用のデータを見やすくするために白地図APIを開発したそうです。

最後はロケタッチで新規に公開した住所表現正規化APIと鉄道情報APIの裏側について説明しました。鉄道情報APIを公開したのは日本は駅を中心にしているからだとのことです。

Tim Bunceさん「Profiling memory usage of Perl applications」

今回初来日のTim Bunceさんのセッションは、日本語で「ありがとう」と招待されたことへのお礼から始まりました。NYTProfやDBIの開発者でもあるBunceさんの今回の発表のテーマは、メモリのプロファイリングについてです。最初は基本的なsystemコマンドで、system("cat /proc/$$/stat")などでメモリの使用量をウォッチできることを紹介しました。

その後、仮想メモリやPerlのデータのメモリ構造のチュートリアルを経て、Bunceさんが作成中のメモリプロファイラについての話へ移りました。使用しているメモリを正確に測るDevel::Sizeを拡張してフックを用意し、その出力を外部スクリプトで分析するというもので、日曜日には公開されるとのことですが、先行してデモを行いました。

デモでは、メモリ使用量の詳細が文字で表示されるだけではなく、親子関係を表すグラフ表示や、NYTProfでもおなじみのtree mapでの表示も実装されて動いている様子を見ることができました。途中、Mooseを使うコードをプロファイリングしたところでtree mapを表示しきれず、長時間処理を待つことになってしまったので質疑応答に。のべ6人から質問があり、このメモリプロファイラへの期待の大きさが現れていました。

Hisashi HATAKEYAMAさん「スマートフォン向けサービスにおけるサーバサイド設計入門」

発表者は、コロプラの運用・インフラエンジニア、HATAKEYAMA Hisashiさん。今年春から新規サービスの立ちあげを行うことになった体験を振り返りながら、スマートフォン向けのサービスを立ち上げるプロセスを説明しました。構成は、サービスを作るための設計の話、サーバサイドの設計の話、アプリとの連携の話と言う流れです。

ネイティブアプリとして開発するかブラウザアプリとして開発するかの判断基準として、それぞれの形で開発した際のメリットとデメリットを紹介しました。たとえばネイティブアプリはカメラとセンサーが利用できてアプリマーケットからの導線がある、ブラウザアプリの場合はアプリアップデートの手間や影響が少なくシステム構成をシンプルに保ちやすいなど、具体的な特徴を示しました。

今回このトークの題材となったサービスはPerlで開発したそうなのですが、その理由は「使い勝手がいいから⁠」⁠。たいていのサーバにデフォルトの環境としてインストールされている便利さと数々のCPANモジュールが充実している点を挙げながら、最近はperlbrewなど、システムに依存しないPerl実行環境を作れることも魅力なのだそうです。

フレームワークはAmon 2を使用していると言います。まずスケルトンを作成し、API、管理画面、モデル、DB、例外と4つの並列した階層をつくってクラスを配置。モデルクラスには、APIに限らず管理画面やCLIからも呼び出せるよう、リクエストに依存しない処理をまとめて配置しているとのことでした。

レスポンスについても専用のオブジェクトを作って入れ子にし、属性名を加工するメソッドを生やすなどして工夫しちるそうです。発生した例外についてはアプリケーション共通で利用する例外クラスのインスタンスを投げる形とし、DispatcherやWorkerのレベルこれをキャッチすることで、各例外の内容に応じたエラーメッセージを作成しているとのことです。

本番と開発環境でドメインや改装が異なっていてもうまく吸収できるよう、Amon 2の持つ機能を利用して動的にconfigを切り替えられるようにし、異なるドメインの場合は個別にプロセスを立てるようにしているそうです。

最初に明確なポリシーを設けたうえで、それを実装に落としこんでいく様子が詳細に語られたトーク。20分という時間を感じさせないいほどの内容の濃さが印象的でした。

Yasuhiro Onishiさん「Redmine::Chan で IRC からプロジェクト管理」

発表は、はてなの大西康裕（id:onishi）さん。33週間新機能リリース中というはてなブログの開発サイクルを支えるプロジェクト管理スイート「Redmine」をIRC経由で直感的に使用できるフレームワーク「Redmine::Chan」を発表しました。

「管理自体が嫌にならないように」「⁠ブラウザを使わず、息をするように案件を登録する」をモットーに開発されたというRedmine::Chan．Any::EventとIRC::Client、WebService::Simpleから構成されたこのフレームワークは、IRCのボットとしてみずからIRCにログインし、自分に向けて話しかけられた内容を判断してRedmineのREST APIを叩く仕組みとなっています。1つのIRCチャンネルにつき1つのプロジェクトが紐付く仕様で、案件の登録からステータスの確認、また特定ユーザへのアサインも通常の会話中で行えるようになっています。

そのほか、案件ごとに特定のgitブランチを関連付けたり、バッファに溜まってるひとつ手前の発言ログをそのまま案件として登録する「SME（それめっちゃええやん⁠）⁠」機能など、はてなの実際の業務フローのなかでどのように使用されているかを具体的に説明しながらのトークは多くの人の興味を引いていました。

Redmine::ChanはGitHub上でオープンソースとして公開されています。

Tatsuro Hisamoriさん「平均レスポンスタイム50msをPerlで捌く中規模サービスの実装/運用」

発表はフリークアウトのエンジニア、「⁠50ms finder」ことTatsuro Hisamoriさん。広告関連技術のひとつである「DSP：Demand Side Platform」の開発運用を例に、瞬時のレスポンスが求められるサービスにおけるPerlの利用事例を紹介しました。

ネット広告におけるさまざまな形態のうち、共通したユーザー属性を持つ複数のサイトをまとめて束ねて巨大な広告枠として販売する仕組み「アドネットワーク⁠」⁠。このアドネットワークに広告を出稿するために導入されている技術がDSPです。広告の表示リクエストが飛ぶ度に複数の広告主によるオークションがリアルタイムに行われ（RTB：Real Time Bidding⁠）⁠、もっとも高い単価を提示した広告が表示される仕組みとなっています。入札から判定、表示にいたるまでには100ms程度の時間しか猶予がなく、少しでも入札に遅れてしまうと広告を出稿できないため、この仕組のなかでいかに速いレスポンス（平均50ms台）を返すかが至上命題となっています。

そんなDSPの仕組みなのですが、バックエンドは一般的なLAMP構成で特別なことはなく、実装の工夫でカバーしているとのこと。具体的には「できるだけ通信しない」「⁠できるだけI/Oしない」ことに注力しているそうです。例えばサーバ間通信の際に発生するホスト名のルックアップにおいても、サービスに関わる部分はDNSを使わずに/etc/hostsで管理。KVSについても、データファイルを直接サーバに配布することで外部との通信を行わないよう工夫していると言います。

つねに計測も続けることで改善点を探ることも欠かしません。Nginxのログにリクエスト／レスポンスタイムを書き込ませたり、一定数のサンプリング対象にDevel::NYTProfを噛ませてベンチマークを実行。CloudForecastやGrowthForecastなどの監視フレームワークも駆使して実行時間の視覚化を行なっているそうです。

「見えるようにしておけば説得力が違う。重要なものをはっきりさせるためにも、ビジネス指標を明確出せるようにすることが大事」とHisamoriさん。DSPの場合を例にすると、障害の深刻度は「配信が停止すること」続いて「入札が停止すること」の順番であるとし、「⁠その障害が⁠”有害⁠”なのか⁠”無害⁠”なのか、ただちにサービス・売上に影響が出るか否か」をすぐに判断できることが重要と語りました。

今回のセッションの内容も含んだ記事をWEB+DB press vol.70に寄稿しています。興味のある方はチェックしてみてはいかがでしょうか。

tagomorisさん「半リアルタイム・分散ストリーム処理をperlで」

NHNに勤務されているtagomorisさんの「半リアルタイム・分散ストリーム処理をperlで」というセッションです。

まず、「⁠ストリーム処理のストリームとは何か」という基本的な解説から始まり、切れ目なく増え続けるデータであるストリーム（Web サーバやアプリケーションのログなど）をEOFに依存せずに抽出や集計などの処理を行う「ストリーム処理」の基本について説明しました。

ストリーム処理をネットワーク越しに実行する事例を挙げ、「⁠重い処理を1つのサーバだけで処理をすると、他の処理がブロッキングしてしまう」として、複数のサーバーで重い処理を分業して実行する「分散ストリーム処理」の重要性を訴えました。

分散ストリーム処理が必要とされる理由として、できるだけレイテンシを短く、リアルタイム的に必要なデータを取得・処理する必要性を挙げました。バッチ処理を引き合いに出し、「⁠バッチ処理の場合、取得してくるデータ群の中で1つでもヘヴィーなトラフィックが存在すると、そのデータの取得だけでブロックングが起きてしまうので無駄」として、ストリームになっていると重いトラフィックが来ても別のノードに退避させることができ、ブロッキングを回避できるため優位であると述べていました。

またデータのI/Oに関してバッファリングの重要性を挙げ、「⁠どの程度の容量、どの程度の時間バッファに貯めるのかを見極めなければならない」と話していました。「⁠プロセスが不意にクラッシュした場合には、ロストするデータの量に関しても考慮しておく必要がある」とリスクマネジメントについても言及しました。それに関連して、バッファリング・キューイングの話題やKeep Alive、コネクションプーリングやロードバランシング、ルーティングやハイアベイラビリティといったストリーム処理に必要とされる技術をひと通り解説しました。

「これらのストリーム処理に必要とされる技術を1からすべて実装するのは大変なので、フレームワークやツールを利用するべき」として、"Apache Kafka"や"Twitter Storm"、"Fluentd"といったフレームワークを紹介し、このトークでは"Fulentd"を中心に解説していました。"Fluentd"はログを集めて集約および保存をMessagePackと呼ばれるハッシュライクなデータ構造で行うTreasureData社製の分散ストリーム処理フレームワークとのことで、タグベースでルーティングが実行でき、強力なバッファリング機構もサポートされていると話していました。また、プラグインによる機能拡張も容易に行えるとのことで、そのプラグインの1つであるexec_filterというSTDINに入力してSTDOUTに結果を流す処理を自動で行なってくれるプラグインを紹介しました。ただ、"Fulentd"の問題点として、バッファリングが一定の容量に達しないとflush しない点や、エンタープライズ向けのためデータの安全性を重視するあまりパフォーマンスが多少犠牲になっている点、またWindows環境で動作しない点を列挙しました。

それらの問題点を解決するために作られた、Perl製の"Fluent::Agent"と"Fluent::AgentLite"を紹介しました。これらは"Fluentd"をバックグランドとしており、シンプルかつ高速でデプロイが簡単で、1インプット、1アウトプットのストリーム処理に特化しており、かつ非同期I/Oを実現したモジュールとのことでした。"Fluentd" のexec_filter 相当の機能も実装されていて、"Fluentd" で挙がっていたバッファリングの問題やメモリ使用量が解決されていると話していました。

最後にまとめとして「バッチで処理をガリガリ書いていくよりもストリーム処理を上手く活用すれば幸せになれる」としてトークを結んでいました。

Lightning Talks Day 1

本日最後のプログラムはLightning Talks（LT)です。

今年はLT参加者には特製のTシャツが配布されました。

takuji31さん「Android開発入門for Perl Mongers⁠」⁠

takuji31さんはAndroidアプリの作成方法を紹介するとともに、Androidの開発者を募集するLTでした。Androidの開発には、$25と不具合に折れない心が必要だということです。

tokuhiromさん「Furl」

tokuhiromさんは事前に話していた内容と全く関係のないFurlの話をされていました。多くのCPAN Authorの力で実装されており、動作が早く拡張性があることが売りとのことです。途中、FurlのLTが最初に行われたのが去年か一昨年かで議論が起こりトークが中断する自体に。著者が調べた所、FurlのLTは去年ではなく一昨年でした。

Ktatさん「Perldoc.jp 10周年」

perldoc.jpはPerlのドキュメントを日本語に訳すサイトですが、今年で10周年を迎えたそうです。もともとmiyagawaさんが2002年に始めたこのサイトですが、argrathさんの継続的なメンテナンスにより長続きし、JPAによるリニューアルを経て10年という節目を迎えることができたそうです。

zeniivaさん「株式会社モバイルファクトリー Hello Perl World」

同社の開発部に異動となったzeniivaさん。開発部部長と結婚し、「⁠変更には慎重あれ」という格言を身を持って知ることができたそうです。入社すると結婚できるかも、と自身の経験を元に振り返っていました。

egoproさん「おどけでね Sendai.pm」

「おどけでね」とは仙台の言葉で「並のことではない」という意味だそうです。2分間という限られた時間でのLTでしたが、著名なPerl hackerを招いた特別講義が行われることを紹介すると、会場からは驚きの声も上がっていました。

studio3104さん「Fluentdでコードを書けるOpsになれる話」

インフラエンジニアがコードを書くためのLT。studio3104さんは、fluentdのexec_filterを使ってPerlのコードを書くのがオススメだと紹介しました。最後は残念ながら時間がなくなり、銅鑼が鳴らされてしまいました。

nqounetさん「ニフティクラウドC4SAを使ってみた」

C4SAはPaasで、GUIで使うことができるそうです。会場で「黒い画面が苦手の方」は少なかったものの、GUIの便利さは伝わる内容でした。今後、MA8に向けたハッカソンを実施するそうです。

@cubicdaiyaさん「ngx_small_light～Nginxで動的サムネイル生成～」

nginxにて画像のサムネイル作成を行う際に便利なngx_small_lightについて発表しました。よくある上司の一声からApacheとnginxの狭間を点々としながら完成して行く様は、現代のエンジニアの置かれる状況を反映していて大変興味深いものでした。

藤堂さん「株式会社ガイアックス」

福岡の研究開発拠点を新設したガイアックスさんですが、資金を使い過ぎてしまい東京では色々と困っているそうです。そんな中でもCodeIQさんと組んで「素数戦争」というプログラムの高速化コンテストをやるとのこと。目が離せません。

kan.fushiharaさん「へんなもの」を作ってみた

25Kgの減量に成功したというfushiharaさん。エンジニアとして成長したかを見るためには昔のコードを再実装してみるとよい、と、Wemaという付箋のアプリケーションを再実装されていました。途中マシンのバッテリーがなくなりかけましたが、なんとか最後までトークを終えることができました。

keigo.tanaka.77さん「AWS Elastic Beanstalk Custom AMI で PSGI Hello World」

AWSを使ってPSGIファイルを走らせるまでの手順を紹介しました。AMIとして保存されているそうですが、ゴミも残っている状況であり、欲しい方はkeigoさんに直接声をかけて欲しいとのことでした。

ノダイイチロウさん「Wano株式会社」

ノダさんが代表を務めるWano株式会社は、音楽とWEBのサービスを作る会社とのこと。CTOの加藤さんがJPA理事に就任したことを受けて、LTに参加したそうです。新サービスtunecoreの動画は素晴らしい出来で、流れ終わると会場からは自然と大きな拍手が起こっていました。

hiratara「Perlでおねえさんを救った話」

本記事のレポーターを務める@hirataraが自ら担当したセッションでした。日本科学未来館の公開した「フカシギの数え方」の動画を題材に、ZBDDを使ったアルゴリズムについて話しました。

mayumineさん「Perl と人生」

昨年に引き続き登場したmayumineさん。相変わらずPerlは書けないとしつつも、人生をPerlの文法で見事に表現するこのLTにより、今日の発表の中で一番の喝采を浴びていました。続きはgithubで公開されるとのことです。

LT-thon

多目的スペースでは、Hachioji.pmの有志によるサイドイベント「LT-THON(エルティソン)」が催されました（YAPC::Asia 2012 LT-THONの公式サイトはこちら⁠）⁠。

LT-THONは、LT以上に気軽で敷居の低い発表ステージとして企画されたもので、一日目では26名ものスピーカーによる発表が披露されました。

まずHachioji.pmの主催uzulla氏によるスピーチで始まり、「⁠拍手くん」（⁠会場に拍手の音を鳴らすwebアプリ）の案内と、飛び入り参加をどんどんしてほしいという旨のお願いをしていました。

また、発表することによるコミュニケーションの充実を狙っているとも語っていました。

非常に盛り上がったため、特に目立った発表をピックアップしてお送り致します。

neko_gata_sさん - 小さなプログラムによる実験音楽

LT-THON 一番手は、Niigata.pm主催のneko_gata_sさんによる発表でした。とあるC言語で構築されたプログラムを見てインスパイアされたらしく、C言語とPerlをつかって波形を構築し、音声データを鳴らしていました。

ビット演算等を駆使して、ライブコーディングを交えて音に変化をつけるデモで、観衆を沸かせました。

daniel_nakanoさん - 「⁠今必要なのは、造船所です！」by飲食店で働く一従業員

都内のシュラスコで働いているというdaniel_nakanoさんの発表が印象的でした。

飲食業の問題点として、何でも手作業＆アナログで済ませてしまう傾向にあるということを指摘し、IT業界などの情報リテラシーの高い業界を「ビットの海」と例えると、自分が身を寄せている飲食業はその真逆の「アトムの陸」と呼び、その仲介役となる「造船所」が必要だと主張しました。

飲食店向けのwebサービスはきっと需要があるだろうから、誰か作りませんか、と聴衆に聞く場面もありました。

YAPCでは珍しい内容の発表だったと感じられました。

M_Ishikawaさん - おせっかい駆動開発のすすめ

趣味でジオコーディング関連等のプログラムを開発しているというM_Ishikawaさんは、誰かを手助けするためのおせっかいツールの一つとして、某大手掲示板の監視を行うプログラムの開発について解説、業務支援に一役買っていると説明していました。

モチベーション維持のコツとして、好きなことをやるのが大事だと言い、誰かを手助けすることで感謝されることのよさを、非常に楽しそうに語っていました。

tk0miyaさん - Excel方眼紙撲滅委員会活動報告 2012.09

Sphinx-users.jpのtk0miyaさんが飛び入りでLT-THONに参加。Excel方眼紙(Excelのセル幅高さを方眼紙のように扱ったドキュメントのこと)がよく利用されるものとして画面遷移図等を例に、問題点を解説しました。

それらに対する解決案として、画面遷移図を生成する自作のコマンドラインツール"Blockdiag"を紹介しました。web用のデモサイトを用いての実践デモでは、非常に簡潔な使い勝手に聴衆も沸き立ち、「⁠拍手くん」もまさかのダウン。

非常に有用なツールをシンプルな形で提供・紹介する、切れのよい発表でした。

sugyanさん - ドルヲタを支える技術

アイドルグループ「ももいろクローバーZ」の大ファンだと自他共に認めるsugyanさんが、アイドルに傾ける情熱をどのようにHackするのかを紹介しました。

メンバーのブログについたコメント数の可視化や、ライブのチケット入手を半自動化するなど、非常にハッカーらしい解決方法に観衆も爆笑していました。

懇親会

1日目のプログラム終了後、多目的スペースにて懇親会が催されました。はじめに、スカイアーク代表の小林さんが乾杯の挨拶を行いました。その後は時間いっぱい、皆さん歓談していました。

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