UNION したクエリで ORDER BY + CASE WHEN する

備忘録。

UNION したクエリで ORDER BY する。さらに ORDER BY 句で CASE WHEN するパターン。使い道があるかは分かりませんが。

UNION したクエリに AS で別名を付けて、ORDER BY 句ではこの別名を使う。

SELECT * FROM (
  SELECT
    t.id AS t_id, t.name AS t_name, t.order AS t_order
  FROM
    table AS t
  WHERE
    ... (略)
  UNION
  SELECT
    t.id AS t_id, t.name AS t_name, t.order AS t_order
  FROM
    table AS t
  WHERE
    ... (略)
) AS uniontable
ORDER BY
  CASE WHEN uniontable.t_order IS NULL THEN 1 ELSE 0 END ASC, uniontable.t_order ASC,
  uniontable.t_id ASC

現場からは以上です。

JJUG Java生誕25周年記念イベントに行ってきた #jjug

先日、JJUG Java生誕25周年記念イベントに参加しました。今回はオンライン開催。簡単に所感をまとめます。

jjug.doorkeeper.jp

所感

JJUG CCC 2020 Spring が中止になり、代わりに開催されたイベントです。Java 生誕25周年。セッションは総会を含めて5本でしたが、幅広い内容で面白かったです。

しかし、IDEの位置付けについてここまで深く考えられるもんなんですね。納得感のある内容でした。今のプロジェクトで使ってる Eclipse めっちょ古いからバージョンアップしなければ...。まずはバージョンアップできるようにプラグインとか周辺のツールを整理するところから。

Jakarta EE はパッケージ名の変更がインパクト大きそうだけど、YouTube のコメントを見てると意外とマイグレーションツールが提供されるっぽい?

あと、キャッシュの更新検知はプロダクト任せになるのかな。Infinispan は通知してくれるみたいだけど。結局、セッションにはユーザー情報とか更新頻度が低いものを入れるのがよさそう。

YouTube の URL はこちら。

youtu.be

以下、メモから抜粋。

Java 14 新機能を軽くまとめてみた

  • Java 14
    • 16 JEPs
    • non-LTS (パッチは15リリースまで)
  • 言語機能の標準化は3段階
  • Incubator
    • ライブラリ
    • incubator モジュールとして import する必要あり
  • Experimental
    • JVM 機能
    • Standard ではなく Production
      • JVM 機能は Java の標準ではなく実装ごとの機能のため
  • Text Blocks (Preview 2)
    • 15 で Standard になる予定
    • 改行のエスケープ (\)
    • スペース文字 (\s)
  • Switch Expressions (Standard)
    • case 句に複数のラベルが指定可 (ステートメントも同様)
    • アローを使うと break は記述不要
    • 値を返すときは yield を使う
    • yield はキーワードではない (型名には使えない)
  • Records (Preview)
    • データをやり取りするための型, 名前付きタプル
    • Record は特別なクラスなので自分のコードでは継承不可
    • invokedynamic で実行時に処理コードが生成される
      • 新バージョンで実装が最適化された場合、旧バージョンでコンパイルしたコードも新しい実装で動く
    • ほぼ enum と同じ扱い?と考えてよい
  • Sealed Classes (Java 15 で Preview)
    • 継承するクラス/インタフェースを限定できる
    • Switch 式で default が不要になる
      • すべての case を処理したことをコンパイラ側で検知できるため
  • Pattern Matching for instanceof (Preview)
    • スマートキャスト
    • if (obj instanceof String s) {...} って文法として微妙な気がするのは自分だけだろうか...
    • 今のところバイトコードには無駄なところが多い模様
  • Pattern with Switch
    • switch でパターンマッチ
    • 近いうちに入るかも?
  • Deconstruction
    • switch の case で Record を分解する
    • 今のところ入る予定なし
  • JFR Event Streaming
    • ファイルにダンプしたデータはストリーミングで見るには不便
    • Event Streaming ではイベントとして処理できる
    • 監視に使いやすい
    • JFR はそろそろ OpenJDK 8 にパックポートされる模様
  • Foreign Memory Access API (Incubator)
    • ヒープ外のメモリを扱う
    • これまでは Unsafe が使われていた
  • @PreviewFeature
    • これまでは PreviewAPI には @Deprecated が使われていた
    • @PreviewFeatureAPI を使う場合は --enable-preview が必要
    • ※資料には --enable-feature と書かれてますが、正しくは --enable-preview です (確認済)
  • Packaging Tool (Incubator)
    • ランタイムを含むアプリケーションパッケージ
      • アプリケーションを使う側は事前に Java をインストールする必要なし
    • パッケージングは jpackage コマンドを使う
    • インストーラ/アンインストーラ
    • ランタイムをコンパクトにする場合は jlink でカスタムランタイムを作成
    • これからはランタイムは開発側が責任をもって提供する
  • https://qiita.com/nowokay/items/ec85d97a7cecaaac8123

