Java Day Tokyo2016に行ってきたよ
都合のため、キーノートとナイトセッションは参加できず。
午後の５セッションの感想です。
スライドがアップされたら更新するかも
Introduction to MVC 1.0
Java EE 8に含まれるMVC1.0の概要の説明。
深く突っ込んだ内容はなし。
「MVCとは？」の説明からなので、基本的なところから学べた。
そうは言いつつも、さりげなくViewでFreeMaker使ってるサンプルがスライドに入ってたり。
実装はOzark。
仕様はそれほど難しくなく、JAX-RSを使いこなせてる人ならそのまま使えそうな感じ。
SpringMVC慣れてる人も大丈夫そう。
感想としては、Viewの指定方法が沢山あるのは使う時に迷いそうなのが微妙。
まとめにもあったけど、Java EEにMVCという選択肢が増えるのは良いことであるのは間違いない。
ただ・・・遅すぎない？
EE７に入っていればよかったのに・・・。
Java EE 7 アプリケーションとWebセキュリティ
スーツ姿の裏紙さんセッション。
IPAが公開している、安全なWebサイトの作り方をJava EEでどう実現するかの話。
重要なこと
- 最初からセキュアなコードを書くこと。セキュアじゃないコードをセキュアにするのはコストが高い
- 対策も必要だけど、脆弱なコードをチェックする仕組みも必要
- それぞれの対策は簡単だけど、攻撃がどういう仕組みでどういう理由で対策できるのかを知らないと対策しても不安が残る
- セキュリティに関する資料は一般的に多く出回っているので、普段から勉強しておくのが大事
- ビジネスロジック（モデル）で対応するのは、可読性や保守性に悪影響。なるべくViewやControllerで対応する
各攻撃に対する対策
JSPや低レベルな処理の話もあったけど、面倒なので割愛。JSFを使おう。
XSS
Faceletならデフォルトで対策済。
CSRF
JSFなら対策不要。
ただしViewをステートレスにすると対策が必要になる。
ステートレスとステートフルを使い分けるといい。
SQLインジェクション
JPAの@NamedQueryアノテーションを使う。
em.createQueryはクエリ文字列を受け取るため、SQLインジェクションの脆弱性があるクエリを指定される可能性がある。
CriteriaAPIを使う手もあるが、学習コストが高いのでオススメはしない。
パスのパラメーターチェック
JavaのFileAPIをそのまま使うのではなく、パラメータチェックを行うラップAPIを作成して利用する。
こうすることで、FileAPIで検索して脆弱なところを検出できる。
クリックジャッキング
レスポンスヘッダーに、X-Frame-Optionsをつけることでiframe、frameを禁止できる。
ただし、Ajaxで行うファイルアップロードも潰してしまう可能性があるので、すべて禁止するのではなくSameOrigin指定を推奨する。
OSコマンドインジェクション、バッファーオーバーフロー
割愛。
どちらも普通に作っていれば起こらない。
その他
レスポンスヘッダーに以下の二つをつけるといい。
X-Content-Type-Options:nosniff
IEはコンテントタイプが指定されていないものを自動で判断する。
そのため、悪意のあるコンテンツを解析した際にスクリプトを実行される可能性がある。
このヘッダーをつければ自動解析を無効にできる。Content-Sequrity-Policy 最強のCSRF対策だけど、CSSやイメージを妨げる可能性あり。
すべて禁止ではなく、許容するリソースを指定する。
Java Concurrency A(nother) Peek the Hood
Javaの並行処理に関する話。
わかりやすかったけど、技術的にはかなり深い所。
概要
- Webアプリケーション、GUIはマルチスレッドが普通
- ライブラリを公開する場合も、マルチスレッドで使われることを考慮しよう
というより、シングルスレッドが許されるのは学校の宿題まで
ConcurrentAPIとか使い方を暗記していても仕組みを理解してないのは危険
メモリモデルを正しく理解しよう
マルチスレッドの場合、各スレッドによって実行順の基準が異なる
Javaの場合はHappened-before
Java SE 5まではfinalがイミュータブルではなかった
並列処理ライブラリを利用するときは、なるべく抽象化されているものを使う。具体的な処理を利用すると実行効率が良さそうに思えるが、とても難しく問題も出やすい。
本番と同じ環境でテストすることが大事
本を読むならJava Concurrency in Practiceがおすすめ
実践してわかったJavaマイクロサービス開発
モノリシックなWebアプリケーションをマイクロサービスに変えていった経験の話。
マイクロサービスは技術的な話は多いけど、実践例は少なかったので参考になった。
スライドが丁寧だったので、内容の詳細は省略。
参考になった点
- サービスディスカバリーは必須
- クライアントとサービスを共通のインターフェースにすることで、IF仕様書を作らなくて良くなる
- 多言語化はEurekaとの関係もあり難しい
- サーキットブレーカーは障害が起きたらどうすればいいかまだわからない
- HTTPは同期処理。AMQPは戻り値なしの非同期
- 画面を中心にAPIを考えると、巨大なものになりやすい
- ドメイン分割は大事。ドメインごとにサービスを作るくらいがちょうどいい
Javaエンジニアのためのクラウド時代の過ごし方
これもスライドがとてもいい感じなのでポイントだけ。
決してお酒が回って面倒なわけではない。
考えさせられた点
- 今までは作ることが大変だった。しかし今は作るところは簡単になり、運用面の問題に向かい合えるようになった。
- 良いコードを書くことは大事だけどそれだけじゃダメ
- アジャイル、クラウド、DevOPS、マイクロサービスは、それぞれの組織が取り組んできた結果
- クラウドによって、ハードウェアがソフトウェアとして定義できる
- 自動化、コピーができる
- 非機能要件のテストが書ける
- PaaSは稼働しているミドルウェアを借りるイメージ
- インフラのテストは本番環境でしかできない。そのテストをするのがNetflixのカオスモンキー
- カオスモンキーはランダムにサービスをダウンさせる
- カオスゴリラはAZを丸ごとダウンさせる
- カオスキングコングはリージョン丸ごとダウン
- ダウンの目的は自動で復旧するかの確認。手順書ではなくコード。運用を不要にする。
これからのエンジニア
２つのどちらかにならないといけない
