今日はYAPC::Asia Tokyo 2013の2日目です

2日目です。地元開催なので、地の利を生かして朝からタリーズでのんびり朝食などとっております。今日もgihyo.jpさんのスペシャルレポートにレポーターとして参加しています。

Yasuhiro Horiuchiさん「Programming AWS with Perl」

• AWSの普及のため、各地を回る
• AWS → 日本でも20,000アカウント以上
  • Redshift データウェアハウス
  • ElastiCache redis対応
  • ブラウザから操作できる
  • コマンドラインツールでも操作できる
  • API(REST/SOAP)が定義されている→制御できる
  • 必要なときに必要な分だけ使える
• 認証をして、起動、停止、DB起動やバックアップ、情報取得などできる
• 対応している言語
  • PythonやNode.jsに最近対応
  • ・・・Perlがないっ
• Command Line Interface すべてのサービスを一つのインタフェースで
  • 今後はこれを使うのがベター
• pip install awscli
  • .aws/config に設定を書く
  • complete -C aws_completer aws のような設定で補完をするといい
  • aws ec2 describe-instances → JSON形式
    • --output table, --output text などで形式を変えられる
  • aws s3 ls → バケット一覧
  • aws s3 sync . s3://bucketname/dir
  • aws help、 aws ec2 help → 困ったときは
  • ソースはgithub で管理されている
• AWS::CLIWRAPPER by hirose31さん
• VPCをPerlのプログラムから作成してWEBサーバを起動するデモ
  • MTが起動するとこまで
• ラスベガスに行きたい人がいれば声をかけて下さい
• Q. Net::AWS::S3 とかモジュールがあるのだけど？
  • A. 性能は違うかもしれない。AWS CLIはバージョンアップされていくので、ラッパーのほうがいいかも
• Q. カジュアル用途じゃない場合はCLIはきつい？
• A. 中の人が書いているので・・・個人的にはCLIがいいかなと

Tatsuhiko Miyagawaさん「What's new in Carton & cpanm」

• cpanm
  • インストールはcurl -Lして実行が簡単
  • perlbrew, plenvと組み合わせると使いやすい
• cpanm 1.6
  • バージョン固定、範囲を指定してのクエリ→最新以外を入れられる
  • cpanm DBI@1.200 → CPANやbackpanを勝手に探す
  • cpanm Plack~">= 1.0, 2.0"
  • --dev デベロッパリリース (バージョン番号に_かTRIAL)
  • MetaCPANとPAUSEの互換性は、100%ではない
  • git://からインストール。@でブランチ名など指定
  • (Makefile.PLやBUILD.PLがない場合はダメ。Dist::ZILLA使ってるとか)
  • cpanfile → 依存を記述したファイル
• cpanm 1.7
  • 実行ファイルが小さくなった
  • Travis CI → .travis.yml に --with-developとか書くといい
  • cpanfileの記述で、develop、recommendsに対応
  • --with-feature=sqlite
  • --configure-args=... で指定ができる
  • --uninstall
• Carton (Bundler for Perl)
  • モジュールの依存関係をフリーズし、他のサーバでデプロイを可能に
  • 「バージョンをあげたら壊れた」を防ぐ
  • cpanfile と cpanm でも実現可能では？
    • 依存先のバージョンが固定されているか未知数
    • MetaCPANが必要
    • ロールバックができない
  • 8月に1.0が出た
• Cartonでのデプロイ
  • cpanfile.snapshot を入れ、install --deploymentkで入れる
  • herokuでデプロイにcartonを使う例も
  • 待ってるだけでは対応してもらえないので、言ったほうがいい
• 今後の方向性
  • cpanfile が git syntaxをサポート
  • git、refでgitのブランチへの依存が可能に
  • PAUSEなどのtarのURLにも対応(MetaCPANに依存していいなら不要)
  • 内部的な修正
  • プラグインの復活
  • CPAN Testersのサポート(プラグインで)
  • carton execの中できちんとロードができるか
  • --path をインストール時の情報を覚えるように(bundlerと同じ手法)
• デモ
  • gitから入れる例。バージョンはSHA1になる
  • carton tree

@naoya_ito さん「YAPC::Asia Tokyo 2013 特別座談会 「Rubyの良いところ語ってください 〜そんなPerlで大丈夫か？〜」」

• Rubyから習う。Perlに触れる
  • PerlをDISる会ではない!!
• @shyouhei → 個人としてやってきた。Rubyの中の人
  • コミッターとして。仕事ではPerl書いていたり
