YAPC::Asia Tokyo 2013 スペシャルレポート

YAPC::Asia Tokyo 2013 1日目レポート[更新終了]

19日から21日までの3日間、慶応大学日吉キャンパス 協生館にて「YAPC::Asia Tokyo 2013」が開催されます。昨日は前夜祭で、本日は1日目ということになります。ここでは、1日目の模様を随時レポートしていきます。

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

受付は、藤原洋記念ホール前に設置されています。

画像

オープニング

JPA運営事務局長の櫛井さんから、オープニングの挨拶です。今年の企画として、次のものを案内しました。

  • 遠方からの参加者支援制度
  • 懇親会無料化
  • ランチセッション
  • ランチ交流企画(くじを引いて4人一組のチームが決まる。抽選でお弁当ももらえる)
  • BOF・交流スペース(アンカンファレンス等で利用もOK)
  • Perl入学式

参加者には、⁠トークを楽しむ」⁠Perl Hacker達との交流」⁠ベストトーク賞への投票」を挙げ、今年もYAPC::Asiaを楽しみましょうと呼びかけました。

画像

Ricardo Signesさん「Perl5 ? Postcards from the Edge⁠

2011年に続き来日されたRicardoさんは、パンプキンと呼ばれるPerlのプロジェクトマネージャーを務めています。今回は最新のPerl5の情報や、今後の開発の展望について話しました。

Perlは5.18になり、スレッドに関する一部不具合の修正や、正規表現の文字集合に関する演算の追加、レキシカルなサブルーチンの採用、ハッシュのキーのランダム化など、実験的な機能も含めて多くの機能追加が行われました。しかし、Ricardoさんによれば「Perl5はあくまでもPerl5である」とのこと。Perl5の良さをそのままに、今後も開発を続けていくということをうかがわせました。

話の最後にはPerl5.20の新機能についての予告も。デリファレンスをもっと簡潔に書ける機能や関数で引数に名前を付けられる機能など、さらに多くの機能が入っていることを紹介しました。会場からはMOP::Reduxに関する質問もでましたが、こちらは5.20には入らないようです。今後のPerlの新バージョンも楽しみになるトークでした。

画像

画像

PSGI/Plack・Monocerosで学ぶハイパフォーマンスWebアプリケーションサーバの作り方

Masahiro Naganoさんは「PSGI/Plack・Monocerosで学ぶハイパフォーマンスWebアプリケーションサーバの作り方」をテーマにお話しました。livedoor blogも10周年を迎えて内部構造をmod_perlからPSGIベースに変更したこと。ご自身が作成されたprefork型でありながらready C10K であり非常に高速で動作されるというMonocerosのが解説。PSIGで簡単なStandaloneServerを作成できることや、簡易的に作成した場合どのような課題が発生しうるのかを解説しました。またPSIGサーバーの種類が沢山あるのでピックアップした上で簡単な使用のためのケース分類をしました。そしてボトルネックの検出方法としてDevel::NYTProfとstraceの例を使用して説明しました。ご自身はopen & shareを大事にされていて現在動いているほかのPSGI ServerなどにフィードバックしているのでPSGIそのものも以前より早くなっていますよという話もしていました。

画像

画像

Songmuさん「今時のカジュアルなデータベース関連開発」

今年はDB関連の話が他になく時代の流れを感じると語るSongmuさんのトークは、データベースを利用したアプリケーション開発のノウハウをまとめたものでした。

まずはスキーマ管理方法の紹介です。DBIx::Schema::DSL, GitDDL, GitDDL::Migratorといったモジュールを利用した管理方法をデモによる実演を交えて解説しました。スキーマ自体もSQLではなくPerlで書かれており、そのメリットとしてPerlモジュールと定数を共通化できるなどよりDryに管理できることや、シンタックスチェックが楽なこと、SQLの出力が統一されるためバージョン管理と相性がよい点などをデモによる実演を交えての紹介でした。

