あいにくの雨ですが、今日も時間通り会場に到着しています。
本日も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が重いとき
- ORMを使うときの注意
- SQLの生成個所が散らばらないようにする → 特にViewで生成しない
- クエリコメントを加える
- DBIx::Sunny → DBIのサブクラス。caller情報をSQLコメントへ埋め込む
- 他、select_oneやselect_rowなど、便利なショートカット
- SQL::Makerとの組み合わせなど
- DBIの接続をキャッシュすると、接続時間が長くなる
- Scope::Container でDB接続管理をする
- local と似たような機能。処理単位で接続を切るようにする
- Scope::Container::DBI
- 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
- Devに依頼ができるOps
- アーキテクチャ、対応すべき問題を理解する。
- 必要な情報はDevに提出させる
- DevとOpsのコミュニケーションに関して作ったモジュールのお話
- 監視
- 死活監視、リソース監視、ログ監視
- ログ監視のソリューションでいいソリューションがないのではないか
- DevとOpsは、ログの出力方法を取り決めるべき
- Opsの一時対応が早くなる → WEB+DBのkazeburoさんの記事を参考
- 監視すべきログ
- 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回サーバを巡回して結果通知したい
- 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コンパイラ用テストスイート自動生成システム」
hkataokaさん「僕とPerlとYAPCAsia」
Eikichi Gotohさん「仙台で1年間 PM をやってみた」
akiyamaさん「なぜ、高校生がPerlを使うのか？」
- 高校生
- Perlメイン、たまにPythonとJS
- Hokkaido.pmの支援で出席している
- 小学生のとき趣味でHTMLをいじっていた
- レンタル掲示板を設置した
- 学校の先生にも教えた
- 広告が小学生に相応しくない! → 閉鎖 → 自分で作りたい
- Kent Webに出会った
- 気に入らない。自分で作りたい
- プログラミングPerlをamazonで買った(内容見ずに)
- 厚さに仰天して読なかった → Perlに数年間触れなかった
- 中学生になってyusukebeさんのサイトをみて衝撃を受けた
- 大量に画像をダウンロードしてくるスクリプト
- 楽しそう、「夢」がある
- CPANモジュールに出会った
- なんでもそろっている、ドキュメントがしっかりしている、SYNOPSISがいい
- CPANの問題 → モジュールが多すぎてモジュールを選ぶのが難しい
- CPANモジュールを読むようになった → のめり込んだ
- Hokkaido.pm を見つける
- 懇親会に参加するとみんなやさしい → モチベーションが上がる
- 空気読まずに行くことが大切
- Hokkaido.pm #5 でLT
- Twitter での反応が嬉しい
- @nekokakuさんから誘われてYAPCに来た
- 単純な理由 = 行動力がある
- なぜPerlを使うのか
- 理由1. 手軽さ
- Plackの登場、たくさんのWebフレームワーク、plackupするだけで動く
- 複雑なことをしなくても、先人のお陰で単純にできる
- 理由2. コミュニティ
- CPAN Authorへのあこがれ → 互いに支え合っているのがすごい
- 理由3. 書きたいから
- Perlが好き
- 質疑応答
- Q. 小学生が買うとは非常に驚いた(らくだ本の訳者さんより*1 )
- A. お世話になってます
- Q. 今夢中になっているプログラミングは？ (yusukebeさんより)
- A. ニコ動のダウンロードページ。他、あるサイトの動画のダウンロード。
sartakさん「DTrace: printf debugging for seventh-level wizards」
Kazuhiro Osawaさん「Perl Hackers Hub の舞台裏」
- Web+DB Press の連載周りで起こったことの話
- 伝えたいこと
- 苦労した話は皆聞きたい
- 読みたいと思うネタは読みたいと思っている
- 雑誌で記事を書く、スピーカーをする、なんて特別な人ではない
- 連載での立ち位置 → 企画を思うついて、人を見つけてやってもらう
- 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
深町英太郎さん「Perl → Common Lisp → Perl」
- clackup を作った
- Perlは駱駝、Common Lisp はカオス
- マクロによってコンパイル時に変換
- 例えば、Plack::Builder はマクロで書くのが自然
- PerlはCommon Lispに比べると十分小さい
- 困ったこと
- 時間があるので京都の話
- 住みやすい
- (ゴーン、時間切れ)
株式会社ガイアックスさん「Sponcered Session」
- 福岡のお国自慢の話
- 日本の西海岸
- 「祭」
- 電車が混んでない → Perl Hackerはラッシュを避けるから関係ない
- 家賃が安い
- 以外と都会
- 車で30分行けば海も山も
- 世界で住みやすい都市14位
- Fukuoka.pmは開催数が多い
- エンジニアにとって最高の町
- 現在は東京だけど、福岡に開発拠点を作りたい
- 立ち上げてくれる人募集
azuma kuniyukiさん「bounceHammerその後、導入、これから」
株式会社ライブドアさん「ロケタッチ」
Yappoさん「folkatdevs」
Naoki Tomitaさん「This session is funny modules」
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の中身を検索」
YUSUKEBEさん「ぼくのかんがえたさいきょうのえろさいとの舞台裏」
- 一時はてブのトップに乗ったエロサイト
- ver1 → 12万PV
- 負荷軽減 → staticファイルをAppserverでサーブしていた
- Front-endへ
- キャッシュ
- ver2 → UI刷新、埋め込み再生、関連動画表示
- 複数サイトに対応
- 関連辞書をモジュール化 → Acme::Porn::JP
- 15PV/1user
- ver3 → Mojolicious + DBIx::Skinny
- とにかくキャッシュする構成 → 3倍速くなった
- 20PV/1user
makamakaさんによる割込
カードゲーム6セットの抽選！
Hideo Kimura「Managing A Band Of Hackers」
- POSIX timeで計算できる
- ISP → 独立 → Server hosting → DeNA
- マネージャーとして、将来の姿のお話
- マネージャーが必要なのは？
- 規模の限界がある → 集団でWEBサービスを作るのはすごいこと
- 集団の場合は、指揮者が必要
- 1+1を2より大きくする (Aristotleの言葉より)
- Perlは歴史が長いので、マネージャーをやっている人は増えている
- マネージャーの仕事 → プロジェクトマネージメント、人事、その他
- プロダクトマネージメント → ライフサイクルの維持
- 期間やリソースを確認する
- 進捗を管理
- システムを健全に動かす
- タスクを見積もる必要がある
- 人事
- 面接、評価 → エンジニアの能力を見抜く必要がある。
- その他 ≒ 事務
- 稟議などはしんどい。最近ヘルプチームはできて楽になった
- 会議 → 必要。メールや電話会議では話が伝わりにくい。ホワイトボードを前にすると数分で終わる
- 無駄な会議はある
- プロジェクトマネージメントや人事には、エンジニアの経験が必要
- 始めは1人、今のチームは20人
- ハッカーのマネージャーは、少し特殊
- 一人だと寂しくて死んでしまう → 声を上げても1人だと声が弱い
- 飽きっぽい。運用を誰かに押し付ける → 餌を与え続ける「変えていいよ」
- 優先度＜興味 → さらにレベルが高いと、興味があるものをやりたいがために今のことを早く終わらせるので、大丈夫
- 朝遅く夜遅い → 相談したいときにいつ来るかわからない
- KY → 仕事には影響しないから、まあいい
- どうマネージメントするか
- 「任せる」 → 10人以上のチームになったところで、コードを書くのをやめた
- サービスの作成に専念できる
- 人が成長する
- 任せると丸投げは違う。失敗をリカバリするプランまで見越しておく
- 悪いニュースは、先に
- TMTOWTDI → 多様性を許容する
- 「Being Geek」O REILLY' → マネージャーになる上でいい本
- マネージャーは優秀なエンジニアがなるべき
- 選択肢として、マネージャーを考えて欲しい
- マネージャーが少ない会社は少ない
- I ♡ PERL
- エンジニアとして成長できる
- マネージャーとなれば人脈と鳴る
- 若い人には、積極的にコミュニティに参加して欲しい
- (テキーラで〆)