IDE起点で2020年代の開発環境を眺めてみる

  • たくさんのツールを使うのは高コスト
  • ツールを組み合わせると取りこぼすものがある
    • これらをシームレスに使えるようにするためにIDEがある
  • いろいろなツールを使うことより開発そのものにリソースを割きたい
  • 開発で使うツールは開発を邪魔するものであってはならない
    • ただし、ツールを蔑ろにしていいわけではない
  • IDEの役割は開発を容易にすること
  • IDEは開発者のためにある
  • 開発対象のアプリケーションがIDEに依存してはいけない
  • IDEはビルドツールの設定を読み込んで使う
    • IDEはビルドツールに依存させる
  • IDEの独立性を高める☆
    • IDEはなんでもいいというところまで持っていく
  • アプリケーションに影響を与えるものはIDEに設定しない
    • JDKのバージョン, ライブラリ管理, フォルダ構成, など
    • IDEの設定を変えたからサービスが停止したということはあってはならない
  • IDEからビルドツールを使うときにIDEバンドルのJDKは使わない
    • アプリケーションに影響を与えるから☆
  • IDEを使うならエラーを出したまま放置しない
    • IDEが出している警告も個人的には残したくない...
  • いざというときにプリミティブなツールが使えると安心
  • IDEの新規プロジェクト作成とかクラスパス設定とかは今はやらない
  • フォーマッタを切り離したい
    • 言語にフォーマッタが付いてるといい
  • IDEのバージョンアップは積極的にするべき☆
    • IDEがバージョンアップできない状況にしない
    • IDEが独立していれば問題なくできるはず

Jakarta EE / MicroProfile を利用したクラウドネイティブアプリの開発

www.slideshare.net

システムのモダナイズ 落ちても良いアプリの作り方

www.slideshare.net

  • スケールアウトしたのに負荷が偏る
  • スケールインで情報を持っていたノードが消えた
  • システムの可能性を高めるには
    • 耐障害性向上
    • スケールアウト
  • クラウドを使っているとそれ以上耐障害性を上げられなかったり
  • ステートレスなアプリケーション ⇒ スケールアウト
  • ステートフルなアプリケーション ⇒ ?
  • ステートの取り扱い
    • DB/インメモリに読み書き
    • 透過的に使う ⇒ HTTPセッション
  • なぜHTTPセッションを使うのか☆
  • HTTPセッションに入れていいもの☆
  • Connection や Thread は Serializable ではない
    • 同一のアプリに接続している場合はたまたま動く
    • 実装の参照がそのまま使えるから? (シリアライズした情報ではなく参照を使う)
    • アプリをまたぐ場合にシリアライズされる ⇒ NG
  • ステートはどのように保持されるか☆
    • ファイル(共有ストレージなど)/DBに置く場合、複数のアプリでステートを共有できる
  • アプリがステートを持つメリデメ☆
    • ステート数が増加してヒープを逼迫するとGCによる停止時間が増えてレスポンス遅延に
  • ファイル/DBがステートを持つメリデメ☆
  • ステートフルで可能性を担保するために重要なこと☆
    • ステートをどこで持つか
    • リクエストをどう振り分けるか
  • セッション外部化
    • DBにステートを持たせる
    • 全体はステートレスになるもののレスポンスは遅い
    • 外部ストアの性能劣化にはニアキャッシュを使う
  • ニアキャッシュ
    • よく使うセッション情報をアプリ上にキャッシュする
    • ネットワークやディスクアクセスを減らす
  • スティッキーセッション
    • アプリが落ちるとセッションは消える (運用で落とす場合も同様)
      • オートスケールできない?
    • 負荷が偏る可能性あり ⇒ 時間を短くして分散しやすいように
  • DBにゴミデータ残らないか?
    • セッションの有効期限を設定する
  • セッションには変更されない情報を入れるのが現実的?☆
  • キャッシュの更新は?
    • HttpSession の実装による
    • Infinispan では無効になったときに通知してくれる
    • Infinispan は同じ JVM プロセスの中で動く
    • Hazelcast も同様?
    • WebSphere では JSESSIONID の Cookie にキャッシュのバージョンが入っていてニアキャッシュと毎回比較している

