せてぃーずノート

Javaのイベント参加レポートとかを書いたりします。

JJUG CCC 2014 Fallに行ってきました

予定があって夕方に切り上げましたけど、今回は非常に内容が濃かったと思います。
とりあえず、参加したセッションの概要のまとめ。

K-1 基調講演1 : これからのJavaエンジニアの生きる道

技術の変化のための技術

クラウド

  • コンテナ型の仮想化ソフトDockerにより、クラウドプラットフォーム間の移動が簡単にできるようになると思われる。 ** より安く、サービスが充実した環境へ簡単に変えられる
  • Dockerで移動出来るようになったらクラウド事業者はどうなるか データロックインの方向に進むのではないか * データロックイン=データ活用のためのツールミドルウェア、ライブラリを充実。利用者が簡単に移動しないようにする。
  • 蓄積したデータを人工知能に利用する

時代はDockerっぽい。
データロックインという考え方は面白いかも。

人工知能

  • 人工知能に必要なものは認識、意思決定、行動
  • IBMのWatson。想定するユースケースはコールセンターで想定問答集や回答をサポートなど ** 「ロボットは東大に入れるか」という本が面白そう

  • 今、何故人工知能の話題が多いのか?
    ** データ、マシンパワーの増大により、認識やデータ解析の制度が向上。意思決定に使えるようになった。

  • 人工知能はデータが貯まるほど補正される関数
    ** 統計で問題をとくことは、理詰めでは説明できない。でも、なんとなくよく当たる。

  • Watsonは、音声認識→質問解析→検索→回答評価のプロセスで回答を導き出す。

  • 質問解析
    ** 問題からキーワードを抽出する。

  • 検索 ** キーワードをWebで検索し、回答の候補となる単語を抽出
  • 回答評価 ** 回答の候補を更に検索し、質問とマッチしているかを検索

Javaの今後

  • JVMは安定した大規模なWebサービスを運用可能 ** 今後は安定しているJVM上で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 作成

  • PrimeFaces、JPAを利用 ** Seasar2時代もJSFを利用していたため
  • どうもしっくりこない。2サブシステムで終了

SpringMVC

  • 開発をリナックスで行う 文字コード、改行コード、パス区切り文字、レイアウト崩れ
    開発環境はVagrantで配布

  • 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について

  • 業界のトレンドを観察
  • HTML5クラウド対応、簡単開発がテーマ

JSONB

  • JAXBとおなじ感覚で使える

JSONP

  • JSONPointer、JSONPatch、クエリに対するラムダ式を追加予定 JSONPointerは特定の値を参照するための標準(RFC)の構文 JSONPatchもRFCに定義されている
    JSONで記述したパッチを利用して更新 ラムダ式用にJSONCollectorクラスを提供
    ** toJsonArrayのような終端処理が出来る

SSE(サーバセンドイベント)

  • HTTP標準。実装をどこでやるかはまだ未定。 ** JAX-RSで対応するのが今のところ有望

ActionベースMVC

  • コントローラーの部分が未定。
    ** JAX-RSでやるのか、新しく追加するのか

  • Viewの部分はJSPかFaceletを選択できる ** Faceletの場合、Formにアクションを追加。

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でアクセスできるのはいいと思うけど、各サーバは独自実装捨てないといけなくなるから対応が大変そう。

セキュリティ

Javaエンジニアのためのアーキテクト講座

システム開発の現状

  • 「アプリケーションをいかによく作るか」から、「ITサービスをいかに良く運営するか 」への変化
  • 静的な仕様から作る→開発
  • 動的なフィードバックに基づく活動→運営 ** Web業界が先駆者
  • デジタル化 ** テクノロジーが社会に関わる
  • 仕様書に従って安全なコードを書けばいい時代は終わる

アーキテクチャの役割

  • 価値は利用者の体験によって定義される
    ** 一度リリースされたら終わりではない
  • フィードバックに対する持続的な成長
  • これら全体をデザインするアーキテクチャが必要 ** 家を建てる例

    家族がそれぞれ家のパーツを考える。それを形にしてもきちんと整合性が取れたものにならない。
    整合性をとり、かつ地震が来ても大丈夫なシステム。
    フィードバックを受け続け、継続的に保証する。

  • 利用者の動線、時期と作業、それに対応するだけの並行処理、トランザクション増加、負荷を分散させるためのclass分割、作るための要因と手法、KPIとしての評価

必要とされるスキル

  • TOGAFの全部が必要
    ** だけど、全部をやる必要ない。
  • 品質モデルとかは知ってないとダメ。
  • フレームワークの構成とかを考えるだけなのはアーキテクトじゃない。

設計の進め方

  • マイクロサービスアーキテクチャ ** 個々のサービス→データ、ガバナンス、手法も独立
  • 個々のサービスは個々のチームによって開発、運用 ** 責任も各チーム

  • マイクロサービスアーキテクチャの考え方はある ECサイト
    商品登録 カート 決済 ** 配送

異なるドメインとして定義

  • ユーザによって役割が異なる
    ユーザによって利用されるサイクルが違う
    * 変化の境界線
  • それぞれのサービスごとに利用者とサイクルが異なる。
  • ドメインを分割しつつも非機能も考えないといけない。
    ** ECサイトの例。決済のASPダウンしてるから買わせないはダメ

QA

  • Q:アーキテクトが役割を理解してもらうためには? ** A:正しいと思う行動をする。それでもダメなら・・・。
  • Q:プロマネとかぶる? ** A:計画をたてる人がアーキテクト、プロマネは計画を進める。
    IBMはアーキテクトが仕事をした後じゃないとプロマネは仕事ができていないと言われている。

  • Q:経営者は含まれないのか? ** A:経営者はざっくりしか言わないし、言うことも変わる。適当に受け流す。