Java Day Tokyo 2016に行ってきた

event javadaytokyo

f:id:kitanow:20160524090845j:plain

5/24(火)に東京マリオットホテルで行われたJava Day Tokyo 2016に有休決めて行ってきたのでメモ。
あくまで自分用に書いているので箇条書きです。

Togetterのまとめもあります。


Innovate, Collaborate, with Java

  • 会場は20代が1/3、30代が1/3とのこと
  • 色々なところでJava使われてますよという話
  • JCP(Java Community Process)について
  • 開発者向けにJava Magazineというのを発行している
  • Javaが今後取り組んでいくのはセキュリティ、これはクラウドでの活用を見据えて
  • 起動速度やGCの改善を行っていく
  • Java 9
  • NetBeans
    • HTML/CSS/JavaScriptの開発に対応
    • 見た目が完全にIntelliJなのですが
    • Java開発者はJavaScriptのコードを書くことが多い
    • 変更した内容が即座にブラウザに反映される(まーIntelliJでもできますが。。。)
    • Jigsawを試すこともできる
  • Java EE
    • モノリスからマイクロサービスへ進化
      • 集中から分散
      • ステートフルからステートレス
      • オンプレミスからクラウド
      • Polyglot(Java以外の言語と組み合わせる)
      • チーム開発の変化(縦割りから小さな専門チームへ)
    • インフラのクラウド化
      • コンテナの変化
      • IPがダイナミックに付与
      • イミュータブル
    • サービスがお互い隔離されている
      • マルチテナント
      • マイクロコンテナ
      • ドメインパーテーション
  • 感想
    • モジュラリティ(Jigsaw)とマイクロサービス推しまくり
    • マイクロサービスといえばSpring Bootなのだが、Java EE 8でマイクロサービスってどうなの？

損保ジャパン日本興亜のJAVA戦略

Twitter上ではライブレビュー状態だったが、お堅い保険会社のメインフレームの刷新にしては攻めている方だと思う。やりたいかと言われるとそこは丁重にお断りさせていただきます。

Night Hacking

JJUGの活動紹介

内容としては5/21(土)に行われたJJUG CCC 2016 Springの基調講演の短縮版かな。

ドローンデモ

  • Oracle IoT Cloud Service
  • Secure IoT Gateway
  • SAM(Secure Access Module)
    • 重要データの管理・保護
    • データ暗号化
    • 認証機能
      • 操縦者・機器の承認
      • 指定日時・場所による運用管理
      • 認証側での停止制御
      • OSGiでアップデート

Papperデモ

  • Papperのカメラで写真を撮影してCloud Storageにアップロード
  • タブレットで撮った写真をCloud Storageにアップロードし、Papperが更新を通知
  • サーバ側はOracle Cloud Platform
  • クライアント側(画像ファイル管理コンソール)はOracle JETで実装

Introduction to MVC 1.0 (JSR 371)

  • Software Technical EvangelistのDavid Delabassee氏(@delabassee)
  • 最終日に空きが出たので登録したセッション
  • MVC1.0はアクションベースのMVC
    • JSRで標準化
    • JSRの参照実装にOzarkがある
  • MVCは新しいものではなく、25年以上使われている
    • Model, View, Controllerのコンポーネントにはそれぞれ役割が決まっている
    • Modelはインタフェースの状態をキープするための中間的な状態を保持するところ
    • Viewはユーザが操作するためのボタン、フィールドなど
    • Controllerはリクエストをユーザから受け取り、ビジネスロジックを実行する
  • MVC
  • Java EE 7の標準はJSF(コンポーネントベース)
  • MVC 1.0はアクションベースMVCの選択肢を提供する
  • リファレンス実装はOzarkというOSSがある
    • Model
      • CDI, Bean Validation, JPA
      • 推奨するのはCDIベース
    • View
      • Facelets, JSP
      • View engineにはsupportsとprocessViewという2つのメソッドが用意されており、他のViewもサポートしている
      • 例外処理はJAX-RSのものをそのまま使用している(Exception mapping providers)
    • Controller
  • アクションベースMVCは悪くはない
    • 今あるものを活用できる
    • JAX-RSが分かっていれば難しくない
    • もっと知りたければOzarkを見る
  • MVC Specification
  • The Aquarium Blog