MySQL以外のデータベースとしてはRedisをよく利用しているそうです。SortedSetによるお手軽ランキングや、Setによりログインユーザを残しておいたり、Listをジョブキューとして使うなど、様々な型を組み合わて利用するのが面白いそうです。特にSetは和集合/差集合など集合演算を利用できることが魅力であるとのこと。ただ注意点としてExpireの設定が重要なことや、冗長構成が難しいこと、永続的なデータは置かない方がよいなどのアドバイスもありました。

その他にもUnicode関連や例外処理など盛りだくさんな内容で最後は駆け足となってしまいましたが、実践的なノウハウをたくさん得られる発表でした。

画像

画像

Kosei Moriyamaさん「BrowserStack を用いたクライアントサイドのテスト」

画像

画像

MoriyamaさんはJavaScriptのテストを自動化をテーマに発表しました。最近ではJavaScriptはクライアントサイドはもちろん、サーバサイド、ブラウザ拡張、スマフォアプリなど、様々なところで登場するようになりました。しかし、旧来のQUnitのようなブラウザでのテスト方法では、CLIでの扱いが難しく、テストの自動化が難しいという課題がありました。

Moriyamaさんの提案する解決方法は、BrowserStackというサービスを使ってそれらを自動化しようというものです。BrowserStackは複数の種類のWebブラウザをクラウド的に借りることができるサービスです。デモでは、実際にこの上でSeleniumを動かすことで、様々な実行環境においてJavaScriptのテストを走らせていました。

学術分野におけるPerlの活用例

企業でのPerl利用例は多く挙げられているものの、⁠大学や高専などの研究分野で道具としてPerlを利用している」という話はあまりうかがい知ることができません。このセッションでは、現在、大学院に所属しているpapixさんが、ご自身が在籍している研究室での取り組みや状況、同僚や教授陣へのアンケートの結果を紹介しました。また、GPGPU(General-purpose computing on graphics processing units)の研究でどのようにPerlを利用しているかを紹介しました。余談ですが、papixさんの画像はCreative Commonsで利用可能だそうです。

大学でのサンプル数を増やそうとしたそうですが時間の都合で所属されている研究室だけの紹介ですので以降そのあたり鑑みながらお読みください。

よくある話ですが、papixさんの研究室でも先輩からコードごと引き継ぐので強制的に多くの学生がPerlを利用しているそうです。しかしながら、経年による改善・改良によりコードの秘伝のタレ化・テストが無いなどの問題が発生しているそうです。この辺り大学でも企業でも同じ課題があるようです。

学生へのアンケートからは、授業ではC/Javaが多いため、⁠取りあえず動く」⁠型を意識しなくても良い」⁠正規表現などの機能・モジュールがよい」がメリットとして挙げ、⁠遅い」⁠コーディングルールが難しい」⁠変数の型がわかりにくい」などがデメリットとして挙げられていました。

最後に、GPGPUを扱うLLモジュールについての紹介と現在研究で開発中のPerlからGPGPUを扱うperCUDAというモジュールを紹介しました。

画像

画像

ランチセッション

お昼時にイベントホールでは、Six Apart社の高山裕司氏によるランチセッションAが開催されました。MovableTypeについて講演を行いました。

画像

画像

ランチセッション2つ目は、Microsoftの佐々木邦暢さんの発表です。Perl大好きと語る佐々木さんは、Perlとの関わりを述べた後、Azureを紹介しました。日本リージョンができるそうです。

画像

画像

大規模Perl初心者研修を支える技術

このセッションではDeNAに入社した71名(!)の新卒、中途採用に対して研修を行った「大規模な技術研修」について語りました。この研修での一番の目的は、1)変化に対応できる、2)主体的に技術習得できる、3)技術以外も成長できる、という「自走できるエンジニアを育てる」ということでした。そのために現場のエンジニアからの協力を仰ぎつつ、一番コストが掛かる「個別のワークショップ」を行ったそうです。その中で面白い取り組みに、早抜け方式で早く終わった方から研修を終わるという研修期間の採用でした。

研修の運営で大変だった課題として、1)人多すぎ:名前と顔が一致しない、一人あたりのコミュニケーションが減る、2)個々人の状況が把握が困難、3)講師間の意思疎通も大変、を挙げていました。これらの課題に対して、1)ランチや(安く挙げる宅飲みなど)飲み会を増やす、2)フォローアップ研修をマメにやる、3)毎日1時間MTGで講師間の課題の共有、を行って解決していたそうです。

