鴨川ビール会議
RubyKaigi の翌日、川でビールを飲む体験をしてきた。
「東京の人はなんで川に入らないんですか」「渋谷って川ないんですか」「セルリアンとヒカリエとガーデンプレイスを繋ぐ川があると良さそう」などの発言がありました。
三条大橋いるけどビール会議始まらない
— たにぐち (@ravelll) 2016年9月11日
川インターネットしてたら iPhone が高温で死んだ pic.twitter.com/wD6PEWXC6w
— たにぐち (@ravelll) 2016年9月11日
鴨川ビール会議の空気感です pic.twitter.com/aycj7uhnoZ
— たにぐち (@ravelll) 2016年9月11日
みんな座らなくなった pic.twitter.com/0iE8pBZsSV
— たにぐち (@ravelll) 2016年9月11日
RubyKaigi 2016
RubyKaigi 2016 に参加してきた。今年は開催地が京都だったので旅行を兼ねられて良かったし、会もとても楽しかった。
今回ペパボはお菓子スポンサーをしていて、自分はその設営を担当していた。設営後はだいたいトークを聞きに行っていたのでブースにはあまりいなかったんだけど、@hsbt さんや @udzura さんがいてくださってスーパー助かりました 🙇
聞いたトークは以下の通り。
- 1日目
- Ruby3 Typing (@yukihiro_matz)
- dRuby in the last century (@m_seki)
- Welcome to haconiwa - the (m)Ruby on Container (@udzura)
- A proposal of new concurrency model for Ruby 3 (@ko1)
- A Tale of Two String Representations (@nirvdrum)
- Unifying Fixnum and Bignum into Integer (@tanaka_akr)
- Scalable job queue system built with Docker (@k0kubun)
- 2日目
- How DSL works on Ruby (@hsbt)
- Learn Programming Essence from Ruby patches (@takkanm)
- Web Server Concurrency Architecture (@wyhaines)
- Building maintainable command-line tools with mruby (@drbrain)
- Modern Black Mages Fighting in the Real World (@tagomoris)
- SciRuby Machine Learning Current Status and Future (@mrkn)
- 3日目
- Hijacking syscalls with (m)ruby (@franckverrot)
- Dive into CRuby (@nalsh)
3日目ぜんぜん聞けてないのは2日目終了後 @hisaichi5518 と飲みに行くぞとなり途中どんどん Rubyist たちと合流してのみ続けた結果朝になり人間が終わったからです。聞きたかった話はいくつかあったけど、エンジニアの知り合いがガッと増えたのはトークを聞きそこねることをカバーするに余りある価値なので良かったと思う。
トークの内容はあとからスライドや動画を追えばいいけど、隣に座っていた外人と英語で話し込んで文化の違いと英語力の無さを味わったり、それまで知らなかった人と飲み会で仲良くなったり、目の前の膨大な人間たちが全員 Ruby 書いてるというコミュニティの大きさに圧倒されたりといったことは現場でしか味わえないし、それによってしか刺激されない気持ちもあると思う。なので少なくとも「自分には理解できないトークが多いし…」「後でスライドは見るし、別に行かなくていい」のようなトーク内容だけを理由に参加しないのはもったいないな〜という気持ち。行くと楽しいですよ。
社内 ISUCON に参加した
今週火曜に開催された社内向け ISUCON に参加してきた。これが、まあなんともなかなかに堪える体験だった。
〜開催日
個人では本家 ISUCON のまとめページにある解説や参加した方々のエントリを眺めて押さえるべきポイントを知ることから始めた。
チームメンバーでは1週間前くらいからちょいちょい集まって、誰がどこのレイヤを担当するか、Ruby・PHP のどっちの実装を使うか、ハマりそうなポイントはどこか、等々話したりした。
アプリケーションのレイヤを担当することになったのと、「実装は Ruby で」となったので、使われるであろう Unicorn の設定ファイルを準備したり、stackprof の使い方を見たり、よくあるアプリケーションの変更ポイント(セッション活用のパターンや N+1 問題が仕込まれるパターンなど)を抑えたりした。
「まあこれくらいやればそれなりには貢献できるだろ」とその時は思っていたけど、今にしてみれば何を根拠に、という気持ちだ。
当日
お昼ごろ、お題のアプリケーションやインスタンスが配布され、試合開始となった。アプリケーションは Slack を模した、10個くらいの action を持つチャットアプリだった。
それから5時間奮闘したのだけど、結果から言うと、全員チューニングがほとんどできないまま5時間が過ぎ、Fail した。
何が起きたかというと、開始してデプロイ環境を作り変更を加え始めたあたりで謎の 500 エラーが頻発するようになり、終ぞその原因を突き止められないまま終了時間になった、といった具合。
何が問題だったのか
利用するであろうツールの素振りをしていなかった・足りていなかったことも問題だったけど、それよりもチームとしての取り組み方に大きな問題があったように思う。そのことについて、以下にもう少し掘り下げて書こうと思う。念のため言うと書いたことは自分や取った行動の話で、メンバー全員が取っていたわけではありません。
・共有なしに変更を行った
変更者以外が変更を知らなかったために、それに起因する問題の原因特定が遅れたことが何度かあった。
どのレイヤの変更にしても、共有 -> 変更のフローを守っていれば、問題の原因の切り分けが格段に楽になっていたことと思う。
・変更の正しさよりもチームの快適さを優先した
メンバー間の空気が悪くなることを恐れて、チームとしてすべき意思決定を断念したタイミングがあった。これは特に良くなかったと思う。
実際の場面を挙げると、初期実装に使われていた puma はメンバー全員が不慣れであり、使用経験者が複数人いる Unicorn にすべき、という提案をしたが、他方の意見に納得することなしに puma 続投を決定してしまった。後日、500 エラーが出ていた原因の一旦は puma にあったことが明かされた。悩んだ岐路と最も困らされた原因のポイントが一致したことは偶然ではあったけど、慣れたツールを使うことで原因の特定がしやすくなったのではとは思う。
そもそもこのイベントに参加している以上、チームとして再優先すべきは最終スコアを伸ばすことであり、そのためには一時的な反感を買っても(当然言葉は吟味した上で)意思を伝え続けるべきだったと思う。
・変更の吟味をしなかった
改善のポイントは膨大にある一方で、それに使える時間は短い。その中で、効果の大小や最終的な状態を十分に考慮せずに変更を行ってしまった。
改善できそうなポイントを探し、期待できる効果の大きさや予想される所要時間からやれるものを割り振って進めるのが良かったのだと思う。
本家 ISUCON で上位になった方々の参加エントリを見ても、各自が手当たり次第改善しまくったのではなく、チームで選択した改善を丁寧に重ねていったチームが多いように見える。
といった初 ISUCON 記でした。精神的に大変負荷のかかったイベントでした...w 開催翌日までダウナー人間でしたが、今となってはとてもよい経験だったように感じます。
次回開催があったとき、もしくは本家 ISUCON に出場するときにはかなりのやっていきを見せつけられるよう、今からアレをコレしていこうと思います。