システム開発で思うところ

JavaEEを主にシステム開発をしながら思うところをツラツラを綴る

思い付きのストック(WebFW)

自分向けの書き溜め(思いついたときに書き足す)。
いつになるか分からないけど、自分なりのJavaEEに薄いラッパーをつくるにあたって、やっておきたいこと。今のシステムのベースとして既に作り込んでいるものも含めて。既に実装しているものについても拡張性や交換可能性まで考慮は至っていないところばかりなので、その辺の見直しも含めた指針。
また、JavaEEがあると楽に環境が準備出来るけど、現状の私自身はTomcatを使っていることもあり、JavaEEに強依存した仕組みには極力したくないと思っている。

なぜ

JavaEEにしてもSpringにしても、セキュリティとかログとかインターセプターとか、なにかしらラップをするものが必要だと思ったから。また要件によって独自実装をする領域を基盤となるフレームワーク(JaveEEとかSpringBootとか)に挟んでおくことで、柔軟な拡張ポイントを確保することも出来るし、それが出来た方が良いと思う。 やりたいことは、すべてに対応するフレームワークというよりも、どこで何を拡張するのか分かりやすいフレームワーク
場合によっては、作業指針にとどまるケースもあると思っている。例えば、DB周りのツールとしてDomaを使う場合、Domaに依存させるのは、このレイヤーまでに留めて、ドメイン領域には浸食しないようにしましょう、みたいな。
考えているのは「書き換えを前提としているフレームワーク」とか「作法を規定するので中身はご自由に。一応、自分なりに便利だと思うコードは準備しておくけど、好きに書き換えてもらっていいですよ」というユルーイもの。つまり、オレオレフレームワークの雛形みたいなもの。

自分で動機を整理しつつ「こんなもの誰がいるのかな?」という思いはありつつ、自分自身が仕組みを作る中で試行錯誤した経緯を考えるとオープンなもので1つくらいあっても良いかなと改めて思ったので、とりあえず出来るだけやってみたいなと思う。*1

何を

共通部品

認証・認可

独自実装:あり
インターセプトで実装。現状はセッションのユーザー情報で保持している権限と、Controllerで指定した権限とのマッチングで制御している。
できればOAuth2みたいな感じで認証サーバーとの連携するようなサンプルまで出来たら素晴らしいんだろうな。

セキュリティ

独自実装:一部あり
CSRFXSSセッションハイジャック、といったところを仕組みとしてまとめたい。今はクローズドな環境で、更新をするユーザーが ごく限られているので、このあたりは後回しにしているけど、必ずほしい機能。

ログ

独自実装:あり
インタセプターによる自動ログ出力と、Producerによる実装をしてはいる。ただ、ログファイルの制御がいまいちちゃんと出来ていないとか問題が多い。。ログについては使用したいツールがシステムによって異なると思うので、そのあたりの置き換え容易性などを考慮した整理とあわせて、ちゃんと見直しをしたい。

例外

独自実装:あり
アプリケーション独自例外が、ログ出力とかメッセージ出力とかツールチップ制御とか、ごちゃごちゃになってしまっている。もっとスッキリできると思うので、ちゃんと見直しをしたい。もしくは、ドキュメントを整理して利用や改修をやり易いようにしておきたい。

バリデーション

独自実装:あり
メッセージの置き換えや、ツールチップの出力位置の情報共有については、自分なりに一旦は実装できたと思う。ただ、メッセージとバリデーションが密結合になっているので、そのあたりをもっと整理したい。
JSFのメッセージ出力とツールチップ出力と強依存の実装になっているところもある。ダメではないような気もするけど「パーフェクトJavaEEJavaEE」のCDI(2章)を読んだ印象では もうちょっと良い感じな整理が出来そうな気もしている。

国際化対応

独自実装:なし Resourceの汎用読み込みは実装済み。
propertiesを都度参照してメッセージを探すのではなくて、Enumで定数にしてパンチミスなどの発生させないようにしたい。 (propertiesからEnumAnnotationProcessorで生成する仕組みを検討中)

