Spring in Summer ～ 夏なのにSpring

JoshLongを見られただけで価値がありました。 おすすめのセッションは「【R2-2.Spring Bootをはじめる時にやるべき10のこと】」です。

【R1-1.オープニングセッション】

オープニングトークであって、技術的にすごいことを話すわけではないので！との断りｗ

• JavaEEが最近生意気だ！
• JSUGは寺田が嫌い 、とかツイートするなよ！はダチョウメソッドじゃないよ！
• アンケートを書いて回収BOXに入れるまでがイベントです。
• JoshLongは今朝、成田に着きました。

年齢層はそんなに高くないなあ、という印象。

【R2-2.Spring Bootをはじめる時にやるべき10のこと】

資料、サンプルプロジェクトが公開されました。
ぜひ一読を。
http://www.slideshare.net/shintanimoto/spring-boot10
https://github.com/cero-t/spring-boot-kinoko-2015

「はまらない、ミスしない、ミスをリカバリできる。」がフレームワークに求めること。
その点で今のベストはSpringBoot。

#1　SpringBootを知る。
複雑化したSpringプロジェクト群を使った開発を簡単に始められる仕組み。

• フルスタックプラットフォーム
  • いろいろなFWを組み合わせるとハマりがある。

#2　はじめてのSpringBoot
新しいプロダクトの利用時あるある

• ドキュメントがない、英語しかない。
• 少しずつググりながらなんとかしのぐ
  • だから設計ミスをする
    「 はじめてのSpringBoot 」を読んでおけば間違いない。

#3　SpringInitializr
プロジェクト立ち上げ時あるある

• pom.xmlを書くのは面倒で、Exampleからソースのみ削除して流用
• 変なJarが混じってる
• バージョンが違う
  • はまりが発生する。

https://start.spring.io/

• 必要な情報と利用するモジュールを選ぶ。
  • Actuatorおすすめ。
    ダウンロードしたPOMを使って、mvn spring-boot:run

#4　pom.xmlの設計
pom.xmlあるある

• 依存Jarのバージョンを複数のpom.xmlに重複して書いている
• 親子モジュールとか難しいから単一で
  • WebAPIとバッチが同じJarに…

pom.xml のグッドプラクティス

• デプロイ単位、ライフサイクル単位で分割
• 共通部分を切り出す。
• 依存Jarのバージョンは親のpom.xmlに書く
• Spring IO platformを使う。
  • 大げさな名前だが、ただのpom.xml
  • Spring関連だけでなく、著名なプロダクトも含むバージョンを規定したpom.xml

「Mavenは人類には早すぎた」

#5　Controllerの共通設定
java.uril.DateやCaendarはハマりやすい

• 余計な時分秒があるせいで判定を誤る
• Calendarで時分秒に０を入れてもミリ秒が残る

JSR310をSpringBootで使いたい。
ControllerでLocalDateを使う

• なぜかLocalDateはJsonで返せない
• Controllerで利用するJacksonをカスタマイズする。

レーザーポインタなくて、傘を指し棒にｗ

${color:red}「入力は柔軟に、出力は厳格に」%

#6 トランザクション境界の設定
トランザクションあるある

• Controllerをトランザクション境界にする
  • 処理の途中で一度コミットしたいけどできない
  • 途中でコミットできるような仕組みを無理に作ったら全体的な整合性が崩れた
• 性能改善のためのリードレプリカを作りたいが、そもそもアクセスを振り分けられない

Service層をトランザクション境界にする。

• Controllerの次の層をトランザクション境界にする。
  • 処理の単位が明確になる。
  • Service層からReturnすればコミット、例外で戻ればロールバック

原則、ReadOnlyトランザクションを使う

• Service層のクラスすべてに＠Transactional(readOnly=true)をつける
• 更新が発生するときだけ、＠Transactional(readOnly=false)にする
  • リードレプリカへの振り分けが容易に。

#7　O/Rマッパーの選択
O/Rマッパーあるある

