先に感想を書くと、YAPCで喋れる人って皆、大企業や有名企業の看板がなくても個人で通用する人ばっかりやなぁって印象です。
前夜祭が終わって宿に帰った後に、いつもお世話になってるお客さんのサーバでアクセス過多の問題が発生して明け方頃までチューニング大会となり、起きたら10:00やったのでオープニングには間に合いませんでした。 以下、拝聴したセッションと簡単な感想。主にインフラ系とか運用系の話を聞いてきました。
一日目: 10/14(金)
Perl 5.16 and beyond
 |
| 宿に帰る道中見かけた居酒屋の看板娘 |
- ``Rule 1: Larry is always right about how Perl should behave (Perlのあるべき姿については常にラリーが正しい)'',
- ``Rule 2: Larry is allowed to change his mid about any matter at a later date regardless of whether he previously invoked rule 1 (自分で決めたことかどうかによらずラリーは後から考えを変えても構わない)'',
- ``Since switch to git, we've nearly doubled our committer list (gitに移行してからコミッタは倍増)''
Perl 5.16以降のヴィジョン、よりスリムでシンプルしていく感じです。
CPANモジュールガイド編集後記＋α
 |
| 著者トミールさんの発表 |
Perlをちゃ〜んと勉強しだしてまもなく3年になりますが、まだまだPerlをよく分かっていないので、この本は必須かなと思っていたところです。
お昼にこの本を買ったので午後のセッションで編集後記を聞いて、著者のトミールさんにサインを貰ってきました。知らないモジュールが多くてなかなか勉強になる一冊です。
正誤表はhttp://cpanbook.koneta.org/sorryにあります。
A Language for getting the job done
編集後記から連続して始まったのでそのまま拝聴しました。Perlの話は出てこない。本題は``Paid vs. Free''. Steve Jobsの講演に出てきた「点と点を繋いでみる」がキーワード、オープンソースとビジネスを考えるセッションでした。僕自身「オープンソースは金になるのか？」の答えが明確でないので、以下思いつきとメモ書きを箇条書き。- それぞれのオープンソースは点
- 重要なのはデータ、データが金を作る
- 点の一個を公開するのはそんなに心配しなくてもいい
- 点と点を繋いでサービスになったり、プロダクトになったり、ソリューションになったり
- アイデアもまた点の一つである
- 点と点を繋いで平面が出来て、それを膨らませて立体になって、ビジネスになる
- 平面のままでは需要の無いプロダクト・サービス←あんまり流行らないOR直ぐに廃れる
- 立体になるとビジネスとして成立して利益も出る
- 立体にするにはアイデアという点、タイミングという点が重要
- 点の組み合わせ方は多種多様、アイデアも点なら無限大の組み合わせパターンかも
- コードは公開・サポートは有料というビジネスモデルは高々2,3個の点を繋ぐ程度のもの
- 自分で点を作ったり、既存の点を組み合わせて新しい点を作ったりしながら立体に近づける
他のセッションは実用的な側面が強い一方で、このセッションは哲学に相当するセッションかなって感じです。
AnyEvent, Coro, IO::AIO - a good team
 |
| Marc Lehmann先生の講演 |
``I think, Coro is the only real threads.'' 実際にCoro, AnyEvent, IO::AIOのどれも使ったことがないから、YAPC来る前に練習でコード書いておけば良かったかなぁと反省。Coro::Channelはコロちゃんって聞こえた。
Perlで構築された中規模サイトのDC引っ越し記録
約20台のサーバで構成されるサイトの移転とリファクタリングを同時に行った話。移転だけでなく性能改善をあれこれやりながら、移転途中はVPNで通信経路を確保するなどして、3時間の計画停止一回で移転できたという貴重な事例紹介。かつてデータセンターでデスマーチを経験した身としては、華麗に移転できたのをうらやましく思います。アプリケーション部分の移転が前日に終わってるのに、計画停止した後にしかユーザからクレームが来なかったというユーザ心理についての話しも面白い。
Mobage オープンプラットフォームの事件簿
モバゲーのとあるAPIにまつわる事件簿、MySQLの話。DELETEは遅いからSTOP SLAVEした奴から必要なデータだけとりだしてMasterやってもらう「おかわり作戦」、柔軟な発想。事件簿3の有名人問題はモバゲーに限らず昨今のソーシャルなアプリ・サイトなら必ず直面するであろう問題。Mobageソーシャルゲームにおける大規模サーバ運用 with Perl
連続でモバゲーの話。これだけ大規模な環境の話はそうそう聞けるものではないから貴重。スライドの構成図が結構詳細に書いてるから、YouTubeで音声流しながら改めてスライドを眺めるとより理解しやすいです。DNSをmyDNSにしてラウンドロビンをアプリケーションに組み込んだって聞いたけど、DNSクエリー数のグラフが気になるというか見てみたい。内部の名前解決専用DNSの台数とか性能とかレコード数とか環境依存の部分はわからんけど、アプリケーションサーバ全てがMyDNSから取り出したデータをもつキャッシュDNSになってるって事かな。
懇親会
TwitterやFacebookでお世話になってる方や久しぶりにお会いした方ににご挨拶できて有意義な懇親会でした。今年の懇親会はスポンサー企業さんの計らいで無料でした。ビールも食事も美味しく頂きました、ごちそうさまでした。二日目: 10/15(土)
続 Unix Programming with Perl
UNIXで動くプログラムを書くには、このセッション(と去年のセッション)での知識は必要、というか基本ということで拝聴してきました。IPC::Open3, Pipeのバッファサイズ(これはOS毎の違いは知らんかった)、シグナル、Race Conditionとかの話。Race Conditionはローカルユーザがroot権限を奪取したり、外部からRace Conditionを利用して攻撃するプログラムを置いたりするって話で必ず出てきます。かつてUNIXに複数のユーザがログインしていて、そういった攻撃(あるいは攻略)について考えたり対処したりする必要がありましたが、今は寧ろサイトに設置したプログラムが意図せず攻撃してしもたり、脆弱性を作り出してしまったりという側面が強いかな。
運用しやすいWebアプリケーションの構築方法
テーマは「障害耐性」です。アプリケーション運用後の障害などで重要になってくるログを記録するためにLog::Minimal、ORMはDBのデバッグ時にコードからSQLがわからんから、コメントの形式でSQLが残るDBIx::Sunny, DBの接続状態管理の為にScope::Container, memcachedの問題(データの永続性、特定キャッシュへの集中など)を解決するためのCache::Memcached::IronPlate.開発期間・工数を短縮するのは重要とは言え、設計がやっつけ仕事やったら後々の障害対応で手も足も出なくなりそう、そして結局通常運用の状態を維持するのに開発期間や工数が肥大する。障害耐性を考慮した設計大事。
watch your log
 |