チームリーディング フロントエンドコンポーネントの指針に行ってきた #narusemi

チームリーディング フロントエンドコンポーネントの指針に参加しました。今回はオンライン開催。簡単に所感をまとめます。

nrs-seminar.connpass.com

所感

前回のクリーンアーキテクチャに続き、今回はフロントエンド寄り、特に新しい技術を導入するときにどのようにチームをリードしたかという話。自分もかつてプロジェクトで Vue.js を採用した経験があるため、とても興味深い内容でした。メンバーに対してきちんと説明できるように自分の中で明確な基準を持つことが大事なのかなと思います。自分はここまでちゃんとできなかったけど...。Vue.js を採用したときのまとめなどはこちら。

Vue.js + Vuex + axios を使うときに考えたことや反省点など - kntmr-blog

メンバーにコンポーネント指向をどう根付かせるか、デザインからどうやってコンポーネントに落とし込むか、そのあたりの話が参考になりました。フォルダ構成は大事。自分は Vuex の examples あたりを参考にしたっけ。

ところで、JS フレームワークjQuery の相性はよくないという話はよく聞くけど、個人的には適材適所かなと思っています。jQuery を Web フレームワークのように扱うと破綻するけど、DOM アクセスのユーティリティとして使う、豊富なプラグインを生かすことを考えれば、決して駆逐するほどではないかなって。ただ、「仮想 DOM など SPA の利点がなくなる」という点は確かにという感じ。

あと、Vuex のようにデータを1箇所にまとめることで「コンポーネントがデータ越しに依存する」という話は興味深かったです。イベントで繋がることで疎結合になる、と。なるほど。そうすると確かにコンポーネント間で emit する方が分かりやすいしメンテしやすくなる気がする。でも、Flux アーキテクチャってまさにこのあたりを解決するものではなかったっけ?ちがったっけ?もしくは Action の IF 設計とか、Store とコンポーネントに持たせるデータの種類にもよるか。

React は JSX が好きになれるかどうかなのかー。

以下、メモから抜粋。

