Seeing is believing

いちエンジニアの日々の興味のあるところ、イベント参加記録、学びの共有を取止めなく※このblogは個人の見解であり所属する組織の見解ではありません

エンタープライズJavaの未来に注目集まる！JJUGナイトセミナー「Jakarta EE特集」に参加しました

2020年1月22日に開催されたJJUGセミナーに参加してきました。

jjug.doorkeeper.jp

Jakarta EE最前線 - Jakarta EE 8の新機能と今後のロードマップなどなど

資料は以下。

www.slideshare.net

  • Oracle 伊藤さん
  • Jakarta EEネタですが、聴講者多し
  • EE4Jとは
    • OracleからEclipseへの移行プロジェクトと思われがちだが、移行するイニシアチブのこと
    • 各プロジェクトを統括する役目として今も存続
    • 仕様策定者はこちらに属する
  • Jakarta EE
    • こちらはブランド名、アーティファクト
    • ステアリングコミッティ
      • Will Lyons（Oracle)がChar。伊藤さんの上司
    • スペシフィケーションコミッティ
      • こちらにはBill ShannonがOracleから参画している
  • Participating Membersには米国のみずほ総研が入っている（国内関係なし）
  • Jakarta EE Committersとして、Oracleが一番多いが、個人エンジニアがオラクルに次ぐ状況
  • 日本からも是非コミッターになってほしい
  • EE4Jでの新しいプロジェクトは２つ
    • KrazoとNoSQL
  • JakartaEE仕様策定の原理原則
    • 利用価値が低下したAPIをDeprecatedに
    • Mavenを標準ビルドツールに
    • CDIとConfig（どこから持ってくるかは未決）の積極的な導入
    • JPMSへの対応-MANIFEST.MFを添付
  • WebLogic14.1.1がQ1にリリース予定で、JakartaEE8、JavaSE8,11で動作。
  • JakartaEE9はTooling Releaseに
    • jakarta.*
      • APサーバ、IDE、製品、ツール、環境の迅速な移行を促すため
    • Deprecation and Removal
      • Removal：Jakrta XML Registies,XML RPC、Deployment
      • Optionへ：EJB2.X,JAX-WSなど
    • JDK11動作保証
    • 1/16にアナウンス
    • 2020midリリース予定（予定としては6月末）
    • Jakarta EE8への後方互換性を維持しないことを許容する（絶対ではないけど、なるべく保証する）
  • JakartaEE 10で機能追加されそうなもの
  • リリース頻度は議論中（6ヶ月、12ヶ月、18ヶ月（会場ではこちらが多め、3年ぐらいという人も））
  • Jakarta EE 8のチュートリアル、イントロダクションがあるので、そこで網羅されている
  • 手取り早くJakarta EE始めるなら以下
  • Jakarta EEはこれからの10年、20年先まで使い続けられるエンプラJava標準

MVCについては直近、以下のツイートもあり、注目していきたい。

Jakarta EE + Microprofile との付き合い方

資料は以下。

www.slideshare.net

  • 楽天岩崎さん
  • 現在は楽天カードで技術管理など
  • 技術者は技術者視点でSpecから製品選定とかすべき
  • JakartaEEと比べて小さな機能だけ
  • MicroProfileだけで何かを作るのは無理があるのでは？(DB,CMTがない。画面もない)
  • 使い所パターン
    • BFF\API Gateway的に使う。後ろはJakartaEEでAPIでつなぐ
    • バッチ系処理として使う
      • バッチ系としては、ロジックが長寿命（作ったらあまり変えない）となりそうなので、MicroProfileの利用が適切なのかは疑問に感じた

Scaled Agile Meetup in Tokyo（SAFeミートアップ） Octoberに参加しました

はじめに

今日はScaled Agile Meetup in Tokyo（SAFeミートアップ） Octoberに参加しました。 きっかけは色々あるのですが、SAFeのmeetupに参加するのは初めてでしたので楽しみにしながら向かいました。 まず、会場はオシャレでよかったです。スクリーン（ディスプレイ）も見やすく、この規模の勉強会には最適ですね。

