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

1日目レポート[随時更新]

10月15日、16日、東京工業大学大岡山キャンパス (東京都目黒区) でYAPC::Asia 2010 Tokyoが開催されます。本ページでは、1日目のレポートを随時掲載していきます。

※今回のレポートは全セッションを回れておりません。ご了承ください。

画像

Daisuke Makiさん「Welcome Speech⁠

JPAの牧さんより、開催の挨拶が行われました。5周年となる今回のテーマは⁠Welcome Perl⁠であること、基調講演の発表者をそれぞれ"The Beginnig"、"Current Master"、"The Purple Master"と紹介しました。

また、今回のイベント運営にノンエンジニアの941さんが加わり、運営に尽力されたことが語られました。そのほか、今回のイベントではロケタッチと協力してYAPCのシールを制作したことが紹介されました。

最後に、スポンサーに対する謝辞が述べられました。

画像

Larry Wallさん「That Goes Without Saying (or Does It?)⁠

最初のトークは、今回のスペシャルゲストであり、Perlの生みの親であるLarry Wallさんによるキーノートでした。Laryy Wallさんは言語が思考に与える影響について話題として取り上げ、英語と日本語の違いとして「しなければなりません」は英語では「must」であるのに対し、⁠いけない」は英語では「must not」であることを取り上げ、日本語はmustよりmust notであることを話す方が簡単であり、同じことを話すにも利用する言語によって差異があると言語学者的な視点から指摘されていました。

画像

次にRMS(Root Mean Square)のロジックを各言語別に取り上げ、それぞれの言語に設計上で悪い部分があるのだと指摘をしていました。例えば、Perl5であればシジル($や@)が必要であったり、Adaではwithとuseをセットで使う必要があったり、Javaではメソッドの呼び出しにクラス名が必要であったり、ということを実際にコードを見ながら説明をしていました。また、随所にPerl6の記法を紹介しており、Perl6がこれらの問題点を克服しようとしているという印象を受けました。さらに、Perl6より短く書けるJ言語のコードを、コードが短過ぎてもよくない例として取り上げていました。

画像

Larry Wallさんのセッションでは日本語も随所に登場し、英語の部分もゆっくりと丁寧に英語が苦手な方へも伝わるように語りかけていました。Larry Wallさんが日本を大切に思っていることがうかがえるセッションでした。最後に、⁠YAPCを楽しんで下さい。楽しま"なければなりません"。」とジョークを交えて会場の参加者達にYAPCの楽しさを伝えていました。

画像

Kazutake Hiramatsuさん「Modern Perl Web Development on Amazon EC2⁠

Kazutake Hiramatsuさんによる、Amazon EC2上でPlack/PSGIアプリケーションを構築・運用するうえでのノウハウ紹介でした。

Plackを使ったPSGIなWebアプリの作り方

まずはPlack/PSGIの基本の解説です。PSGIとはWebサーバとアプリケーションとのやりとりを規定した仕様であり、PSGIアプリケーションとは単なるperlのコードリファレンスであること、PlackはPSGIアプリケーション開発をサポートしてくれる便利なツールキットである事の説明がありました。Plackの中ではplackupコマンドが特に重要で、-sオプションによるサーバ実装の変更、-Lオプションによるロードモジュールの変更方法が紹介されていました。プロダクションで使うサーバとしてはStarmanかStarletがおすすめとのことです。これらはもう十分に安定しているとおっしゃっていました。 またPSGIアプリケーションの書き方として、自分でフレームワークから作ってみることを提案されていました。Plackを使えば比較的簡単にフレームワークが作れるということで、その際におすすめのモジュールとしてPlack::Request、DBIx::Skinny、Router::Simple、JSON::XSをあげられていました。

画像

daemontoolsを使ったwebサーバの運用

続いてdaemontoolsを使ったサーバの運用について解説されました。server_starterをdaemtools経由で起動する形で運用されているそうです。ただ導入の際はsrc/error.hの修正が必要なこと、起動シェルはexecでプロセスを実行しなければいけないなどの注意点をあげられていました。