https://youtu.be/sZA92l4XQsAyoutu.be

  • ゲーム業界に比べて Web 業界のコンポーネント指向は遅れてる
  • Atomic Design
  • JS フレームワークjQuery の相性はよくない
    • 仮想 DOM など SPA の利点がなくなる
  • フレームワークを使う理由
    • 無意味に重複したコード
    • 意図が見えづらいコード
    • 解読が難しいコード
  • jQuery のコードは前提とする DOM の状態が実装者以外に見えづらい
  • フレームワーク + コンポーネント指向
    • モジュール性を高める
    • 小さく作って理解の範囲を狭める
  • Atomic Design
    • パーツ同士を組み合わせる
    • コンポーネント指向
    • どういう粒度で作ればいいかイメージできる
  • Atomic Design はデザイナー向けのデザイン手法ではない?
  • CSS フレームワークと Atomic Design の粒度は合わないかも?
  • オブジェクト指向は継承やポリモーフィズムなどのための仕組み
  • コンポーネント指向はパーツの取り外しがしやすいように疎結合にするための仕組み
  • ひとつのページを分析してみせる
    • これ以上分解できない要素はどれか (Atoms)
    • Atom を組み合わせる (Molecules)
    • Atom もしくは Molecules を組み合わせたもの (Organisms)
  • ページを担当分けしてみんなでやってもらう
    • 最初にやってみせることで参考になる
    • みんなでやってあとで集約する
    • みんなにやってもらう間にサンプル実装を作る
    • 構成サンプル☆
      • Atomic Design の要素に合わせて構成する
      • Atom の下でさらにフォルダを切ると見通しがよくなる
  • Templates はページレイアウト?
    • Templates や Pages はない場合もある
    • ステークホルダーと話し合うときに使うためでもある
    • コードに落とし込むかどうかはプロジェクト次第
  • Atomic Design とは別に pages フォルダを用意
  • 位置調整などはコンポーネントにしない
  • ボタンコンポーネントを分けたらボタンじゃなくなる
  • Atom を利用したら Molecules
  • Molecules を利用したら Organisms
  • 意味のある塊は Organisms
  • Organisms を利用した Organisms はあり
  • コンポーネント定義
  • データは親コンポーネントが持つ
  • Vuex のようにデータを1箇所に集めるとどこからデータが変更されるか分かりづらい
  • Playground の場を用意して実践してもらう
  • 通化しすぎて内部で v-if が増える場合は分離するタイミング?
    • 別のものをあとから共通化するより、共通化したものを分ける方が簡単
  • API アクセスはページが担う
    • 共有されるパーツでは Organisms でも許可
  • Molecules が Organisms になることはある
    • Molecules と Organisms の違いは意味を持たせるかどうか
  • BFF のメリットは複数の API アクセスをまとめられること

テスト駆動開発(TDD)オンライン勉強会 #1 に行ってきた #tdd_online

先日、テスト駆動開発(TDD)オンライン勉強会 #1 に参加しました。今回はオンライン開催。簡単に所感をまとめます。

ddd-community-jp.connpass.com

所感

ライブコーディングが2本ありました。TDD のセッションで FizzBuzz 以外の題材が見れたのはとても参考になりました。途中でググったり普段の生々しい感じのコーディング風景が見れてなかなか面白かったです。

FizzBuzz の TDD と言えば、de:code 2017 で t_wada さんが公演されていた動画がとてもわかりやすいです。今回、コメント欄にもいらっしゃって大変学びがありました。

channel9.msdn.com

TDD や自動テストの特徴や課題について、感覚的になんとなく理解はしているつもりでも、きちんと言葉で説明されるとなるほどと思うところがあります。特に自動テストと TDD の違いやカバレッジのあたりの話とか。

以前、TDD (モドキ) を実践してみましたが、リファクタリングや機能追加に対して安心感があって、やはりそのあたりは TDD の大きなメリットかなと思います。最近はテストがほぼないレガシーな環境にいるので、まずは自動テストから取り組まなければ...。

TDD とは関係ないけど、JUnit の diff のビューが便利そう。Eclipse でも使えるんだろうか。あと、懇親会は参加してないけど、spatial.chat が面白そう。Vue.js が使われてるっぽい。

以下、メモから抜粋。

ライブコーディングで体感するTDD基礎

