なみひらブログ

学んだことを日々記録する。～ since 2012/06/24 ～

「Spring in Summer ～夏なのにSpring」に行ってきました

Java SpringFramework セミナー

「Spring in Summer ～夏なのにSpring」に行ってきました。
Java向けのアプリケーションフレームワークである「Spring Framework」のユーザカンファレンスです。

summer - 日本Springユーザ会

開催概要


会場雰囲気

f:id:Namihira:20150828133107j:plain

所感

  • 以下のキーワードが盛り上がっていました。
    • Spring Boot
      • SpringFramework界隈で活発なSpringプロジェクト
      • 簡単にアプリ開発、デプロイを実現するための軽量プロジェクト。
      • ＼boot!／ ＼boot!／ ＼boot!／ といった風潮。
      • 個人的には本開発/運用に耐えられるか要経過観察、事例調査。
    • Microservices
      • James Lewis/Martin Fowlerが提唱しているソフトウェアのアーキテクチャパターン
      • ざっくりいうとサービスを一枚岩で作らず、それぞれ独立したサービスの組合せで実現すること（独立＝開発的に。組織的に。デプロイ的に。運用的に。）。
      • SOAとの違いは組織構成やデプロイなどにまで切り込んでいる所。
      • それぞれのサービスを作るのにSpring（特にboot）が最適だよーという流れ。
      • 発表内でもあったように、この思想に沿って厳格に作るというよりか、大規模にサービスをつくろうとすると自然となっていくアーキテクチャ構成。メンバー内で認識合わせのためのアーキテクチャ指針とかをこれに置き換えられそう。
    • 逆にSpring Boot/Microservices以外の発表が少なく、ベタなSpringの話（事例とか工夫とか新機能とか）が少なかった(；´Д｀)（実はそれが一番聞きたかったりする）

セッションメモと雑記

オープニングセッション

  • 日本Springユーザ会 会長さんの話
  • 「Java EE」は最近生意気だ。それを懲らしめるための会。
  • Seasarはもう敵ではない。
  • （所感）
    • 「今回の見所は入館カードが返却されるか、Josh Long（ブラジルから今朝7時成田到着）が無事会場に到着するか？」・・・こういったカンファレンスの運営、大変そう(；´Д｀)

マイクロサービスアーキテクチャの設計

  • 日本Javaユーザーグループ 会長さんの話
  • Micro Service Architecture(MSA)の全体説明。
  • MSAはデザインコンセプト。
    • 分散配置。
      • サービスをサービスで構成する。サービス間はメッセージ（HTTPやRPC）で統合/協働させる。
    • 持続性と分権
      • ソフトウェア開発から、ITサービス運営へ。
  • MSAは新しい理想論ではなく現実論。
    • 調べたら似たような作り方だった。
  • プラットホームを先に決めたら楽だが、技術のロックインとのバランスを考えると必要がある。
  • Springはあるゆる粒度で関係性を管理できる。
  • （所感）
    • Springについてはほとんど関係なかった。
    • MSAについては全く知らなかったので大変勉強になった。
  • www.slideshare.net