技術的に研修で最も難しいのはそもそものプログラムスキルや、やはりオブジェクト指向とWeb Application Frameworkの理解だったそうです。これらの課題を解決させたのは、新人自体に勉強会の開催を促すことで、例えばSQL::BuilderやClass::Data::Inheritableのコードリーディングが行われたり、飲み会でできる同期に説明を受けたりといった、大規模だからこそ現れる「できる同期」の存在をうまく活用したことだったそうです。

大規模だからこそ、同じような急成長や同じような問題にぶつかる研修生が現れた場合に、そのノウハウや課題解決の方法を横展開することができたそうです。このようなことができたのも、71名と大人数だったにもかかわらず、フォローアップを含むできる限り濃密な時間を作るようにした結果ではないでしょうか。

画像

画像

takesakoさん「SPDY、HTTP/2.0の使い方」

ドヤリングの定義から始まった竹迫さんの発表です。httpで公衆無線LANを使ってるとFiresheepでパケットキャプチャされて、ハイジャックされるということが話題になりました。このツールがデフォルトで対応しているWebサービスが有名なところも含めて非常に多かったため、各社一斉にhttpsに対応したそうです。

このSSL対応の際の各社の対応として、1)headerにsecure属性/httpOnly属性の追加、2)HTTP通信をHTTPS通信に切り替えさせるStrict_Transport_Securityヘッダの追加を紹介しました。また、このような対策の中で、TLS/SSL上に安全な通信レイヤを構築するSPDY・HTTP/2.0の対応が各社によって行われ、GoogleやTwitter、FacebookではSPDY/3の対応が行われているようです。

SPDYを使うための方法として、1)mod_spdy (SPDY/3) Googleがdepパッケージを提供、2)node-spdy (SPDY/3)、3)nginx 1.3.14 (SPDY/2)を紹介さしました。SPDYのライブラリとしてはspdylayが紹介されました。このライブラリを利用することでspdycatというコマンドを利用することができ、spdyの中身を見ることができます。また、Perlのライブラリとしては、今年の8月に入ってからようやくProtocol::SPDYがリリースされたそうです。

最後にSPDYがまだまだ普及しない現状を踏まえ「Outbound Port 80 Blocking (HTTP)」の提案がありました。内容としては、1)HTTP (80) 通信をすべてブロック、2)信頼できるSSL/SLS(443)通信のみを許可、3)WebサイトのSSL化を促すというものです。これにより普及が促され、ユーザとしても安全な通信経路でドヤリングできるのでよいのではないでしょうか。

画像

画像

SUENAGAさん「0から学んだポストモダンPerl」

画像

画像

hiratara 「Types and Perl Language」

このトークについてはスピーカーである本間が自らレポートします。

まず、マシンのトラブルで開始が遅れてしまいましたこと、お詫び申し上げます。すみませんでした。このトークでは、Perlのプログラムを題材に型理論の初歩について簡単にお話しました。