プレゼンテーション関連

メッセージツールチップ

独自実装:あり
例外時に限った実装になっている。例外とは分離させて、ツールチップ単体として完結したものにしたい。例外時には部品としてそれを使用するイメージ。

Ajaxによる更新

独自実装:あり
過去のブログは、現システムのエッセンスを抽出したものに近い。パッケージとして整理さえすれば良いだけかもしれない。

サブ画面制御

独自実装:なし

ダイアログとか子画面とか、そういう感じのもの。個人的には避けたい実装だけれど、実際の要件としては良く挙がっているネタなので。
PrimeFacesとかリッチコンポーネントもあるけれど、ここで試したいのは、サブウィンドウ。
参照サブウィンドウではなく、登録サブウィンドウ。 モーダル制御までするのであれば、それはHTML5とかPrimeFacesとかの出番なので、それは関与しない(ブラウザの挙動ではモーダルを保証できないという過去の経験より)。
この辺は、全くの無知なので、落としどころも含めて考察から必要。

モーダル画面連携

独自実装:なし

「サブウィンドウ」ではなくて、モーダルダイアログへの連携。クライアント側の実装については、各種クライアントフレームワークjQueryでゴリゴリとかやり方はたくさんあるので、そちらにお任せ。あくまで「連携」をするための仕組み、もしくは作法の整理。
この辺は、全くの無知なので、落としどころも含めて考察から必要。

ドメイン関連

カテゴリは設けたけど「POJO」であることがポイントになる気がするので、フレームワークとして設けないといけないことは、今のところ思いつかない。

永続化関連

DB操作

独自実装:あり

外部SQLファイルの参照について、独自に作り込んで「しまった」。このメモを整理している中で調べて見たら方法があったようだ。。

SQL文を外部ファイルに|老いぼれSEの艱難辛苦

ただ独自の実装といっても、指定のクラスパス内の指定クエリー名を読み込むだけのシンプルなもの。結局はNativeQueryで使用する文字列をどうやって渡すのか、というだけの話だから、これはこれで残しておいても良いかな、とも思う。それに上述のリンクは「NamedQuery」の話みたいだから「NativeQuery」でも同じかどうかは検証が必要になると思う。また、外部SQLファイルの検証を考えるとXML定義にしておくよりも平文SQLファイルの方が扱いやすい気がする。

現状の方式は、DBからNetBeansでEntityクラスを生成+基本となるクエリーは自動生成しておき、その他に必要な問い合わせをJPQLや外部SQLで作成をしている。Entityクラスの自動生成は色々な方法があるし、プロジェクトによってはExcelから自動生成をすることもあると思う。個人的にはDBからの取得結果のDTOとして充足していれば、それで良いと思っている。なので、ここでは、自動生成したEntityクラスに手を加えるのではない方式を整理できればと考えている。

少なくとも、今は自動生成したEntityクラスに問い合わせクエリーを記述したり、しなかったりと統一していないので、そこは見直したい。

また、これを言ったらどうしようもないんだけれど、永続化周りについては、DomaMyBatisDBFluteとか仕様としてのJPAすら適用外になることも多そうだし、SQL生成および外部SQLの読み込みそのものについても、採用する技術要素によって大きく変わってくると思う。

検討する指針としては「どのような技術要素でも、永続化においてドメイン領域と明確に分離する整理が出来ていること」「どのパッケージで、どういうことをするのか明確に整理すること」をポイントにしたいと思っている。なので、私が実装した外部SQLファイル読み込みの仕組みに強依存しない方が良いと思っている。

トランザクション制御

独自実装:あり

