｢JJUG_CCC_2017_Spring」へ行ってきた

セミナー参加レポート
  • タイトル: JJUG CCC 2017 Spring
  • 日時: 2017-05-20（土）9:30 - 18:30
  • 会場: ベルサール新宿グランド コンファレンスセンター（5F）
  • URL: http://www.java-users.jp/ccc2017spring/
  • 資料: TBD

「JJUG CCC 2017 Spring」へ行ったので参加レポート書きます。

今回のCCCもとても充実していた。同時に開催されるセッション数が最大8もあるので、選択肢は多いし内容もバラエティに富んでいる。公式サイトによるとCCCは20回目を迎えたらしく、順調に成長している感もあるし、参加者も1,000人を超えていてまだまだ成長しそうな勢いがある。

個人的にはJava SE 8あたりがリリースされたあたりから徐々にJavaに人が戻ってきたかんじがする。その戻ってきた感じのところにJJUG CCCがしっかりはまっているのではと思う。

セッションのラインナップとしてはJava SE 9がまだ正式リリースされないので9関連はまだ多くない。Spirng Boot関連が複数あり相変わらず人気。コードの書き方系も複数あって勉強になるし人気だった。その他にもscalaやらAndroidやら豊富で偏ってないのもよかった。

1,000人を超えて会場のキャパ問題があるようだが狭いのはしかたない気がする。ただ立ち見や入れないなどを極力なくすってことかな。人気がそれほどなかったときのCCCも知っているので、ここまで盛り上げてきた現会長や幹事さんたちを信じて次回の改善を期待するのみ。

以降は各セッションごとのまとめ

非機能要件とSpring Boot

非機能要件のおさらいからSpring Boot ActuatorやSpring Securityでそれらをどう実装していくかというお話。

非機能要件のおさらいの部分はわかりやすくてとてもよい復習になった。ActuatorとSecurityの話は個人的にドンピシャな内容なのでありがたかった。Actuatorの拡張するポイントやSecurityの使い方なんかがつかめた気がする。

Spring Securityは設定が大変なイメージがあるけど、昨今のセキュリティ検査を通すにはCSRFなどを自作していく方が遥かに大変なので、寄り添う必要はあるなあって思った。

メモ

  • 非機能要件
  • Actuator
    • 1.5からSSHは非推奨
    • ポートで入り口を縛る
    • atuditevent
      • 認証認可のイベントログ
    • info
      • デフォルトでは何も表示されない
      • application.propertiesなどで設定できる
    • エンドポイントを自作可能
      • CustomeEndpointクラス
    • エンドポイントの拡張も可能
  • Security
    • パスワードポリシーにはPassyが使える
    • アカウントロック
      • @EventListenerでイベントをハンドリングできるので、そのときに回数をカウントする
    • パスワードハッシュ化
      • SHAではなく、Bcrypt Scryptを使う。
    • 接続情報の暗号化
      • jasyptが使える
    • セッションIDの書き換え、CSRFなどはSpring Securityに備わっている
    • TymeleafではデフォルトでXSS対策される

Javaエンジニアに知って欲しいRDBアンチパターン

RDBアンチパターンのお話。曽根さんの熱さが伝わってきて思わず引き込まれた。「データベースの寿命はアプリケーションよりも長い」「DBが停止するとサービスが止まる」は今後もかみしめていきたいと思った（とりあえずでテーブル設計しないようにする）。

メモ

  • データベースの寿命はアプリより長い
  • アンチパターンを知り同じ過ちを繰り返さない
  • データベースの迷宮
    • 名前がデタラメでは困る
      • コードではデータの中身が見られないから要注意
    • リレーショナルモデルに基づいた設計をしていないとツールが使えなくなる
      • ちゃんとリレーションを張っておけばテーブル図等自動生成できる
    • データにロジックを埋め込まない
    • 処方箋としてはリファクタリングをし続けること
  • 強すぎる制約
    • 例
      • トリガーが多くのテーブルに影響を与える
      • ストアドがロジック持ちすぎ
      • マテビューやDB Linkの多用しすぎ
    • 処方箋
      • その機能を利用する期間を検討する
        • 一時的？一生？
      • その機能を影響範囲を理解する
  • 監視されないデータベース
    • 監視は3段階ある
      • いち早く障害発生を確認する（死活監視）
      • 復旧のための原因を確認する（チェック監視）
      • 状況の変化を時系列で監視して、障害の予兆を把握する（モニタリング監視）
    • インフラは生き物、日々の成長記録を見る。
    • 処方箋
      • しっかりモニタリングする

Introduction of Project Jigsaw

Java SE 9のJigsawの話。櫻庭さんの話は背景なんかもしっかり話してくれるのでわかりやすい。Jigsaw自体の背景やモジュールの作り方やなどはそろそろわかってきたのであとは実際どうなることやらやってみてベストプラクティスを探すことになる。Mavenはどう対応されるかとかも今後だろう。

あとJCPにおけるJigsawが否決された状況が聞けて勉強になった。IBMやRedhatの反対って状況だけはわかっていたが、なるほどAutomatic Moduleの件が大きいのか…。

メモ

  • Jigsawの背景
    • jar hellの問題
    • バージョンのゴチャゴチャとか
    • 本当に必要なjarがわからない
    • publicがpublicすぎて、少しパッケージを超えたいだけでも全部に公開されてしまうなど。
  • モジュールの導入
    • module-info.javaがあったらモジュールとなる
      • これによりjarは今までのjarとモジュールのjarで2種類になる
    • requiresで依存するモジュールを記述
    • exportsで公開するパッケージを記述
    • public ≠ accessibleとなるので、これまでリフレクションを利用している場合は要注意。
      • JDKのライブラリにも一部使えなくなるモノが出てくる
    • モジュールじゃないライブラリ
      • Automaticモジュールで扱える予定
      • そのときjarファイル名をモジュール名として扱うみたいな話が否決におけるポイント。
        • そんなんでいいの？
      • 修正案としてマニフェストファイルに書くが提案されそう。
        • これが通れば…

VMの歩む道。Dalvik、ART、そしてJava VM

JavaVMとアンドロイド（Dalvik/ART）の話。アンドロイドのVMについては個人的にさっぱりだったのでそれらの違いがまとまっていって良かった。やっぱりアンドロイドはHotSpotからみるとだいぶ違うなぁ。

メモ

  • Dalvik/ARTはJLSは満たしているようだが、JVMSを満たしていない。
    • 標準ライブラリなども違う
  • マシン命令も違う
    • HotSpotはスタックマシン
    • Dalvik/ARTはレジスタマシン
  • バイナリ形式も違う
    • HotSpotはクラスファイル
    • Dalvik/ARTはdexファイル
  • JIT or AOTも違う
    • HotSpotはJIT/Interpreter
    • DalvikはJIT/Interpreter
    • ARTはAOT
      • JIT/Interpreterも選べる（Android7からAOT+JIT）
  • プラットフォームを優先した結果独自VMとして別々の道を歩んでいる

SQLアンチパターン

SQLアンチパターン