• とりあえずHibernate
  • 思ったのと違うSQLが発行された
  • １リクエストでSQLが１万回発行された

「Hibernateは人類には早すぎた」

• じゃあMyBatis
  • SpringBootで標準対応していない
  • SQLを書いたXMLをフォーマットしたらインデントが全部消えた

• じゃあJdbcTemplate
  • なんかAPIが古くさい
  • publicフィールドが使えない
  • JSR310に対応していない

• Bootiful SQL Template
  • JdbcTemplate/NamedParameterJdbcTemplateの独自ラッパーとして作った。
  • SQLファイルをかける。FreeMaker形式も可
  • モダンなAPI
  • publicフィールドが使える
  • JSR310に対応（ZonedDateTimeも）

#8　例外処理の共通化
例外処理あるある

• 個別の開発者任せ。
  • もちろん死ぬ
• フレームワークが返す例外とアプリケーションが返す例外でJSONの形式が違う。
  • クライアント側で判別が必要で死ぬ。

例外処理は共通化する

• ApplicationException extends RuntimeExceptionを作って、必ずこれを使う。
• エラーコードはenumに定義しておき、コンストラクタの引数に必ず渡す。

「すべての例外を共通化してハンドリングせよ」

#9　AOPによるロギング
AOPとは

• アプリケーション横断的に行う処理
  • トランザクションのコミット、ロールバックもAOPで実現されている

#10　テスト設計
テストあるある

• とりあえず、手動でテストしようぜ！
  • 回帰試験で死ぬ
• ロジックがあるControllerからテストすればOK
  • バリデーションの設定ミスで死ぬ
• 通常使うComponentとモックのComponentは＠Profileで切り替える
  • 管理で死ぬ

テストのグッドプラクティス

• Controller以降をJUnitでテストする
  • カバレッジは最低60%、できれば80%を目指す。
• 外部サービス呼び出しはモック化する。

テストのTips

• ＠Componentのモックは@Profileよりも@Primaryをつけた方がよい。

【R2-3.大規模* 長期保守を見据えたエンタープライズシステム開発へのSpring Frameworkの適用】

●TERASOLUNA　Frameworkとは
Struts１でもきちんとパッチを作ってるが、業界の動向を考慮して新たなTERASOLUNA FWの提供を開始。
http://terasoluna.org/

なぜSpring？

• シェアNo1
• JavaEEは仕様策定までに時間がかかりすぎる

ソフトウェアスタック

• SecurityLayer:SpringSecurity
• ApplicationLayer:SpringMVC,JSP,BeanValidation
• DomainLayeer:Spring(TX)
• InfrastructureLayer:MyBatis3,SpringDataJPA

●SpringFrameworkを利用したときの課題
☆Springのバージョン組み合わせ選定

• 各Springサブプロジェクトのどのバージョンを使用すべきか？
• サードパーティライブラリはどのバージョンを使用すべきか？
  • Spring IO Plaformで解決！

TERASOLNA FWが依存、推奨する66ライブラリの管理をIO Platformに委譲。

☆Spring等の膨大な設定

• 必要な設定が漏れていたり、初期値のまま使われてしまう。

☆乱雑なプロジェクト構成
よくある課題

• 複数のプロジェクトで構造の一貫性がとれていない
• コードや設定が特定の環境に依存し、テストのしやすさが考慮されていない

「TERASOLUNAでは以下のようなブランクプロジェクトを提供します。」

• 例や分割したマルチプロジェクト構成
• 環境依存を集約
• 各種設定、ライブラリ依存関係が設定済み

mvnコマンドでブランクプロジェクトを作成できます。

☆不完全な例外ハンドリング* ロギング
以下の４パターンを提供

• try-catch
• @ExceptionHandler
• HandlerExceptionReolver
• error-page

ハンドリングに必要なxml設定はブランクプロジェクトで設定済み。

☆信頼性の低いコードの模倣
FWとしてのガイドラインを提供します。

