とは言え、2日目のみの参加でした。1日目も出たかったなー。
個人スポンサーにもなってんだから、せめて懇親会くらい行きたいなーと思ってたんだけどね。夜に会議入っちゃったから、諦めた。
1日目後
Twitterで眺めてたら、PerlDojoとかいう面白いことをやっていたので、参加。
gfxさんの問題に回答おかしくないですか？と質問したら、自分が問題読んでないことが発覚。すみませんでした m(__)m
と言われたので、perldojo を fork。
動作確認してから、pull request したかったので、Arkのインストールから、依存モジュールをいれていると…
…Perl 5.12以降でしか動かないことが発覚。
がーん。
で、仕方ないので、Perl 5.14系のコンパイル、依存モジュールのインストールなどなどしているうちに、結構な深夜に。
なんか眠れないし、1日目行けなかったのを、問題作ることで参加した気分になるメソッドを実施してみた。
言われた分のpurll requestと、問題を5件くらい(？)。今のところ採用されたのは、3件かな。
で、あんまり知らないだろうというところで攻めて見たら、15日時点で難問ランキング1位でした。良かった(何が
残りは、レビューされて止まっています。深夜クオリティでごめんなさいって感じです。 m(__)m
しかし、選択問題にしようと思うと、なかなか難しいなーと思いました。
というわけで、残念な一日目でしたが、録画が公開されたら気になるトークでも見ようと思います。
2日目
そんなわけで、pull request する前に没にした問題なんかもあって、6時くらいまで起きてた。その後、いつの間にか寝てて、起きたら8:40くらい。
kazuhoさんのトークを聞きたかったので、助かったーと思い、支度を整えて、YAPCへGo!
続 Unix Programming with Perl by id:kazuho
UNIXでプログラミングする上での勘所の解説。
パイプにもサイズがあるとか、セキュリティ的に、open '|-'な呼び出しじゃなくて、IPC::Open3を使いなさいとかそういったお話。
最後の方に、プロセスを止めるSIGNALを受けるタイミングの話があって、こないだ実装した状況と似ているなーと思った。
ログを監視して怪しげな文字列を見つけたら何かするてのを書きましたが、これは、forkを使って、File::Tailで、別プロセスでファイルを読み込み続け、怪し気な文字列を引っ掛けてなにかするっていうものです。
ログファイルはローテートされるので、renameされたらファイルを読みなおしてもらわないと困る。だが、そのプロセスはファイルを読み続けているわけなので、他のこと出来ない。ので、ALRMで一定時間で割り込んで、そのALRM処理の最後に、また、ALRMを仕込むとかいうことをしていた。
って、別プロセスで監視して子プロセスにHUPでも投げて、そこで、読み直させればいいんじゃないか…(ぉぃ
…ま、まぁ、それはおいておいて、参考になるお話でした。
大規模環境における、マニアックなキャッシュ利用術 (Cache Maniacs) by id:xaicron
memcachedのキャッシュの生成は戻り値をチェックして、リトライすべきとか、キャッシュをワーカーで作るとか。
DNSのキャッシュをどうするかとか、キャッシュに関するマニアックな話。
すごいいい話だったと思います。
でも、この手の話は、相当な大規模環境でしかあんまり関係ない話なので、聞いてる人がそれを実装することはあんまりないんだろうなぁ。僕も含めて。
ぼくがかんがえたさいきょうのうぇぶあぷりけーしょんふれーむわーく by id:cho45
薄いフレームワーク。安全側に倒す。安全じゃないところは面倒臭くさせる。
フレームワークっていうのは、究極に薄くすると、設計指針だ、という話。
今、ちょうどAmon2を拡張してWAF作ってるところなので、参考になりました。
ちょっと反論があるとすれば、「コストがかかることを便利にしてはいけない」というところかなぁ。
これは、規模にもよるんですが、例えば、CPUすかすかのサービスで、そこまで伸びるようなサイトでもないとします。
そのようなサイトに生DBIで書いて、開発コストを上げるよりも、ORマッパーでシステムのコスト(負荷)を上げて、開発コストを少なくしたほうが良いという判断は蟻だと思う。まぁ、これは、観点の問題で、
コスト=開発コスト(お金)であれば、 「コストがかかることを便利にすべきだ」
コスト=システムコスト(負荷)であれば、「コストがかかることを便利にしてはいけない」
となる。いずれかを選択するかは、ケースバイケースだと思います。でも全体に納得できるお話でした。
※システムコストもサーバ台数などにも関係するので、それもお金っちゃお金ですが、そこは開発人員とか、納期とか、サービスの規模とか色々な要素が絡むところではあります。
watch your log by id:nekokak
ログ監視の重要性のお話でした。開発者と運用者のコミュニケーションは大事だと。まぁ...うちは別れてないから「好き勝手しても大丈夫」な部類なんですけども。それでも、ある程度のドキュメントは必要だと思います。ていうか、自分が明日急に働けなくなるとか死んじゃうとかいう可能性を考慮すると、最低限のことは、どっかに記しとかないといけないなぁ、と前から思ってる(いや、足りてないですけど、全然)。
そして、ログ監視フレームワークKomainuというのを作っているそうです。
ちょっと画像なんかがなかったので、いまいちイメージ付かなかったんだけども、notifyやグラフ化とかできそうな感じです。
相当数の台数で実運用しているということなので、ちょっと興味があります。
闇のEメール伝説 by rjbs
Email::関係の作者rjbsのお話。
とりあえず、Emailに関する仕様はクソだ！ということを連呼していた。
クソっていうか、なんというか、あんなん実装しろとか言われたら、逃げたいなーと思いましたw
ありがとうございます。
でも、ぶっちゃけ、送るのだけでも結構メンドクサイ気がします。僕はラッピングして使ってますけども…。
Evolution of API With Blogging by Takatsugu Shigeta
タイトル通りの、BlogとAPIの進化の歴史についてのお話。
なぜ、高校生がPerlを使うのか？
若い人が頑張ってるのはイイなーと思った。もう僕はおっさんか。ていうか、発表者の秋山さんとは、ぎりぎりダブルスコアじゃない年齢差w
僕が大学の頃にやった道を小学生からやってる辺り時代が違いますね!
小学生で掲示板をつくろうとして、プログラミングPerlを買って、諦めたらしいw
小学生にあの本は厳しすぎると思う。その後、とある情熱(yusukebeさんが感動していた)で勉強しはじめたらしい。
僕が小学校のころといえば、N88-Basicで、中学校はやらなかったけど、高校もまだBasicやってた。あとは、Excelのマクロくらいか。
大学で趣味で掲示板作るのに、Perl始めたって言う感じ。
是非、頑張っていただきたいと思います。
DTrace: printf debugging for seventh-level wizards by sartak
dtraceで、デバッグするという話。寝不足がきわまりだしたのと、英語で結構寝てしまってた。
たまに、strace でデバッグするときはあるけど、dtraceは出力を柔軟に変更できるということで良いんだろうか。
http://yapcasia.org/2011/talk/45:titel=Perlで仮想サーバ制御
福岡はRuby押しっていうのが分かった。要件にRubyでって入るのかー。悲しいですね。
Sys::Virtていうのがあるらしいので、ちょっと見てみようかなぁ。
LT
YAPCがLisperに侵されていた。もっとやれば良いと思うw
いずれも面白かったです。Yappoさんの話が非常に良かったと思います。
竹迫さんが相変わらずすごい。安定している。
Managing A Band Of Hackers by id:hidek
マネージメントの話。為になりました。
マネージャーがなぜいるか
1 + 1 = 2 だったら、マネージャーなんかいらない。組織として人を動かして、より大きな成果をだすためにいる。
マネージャーの仕事
1. プロジェクトマネージメント
計画->開発->運用のプロジェクトのライフサイクルを維持する。
マネージャーは開発の経験者であるべき。もし違ったら月曜にでもやめたほうがいいとまで言ってました。
広い知識も必要。
2. 人事
採用の面接とか。これもエンジニアじゃないと判断できないよねっていう話。
採用したら、仕事を与える。どんなスキルを持っているのかを把握する。何がしたいのかを把握する。
コミュニケーション力は重要。
評価もしないといけない。
3. その他
事務仕事はめんどくさいけど、粛々とやるべき。
僕も嫌いだけど、メンドクサイことは引き受けて、開発者に開発に集中してもらうのは筋だと思う。
会議なども多くなる。無駄な会議もあるけど、面と向かって話すことで話がすすみやすいこともある。
ハッカーを率いる
- ハッカーを一人にすると死んじゃうらしい
- とんがってるので、衝突することもあるから、仲間が必要
- 飽きやすい
- プライオリティ < 興味
- 興味をもったことをするために、プライオリティの高い仕事を意欲的に片付ける
ていうか、hidekさんのチームのろけ話のようでした。
マネージャで重要なこと
- コードを書かない
- プロダクトを持っちゃうとそっちに集中しちゃって、マネージメントがおろそかになる
- 任せる
- 信頼して任せる。丸投げ肌目
- 悪いニュースは最初に
- 後から悪いニュースを言われてもどうしようもない
- TMTOWTDI
で、エンジニアリングのマネージャーはエンジニアでないと務まらない。
だから、そういうキャリアパスもあるということを頭に入れておいて。
ということだそうです。
また、YAPCやコミュニティなどで培った人間関係はとても大切とのことでした。
おすすめ書籍
Beeing Geek という本がおすすめらしい。買ったら良かった。
クロージング
牧さんによるクロージング。今年のYAPCは過去最大規模(客、スポンサー、スタッフ、トークの応募など)だったらしく、大成功ということでした。
941さんと牧さんがうまく回ってるんでしょうか。なんかいい感じでした。
後夜祭
一番端っこの方で、最年少の秋山さんを囲んでお話してました。名刺は全然交換できなかった。
まぁ、いいか(会社の人に怒られそうだけど)。
perlmonカードゲーム朝に買っておけば良かった。なんか、飲み会の最後の方に、まかまかさんと冨田さんがやってたのを見てると、楽しそうだったw
最後に
来年…は、本当にわかんないよ？というお話でしたが、是非頑張っていただきたいなーと思います。
うちの会社はお金を出すくらいしかないけど。
個人的には翻訳とかなら手伝いますけど、charsbarさんのクオリティが高いから気が引けるのはある。スライドの翻訳は難しい。
牧さん、941さん、スタッフの皆様方、本当にありがとうございました! m(__)m