www.meetup.com

移行は当日とったメモベースでふりかえりたいと思います。

Chrisさんセッション

  • SunやDecのような革新的なIT企業でさえ、変化の波に乗れないとうまくいかない
  • 欧米では技術を適応するChasmを超えた状況
  • SAFe Enabling Services
    • 12 Month SAFe Implemetation Roadmap でPI プランニングARTs
  • 戦略から実行に移しきれない問題について、リリーストレインで解消させる
    • 企画から開発、運用までの各担当がリリーストレインに乗って巻き込むことで実行性を持つ
  • 可視化がポイント。依存性とかを2日間で明らかにする。全世界から1箇所に集まって行うため投資コスト高いが、2日で決まるので価値がある
  • プログラムポードが完成することがGoal
  • 上層部から、ビジネスオーナーとして優先度を明確に聞けるので、早い
  • Safeの社内推進プロジェクト自体をSafeで進める事例も
  • 欧米ではDXという言葉は古くなってきている
  • Safe5.0ではビジネスアジリティを如何に上げるかに着目されている
  • プロジェクト to プロダクト　という本があり、考え方の変換になる

www.amazon.com

  • ビジネスとITをつなぎ合わせる
  • カルチャー変革が肝

Global SAFe Summit

  • プレゼン資料は公開されているらしい（どこなのか。。。）

global.safesummit.com

  • 10月頭にサンディエゴで開催された
  • 2100人の参加者、570社、日本からは13人。去年は日本人1人。セッション100以上
    • NTTコムウェアさんも2名参加
      • どういう風に導入するかの情報収集目的
    • NTT Dataさんも参加。グローバル4カ国から参加
    • NTTソフトさんも参加
  • キーノートの目玉はSAFe5.0
    • ビジネスアジリティのMeasure&Grow
    • それを支える7つのコアコンピテンシー
    • 追加されたのは、学び続けること(Continues Learning Colture)のコンピエンシー
  • 次回のmeet up にて5.0 Previewを紹介予定
  • 来年のGrobal SAFE Summitはデンバーで開催(本社ディーンの近く)
  • 来年2月にDeenさん来日予定。meetupも開催
  • 5.0の翻訳についてレビュアー募集！
    • これは是非コントリビュートしたいので、続報を待つことにします

終わりに

SAFeは日本でまだまだこれからの印象が最初ありましたが、エンタープライズ業界中心に、変わる（変われる）可能性を感じました

まずは、危機感を正しく持つこと、勉強し続けることの文化については、個人の思いとして進めていきたいと思います。

SpringのControllerから先で非同期化するパターン

やりたいこと

  • リクエストはHTTPで受け付けて、後ろ側の処理を並列実行
  • 結果は全結果を待ち合わせてHTTPレスポンスを返す
  • できれば、エラーが発生した場合は待ち合わせせずに早期にレスポンス返したい

Spring5 Recipesに記載されていたパターンは以下

qiita.com

  • java.util.CompletableFutureを使うパターン

  • 参考

qiita.com

  • SpringのListenableFutureを使うパターン

  • 参考

qiita.com

今後それぞれのメリットデメリットなどを整理していきたい

  • 色々情報公開されていて、とても助かります。ありがとうございます。

MyBatisでTypeHandlerを使ってDBカラム単位に暗号、復号

ちょっと調べたメモ

やりたいこと

  • 要件として、DBのカラム単位に暗号化してテーブルにInsert、Updateしたい
  • Selectする場合はオブジェクトにマッピングされた時点で複合されていてほしい
  • つまり、カラム単位の暗号化、復号化を透過的に行いたい 　⇨テーブルの中身には暗号化された状態で永続化しておきたい

前提

透過的なカラム単位の処理⇨TypeHandlerをつかったら良いのではないか？

  • TypeHandlerとは 　- MyBatis自身もデフォルトで多数持っている、DBのカラム定義とJava側のフィールドの型定義のマッピングを行うもの

www.mybatis.org

  • よく使われるパターンとしては、Java側はEnum、テーブル側は文字列型とかのときに自作TypeHandlerとして使われる