アプリケーションサーバー(Tomcat)のシステムのため、トランザクションEntityManagerを使って行っている。現状はEntityManagerに基本操作を加えたラップクラスを設けている。それはService層でEntityManagerを直接操作をするのを避けたいという考えから。
正直、トランザクション境界であれば、EEサーバーを使うことで、こんなことをしないでも良いと思う。 どちらかというと、ここで検討しておきたいのは、@Transactionalを直接使用しないことと、トランザクション境界をControllerの操作境界と同じようにログ出力などを同時にするようなインターセプターを実装することを想定している。
たとえば、EEサーバーとアプリケーションサーバーをそれぞれ分けて検討して、EEサーバーの場合、トランザクション境界は@Transactionalを使用することで解決しつつ、処理の前後のログについては独自に実装したインターセプターを作成する、とか。
まずはアプリケーションサーバー(JTAの実装を持っていないサーバー)から実装を作って、EEサーバーだと こんな風に書き換えたら良いと思いますよ、みたいな参照実装が作れたら良いなぁと思っている。

どのように(サンプル)

どんなものを作る?

フレームワークに限らず、道具は実際に自分が使ってみて嬉しいものであることが一番大事。そして、できればサンプルのためのサンプルではない方がさらに良い。
ということで「ユーザー登録」あたりが一番いいかなぁと思っている。 出来ればJavaEEでモノリシックなものと、Restなマイクロサービスっぽい感じの2パターンが作れたら良いかなぁ。
なんとなーく、この2つが出来たら、一見モノリシックなJavaEEな実装に見えるけど、フレームワーク部分が頑張る事で裏ではマイクロサービス風な仕組みが動いている、みたいなことが出来そうな気がしている。
一番の課題はトランザクション関連になると思っているし、そこについて問題が解消できるとは正直思っていないんだけど、なんとなーく構想だけはあるので、そこまで出来たら個人的には大満足。

パターンは?

同じユースケースでも、オペレーションは様々あると思っているし、いくつかのバリエーションを設けておくことで有用なサンプルになると思っている。

  • ショッピング風

SAStrutsの登録ユースケースのイメージ。入力→確認→完了、のパターン。
JavaScriptなどの無いシンプルなWebシステムらしい感じのパターン。

  • SPA

1画面でリアルタイム(またはSubmitで)登録するイメージ。問題は通信上の情報改竄を仕組みとしてどうやって回避できるのか、だと思う。「ショッピング風」は実際の登録情報はサーバー側に保持しているもので処理をするので、そのあたりの心配はないけれど、SPAの場合どうなるのか調べるところからになると思っている。
Restにおけるセキュリティと同じような課題になるかなぁと何となく考えているので、ここをちゃんと解消できたら色々と幅広い領域についても安心なものになる気がしている。

  • サブウィンドウ

登録用サブ画面を使うパターン。クラサバだとよく出てくるパターンと思っている。
SPAが出来たとしたら、このパターンも割と安全に実装できそうな気がしている。 あとは、親画面の方に良い感じに情報を連携できるのか?というところが課題になりそう。できるだけJavaScriptでリッチな実装をしないという風にしたい。

  • 一覧処理

新規登録ではなく、既存データの修正をする場合のパターンとして、一覧から直接部分的に修正をする。これもクラサバだとよくある気がする。

  • 大量処理

所謂、ファイルダウンロード&アップロードによる更新処理。個人的にCSV(カンマ区切り)は好きではなく、TSV(タブ区切り)の方を選びたい。ただ、それはそれで多くの人になじみがなさそうなので、見栄えの調整もしやすいExcel形式を考えている。
ここについてもポイントはファイル形式ではなくて、仕組みの方になるようにしたいと思っている。例えば「CSV形式にしたい場合は、ここの部分を変更したら良いんだな」と分かりやすいようなクラス分割をする、みたいな。

今回は会話型で対応しうる大量処理を前提にするに留めて、対応するのは同期・非同期の制御までは出来たら良いかなと思っている。

大量処理というと「バッチ」になると思う。ただそういうのはWebからトリガーするというだけでなく、タイマーとかコマンドで実行するフローになると思うので、今回の構想には入れないつもり。またバッチ処理については、自分の中でコレでいったん整理してみよう、という構想すら持ち合わせていないからという後ろ向きな理由もあったりしますが。。だからといってバッチを甘く見ているわけではなく、元バッチCOBOLerだった私としてはバッチ(分散処理・大量処理)の重要さは経験的に理解しているつもりではいます。むしろ、WebFWと混ぜてはいけないと思っていて、中途半端な整理はしたくないなぁと。まぁ言い訳ですね。