大規模エンタープライズにおける、最新のフロントエンド・アーキテクチャへの挑戦

  • モバイル化で技術要件レベルが落ちたが、最近フロントエンドへの要求が高まった来ているので、フロントエンドの技術（フレームワーク）を最新化する必要がある。
  • Springはjarを入れるだけ適用できるのでいい。
  • エンタープライズでもUXへの投資が始まっている。フロントエンドを最新化する必要がある。
  • JFSをJavaScriptで動かすと予期せぬ動きをする場合がある。詳しくないとjQueryが使えない。
  • シンプルにリクエストマッピングができた。
  • 例外の処理。Filterで例外が置きても、後ろに流してそこで例外処理するようにした。
  • コントローラーからコントローラーを呼び出す機能を追加した。
  • クライアントMVCを適用すると、開発の分担が30%(jQueryのみ）から、85%にできた。＃オフシェア時。
  • Javaと一貫性がある書けるようにTypeScriptを使った。
  • （所感）
    • 最近フロントエンドの仕事のやりつつあるので、Springと他のテンプレートの位置づけ関係がはっきりできた。

The Macro of Microservices（キーノート）

Spring DIと大規模プロジェクト、春は来るのか本当に？

  • HUEでのSpringトラブル事例
  • component-scan、Autowiredを使っていたらアプリの起動が遅くなった話。
  • モジュール性の担保。インターフェースと実装を分離するなど。
  • scanしないようにした。独自にbean管理をするようにした。
  • アノテーションベースDIからJavaベースDIへ。
  • @Importもちゃんと使う
  • 人が増えると知識が薄まる。成果物（ドキュメントやjarなど）が多くなる。
  • （所感）
    • DIする際の工夫/こだわりがすごかった。DI/コンテナの仕組みをちゃんと理解していない泥沼にハマりそう(；´Д｀)

The Bootiful Application

  • Josh Longの発表
  • Spring Bootを使ったアプリ開発のライブコーディング
  • 以下のサイトでプロジェクトのひな形を作れる。便利そう。
  • Bootを使うと、LinkRelation的なプロトコルにも簡単に対応できる（HATEOASとかHALとか）。
  • /infoには独自の情報を出せる。例えばビルド時のパラメータなど出力するなど。
  • アプリ起動時に発行されたパスワードでSSHログインする仕組みがある。
  • /healthcheckは200 OKといった情報だけでなく、バックエンドの情報も返すようにしたほうが何かと役に立つ。その仕組みがBootにはある。
  • (所感)

【前半】Spring Framework/Boot/Data徹底活用～Spring Data Redis編～ / 【後半】 Spring適用のアンチパターンとベストプラクティス(仮)

  • リクルートは社内標準フレムワークとしてSpringを全社的に採用することを決定した。
  • Confluence(Atlassian)もspringを使っている。
  • IntelliJがデフォルトでサポートしているフレームワークはSpringだけ。
  • 【前半】SpringからRedisを使う話。
    • 単一構成のRedisならライブラリを取り込むだけですぐに使える。
    • Cacheも簡単に使える。
    • ただRedisがクラスター化されているときつい。ライブラリがサポートしていない。
  • 【後半】これまでSpringを利用していたことで得られた成功/失敗の事例集
    • Wicket（フロントエンド）と同居してSpringを使っていた。
    • フロントエンドの技術進歩は速いため、それに対応するためView部分はフレームワークから切り離せるようにしたほうがいい。
    • アノテーションに従えば責務分担は自然にできる。分担の判断基準はテストしやすいか。
    • SpringはAOPが強い。使いやすい。
    • SpringはViewが柔軟に返せる。
    • 下の層（DBなど）を叩く際は抽象化レイヤーを介する。
    • 独自ライブラリを作る際は着脱可能なものを作る意識をする。
    • まずは理解を深める。調べればだいたいのものが出来るはず。作る前に。
  • DB初期化のフレームワーク作った。
  • あとで調べる
    • @Primary
  • www.slideshare.net
  • （所感）
    • Spring内のモジュール構成の整理がわかりやすかった。Springに沿った構造にすることが綺麗に作るために大切。

Spring Bootをフル活用した継続的デリバリーの実践

  • Spring Bootを使った社内開発フレームワーク作成の話
  • 困り事
    • アーキテクチャが異なるとと学習コストが高くなってしまう。
    • 独自の構成があると対応者が限られてしまい問題解決が遅れる。
  • 以下の資料も参照
  • 共通の開発手法の確立。
  • フレームワークの選定はコミュニティとメンテナンスの活発さで選んだ。
  • プロジェクト自動生成とデプロイのためのスクリプトも提供した。
  • 標準フレームワークの是非はよく話に上がる。
    • 使わなくてはいけないという強迫感があるので、利用を強制しないこと。
    • よく使うデータ構造、ログ機能などはライブラリがあると楽なはず。
  • あとで調べる
  • （所感）
    • モジュール開発のテンプレートだけでなく、それ以外のデプロイのためのスクリプトなどなど周辺の環境提供も大切。
    • 大きな組織になったときのフレームワークの問題はやっぱりなにか起こりそう。「身動きとれない」とか「ライブラリのバージョンが上げられない」などなど。

その他