qiita.com

  • Java8からのLocalDateTimeでも使われることがある

qiita.com

  • これを応用して、型としてはどちらも文字列型であるがDBに投入する際に暗号化、DBからSelectしてJavaオブジェクトにマッピングする際は複合化すればOKでは、と考えた

調べたら中国語ではあるがGithubに同じことをやろうとしているソースを発見。

github.com

結構いろいろやっているので、まずは以下のような単純な暗号化ロジックをつかって今後試してみたい。

www.suzushin7.jp

JSUG勉強会 2019その2 Spring BootベースのDDDサンプル徹底解説！に参加しました。

20190218JSUG勉強会 2019その2 Spring BootベースのDDDサンプル徹底解説！

Spring Bootベースのドメイン駆動設計のサンプルコード　徹底解説

  • いつもながら運営の皆さん、登壇者の皆さん、大変勉強になりました。ありがとうございました。

サマリ

  • 増田さん、irofさんによるDDDの設計、実装パターンのサンプル
  • 今はこれにチャレンジしているという話が多々あったので、日々改善を繰り返している。つまりこれ、という答えはない
  • 気づきは多い。現場の状況に応じて少しずつやり方変えていくべき。。

セッション中メモ

  • https://github.com/system-sekkei/isolating-the-domain
  • サンプルは設計、開発で１ヶ月ぐらい
  • 増田亨（有限会社システム設計）、irof（関西Javaエンジニアの会） さん
  • ソースコードはirofさんを始め、関西中心のコントリビュータの方々が書いている
  • DDDをコードで示すことがサンプルを作った目的
  • 質問が具体的になり、考え方の違いがはっきりしてきた
  • ソフトウェアの複雑性とはなんなのか？
    • ビジネスルールの複雑さに影響される
    • 計算をどうやって実現するか？-> 計算をモデリングする（データだけではない）
    • 型志向でプログラミング（Classにこだわる）
  • 詳細は3/22のDevLovePremiumで語る解説する予定
  • 計算（ビジネスルール）を実行するモジュール群とデータの入出力するモジュール群を分けることに拘る
  • 業務系のアプリはトランザクションスクリプトで実装されることが多い
    • ここにドメインモデルをモジュールとして組み合わせるのが良い
  • 開発（設計）の順番
  • POJO
    • BeanValidationは、有効な値の表明であり、自己署名化の一部
    • privete とか　finalはこのサンプルでは書いてない。ルールはシンプルで読みやすいようにしている。（可読性 over Java)
    • No getter, no setter , no Lombok, JPA
  • プリミティブをなくす方向で整理したい。ただしパッケージ間の相互依存を無くすためにプリミティブで値のやりとりをしていたという背景もあり。ケースバイケース
  • StreamAPIを使いたいケースもあるが、業務としての表現が貧弱なケースもある。forのほうが読みやすい。
  • 増田さん個人的には、Haskellとかと比べるとStreamに違和感がある。。（Groovyとかでも比較対象として良いかも）
  • IntellJでforとStreamの相互変換はできるので、見比べながらバランスみて決めている
  • DBのDDLの内容とドメインのバリデーションの差異はどう考えたら良いか？マルチチェックすべき内容なので、それぞれで確認すべき
  • パッケージに閉じているのであれば、フィールド直接アクセスするもの良いのではないかと考え始めている
  • バリデーションが権限によって変わるというのは複雑さの一因となっている。Groupバリデーションを使うか、それぞれ分けてしまう
  • DTOはできれば使いたくないが、実際にはかなり大きいJSONを受け取って、ドメインをIFたくさん書いて組み立てるということは現実ありうる
  • オペレーションサービス 計算結果の記録と通知の指示 -> データソース層
  • Serviceクラスは単純１RepogitryへのCRUD。あまりビジネスロジックを描かない
  • coodinatorクラスは上記のserviceクラスを複合するサービス。IF文はこちらに持つ
  • どちらも@Service。パッケージを分ける
  • 増田さんはMyBatis一択派。irofさんはDomaにしたい。。。SQLを生で書くことを優先している。
  • テーブル設計は単独でよりよく見直されるようになるべき。データモデルへのマッピングについて橋渡ししているのがSQL。よってSQL書くのは大事。
  • データベースはイミュータブルデータモデル（川島さんが発表された内容を参照）
    • https://www.slideshare.net/kawasima/ss-40471672
    • 履歴＋最新状態のレコード
    • 履歴：事実の記録ーInsertオンリー
    • 最新状態レコード：論理的には不要だが、Insert/Deleteで実現する
    • Update無くしが基本
    • スキーマ名、テーブル名、カラム名を日本語でやるチャレンジをしてみた
    • 外部APIを叩くときは、Transfer層（Outbound）、プレゼンテーション層（Inbound)で詰め替える。
    • DB,SQLでエラーが起きるのは基本はシステムエラーケースを想定。事前にドメインとしてチェックされているのがあるべき
    • トランザクションは意図的に組んでいない。今はやってない。履歴を事実として積み上げたい
  • JIGは自作ツール。以下が確認できて便利
    • 一覧表示での平仄確認
    • パッケージ間の相互依存の確認

