@kyanny's blog

My thoughts, my life. Views/opinions are my own.

YAPC::Asia Tokyo 2009 に行ってきた (9/10, day1)

Perl

http://conferences.yapcasia.org/ya2009/ に行ってきた。今回は自分のなかで「初心に帰る」をテーマに臨んだので、紙のノートにボールペンでメモをとった。以下、メモした内容のまとめ（まとまってないけど）と、それを踏まえて感想というかコメントを。かなり長いです。

Welcome / Daisuke Maki (lestrrat)

JPA 代表理事の牧さんによる、オープニング。

朝少し寝坊して、駅からダッシュしてなんとか九時ぎりぎりに滑り込んだ・・・と思ったら少し開始が遅れていて、息を整えてから開会の挨拶？を聞けた。「三つのC」で「王様のレストラン」を思い出した。

基調講演 / Richard Dice

TPF の代表を務めていた、リチャード・ダイス氏による基調講演。

  • FLOSS 進化的モデル
  • 安定した状態になる (**** is Dead)
  • 誰も必要に迫られない -> いつかやる -> では、ダメ。競合の技術に先を越されてしまう。「いつか」がきたときには競合の技術がネットワーク効果でシェアをとっている。
  • Perl と TPF の関係は？他の OSS の場合とどう違うのか？
    • 例: Mozilla と Netscape, Google -> 大企業と提携する
    • 例: Ecripse -> 企業に議決権つきの会員権を売る (公益団体ではないから、できる)
  • TPF は公益団体なのでそういうことはできない。ではどうする？
  • IBM, Intel -> 時代はマルチコア -> 並列プログラミングの必要性 -> でも多くのプログラマはそういうのあんまり・・・ -> Perl6 はそういうの得意だよ！ -> 企業に、 Perl6 とともにマルチコアを広めよう！と働きかける
  • TPF の目指すところ、議論中
    • 最小限モデル -> いまと同じ、要請があったときだけコミュニティに働きかける
    • 意欲的モデル -> もっと積極的にコミュニティに働きかけてリーダーシップをとる
  • Hague 基金 Perl6 のよりいっそうの開発のために用いられている
  • Perl のベンダーサポート
  • 新しいプラットフォームがでるとすぐに「糊(grue)」を誰かが書く -> タイムラグができてしまう、後手ではダメなことも -> 先手をうっていきたい
  • Java は企業主導でのエンタープライズとコミュニティが共存している、お互いに違った領域をカバーする
  • Perl は？コミュニティは素晴らしい、でもエンタープライズ分野では影が薄い・・・
  • そこに食い込んでいく戦略、 Perl の生態系、 TPF や JPA はその役目を担うことができる

基調講演は、 JPA 主催の YAPC にふさわしいテーマだった。ファンユースもエンタープライズも含めたよりいっそうの普及を目指すために、コミュニティと企業がてをとりあって動いていく必要があり、 TPF や JPA はその間を取り持つ存在となれる。 JPA の発足はまったく正しく、意義のあることなんだなと再確認できるセッションだった。

Web エンジニアのための mixi アプリ開発ガイド / Hiroyuki Oyama

株式会社ミクシィによる、コーポレートトラック。小山さんのセッションと書いてあるけど、実際には田中さん？が発表されていた。

  • mixi アプリ、 mixi プラットフォーム -> 開発者をとりこみたい?
  • OpenSocial + 独自API (どこのSNSプレイヤーも独自APIをつくってる)
  • mixiアプリモバイルでは RESTful のほうの仕様を採用している
  • Apache Shindig OpenSocial のいろんなのの実装
  • mixi では API のほとんどを Perl で実装しなおしている (Shindig は Java)
  • Perl で培ってきたノウハウをそのまま使える
  • リリース -> ダウンw
  • Shindig のバグで opened sokect max に達して HTTP 504 (珍しい) とか -> revison あげたらいいんじゃね？

ここで中座。。

