読者です 読者をやめる 読者になる 読者になる

北海道苫小牧市出身の初老PGが書くブログ

永遠のプログラマを夢見る、苫小牧市出身のおじさんのちらしの裏

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

あいにくの雨ですが、今日も時間通り会場に到着しています。

本日もgihyo.jpさんの特集のレポーターをやってます。参加されているみなさんと一緒に楽しみながらレポートしようと思っています。

Kazuho Okuさん「Unix Programming with Perl 2」

  • 昨年のトークでは、エラーやファイルハンドル、シグナルについて話した
  • 今年はプロセス間通信と、シグナル周りのレースコンディション
  • IPC::Open3 : open3がロックする場合がある。いつ?
  • A). STDIN を読むコードの場合、$cinを待ち続けるのでロック
    • close $cin する
  • B). 子プロセスがSTDOUTとSTDERRに大量にデータを吐いた場合、バッファがいっぱいとなる
    • 試すと、16384byte (16KB)でブロックする。これがバッファサイズ。OSによって異なる--close $cout, close $cerr では解決しない → エラーにより戻り値が変わる
    • while (<$cout>) + while (<$cerr>) では? → <$cerr> の読み込みに処理が移らないので駄目
    • 答え: $cerrにundefを渡し、while (<$cout>)する。
  • ADVICE). パイプを使わずに、tempファイルを使うとよい
    • |- cmd > tmp とかじゃだめ? → shell の解釈が入る分遅くなる。また危険にもなる
    • open3を使うとよい
  • レースコンディションについて : while して signal するプログラムで、間にSIGHUPが割り込むと想定通りに受信できないことがある
    • POSIX::pselect を使うといいはず・・・しかし、この実装に不具合のあるケースがある
    • evalとdieでsigprocmaskをしても問題は解決できない
    • シグナルにsyswriteを呼ぶとよい
  • まとめ
    • バッファーサイズは有限なのでデッドロックに注意
    • shellの呼び出しには問題があるので、@argsやIPC::Open3を利用
    • シグナルのレースコンディションには注意する
  • 質疑応答
    • Q. UNIXの仕組みでなくAnyEventで何か違う考え方ができる?
    • A. ラップされてるはず。なので、これらは問題にならない

masahiro naganoさん「運用しやすいWebアプリケーションの構築方法」

  • 旧職での経験 : 1億PVから10億PVへの増加、2000台のサーバ、数十のサービス
  • 運用しやすい = 「障害を起こさない」「早く復旧する」「スケーラビリティ」
  • ログ → アプリケーションからの情報発信
    • 障害発生の際に最初に見る
  • ログがないと調査に時間がかかる
  • Log::* はたくさんある。どれを選ぶべきなのか
  • ログが含むべき情報
    • 時間、ログレベル、環境、caller、メッセージ(主語+目的語、述語)
    • Log::Dispatch は機能不足ではないか
  • ログレベル
    • DEBUG、INFO、WARN、CRITICAL
  • Log::Minimal
    • ログレベルごとにXXXXfとXXXXff が用意されている
    • fとffの違いはスタックとレースの有無
    • LM_DEBUG を環境変数を指定すると、debugレベルが表示される
    • $Log::Minimal::PRINT を上書きすると、出力方法を変えられる
    • $Log::Minimal::COLOR を有効にすると、カラーリングできる
  • Log::Minimalの設計思想
    • WAFともModelとも粗結合。環境の情報はPSGIのMiddlewareで行う
    • Plack::Middleware::Log::Minimal はREQUEST_URI情報をログへ付け足す
    • worker の中では、$Log::Minimal::PRINTを上書きして負荷情報を足せばよい
  • DBが重いとき
    • show processlist、slow_log、などを確認
    • アプリケーションのコードからなんのクエリか確認。killしていいのか?
    • チューニングで解決できるのか
    • → ORM大っ嫌い
      • SQLとコードがマッチしない → grepで該当箇所が見つからない
  • ORMを使うときの注意
    • SQLの生成個所が散らばらないようにする → 特にViewで生成しない
    • クエリコメントを加える
  • DBIx::Sunny → DBIのサブクラス。caller情報をSQLコメントへ埋め込む
    • 他、select_oneやselect_rowなど、便利なショートカット
    • SQL::Makerとの組み合わせなど
  • DBIの接続をキャッシュすると、接続時間が長くなる
    • 最大接続数に達しやすくなる
    • DNSの書き換えが浸透しなくなる(メンテしにくい)
    • SHOW INNODB STATUS が見れなくなる (欲しい情報が末尾にあるので)
  • Scope::Container でDB接続管理をする
    • local と似たような機能。処理単位で接続を切るようにする
  • Scope::Container::DBI
    • Scope::Container + DBI を楽に実現
    • 他、DBIのクラスを変更できたり、slaveのランダム接続など
  • Plack::Middleware::Scope::Container
    • コントローラとモデルにまたがる処理単位を、まとめる
  • memcachedの課題
    • 永続化されない
    • 特定のキャッシュへアクセスが集中すると、特定のサーバ負荷が高くなる
    • キャッシュが切れるタイミングで、DB負荷が一気に上がる
  • Cache::Memcached::IronPlate (CPANにない)
    • memcachedのラッパー
    • cacheを複数に保存する。過半数が生きていれば有効と見なす
  • Cache::Isolator
    • graceful expire → expire 時間の違うキャッシュを二つ作成し、9:1の割合で分岐
    • concurrency controled get_or_set → 同期をとってDBへの同時アクセス数を制御
  • Plack::Middleware::ServerStatus::Lite
    • Apacheのmod_statusに相当
  • Parallel::Scoreboard
    • update->('.')、update->('A') などで、ジョブのワーカーなどから状態通知させる