• @secondlife → はてな入って1週間1ヶ月でRuby書くようになった
  • 組織的な話
• @masuidrive → 風呂でIKEAの人
  • いろいろなコミュニティを見ている。ユーザの立場
• @tokuhirom → Shibuya.pm。Amon2の人。ツールチェーン。
  • Perlの立場
• なぜPerl?
  • @masuidrive 4のころPerl使っていた。オブジェクト指向でRubyに移った
  • @shyouhei ブログブームでtdiary。不満があってコミッターに
  • @secondlife tdiary。Railsでコミュニティ形成が面白かった。
    • 「PHPからどう移った？」「趣味として」
  • @tokuhirom 15からRubyとPython。学生はPython。LLの実行委員で求人されて、仕事で始めた
    • Perlがいいからというわけではない。naoya_itoさんやmiyagawaさんの影響も
    • いろんな言語使ってみたかった
• 好き、嫌いは？
  • @secondlife Rubyは標準ライブラリのセンスがいい。
    • 「やろうと思えばできる？」「学習コストが高い。言語がサポートしていると入りやすい」
  • @shyouhei
    • 似ているとこが多い。この時間はあえて差分はとりあげるが、ナーバスになる必要はない
    • Rubyにあるのは未来。言語がプログラマに思想を振りまく。例はキーワード引数。言語でサポートした
    • Rubyは世界を変えることに積極的
  • @masuidrive 肌に合った。Rubyの良さは処理系の多さ
    • @tokuhiromさん「goccyさんのような動きはある。Perl6は種類がある(どれひとつとして・・・だけど)」
    • パフォーマンスを考えるとJVMで動くのはよい。実装が複数生まれたのは面白い
• 言語を変えて生産性は？
  • @masuidrive 1つに集中するとよくなる。知識の蓄積。肌にあうか合わないか。
    • Ruby検定に落ちた。公式の検定対処本を書いた。二度と受けられない
  • @shyouhei 適材適所。全部をRubyで書くのはどうか。Shellで書いたほうが早いとことか
    • 「LLでの比較では？」「違いはわからない。開発する分野による」
  • @secondlife Rubyがサポートが厚いという意味で生産性が高い。足りないものがあれば補えばいいけど。
    • 会社内に詳しい人がいるといいけど、コミュニティが大きくないときつい
  • @tokuhirom LLは言語レベルでの違いはない。行列計算とかだとpythonとかはあるけど。自分が使いたいライブラリは書いてしまったので、使いやすい
• こういうライブラリがあってすごいとかある？
  • @secondlife Rails、Capistrano、bundler。OSSの活動が視覚化、活発
    • 「他の言語との比較で？」「ファッション的な風。nodeとかでも感じる」
  • @shyouhei 個人的にはない。Railsより前の人が多い。スレッド、struct。
  • @masuidrive Railsがあるから。ビジネスとくっついた。経済圏(heroku、パフォーマンス監視)
  • @shyouhei Railsは適当に作って適当に動かす。当時ビジネスになるかと疑問だったが、ビジネスチャンスがあったようだ
  • @masuidrive Rubyなの？Railsなの？ コミッターから見て
  • @shyouhei RubyはRailsのものではないが、いろんな分野のいろんな専門家が来た。初心者の気付きは重要
• Perlとビジネスの現状は？
  • @tokuhirom Heroku、dotcloudくらい。サポートしない、サポートしてと頼まない、流れがちょっと
  • travisとか、周辺ツールのサポートは、Perlのコミュニティが頑張って働きかけている
  • @masuidrive Rubyを使っている人が始めた。と言うのが多い
  • Perlはコミュニティの人が切り開く、Rubyは勝手にできていってるイメージ
• CPAN VS rubygems
  • @secondlife 2008年のgithub以前はPHPで作ったサイトやMLで動いていた
  • @shyouhei RailsはSVNだった。その後githubに移った。新しもの好き。古いバグチケットとか
  • @tokuhirom CPANにRTとかあるけど、githubに移ってる人は多い
  • @masuidrive githubはコードとコミュニティの距離を縮めた。メールで聞くよりpatch送る方がいいでしょう
  • @tokuhirom PerlにとってRTはすごく重要だった。歴史的な問題
• DevOps
  • @secondlife puppet。Rubyで書かれてるだけど言語関係ない
  • 「使おうとしているツールがRubyばっかなんだけど」「仕事として使っている人の比」
  • @secondlife 言語学習のコストの問題。低いほどDevOpsで使いやすいのでは
  • @masuidrive 一昔前はrubyをサーバに入れられると嫌がられた。5年前ならPerlで書かれていた気がする