☆フレームワークの長期利用
すべてのサンプルコードのテストをseleniumで書いています。
リリース前にすべてのAPコンテナ、JDKの組み合わせでオールグリーンを確認。

【R1-4.超高速開発ツールWagbyの技術基盤】

ランチセッションなのでまったりと。

excelでJSONパーサ書いた人がいるので、それを使ったデモ。
Wagbyで作成したアプリをRESTAPI化して、そこから顧客情報を取得→excelのセル埋め。

【R1-5.キーノート The Macro of Microservices】

JoshLongの登壇。
・プロジェクタがうまく動かず、しばらく手間取ったあと「コンピュータはバカだな」とｗ
・38時間かけて日本にやってきたんだよ！
・プロダクションはディズニーより楽しいよ！
・やったーWaterFallだ！なんて喜ぶヤツはいないだろ？

JoshLong、すげぇおもしろい。

https://speakerdeck.com/joshlong/the-macro-of-microservices

【R1-6.Spring DIと大規模プロジェクト、春は来るのか本当に？】

HUEプロジェクトの中でのSpringの話。
まあ、PJの苦労話は鉄板ですわね。

• 社長の「いまどきRDBMSなんてないよね」の一言でCassandraに。

@Autowired使ってますか？

• Springといえば！
• ComponentScanの恩恵は受けたい。

●時間の経過とともに…

• AP起動時間が遅くなっていく
• プロジェクト間の依存関係が
• 依存性の注入って言うけど
  • 結局、何が読み込まれているの？人間の思念ですか？

●結論
Modularityの担保

• 実装とIFの分離
• フレームワークの設定は@Importで管理
• ２重ロードの防止
• 速度の考慮
  • ComponentScanをしないという選択肢

特に問題なく使えてる…はずだったが

●表面的に噴出した問題
依存関係が謎。解決できない

• ComponentScanの推移的依存解決のせい。
• 起動時間が遅い
  • basePackage対象以下のフルスキャンが走るので遅い。
  • Bean生成時の問題
    • コンストラクタでDB読み込み…
• プラグイン的に扱うものは？

●人が増える＝Jarが増える
どんどん遅くなる

• Eclipseだともっと遅い

●ソリューション
フレームワーク開発者

• 速度を重視。Scanをしない。
• @Componentにあたるものは自前で管理。

業務開発者

• 効率を重視。Scanする。

●なぜ？Scanしない？
Scanしない。

• アノテーションベースDIからJavaベースDIへ。
• @Configurationを有効活用
• @Beanも有効活用
• applicationContext.xmlは使わない。
  メリット
• 依存の整理が楽
• テストも一元化
• Grep天国からの決別

●こうすると実は問題が…
N回読み込まれる問題

• 空振りすればよいが、名前が被ると重複登録
  • @GuardedConfigurationを内製しました。

●おまけ：傾聴
開発者の愚痴に敏感に。

• 作りにくい
• 時間かかる
• 何でこれ？
• なんか怒ってる、諦めてる。

バグ管理とかに現れない愚痴が大事。

【R1-7.The Bootiful Application】

ここもJoshLong。
IntelliJユーザは手をあげて？→多数
Eclipseユーザは？→多数
NetBeansユーザは？→いない

「どこにいってもNetBeansユーザがいるんですが、今日は潜り込めなかったようだなhahaha」
「Springチームはみんな禿げてる。みなさんにこのようなサービスを提供するためにがんばっているからだ。」

ライブコーディングに合わせてのお話。
一流の技術者は一流の芸人でもありました。

https://speakerdeck.com/joshlong/the-bootiful-application

【R1-8. 【前半】 Spring Framework/Boot/Data徹底活用～Sprnig Data Redis編～【後半】 Spring適用のアンチパターンとベストプラクティス（仮）】

朝からずっと聞いて疲れたので流してた。

http://www.slideshare.net/yoshidanaohiro52/spring-framework-boot-data-spring-data-redis
http://www.slideshare.net/Yoichi-KIKUCHI/jsug2015-summer-spring