https://youtu.be/UhHdnLTxOjEyoutu.be

  • TDDはDDDとも相性がよい
  • Red-Green-Refactor
  • TDDは開発スタイルであり教義ではない
    • 手段が目的になってはいけない
  • TDDだけで十分に品質保証できるわけではない
  • 必要なければリファクタリングはスキップしてよい
  • ステップを細かくすると過剰な設計を防げる
    • Red ⇒ Green までに時間がかかるときは過剰な設計を疑う☆
    • 差分が大きいとテストコード外の不具合を埋め込んでいるかも
    • フィードバックサイクルの短さが大事
  • @ParameterizedTest, @CsvSource, @MethodSource (JUnit)
  • ループで回すと各テストを展開してくれない
  • Parameterized Test
    • 期待値ごとに分けるかどうかはテスト対象の性質とテストコードの可読性による
    • テストコードから仕様が読み取れるか
    • 同値分割における同値クラスを増やす場合に楽?☆
  • リファクタリングしたテストコードがきちんと動作するかプロダクションコードをわざと壊してテストが落ちることを確認することも大事 (テストのテスト)
  • TDDと自動テストは解決したい課題が異なる☆
  • 自動テスト
    • 自動テストはTDDがなくても実施できる
    • 自動テストは回帰テストの実行コストを抑える
    • リファクタリングしやすく
    • テストコードに想定される挙動が記述される
    • ドキュメントと違って形骸化しない (実行可能ドキュメント)
  • TDD
    • 十分なテストが書かれやすい
    • カバレッジは「足りないこと」は不足はわかるが「十分であること」の根拠には使えない☆
    • テストが書きにくい設計であることに気付く
    • 自然と高凝集/低結合なクラスを書くようになる☆
  • 外部APIはモックにする
    • Dockerで代用するのもあり?
  • Red からなかなか Green にならないと正しい方向に進んでいるか分からない
  • Red-Green-Refactorの うち Refactor のところで設計する☆
    • Red-Green のうちは汚くてもいいからとりあえず通す
  • ToDoリスト
  • テストしやすくするためにメソッドを括り出す
    • テスト観点が明確になる
  • 1テストメソッドにまとめるとテストのバリエーションを増やしにくい
  • カバレッジが100%でもアサーションが十分かどうかは分からない☆
    • テストから書いた方が抜けにくい
  • 自動テストはMust/TDDはWant
    • TDDは開発の進め方なので強制しにくい
  • テストコードの保守コスト
    • 自動テストの問題 ⇒ 解決するにはテストを書くスキルが必要
  • TDDだけでは品質は担保できない
    • テスト戦略の問題 ⇒ UT以外に全体としてどうするか
  • テスト実装工数
    • 自動テストの問題 ⇒ 長期的に回帰テストのコスト削減になるかで判断
  • TDDの問題の多くは自動テストの問題であることが多い

実践クリーンアーキテクチャに行ってきた #narusemi

実践クリーンアーキテクチャに参加しました。今回はオンライン開催。簡単に所感をまとめます。

nrs-seminar.connpass.com

所感

JJUG CCC 2019 Spring の再演。このセッションは参加してなかったのでこの機会に聴けてよかったです。先月、ドメイン駆動設計入門を読み終わったところなのでより理解が深められた気がする。

クリーンアーキテクチャは確かに定義するファイルが多くなりがちみたいだけど、それぞれがどういう役割を担っているか、特にクリーンアーキテクチャの図で右下の図がどういうことを表しているのかが理解できました。あと、課題に対してどういうアプローチを取るか、そのあたりの話は参考になります。

とはいえ、クリーンアーキテクチャを知らなくてもインタフェースの役割が理解できていれば、ある程度は近しい形というか同じような目的を実現する仕組みにはなるのかなって思ったり。ただまぁ、そのあたりの共通認識になるものとしてアーキテクチャとして提言されてるんでしょうけど。

次回はフロントエンド寄りの話らしいです。期待。

以下、メモから抜粋。

先行開発!クリーンアーキテクチャ -- ゼロから始める新規開発