• コミュニティとの関わり
  • @shyouhei コミットしている。コミット権は比較的もらえる。時々集まる。フラっとコミッターが現れる
    • 意外と言語のセッションがあって、いい意味で意外だった
  • @masuidrive Seattle.rb。日本人に優しい。Matzを中心としたコミュニティ
    • 「海外からの参加者との関わりは？」「RubyKaigiのほうが海外から来る方が多い」
  • @secondlife 組織とコミュニティが関わっている企業も多い
  • @tokuhirom 日本にPerlのコミッタは居ない。コミッタを崇める文化がない。コミッタをそもそも知らない。一方CPANモジュールのメンテナのほうが注目を集める
  • @shyouhei コミュニティはふわっとしていて分断されているわけでもない。所属しているコミュニティを自分で思うのは自由だけど、排斥すべきではない
• Perlリスク論が生まれることについて
  • @masuidrive あまり詳しくない
  • @shyouhei Rubyは今盛り上がってるが、10年後とかは？ 拘るのはよくない。プログラミングをハッピーにする。Perlが衰退している、ということより重要なことはもっとあるのでは
  • @secondlife ユーザに価値を早く提供するために仕事をしている。Ruby以外の選択も決断できることも。Perlのコミュニティの人は他のコミュニティを研究している
  • @tokuhirom 何年も前から、Perlは今さら駄目だ、と言われ続けて状況が変わっていない。言語は仕事の一要素でしかない。そこに依存したエンジニアになるべきではない
• Perlでこういうことできるよ、ってよりは、いろんな言語のコミュニティに目を向けるといいでしょう
• Q. 昔RubyのプログラムはPerlより遅かった。苦労はない？
  • A. @secondlife IOが支配的。なのできっと大丈夫でしょう
  • A. @shyouhei CP社からはGCを早くと言われる。JVMのようなチューニングできるようにはしたい
  • A. @masuidrive そういうことで実装が多数生まれている
• Q. FreeBSD でRuby 1.9になったが、いろんな物が壊れた。これを上げるとこういうものが壊れるというチェックは？
  • A. @shyouhei やってない。壊れてもやる。これから書くコードを楽しくしたい
  • A. @dankogai Perlでは奇数バージョンでなんとかする
  • A. @secondlife 最近だと短期間で問題なく上げれた。最近は重視し始めた。新しいものを受け入れるコストはあるが、そのほうがトータルでプラスだろう

handlenameさん「チャットサービスの運用事例」

• Lobi チャット＆ゲームコミュニティ
  • スマホのゲームと一緒に使う
  • API/SDK がある。スマホ向けアプリに組み込む想定
  • #lobi@freenode
• 規模 550 req/seq, ピーク 2,000
  • 6500qps。ピークが18,000。アカウントが800万程度
  • 専属20名。サーバサイドエンジニア中心
  • 他に、インフラチーム、CSチーム
• データセンターとAWSの併用。AWSに移行したい
  • 自社センターにコアAPI。他をAWS。CloudSearch、CloudFront
• カンバン方式
  • プランニングポーカーを利用
  • ホワイトボードで見えるか
• レビュー
  • GithubのPull Request
  • レビューを経なければマージ不可
  • 開発とレビューのバランス
  • 巨大プルリク → 細かくレビューを
• GitHub Flow
  • masterと作業用ブランチのみ。releasブランチはない
  • masterはリリース可能
  • 1日に数回〜十数回
• CIはJenkins
  • EC2のスポットインスタンス
  • Githubとの連携。実行中、成功、失敗をアイコンで表示できる
• テストの並列化
  • App::Prove::Plugin::MySQLPool → Test::mysqldを一階建ち上げる
  • c1.xlargeインスタンスで10並列
  • 7分
• カバレッジ 85%
  • APIを叩くテストがメイン
  • リファクタリングの妨げになることを防ぐ
• デプロイはgit pull
  • 変更のあるファイルに気がつける
  • git status -s -uno
  • parallel コマンドを並列実行するツール
  • デプロイしたら通知をIRCへ流す
• IRCの活用 → botが簡単に作れる
  • ボットに話しかけると、ログの検索してくれたり → 結果は社内用nopasteへ
  • チケット番号をURLへ展開
  • cronの実行結果をfluentdに投げ、社内に投げるfluent pluginの組み合わせ