別会場のスタート時間になったので途中ででたが、移動しおわったら開始を遅らせるアナウンスが。メイン会場のほうでもアナウンスがあると、移動もスムーズだしスポンサーのトラックの途中で人が抜けることも少なくなくて、よかったのでは。アナウンスするといっても、なかなか方法やタイミングが難しいと思うけど・・・。

mixi アプリの概要についてのセッションだった。 mixi アプリに限らず、あの手のものにはあまり興味を持っていなかったけど、ちょっと試してみようかな、と興味を抱ける内容だった。やっぱり、大ざっぱでも構成とか、どういう実装がされているのかとか、そういうのがわかると関心が持てるなと思った。特に、 API の大部分を自社で実装したという話は、独自拡張のためにやらざるをえなかったという要件も当然あったのだろうけど、 Perl で日本最大規模のサービスを構築し運用してきたノウハウを活かすという戦略も正しいと感じた。

Plack, PSGI / tokuhirom, miyagawa

miyagawa さんと tokuhirom さんによる、 Plack/PSGI のセッション。前日くらいにブログでアナウンスがあって、急遽内容が変わった。

  • PSGI ... 仕様
  • Plack ... 実装
  • HE は仕様と実装と API が混ざっていた
  • 分離したほうがキレイで使いやすいね、ということで Plack/PSGI がうまれた
  • Request ... HashRef
  • Response ... ArrayRef (Set-Cookie ヘッダを複数吐きたい、などの要請のため)
    • WAF を作る人だけが考えれば良い。 WAF を利用する人は意識する必要がない。
  • HE は Interface::PSGI を残してあとは消える？ by miyagawa
  • Plack Adaptor WAF 間の違いを吸収してくれる
  • Catalyst のテスト (live test) とかも Plack/PSGI の実装上で動く
  • もちろん Catalyst そのものも Plack/PSGI 上で動く
  • 既存の実装、既存のテストをそのまま利用できる
    • 例: mod_perl はいろいろできすぎて ISP が入れたくない、ときに mod_psgi とかが実装されるとPSGI に沿って実装してる WAF はすべて無修正で mod_psgi 上でも動く、とかメリットがある
  • パフォーマンス？
  • Plack はリファレンス実装みたいなもの？
  • もっと効率の良いチューンドな実装がでてくればそちらを選べば良い (mod_psgi とか)
  • Perl6 の Core に入れてもらいたい
  • CGI.pm は PSGI サポートが入る予定なので Perl5 でもいずれ Core に入る

以下、 miyagawa 語録

  • 「オレ vi だと書けないな」 tokuhirom のかわりにコーディングしようとして
  • 「2,3 行ってのはちょっとないけど、まぁ、10行くらい」 - 既存の WAF も少しの変更で動くよと話していて
  • 「ちょっと聞こえないワ」 質問をききながら

Python の WSGI や Ruby の Rack のように、 Perl の WAF にもリクエストとレスポンスを統一的に扱うための仕様をつくろう！そして仕様に沿った実装も用意しよう！というところからはじまった、 Plack と PSGI についてのセッション。これはかなり良かった。正直、俺 WAF なんて作らないしー、と思っていたのだけど、作らなくても最新の動向がどうなっているのかを知ることができて、とても中身の濃いセッションだった。

シックス・アパート・フレームワーク / Takatsugu Shigeta

SAKK の重田さんによるコーポレートトラック。途中から。。

  • 会社紹介的な (SA と SAKK)
  • MT フレームワーク MT, TypePad JP
  • MT::Entry とか、 D::OD ベース、ほとんど D::OD ですねーらしい
 D::OD::BaseObject
         |
     MT::Object
   /     |
MT::Blog MT::Entry ...
  • TypePad::Object, これも D::OD ベース
  • TypePad と MT はアプリケーションとしては別モノ（コードベースが）だが、フレームワークの元は