cpanmを使ったCPANモジュールのインストール

モジュールのインストールに関しては標準のcpanコマンドは使わずにcpanmコマンドを使うのがおすすめだそうです。-lオプションを指定することでインストール先の変更も簡単に行えるそうです。

Amazon EC2上でのWebアプリ構築、運用

Amazon EC2については、普通にアプリケーションを開発する上では大きな違いはないとのことです。ただし、インスタンスを停止するとデータが失われる点や、IPアドレスが変わるケースなど注意点もあるようです。そのあたりはEBSやS3、Elastic IPといった周辺サービスで補う必要があるそうです。それでもオートスケールするのはやはり便利であるとのことで、CPI使用率などのしきい値を設定しておくと、自動的にインスタンスの追加/削除を行ってくれるのは魅力的であるとのことでした。

画像

リクルート メディアテクノロジーラボさんによるセッション

このセッションでは、リクルート メディアテクノロジーラボさんが実際に現場でPerlをどのように使っているのかを紹介して下さいました。スピーカーはお二方で、Kensuke Kanekoさんとkawanetさんが順に登壇されました。

石橋利真さん「最近のPerlな物作り事例」

まず最初に登壇された石橋さんのトークは、現場の様子を事例として紹介して下さるもので、大変参考になりました。メディアテクノロジーラボさんでは自分たちだけで実現しているATNDのようなサービスと、リクルートさん本体と協業するsuumoのようなサービスを手がけているとのことで、今回のお話は主に後者についてでした。

メディアテクノロジーラボさんでは「開発手法までを含めてフレームワークである」という考えの元、個人には全員に同じ環境のVMを配布し、Subversionに成果物だけでなく設定ファイル、必要なライブラリ等をすべて登録して開発を進めているそうです。また、扱っている案件の規模について紹介をし、エンジニアとして非常にやりがいのある環境であることを強調されていました。

質疑応答も非常に活発で、このトークへの関心の高さを伺い知ることができました。

画像

画像

kawanetさん「Mashup Awards 6」

kawanetさんが紹介をしたのは、技術者の支援とWEB業界の発展を目的として毎年開催されているMashup Awards 6に関してです。ルールは単純で、62社が公開をしているAPIのうち、1つでも利用していれば応募可能であるとのことでした。WEBアプリである必要はなく、組み込み機器からこれらのAPIを叩く物であっても構わないそうです。

多数あるAPIのうち注目のAPIの紹介が行われ、音声合成を行うNetVOCALOID-flex APIや、普段は非公開であるNHKさんのAPIなど、Mashup Awards 6ならではのAPIが紹介されており、このコンテストに賛同するサービスの多さを印象づけられました。

Tokuhiro Matsunoさん 「モダンな Perl5 開発環境について - Modern Perl5 Development Environment - 2010年代を生きのびる Perl5 活用術」

tokuhiromさんによる開発環境構築ノウハウの紹介トークです。