*1:思うだけで終わる可能性も十分ありますが

JJUG CCC 2017 Spring に参加してきました

日本Javaユーザーグループ 年次総会

ここから話題ににする必要があるか分かりませんが、会長の鈴木さんの話し方は妙に安心感があるなぁと毎度のことながら感心しきり。

大事な事

  • 申し込みしたけど参加できない場合はちゃんとキャンセルしましょう
  • キャンセル待ちを諦めないで!

ふつうのJavaコーディング

ふつうのJavaコーディング #ccc_e1 // Speaker Deck

印象に残ったところ

  • コードは読み物
  • メソッドは高次元に特化したものに
  • 防御的プログラミングを避ける
  • ギリギリまで文字列に頼らない
  • 型と向き合う(DDD的なことだと思う)

業務アプリにおける実装としては正しいことが多いと思った。ただ基盤的なところの実装については(コアAPIとまではいかないけど)ある程度 汎用的であった方が個人的には分かりやすいと思う。いずれにしても、その汎用的なものは業務アプリに落とし込む過程で「特化した実装」にした方が良いと言うのは賛成。

ちょっと考えたところ

  • 固定値の引数はメソッドを作る
    型がEnumでメソッド名と定数の組み合わせで文章として成立していたら可読性は保たれていると思うんだけどなぁ。どうなんだろ?
    でもコンストラクタのパラメータで属性を分類するのではなくて、それはクラスで実装するから、正しい気もするな。
    ひょっとしたらサンプルのメソッド名がドメインを表現するような命名だったら印象違ったのかな? 基本思想としては賛成だから、賛成で良いかも。

Java Clientで入門するApache Kafka

基本知識が無かったので駆け足で理解できた。話し方も丁寧だった。 過剰にモックを準備することなく、ローカルでテストするためのやり方を具体的に目にすることが出来たのは、とても良かった。 これってController層とService層の間の通信をKafkaで疎結合させたら冗長性を簡単に拡張出来るのかな?と思った。

Selenideを使ってみた ブラウザテスト自動化

ブラウザのテストは現状、手作業でやっているけど、Selenideは機会があったら使ってみようと思った。自動化に頼りすぎないというのも良い知見だと個人的には思う。

Javaで実装して学ぶOAuth 2.0

Javaで実装して学ぶOAuth 2.0! // Speaker Deck

  • 対象とするのは認可(認証じゃない)
  • 登場人物の名称と定義を正確に理解するべし

歯ごたえのある内容だったので大変満足。
誤解しがちなところを強調して下さったので、雰囲気での理解から一歩踏み出せた気がする。 結構、自分で実装しないといけないところがある低レベルフレームワークなんですね、という印象。よく言えば汎用的で幅広いのかな。
触ったことは無いけどApache Shiroみたいな感じのものがあると利用しやすいのかな?

Java x Arduinoで始めるIoT

格安のクライアント環境をテスト的に準備してみようとRaspberry Piを試してみたことはあったけどIoTという感じではなかった。
値段も安いし、ハンダも不要のArduinoは、いろいろと試すのには面白そうに思った。
JJUG的な側面の話は少しだったかもしれないけど、こういう話があるのもJJUGの面白さだと思う。

さいごに

以前、お仕事を一緒にさせていただいた方に会って、懇親会はLT大会そっちのけで、その方と話をしたのが何気に充実した時間だったり(笑)
縁とは不思議なものだと思うのと共に、興味の範疇が似ていることが面白かった。
新しい情報が少ないのでJJUGで取り上げられる機会が少なくなっていますが、JavaEEJSF・Facelets含めて)ってそんなに悪くないと思うんですけどねぇ。。良い感じに復権していただきたいところです。

セミナー資料のまとめ

自分向けのメモ

Java Day Tokyo

Java Day Tokyo 2016

Java Day Tokyo 2015