• 5年で様々なリプレース
  • svnからgit → 元々git-svn使ってた。今はGithub
  • DBICからteng → 共存していた時期はデリゲートするメソッドを書いて
  • Catalist から Ark + Amon2 → モデルはArkとAmon2で共用
    • Arkはcpanに上がったらしい
  • AWSからデータセンターからまたAWS → 最初は小さいからAWSを選択していた。伸び率が大きくなってまたスケールを簡単にしたくなった
  • NakamapからLobiへ → ターゲットが、仲間内、女子会、ゲーム、と変化
  • nakamap.comからlobi.coへ → APIは提供していたため、古いドメインも残している
• Q. ORマッパとフレームワークの変更は、経営的に見てどういうメリットがあるのか
  • A. 開発コストが下がる。新しいものを使いたいエンジニアがリードする。
• Q. 巨大なプルリク
  • A. まとめてリリースする必要があるのはブランチのブランチ
• Q. リアルタイムメッセージのテストは？
  • A. 並列実行のテストは甘いかもしれないけど、テストは必ずつけている
• Q. 秒間550はnode？perl？
  • A. アプリケーションをブロックする処理はnode。APIはPerl。合わせて550。比率はPerlが多い
• Q. デプロイツールはないようだけど、ロールバックは？
  • A. revertしてpullする。スキーマの変更は別の手順が必要
• Q. リアルタイムメッセージングのスケールは？
  • A. node.jsで受け、それぞれがつながっているユーザ情報を持っている。メインのアプリがnode.jsに流す。接続情報はKTが持ち、アプリケーション側で振り分ける
• Q. 1台で10並列すると競合するのでは？
  • A. App::Prove::Plugin::MySQLPoolがそれをやっている。インスタンスのコピー。

makamakaさん「同人ゲーム「PM（ぷむ）からの野望」の考案と実践」

• Perlコミュニティについてアナログ的に考える
• 2011年 Paumon
• 2012年 やっぱしぃ YAPC → β版。未完
• 2012年 新春初笑いperlすごろくとして完成
• 牧さん曰く、「肉料理ばっかたべると飽きる。サラダが必要」
• 「PMレボリューション」に名前変更
• 良くないお知らせ → カードゲームになった
• 悪いお知らせ → 完成しなかった
• 理由 → YAPC::Asiaの開催時期が年々早まってる
• 概要
  • プレーヤーはPMとなってイベントを皆済、ポイントを獲得。
  • プレイヤー2〜4、10〜20分。
  • PMカード、手札カード「人気カード、会場カード、特殊カード」
• PMカード → PMの属性、拠点となる会場が書かれる。CP(会場のキャパシティ)
  • 13PM
• 人気カード → 初学者、初心者、ベテラン、ギーク
• 会場カード → CPが獲得ポイント最大数の制限
• プレイヤーができること
  • 会場カードを置く
  • イベント開催の宣言→声が裏返る感じで絶叫する。属性を指定できる
  • 人気カードを裏にして出す
  • イベント開催して改修→「今開催！」と絶叫
  • 特殊カードの使用(ターンじゃなくてもいつでも)
    • Perl入学式とか、モバイルガジェット販売
    • 三種の人気を集めると300pt(!!)
• Q. カードゲームの再販は？
  • A. 「良い質問ですねぇ」
• Q. Acme大全は後何冊？
  • A. 後7冊。引き換えて頂けると

Lightning Talks Day 2

kanさん「目指せ、テストカバレッジ100%」

• タイトルは釣り。100%は目指さない
• カバレッジ → テストがコードの何%を通っているか。ifの分岐とか忘れてないか
• Devel::Coverが鉄板
• HTML生成して確認するのはめんどい。チームの共有がめんどい
• coveralls
  • プロジェクト単位でカバレッジを表示してくれるサービス
  • Perlに対応していない
• Devel::Cover::report::Coveralls
  • Devel::Coverのフック
  • .travis.yml からcover -test -report coveralls を実施するといい
  • travis CIの環境変数からtokenをとっている
• coverallsの人が入れてくれると言ってたけどまだ入ってない

walf443さん「DBIx::RecordFactory」

• DBIx::... → またか
• RubyのFactoryGirlのようなもの
• Tengのschemaからルールを自動生成
• intやvarchar、PKに合わせて自動でランダムにデータを作る
• DBIx::Inspectorとかはちょっと重い

maka2_donzokoさん「今年のPerl同人活動報告」

• 新春初笑いPerlすごろく
• Acme大全2013 370ページ、500g
• 北海道で「エロ本持って来ないで下さい」と言われた
• 10日でおぼえきるPerl / どんどこ楽屋
• シールについて
  • 100枚くらい余ってる
  • 没ネタ。弾これ