nekokakuさん「watch your log」

  • 使ってないモジュールのトークばっかじゃん→今日のアプリは業務で使ってます
  • DevOps → DevとOpsは仲良くすべき
  • Opsのことを考えられるDev
    • Opsの人が1次対応をする → Opsの人へ情報を送る
    • 運用したことがないミドルウェアの情報をDevでも調べて共有
    • 新機能のリリースはOpsへ伝達
  • Devに依頼ができるOps
    • アーキテクチャ、対応すべき問題を理解する。
    • 必要な情報はDevに提出させる
  • DevとOpsのコミュニケーションに関して作ったモジュールのお話
  • 監視
    • 死活監視、リソース監視、ログ監視
  • ログ監視のソリューションでいいソリューションがないのではないか
  • DevとOpsは、ログの出力方法を取り決めるべき
    • Opsの一時対応が早くなる → WEB+DBのkazeburoさんの記事を参考
  • 監視すべきログ
    • access_log, error_log, application log(syslog), mysql slow log
  • access_logやerror_logは外部からのリクエストへのレスポンス
    • 500系 → アプリのバグ
    • 404 → HTMLの記述の不具合
    • error_log はゴミが多かったりする
    • error_logのundef のwarning などは緊急性が低いので、1日に一回見ればよさげ
  • application logはDevとOpsの取り決めが生きる
    • ビジネス的な深刻度をログに吐き、対応フローを決めておくとよい
  • mysql slow log : ほとんどの場合、DBがボトルネック
    • 数十GB溜まっていたりする・・・
  • ログファイルのローテーション
    • mysql slow log は日単位でローテーション → 圧縮したり
  • ログの収集方法 → Komainu
    • accesslog, applicatio log, slow log の集計を設定により集計
    • fork model で動く。fork数は制御される。結果はDBへ
    • 親プロセスはDBから収集する
  • DBにいれるメリット
    • 過去のデータと比較できる
    • グラフ化しやすい
    • 子プロセスと親プロセスのやりとりが楽
  • 最低でも5分に1回サーバを巡回して結果通知したい
    • 時間でgrep × ステータスでgrep して集計
    • 実行は、昨日のpfperlにて各サーバで
  • Application LogはDevとOpsで決めた文言をgrepするだけ
  • deployすると、時間が自動的に記録される
  • mysqlで実行に時間がかかっているものをリアルタイムであれrつぃたい
    • show full processlist でしきい値を見れば
    • 自動でKILLかは微妙
  • 実際の監視対象
    • 100台以上。access_log ベースで億単位。
    • fork modelで2.5分で処理完了
    • 監視用の専用サーバも必要
  • 重要なこと → サービスのクオリティーの維持
    • 利用者からの問い合わせで障害に気がつくのは情けない
    • ログ情報を通知し、以外にエラーが出てることに向き合う
  • Shut the fuck up and write some code
    • DevもOpsもエンジニア。行動すべき
    • コードの善し悪しは二の次。問題意識を持った人が行動することが重要
  • まとめ
    • DevとOpsは密なコミュニケーションが必要
    • 監視を軸にコミュニケーションを深められる
    • 監視を仕様化する
    • ログも監視しよう
  • 質疑応答
    • Q. syslogサーバは何台? ストレージの容量は?
    • A. 2台とか。ディスクも特別ではない。貯めるよりも、出たことに気がつくこと。過去の記録が残ればいいだけで、全てを残す必要はない。
    • Q. アクセスログ1時間で何GB?
    • A. 結構なサイズ。forkも何もしないと、5分では収まらない
    • Q. daemontools のマルチログをうまく使うには?
    • A. 使いにくいので副次的に使う程度でいいのでは。