まずはperlの自体のインストールの話から。OSに標準ではいっているperlは一般的な設定となっているためthreadが有効になっているなどWebアプリケーションとして使うには不要な設定が入っていたりします。perlではthreadをoffにするだけでインタプリタの実行速度が10〜15%程度高速化されるそうで、WEBアプリケーション環境として使う場合には1からインストールしなおすことを進められていました。続いてどのバージョンを使うかという話ではperl-5.12.2が一番とのことでした。安定志向の場合はperl-5.8.9も良いとのことですが、5.10以降はgiven/whenや、smart match, defined or (//), naped captureなど便利な機能が使えるため、新しいバージョンを勧められていました。とくにdefined or (//)は0や空文字列に起因するバグ削減に効果的なので、これだけでも5.10以降を使う動機になるのではとのことでした。

perl環境を構築するうえでの便利なツールとして、様々なバージョンのperlを簡単に切り替えられるperlbrewや、標準のcpanコマンドの軽量版であるcpanm、インストールされているモジュールの更新をチェックするcpan-outdated、使わなくなったモジュールをアンインストールするpm-uninstallなどのツールの紹介がありました。そうやって構築したperl環境を本番環境に配置するときは、単純にrsyncするのがおすすめとのことです。

CPANモジュールの選び方についても紹介されました。CPANには現在8万以上のモジュールが登録されており、初心者がその中から必要なものを選ぶのはとても困難です。そんな中よいモジュールを選ぶにはやはり人に教えてもらうのが一番で、気楽にIRCチャンネルの#perl-casual@irc.freenode.orgやTwitterでperlについて質問してみるのがいいのではとのことでした。どうしても自分で選ばないといけないときの調べ方として、CPANソムリエになる方法というtokuhiromさんのエントリも紹介されました。

質疑応答では、リリース後更新されたCPANモジュールはどうアップデートするかという質問がありましたが、tokuhiromさんは開発中はどんどん最新化しているが、リリース後は気になったものだけをチェックして手動でアップデートされているそうです。

本トークは今回から導入されたセッション投票システムにおいて、Best talk賞を受賞されました。

画像

画像

Kensuke Kanekoさん「30days Albumの裏側 後日談」

昨日の前夜祭にも登場した、刺身さんによるトークです。paperboy&co.さんが開発している30days Albumという写真共有のサービスを運用するにあたり、発生した様々な問題について解説をして下さいました。30days AlbumではPerlbalとMogileFSを利用しており、主にこの二つのプロダクトにまつわる具体的な事例が紹介されました。

最初に紹介されたのは、MogileFSの稼働している実サーバの1つでディスク障害が起きたときの事例。このような障害が発生したときは、mogadmコマンドにてデバイスを一度「dead」の状態にし、その後データ復元後に「alive」へ戻すことで、サービス停止なしで障害対応が可能だったそうです。また、MogileFSのリバランスの動作も解説され、ネットワーク負荷やMySQLの負荷が上がるため、Muninなどの監視ツールで監視をしながら実行した方がよいと指摘されていました。MySQLの負荷については、MogileFSの最新版を使うことで緩和されるとのことです。

Perlbalに関しては、FLVの疑似ストリーミングへの対応とRangeヘッダへの対応について説明がありました。PerlbalはFLVの疑似ストリーミングを行うためのプラグインを持っていないため、paperboy&co.さんではこれを自作されているそうです。また、Rangeヘッダについてはバックエンドのストレージサーバの挙動に問題があったため、Rangeヘッダを含む場合に適切なContent-Lengthを表示できるように調整をしたとのことです。Rangeヘッダの仕様には複雑な機能も含まれていますが、その部分に関しては対応をしなくても実用上問題はないそうです。

画像

画像

Hiroki DaichiさんInside Mixi - ソーシャルネットワークを支える技術

Hiroki Daichiさんにより、mixiシステムの内部について「二つのスケーラビリティ(Performance, Development)」というテーマで発表されました。

Performance : アクセス数の増加や変動に耐える

mixiではmemcahcedをキャッシュ機構として利用しているそうです。memcachedは揮発性KVS、汎用キャッシュ機構、LRUといった特徴をもったプロダクトです。 キャッシュをする上で考慮する点として、キャッシュ方式とキャッシュ対象レイヤについて解説されました。キャッシュの方式は大きく分けてリードスルー方式とライトスルー方式があります。リードスルー方式では、データソースから読み込み時にキャッシュに書き込む方式で、実装が簡単という特徴があります。Perlで実装する場合は、Moose::RoleやClass::Method::Modifierを使えば、データ取得ロジックに手を加えずにキャッシュ機構が実現できるそうです。ライトスルー方式はデータソースへの書き込み時にキャッシュに保存する方法です。ただしデータソースへの保存粒度とキャッシュの粒度を合わせる必要があるなど実装上すこしハードルが上がりがちのようです。またmemcachedの場合はキャッシュが揮発するので、リードスルー方式と併用する必要があると述べられていました。続いてキャッシュ対象レイヤの話では、キャッシュの粒度についての説明がありました。データベースレコードの1カラムデータをキャッシュするレベルから、レコード単位、ドメイン単位、サービス単位など、様々な粒度でのキャッシュを使い分けているそうです。

Development : 機能追加や他人数開発に耐える

開発面でのスケーラビリティについては、MVCの重要性について述べられていました。特に様々なデバイスでサービスを展開する場合、コントローラが肥大化した作りだとうまくいかないケースが多く、MVCの真価が問われるとのことでした。また凝集度を高く結合度を低く保つことも重要です。ライブラリは 基礎ライブラリ、フレームワーク、サービス、アプリケーションというレイヤに分割し、レイヤごとの依存関係の制限や、品質基準などを設定されているということでした。またModelのCRUD操作にフックを定義されていて、それによりモデルの深い事情をしらなくても連携するサービスが作れるようになっているそうです。イイネ機能などはその仕組みにより実装されているとのことでした。

まとめ

最後にまとめとして、パフォーマンス面でも開発面でもスケーラビリティを保つためには負荷の分散構成と責務の分散構成が必要だが、それらは構成的には共通点が多いということをおっしゃっていました。

画像

画像

Tatsuro Hisamoriさん「ソーシャルアプリ向け システム監視運用の勘所」

このセッションは、Social Applicationの開発者を対象としたレスポンス時間に関する不具合を調査する方法についてのトークでした。DeNAのHisamoriさんより、実際に問い合わせが発生した事例に基づいて現象の切り分けていくHow Toが紹介されました。

Social Applicationでは、コンテンツ提供サーバがレスポンスをする際に、タイムアウトが規定されています。今回の事例では、規定の時間内にコンテンツを返しているのにタイムアウトになってしまう、という問い合わせが発生したというものでした。結論としては、GadgetServerの計測する時間とプロバイダー側が計測していた時間にブレがあるのが原因でした。前者は問い合わせを行うPerlコード内でalert関数での割り込みが発生する時間であったのに対し、後者はリクエストラインを受け取ってからの応答時間であったというものです。この調査に利用した道具として、tcpdumpとwiresharkが紹介されていました。

HisamoriさんはSocial Application開発者に意識して欲しいものとして、⁠コンテンツを返すのにかかる時間」⁠DB周りの処理時間」⁠ネットワークのレイテンシの把握」の3つを上げていました。DBに関してはDBIx::ProfileManagerを利用したりmaatkitを利用した調査方法が紹介されました。レイテンシに関しては、EC2やGAEでは100msから200msの時間がかかることもあり、ネットワークだけで大きく不利になることもありうると指摘されていました。

画像

画像

Lyo Katoさん「DataPortability and SocialWeb Protocols」

まずは最近のソーシャルウェブ界隈の様々なプロトコルが紹介された後、OpenIDとOAuthによってサービスはIDの提供者(IdP:Identity Provider)とサービスの提供者(SP:Service Provider)をわけて考えることができるようになってきたと述べられました。それまでは各サービスごとにIdPとしての機能とSPとしての機能を実装する必要あったが、それらを他のサービスから借りてくるというエコシステムが形成されてきています。OpenIDとOAuthの相違点については、一般的にOpenIDはIdPの部分を移譲するための仕組みであり、OAuthはSPの部分を移譲するための仕組みとなっていますが、実際にはOpenIDでも拡張機能でユーザのプロファイル機能が取得可能であったり、OAuthでも認証をIdPに移譲していると言えなくもないなど、似通っている部分も多いとのことでした。

続いてOAuth2.0の紹介がありました。sslが必須になり、Request Tokenも必要なくなるそうです。また署名も必要なくなるかもしれないということで、そうなればクライアント側はOAuth用のライブラリがなくても通常のWebサービスクライアントライブラリだけで十分になるかもしれないと仰っていました。OAuth2.0の実装としてlyokatoさんが作成されているモジュールのOAuth::Lite2も紹介されていました。現在はOAuth2.0(draft10)に対応しているそうです。Server側はPlackに対応していて、OAtuth::Lite2::Server::Handlerを継承して実装します。ただしこの実装にはOAuthプロトコルを熟知していないと難しいそうです。

iPhone, AndroidなどでOAuthを利用するためのtipsなどが紹介されました。例えばAndroidではAccount ManagerというOSがアカウント情報を統合管理する仕組みを持っているそうです。その他xAuthを使うときなどはパスワード情報の保存を平文でおこなってしまうと漏洩リスクが高いので、扱いに注意を促されていました。

最後にOAuthはそろそろ必須技術になってきているとして締めくくられました。

画像

画像

malaさん「Studying HTTP with Perl」

本セッションは、malaさんによるHTTPプロトコルの処理全般に関するトークでした。まず、PerlのHTTPクライアントライブラリについて、同期と非同期のものをそれぞれ紹介されていました。PerlのHTTP接続といえばLWPがデファクトスタンダードではありますが、さらに高速な実装としてWWW::Curlをあげていました。

非同期なものに関してはAnyEvent::HTTPが有名ですが、malaさんが作られているもっと高速なAnyEvent::Curlが紹介されました。今までの通説ですと、LLのボトルネックはI/Oであり、コードの実行速度はさほど問題にはならないというのが通常の考え方でした。しかし、通信速度が0と仮定したときの速度(性能限界)を考えた時、LWPではCPU 1つあたり秒間200回しか実行できないことがわかり、これでは少し問題がありそうです。そこでWWW::Curlを利用することで、性能限界を秒間2500回まで向上させることができるそうです。もちろん、すべての場合にWWW::Curlを使うべきではなく、非同期アクセスが必要で、性能限界が間にあわないときに使用すべきだということです。

その後、今度はサーバの実装としてpreforkとイベント駆動との二つの方法の比較がありました。preforkのサーバは簡単に書くことができるのが利点ですが、DoS攻撃に弱いという問題点を指摘されていました。1リクエスト辺りの実行時間がはっきりとせず、必要なリクエスト数も不明な場合に、起動されるプロセスが想定よりも多くなって枯渇してしまう可能性があるためです。

話の最後には、テストコードにGoogleなどの外部URLを参照する場合の問題点を取り上げ、Test::TCPなどのモジュールを使ってローカルサーバを立ち上げ、簡単なPSGIアプリケーションを作ることでWEBクライアントのテストはローカル環境だけで可能であることを解説していました。

画像

画像

Jiro Nishiguchiさん「Write Good Parser in Perl」

Jiro NishiguchiさんによるPerlでのパーサモジュールの紹介と、その実装方法についての解説でした。

まずはパーサとはなにかというところから始まりました。パーサとはなんらかの意味をもったテキストを、その後の処理に適した形にするためのものです。 そんなパーサのPerlでの実装例として、HTML::Parser、XML::LibXML、JSON, JSON::XS、HTTP::Parser::XS、Template-Toolkitといった定番モジュールの紹介がありました。またCache::Memcachedモジュールも紹介されていて、こちらはパーサモジュールではないが、内部でmemcachedプロトコルを解析するためにパース処理を行っており、その点でパーサ実装例として挙げられていました。

これらのモジュールの実装はXSを使ったものが多いようです。特に1文字ずつ処理していくようなタイプの処理はPerlで書くよりもCで書いたほうが高速に動作することが多いのがその理由のようです。とはいえPerlの正規表現でもかなり高速に動作するので、書き捨てのパーサなどを作る場合には正規表現は有効な手段として紹介されていました。また正規表現を最適化してくれるRegexp::Assembleについての紹介もありました。

続いて実装パートではRagelの紹介がありました。Ragelとは正規表現に似た文法を用いて比較的わかりやすく宣言的に書けるのが特徴のパーサジェネレータです。ただし、perlはサポートしていないため、利用するにはCで書いてXSで呼び出すなどひと工夫する必要があるそうです。XSといってもデータ構造を作って返すだけで複雑な処理は必要ないので恐れることはないとのことでした。実際にログ解析プログラムを書いたところ、正規表現と比べて5倍程度高速な物ができたそうです。ログ解析のようにフォーマットがあまり変わらなそうなところについては、パーサジェネレータとXSで高速化するのもお勧めとのことでした。

画像

画像

Seiji Haradaさん「mixi チェックインの裏側」

mixiチェックインの裏側に関するトークです。スポット絞り込み検索機能を実現するための方法と、高速化するために行っている工夫について発表されました。

mixiチェックインでは現在の位置情報からスポットを検索する際に、geohashという手法を用いているそうです。geohashとは経度緯度の範囲を文字列で表現したもので、先頭からたどっていくと範囲が絞り込めるように表現されています。その性質により一定長さの文字列で前方一致検索をすることにより、高速に現在位置周辺の検索が実現できるそうです。実際のサービスではGeo::Hash::XSを使用されていて、とても高速に動作するそうです。ベンチマークをとったところ、Geo::Hashと比較して140〜200倍程度高速だったとのことです。

また高速化の手法としてmysqlまわりにも触れられていました。スポットの情報はそれほど頻繁には更新されないので、6文字のgeohashをキーにしてmemcachedにキャッシュしているそうです。ただし全ての地域についてキャッシュしてしまうとキャッシュ容量的に無駄が多くなってしまうため、特にスポットの多い関東、関西地区に限定している人のことでした。また検索範囲に関しては半径250mを規準にしているそうですが、これは厳密に指針があるわけではなく、実際に外にでて実機で検証したところGPSの最大誤差が250m程度だったので、それを規準にしたそうです。デバイス周りの開発ではコードの検証だけではなく、現実の世界での検証が重要だということを認識させられる一例だと思いました。

最後に位置情報サービスは難しくないので楽しみましょうと締めくくられていました。

画像

画像

伊藤直也さん「Perl/PHPと大規模Web開発」

最近PerlからPHPへシフトをしたことでPerlプログラマからもPHPプログラマからも注目されている伊藤直也さんのセッションは、大規模Web開発をテーマにした内容でした。

まずLLのWeb Application Frameworkについて最近の流行として、どの言語でも「作り込まれたWAF」⁠シンプルなWAF」⁠実行環境」の3要素が存在していることを取り上げました。Rubyにおいてこの三者はそれぞれ、Rails、Sinatra、Rackとなります。Perlですと、Catalyst、Mojolicious::Lite、Plack/PSGIが該当します。PHPにおいては、最初の二者はCakePHPとLimonadeを挙げることができますが、実行環境に関してはまだデファクトスタンダードはないそうです。これは、ニーズが少ないためではないかと伊藤さんは分析していました。

また、大規模Web開発について「収益に数年かかかる」とし、数人で作った昔のアーキテクチャを十数人規模で使い続けるということが必ず発生すると指摘をしました。ただ、Webシステムの開発についていえば、プロトコルは十分に枯れているHTTPであり、LLは後方互換を重視していることが多いため、一般的にいう「レガシー」とはちょっと事情が違うとしました。アーキテクチャの刷新方法としては、新案件に新しいアーキテクチャを導入したり、継続的な改善で新しいアーキテクチャを目指したり、システムをWEB APIで分断してから新アーキテクチャ化を進める方法等を紹介していました。

最後に、PHPへの移行について、⁠言語よりも基幹技術が重要であり、移行はそんなに難しくない」と移行の簡単さをアピールしつつも、⁠ツールにはPerlを使っている」とPerlも日常的に利用していることにも言及していました。

画像

画像

keroyonnさん「非同期タスクの通知処理 with Tatsumaki」

Hokkaido.pmのkeroyonnさんによる非同期タスクを通知する手法に関しての発表となりました。

まずは簡単な通知の方法として、CGIベースによるブロッキング&ストリーミングの解説がありました。perlだと$|=1を設定して少しづつprint文などでコンテンツを出力していく手法です。この方法は手軽なのですがブラウザがずっと読み込み中になってしまいます。

続いてクライアント側を非同期化するためにmultipart/mixedを使った通知方法の紹介がありました。ブラウザ側ではXMLHttpRequestで接続を維持したまま、CGI側ではboundaryをつけつつコンテンツを出力します。クライアント側の実装ではDUI.jsで処理すると簡単なようです。ここまでで単一の処理を非同期化する上では十分ですが、サーバ側がブロッキングする実装のままではC10K問題の影響を大きく受けてしまいます。それを回避する方法としてPSGI/Plackストリーミングの紹介がありました。サーバ側をノンブロッキングにすることで1プロセスで多数の処理をこなせるようになり、C10K問題を回避できます。

しかしノンブロッキングなサーバには、同期IOを使えないため処理が複雑になる、CPUを占有するような処理も好ましくないといった欠点があります。それらを解決する手段としてTatsumaki, Gearman, WebService::Asyncの3モジュールが紹介されました。まずTatsumakiを使うと、ノンブロッキングなストリーミング処理を簡潔に記述することができます。続いてGearmanはノンブロッキングなサーバが苦手とするCPU負荷が高い処理を補うジョブキューサーバで、ストリーミングしているプロセスから処理を移譲するために使います。ジョブを登録するときにブロックしては意味が無いので、クライアントから呼び出すときはAnyEvent::Gearman::Clientを使うとよいそうです。最後にkeroyonnさんが作成されているWebService::Asyncが紹介されました。TatsumakiにはHTTPClientというモジュールも付いていますが、結果のパースなどは自分で実装しないといけません。WebService::Asyncを使うと非同期でWebサービスを呼び出して結果のパースまでをシンプルに行えるとのことです。

セッション中は「笑いあり、涙あり、萌えあり、ポロりありの20分間」という副題の通り、ジョークで会場の笑いを誘いつつのなごやかな雰囲気でした。

画像

画像

吉見 圭司(walf443)さん「Webサービスのページング処理について」

吉見 圭司(walf443)さんによるページング処理のトークです。Webサービスでよく行われるページング処理について、いろいろな手法の紹介トークとなりました。

まずは一般的な方法の説明で、mysqldでのlimit offsetを使って1ページ分の結果を取得する処理と、limit句をつけないcount(*)文を発行してトータルの件数を取得する処理の二つを行ってページングを実現する手法を紹介されました。この手法は大抵の場合うまくいきますが、count処理が重いなど非効率な面もあります。

続いてmysqlの機能であるCALC_FOUND_ROWSを使う方法が紹介されました。これを使うと結果取得SQLの直後にselect FoundRows()を実行することでトータル件数を取得することができます。count処理を別に行うより効率的ですが、DBに依存してしまう欠点があります。次のページがあるかどうかだけが分かればいいというケースでは、1件余分に取得して次ページがあるかどうかを判定するという方法も紹介されました。

吉見さんはこれらのページングロジックを必要に応じて切り替えられるようにDBIx::Skinny::Pagerというモジュールを開発されているそうです。

質疑応答では、ページング処理中にデータが増えた場合表示位置がずれる可能性があるがどう対処するかという質問がありました。それに対してページング処理をタイムスタンプなどを規準に行えばよいのではないかと回答されていました。

画像

画像

Lightning Talks

初日のLTを紹介します。

西林拓志さん「学生PHPプログラマーがPerlな会社に就職した!」

Perlを使ってみての感想のLTでした。実際に使ってみるまではいい印象を抱いていなかったそうですが、実際に使ってみると柔軟で楽しい言語だったということです。今では自作のモジュールも公開しているそうです。

画像

Fumiko Kuranoさん「Inside webcast of Gozan-no-Okuribi in Kyoto⁠

京都送り火の中継の舞台裏について、解説されていました。システム全体のうち中継システムがPerlで書かれており、PerlMagickや、Net::SFTP::Foreinなどのモジュールが利用されているのが印象的でした。中継後もTwitterの分析等を行うそうです。

画像

Yappoさん「Happy AnySan Hacking⁠

今年はtsudaさんのコスプレで現れたYappoさん。AnySanというメッセージングフレームワークを紹介して下さいました。実装を意識することなくメッセージングを実現できるのが特徴で、dan_the_botというTwitterとIRCの双方で小飼弾さんの名言を呟くbotのデモを実演していました。

画像

Naoki Tomitaさん「OFPM⁠

朝から会場を沸かせていた忍者の正体は、伊賀流手裏剣打選手権大会に参加して忍者ファンになったTomitaさんでした。Tomitaさんが2008年まで運営していた「今日のCPANモジュール」が書籍化されるそうで、そのための統計情報を集めた http://ofpm.koneta.org/ を立ち上げたというお話でした。

画像

Kamipoさん「MySQLのPluginいろいろ⁠

MySQLのUDF、STORAGE_ENGINE、FTPARSER、DAEMON、INFORMATIONと5種類あるプラグインの、それぞれのオススメを紹介するというLTでした。mycachedやSpiderなどといったようなプラグインが挙げられ、最終的にはKamipoさんが自作したプラグインのデモを行う予定でしたが、時間切れとなりました。

画像

issmさん「⁠⁠名古屋でPerlをゆるく語る会」をはじめました⁠

ロールプレイングゲーム風の画面でプレゼンしたissmさんは、Nagoya.pmの前身(となるかもしれない)ゆるく語る会について紹介をしていました。パスタを食べたりポケモンの話をしたりと、文字通りゆるく集まるのが特徴です。近場の方はぜひ参加されてみてはいかがでしょうか。

画像

吉川 毅さん「RubyプログラマがPHP大規模開発の会社に入って⁠

CTOの代わりに登壇することになったと語る吉川さん。図説で非常にわかりやすく壇上での心境を説明して下さいました。SinatraやPSGIにインスパイアを受けてPHPでViciousとPhackと名付けたモジュールを作ったとのことですが、残念ながら途中で時間切れとなりました。

画像

bayashiさん「YAPC::EU 2010 Reports⁠

ヨーロッパ最大のYAPCに参加されたbayashiさん。質疑応答の活発さと、食べ物の充実さが印象的だったとお話されていました。その中で「Larryさん一家のプレゼンがYouTubeで公開されているが、必聴」だとおっしゃっていましたので、筆者もぜひ見てみたいと思います。

画像

峰松 浩樹さん「基幹システムがperlでどうしてこうなった⁠

汎用機を2013年までになくすという無謀な計画を実施することになった峰松さん。JCLはPerlで自動変換し、MySQLへの接続にもPerlを使うことにしたそうです。最終的にはApache>mod_php>OpenOBOL>perl>MySQLと跨ぐことになったシステムに、会場も拍手喝采の盛り上がりでした。

画像

zentoooさん「Test::QUnit - QUnit test via prove⁠

ブラウザでのテストは面倒くさいけど、CUIでのテストではブラウザの非互換な部分はテストできないと語るzentooさん。最終的に辿り着いたのは、CUIからブラウザでテストを叩くということでした。そのためのTest::QUnitというモジュールを自作されたそうです。

画像

Karen Pauleyさん「10 Things to Do with a conference T-shirt⁠

YAPCに20回以上出ていると語るPauleyさん。出席するたびに手に入るTシャツは女性のPauleyさんには巨大過ぎて着こなせず、これを有効活用するためのノウハウを紹介しておられました。はさみでセクシーな衣装に仕立て直したり編み直してタオルに変えたりといった次々と紹介される本格的な手法に、会場からは盛大な拍手が巻き起こっていました。

画像

Yoshinori TAKESAKOさん「all your base16 are belong to us.⁠

一日目の大トリを飾ったのはTAKESAKOさん。PythonではUnicodeの「emoji」も含めて1000文字以上がソースコードに使えるのを多過ぎると一蹴。ASCII記号10文字だけを使った目視のできるバイナリプログラムの手法を紹介し、トリに相応しいますます磨きのかかった"TAKESAKOワールド"を展開していました。

画像

懇親会

1日目のプログラム終了後、懇親会が催されました。皆さん、歓談を楽しまれていたようです。

画像

画像

画像

※ブラッシュアップする前にあったメモ書きの一部は、a geek born in Tomakomaiへ移しました。

おすすめ記事

記事・ニュース一覧