azumakuniyukiさん「JSONでメール送信」

• bounceHammer、Acme::Nyaa
• Haineko (HTTP API INTO ESMTP K=undef O=undef)
  • JSONでメールのデータを渡すと、別のSMTPサーバにリレー
  • ドメインごとに配信方法を分けたり
  • plackupで上げておいて、投げるとよい

barimiさん「初めてのPerl 〜つぶやいてないでコードかけ〜」

• Perl歴5日。初めてのYAPC::Asia ITディレクター
• つぶやくとフォローあーが減る
• Do Not Tweet And Write Some Code
  • フォロワーのつぶやき数をカウント、上位10名にコード書けとメッセージを送る
• 最速でPerlを覚える
  • 初心者向け
  • 締め切りを作る
  • 徒歩5分に住むPerl Mongerからコピペ

papixさん「Perl入学式2013年度中間報告」

• 40人参加、サポーター10人
• YouTube APiをWebService::Simpleで
• 大阪:22回開催、福岡:3回開催、宮崎は3日
• 今年 大阪は3回、東京は6回
• 今後
  • Perl6入学式、Perlテスト入学式。
  • 沖縄、札幌で短期集中。
  • YAPC::Tohokuでも？

kamipoさん「mysql-buildでQ4Mやmroongaもビルドしたい」

• ストレージエンジン
  • Q4M livedoor, mixi, DeNAで利用
    • 仕事で使ってるからセットアップできると嬉しい
  • mroonga
• mysql-buildにプラグインをビルドする機能
  • mysql-buildはmysqlの3系から最新のすきなものを
  • -plugin オプションで mroonga, Q4M

n.tomitaさん「ねたモジュールについて」

• ネタはタネからきている
• もっとネタモジュールがあればいい
  • Perlは柔軟性がある。うけ入れる文化がある
• 今でしょ！ → Bangs::ProhibitFlagComments
• use hanzawa → 数字を勝手に倍にする
  • returnするときだけ倍にするには工夫が必要a
• github、PrePAN
  • ハードル高いのでnetacpan.orgを作った

kamadangoさん「5文字以内のレスを推奨する節」

• ボケてはスモールチームで開発した → マイクロコミュニケーション
• テンションの維持がポイント
  • 依頼、了解、質問、回答、完了
  • 短文＋「！」
  • 短文で開発効率が上がる。!でテンションが上がる

tokuhiromさん「Test::Power」

• okだけで書きたいんだけど、ok $x == 3 と書くとわからない
  • Test::Powerが解決→gfxさんが話したから微妙・・・
• HTTP::Body::Builderを作っておきました
  • (Yappoさんがビールを渡す)

takusさん「若者が Velocity Conferenceに参加して感じたPerlの現実」

• Velocity Conference
  • オライリー主催。WEbのパフォーマンスとオペレーション
  • 会社に国際学会派遣制度があるので
• Ignite Velocity
  • 5分の持ち時間、15秒でスライドが移る
  • serverspec、Growthforecast、fluentd
  • できれば自分のプロダクトで話したい
• 運用ツールはRuby、Pythonが多い
  • コミュニティにアピールすべき。マイノリティになると辛いので

cubicdaiyaさん「mruby_nginx_module」

• nginxの記事を書いたらdisられた
• nginx.confが6000行超えてる
• mruby_nginx_module
  • ngx_mrubyのフォーク
  • nginxの設定でrubyが書ける
  • 各フェーズで処理を共有できる
  • 中間コードはキャッシュする
• 今後 → 正規表現、共有メモリ、サブリクエスト、ノンブロッキングソケット

nekokakさん「DeNA common tech Trial」

• CM動画が最後まで流れてなかったので改めて公開
• コミットログにfuckと書くと怒られる
• 個別な問題解決を避ける → common tech
• Baranネームスペース
  • 弁当の隙間に入れる緑色のアレ
• 横の連携がとれるように

引き続き

pjfさん「Staying sane with Method::Signature」

• Method::Signature
  • methodキーワードを使う
  • !を使う
  • $self
• JSONは審議がtrue、false
• 日付を自動で変換
• @_は使わなくて良い

takesakoさん「Perl○×クイ大会会」

