メソッド名に見慣れない単語があると不安になる

処理の内容を端的な名前で表現できないとき、必要以上に複雑さを抱えている可能性があると考えていいと思います。なので、calculateXxx みたいな抽象的なメソッド名を業務ロジックの中に見つけると不安になります。そして、だいたいそういう名前のメソッドは処理が長くて多くの責務を持っている傾向にある気がします。あと、execute とか。バッチアプリケーションのエントリポイントとかであればいいんですが、これも業務ロジックの中に出てくるような名前ではないと思います。

メソッドの命名については、CRUD ごとに分類するとだいたい以下のようなパターンになるのではないかと思われます。他にもいろいろあるとは思いますが、とにかくシンプルに端的な名前が付けられないときは一旦立ち止まって考え直した方がよさそうです。あと、createXxxYyyZzz みたいに目的語(?)が多いときとか。

Create 系

  • create : オブジェクトを生成する
  • generate : ファイルを生成する (ファイルシステムへの書き込み)
  • insert : DB に新しくレコードを作成する

Read 系

  • get : オブジェクトのプロパティ値や計算結果を返す
  • load / read : ファイルシステムやストリームから読み込む
  • fetch : ネットワーク越しに読み込む
  • find : DB やオブジェクトの集合などの検索結果を返す
  • is / can / contains : オブジェクトの状態や操作の許可を返す

Read 系の処理の中では副作用があってはいけない。必要なデータが存在しない場合、デフォルト値を返すか、例外とする。安易に null を返してはいけない。あと、find ではリストや Optional を返す。リストを返す場合、条件に一致するものがなければ空リストを返す。null は返さない。

更新系

  • set : オブジェクトのプロパティ値を変更する
  • update : DB の既存レコードを変更する
  • write : ファイルシステムやストリームに書き込む

set については可能であれば immutable にしたいところ。

削除系

  • delete : 完全に削除する (物理削除のイメージ)
  • remove : ある集合から取り除く、別の領域に退避するイメージ

deleteremove はできるだけ使い分けたい。

Java EE (Jakarta EE) 周りの名称や用語のメモ

Java EE (Jakarta EE) 周りで似たような名称や用語によく出会うので、簡単に調べてまとめてみました。個々の詳細や比較については書いてません。また、間違ってる箇所があるかもしれません。他にもいろいろあるので随時追記していこうと思います。たぶん。

Java EE / Jakarta EE

Java Platform, Enterprise Edition の略。旧称は J2EEエンタープライズアプリケーション開発で利用される機能の仕様をまとめたもの。2017年に Oracle から Eclipse Foundation に移管されて、Jakarta EE に改称。

Web ProfileJava EE の一部の仕様を抜き出した(?)もの。

EE4JJakarta EE を管理するプロジェクト。これは Java EE の頃から同じ模様。Eclipse Enterprise for Java の略。

GlassFish

Java EE アプリケーションサーバー。Java EE から Jakarta EE の改称に併せて、Eclipse GlassFish に改称。

WebLogic

Java EE アプリケーションサーバー。正式名称は Oracle WebLogic ServerGlassFish とは別のものと捉えてていいと思われる。

MicroProfile

Java EE をベースにしたクラウドやマイクロサービス向けの仕様。Java EE の一部ではなく、補完するものという位置付けの模様。現在は Eclipse Foundation で管理されている。なので、正式名称はおそらく Eclipse MicroProfile と思われる。

Payara / Payara Micro

GlassFish ベースのアプリケーションサーバー。Payara Micro は、Eclipse MicroProfile 互換で、クラウドやマイクロサービス向けのアプリケーションサーバー。

JBoss / WildFly

Java EE アプリケーションサーバー。商用版は Red Hat JBoss Enterprise Application Platform で、OSS 版は WildFly と呼ばれる。WildFly の旧称は JBoss Application Server

WildFly SwarmJava EE アプリケーションを実行可能 jar として生成できるもの。現在は Thorntail という名称らしい。

WebSphere

IBMJava EE アプリケーションサーバー。正式名称は WebSphere Application Server

WebSphere Liberty / LibertyProfile

WebSphere Application Server の一部で、アプリケーションサーバーの ランタイム

Open Liberty

WebSphere Liberty の OSS 版。

補足

Tomcat や Jetty は、JSPServlet など Java EE の一部を実装したもの。なので、Java EE アプリケーションサーバーではない。

GraphQL を Spring Boot で試してみる

最近、GraphQL が気になっています。学習を兼ねて簡単なサンプルを作ってみようかと。今回は Spring Boot 版で試してみます。

