YAPC::Asia 2014 に行ってきました
8/29, 8/30 の2日間、 YAPC::Asia in Tokyo 2014 に行ってきました。
YAPCは以前も一度行ったことあったよな？と思い返してみたら、それは 2006 年だったようで、なんと 8 年ぶりの参加でした。 それだけ久しぶりに参加してみたら、昔はほんと Perl の濃いお祭りという印象だったのが、今年はベストトーク賞 1 位が PHP のセッションというようなイベントになっててなんとも浦島気分でした。実際、自分も今回はやや意識的に Perl 以外のトークを多めに選択したので、特に言語の垣根を超えたイベントだった印象が強いです。 それでも、全体的には昔からの Perl Mongers たちのギーク感あふれるノリが感じられ、とても楽しかったです。
いくつか、聴講したトークのメモや感想など簡単に記しておきます。
Go For Perl Mongers
Golang のハマりどころなど。「Go かじってみたけどしっくりきてない人」が対象で、かじってもいない自分にはいまいち実感として分からないところも多かったが、むしろ Go さわってみたくなった。 オブジェクト指向は忘れろ、例外(Exception)は存在しない、POSIX のプロセス処理とは違う、など、いろいろパラダイムの異なる言語のようで興味深い。この先も、用途に応じて発展する言語がいろいろ共存する世界がくるのかなと漠然と思う。
お待たせしました。Perl で BDD を簡単に実践する最高にクールなフレームワークができました
QA エンジニア出身で開発エンジニアやってる身としては個人的に一番興味のあったもの。 Test::Builder2 が頓挫してしまったので Test::Kantan というテストフレームワークを作ったというお話。 Builder をベースにしていないが、 Test::Exception とかのためにフックはしているという。インタフェースは Jasmine インスパイア。 テスト最終結果の出力は 1 か 0 で出る(何分の何とかではなく。成功なら OK 1..1)。確かに何％通ったかって基本気にしない。100%通ったか否かが重要。 ちなみにテストの出力をキレイにするモジュールは Test::Pretty というものがある。 Test::Builder2 が出るまでのつなぎとして位置づけてたらしい。既存のテストで、キレイで読みやすい出力を得たい場合はこれを使うとよい。
Scala In Perl Company : Hatena
はてなでの Scala 利用の話。静的型システムを求めての選択。 しかしウワサで聞いたことあるとおり、コンパイルは長くてしんどいらしい。
One layer down below.
Booking.com では一見、車輪の再発明にもみえるものを独自に作っていたりするけど、そうではなく、目的に特化したものを作っているよ、という話。 たとえば HTTP Client として Hijk (ハイク)というものを作っているが、単純なデータ取得目的に特化した 200行くらいのコンパクトな実装で、 LWP の 1万倍早い (あるケースでは C で書かれてる curl コマンドよりも早いとか)。 一般的なモジュールやフレームワークはあらゆるケースを網羅するために主にパフォーマンスが犠牲になってることがままある。 問題解決にはトレードオフが必要で、1つレイヤーを掘り下げて、そもそもの仕組みをしり、自分たちが必要なものだけを実装するということが大事だよ、という。
いろんな言語を適材適所で使おう
組織の技術選択には時間を追うごとに変化していく環境への不確実性に対処する必要がある。そのために 1. 技術的分散: "Microservices" by Martin Fowler 2. 組織能力の涵養 (フレームワークへのコミット, OSSアクティビストのサポート, エコシステムへの join, etc) の2軸が大事だという話。 不勉強で Microservices という単語は今回はじめて知ったのだが、 Amazon の方針としては知っていた。巨大な1システムではなく、複数の小さいサービスの集合体として製品を実現する、それぞれのサービスごとに小さいチームを編成して、サービス間はインタフェースを決めてやりとりする。 大きなシステムは開発効率よいようにみえて非常にハイリスクであること(技術環境が変わっても何も変えられなくなる)は目の当たりにして知っているので、もう、ですよねーとしか言えない。
O2O/IoT/Wearable時代におけるWeb以外のネットワーク技術入門
こちらもあえて馴染みのない分野の話をきいてみようと思って参加。 機械間通信だと省エネが厳しく要求される中で、もともとは HTTP でデバイス間通信しようとしたが、テキストでのやりとり前提でキツく、そこで一方では HTTP ではない PubSub システムとして MQTT が策定され、もう一方では CoAP という HTTP ベースで改善したものが作成されたらしい。 プライバシーとセキュリティの課題を克服していけば、インターネットのパラダイムがもう一段進化するのかもしれないが、このへんはまだまだ進化中の領域なのだなと感じた。モノがネットワーク、システムに加わった世界で、テストとかますます難しそうになる気はする。。 Selenium の作者が(リアルな)ロボットによるテストに走る理由もよく分かる。
Dockerで遊んでみよっかー
Docker もなんとなく概要くらいしか知らずに参加してみたが、具体的なデモでだいぶイメージができた。 具体的なビルド手続きの作り方として、 - 前回から変更のない部分は再ビルド時に省略されること (実行したい場合はノーキャッシュのオプション指定) - COPY コマンドでは対象のファイルに変更があったら再実行され、それ以降のコマンドも再実行されること - それを利用して、毎回実行したいコマンドの前に COPY をおくこと - 変更されにくいファイルだけを先のほうで COPY しておくこと など、だいぶ細かいけど参考になった。 あとは、Docker Hub 上のイメージの選択基準として、 Dockerfile が公開されてて内容がちゃんとしてるかということや、 Automated Build で作られたリポジトリかどうかなど。
Perl Mongersのためのstrace入門
こちらも具体的なチュートリアル。 strace 聞いたことある、くらいの初心者なので、使いドコロとか使い方のイメージをつかめてよかった。 パフォーマンス系の問題などで調査に使えるかもしれない。 - Web サーバは基本的に accept コマンドでブロックしてリクエスト待ってる - 最初の accept の返り値 がそのリクエストのファイルディスクリプタなので、そのFDをおうとそのリクエストへのレスポンスがおえるのでそれが基本 - ちなみに event driven だと accept ではなく epoll で待ってたりする - memcached には sendmsg でコマンド送ってる - strace -p $pid -e "trace=sendmsg" みたいにして既に走ってるプロセスにアタッチして特定コマンドを追う
Plack for Fun and Profit (But Mostly Profit)
既存のコードを rewrite したり refactor すべきかどうかは場合による。セットアップ(環境とか)の変更もコストがかかる。 お金を生むコードを消すわけにはいかない。 既存のレガシーなシステムを維持しつつ、どう新しい仕組みを導入していくか？ １．全部スクラッチで書きなおす → コスト倍以上かかる、ムリ ２．新しいものは新しいフレームワークで ３．なにもせず泣き寝入り → 人生つまらなくするのでナシ
というわけで 2. を実現する("decoupled divergence")ために Plack の Middleware のしくみで複数のシステムを共存させる。 旧フレームワークの仕組みにも、新しいシステムにもルーティングするようにする。
いくつかの Tips: - prefork preloading - async cleanup - smart auth (認証の切替。開発用とか) - SanityDestroyer (メモリリークをふせぐ？)
Plack をそう利用するという視点はなかった。 今仕事で扱ってるシステムの今後の方針のおおきなヒントになった。 microservices の方向にシフトするための手段となるやもしれぬ。
Perl For (Non?) Perl Mongers
scope::guard は go でいうとこの defer Test::mysqld もガードオブジェクトかえす 互換性を保つ＝小さいパーツを組み合わせる
Changing the tires on a moving car: a case study in upgrading legacy architecture
GitHub での、アーキテクチャ移行の話。 同時通訳なしで聞いてたのもあって、ちょっと理解が怪しい。
ローカルシステムなら簡単だが、ストレージが分散すると大変になる。 裏側では git コマンドを直接操作するのではなく Grit という Ruby 製のラッパーがあるらしい。 これをさらに分散ストレージに対応させた Smoke (= Grit in cloud)に発展させた。 また、shared lib つかうのつらい & license 問題があり、 libgit2 (= 再配布可能な git)ができた。 またそれに対し、Rugged という Ruby 製のラッパーをできた。 さらに encode も扱う GitRPC (Git 自体は encode 気にしない (Smoke も)) backscatter というプログラム仕込んで、新旧へのコールの割合をトラックして、新しいほうに移行してないやつをつぶしていく。
といった話だったと思う。 これも、先の Plack の話と同様で、既に動いてるものを維持しながらどう新しい仕組みにシフトしていくかの話。 やはり、どちらでも使い分けられるようにした上で新しいものを追加していく、置き換えていく、というのが定石のようである。
OAuth/OpenID Connectを用いてID連携を実装するときに気を付けること
少し前に OAuth 認証のプロジェクトに関わってたので聴講。ふむふむという感じで、概ね自分の理解や考え方がずれてないっぽいことがわかった。
UX的注意点: - キャンセル時 → ユーザ意図をくむ エラーじゃない - 未登録ユーザ→ メッセだしつつ新規登録へ誘導など - 過去のログイン情報 → 一度認証につかったサービスおぼえとく (e.g. janrain)
セキュリティ: - CSRF: 攻撃者は、認可コードもどってきた時点で別のユーザのセッションで処理させる → 対策: state パラメータをセッションと結びつけておいて戻ってきたら検証。外部におくるので session id そのものは使わない
- ネイティブアプリの場合: 方式1. SDK で取得した access token を使う、バックエンドサーバでユーザ識別子得る → バックエンドはまず access token の発行先が自分かどうかを idp に確認 方式2. WebView で認可コードつかう この場合バックエンドは安心、だけど クライアントサイドがフィッシングぽくなる Google の場合、クライアント登録しておくとネイティブアプリ側で 認可コード取得できる
どうやって導入していくか: - 強度の低いとこだけソーシャルログインに置き換えるのもあり - メールアドレス確認の省略にもなる - 導入の優先順位: 対象は既存ユーザを先に、 デバイスはスマホブラウザを先に
Perlの静的解析入門とPerlリファクタリングツールApp::PRTのご紹介
内容はタイトルのとおりだが、独特かつ小気味よいテンポでかなり笑いの起きていたトーク。 静的解析では、やはり PPI 使って構文分解したうえでいろいろ調べるというのがよいようである。 「git grep のいいやつ」は、ちゃんと関数名のものだけ拾ったりなど、便利そう。 デモ用に用意されたクソコードｗ を実際に App::PRT 使って関数置き換えたりクラス名変えたり。 これもかなり実践で使えそうな予感。 コツとして、対象ファイルをあらかじめ絞ったほうがよい、というのはやはり PPI で解析した場合、ファイル数多いとそうとう時間かかるということだろうか。
おわりに
ライトニングトークの内容はさすがにひとつひとつ書けないですが、やはりライトニングトークが YAPC の醍醐味のひとつかなと感じました。
Perl 以外の内容が多くても、 YAPC の文化は Perl コミュニティの文化をまんま反映していて、どんな変わり者でも受けて入れてくれそうな懐の深さを感じさせる、なんだか居心地のいいイベントでした。
とりあえず以上、雑ですがまとめでした。
