JJUGナイトセミナー(11/27)レポート その2
前回の続き
おっぴろげDevOps
どう作って、どう運用しているまでのJava EE導入事例。
RESTAPI経由でのジョブワーカーのアプリケーション。
使っている要素はJAX-RS、CDI、JPA。
Lombokを使っているので、コードの記述量はほんとうに少ない。
JPAはabstractのベースエンティティと実装クラスの組み合わせ。
JAX-RSの応答で使用するため、表示させたくない項目はJAXBの@XMLTransientを使用している。
入力項目はBeanValidationでチェック
Cliteriaを使ってクエリを作っているが、Java8のLambdaでかけるように書いてある。
将来的なLambda対応を今から考えておくのは重要。
テストでは、コンテナを使ったテストは重いため、できるだけユニットテストに寄せる。
JPAのユニットテストは、テスト用のpersistenceXMLを作るのではなく、Mapで必要な属性を上書きする方式。
運用は2つのインスタンスから構成されるクラスタ。
24365を実現している。
モジュールのアップデートは
- dasにアップデートモジュールをデプロイ
- リバースプロキシの振り分けを、片方のインスタンスだけに変更
- JMXから、インスタンス内のサービスが完了していることを確認
- インスタンスを停止して、新しいモジュールを関連付け
- インスタンスを起動して振り分け先を変更する
「DBのカラム変更を伴うアップデートは?」との質問に対しては「ダブルライトで対応している」とのことでした。
JJUGナイトセミナー(11/27)レポート その1
とてつもなく内容が濃ゆい2時間でした。
もう大満足。
レポートは2回に分けてまとめていこうと思います。
CDIを始めよう
CDIとは、コンテキスト(スコープ)を持った、依存性注入(DI)のこと。
Java EEでDIコンテナを使えるようになる。
おさらい
Web3層アーキテクチャを構成する、UI・サービス・DBの各層をどうつなぐか。
newをしてインスタンスを生成する関係でつなぐと、各層で依存性が発生してしまいユニットテストが困難になる。
interfaceを使いたいが、単純に使っただけだとやっぱり実装クラスのnewを誰がするかという問題が残る。
そこでDIコンテナを使い、コンテナがインスタンスを生成することで問題を解決できる。
CDIはJava EE5まではEJBしかできなかったDIを、一般のクラスにも拡張することができる仕組みである。
使うための条件
コンテナが管理するサーブレットやフィルター、EJBなどが対象。
管理対象外のクラスに対して@Injectをつけても無駄。
例外というわけではないが、CDIでインジェクションされたインスタンスには挿入してくれる。
なので、 JAX-RS→CDI →JPAというチェーンをすることは可能。
EJBとの違い
CDIはEJBの特権とも言える、宣言型のトランザクションもできるようになった。
EJBにない、EL式との連携や細かいスコープ(SLSB、SFSB)制御もできる。
じゃあEJBっていらないの!?
逆に、EJBができてCDIができないことは非同期実行、MQ連携、リモート実行、タイマー機能が挙げられる。
これらの機能はWeb構築では使わないが、基幹系では必要になる。
WebアプリケーションならCDI。
基幹系で大規模なシステムならEJB。
そんな使い分けができると思う。
ただ、分散オブジェクトはいらないと思うけど。
とりあえず、今日はここまでで・・・。
SIerの現実
とりあえず、自分は@kisさんよりです。
SIビジネスは必要不可欠なのに何故ダメ出しされるのか - GoTheDistance
優秀な人(上のエントリで言うプロだけじゃなくプロフェッショナルも)はもはやこの業界には残っていません。 残っているのは「技術力のない高級取りの元請け」と「技術力のない下請け」だけです。 技術力のある人はこの業界の行く先がないとわかってさっさと逃げ出してます。
最近の悲劇は、不景気で案件が数や質とも減り、大手SIer(FやNとか)が外注に出すお金がないことです。 技術力があって自分たちでできるから内製ではなく、外注に出すとお金が外に出るから連結決算内での内製を推進しています。 今まで金勘定だけやっていればよかった人たちにシステム開発等できる訳ありません。 結果として、いわゆる下流工程で仕方なく外注を出します。 外注に出しても「上流がダメでも下流でリカバリ」できません。 外注側も優秀な人は抜けているので、「言われたことしかできない」という低い目標でしかできません。
SIer周辺には「未経験歓迎の中途採用」と「技術力よりコミュ力」という人材しかいません。 ユーザ企業の業務や戦略を考えられる人がいません。 SIerも外注も保身だけしか考えていません その方法として「契約書」という手段がはびこっているんだと思います。
【JUnitメモ】static変数に注意
static変数を含むクラスをテストする場合、テスト前にかならず初期化すること。 失敗すればまだマシな方です。 最悪の場合は、「テストメソッドの実行順によって、うまく行ったり行かなかったりする」とか「間違った値で動くのを正常としちゃってバグを作りこむ」っていう悲惨な事態になります。
public class Static変数テスト {
private static int num = 1;
@Test
public void 値を変更() {
num = 3;
assertEquals(3, num);
}
@Test
public void 初期値確認() {
assertEquals(1, num);
}
}
すごく適当なサンプルです・・・。 テストメソッドごとにnumは初期化されません。 よって、先に「値を変更」テストが動くともう「初期値確認」テストは失敗します。 逆の場合は成功します。
当たり前って思うかもしれないんですけど、知らない人は知らないんですよね。 これをJenkinsでビルドしたりするとたまにコケる。 担当者に聞いても「うちの環境じゃ大丈夫」って言う。
FF6発売から20周年ですって
1994年発売なので、来年は20周年。 あの頃は発売日の前にゲームが手に入った時期。 むしろ、以下に早くゲームを買うかの競争。 そのためにゲーム屋のおじちゃんと仲良くなったり。
しかし、20年か・・・。 20年の間に何万人のシャドウが見捨てられてきたんだろう・・・。
秋のJJUG CCC雑感とか
体調悪い&モチベーション低下中のだったけど行ってきました。
午後の4つ目が終わったところで帰ってしまいましたが、なかなか考えさせられるイベントでした。
盛り上がって・・・ない?
今までのCCCだと、基調講演はホールに入れない人とか出ていた気がします。
ホールでのセッションも席は満席、立ち見もありくらいの印象です。
でも、今回は普段よりは参加者が少なかったような気がします(小さい部屋は満員になってましたが・・・)
前の方に座っていたからかな・・・。
地味なJava EE
前回は「Web Socket!Java Batch!いよいよリリース!」っていう勢いだったので、それと比較すると酷ですが、あまりネタが無かった気がします。
どちらかと言うとGlassfish4以降は商用サポートしないっていうマイナスのニュースが響いているのかも。
今回のメインであったavatarは面白いアーキテクトだと思いますが・・・。
リーンスタートアップ
ユニットテスト改善ガイドは非常にためになった。
今までユニットテストはやって当然と思っていて、導入するためのコストやハードルの高さは意識していなかった。
上司を説得しないといけないという状態にはなったことはないが、今後そういう自体になるかもしれないことは覚悟しておく必要があるかも。
そしてその次のセッションのリーンスタートアップ。
その話を聞きながら、ユニットテストもリーンスタートアップで導入するのがありなんじゃないかと考えたりもしました。