hiratara「Monads in Perl

こちらはgihyo.jpさんの特集へ掲載しています。

SKYARC System presents 招待 LT

papixさん「Cコンパイラ用テストスイート自動生成システム」
  • testgen2 は Perlで書かれている
    • テスト生成、出力の解析などをPerlで解析
    • Cコンパイラ用のテストスイートの自動生成
    • K&RとC89コンパイラ開発の初期。9000本。テンプレの追加。開発進行中
    • コンパイラ作ってる方に知らせて下さい
hkataokaさん「僕とPerlとYAPCAsia」
  • 2002年正月Perlと出会った
  • モダンPerl入門Perl CPANモジュールガイド が方向性を教えてくれた
  • 2005年12月YAPCを知った
    • スカイアークシステムさんのお陰で5年越しでこれた
  • 臨場感や熱気が違う。他のPerl Mongerとのコミュニケーション
  • miyagawaさんからPlack::Middleware::ExceptionNotice のアドバイスを頂いた
  • YAPCは東京でやっていて、すごい
  • 地元も、メンバーを増やせばすごいはず
    • 地元からもすごい人が出るかも
shinpei_cmykさん「プレNiigata.pm活動報告」
  • ゆのっちunicodeで書ける - YUNOCODE と呼ぶべk(すべった
  • Hachioji.pmに出席していた
  • Niigata.pmをやりたい
    • Perlをメインで使っている会社内
    • めっちゃ少ない。学生も居ない。
    • Perl = CGIと思われている
  • NDS、技大LT
    • Perlの宣伝をして、新潟にPerlの仲間を増やしたい
  • 勉強会とかがない人は、やるといい
  • 司会「Twitterで白眼鏡が公表でした」
lapis_twさん「Perl meets C++
  • Sapporo.cppのコアメンバ
  • libperl++が動かない
  • perlembed : C言語からPerlを呼び出す方法
  • XS使用モジュールを呼ぶのは大変
    • perl_parse 周りのグルーコードが必要
    • xs_init
    • C++11のVariadicTemplatesやBoost.MPL、Boost.Preprocessor, Boost.CallTraits などが使える
1VQ9さん「Plack::Middleware::Auth::SAML2」
  • 蜘蛛の遺伝子の解析をPerlでしている
    • システム全体ではRubyPerlが半々
  • SingleSignOn → SAML
    • pingIdentity, oneloginなど
    • Perlのモジュールがなかったので、作った
  • Plack::Middleware::Auth::SAML2
    • SSOにのみ対応。SLOに未対応
    • デモ

Eikichi Gotohさん「仙台で1年間 PM をやってみた」

  • YAPC::Asia 2010 PMディスカッションに触発された
  • YAPC::Asia の出席は5回目
    • 東北の人にあったことがない
    • Twitterでも東北のperlの人を見てない
  • Sendai.pm #1 → 7名。
  • 震災で町の半分がなくなった
  • Sendai.pm #2 → 10名。
  • pm.org登録
    • Perlの話ができる場
    • 牛タン食べたいPerl Hackerはメンションを
    • 喜久福 → 仙台でしか食べれない
  • *.pmの作り方
    • charsbarさんの解説がよい
    • 英文が必要なのはサーバとメーリングリストどうするかだけ
    • 頑張って英文で問い合わせたら、ネイティブOops!をもらえた!

akiyamaさん「なぜ、高校生がPerlを使うのか?」

  • 高校生
  • Perlメイン、たまにPythonとJS
  • Hokkaido.pmの支援で出席している
  • 小学生のとき趣味でHTMLをいじっていた
  • レンタル掲示板を設置した
    • 学校の先生にも教えた
    • 広告が小学生に相応しくない! → 閉鎖 → 自分で作りたい
  • Kent Webに出会った
    • 気に入らない。自分で作りたい
  • プログラミングPerlamazonで買った(内容見ずに)
    • 厚さに仰天して読なかった → Perlに数年間触れなかった
  • 中学生になってyusukebeさんのサイトをみて衝撃を受けた
    • 大量に画像をダウンロードしてくるスクリプト
    • 楽しそう、「夢」がある
  • CPANモジュールに出会った
    • なんでもそろっている、ドキュメントがしっかりしている、SYNOPSISがいい
  • CPANの問題 → モジュールが多すぎてモジュールを選ぶのが難しい
    • CPANモジュールを読むようになった → のめり込んだ
  • Hokkaido.pm を見つける
    • 懇親会に参加するとみんなやさしい → モチベーションが上がる
    • 空気読まずに行くことが大切
  • Hokkaido.pm #5 でLT
  • @nekokakuさんから誘われてYAPCに来た
  • 単純な理由 = 行動力がある
  • なぜPerlを使うのか
    • Perlに出会ってそのまま使い続けている
    • PythonRubyもあるのに?
  • 理由1. 手軽さ
    • Plackの登場、たくさんのWebフレームワーク、plackupするだけで動く
    • 複雑なことをしなくても、先人のお陰で単純にできる
  • 理由2. コミュニティ
    • CPAN Authorへのあこがれ → 互いに支え合っているのがすごい
  • 理由3. 書きたいから
    • すべてが奇麗である必要はない。書きたくなる気持ちが大事
    • Perlハッカーへの憧れ、コミュニティへ貢献したい気持ち
  • Perlが好き
  • 質疑応答
    • Q. 小学生が買うとは非常に驚いた(らくだ本の訳者さんより*1 )
    • A. お世話になってます
    • Q. 今夢中になっているプログラミングは? (yusukebeさんより)
    • A. ニコ動のダウンロードページ。他、あるサイトの動画のダウンロード。

sartakさん「DTrace: printf debugging for seventh-level wizards」

  • 「来年日本語で話してくれるので期待!」
  • DTrace
    • コーンピュータが何をしているか知る
    • iotopで使われている
    • OS XSolarisLinuxで使える
    • プロファイラ、デバッガ、カーネルモジュール
  • XcodeのプロファイラもDTrace
  • dtruss → 全システムコールの表示
  • iotop, opensnoop, iosnoop
  • コーディングも可能 → corpusというプログラムの例
  • mod_perlのテストを失敗してた → 日本語設定していたので、「公開鍵が見つかりません」がマッチしなかった
  • DTraceの言語にはifがないので注意
  • Perlの5.14.1 以降で、DTraceで拾える項目が増えている

Kazuhiro Osawaさん「Perl Hackers Hub の舞台裏」

  • Web+DB Press の連載周りで起こったことの話
  • 伝えたいこと
    1. 苦労した話は皆聞きたい
    2. 読みたいと思うネタは読みたいと思っている
    3. 雑誌で記事を書く、スピーカーをする、なんて特別な人ではない
  • 連載での立ち位置 → 企画を思うついて、人を見つけてやってもらう
    • Twitter でWeb+DBに記事載せたい → 決まった
  • 今は亡きCodeRepos → まだあります!
  • 元々のコンセプト
    • 機構経験がないけど面白い人を持ち上げる
    • 自分が読みたい人の原稿
  • Perl Hackers Hubはバトン企画
    • AdventCalendarが面白かった
    • JPAの代表理事によるハンドリング (金銭面でトラブるので)
  • 【会場を歩き回りながらしゃべる】
    • 【ここで想定内のBコースのスライドへ】
    • 【執筆陣を片っ端から壇上へ呼び出してしゃべらせる。】
  • @inaoさん「Yappoさんが主催者です」
  • @xaicronさん「ひどいプレゼンですね」
  • @dankogaiさん「昔のYAPCは宿だったし大変だった。今のYAPCは余裕があって、iPhone4Sも変えた」
  • @nekokakさん「いい経験をした。発売されてるので見て下さい」
  • 全員別会社にする予定が、次々とDeNAとなってしまった
  • そろそろ後1分なのでm「まだkazeburoさんが!」
  • @kazeburoさん「22日発売なのでお願いします。mixiの頃1年連載して久々だった」
  • (登壇者へ拍手っ)
  • 技術系の原稿書いてみたい人は?
    • 特別なことではないので、参加してみて下さい
    • AdventCalendarにも

Lightning Talks

kiwanamiさん「Perl, Emacs and Async」
  • Rubyを書く人
  • Emacsで絵を書く
  • ぼくのかんがえたさいきょうのてきすとえでぃた
  • バックエンドは苦手
    • Perl → どこでも入っている、非同期に強い
    • Perl側はAnyEvent, Emacs側はdeferred.el
  • デモ動かず・・・
    • セッション中にデバグするのはよくあること
    • 復旧
    • echo、足し算
    • SQLの実行
深町英太郎さん「PerlCommon LispPerl
  • clackup を作った
  • Perlは駱駝、Common Lisp はカオス
  • 例えば、Plack::Builder はマクロで書くのが自然
  • PerlCommon Lispに比べると十分小さい
  • 困ったこと
    • コアで入っていないと、積極的に使わない
    • Modern Perl → "最新のModern Perl"
    • おうのが大変
  • 時間があるので京都の話
    • 住みやすい
    • (ゴーン、時間切れ)
株式会社ガイアックスさん「Sponcered Session」
  • 福岡のお国自慢の話
  • 日本の西海岸
  • 「祭」
  • 電車が混んでない → Perl Hackerはラッシュを避けるから関係ない
  • 家賃が安い
  • 以外と都会
  • 車で30分行けば海も山も
  • 世界で住みやすい都市14位
  • Fukuoka.pmは開催数が多い
  • エンジニアにとって最高の町
    • 現在は東京だけど、福岡に開発拠点を作りたい
    • 立ち上げてくれる人募集
azuma kuniyukiさん「bounceHammerその後、導入、これから」
  • bounceHammerとは
    • Perlで書かれている
    • 戻ってくるメールの解析のみ行うツール
  • 去年のYAPCで発表する予定だった
    • ケーブルを忘れた
    • 猫神様に救っていただいた
    • 今年はJPA会長のPCを借りた
  • SMTPのSはSimpletonのS
  • ケーススタディ : @type。40万通/日。「私の年収低すぎ」で有名
  • 来月、新バージョンをリリース
  • (ここでマイク交換)
  • 将来 : Coro使ったりPlack対応したり
  • 続きは大阪で話します。関西オープンソース2011
株式会社ライブドアさん「ロケタッチ」
  • 半分以上の人がYAPC::Asia 2011へタッチしているようだ
  • タッチするとシールがもらえる
  • ロケタッチ
    • Perlで書かれたアプリ
    • チェックインができるアプリ
    • カジュアルに使えるライフログツール
  • ロケタッチAPI
    • ロケタッチ Developers
    • OAuth2で認証
    • 基本機能をほぼ網羅
    • サンプルコードも公開予定
  • 大カテゴリ、小カテゴリによる分類
  • API Explorer を使って、色々ブラウザから試せる
  • わからないことはfacebookで質問
  • MASHUP AWARDSにもAPIを提供している
Yappoさん「folkatdevs」
  • 昨日のIkachanの詳しい人ははてなの人に聞いて下さい
  • 開発環境の整え方
  • IRCに片っ端から入って情報収集
    • gyazoサーバはあったけど、専用Macクライアントがない
    • Win版を作った
  • ikachanをベースに通知ツールの整備
  • ちょっとしたツールで、大きな改善
  • 非エンジニア向けの改修など
  • 小さなツールを作る
Naoki Tomitaさん「This session is funny modules」
  • CPAN毎日チェックしている人は暇な人
    • Tomitaさんは毎日見ている
  • akefile → -Makefile=PL できるように
  • AAAAAAAAA
  • Moose → Mouse → Moo → Mo → M
    • 何もしてない
  • Sakai::Nakamura → SakaiのNakamuraバージョン
  • Devel::Comments
    • 熊 全熊に捧ぐ
tokuhiromさん「File::Zglob」
  • lib/**/*.pm
    • File::Find がめんどくさい
    • File::Find::Rule perldoc みないと書けない
  • File::Zglob
    • zglob('lib/**/*.pm') と書ける
  • 時間があるのでmore 20 modules
  • FCGI::Client
  • DBIx::Inspector → DBIのものより使いやすい
  • Daiku → Rake for Perl
  • App::watcher → アップデートされたらなんか実行する
  • autobox::Encode → "ほげ"->encode("cp932")
  • cpan-outdated → とにかく新しいモジュールを使う。cpanmに渡せる
  • Cache::KyotoTycoon → クライアント
  • Furl → 去年のLTのせいか物。モバゲーで使われている。
  • ・・・(ゴーン、時間切れ)
ミクシィさん「たんぽぽチームリーダー」
  • 静的解析
    • コードレビュー自動化、ソフトウェアの検査
    • 技術的夫妻の防止
  • 計測できない者は改善できない
    • 分岐、ループなど関数をグラフ構造として捉えて、その複雑さを測定
    • 差分が極端に多いモジュールを調べる → 王様モジュール
    • より多くと依存されているコンポーネント
  • inspect-package → 解析を行う
  • 働きたい人が居たら、話しかけて下さい
Kenichi Ishigakiさん「Top Ten 2011」
  • cpants.perl.org → いろいろあってとまってる
    • cpants.charsbar.orgをたてた
    • DBIC のwarningsが
    • アンオフィシャルな記録で
  • 全日本最強CPANAuthor選手権2011
    • 10位 KAZEBURO さん
    • 9位 LUSHE さん
    • 8位 Takeshi Miki さん
    • 7位 TYPESTER さん
    • 6位 CHIBA さん
    • 5位 TOMITA さん
    • 4位 SATOH さん
    • 3位 MORIYA さん
    • 2位 BAYASHI さん
    • 1位 XAICRON さん
  • acme.cpanauthors.org → 様々な角度で分析
    • 日本が多い
    • モジュール率だとイギリス
  • 1年間で40個以上モジュール更新されている方もいる
kamipoさん「MySQLでMessagePackの中身を検索」
  • msgpackはjsonよりちょっと速い
    • 空間効率も良い
    • 人間が読めない
    • MySQLに突っ込むと検索しにくい
  • MySQL上でのjsonの検索はkazuhoさんが作った
  • messagePack用のmsgpack_getを作った → デモ
YUSUKEBEさん「ぼくのかんがえたさいきょうのえろさいとの舞台裏」
  • 一時はてブのトップに乗ったエロサイト
  • ver1 → 12万PV
  • 負荷軽減 → staticファイルをAppserverでサーブしていた
    • Front-endへ
    • キャッシュ
  • ver2 → UI刷新、埋め込み再生、関連動画表示
    • 複数サイトに対応
  • 関連辞書をモジュール化 → Acme::Porn::JP
  • 15PV/1user
  • ver3 → Mojolicious + DBIx::Skinny
  • とにかくキャッシュする構成 → 3倍速くなった
  • 20PV/1user
TAKESAKOさん「Perlで無理ゲー攻略2」
makamakaさんによる割込

カードゲーム6セットの抽選!

Hideo Kimura「Managing A Band Of Hackers」

  • POSIX timeで計算できる
  • ISP → 独立 → Server hosting → DeNA
  • マネージャーとして、将来の姿のお話
  • マネージャーが必要なのは?
    • 規模の限界がある → 集団でWEBサービスを作るのはすごいこと
    • 集団の場合は、指揮者が必要
    • 1+1を2より大きくする (Aristotleの言葉より)
  • Perlは歴史が長いので、マネージャーをやっている人は増えている
  • マネージャーの仕事 → プロジェクトマネージメント、人事、その他
  • プロダクトマネージメント → ライフサイクルの維持
    • 期間やリソースを確認する
    • 進捗を管理
    • システムを健全に動かす
    • タスクを見積もる必要がある
  • 人事
    • 面接、評価 → エンジニアの能力を見抜く必要がある。
  • その他 ≒ 事務
    • 稟議などはしんどい。最近ヘルプチームはできて楽になった
    • 会議 → 必要。メールや電話会議では話が伝わりにくい。ホワイトボードを前にすると数分で終わる
    • 無駄な会議はある
  • プロジェクトマネージメントや人事には、エンジニアの経験が必要
  • 始めは1人、今のチームは20人
    • 6人CPANAuthor → CPAN Author率が一番高い
    • DeNAYAPCに登壇した9人中、7人がこのチームのメンバー
  • ハッカーのマネージャーは、少し特殊
    • 一人だと寂しくて死んでしまう → 声を上げても1人だと声が弱い
    • 飽きっぽい。運用を誰かに押し付ける → 餌を与え続ける「変えていいよ」
    • 優先度<興味 → さらにレベルが高いと、興味があるものをやりたいがために今のことを早く終わらせるので、大丈夫
    • 朝遅く夜遅い → 相談したいときにいつ来るかわからない
    • KY → 仕事には影響しないから、まあいい
  • どうマネージメントするか
    • 「任せる」 → 10人以上のチームになったところで、コードを書くのをやめた
    • サービスの作成に専念できる
    • 人が成長する
    • 任せると丸投げは違う。失敗をリカバリするプランまで見越しておく
  • 悪いニュースは、先に
  • TMTOWTDI → 多様性を許容する
  • 「Being Geek」O REILLY' → マネージャーになる上でいい本
  • マネージャーは優秀なエンジニアがなるべき
    • 選択肢として、マネージャーを考えて欲しい
    • マネージャーが少ない会社は少ない
  • I ♡ PERL
    • エンジニアとして成長できる
    • マネージャーとなれば人脈と鳴る
    • 若い人には、積極的にコミュニティに参加して欲しい
  • (テキーラで〆)

牧さん「Closing」

  • 結果発表!
    • 3位 徳丸 浩さん「Webアプリでパスワード保護はどこまでやればいいか」
    • (未カウント)闇のEmail伝説、Carton、Perl 5.16 and beyond
    • 2位 TAKESAKOさん「Perlで無理ゲーム攻略」
    • 1位 FUJIWARA Shunichiroさん「Perlで構築された中規模サイトのDC引っ越し記録」
  • 抽選 → 1369
  • 記録破りのYAPC
    • 30社 (前は20社最高)
    • スタッフ42人 (前は30人以下)
    • トーク71 (前は40~50)
    • 個人スポンサー91名
    • 672(去年は518)
  • 今年のテーマは進化
  • よかった偶然
    • スペシャルゲストが揃った
    • 941さん
    • スタッフ
  • 来年はどうする? → 来年はどうなるのか不明
    • やってみたい人は連絡を
    • ブログを書くまでがYAPCです!
    • See you next time!