JJUG CCC 2014 Fallに行ってきました
予定があって夕方に切り上げましたけど、今回は非常に内容が濃かったと思います。
とりあえず、参加したセッションの概要のまとめ。
K-1 基調講演1 : これからのJavaエンジニアの生きる道
技術の変化のための技術
クラウド
- コンテナ型の仮想化ソフトDockerにより、クラウドプラットフォーム間の移動が簡単にできるようになると思われる。 ** より安く、サービスが充実した環境へ簡単に変えられる
- Dockerで移動出来るようになったらクラウド事業者はどうなるか データロックインの方向に進むのではないか * データロックイン=データ活用のためのツール、ミドルウェア、ライブラリを充実。利用者が簡単に移動しないようにする。
- 蓄積したデータを人工知能に利用する
時代はDockerっぽい。
データロックインという考え方は面白いかも。
人工知能
- 人工知能に必要なものは認識、意思決定、行動
IBMのWatson。想定するユースケースはコールセンターで想定問答集や回答をサポートなど ** 「ロボットは東大に入れるか」という本が面白そう
今、何故人工知能の話題が多いのか?
** データ、マシンパワーの増大により、認識やデータ解析の制度が向上。意思決定に使えるようになった。人工知能はデータが貯まるほど補正される関数
** 統計で問題をとくことは、理詰めでは説明できない。でも、なんとなくよく当たる。Watsonは、音声認識→質問解析→検索→回答評価のプロセスで回答を導き出す。
質問解析
** 問題からキーワードを抽出する。- 検索 ** キーワードをWebで検索し、回答の候補となる単語を抽出
- 回答評価 ** 回答の候補を更に検索し、質問とマッチしているかを検索
Javaの今後
社会の変化
- 価値にお金を払わない 例えばKickStarter。まだ製品化されていないのにお金を払う。 クオリティーじゃなく心に響く何かにお金を払っている
まとめ
- 企業が人の成長を見られない状況。だからこそコミュニティは重要。
本当に人のつながりは大事だと思う。。。 というより、企業が人のつながりを軽視し過ぎで、コミュニティが特別じゃないというのが正直な思いかも。
私がTDDできないのはどう考えてもお前らが悪い!~エンタープライズJava開発でのTDD適用の勘所~
どうTDDするかについて?
チームの概要
- BackBone.js+Spring MVC+Spring Batch+JPA
テストケース3800ケース クライアント開発部隊とインテグレーター2社で1チーム *** 初めて顔を合わせるメンバーが多い。手探り。 - ペア組んでユニットテストのコーチング。
進め方
- インテグレーションの中で実装とテストが完結していればOK。
** テストがあることのメリットを感じてもらう - フェイルファストしてないユニットテストは、フェイルファストしているテストと比べて信頼性を欠く。
- 自動でないテストを重視する
** ユニットテストから漏れるバグが有ることを知っておく コントローラーとサービスを優先的にテスト テストで100%を目指さない。
再現性がある、独立しているが重要。
*** それがないとCIに乗せられない技術的負債は改善サイクルに含める ** Tryをちゃんとタスク化する
- 今のチームは問題を指摘したら次のスプリントに乗せてくれる。
** チームの信頼感重要
スローテスト
- スローテストによる開発リズムの悪化はプロジェクトの死因
- データベースを使うテストは遅い問題 データベースを使うことが遅いなら、データベースはプロダクトに使えない テスト実行時間より、テストデータのメンテナンスがスローテストの原因 *** エクセルでデータ管理の限界
- データベースのアサートはテーブル全体に行う ** 差分をとってアサート出来るようにDBユニットをカスタマイズ
- データベースマイグレーションはTDDを実施するのに必須
コントローラー層のテスト
- End to Endに近い条件で。
- DIしたオブジェクトをモックにすると、コンテナ内のオブジェクトが汚染される。
** @Afterでモックオブジェクトを取り除く
リグレッションテスト
デプロイの自動化
- ServerSpecでデプロイスプリクトのコードを検証
なぜTDDするのか
- 「もううんざりです。何も改善できません。」問題
- TDDを導入するために必要なのはチームを作ること
スキルの有無、キャリアの長短を人を測る尺度にしない
「新人だから知らないと思うけど」という考え方は間違い ** IT技術者各人の背景を尊重すること重要
Spring Boot + Doma + AngularJSで作るERP(統合基幹業務システム)
プロダクトの歴史
2007年 seasar2、IE6と7をサポート。
- IE8で動かない問題
- 時代遅れ感の出てきたUI
- リッチなWebサイトが増えて顧客の目が肥えてきた
- 他のRESTAPIとの連携
- 改修より作りなおすことを選択
Java EE 6 作成
SpringMVC
Doma2 S2DAOを利用していたので、移行が楽だった SQLをごりごり書きたい派にはおすすめ。
** 依存ライブラリがない点もいいAngular.js bootstrapのみを使用。ライブラリは自分で作成。
JSFより軽快(当社比) ** バージョンアップで後方互換性が保たれない。Spring開発にTerasolnaのガイドラインが役にたった
Angularは業務で使っても大丈夫 動かなくなったらフロントだけ作りなおせばいいという割り切り 当然コストがかかる
一般的なシステムの償却期間は5年 フロントFrameworkの追従の予算が取れるかどうか。
** とれないならJSFのように一度作れば動き続けるものがよいのでは標準だから、流行ってるからじゃなく、きちんと検証して自分たちに合うものを選ぶ
QA
- 3つのアーキテクチャの連携は? ** 認証はそれぞれ独立。連携する部分は少ない。
Java EE の新たな旅立ち : Java EE 8 へ向かって
Java EE8の具体的な内容について
現時点でのSnapshotのため、コードは変わる可能性あり
Java EE 8について
JSONB
- JAXBとおなじ感覚で使える
JSONP
- JSONPointer、JSONPatch、クエリに対するラムダ式を追加予定
JSONPointerは特定の値を参照するための標準(RFC)の構文
JSONPatchもRFCに定義されている
JSONで記述したパッチを利用して更新 ラムダ式用にJSONCollectorクラスを提供
** toJsonArrayのような終端処理が出来る
SSE(サーバセンドイベント)
- HTTP標準。実装をどこでやるかはまだ未定。 ** JAX-RSで対応するのが今のところ有望
ActionベースMVC
http2.0対応
- Request/Responseの多重化、Streamの優先順位付け、ServerPush ** 今のServletAPIでは、Request/Responseの多重化に対応できない
CDIの適用範囲拡大
- JSRは365
- JavaEE以外でも使用できるようになる
これはちょっと嬉しい。
CDIのモジュール化
- 多くの機能が追加されることによる肥大化の回避。
** DIのみ、CDIイベントのみ、フルセットから選択
EJBの教訓かな。
他機能との連携強化
- JMSとの連携 ** MDBの実装が不要に
セキュリティインターセプタ
サンプルコード見た限り、ごちゃごちゃしすぎて使いづらそう。
仕様削減(pruning)
- EJB2.Xのクライアント
まぁ、これはなくなっていいと思う。
JMX
- JSR77にRESTインターフェースを追加
** JMXがサーバ実装に非依存
RESTでアクセスできるのはいいと思うけど、各サーバは独自実装捨てないといけなくなるから対応が大変そう。
セキュリティ
- パスワードエイリアス、ユーザ管理、ユーザマッピング
- パスワードエイリアスの標準化
- ユーザ管理の標準化。アプリケーションサーバ間の互換性 ユーザソース:データの元ネタ。DBとかLDAPとか。 ユーザサービス:追加・変更・削除 ** ユーザInfo:ユーザの情報Bean
Javaエンジニアのためのアーキテクト講座
システム開発の現状
- 「アプリケーションをいかによく作るか」から、「ITサービスをいかに良く運営するか 」への変化
- 静的な仕様から作る→開発
- 動的なフィードバックに基づく活動→運営 ** Web業界が先駆者
- デジタル化 ** テクノロジーが社会に関わる
- 仕様書に従って安全なコードを書けばいい時代は終わる
アーキテクチャの役割
- 価値は利用者の体験によって定義される
** 一度リリースされたら終わりではない - フィードバックに対する持続的な成長
これら全体をデザインするアーキテクチャが必要 ** 家を建てる例
家族がそれぞれ家のパーツを考える。それを形にしてもきちんと整合性が取れたものにならない。
整合性をとり、かつ地震が来ても大丈夫なシステム。
フィードバックを受け続け、継続的に保証する。利用者の動線、時期と作業、それに対応するだけの並行処理、トランザクション増加、負荷を分散させるためのclass分割、作るための要因と手法、KPIとしての評価
必要とされるスキル
- TOGAFの全部が必要
** だけど、全部をやる必要ない。 - 品質モデルとかは知ってないとダメ。
- フレームワークの構成とかを考えるだけなのはアーキテクトじゃない。
設計の進め方
- マイクロサービスアーキテクチャ ** 個々のサービス→データ、ガバナンス、手法も独立
個々のサービスは個々のチームによって開発、運用 ** 責任も各チーム
異なるドメインとして定義
- ユーザによって役割が異なる
ユーザによって利用されるサイクルが違う
* 変化の境界線 - それぞれのサービスごとに利用者とサイクルが異なる。
- ドメインを分割しつつも非機能も考えないといけない。
** ECサイトの例。決済のASPダウンしてるから買わせないはダメ