今年学びたいこと

元日ということで、今年やりたいこと、学びたいとを、メモ。

ブログする頻度あげる

社内での発信にさらに力を入れる

マイクロサービス関連のアンテナ高める

WEBAPI関連も同様

リアクティブを正しく人に伝えられるように理解する

外部講演（登壇）を2回以上

フロントエンドも追う

アジャイル（スクラム）の良さを真に理解、これまでのコンテキスト異なる人にも分かりやすく伝える

 

頑張ります。

JSUGイベントSpringOne Platform 2018報告会メモ

SpringOne Platform 2018報告会

SpringOne Platform全体所感

  • NTT 岩塚卓弥さん、NTTデータ 岩本純佳さん
  • 前身カンファレンス（Groovyとかといっしょの時代とか）からくらべて10年目
  • スポーサーとして日本からはNTTDataと富士通
  • セッション１５０個のうち、一番多かったのはケーススタディ
  • Springのセッションがそこまで多くなかったのは前年にSpring5のメジャーバージョンアップがあったから
  • JDK11使う人はSpring5.1を使う
  • 5.2は6月リリース予定
  • 5.1は去年発表のリリース予定から数ヶ月遅くなったので、5.2も遅くなる可能性あり
  • 関数型スタイルVSアノテーションスタイル
    • これからも両建て
    • 関数型スタイルも選択できる
      • パッケージスキャン不要
      • KotrinDSLで簡潔にかける
  • フレームワーク内のリフレクション使用の最適化
    • Spring5.1(Boot2.1)にするだけでヒープサイズ、起動時間が少なく短く起動できる
    • 関数型Bean定義で明示的に定義するとさらに早く起動できる
  • GraalVMによるnative imageへのコンパイル
    • GraalVMとはOracleがOSS公開している多言語対応VM
  • Spring5.2
    • JDK12のサポート
    • GraalVMへの完全対応
    • Kotorin1.3の完全サポート
    • HibernateORMの5.3
  • DBS銀行の事例
    • 外注と内製の割合を逆転（8:2)
    • 技術の社内展開：技術者とのペアでの活動
    • 新規人材採用
      • 採用プロセスにオンライン技術テストやハッカソンを取り入れた（hack2hire)
  • https://codezine.jp/article/detail/11180

Spring Cloud Stream および2.1での新機能

  • Jia Xiaozhouさん
  • メッセージドリブンマイクロサービスのためのフレームワーク
  • Spring Integration + Spring Boot => Spring Cloud Stream
  • コンセプトはBinderレイヤを設けることによってアプリとミドルを疎結合（RabbitMQやKafkaなどをアプリからメッセージキューの種類を意識せずに使える）
  • 2.1ではSpring Cloud Functionとの連携
  • FunctionをBean登録、プロパティ指定するとイベント契機で呼べる
  • Function Compositoin：アプリに閉じたワークフローの定義ができる
    • Spring Cloud Data Flowとの連携も現地で話されていた
  • Source -> メッセージの源
  • Sink -> メッセージが流される場所（受け取る側）
  • Processor -> Source兼Sink
  • Functionの引数でメッセージを受けとって、戻り値がメッセージ送信になる
  • ActuatorエンドポイントからBinderを停止したり出来る

