YAPC::ASIA 2012 1日目に逝ってきた(感想のみ) #yapcasia

聞いたセッションの内容とか詳しい事はほかの人が書いちゃうだろうから、見てきたセッションとその感想とか覚書とか。
LTソンは全く見てません。録画配信期待。

What Does Your Code Smell Like ?(Larry Wall)

Perlのお父さんの貴重講演。でも英語で良くわからなかった。
Perlの父と同じフロアにいたと思うとヴォオースゲーって感じでした。


ライブコーディングでPerl5のコードをPerl6で動作するように書き換えるような内容だった。
viの補完が意味わからないほど早かった。僕の知ってるviと違う。
Perl6は色々省略できたり、オブジェクトっぽく扱えたりして良い感じだけど、その分いくつか構文とか予約語が増えちゃうのが...という感じ。

Web::Security beyond HTML5(Yosuke HASEGAWA)

はせがわようすけ氏のPerlHTML5にはほとんど関係ないセキュリティに関するセッション。
XSSと各ブラウザの挙動についていくつか例を挙げつつ、その対策を述べていた。
最近はブラウザもXSS対策を頑張っていて、Content Security Policyといった実験的な試みも行っているらしい。
参考:コンテンツセキュリティポリシー (CSP) - HTTP | MDN
IEは死ねばいいのに。

昼食@ランチ交流会

YAPC::ASIAの計らいにより、くじで当たった4人で適当にランチをとってもらうランチ交流会という企画に参加することができました。
人と話をするのが苦手なシャイボーイにとっては
話をせざるを得ない状況にしてくれるのは、とてもありがたいものです。
結局その時はあまり話はできなかったけども、
そのあとの懇親会で話しかけるきっかけになったりしたので、
ぼっちにならずにとても良かったです。
ちなみにお店は会場近くのスープとパスタのお店でした。

リアルタイム通知システムの舞台裏(しんぺい@猫型技研)

<アプリ>→<通知サーバ> x n→<利用者>
こんな感じの通知システムがあったけど、
アプリ側で通知サーバと利用者の紐付けを管理する必要があるし、通知サーバが死んだら再度アプリと通知サーバの紐付けを更新する必要があった。これを、
<アプリ>→<RabbitMQ x n>→<通知サーバ>x n→<利用者>
ってなかんじで、紐付けの面倒はRabbitMQで見てくれていい感じになったよといった話。


RabbitMQがよくわからんけども、コネクションにタグみたいな何かを割り当てて、タグに紐づいてるコネクションの宛先に、同じ通知を流すといったマルチキャストみたいなことが出来るらしい。
後はRabbitMQから情報を受け取った通知サーバが、
宛先となる利用者は自分がその利用者に流すべき情報なのかを判断させるだけになるので、
アプリ側はその辺を考える必要がなくなる...という感じ?

Perl初心者が作ったサーバ運用ツール(りーお@DeNA)

英語でセッションすることで英語でのセッションへの参加の敷居を下げる試み(?)を行っていた。
サーバ運用を行う上で出来るだけマニュアル操作を減らすため、構築の自動化ツールを書いたよという話ぽい。
chefがあるけど、あれはテストできないからダメみたいな事言ってたような。


個人的には今まさに8サーバ同時リリースの仕事があり、先日終わったばかりなのだけれど、
今後もアップデート対応をするとなると、3時間4時間かかっちゃうので、このままで良いのかどうか考えていた。
その一つの答えを聞けたのかな、と思ってる。
やっていることは必要な設定ファイルのテンプレートに、
環境依存の値を設定して各環境用の設定ファイルを作って、
テスト時ならその値が妥当か調べて、リリース時は実際にsshで送り込むという、
わりと単純な作業に見えたので、試してみたいなーと思う。

Perlと出会い、Perlを作る(Masaaki Goshima)

Perlを知るために処理系をC++で依存ライブラリも含めてフルスクラッチで書いている模様。
既存のPerlよりも早く動くことも目的としているため、
独自アノテーションによる静的型付けや、JITを取り入れていた。
ただ高速化のために、Perlのいくつかの処理を諦めることも考えている模様。
GitHubで公開しているようなので覗き見てみるつもり。

Perlでファントムする(motemen)

最近Javaしか触ってない自分としては、ファントム参照しか出てこなかったわけだけど、まったく関係なかった。
ファントムとはPhantomJSの事を指しており、JavaScript向けのwebkit API
これを使えばJavaScriptにより、Web画面遷移や、クリックの挙動のテスト、スクリーンショットの記録といったことも可能。
それをPerlで使えるモジュール、Wightを作ったというお話。
jQueryビルダーのWight::jQueryもあるよ!

続・Mobageを支える技術(Yuji Shimada)

prefork workerの苦労話みたいな感じだったけど、Mobageを支える技術を読んでいなくとも楽しめた。
終盤はRedisを使ったAPIの話とかを駆け足で。


die(ダイ↑)します。


Profiling memory usage(Tim Bunce)

DBIを書いた偉い人。でも英語でよくわからなry
タイトル通りで見れば、Perlでのメモリの扱い方と、各プロファイリングに使えるモジュールと行う方法?を紹介してた感じ。
Perlプロセスのメモリの使用を視覚化するデモが印象的。
要所要所でスナップショットを記録していて、今後は差分を見てメモリリークが見つけられるようにもなるかもしれないとか、Perl管理外のメモリもサポート予定だとか。
スライド見て勉強させていただきます。
Perl Memory Use 201209

平均レスポンスタイムを50msをPerlでry(Tatsuro Hisamori)

広告枠のオークションを50msで終わらせるために色々やった話。
SSDを使うとか、IOを無くすとか、DNSの正引きを無くすとか、KeepAliveを使うとか、さまざまな方法で応答速度を上げたといったお話。
「古典的でも地道にやる。」

Perlアプリケーションのベンチマークとプロファイリング(Shunichiro Fujiwara)

パフォーマンスが気になったらベンチマークをとる。
呼び出しが少ない箇所を高速化してもほとんど意味がない。
運用中のパフォーマンス低下には、ログを記録し、集計し、レスポンス時間によって分けて、視覚化することで、原因がわかる場合もある。
頻繁にログをとってたら本来のパフォーマンスが発揮できない場合、あるプロセスのみプロファイリングの対象にすることで、
ある1ユーザーは遅く感じても、残りのユーザーには影響がでないようにするといったことも可能。
本セッションの内容をWEB+DB Vol.71に寄稿しているので読む。
「推測するな。計測せよ」

懇親会

ランチ交流会で一緒になった一人と話をしつつ、
@dankogaiさんにEncode.pmにお世話になってます!とか、
@takesakoさんが持ってた本を見に行ってなるほどわからん、といった感じの事をやってました。
でもやっぱり話す話題がなくて会話が途切れてしまうのでした。
もっと話したいけど、話題が出てこない。コミュ障ェ...

終わり

たのしかったです(小学生並みの感想)
自分の中の有名人がわんさかいるのは不思議な感覚ですね。


明日のおひるごはん、誰かご一緒させてください。