| nekokakさん |
サーバ・ネットワークの監視は択さんの監視項目があれば在るほどよいし、記録が多ければ謎の障害が発生しても原因を特定する道筋は立てられるはず。
障害に特化したDev側とOps側のCommunicationにおいて、それぞれがすりあわせたフォーマットのログが潤滑油となり、障害の一時対応が迅速に行える。
Nagiosの監視通知は瞬間を切り取ったものやし、MRTGとかのグラフは要約されたデータやから、それらの変化が何故起こったかを追求するにはログを読む必要があるので、ログ監視も侮るべからず、という感想です。
闇のEメール伝説 (Email Hates the Living!)
 |
| Ricardo Signesさんによる闇のEメール伝説 |
古代のプロトコルSMTPの闇、開発しているbounceHammerで一番苦労しているのが無数にあるバウンスメールのフォーマットに対応する点なので、共感できるというか、Recardoさんの気持ちがよくわかるセッションでした。
そして.af, .krとかスライドのメールアドレスにちょいちょいネタが仕込んであったのも面白い。Webに比べてメールが人気ないように見えるのは、こういった複雑さも寄与しているのかなぁと思ったり。``SMTP is Simpleton Mail Transfer Protocol''.
RFCで定義されているように、どこにでも無節操に入れられるコメントと、そこから正しいメールアドレスを取り出す処理はEmail::Addressあたりを使うのが最も最適解やと思います。
Hello Embed Perl!
Perlインタプリタをいろんなものに埋め込むって話。CのプログラムにPerlインタプリタを埋め込んだり、CのコードからPerl呼び出したり。bounceHammer実装する時に「サーバで動かすプログラムやし処理速度を考えるとCで書いた方がいいかな」って思ったけど、パターンマッチの正規表現を考えるとPerlって結論になりました。そもそもCは久しく書いていないから慣れていないCとPerlはきっと困難が待ち受けてるやろうって思いましたし。
このセッションではPerlと同様やり方はいっぱいある(TIMTOWDI)し、難しくないからやってみるといいよ！って感じのメッセージを受け取りました。セッション終わって自分のLTスライド作るのに直ぐに退室したけど、node-perlってなんやろ?
Perlで仮想サーバ制御
ここ数年でユーザ数ががばっと増えた仮想環境をPerlで制御するって話。仮想環境はユーザサイドからはVPSと呼ばれているけど、裏側を見ればXen, KVM, VMWare, VirtualBoxとかいろいろ。そう言った仮想環境の共通ライブラリlibvirtを制御する為のPerlモジュールSys::Virt(libvirtのバージョン依存), Beccoameってのを作ったけど大人の事情(いわゆるOSI参照モデルの政治層かな)でお蔵入り。時には理不尽とも思える政治層での問題って、エンジニアサイドから見るとなかなかよい解決策が見つからないっていうか、寧ろ政治層に影響力を持っているエンジニアになるべきかなぁと思ったり。
自分のLT
 |
| 猫神さま |
今年はちゃ〜んとVGAケーブルも持ってきて、出力もKansai.pm 13thと出発前のCRT接続で確認してきたのですが、接続テストで映りませんでした(´ヘ｀；
...結局今年も人様のMacを借りて発表しました。今年はJPA理事長(会長?)がMacを貸してくださいました、助かりました、ありがとうございました、お世話になりました。
 |
| JPA理事長さま |
YAPCの為に東京に着いた日にうちのMac(PowerBook G4)でDisk IO Errorが頻発するようになって、日本語変換を呼ぶ度にカーソルがぐるぐる廻ってどうしようもないので、スライドの殆どは英語というか英単語で書かざるを得ませんでした。
0 件のコメント:
コメントを投稿