サンプルコードはこちら。

kntmr/playground - GitHub

GraphQL

graphql.org

2016年頃に登場してしばしば名前を見かけることはあったのですが、特に自分の観測範囲ではあまり盛り上がりを感じられず...。ただ、REST API の煩雑なところをいい感じに解決してくれそうで、今さら魅力を感じるようになってきました。

よく言われる GraphQL の特徴は以下のあたりかと思われます。

  • エンドポイントを1つにまとめることができる
  • 1リクエストで必要なデータを取得できる
  • スキーマファースト (ドキュメントファースト)

とはいえ、レスポンスとして返して欲しいデータをリクエストで指定したり、Swagger などを使うことで同等のことは実現できると思いますが、当然、サーバー側でそれなりに実装したり、ツールを導入する手間はかかるわけで、そのあたりは GraphQL を使うメリットになりそう。あと、今回は試してないですが、コードを自動生成するツールもあるようです。

あと、AWS がマネージドサービスとして提供するようになったので、これからグイグイ来るんではないかと思っています。

aws.amazon.com


以下、備忘録。

依存ライブラリ

GraphiQL を追加すると、/graphiql で GraphiQL が使えるようになる。

<dependency>
    <groupId>com.graphql-java</groupId>
    <artifactId>graphql-java-tools</artifactId>
    <version>5.2.4</version>
</dependency>
<dependency>
    <groupId>com.graphql-java</groupId>
    <artifactId>graphql-spring-boot-starter</artifactId>
    <version>5.0.2</version>
</dependency>
<dependency>
    <groupId>com.graphql-java</groupId>
    <artifactId>graphiql-spring-boot-starter</artifactId>
    <version>5.0.2</version>
</dependency>
schema / データクラス

resources/graphql/schema.graphqlsスキーマを定義。データクラスでは参照先のIDをフィールドに持つ。

DAO / Resolver

DAO は適当にダミーデータを返すように実装。Resolver では、Query の場合は GraphQLQueryResolver インタフェースを実装、それ以外は GraphQLResolver<T> インタフェースを実装する。

所感

今回は簡単なサンプルでしたが、スキーマが複雑になるほど、実装が大変になりそうな気がしています。自動生成のツールを使うことで解決できるんだろうか。スキーマファーストというだけあって、やはりそこがキモなんだろうと思われます。いかに無駄なくシンプルに設計できるか。

次は更新系のクエリを試してみようかと。あと、全体的にまだ理解が浅いのでドキュメントを読んで勉強する。その他、自動生成などの開発ツール周りを調べる。

参考

JJUGナイトセミナー「JDK 11リリース記念:今知っておくべきJDK 11の重要ポイント」に行ってきた #jjug

先日、JJUGナイトセミナー「JDK 11リリース記念:今知っておくべきJDK 11の重要ポイント」に行ってきました。簡単に所感をまとめます。

jjug.doorkeeper.jp

メモから抜粋。(詳しくは資料をご参照ください)

Java Is Still Free

Java Is Still Free の翻訳がついに来た。ありがたい。

www.sakatakoichi.com

JDK 11 リリースなので改めて「新しい JDK リリースモデル解説 (サマリー&アップデート)」

www.slideshare.net

  • Oracle OpenJDK
    • GPLv2 + Classpath Exception
    • ラクルによるセキュリティアップデート提供
  • Oracle JDK
    • 今まで(v9/v10)までのライセンスと少し違う
    • 商用ライセンス or OTNLA for Oracle Java SE
    • JDK11以降は社内もしくは個人での開発/テスト/試作/デモの用途では無償で利用可能
  • OTNLAが6ヶ月で切れるかどうかは未定 (LTSと同期間になる可能性はある)
  • JMCは個別にダウンロードできるようになる
  • Subscription
    • Javaが実行される可能性のあるすべてのハードウェアが対象
    • デスクトップとサーバーが対象 (クラウド含む)
    • Named User Plus (1台から購入可能、個人でも購入できる予定)
    • Processor

Java 11 : サポートとVM機能編

www.slideshare.net