同じ

  • Vox, ArcheType (new codebase based Catalyst), 去年の YAPC でネーミングライツ買ってた
 MT    TypePad   Vox
   \      |      /
      ArcheType
          |
       Catalyst
  • FogBugz バグトラッキング、所要時間なども記録されるので仕事どんくらいしたかとかもこれでやってる
  • svn revision 11万 (12万), コミット多いらしい　(やっぱ大きくなるんだ)
  • 質問してみた「CPAN モジュールのバージョンアップとかにどうやって追随してるのか」
    • 全部 rpm 化して rpm repos に入れてからデプロイしてる、rpm にする前にコードレビューがある

sixapart の代表的なプロダクトである MovableType, TypePad, Vox を支えるフレームワークと、開発体制についての紹介。今回の YAPC では、自分も Perl を使ったサービスを運営する会社に勤めていることもあり、他社がどういう風にやっているのかは常々気になっていたので、コーポレートトラックをハッカートラックなどよりも重視して参加した（ハッカートラックは難しくてついていけないからだろ？とか言わないこと）が、その中でもとても参考になったセッションの一つだった。 CPAN モジュールのバージョン管理、整合性のとり方については、各社工夫して（おそらく苦労もして）いるのだなあと思った。

ランチタイム

  • サンドイッチ無料、スタッフボランティアおつかれさまです、メモを少し清書、 Acme大全2009買えたよ！素晴らしきPerlモジュールの世界が自分のPerlモジュールとのファーストコンタクトで大好きですと話した

夏コミで買えなかった「Acme大全2009」を、念願の「Acme大全2009」を、ついに手に入れることができた。まかまかさんありがとうございました！「素晴らしき Perl モジュールの世界」は、自分が Perl のモジュールというものを知ったばかりの頃に検索して見つけたページで、 Acme::Damn の解説が面白くて面白くて、「Perl のモジュールって、難しそうではあるけど、でも面白そうだな」と、挫折せずに使い方を勉強し続けられた原動力だった。そのことで個人的に感謝していたので、そのことをお伝えできてよかった。ちなみに「Acme大全2009」は、帰りの電車などで少しずつ読んでいるが、本当に面白い内容で、偉業とよぶにふさわしい仕事だと思う。

API Design / Shawn Moore (Sartak)

外国人トラック（勝手にそう分類してる）一発目。ミーハーなので著名なハッカーのセッションは「一目見てみたい」ので参加した。

  • Sharn Moore, sartak, Best Practical (Hiveminder? Jesse Vincent) ほっぺが赤くてアンパンマンみたいな顔w
  • Cool API
  • とにかくたくさんテストを書け！
  • そうすれば使いやすい API かどうかわかる
  • Moose, MOP の話、 has とか、関数的に書くとたいへんみづらい、
  • Path::Dispatcher OO sugar とかいってた
  • HE, very cool
  • Dist::Zilla プラグインの機構とか？拡張性が高くて柔軟だってこと
  • RT の話、上と同じ
  • 拡張性は大切、公開できないコードもある (Secret)
  • 拡張できれば、そこだけ分離してプラグインとして書ける(他は公開できる)
  • IM::Engine, instant messanger (Jabber, IRC, etc.)
  • on Moose world, Roke == Trait
  • 会場からいろいろつっこみがあってなかなかエキサイティングなセッション、でも英語なので内容よくわからず
  • 結論:: テスト書けよ！!

最近のイケてるモジュールをいくつかとりあげて、ソフトウェア設計の点でどこがどのように優れているのかを紹介したセッション。特に重要だと感じたのは、「拡張性は大切、公開できないコードもある (Secret)」という部分。自分も仕事でコードを書いていて、ビジネスロジックというか「外部に出せない部分」をうまく切り出せていなくてベッタリ書いてしまったせいで、変更もしづらいし、あとで使い回せそうな部分だけを公開したりすることができなくて、もどかしい思いをしたことがあるので、身にしみた。テストもっと書かないとな、と思った。

prettyfs 分散ファイルストレージ / Kan Fushihara