https://youtu.be/5oJeSrwztPgyoutu.be

  • 最終形に辿り着くために試行錯誤したい
  • クリーンアーキテクチャ
  • 先にヘキサゴナルアーキテクチャを学ぶのがおすすめ☆
  • クリーンアーキテクチャ
  • SOLID原則
  • Entities (Enterprise Business Rules)
  • Use Cases (Application Business Rules)
  • Controllers, Presenters, Gateways (Interface Adapters)
    • Use Case Interactor
    • Use Case Input Port / Output Port (interface)
  • Frameworks & Drivers
  • 依存の方向を内向きにする
  • Controller
    • アプリが要求するデータに入力を変換する
    • Input Data に変換する
  • Input Data / Output Data / View Model
    • Data Structure (データ構造体)
    • DTO (POJO)
  • Input Boundary (interface)
  • Use Case Interactor
    • Input Boundary の実装
    • アプリケーションロジック
    • Input Data を受け取って処理して Output Data を返す
  • Data Access Interface (interface)
    • Repository
    • データにアクセスするためのインタフェース
    • クリーンアーキテクチャの Gateways
  • Data Access
    • Entity のオブジェクトを再構築する
    • 実装は何でもOK (SQL, ORM, Mock, ...)
  • Entities
  • Output Boundary (interface)
    • Presenter のインタフェース
    • 出力データを渡すためのインタフェース
  • Presenter
    • Output Boundary の実装
    • Output Data から View Model に変換する
    • View Model を View に引き渡す
  • 処理の流れ☆
  • フロントを先行開発したい
  • Web アプリのフレームワークでは Controller でレスポンスが必要
    • Presenter と相性がわるい
    • ネイティブアプリの場合は Presenter は相性がいい?
    • ⇒ Presenter を捨てる
    • ⇒ Output Data をそのまま返す
    • ⇒ Output Data を Boundary に渡すか、戻り値で返すかの違いだけ
    • Output Data に変換してるからビジネスロジックに依存していないはず☆
    • Output Data ⇒ View Model の変換は Controller が担う
  • アクションごとにユースケースがある
    • Controller のフィールドが多くなりがち (@Inject Hell)
    • ユースケースが増えるたびに Controller の修正が必要
    • ⇒ Message Bus (UseCaseBus)
    • ⇒ Command オブジェクト
    • Input Data から期待する Output Data は分かる
    • 処理の実体 (Interactor) は何でもOK
  • 定義するものが多い (作るファイルが多い)
    • ⇒ 自動生成ツール
    • モジュール / テストモジュール / テストデータ / DI 設定
    • 同名の JSON ファイルから Output Data を構築するスタブ
    • BFF とかだと特に便利
  • 依存関係逆転の原則☆
  • ビジネスを中心にシステムを組み立てる☆
  • https://github.com/nrslib/play-clean-java

JJUGナイトセミナー「みんなの小噺」に行ってきた #jjug

JJUGナイトセミナー「みんなの小噺」に参加しました。今回はオンライン開催。簡単に所感をまとめます。

jjug.doorkeeper.jp

所感

Retrofit は割と前からあるみたいだけど、初めて知りました。もともとは Android 向けなんだろうか。Type-safe だし、新しいプロトコルにも対応しているようでなかなかよさそう。

今回、初めて JIG のデモを見ましたが、思ってたよりずっといい感じ。設計と実装のサイクルを回すという考えをしっかりサポートしてるように見えました。DDD の勉強でコード書くときに使ってみようかな。

Dapr は、この前の JSUG で聴いた Spring Cloud Consul の話に似てるような気がした...?同じ目的で作られてるものなんだろうか。あと、組み合わせ問題の話があったけど、そのあたりがイマイチ腹落ちしてない...。

[2020/05/02 追記] YouTube の URL

youtu.be

以下、メモから抜粋。

JavaでHTTP接続してみよう

  • JSON は js のオブジェクトをデータ記述に流用したもの
  • 標準 API
  • java.net.Socket
    • TCP 接続
    • バークレイソケットをラップ
  • HTTP プロトコル
  • java.net.URLConnection
    • HTTP で使うときは HttpURLConnection にダウンキャストが必要
    • 主にドキュメント取得で使う (POST パラメータ送信は面倒)
    • 同期処理のみ
  • java.net.http.HttpClient
    • HttpResponse.BodyHandler でレスポンスのハンドラ
    • BodyHandlers#ofLines でレスポンスを Stream で返せる
    • HTTP2 に対応
    • 非同期でモダンな API
  • Retrofit
    • Type-safe HTTP Client
    • interface のメソッドにマッピングする
    • 内部では OkHttp で HTTP 接続する
    • リクエストのオブジェクトは Call<T> でラップする
    • HTTPS, WebSocket, WebRTC, HTTP2, HTTP3
  • フレームワークで用意されているものがあればそっちを使うのがよさそう