Java EE 7アプリケーションとWebセキュリティ

  • @skrbさんのJigsawはすごい混みそうだったのでこちらにした(まーこっちも満席ですけど)
  • うらがみさん(@backpaper0)と言えばJAX-RSとDomaだけど今回はセキュリティネタ
  • イントラのシステムはセキュリティが甘くても致命傷にはなりにくい
    • でも、仕様が変わって公開することもある
    • ならば、最初からセキュアなコードを書いておけば要件が変わっても問題ない
    • 但し、そこに掛けるコストは無視できない
    • 対策することでコードリーディングのノイズとなることも
  • フレームワークが対応していれば実装もなくノイズもない
  • ビュー・コントローラで対応する場合は個別による実装が発生
  • その他
    • ビジネスロジックで対応しなければいけないもの
    • その場合でもInterfaceなどで切り分けるようにする
  • 対策の基準
  • XSS
    • 反射型、蓄積型、DOM型がある
    • ここでは反射型と蓄積型についての対策
    • JSPの対応
      • jstlのc:outタグを使うことで対応できるが見づらい
      • 関数を自作してf:hの関数として呼び出せるようにするとEL式だけで表せる(hというメソッドを作り、fでsetAttribute)
      • カスタム関数はTLDファイル(XML)で定義を作成する必要があり、気軽にパッケージ変更できない
    • Faceletsの対応
      • デフォルトでエスケープされる
      • そのまま出す場合はescape="false"と指定する
    • メソッドの呼び出し漏れをチェック
      • JSPの場合はHTML出力に使われているEL式を洗い出す必要があり、面倒
      • Faceletsはそこまでしなくてよく、escape="false"と指定している箇所だけチェックすればよい
  • CSRF
    • ユーザのセッションが生成されたタイミングで乱数(トークン)を生成し、hiddenに埋め込む
    • リクエスト時に一緒にポストして、サーバ側で正しいかをチェックする
    • JSPの対応
      • 自力で実装
    • Facelets
      • javax.faces.viewstateがCSRFトークンとして機能する
      • ページを開くたびにvalueが変わる
      • 但し、これはステートフルの場合で、ステートレスビューの場合はvalueが固定になるのでCSRF対策にならない
      • ステートレスビューでは表示用のビューと処理実行用のビューを分ける
      • faces-config.xmlに記載したURLパターンに一致するビューを保護するようにする
  • SQLインジェクション
    • JPAのJPQL
    • em.createqueryではプレースホルダーを使ってパラメータをバインドする
    • @namedQueryは定数しか渡せず、動的に文字列連結できないのでこちらがおすすめ
      • Criteria APIを使ってJavaでクエリを組み立てることもできるが、学習コストは低くない
  • セッション管理の不備
    • ログインしたタイミングでセッションIDをリフレッシュ
    • Java EEのログイン認証
      • Servlet APIのform認証
      • Glassfishは認証成功後にセッションIDがリフレッシュされるがJDBCレルムの設定が必要
      • HttpServletRequest.changeSessionId()を呼び出す
      • URLにセッションIDを埋め込まない
      • Cookieに格納し、Secure属性を付ける
  • ファイル操作・パス名
    • 未チェックのパラメータ(パス)でファイル操作をする
    • ファイル操作を行う前に想定したパスかチェックする必要がある
    • 漏れ検出
      • ファイル操作はSEのAPIなので漏れ検出は難しい
      • 自前のAPIでラップし、ファイルのAPIを直接使用していないかをチェックする
      • インターフェースを用意するとテストコードが書きやすい
      • この対策は保険的対策で根本的対策としてはファイル名を直接指定する実装を避ける
      • 根本的対策を施す場合でも自前のAPIでラップする
  • クリックジャンキング
    • X-Frame-Optionsレスポンスヘッダを付けるだけ
    • 但し、frameやiframeが無効になるためAjaxで使われていれば、そちらも無効になる
    • 制限をDENYではなく、SAMEORIGINにすれば生成元が同じiframeは読み込める
  • HTTPヘッダインジェクション
    • Java EEだと自力でHTTPレスポンスを書き出すことが無いので対策不要
  • メールヘッダインジェクション
    • 対策もHTTPヘッダインジェクションと同様だが、意図しないヘッダを書き出すことはできる？
    • ヘッダにセットしない、セット前にチェックする
  • OSコマンドインジェクション
    • 外部プロセスを起動することがないので省略
  • バッファオーバーフロー
    • 直接メモリを操作しないので省略
  • アクセス制御
    • アプリケーションによるところなので省略
  • その他
    • X-Content-Type-Options: nosniff
      • Content-typeが設定されていないリソースに対して自動で判断する(IEの機能)
      • このsniffを無効にする
    • Content-Security-Policy
      • 最強のXSS対策レスポンスヘッダ
      • この対策でDOM型のXSSにも対応できる
      • 任意のHTMLを書き出す脆弱性があったとしてもJavaScriptが動かない
      • style-srcやimg-srcで個別に制約を設定できる
  • まとめ
    • Java EEで対応しているものもあれば、自分で対応するものもある
    • 仕組みを理解しないとなぜそれで防げるのか分からない
    • 資料を読んで普段からセキュアなコードを書く癖をつける
  • 感想
    • 話としてはオーソドックスなセキュリティ対策
      • こういうのを設計段階で決めておくと、リリース直前でセキュリティ対策が漏れていて炎上するみたいなことはなくなると思う
    • SQLインジェクションでDomaに触れなかったのはOracleへの配慮かな？