• アセンブラかるた、バイナリかるた
• セキュリティ速押クイズ
• ECMA-262を読む、的な訳本をプレゼント
• 全員起立
  • Q. Perlの変数名に250文字は使えるか
  • Q. Perlの変数名に255文字は使えるか → 変数名は251文字まで
  • Q. perl -E'say($[ == 0)' →丸
  • Q. perl -E'say($] < 6)' →丸
  • Q. perl -E'say($^F == 2)' →丸
• 一人が確定

Tomohiro Ikebeさん「management and Perl culture」

• 娘さん「またAKB??」
• EDGE、LIVEdoor、nhn、LINE (転職ではない)
  • dankogaiさん、miyagawaさんと働いていた
  • LINE**、livedoorポータル、livedoor Blog、naverまとめ
• livedoor Blog → 恐らくmod_perlでさばいたPV数で一番
  • 負債が一気に返済されてよかった
  • 2007年以降マネージメントを考え始めた
• Software development → PCに向き合ってカタカタやってデュフフ
  • 昔のイメージ「少数のおかしい人が作るのがソフトウェア」
  • 実際はそういうことはない。人間が集まって作る
• managerとは
  • 上司？「きみきみ、やっておいてくれたまえ」？
  • 中高生の頃はマネージャーは南ちゃんだったはず
  • 偉そうにしていてもやる気はでない
  • 選手が集中して競技できるようにする
  • 「はちみつレモン的なことをやる」
• management != 管理
  • マネージメント、と言いたい
• work environment
  • 非常に大事。PC、椅子、朝起きれない、子供の送り迎え
  • 自分の裁量で出来ないこともあるが、善処する
• personnel issues
  • 自分より優秀な人を雇う
  • 優秀な人をとるのは怖い。チームのキャップがマネージャーの能力になってはいけない
• personnel issues
  • 個人個人で色が違うのが重要
  • 「数字が上がることに興味がある」「技術的な正しさに興味がある」など
  • ユーザに近いのが好きな人、苦手な人 → 辛辣な意見への耐性
  • 誰に何をやってもらうか。誰と誰をペアにするか
  • 将来をどうするのか。人事制度が必要
  • できるエンジニアにマネージメントをやらせるのは無駄が多い
  • エンジニアのまま相応の対価が渡るような人事制度
  • マネージメントとリーダーシップ→一般的に、優れたエンジニアはリーダーシップがある
  • 「そろそろマネージャーにならなきゃいけないんですよね？」はちょっと
• direction
  • この仕事をなんのためにやっているのか
  • 使うフレームワークとか、スマフォに力を入れましょうとか
• marketing
  • エンジニアから、言いようのない嫌悪感
  • 自分たちのやってることを、きちんと周りに伝えることは重要
  • エンジニアの成果はわかりにくい。mod_perlをPSGI化するとか、経営層に伝わらない
  • 我々はきちんとこういうをやってるので、こういう権利を下さい。という交渉
• 80人のエンジニアのチーム
  • AKB48の研究生まで集めた人数くらい
  • サーバサイドはPerl。Objective-C、Java、JS。Rubyを使っている人
• なぜPerlを使うのか？
  • dankogaiさんが使ってた→それ以前にホリエモンが使ってた
  • Perlができない人も、入社して欲しい
  • プロダクトを作る上で、言語の差はない
• なぜPerlなのか
  • TIMTOWTDI → やり方が1つだとつまらない
  • CPAN → CPAN sommelier という職種がある。OSSの質を見分ける力
  • Legacyだけどモダン → 古くからあるし、新しいものも作れる

牧さん / YACP::Asia Tokyo 2013 Wrap up

• 8回目のYAPC::Asia。8回スタッフを経験
• チケット販売数、1,131枚
• ベストトーク賞
  • 「SQL書くまでは投票大丈夫です」
  • 3位 kazeburoさん
  • 2位 myfinderさん (実はlestrratさんも2位タイ)
  • 1位 yusukebeさん
• お知らせ → これがラストのYAPC
  • 941さんとlestrratさんは引退
  • JPAは継続
• わくわくする話はたくさんあったはず
  • Perl 5.20、Carton、PerlMotion、p2, gvip, perl.js
  • 日本のプロダクトが多い
  • 地域YAPC、Perl入学式 → 新しい世代
• 今までのYAPCでやってきたことの芽が出始めている
• 次はあなたがYAPCを。今年中に話をしに来て下さい
• ネットワークチームより「ネットワークどうでした？」「よかった」
  • 100Mbpsを記録(ほかは50mps)
  • みんなiOS7をダウンロードし過ぎ！
• スタッフによる写真撮影「はいチーズ」
• 次はみなさんのYAPCでお会いしましょう