High Performance Batch Processing

  • アスクル 寺山さん
  • Spring Batchの情報が古いので参加
  • 半年前からBatch使っている
  • SpringBatchはStepという概念で管理
  • stepの途中で失敗したら失敗したところからリラン可能
  • stepはtasklet（読み込み、加工、書き込みに別れる）とchunk（それ以外）にわかれる

Reactor NettyネタとKafkaネタ

  • Yahoo! JAPAN 水落さん
  • PCFを利用
  • reactor-netty最新は0.8
  • Nettyネットワークプログラミング向けのフレームワーク（HTTP以外のTCPやUDPも選べる）
  • 高スループット、複雑な非同期処理が求められるミドルウェア等の実装に向いている
  • non-bloking IO
  • WebFluxのデフォルトバックエンド
  • Springからみるとメタフレームワークと言える
  • Reactor NettyはReactor利用時のネットワーク通信全般に用いる
  • イベントループ前提
  • wiretapメソッドを入れておくと通信ダンプがログに出る
  • KafkaはStreaming Platform
    • Producer/Consumer
      • Kafkaにデータを送受信する基本的な機能
      • Producer/Consumer　APIにより実装する
    • Connectors
      • Kafkaとデータ連携するアプリケーション
      • データソース、シンクごとに実装が公開されている（MySQL,Elasticserch)
    • Sreaming Engine
      • トピック間同士でリアルタイムにデータを変換、統合するようなアプリケーション
      • Streams APIにより実装する
      • 後述のKafka Streamsライブラリより手軽実装できる
  • KafkaStrems
    • Kafkaを用いたストリーミング処理を書くためのライブラリ
  • Spring for Apache Kafka
    • KafkaTemplete
    • ＠KafkaListener

R2DBCネタとRSocketネタ

  • Pivotal 槙俊明さん
  • SpringOne 2018 Ben Haleで検索して出てくる動画を参照
  • リアクティブプログラミング
  • Springの人たちが言うにはback pressureが大事
    • Reactive Streamのrequest(n)が大事
    • Subsctiverがボリュームかわりに流れてくるデータ量を調整できる（back pressure)
  • WebClientはリアクティブでなくても使えるので、おすすめ。シンプルに書ける
  • JDBCがノンブロッキングなので、別のものをAPIを作ったもの
  • OracleのADBAによい影響を与えたいという思いでSpringチームが開発している
  • Driver SPI（サービスプロバイダインターフェース）
  • JDBCっぽくかけるが、MonoやFluxで戻り値をもらえる
  • トランザクショナルなインサートも実現。スレッドローカルは使わない（JDBCだとつかっている）
  • SPIではなく、r2dbc-clientでハイレベルなAPIが提供されている。テンプレートパターン的な。
  • spring-data-r2dbcというとなりの存在のプロジェウトも。リポジトリインターフェースの作成だけで実現できる。リポジトリパターン。
  • WebFluxを使えばReactiveになるわけではない。書き方に注意。currectAllとかすると待ってしまうので、リアクティブではない
  • リアクティブアプリケーション間のback pressureを制御できあかった課題に対してのプロトコルがRsocket。L7のプロトコル（HTTPと同じレイヤ）
  • NetflixでrScoketを使っていた人がFacebookにいって活用していた人がキーノートに
  • Netflixでは今はあまりrSocketを使わずにgRPCを使っている
  • プロトコル定義なので、プログラム言語非依存（今はJS、Java、Kotlin、C++)
  • TCP直接使えないようなプラウザ上ではWebSocketを使ってその上でRSocketを使う。プロトコルなので下は意識しない。
  • マイクロサービス的な構成になった場合にRsocketを使うとback pressureを伝播できる。Istioと競合？
  • battle-flux-ui.apps.pcfone.io
  • Rsocketでクライアントからback pressureを設定できるデモ