簡単に言うと、型はプログラムがある種のよい性質を持っているか、持っていないかを判定するために使えます。これを、⁠型付けできる(typable⁠⁠」と言います。まず簡単に型のないラムダ計算について説明してから、型付きラムダ計算について説明しました。また、型付けの表現を豊かにする手法として、多相型とレコード型について解説しました。

画像

画像

Naoya Itoさん「モダンPerlリファクタリング」

Naoyaさんは、既存のPerlコードをどのようにしてリファクタリングをしていくとよいか、具体的な例を交えて解説しました。題材は、知る人ぞ知るText::Md2Inaoというモジュール。Martin Fowler氏の著書を引用し、リファクタリングを行うべきタイミングは「新機能を付け加えるのが困難となったとき」であるとしました。

リファクタリングを始めるにあたって一番大切なのは、End to Endのテストをしっかり書くことです。そのためのツールとして、特にWEBアプリケーションの場合はPlackを始めとして、Plack::App::WrapCGIなどのモジュールを用いるとよいと紹介していました。さらに、回帰テストを貯めることで、さらにリファクタリングを進めやすくなります。

ただ、リファクタリングをするにつれてテストを書くのが簡単になることから、⁠テストファストを徹底しすぎるのはむしろよくない」と注意を述べました。End to Endのテストをしっかり書いて足回りを固めたら、リファクタリングをしながら徐々にテストを増やしていくのがベストプラクティスのようです。

画像

画像

Kazuhiro Osawaさん「Inside amon2-livedoor-setup.pl with web application development 2013」

Kazuhiro Osawaさんは「Inside amon2-livedoor-setup.pl with web application development 2013」をテーマにお話しました。

標準のセットアップツールが最近のWAFにはついてきますがそのまま使用してしまうことが社内環境を考慮していないシステムを構築してしまい社内的に技術的負債を作る流れになってしまうため社内環境を意識したツールを選んで共有できることを増やし、コピペ駆動開発をいかにして防ぐかという内容でした。

amon2-livedoor-setup.plというセットアップツールを作成し自社独自の設定をあらかじめ書いておくことにより自動的に最新の状態が共有され秘伝のたれが回避されノウハウが共有される流れをつり、また事故を防ぐためにconfigに間違った設定があればデプロイできないような仕組みを導入したりして集団開発をすることによって起きうる負債が蓄積されることを防ぐ仕組みを導入していました。

最後にこのスクリプトを特定の企業向けではなくそれぞれの会社で作れるようにgithubにアップされているKsgkというモジュールを紹介し、設定をPerlで書くことができるので特定の機能に関するレシピが生まれてくるのではないかと、将来に向けて期待していました。

画像

画像

karupaneruraさん「ぼくがかんがえたさいきょうのMVC」

karupaneruraさんは「ぼくがかんがえたさいきょうのMVC」をテーマに話しました。

MVCModel,Veiw.Controllerが果たす役割を基本に立ち返って説明しました。巨大なModelができる、SQLが色んなところに書かれているなどのMVCをやっていて起こりうる問題を例示し、こういった問題点をなくすためにどうしたら良いのかを紹介しました。

MVCはアプリケーションの種類に応じて適用が異なることが重要であるとしてWebアプリを例にとって紹介しました。最後に、MVCの実現方法として、チーム内の規約を作ることとそれをきちんと守っていくようにレビューやテストをすることが重要だと述べていました。

画像

画像

Toru Kobayashiさん「個人で出来る!PerlによるWebアプリケーションの作り方」

個人でいくつものWebアプリケーションを開発しているKobayashiさんは、個人でのWebアプリケーション開発のメリットについて話しました。

Webアプリケーションを開発するにあたって、Perlのバージョン管理に有用なplenv、モジュールの管理に有用なCarton、そして数あるWebアプリケーションフレームワークの中でもシンプルで使いやすいAmon2を紹介しました。

フロントエンドの開発でも、JavaScriptのフレームワークとしてbackbone.jsとAngular.jsを紹介しました。backbone.jsは日本語の情報が多く導入しやすいとのこと。一方Angular.jsは学習コストは高いが多機能でテストも書きやすいとのことでした。他にもTask RunnerのGruntやフロントエンドのライブラリを管理してくれるBowerについても取り上げました。

最後に、実際にWebアプリケーションを開発することで多くの学びを得られること、そのために試せる環境を用意することとスモールスタートすることが大切だと述べていました。

画像

画像

Taiki Kawakamiさん「CPAN Testers Reportの情報を上手に使おう!」

先日まではてなでインターンされていたというKawakamiさんは、初めにインターンの成果であるはてなブログのAtomPub APIについて説明しました。その後、本題であるCPAN Testers Reportについて話しました。

Perlの世界ではテストが大事だというKawakamiさんは、CPAN Testers Reportから得られる情報がモジュールのユーザにとっても開発者にとっても有用だと語りました。CPAN Testers Reportを見ればモジュールがテストをクリアしているかどうかを環境(OS、Perlのバージョン)ごとに知ることができるとのこと。⁠Perl/CPANは枯れている」と言われるのもCPAN Testers Reportによるところが大きく、これらのテストの結果はすべて有志のテスターの方々によって確認されているそうです。

モジュールの開発者にとっても、どのテストが失敗しているか、どのような依存モジュールがあるかなどを確認できるそうです。ただ、その結果は少々読みづらいとのことで、現在それらの結果をまとめて見れるような仕組みを作っているとのこと。また、CPAN Testers Reportの結果を元に再現環境を用意してくれるTestamentというツールも開発中とのことです。

画像

画像

Dan Kogaiさん「Perlは他言語(から|に)何を(学んだ|教えた)か」

小飼弾さんのトークは聴講者との対話とライブコーディングを中心に行われました。最初にFizzBuzzについて、聞いたことがある人に挙手してもらい、FizzBuzzとはどういうものかを挙手した人に説明してもらいました。FizzBuzzについての説明の後、手続き型プログラミングでの実装例としてCで書かれたFizzBuzzのコードを紹介しました。

次にRuby1.9での配列を用いたFizzBuzzの実装を提示し、Perlでの同様の実装をライブコーディングを行いました。さらに今度はHaskellでのFizzBuzzの実装を提示しました。これまでに提示された様々な言語での実装ではFizzBuzzを処理する関数に対して数値を引数として与えていましたが、HaskellではFizzBuzzを処理する関数が引数として与えられる側になるとのこと。関数を引数として与える実装方法は、たとえばJavaScriptでは難しくないそうです。Perlでは難しいけれど不可能ではないとのことでした。

画像

画像

Tokuhiro Matsunoさん「僕の考えたFuture Perl」

「僕の考えた Future Perl」改め、⁠Perl の過去と未来」というタイトルで、tokuhirom さんが発表しました。

まず Perl全体の歴史のおさらいから始まり、Perl5のリリースの歩み、そしてPerl5の最近の動向について解説しました。動向の解説では、Perl国勢調査で得られた、国内で利用されているPerlのバージョンの割合を図を交えて紹介し、それと併せてPerl5.10以降の変更点や追加機能について説明しました。

その中で追加機能のいくつかを取り上げ、それらが Perl6 からバックポートされているものが多いことを挙げた上で、tokuhiromさんが作成したRegexp::Rulesという、Perl6のRuleをPerl5にバックポートしたモジュールについても紹介しました。また、MoeやCompiler::Lexer、Compiler::Parser、gperlといった、ここ1, 2年で流行の兆しを見せているPerl5のオルタナティブな実装に関しても紹介し、聴衆の興味をひいていました。

Future Perlのもう一対であるPerl6に関しても、パフォーマンス等の現状の問題点について明らかにして上で、現在ホットなPerl6処理系やRoastと呼ばれるテストスイート、JunctionやMOP、Reduction OperatorといったPerl6特有の機能を詳細に解説しました。

トークの最後ではtokuhiromさんが開発しているSeisと呼ばれるPerl6のコードからPerl5のコードに変換する、コーヒースクリプト的なトランスパイラの紹介もデモを交えて紹介しました。Seisに触れることによってPerl6を書き、勉強するきっかけになってほしい、そしてコントリビュートしてほしいと締めくくりました。

画像

画像

Masaru Hoshinoさん「大きくなったシステムを元に新たな環境を作る取り組み」

昨年に引き続き、Masaru Hoshinoさんによる、mixiのサービス開発の変遷についての発表でした。

まずはPerlのバージョンアップに関する事例からです。Perl-5.8.8からperl-5.14.4にバージョンアップした際、CPANモジュールアップデートの部分ではいくつか問題が発生したものの、perlコアの変更による問題はほとんどなかったそうです。後方互換性を大切にしているperlの特徴がうかがえる実例で、バージョンアップに戸惑っている方も頑張ってやりましょうとエールを送っていました。バージョンアップ後はdefined-orなどの新機能は積極的に使っているが、Experimentalな機能は使わないようにしているとのことです。

また外部化したモジュールの紹介では、useしてるけど使ってないモジュールを検知できるTest::UselessModule、これ以上負債を増やさないためにどうするかというアプローチで作ったTest::CodingStyleなどを取り上げました。

今後もモジュールなどのオープン化を進めていきたいと締めくくりました。

画像

画像

でぃーきゅーねおさん「やさしいGit の内部構造」

分かりやすさを優先したため厳密性は犠牲にしていると断った上で、Gitの内部構造について解説した、でぃーきゅーねおさんによる発表です。

まずgitのコミットで記録されるのはその差分ではなくリポジトリ全体のスナップショットであることを紹介しました。このため仮に1行追加しただけのコミットでも、元のリポジトリサイズ分のdiskを追加で消費することになります。一方コミットのハッシュ値や親子関係の情報をもつコミットオブジェクトは差分情報を含まずスナップショットへのポインタを保持しているだけで非常に小さくなっています。タグやブランチはこのコミットオブジェクトへのポインタとなっています。Gitを理解する鍵はこのポインタによるオブジェクトグラフを理解することであると強調していました。

発表はQA形式をベースしたもので、会場に質問を投げかけながら非常に理解しやすいかたちで進みました。

画像

画像

soh335さん「perl な web application のためのテスト情報」

soh335さんから「テストを書こう!」というのではなく、⁠テストを書きやすい環境を用意する」という内容で発表がありました。

テストが書かれない原因として「なぜ書きにくい状態なのか?」にフォーカスして、これらに対する解を用意したところ、最終的に会社全体がテストを書く雰囲気になってきたそうです。具体的に挙げられた手法をいくつか取り上げます。

  1. t/Util.pm:テストの本質ではないところのコードを吸収してあげることでテストが楽になる。スキーマの変更も楽
  2. random_name:一意のキーを用意する手間を簡略化する
  3. Test::More::Subtest:連続したテストで前のテストによる影響を適切なスコープで閉じよう
  4. Time::MockTime:「ある期間だけ挙動を変えたい」のためにtimeを好きな時間に固定する
  5. Test::mysqld / Test::RedisServer:テスト用のモックDBを立ち上げる
  6. Test::Output:batchもテストを書くscript/moduleに分割して、moduleをテストする

テストは非エンジニアにも使ってもらっているそうです。例えば、⁠YAPC」を掲載時に「やーぴっく」と記載してしまった場合には、テストに書きJenkinsを回すことで2度そのような記載をすることがなくなるなどは素晴らしいことだと感じました。

最後のQAで、このような試みによって会社全体がテストを書く雰囲気が出てきたと答えていました。企業内でテストを普及させたい方は参考にできるかと思います。

画像

画像

Paul Fenwickさん「Build Your Own Exobrain」

ゲストスピーカーとしてオーストラリアから来日したPaul J Fenwickさんは⁠Build your own exobrain⁠と題して発表しました。

PaulさんはPerl Training Australiaの創始者であり、autodie.pmの作者、またDance Dance Immolation(周囲を炎に包まれながら行うDance Dance Revolutionのようなゲーム!)の覇者でもあります。

Paulさんはまず、アクティビティを登録するとその1年後のその日にそのアクティビティをメールで教えてくれるサービス(つまり、1年後に何をしていたかをメールで教えてくれるサービス)を紹介しました。そして、そのサービスが(残念なことに)終了してしまったことを契機に、そのサービスのWebAPIを使ったコマンドラインクライアントを作成し、それが非常に有益だったという経験を話しました。

Paulさんはその経験や、forsquareやFacebook等の様々なソーシャルアプリケーションの利用経験から、ExobrainとよばれるWebAPIをプラガブルに集約し、他のWebサービスなどからそこに飛んできたリクエストを、WebAPIを介して他のWebサービスにレスポンスとして投げるというソフトウェアを開発し、そのExobrainについて紹介しました。

Exobrainを利用することで、あるWebサービスに起こった変更を他のWebサービスに反映することができるようになり、WebサービスとWebサービスとを連携させることが可能となると説明していました。

また、Exobrainが内部的に利用しているZeroMQや、プロセスの立ち上げや終了に使用しているUbicと呼ばれる便利ツールについても取り上げ、観客の興味をひいていました。

画像

画像

toku_bassさん「ライブコーディングで学ぶWebアプリケーション」

普段Hachioji.pmに参加されているtoku_bassさんは、Webアプリケーション開発の初めの一歩をライブコーディングしながら説明しました。

Plackを用いたアプリケーションの起動から始まり、PATH_INFOを取得してアクセスされたURLによって返す結果を分岐できるようにしました。さらに発展して、ロジックをモジュールに切り出し、DBへの接続も実装しながら解説しました。最終的にはSkypeのログをDBから取得し、件数を返すアプリケーションが完成しました。結果をJSON形式に整形したところでライブコーディングを終了しました。

ライブコーディングではWAF(Web Application Framework)を使用しませんでしたが、実際に開発する際はWAFの使用を推奨するとのことです。実際にISUCON2で使われたコードを見ながら、ライブコーディングの内容との類似点やWAFを使っていることによる違いを説明しました。

画像

画像

Yuuki Tsubouchiさん「はてなのサーバ管理ツールの話」

インターンを経験し、現在はてなでアルバイトをされている@y_uuk1さんによる、サーバ監視・プロビジョニング・デプロイなどのツール間で管理しているホスト情報を一元化するためのツール「Macherel」についての発表でした。

これらを統合したツールとしてのZabbixやCrowbarはありますが、それぞれ好きなツールを使いたい。しかし、それぞれのツールでのホスト情報の利用方法が別々であるため結局これらの情報を個々で管理することになるという問題があります。これを解決するためにREST APIでホスト情報を管理するツールとしてMackerlを開発したそうです。

ホスト情報は物理・仮想のデータセンタ・ラックの情報だけではなくAWSのマシンも管理可能で、物理と仮想の親子関係、Service・Roleといった情報、どのマシンがVIPやDNSラウンドロビンにぶら下がっているかも管理できるそうです。Mackerelは管理している情報を一瞥するビューも備えており、そのビューは競馬新聞を参考に、情報密度を限りなく高めることを目指したと言います。

さらにこのツールはRRDtoolを利用することで、load averageやmemory、Disk容量などの基本的なサーバメトリクス、nginxのaccept数などの各種のメトリクス情報を可視化する機能も備えており、グラフで表示出力が可能だそうです。

将来的には、munin-nodeのように各種メトリクスを収集するデーモンの開発と現在は「画像で出力しているグラフをd3などを利用したリッチなグラフへの変更を考えている。そして最終的にはグラフ生成・予測機能を担っているRRDtoolからの脱却を目指している」との展望を述べて、まとめていました。

画像

画像

Lightning Talks Day 1

ライトニングトーク(LT)1日目です。櫛井さんがドラ娘を紹介しました。

画像

kazuhoさん「Using the Power to Prove⁠

proveコマンドの様々な使い方を紹介するという内容でした。並列実行のための-jオプションを始めとし、二回目移行の実行順を制御する--state、バイナリファイルを実行するための--exec ''、様々な拡張子をテストとして実行するための--extなど、マニアックなオプションが次々と紹介しました。

最後にはTAP形式で吐けるスクリプトであれば、モニタリングなどにも利用できると例をあげており、LTとは思えない非情に濃い内容でした。

画像

画像

yoshims85さん「ギークな異性を落とす魔法の言葉」

ギークな女性と付き合うためのやりとりを提案するLT。⁠200 OK」の返事をもらうための言葉をたくさん紹介していましたが、会場からの「でも彼女居ないんでしょう?」というツッコミには返す言葉もなかったようです。

画像

画像

sanematさん「Tachikomaで依存ライブラリの断続的バージョン上げ」

bundle updateによって新しいバージョンのライブラリをインストールし、自動でpull requestまで送るアプリの紹介でした。CPAN Testers ReportsやPrepanなど、Rubyで盗みたいPerlの機能を紹介するとともに、逆にci.hsbt.orgのような機能はPerlも真似するべきであるとRubyでの便利な機能を紹介していました。

画像

画像

Yappoさん「HTTP::Body::Builder」

Perlにおいてmultipart/form-dataのbodyを含むリクエストを作るインタフェースが現状は直感的ではなく、これをなんとかするようなモジュールを作ろうと呼びかける内容でした。実装者を求めているとのことですので、興味のある方はチャレンジしてみてはいかがでしょうか。

画像

画像

hirose31さん「How to inspect a RUNNING perl process」

動作中のPerlのプロセスの状況を調べるための方法を解説するLTでした。straceやgdb、gdbperlを使った手法の比較した上で、さらにperlの様々なバージョンと併用できるinspect-perl-procというものを作ったそうです。

画像

画像

yusukebeさん「YAPC::NA へ行ってきた」

去年のYAPCでベストスピーカー賞を獲得したyusukebeさんは、賞品として参加したYAPC::NAについて紹介しました。NAでは参加者同士の交流が日本よりも盛んであり、スピーカーと聴衆の掛け合いがあったり、毎晩交流会が開かれたりしているそうです。

画像

画像

egoproさん「んだっちゃだれ Sendai.pm」

本当は5分持ち時間があるLTですが、あえて2分でLTをされていました。宮城大学にて開催した特別講義の紹介とともに、来年はYAPCをTohokuで実現したいという熱い思いの篭ったものでした。著者も陰ながら東北での開催を祈っております。

画像

画像

comewalkさん「オープンソースプロダクトに貢献するということ」

patchを書く以外の方法でも、オープンソースに貢献することはできるという内容でした。プロダクトを使うこと、ブログに書くことなど、様々な貢献の仕方を紹介していました。comewalkさんが体験したという、海外と日本の時差を利用した貢献方法も興味深いものでした。

画像

画像

bayashiさん「細かすぎて伝わらないモジュール選手権」

この一年で26ものモジュールをアップしたbayashiさん。すべてのモジュールの紹介にチャレンジしましたが、さすがに途中で時間切れとなってしまいました。会場に対しても、もっと気軽にモジュールを公開するべき、と自信の経験を元に訴えました。

画像

画像

__gfx__さん「Power Assert on Perl」

LLVMのバイナリをJSに変換するためのemscriptenを使った話でした。これを使い、JS上でperlを動かすperl.jsというものを作ったそうです。システムコールなどはすべてemscriptenで上再実装されており、実現が不可能な機能は未実装のままとなっているなどまだ問題もあるようです。

画像

画像

mizuki_rさん「p5-SPICA」

WEB APIを統一したインタフェースで扱うためのp5-SPICAというモジュールの説明でした。DBのスキーマ定義をするのと似たような定義で、APIを定義することができるようです。最後に、Perlを書いてYAPCで話すことは楽しいと、聴衆にも何らかのプロダクトを開発することを促していました。

画像

画像

songmuさん「Riji」

英語の字幕に中国語で話すという一風変わったLTでした。Rijiはブログツールであり、RubyのJekyllと似たようなプロダクトだそうです。筆者は中国語に堪能ではないため理解はできませんでしたが、発音などを聞く限り流暢に話しているようには感じられました。

画像

画像

BoF(Birds of Feather)

今年初の試みとして、BoF(Birds of Feather)が催されました。

まずtokuhiromさんがMinillaの使い方について、ライブコーディングを交えて紹介していました。また、cpanfileの書き方についての質問に対して、とても丁寧な回答をしていました。

次に、tagomorisさんはデータの集計について話しました。Hadoopでのデータ集計フロントエンドであるShibを紹介し、その後、スキーマレスなデータ集計ツールnorikraをつかったデータ集計の実例を、ライブコーディングを交えて発表していました。

他にもSpring_MTさんによる初めてのPer読書会の紹介や、ytnobodyさんによるPerl Beginnersの紹介と小規模WAFのNephiaの紹介、まかまかさんによる同人活動の宣伝など、様々な方がさまざまな発表を行っていました。

懇親会

イベントホールにて懇親会が行われました。乾杯の挨拶は、懇親会のスポンサーであるDeNAの木村秀夫さんが行いました。

画像

画像

懇親会の途中に、木村さんによるセッションが行われました。DeNAに勤めているPerl MongersをAKB48の誰かに例えてみるなら、というお題で会場を盛り上げていました。

画像

画像

以上、1日目のレポートでした。

おすすめ記事

記事・ニュース一覧