サポート

  • 開発サポート
    • OpenJDK コミュニティ
  • 配信サポート
    • OpenJDK コミュニティは配信はしていない
  • 問い合わせサポート
  • AdoptOpenJDK
    • 配信サポート期間が一番長い(4年)
  • OpenJDK の開発サポートは現時点では3年間
    • 今後より長くなる可能性もある
  • Oracle JDK から OpenJDK のマイグレーション
    • 証明書周りがネックになるかも (配信元による)
    • だいたいはライセンスの問題
  • AdoptOpenJDK のリリースが遅れているかのは大丈夫か
    • テスト期間があるので1-2週間は遅れる
    • ゼロデイ攻撃が心配なら Oracle OpenJDK の利用を検討する
  • JRE
    • コンテナなどで、バイナリサイズを削減したいなら jlink を使う
    • モジュール化が進むとより効果がありそう
  • 特に理由がなければ OpenJDK の開発サイクルが短いバージョンは無視してOK
  • 多くの場合、必要なのは配信サポート
    • AdoptOpenJDK が4年なのでマイグレーションに1年の猶予がある
    • 問い合わせサポートは予算とSLAに依存する

VM機能

  • JEP 330
    • ソースファイルを java コマンドで実行
    • Java ソースをスクリプトのように扱う (バージョン指定可能)
  • JEP 328 (Flight Recorder)
    • プロファイラ
    • Oracle JDK のものとはオプション構成が違う
  • JEP 318 (Epsilon)
    • No-Op GC
    • 主に開発や研究用途を想定
  • JEP 333 (ZGC)
    • アプリケーションスレッドとGCスレッドの並列化
    • 従来のGCとはアルゴリズムが異なる (世代別GCではない、など)
    • 64bit, Linux 限定

Java 11 : APIの変更点編

  • JEP 181 (Nest-Based Access Control)
    • Nestmates
    • 第5のアクセス制御 (インナークラス間の private メンバ参照)
    • NestHost, NestMembers
  • JEP 309 (Constant Dynamic, condy)
    • Constant Dynamic が Constant Pool に入る
    • static final フィールドではなく、class-file 上の定数
  • JEP 320
    • Java EE & CORBA 関連モジュール削除
    • Maven artifact を使う
  • JEP 321 (HTTP Client)
    • モダンな API, HTTP2, Reactive
    • 非同期呼び出しの場合は Flow が返る
  • JEP 323
    • ローカル変数の型推論が Lambda で使えるように

API

JDK12

  • JEP 326 (Raw String Literals)
    • バッククォートで囲む
    • 変数の埋込は今のところない
  • JEP 325: Switch Expressions

さり気なく JShell のバージョンが JDK 12 っていうのがなんとも。

Developers.IO 2018 に行ってきた #cmdevio2018

先日、Developers.IO 2018 に行ってきました。

dev.classmethod.jp

セッションレポートと発表資料は以下にまとめられています。

Developers.IO 2018 セッションレポートと発表資料まとめ #cmdevio2018

今回参加したセッションは以下の通り。最後までいるつもりだったけど、16時過ぎで体力切れ...。無念。

1000件以上の活用を見てわかった絶対に失敗しないAWSベストプラクティス

おなじみの AWS Well-Architected Framework の話です。

基礎から応用までじっくり学ぶ「AWSでのネットワークの作り方」

ネットワーク関連はあまり知見がないため、基礎の部分はとても勉強になりました。最後の方は若干理解が追い付かず...。

クラスメソッドにおけるWeb APIエンジニアリングの基本的な考え方と標準定義

今回聴きたかったセッションの1つ。API アクションやユースケース、パス、リソースなど、Web API を検討するときにどういうことを考えるのか、とても参考になりました。CQRS のエッセンスを取り入れるのはいいけど、例えば、RDB から ES に大量にデータを連携するときにタイムラグは発生しないのだろうか。

あと、クラスメソッドさんもドキュメントに GitBook を使っているということを知れてよかったです。自分のプロジェクトでも使ってるけど、あまり開発がアクティブじゃないっぽくてちょっと不安になってたのでw

dev.classmethod.jp

次世代モバイル向けクラウドサービスAWS AppSyncを使って店舗スタッフと顧客の体験を最大化する方法

最近、GraphQL に興味があって、今回聴きたかったセッションの1つ。スキーマをもとにコードを自動生成するツールが豊富というのはちょっと意外でした。GraphQL 自体の前提知識は必要なものの、スキーマファーストの開発は確かに効率がよさそう。

AWSのセキュリティ設定がどうなっているか抜け漏れなくちゃんと確認する方法

責任範囲の理解、現状把握、対策。必要に応じてツールや専門家を活用する。あと、初めて生の徳丸さんを観ました。徳丸本第2版ポチるか。

ビジネスを阻害しない!AWSアカウントのID・権限管理について

IAM の構成要素やベストプラクティスの話。AWS を使う上で特に重要な内容の1つだと思います。要復習。

その他

ありがたいことにほとんどの資料はすでに公開されています。今回参加できなかったセッションの資料もあとで読もうと思います。