Java Day Tokyo 2014

online20130514-javaday

JJUG CCC

JJUG CCC 2017 Spring ( #jjug_ccc ) - セッション資料の一覧 - 地平線に行く

GitHub - jjug-ccc/slides-articles-2016fall: JJUG CCC 2016 Fallの発表資料およびブログ記事まとめ

JJUG CCC 2016 Spring ( #jjug_ccc ) - セッション資料の一覧 - 地平線に行く

JJUG CCC 2015 Fall ( #jjug_ccc ) - セッション資料の一覧 - 地平線に行く

JJUG CCC 2015 Spring ( #jjug_ccc ) - セッション資料の一覧 - 地平線に行く - 地平線に行く

JJUG CCC 2014 Fall ( #jjug_ccc ) - セッション資料の一覧 - 地平線に行く

JJUG CCC 2014 Spring ( #jjug_ccc ) - セッション資料の一覧 - 地平線に行く

JJUG CCC 2013 Spring の発表資料について | 寺田 佳央 - Yoshio Terada

AWS Summit Tokyo

AWS Summit Tokyo 2016 セッション資料・動画一覧 | AWS

AWS Summit Tokyo 2015 開催レポート動画・資料一覧 | AWS

AWS Summit Tokyo 2014 開催レポート動画・資料一覧 | AWS

AWS Summit Tokyo 2013 レポート セッション動画・資料一覧 | AWS

  • 行ったことは無い。面白そうな資料がありそう。

勉強会の情報

自分が参加したことがある勉強会・カンファレンス・セミナーの情報です。
私が参加しているものは無料のものばかりです。ちなみに、私はヘタレなので複数人によるワークショップではなく、セミナー型の聴講タイプのものにしか参加していません(意図せず、ワークショップになることもありましたが)。
ハンズオンや参加人数が少ないものも基本的に参加していません。私は「その他大勢の一人」でいたいので(ヘタレです)。逆に言えば、私のようなタイプの人でも参加できそうなものを紹介しているともいえます。良い意味で敷居が低いと思いますので 興味を持たれたら まず参加してみてはいかがでしょうか?

UMTP

UMTP Japan - セミナー・イベント情報

  • 今はアジャイルのワークショップもやっているみたいですね(未参加)。モデリングだけでなく、DDDやスクラムなどモダンと言われる開発手法全般に守備範囲を広げているとは思っていませんでした。
    UMLの勉強会の内容は書籍だけで黙々とやるのとは違って人の話として聞くのは刺激も含めて参加して良かったと記憶してます。オブジェクト指向UML(DDDも?)に興味があって有識者の話を聞いてみようと思うのでしたら、是非参加されることをお勧めしたいです。講師の方は皆さん質問のしやすそうな方ばかりだったと記憶しています。

  • モデリングについては基本的に固定の内容で実施しているようなので、レベル毎のものを一度参加されれば良いと思います。

OSS-DB

イベント・セミナー|DBスペシャリストを認定する資格 OSS-DB技術者認定試験

  • PostgreSQLの勉強会です。基本的なSQLの書き方というのも多少はありますが、メインはDBの仕組みなどの技術的な話です。私はそちらの方が聞けたので非常に良かったです。ログの話などバックアップ&リカバリーに関係する話もありました。たしか、こちらは勉強会の後、質問させていただいた記憶があります。丁寧に答えていただけたと思います。PostgreSQLは使わないから、という理由だけで聞かないのは勿体ないと個人的には思います。DBも広い意味ではファイルシステム(オンメモリ―でも)だということを理解できましたし、それは多分、本質的には他のDBでも類似だと思います。

  • 基本的に固定の内容で実施しているようなので、レベル毎のものを一度参加されれば良いと思います。

JJUG

日本Javaユーザーグループ

  • Java全般の事を学べる場所です。JavaSE、JavaEEJVM言語、DDDなどの設計関連など多岐にわたります。個人的には一番知りたい情報を収集できる場です。
    ナイトセミナー(月1回)は情報公開当日にほぼキャンセル待ちになるくらい人気。
    JJUG CCC(年2回)で技術動向が分かったり、他の開発現場の話を聞けたり、書籍を執筆者やアクセス数の多いブログの中の人に出会える場でもあります。私は懇親会に参加したことはありませんが、参加すれば より面白いかもしれませんね(人によっては)。

  • 内容はイベント毎に異なります。

JSUG

日本Springユーザ会 | Doorkeeper

  • Springは使っていませんがJavaEEとの違いや技術動向を知っておきたいという意図で参加しました。JavaEEは技術標準として、SpringはOSSの代表という感じと個人的には思っています。どちらが良いというのではなく、どちらも大切だと思います。一応、なんでもかんでも参加はしていませんが、私のようなアプローチはキャンセル待ちになってしまった人からすれば迷惑かもしれませんね。。とはいえ、JavaEEから離れるとしたらOSSとしてのスタンダードだと思われるSpringは選択肢になるので情報取集はしておきたいんですよね。
    (でも正直、JavaEEって そんなに悪くないと思うんだけどなぁ。)

  • 内容はイベント毎に異なります。

Java Day Tokyo

  • 個人的にはJJUGの延長的な位置づけです。Oralceが主催をしているということもあると思いますが、Java標準(JSR的な)の情報を知ることが出来ます。今後のJavaSEやJavaEEのリリース情報なども、このカンファレンスならではなのかもしれません。

Google Atmosphere Tokyo

  • Googleの情報収集。便利な機能や技術動向を収集するために参加しています。年に1回なので定期イベントというと語弊があるかもしれませんね。 Googleを採用しなくとも、類似のクラウドプラットフォームはあります(マイクロソフトとか)。情報システム部の方であれば技術要素よりも仕事改善の手法という意味で、聞くだけでも価値はあるのではないでしょうか。
    また、すでにGoogleAppsを導入している方であれば、より便利な活用方法の情報を入手できる機会になるのでお勧めです。

Developers Summit

  • デブサミ2017から参加しました。技術者の集いという感じでしょうか。ただ紹介される技術範囲が広いので逆に薄いという印象にも。普段自分が関わってこなかった情報を入手できるという意味では良かったと思います。

POStudy

POStudy ~アジャイル・プロダクトマネジメント研究会~ | Doorkeeper

  • 言語を固定しない、アジャイル開発のプロセスに関する勉強会です。私が参加したものは「その他大勢の一人」でいられたものでしたが、基本的にスクラムなどの実践やワークショップというのが多いみたいです。コミュニティの目的を考えるとそちらが正しいと思います*1

あとがき

基礎技術としてUMTPOSS-DBはお勧めです。私が技術的に聞きたいことをバランスよく聞かせてもらっていると思うのはJJUGです。
とりあえず、どんなことをしているのかな?というのは全てではないですが過去の資料が公開されているので、それらを読むところから始めても良いかと思います。

*1:ですが、いかんせん私はワークショップ系は得意ではないので。。。

JavaEEのメモ

自分向け

未分類

JSFでエラーのある項目の背景色を変える - じゃばらの手記

  • 自分でも似たようなことをしているけど、全く違うやり方。
    いつか、ブログにまとめたい

認証

Java アプリケーションコンテナに依存しないユーザー認証 : まだプログラマーですが何か?

  • JavaEEとはちょっと違うけどメモ。

未分類メモ

自分向け

Java関連のスライド

Minazou67, Software developer | SlideShare

仮想化

VagrantとDockerについて名前しか知らなかったので試した - Qiita

データベースのメモ

自分向け

基本

「理論から学ぶデータベース実践入門」読んだ - $shibayu36->blog;

  • 多分、この資料の勉強会(?)は、直接聴講したと思う。

ロック

JavaでRDBデッドロック検出 - Qiita

データベース - Webアプリケーションのデータ更新で楽観ロックを使う理由について(5504)|teratail

i am BEST : 楽観的ロックに必要な悲観的コーディング(2)

排他制御のあれこれ - Qiita

他の人にも勧められる書籍