に、行ってきました。

なんか怖そう

いやー、本当に参加するまでは本当にビビっていたわけですよ。前提とされる知識のハードルが高そうで。

その上で、以下の知識があると、説明の内容を十分に理解できることでしょう。

データベースサーバの表ロック・行ロックによる問題を説明できること

Java のスレッドの状態を知っていること

アプリケーションサーバのスレッドプールとコネクションプールのリソース枯渇による問題を説明できること

これらを説明せよと言われても、正直できないので。

ただ、私の場合、たまたま身近に #0 に参加した人がいたので聞いてみたところ大丈夫との回答を得たので特攻してきました。

Tech Deep Dive、たまたま #0 の参加者が身近にいたので「僕でも大丈夫ですかね？」って聞いてみたら「だいじょうぶー」って返事が帰ってきたので、置物覚悟で特攻します
— Toy (@mdstoy) February 23, 2018

怖くなかった

実際は、お二人のセッションは非常にわかりやすく丁寧でしたし、内容は今の私が知りたいかつ知るべきであろう事柄にとてもはまっていたのも幸いでした。また、なにより難易度が事前に予想していたよりは高くなかったです。むしろ、ぶっちゃけ私にはちょうどいいけど物足りないとかもっと濃ゆい話がほしいと思う人もいっぱいいるんだろうなと思うくらいでした。

いろふさんがブログで

経験が浅い人にこそ聞いてほしい話なんじゃないでしょうか。この知識がx年前にあれば、あの時もっと楽できたのになぁ、なんて。

という感想を述べられていましたが、まさに私はそれに該当しているのかもしれないです。実際にセッション中にもこの話が近い将来生きてくるのかなぁなんて感じながら話を聞いていました。主にインフラのスキル的な意味だったり、仕事における立ち位置的な意味で私はまだまだ途上で、それでもこれからはアプリを支えるインフラも含めた上でのサービスというものをいやがおうにも意識していかねばならない立場になりそうなので。

具体的には

クラウドでは、アプリの性能が悪いと余計なコストがかかる
本番を想定したデータで性能テストをすることは重要
- 例えば特定の商品に注文が集中するなどの特別なケースなどもちゃんと考える
安易なスケールアウトは問題の解決にならないばかりか危険
- 解決のためには問題を正しく分析することが重要
負荷は、変わる（増える）
- サービスの成長とともに負荷は増大する
  - しかも、それは比例とは限らない
- 特殊な状況での負荷
  - EC サイトだったらセールとか
コストを考えると、スケールアウトだけでなくスケールインについてもよく考えるべき
データストアのロックをアプリ側のスケールアウトでは対処できない
非同期は要件次第
キャッシュは条件が揃わないとさほど有効な手段とはならない
リカバリの範囲（トランザクション単位なのか、テーブル単位なのか、データストア全体なのか）を意識する、影響を最小限に抑えられる適切な範囲で切り戻せるようにする

などなど、ためになるお話がたくさんありました。（独自解釈が入っているかもしれないのでご注意を）

怖くないよ

少なくとも今回の内容は、言われたことをコーディングするだけの人では、たとえそれなりのプログラムがかけたとしても辛いかと思いました。しかし、そのもう少しだけでも先の段階に行っている人なら十分受け止められるのではないかと思いました。具体的には、自分でコードが書けてアプリケーションの一つや二つは作れます、インフラは正直よくわからんけど作ったアプリケーションを動かす環境を自分で構築するくらいはできます、というレベルの人なら多分大丈夫なのではないかと。ていうか、少なくとも自分はそうです。

なので、もし私のようにハードル高そうだ、うっかり侵入したら穴だらけにされてしまうのではないか、と思って敬遠した人がいたとしたらそんなことはない「かもしれません」よ、とお伝えしたいです。

でも（余談気味に）

とある構文解析ハンズオンに「Java SE 9(Java Platform (JDK) 9)をダウンロード・インストールしておいてください。また、javacにパスを通しておいてください。（中略）誤って、JREのみをダウンロードされる方がこれまでも一定数見られましたので、注意してください。」と書いてあって、大木こだま師匠ばりに「JDK と JRE を間違うなんて、そんなエンジニアおらんやろー」と思って見ていました。しかし、今回 TDD になぜ一見厳し目のハードルが設けてあるのかの理由を実際に伺ってみて、そういう（レベルと意識の）人が本当ににいるんだな、それは仕方ないな、と思いました・・・。