RDRA2.0のサンプルをJIGを利用して実装してみたよ

www.youtube.com

  • system-sekkei/library
  • RDRA
  • JIG
  • ドメインモデルの実装
    • バリエーションダイアグラム
      • ビジネスに登場する値/区分(条件)
    • 状態モデル
      • ビジネスに登場する状態/状態遷移
    • 情報モデル
      • ビジネスに登場する情報とそれらの関連を表す
      • パッケージ構成
  • アプリケーション層の実装
  • JIG ドキュメント
    • パッケージの依存関係 (深さはファイル名の -depthN で見れる?)
    • ビジネスルールの関連 (クラスの関連)
    • クラス間の相互依存が見つけやすい
    • 各層の呼び出し関係が分かりやすい
      • Controller ⇒ Coordinator
      • Coordinator ⇒ Service
      • Service ⇒ Repository
      • 画面 ⇒ ユースケース
  • RDRA ⇔ JIG で図を比較しながら実装する
    • サイクルを回す

なぜ僕がDaprを使おうとしているのかという話

  • 分散アプリケーションランタイム
    • アプリとインフラの間に置く (プロキシ?)
    • マイクロサービスのビルディングブロック?を提供
    • マイクロサービス開発の機能群を抽象化する
    • サイドカーとして提供
      • アプリ ⇔ Dapr API は HTTP/gRPC
  • Dapr のコンテナ上でアプリが動くわけではない
  • サービス呼び出しやデータストア保存は Dapr のプロセス経由
  • サービスディスカバリは Dapr が担う
  • Spring Boot / Spring Cloud でも実現可
  • Dapr
  • バージョンアップ
  • Java と Dapr のバージョンアップを別にできる
  • Spring のようにフルスタックではない
    • 組み合わせ問題が起きるかも?
  • https://github.com/cero-t/dapr-trial

IAM クロスアカウントロール作成

AWS アカウント間でアクセスを委任 (クロスアカウントアクセス) するための IAM ロール (クロスアカウントロール) を作成する手順。

docs.aws.amazon.com

IAM 本 を読んでて、クロスアカウントロール作成のところでイマイチ流れが掴めなくてモヤモヤしてました。そこで、AWS のドキュメントにあるチュートリアルを読みつつ、自分の理解のために手順をざっくり図解してみたらなんとなく理解できた気はする。

f:id:knt_mr:20200426135349p:plain

※切り替え先の AWS アカウントの IAM ユーザー

  1. 対象サービスへのアクセス許可を定義したポリシーを作成
  2. 切り替え用のロールを作成
  3. 1) で作成したポリシーを 2) のロールに割り当てる

※切り替え元の AWS アカウントの IAM ユーザー (図と番号がズレてる)

  1. 切り替え用のロールへのアクセス許可を定義したポリシーを作成
  2. 1) で作成したポリシーをアクセス許可するユーザーのグループに割り当てる
  3. 切り替え用のロールへのアクセス拒否を定義したポリシーを作成
  4. 3) で作成したポリシーをアクセス拒否するユーザーのグループに割り当てる

切り替え元のユーザーは切り替え用のロールを使って対象のサービスにアクセスする。なお、切り替え用のロールにアクセスできるユーザーはポリシーで制限できる。AWSチュートリアルでは、Deny を定義したポリシーを切り替え元のグループに割り当てている。IAM 本では、切り替え用のロールに割り当てているポリシーにアクセスを許可するユーザーを定義している。(Principal)