コンテナとJavaとOracle JETによるアプリ開発ハッカソン

  • Oracle Cloud Platform
  • Application Container Cloud
    • Dockerベースの軽量プラットフォーム
    • 多様な開発言語に対応
    • ロードバランサを内包、無停止で拡張/縮退可能
    • 特徴として組み込みJFR(Java Flight Recorder)による稼働記録、Java SEのupdateを長期間提供
    • デプロイはアプリケーションのjarとメタデータファイル(json)をzipファイルに固めたものを、アップロードするだけ
  • Oracle JET
  • デモアプリ
    • サーバサイド
      • 全てJava製のもので構成
      • REST APIコンテナとしてSpring Bootを使用し、組み込み型のTomcatで動かす
      • O/RマッパーはEclipseLink(JPAの実装の1つ)
      • RDBはDerby(内部でDBを持たせている)
      • レスポンスはJSON
    • クライアントサイド
      • Oracle JETを使用
      • Model/View/ViewModelパターンに基づいて実装
  • ハンズオン
    • デモアプリをローカルの環境で動かす
    • 編集したデモアプリをApplication Container Cloud上でデプロイ
  • ハッカソン
    • デモアプリをもとにアプリを開発
    • 発表者には粗品(Javaグッズ)をプレゼント

パネル・ディスカッション - Java Day Night Session with NightHacking Tour

  • 日本のJavaコミュニティはとても熱気に溢れているが、質問が少ない
  • Java Championはコミュニティへの貢献を評価されたリーダ
    • 日本人は一人(@skrbさん)しかいない、アジアでも少ない、英語で発信していないから
    • @skrbさんはLooking Glassで英語の発表をやっていたから推薦されたとのこと
  • Java Championになるには
    • 技術的なリーダであること
    • コミュニティのために教育をしていること
    • コミュニティメンバとして啓蒙活動をしていること
    • オラクルから独立していること
      • オラクルに入ったので私はJava Championでなくなった(@steveonjava)
    • Coolなアプリケーションを開発している
    • 他のJava Championからの推薦
  • JCPは今後、企業以外での参加も可能になるとのこと
  • #てらだよしおがんばれ
    • マイクロソフトでJavaエバンジェリスト
    • 前職ではJava EEなど製品ベースの仕事をしていたが、現職はより上のレイヤーで見るようになった
    • Java Championに相当するものとしてマイクロソフトにはMVPがあり、MVPが主体となって勉強会などを行う
    • ぼくは元々、こっち側の人間です
    • Javaコミュニティについて
      • もっとJavaに興味を持っている人を参加しやすくする
      • あるいはエンタープライズ向け、こども向け、などに特化したコミュニティ
      • それをJJUGが担うのがよいのかは分からない
      • JJUGの幹事は多忙なので現状の運営だけでも大変
  • その後はStephen Chin氏によるRaspberry Piのプレゼン

その他

  • 展示コーナーにNightHacking Interviewのブースがあり、色々な人がインタビューを受けていました
  • 皆さん英語で受け答えしていて素晴らしい

全体の感想

  • 初のJava Day Tokyoとても楽しめた
    • Twitterではスーツ率高いとあったけどOracle Open Worldに比べたら全然少ない(Oracle Open Worldはスーツの人しかいない)
  • 1日中セッション聴くのは疲れるので初めてハンズオンに参加してみる
    • 参加者が少ないのでゆったり座れた
    • ハンズオンの会場は机、電源、Wifiあり:-)
    • 後半はハッカソンだったが全く作れずに終了orz
    • @cero_tさんや@kawashimaさんの発表も聴きたかったけど
  • 満席セッションでも入れるみたいなので事前予約の意味があまりないのでは
  • 昼は11:30-13:00だったのでゆっくり出来た
    • 昼食は少し歩いて北品川商店街の「プサン」という韓国料理店
  • JAVAおじさん問題
    • 最前列で寝ているおじさんがいるというので、それは発表者に失礼だなと
    • 参加料を取るようにすれば来なくなると思う
    • 業務の一環(研修とか)で来ている場合、有料だと会社に書類(申請書や報告書)を提出しないといけなくなるはずで、そうなれば面倒で来ないだろう
    • 本当に来たいと思う奴は有給休暇取ってでも来るし、自腹でも来る
  • Java Day TokyoとJJUG CCC(あくまで個人的な意見です)
    • Java Day TokyoはJavaの最新動向をキャッチアップするところ
    • JJUG CCCはJavaのフレームワーク、活用事例などをキャッチアップするところ
      • セッションのバラエティはCCC
      • 但し、Java Day Tokyoにもスポンサーセッションというのが設けられているので事例もある
    • Java Day Tokyoはformal、JJUG CCCはinformal(発表者の立場という意味で)
      • 会社として発表するのか、個人として発表するのか
      • CCCの方がお祭り感(土曜だからなのかもしれないけど)があるし、純粋に楽しむならCCCがいいかもしれない
    • ちなみに私はCCCに参加していませんが。。
      • 前参加した時に、お目当てのセッションが立ち見状態なので心が折れた
      • 何処が満席セッションなのか分かりづらい、分かっていれば第2候補とか第3候補を考えられる
      • 土曜潰してまで疲弊したくないという極めて老害な理由
      • CCCはでかくなり過ぎた感が否めない
      • 昔の寂れた感じの方がよかったと言ったら怒られそうだが、その場の気分で好きなセッションを気軽に聴きに行くという感じではない