GitHub から Potential security vulnerability found という通知が来てた

GitHub の通知欄に「Potential security vulnerability found in the bootstrap dependency」という通知が来てた。クリックしてみるとこんな表示が。

f:id:knt_mr:20180920170710p:plain

package.json脆弱性のある依存パッケージが含まれているからアップデートしなさい、ということらしい。

「Review vulnerable dependency」をクリックすると、Bootstrap に CVE-2018-14041 という脆弱性があることが分かります。

f:id:knt_mr:20180920170719p:plain

初めて知りましたが、GitHub はこういうのを検出してくれるんですね、親切。

で、このプロジェクトなんですが、もともと学習のためにお試しで作ったもので、かつ、Bootstrap 3 から 4 にアップデートするのがちょっと面倒だったので、今回はそっ閉じすることに...。時間があったらアップデートしよう。

GitHub - kntmr/bootstrap-vue-mockup

現場からは以上です。

GFUG の「各ベンダーのJDKリリースモデル特集!」に行ってきた #glassfish_jp

先日、GFUG の「各ベンダーのJDKリリースモデル特集!」に行ってきました。簡単に所感をまとめます。

glassfish.doorkeeper.jp

メモから抜粋。

Azul Systems - Your Long Term Java Partner

  • Microsoft は Azul 製品の最初のユーザー
  • Zing
    • Java ランタイム
    • JavaGC やウォームアップの問題を排除
    • パフォーマンスのよさがウリ (HotSpot よりパフォーマンスがいい)
    • ヒープ 8TB までをサポート
    • LLVM ベースの JIT コンパイラ
  • Zulu / Zulu Enterprise
    • Zulu は OpenJDK ビルド
    • Java スタンダードに準拠 (Java SE 認定の100%オープンソース)
    • Enterprise は Zulu + サポート
    • LTS あり
    • 10年以上(!)のサポートあり
  • Zulu Embedded
    • 組み込みや IoT 向け
    • 技術的な違いは Enterprise と違いはない
    • 組み込みの場合は Embedded になる?
  • x86/32ビットOSをサポート
  • 非LTS版 の Mid Term Support あり
  • Java FX はすべてサポート
  • ブラウザのプラグインや Applet はない
  • Azul のサポートは基本的に英語 (日本にエンジニアがいない)

オープンソースで提供される第二のJVM:OpenJ9 VMIBM Javaについて

www.slideshare.net

  • IBM SDK for Java Technology
    • Java SE 仕様に準拠
    • IBM 独自実装の JVM (J9 VM) を含む開発/実行環境
    • サーバーサイドのみ (JavaFX などは含まれない)
  • OpenJ9
  • OpenJDK + OpenJ9
    • OpenJDK (クラスライブラリ) + OpenJ9 (JVM)
    • AdoptOpenJDK や Docker Hub (Dockerイメージ) から入手可能
  • サポート
  • IBM SDK for Java Technology
    • OpenJDK + OpenJ9 ベース + IBM 独自機能
    • 製品同梱で提供
    • 単独入手は Docker イメージのみ
    • IBM SDK for Java 11 は 2025年までサポート
  • 今後、IBMミドルウェアは原則としてDockerイメージで提供していく
  • WebSphere Liberty
    • 軽量/高速なランタイム
    • Open Liberty の商用版
  • OracleIBMバグフィックスは別物か?
    • 原則、Oracle と同期するようにしている
    • 今のところ Oracle からパッチの提供を受けている

今後の Java に関して

  • なぜ半年1回のリリースになったのか
  • IT業界においての3年はとても長い
  • 3年ごとに新しい機能を入れても価値がないかもしれない
  • Java の進化のためにサイクルを早くする
  • モジュール化によって新しい機能を追加しやすくなった
  • Java の開発/提供もアジャイル的に
  • JDK10 から Docker コンテナの対応を強化
    • ヒープのメモリ割り当てや CPU 状況の取得を改善
  • JDK11 では今まで動いてたアプリケーションが動かないかも?
    • Java SE から多くのパッケージが削除される (JAX-WS, JAXB, ...)
    • 依存ライブラリを追加する
    • ユーザー側で対応できるのか製品側の対応を待つ必要があるのかを確認すること
  • カスタム JDK/JRE が作れる

その他

今回の勉強会に合わせて公開された Red Hat さんのエントリ。

nekop.hatenablog.com

あと、Java Champion の公式アナウンス。あとで読む。

ちなみに会社の別チームでは Oracle JDK のサポートを購入するという話になっているところがチラホラ...。他には製品ベンダーの対応を待つ感じですかね。