モバイルファクトリーのふしはらかんさんによるセッション。お題はファイルストレージということで、かなり興味があった。途中から参加。

  • ファイルストレージのいろいろ、
  • ローカル保存 -> 簡単、スケールしない、 NFS, rsync
  • DB 保存 BLOB -> パフォーマンスが...
  • 分散 FS mogilefs の話が中心に
  • perlbal も一緒に
  • X-REPROXY-URL むかしやったなあ(遠い目
  • X-REPROXY-CACHE-FOR これも(ry
  • prettyfs
  • 手軽、かわいい
  • 一台で全部動く (tracker, store), tracker isa httpd, perlbal 不要
  • mogilefs の問題点
    • store したファイルを返すとき content-type などをつけてくれない、 app ががんばって Header つける必要がある
    • prettyfs では header などのメタデータも file と一緒に登録しておける
  • update すると stored url がかわる -> perlbal でキャッシュしづらい（delete はできるけど app からじゃないと消すリクエスト投げられないから消しづらいよね)
  • on github
  • mogilefs ... telnet manage
  • prettyfs ... CLI

やはりというか、 MogileFS との比較を中心に話が進んでいった。 MogileFS については、自分もかつてサービス投入の直前（は言い過ぎかな）までいったことがあって、そのときずいぶん苦労していろいろ調べたりした覚えがある。ので、実運用してみて使いづらい点などは未体験なのだけど、構築して動くようにするまでも結構大変だということはわかっていたので、もっと簡単に導入できる分散ファイルストレージにはニーズがあるだろうなと思った。これはちょっとコードを読んだり、動かしてみたりしたいなと思った。ちなみに懇親会で kan さんとお会いしたとき、プロジェクト名の由来を聞いたら、やっぱり思ったとおりアレが語源だった。

ark - Framework inspired by Catalyst / Daisuke Murase (typester)

typester さんによる、 Ark のセッション。

  • Catalyst like, +CGI mode
  • Ark は BM11 に特化
  • 人気がなくなったサービスを CGI mode に移行してサーバリソースを節約できる www 現実的なソリューション
  • CGI mode 遅延ロード (Nanoa)
  • GET / => Controller::Root だけがロードされる、必要になったときにはじめてモジュールが読み込まれる
  • Text::MicroTemplate::Extended
  • 元々 Mojo::Template
  • TT の wrapper モデルににてる、ブロックをうめてくタイプ（あとで試す？
  • あと Ark::Models, models() とか
  • Ark, Catalyst をチューニングしてるかんじ
  • テンプレートと Ark::Form よさげ、 form パーツの html を楽に perl とかで書ける
  • use Ark すると use utf8 もしたことになる
  • mobile ブランチ モバイル対応
  • Plack/PSGI サポート
  • #ark, github

gihyo.jp でも連載があった（ような？）、 Ark についてのセッション。「人気がなくなったサービスを CGI mode に移行してサーバリソースを節約」というのが、なんともユニークなアイデアというか、言われてみればそのとおり、という感じで面白かった。テンプレートエンジンとフォーム構築のところが良さそうだった。遅延ロードなど、メモリや CPU などのハードウェアリソースに余裕がない環境でもストレスなく動くように考えられていて、なおかつ前に流行った CGI 専用フレームワークのブームとは違い正当派の WAF なので、覚えておいて損はないと思った。あまり規模の大きくないプロジェクトを今後もしやることがあったら、採用してみるのもいいかもな、と思った。フリーで受託案件などをやってる人が使うと、恩恵を受けられそうだなと思った。

Perl で圧縮 / Naoya Ito

はてなの伊藤直也さんによる、圧縮アルゴリズムなどについてのセッション。

  • なぜ圧縮？
  • データ容量が減っていっぱい保存できる
  • 読み込み速度があがる(!これが重要）
  • HDDのディスクシーク回数を減らしたい、圧縮と展開の CPU 時間オーバーヘッドよりも I/O 時間を減らしたほうが速くなるケースがある
  • データが小さくなると OS のキャッシュにものりやすくなる
  • アルゴリズム、符号化の話 Algorithm::Huffman
  • 整数、テキストなど、圧縮したいデータの性質によって、採用すべき圧縮方法も違ってくる（圧縮効率に差がでてくるので戦略を考える必要がある）
  • (可逆)圧縮の限界は数学的に証明されている、これ以上やったら復号できないというラインがある
  • 圧縮効率と速度はトレードオフ、効率を少し落とす（ファイルサイズ大きめ）と速度とメモリが効率よくなる
  • Perl (CPAN) で圧縮
  • Compless::*
  • Complress::Zlib 枯れている
  • Complress::LZMA liblzma, 7-zip のアルゴリズム (.xz)
  • Complress::LZO
  • 数字の圧縮なら pack() 関数もだいぶ良い
  • yapc2008, Pathtraq のプレゼン、 Kazuho Oku, URL の圧縮のために独自のアルゴリズムを実装、そういう戦略もアリ

最近の naoya のはてなダイアリーはむつかしい話が多くて読み飛ばしてばかりなので、このセッションもさっぱりわかんないかもなぁ・・・と心配しながら臨んだが、そこまで難解でもなくてほっとした。アルゴリズムの話はやっぱりわかんなかったけど、圧縮するとデータ量が減るので I/O 負荷が減るので良い戦略なんだよ、という話はわかりやすかった。 Complress::* ネームスペースのモジュールは、自分で使ったことはなかったけど、いろいろ特性が違うものがあるようなので、どんなものがあるかざっと眺めておいたほうが良さそうだなと思った。あと、 pack() で圧縮できるという話は興味をそそられた。

Booking.com & Perl / Cristina Nunes (mega)

ヨーロッパで最大規模の Perl をメインで使ってる企業だという、 booking.com のコーポレートトラック。

  • プレゼンした人女性、 Lisbon, ポルトガル PAUSE: mega
  • 基本的に会社紹介
  • Perl5.8.8
  • Class::DBI (old version?)
  • HTML::Mason
  • HTML::Template (forked)
  • Apache + mod_perl
  • MySQL (マイシークォー)
  • memcached
  • git (ギット)
  • jabber
  • front: 100+ web
  • DB: 100+ mysql
  • data center: 700+ servers
  • developers:
  • Perl, Java, Network, Sysadmin, designer
  • future goal
    • perl upgrade
    • modules upgrade
    • apache, mod_perl upgrade
    • mysql upgrace ... どこも同じ問題かかえてるんだなw
  • Hackers 多数在籍 (超有名なモジュール作ってる人だらけらしい)
  • オープンソース開発者をサポートする体制がある（仕事しながら OSS 開発していいとか)

急遽 YAPC のスポンサーになってくれた booking.com のセッション。なんといっても注目せざるをえないのが、 Class::DBI の古いバージョンを使ってますという点。自分がいま仕事で関わっているプロジェクトもそうで、たぶんかなり似たような状況なんではないかなと思ったので、この話題が出る前と後で聞く姿勢がかなり変わった。 MySQL のバージョンも古いっぽいのをほのめかしていたり、ある程度の歴史があるサービスはみんなそうなんだろうなあ、つまり同じようなことで苦労しているのだろうなあとしみじみ思った。あと、 Perl の凄腕ハッカーたちが多数在籍しているということで、 PAUSE id だか名前だかをメモったので以下に。あとで cpan で調べてみようかな。でも名前間違って書いてそう。

  • rgs
  • Abigail
  • Liz M
  • Book
  • demerphq
  • Favio Glock
  • Jouke Visser

ペパボでの Perl のつかいかた / Gosuke Miyashita (mizzy)

paperboy&co. の mizzy さんと hiboma さんによる、コーポレートトラック。ドクターペッパーチェリー飲みたい！

  • hiboma: アプリとサーバが両方できる貴重な人材
  • ドクターペッパーチェリー飲みたい！
    • daiba さんからドクターペッパーの差し入れw
  • 30d
  • perlbal, mogilefs + API (Catalyst), TheSchwartz, Gearman, Rails
  • Job Servers, API, web は rails
  • Gearman, Proc::Background + daemontools
  • TheSchwartz, Proc::Background + daemontools ... LD とにた構成みたい
  • ホスティング事業
  • ロリポップ、チカッパ、ヘテムル
  • 共有サーバ -> 全体の安定が重要 -> プロセス監視して行儀の悪いプロセスは始末する(時間かかるCGI とか) kill -9 してプロセスの情報をロギング
  • hetetop ..... プロセス監視デーモン
  • Sys::Statistics::Linux
  • many servers:
  • Archer by tokuhirom, deploy だけじゃなくてシステム管理にも使ってる
  • ロリポップリニューアル
  • 内部を API 化、 JSONRPC
  • かなりモダン、 HE, AnyMoose, D::OD
  • 管理用の各種ツール、コマンドを API -> Func 経由で叩く
  • qpsmtpd, SMTP server written by Perl
  • qmail のパッチあてて運用とか大変そう、 Perl なのでいじりやすい、プラグインかいたり本体に手を入れて使ってる
  • 勤怠管理、稟議など、バックオフィスのシステムも mizzy さんが Perl で書いてる（！）
  • 質問してみた
    • 「勤怠や稟議などバックオフィスのシステムは出来合いのを買ってくる会社も多いが、自前で作ったのは管理部門から自社で作れと要請があったのか、使いづらいものを買うくらいなら自分で作るよというハッカー魂がそうさせたのか？」
    • もともとシステムがなかった（紙ベースだったらしい）、システム化の要請はあった、あんまり買ってくるとか考えない気風

ペパボで Perl を使ってるというのは、ある程度 Perl のコミュニティに詳しい人なら mizzy さんと hiboma さんのことを知ってるから、当然使ってるよねーとわかるわけだけど、そうでもない人には新鮮な話題だったのかもしれない。自己紹介ならぬ他己紹介？は面白かった。真っ昼間から大学の講堂で TENGA はどうかと思ったけどｗあと25万とかｗセッションの内容は、ちょこちょことブログなどで見た内容だったが、 Any::Moose や HTTP::Engine を使っているとか、かなりモダン Perl を導入しているんだなと驚いた。ジョブキューを使ってどうこう、とかそういうあたりはライブドアと似ているのかなと思った。あと、 Perl 技術者があまり多くなさそうだなーとは思っていたけど、サーバ管理なども（アプリ書きとともに）両方できる hiboma は貴重な人材、といっていたところが、 PHP 書きつつサーバ管理もやりますって人はあんまりいないものなのかな？と少し不思議に思った（懇親会で hiboma さんに聞いてみたら、どうも PHP の人はあんまりサーバに興味ないという人が多いのかも？）質問の意図は、自分がいまいる会社だと勤怠管理システムのウェブインターフェースなどは管理部門が買ってきたものをそのまま使っていて、プログラマはみんな使いづらいと不満を感じているんだけど、そういうシステムはうちみたいな技術を売りにしてる会社でもそうなのだからどこも似たようなものなんだろうなと思い込んでいたので、そうじゃないというのはかなり意外で、だからなぜ自社で作るに至ったのかその経緯や意図が知りたかった。

MooseX Toursm / Florian Ragwitz (rafl)

MooseX::* の紹介のセッション。これも有名外人ハッカー見たさで選んだ。次の Danga::Socket と Perlbal のセッションが聞きたかったので途中で抜けてしまった。 Florian Ragwitz がナマで見られてよかったｗ

「Ficia」インフラと Perl にまつわるエトセトラ / ひろせまさあき (hirose31)

最後少しだけみた。

  • MATRIX, 一台のサーバが基本なんの役割もできるようにセットアップされてて MATRIX の定義にしたがって自分に必要なサービスを立ち上げる、みたいな
  • Wakame に通じるものを感じた

Danga::Socket の非同期処理の仕組みと Perlbal で非同期処理するプラグインを書く方法 / Gosuke Miyasita (mizzy)

Danga::Socket と Perlbal についてのセッション。

  • イベントドリブン、Danga::Socket 入門、
  • くわしくはスライドの図をみるとわかりやすい(言葉だと説明しづらい）
  • kqueue, epoll, poll
  • I/O, Timer
  • イベント登録 -> イベントループ(メインループ)に入る
  • Perlbal
  • TCPListener, Client Proxy, Backend HTTPD
  • Danga::Socketなので非同期に動く、ブロックしない
  • しかしプラグインがブロックすると他のもブロックされてしまう
  • ノンブロッキングなプラグインが欲しい
  • Danga::Socket ベースのクラスを作るか、
  • Danga::Socket::Callback をつかう
  • 外部ライブラリもノンブロッキングなものを使う必要がある
  • どうしても無理なら Gearman::Client::Async

Danga::Socket については、最近すこし Gearman をさわっていることもあり、ちゃんと勉強したいと思っていたところなので、入門というつもりで概要を聞いておこうと思って、早い段階からチェックしていたセッション。これはもう、図をみるのが圧倒的にわかりやすいので、 mizzy さんが公開するとおっしゃっていたプレゼン資料をあとでもう一度じっくりみてみようと思う。その上で自分でもコードを書いて、動作を理解したい。この前に聞いたペパボのセッションとあわせると、 Perlbal などはかなり実際のサービスで使い込んでいるのだなと思った。本体に手を入れるなど、かなり BradWare (Brad Fitzpatrick 製のソフトウェアのこと）のノウハウがたまっていそう。

Lightning Talk

LT はもうメモをとらず（とってる暇ないし）、ただただ楽しく聞いた。 yusukebe++

懇親会

今年の YAPC は「初心に帰る」をテーマに(ry　ということで、いまだかつてないほど積極的に懇親することを心がけた。結果、懇親しまくることができた。話してくださった皆さん、ありがとうございました。以下、帰ってからメモをとったぶんだけ、感想を箇条書きに。

  • pokemaru さんお久しぶりでした的な
  • zigorouさんtomi-ruさんjunichiroさんらとzigorouさんのもってきたカードゲームに混ぜてもらった、シンプルなルールだけど駆け引きがあって面白い！zigorouさんjunichiroさんはゲーム慣れしてて上手い、tomi-ruさんが大胆プレイで面白かった
  • kazeburoさん連載立ち読みしてます -> 買ってください、とか
  • 8-p.info のかとうさんといろいろ、むかしの話やいまの話を聞かせてもらったりとか (昨日前夜祭の帰りに渋谷の hmv でばったり会った)
  • まかまかさんといろいろお話しした、次からも同人誌をつくられるそうで、acme大全買えてすげーうれしっす、次も買います！といった、 JSON 1.x -> 2.x での api 変更にまつわる苦労話などを聞いた
  • typester さん曰く「LTはそれ用にネタ用意するけどふつうのトークは普段やってることを出せばいい、LDでブログやってて話すネタがないわけがない、ライブドア技術者の憂鬱とかどうですか」といわれた、精進します
  • nekoya さんといろいろお話、「Perl の人ってブログにあんまり○○がわからない、とか書かないけど刺身はけっこうそういうのを書くので、わかんない人ほかにもいるんだなって元気づけられます」といってくれた
  • hiboma といろいろ話をした、やっぱり「○○わからない系の素朴な疑問エントリは好き」といってもらえた、 clouder さん曰く「オレもむかしmiyagawaさんとか近くにいてわからないってブログに書いたりしててnaoyaが教えてくれたりした、このへん似た匂いを感じるんだよね」


一日目を振り返ると、朝から晩まで集中力を切らさずにセッションに参加できたと思う。メモもそれなりにとれた。東工大のロケーションは素晴らしく、今年からの試みであるコーポレートトラックもかなり良かった。 JPA 主催になってから一回目の YAPC で、スタッフも少し入れ替わりがあったのか、やや進行がもたつくところもあったけど、大きな事故もなく内容も充実していて良かったと思う（なにこの上から目線）

スタッフの皆さん、ボランティアの皆さん、スピーカーの皆さん、参加者の皆さん、お疲れ様でした。二日目に続く。