Zenn
🐷

Technology Radar vol.23(2020年10月版)を読む

に公開
Technology Radar
idea

Technology RadarのVol. 23(Oct. 2020)を読んだので、気になった項目をまとめて、感想を記録しておく。

ここしばらく、Kubernetesの勉強をしているので以下は触ってみる予定。

  • Istio: こんなにも前からAdoptだったとは
  • Lens: コマンドラインとGUIのバランスをとったプロダクト

翻訳関連は業務で関係あるので以下を調べてみる。

なるべく早く習得したい。

  • Zero trust architecture (ZTA)
  • Open Policy Agent
  • OpenTelemetry
  • Jaeger: 以前、AWS SQSをサポートしていなくて諦めたけど、最近Apache Kafkaに乗り換えたのでどの程度使えるのか調べておきたい。

その他に気になったものを以下に取り上げる。

Techniques

【Adopt】

3. マイクロフロントエンド

  • マイクロサービスの利点と課題: マイクロサービスはチームが独立してサービスをデプロイ・保守できる大きな利点をもたらしましたが、多くのチームが大規模で絡み合ったフロントエンドモノリスを作成しており、これがマイクロサービスの利点を相殺しています。
  • マイクロフロントエンドの普及: マイクロフロントエンドは導入以来人気を集め続けており、複数の開発者やチームが同じユーザーエクスペリエンスに貢献する際の複雑さを管理する方法として多くのチームに採用されています。
  • リファレンス記事の公開: 昨年6月には、この技術の考案者の一人により、マイクロフロントエンドのリファレンスとなる入門記事が公開され、その動作原理が示されています。

感想: その後も、色々と注意点が公開されているが・・・ オライリーの本も第２版が出ているので読むべきか。

4. Pipelines as code

  • Pipelines as Codeの定義: アプリケーションやインフラストラクチャの構築、テスト、デプロイを行うデリバリーパイプラインの設定をコードとして扱う技術です。
  • 特徴と目的: ソース管理下に置き、自動テストとデプロイを備えた再利用可能なコンポーネントとしてモジュール化されるべきです。
  • 必要性の高まり: 分散型自律チームへの移行や、マイクロサービス/マイクロフロントエンドの構築に伴い、組織内でソフトウェアの構築とデプロイの一貫性を維持するために「Pipelines as Code」を管理するエンジニアリングプラクティスが必要とされています。
  • デリバリーパイプラインテンプレートとツールの登場: このニーズに応える形で、標準化された構築・デプロイ方法を可能にするデリバリーパイプラインテンプレートやツールが生まれました。
  • ツールの機能: これらのツールは、アプリケーションの宣言型デリバリーパイプラインを使用し、構築・テスト・デプロイといったデリバリーライフサイクルの各段階で基盤となるタスクを実行するためのパイプラインの設計図を採用し、実装の詳細を抽象化します。
  • CI/CDツール選定基準: コードとしてパイプラインを構築、テスト、デプロイできる能力は、CI/CDツールを選択する際の重要な評価基準の一つとなるべきです。

感想: やっと、この運用の仕方が分かってきたところだけど、5年前にAdapt

6. Simplest possible feature toggle

  • 機能トグルの現状: 機能トグルは十分に普及しておらず、その種類やユースケースが混同されがちです。
  • 不適切な利用例: 継続的インテグレーションのメリットを得るために、リリース機能トグルやカナリアリリース、ビジネス担当者への機能リリース責任の委譲が必要ないにもかかわらず、LaunchDarklyのような高機能プラットフォームを使用しているチームが散見されます。
  • シンプルな機能トグルの推奨: A/Bテスト、カナリアリリース、ビジネス担当者への機能リリース責任の委譲が不要な場合は、不必要に複雑なフレームワークではなく、シンプルなif/else条件式を用いた機能トグルを使用することを推奨します。

感想: リリースのプロセスが重いとif/elseですら大変。

【Trial】

12. Security policy as code

以下は、提供されたテキストの要約です。

  • セキュリティポリシーの定義: セキュリティポリシーとは、脅威や混乱からシステムを保護するための規則と手順のことです（例：アクセス制御ポリシーやネットワークセキュリティポリシー）。
  • 「セキュリティポリシーをコードとして」の必要性: 現代の複雑なテクノロジー環境では、セキュリティポリシーをコードとして扱うことが求められています。これは、ポリシーをバージョン管理し、自動で検証・デプロイし、そのパフォーマンスを監視することを含みます。
  • 関連ツールの活用: Open Policy Agent (OPA) や Istio といったツールは、「セキュリティポリシーをコードとして」の実践をサポートし、柔軟なポリシー定義と強制の仕組みを提供します。

感想: 言ってる事は理解できるけど、セキュリティ・チームがアプリチームに迷惑を掛けないで運用するのは難しいし、アプリチームがIstioを使ってポリシーをコード化するのも・・・

16. Zero trust architecture (ZTA)

  • 複雑化するテクノロジーランドスケープ: 現代の組織のテクノロジー環境は、資産が複数のセキュリティ境界（オンプレミス、複数クラウド、SaaSなど）に分散しているため、複雑化しています。

  • セキュリティパラダイムの転換: この複雑さにより、静的で変化の遅いセキュリティポリシー管理から、動的で詳細、かつ時間ベースのアクセス権限に基づくセキュリティポリシーの強制へと、企業セキュリティ計画のパラダイムシフトが求められています。

  • ゼロトラストアーキテクチャ (ZTA): ZTAは、デバイス、インフラストラクチャ、サービス、データ、ユーザーを含むすべての資産に対してゼロトラストセキュリティ原則を実装するための組織戦略です。

    • ネットワークの場所にかかわらず、すべてのアクセスと通信を保護します。
    • 可能な限り詳細なポリシーをコードとして強制します。
    • 脅威を継続的に監視し、自動的に軽減します。

  • ZTAを可能にする技術: レーダーは、セキュリティポリシーをコードとして、エンドポイントセキュリティのためのサイドカー、BeyondCorpなど、多くの有効化技術を反映しています。

  • 参考資料: ZTAへの移行を検討している場合は、原則、有効化技術コンポーネント、移行パターンに関するNIST ZTAの出版物、およびGoogleのBeyondProdに関する出版物を参照することが推奨されます。

  • セキュリティポリシーをコードとして、

  • エンドポイントセキュリティのためのサイドカー、

  • BeyondCorp など、多くの有効化技術を反映しています 。

  • ZTA への道のりにいる場合は、原則、有効化技術コンポーネント、移行パターンに関する NIST ZTA の出版物、および Google の BeyondProd に関する出版物を参照

【Access】

19. Declarative data pipeline definition

以下は、提供されたテキストの要約です。

  • 従来のデータパイプライン: 多くのデータパイプラインは、PythonやScalaで書かれた命令型スクリプトで定義されており、個々のステップのロジックとそれらを連結するコードの両方を含んでいます。
  • テストにおける類似の課題と解決策: Seleniumテストで同様の問題に直面した際、開発者はページオブジェクトパターンを採用し、BDD（ビヘイビア駆動開発）フレームワークではステップ定義とその構成を分離するようになりました。
  • データエンジニアリングへの適用: 一部のチームは、この考え方をデータエンジニアリングに応用しようと試みています。
  • 宣言型データパイプライン定義: YAMLなどで記述される宣言型のデータパイプライン定義は、ステップの宣言とシーケンスのみを含み、入出力データセットを宣言し、複雑なロジックはスクリプトを参照する形になります。
  • オープンソースツールの登場: この分野で最初のオープンソースツールとして「A La Mode」が登場しています。

感想: Scalaは宣言的のような。なんでもYAMLってのもちょっと。

20. DeepWalk

  • DeepWalkの目的: DeepWalkは、グラフに機械学習を適用する際に役立つアルゴリズムです。
  • グラフからの特徴量抽出: グラフデータセットで機械学習を行う際の主要な課題である、グラフからの特徴量抽出を支援します。
  • 動作原理: SkipGramを使用し、グラフを言語として捉えます。
    • 各ノードは言語における固有の単語とみなされます。
    • グラフ上の有限長のランダムウォークが文を構成します。
  • ノード埋め込みの生成: このプロセスを通じてノードの埋め込み（Embedding）を構築します。
  • MLモデルへの活用: 生成されたノード埋め込みは、様々な機械学習モデルで利用できます。
  • 試行中の技術: DeepWalkは、グラフに機械学習を適用する必要があるプロジェクトで試行されている技術の一つです。

感想: グラフのウォークが文になるのか。

【Hold】

Legacy migration feature parity

以下は、提供されたテキストの要約です。

  • レガシーシステム置き換えの必要性: 多くの組織が、顧客の要求を満たすために老朽化したレガシーシステムの置き換えを迫られています。
  • アンチパターンとしての「機能パリティ維持」: 既存システムとの機能パリティ（機能同等性）を維持しようとすることは、大きな機会損失です。
  • 置き換えの無駄: 古いシステムは肥大化し、多くの機能（Standish Groupのレポートによると50%）が使用されていないことが多いため、それらの機能を置き換えるのは無駄です。
  • 推奨されるアプローチ:
    • 顧客に一歩引いてもらい、ユーザーが現在何を必要としているかを理解する。
    • ビジネスの成果と指標に基づいてこれらのニーズを優先させる。
    • 通常、これはユーザー調査を実施し、既存のものを単に置き換えるのではなく、現代の製品開発プラクティスを適用することを意味します。

感想: わかっちゃいるけど、やめられない… SaaSでも、一度提供した機能は引っ込められない組織は多い。

Platforms

【Adopt】

29. Istio

  • サービスメッシュの採用: Kubernetesベースのスケーラブルなマイクロサービスアーキテクチャでは、サービスメッシュの採用が標準的です。
  • Istioの普及: 多くのサービスメッシュ実装の中で、Istioが広く採用されています。
  • 豊富な機能: Istioは、サービスディスカバリ、トラフィック管理、セキュリティ、可観測性（テレメトリ、分散トレーシング）、ローリングリリース、レジリエンスなど、多岐にわたる機能を提供します。
  • 改善されたユーザーエクスペリエンス: 最新リリースでは、インストールとコントロールプレーンのアーキテクチャが簡素化され、ユーザーエクスペリエンスが向上しました。
  • 運用の課題: Istioは大規模なマイクロサービスの実装を容易にする一方で、IstioとKubernetesインスタンスを運用するには専門知識と内部リソースが必要となります。

感想: この頃既にAdaptだったのか、未だに触った事がないが。。。

【Trial】

32. Crowdin

従来の翻訳ワークフローの課題: 多言語プロジェクトでは、開発チームが単一言語で機能を作成し、オフライン翻訳で他の言語を管理することが多いですが、これは非効率でコラボレーションを阻害します。
Crowdinの役割: Crowdinは、プロジェクトのローカライズワークフローを効率化するためのプラットフォームです。
開発と翻訳の並行作業: Crowdinを使用することで、開発チームは機能構築を続けながら、翻訳が必要なテキストをオンラインワークフローに効率的に取り込めます。
継続的な翻訳の推奨: Crowdinは、翻訳を大規模なバッチではなく、継続的かつ段階的に管理することを推奨しています。

感想: なんか仕事で使えないかな。コードベースを理解しながら翻訳する機能を実装できれば素晴らしいのだが。

36. Hydra

  • 完全準拠: オープンソースのOAuth2サーバーおよびOpenID Connectプロバイダーとして、完全に準拠しています。
  • 柔軟なストレージ: 開発用にはメモリ内ストレージを、本番環境用にはPostgreSQLのようなリレーショナルデータベースをサポートしています。
  • 高いスケーラビリティ: ステートレスな設計のため、Kubernetesなどのプラットフォームで水平方向に簡単にスケーリングできます。パフォーマンス要件に応じて、データベースインスタンスやHydraインスタンスを調整できます。
  • ID管理との分離: Hydra自体はID管理ソリューションを提供しません。これは、クリーンなAPIを通じて既存の認証エコシステムや任意のID管理システムと統合しやすいという利点があります。OAuth2フレームワークからIDを明確に分離することで、柔軟な連携が可能になります。

感想: 独自の認証機能を実装していた場合、(PHP/RDBでログイン画面を作ってしまったとか)移行しやすいかも。Keycloakと比較してクラスタリングがやりやすいかも。

37. OpenTelemetry

感想: この後も、何度もでてくる。

【Access】

46. MeiliSearch

  • 高速で使いやすい: MeiliSearchは、高速で使いやすく、デプロイが容易なテキスト検索エンジンです。
  • Elasticsearchとの比較: Elasticsearchはスケーラブルなテキスト検索の選択肢として人気がありますが、MeiliSearchは分散型ソリューションが不要な規模で、高速かつタイプミスに強い検索エンジンを提供したい場合に推奨されます。

感想: 今はRAGと併用できる検索エンジンが欲しいかな。

Tools

【Trial】

56. Jaeger

  • 分散トレーシングシステム: Jaegerは、オープンソースの分散トレーシングシステムです。
  • OpenTelemetry準拠: Google Dapperの論文に影響を受け、OpenTelemetryに準拠しています。
  • Istio/Envoyとの連携: IstioおよびEnvoyと組み合わせてKubernetesでうまく機能し、使いやすいUIも提供されています。
  • Prometheus形式のメトリクス: トレースメトリクスをPrometheus形式で公開しており、他のツールとの連携が可能です。
  • 新世代ツールとの比較: Honeycombのような新しいツールは、トレースとメトリクスを統合してよりシンプルな分析を提供しています。
  • CNCFでの成熟度: 2017年にCNCF（Cloud Native Computing Foundation）に参加し、最高レベルの成熟度に達しており、本番システムでの幅広い採用を示しています。

感想: 以前に検討したときはSQSがネックになっていたけど、Kafkaに変えたから使えるかも。

57. k9s

  • インフラストラクチャアズコードと監視の重要性: 分散アプリケーションの運用には、インフラストラクチャアズコードと堅牢な監視ソリューションが不可欠です。
  • AWSウェブコンソールの利用: AWSウェブコンソールのようなインタラクティブツールは、リソースのアドホックな探索に便利で、複雑なコマンドを覚える必要がありません。
  • 手動変更への懸念: インタラクティブツールを使った手動での変更は、依然として推奨されない運用方法です。
  • k9sの紹介: Kubernetes環境では、kubectlのほぼすべての機能にインタラクティブなインターフェースを提供するk9sが利用できます。
  • k9sの特徴: k9sはウェブアプリケーションではなく、ターミナルウィンドウ内で動作し、Midnight Commanderを彷彿とさせます。

感想: kubectl の使い方を忘れるツールは危険だな。

61. Open Policy Agent

  • 急速な普及: Open Policy Agent (OPA) は、分散型クラウドネイティブソリューションにおいて好ましいコンポーネントとして急速に普及しています。
  • 統一されたポリシーフレームワーク: OPAは、クラウドネイティブソリューションの様々なコンポーネントに対するポリシーを宣言、強制、制御するための統一されたフレームワークと言語を提供します。
  • 「ポリシーをコードとして」の実装: OPAは、セキュリティポリシーをコードとして実装する優れたツールです。
  • 多様な適用シナリオ: Kubernetesクラスターへのリソース展開、サービスメッシュ内のサービス間アクセス制御、アプリケーションリソースへのきめ細かいセキュリティ制御など、複数のシナリオでスムーズに利用できます。
  • 企業向け採用の促進: StyraのDeclarative Authorization Service (DAS) のような商用製品は、OPAに管理ツールやコントロールプレーンを追加し、事前構築済みポリシーライブラリ、ポリシー影響分析、ロギング機能を提供することで、企業でのOPAの採用を容易にしています。
  • 将来の展望: OPAが運用サービスを超えて、ビッグデータ中心のソリューションへと成熟・拡張することに期待が寄せられています。

感想: 2024年4月にもTrialで紹介されている。覚えた方がいいかな。

63. Phrase

  • 翻訳プラットフォームの選択: 大規模なスプレッドシートでのメールによるやり取りではなく、製品の多言語翻訳に特化したプラットフォームの利用が可能です。
  • Phraseの評価: チームはPhraseを肯定的に評価しており、主要なユーザーグループにとって使いやすいと報告しています。
  • ユーザーごとの利便性:
    • 翻訳者: 便利なブラウザベースのUIを利用できます。
    • マネージャー: 新しいフィールドの追加や、他のチームとの翻訳同期を同じUI内で実行できます。
    • 開発者: ローカル環境やビルドパイプラインからPhraseにアクセスできます。
  • バージョン管理機能: タグを通じて翻訳にバージョン管理を適用できる点が特筆され、これにより実際の製品における異なる翻訳の外観を比較できます。

感想: ビルドパイプラインに組み込んで、翻訳エンジンと組み合わせる方法はないのだろうか?

65. Visual regression testing tools

感想: 2024年10月にAdoptへ

【Access】

68. AsyncAPI

  • オープンスタンダードの重要性: 分散システムの構築において、OpenAPI（旧 Swagger）のようなオープンスタンダードは、RESTful APIの成功に貢献し、関連ツールの普及を促しました。
  • イベント駆動型システムの標準化の不足: イベント駆動型分散システムでは、このような標準化が不足しています。
  • AsyncAPIの役割: AsyncAPIは、イベント駆動型および非同期APIの標準化と開発ツール提供を目指すオープンソースイニシアチブです。
  • AsyncAPIの仕様: OpenAPI仕様に触発されており、イベント駆動型APIを機械可読な形式で記述・文書化します。
  • プロトコル非依存性: MQTT、WebSockets、Kafkaなど、多様なプロトコルに対応したAPIに利用可能です。
  • 今後の展望: AsyncAPIの継続的な改善と、そのツールエコシステムのさらなる成熟に期待が寄せられています。

感想: その後、2025年4月まで、Accessのまま。

71. Gloo

  • APIゲートウェイの存在意義の変化: Kubernetesとサービスメッシュの普及により、APIゲートウェイの機能の多くがイングレッサコントローラーやメッシュゲートウェイで提供されるようになり、その存在意義が問われています。
  • Glooの登場: Glooは、この変化を受け入れた軽量なAPIゲートウェイです。
  • Envoyの活用: ゲートウェイ技術としてEnvoyを使用し、外部ユーザーやアプリケーションに対してAPIの一貫したビューを提供します。
  • サービスメッシュ連携と管理インターフェース: Envoyゲートウェイの管理インターフェースを提供し、Linkerd、Istio、AWS App Meshなど複数のサービスメッシュ実装と連携して動作します。
  • 機能の提供: オープンソース版は基本的なAPIゲートウェイ機能を提供し、エンタープライズ版はAPIキー管理やOPAとの統合など、より高度なセキュリティ制御を備えています。
  • クラウドネイティブエコシステムとの親和性: Glooは、クラウドネイティブ技術とアーキテクチャのエコシステムとよく連携し、APIゲートウェイにビジネスロジックを結合させるという一般的な問題を回避する、有望なソリューションです。

感想: Kubernetesでサービスメッシュを構築すると、APIゲートウェイは要らなくなるのか・・・ 仕事では使い続けてしまっている。

72. Lens

以下は、提供されたテキストの要約です。

  • Kubernetesの強みと課題: Kubernetesは柔軟性、構成可能性、API駆動型のプログラマブルな構成、マニフェストファイルによる可視性と制御が強みですが、複雑なデプロイや複数クラスターの管理においては、コマンドラインやマニフェストだけでは全体像の把握が困難になるという課題があります。
  • Lensの目的: Lensは、このKubernetes管理の課題を解決しようとするツールです。
  • 統合環境の提供: クラスターとそのワークロードの現在の状態表示、クラスターメトリクスの可視化、組み込みのテキストエディタによる設定変更のための統合環境を提供します。
  • ユニークなアプローチ: 単純なポイント＆クリックインターフェースではなく、管理者がコマンドラインから必要なツールを一つのナビゲート可能なインターフェースに統合します。
  • グラフィカルUIとコマンドラインのバランス: Kubernetes管理の複雑さを克服する多くのアプローチがある中で、LensはグラフィカルUIとコマンドラインツールの間で興味深いバランスをとっています。

感想: 既存のプロジェクトに参加した時に、構成を手っ取り早く確認したい時に便利かも。同様のツールは以下の通り。

  • シンプルな管理と手軽さを求めるなら Kubernetes Dashboard や Skooner。
  • ターミナルでの高度な操作性を求めるなら k9s。
  • 複数クラスターの一元管理や包括的な機能を求めるなら Rancher。
  • 開発者向けの可視化やデバッグに重点を置くなら Octant。
  • 運用効率化やトラブルシューティングに特化するなら Komodor。

Languages & Frameworks

【Trial】

81. Exposed

以下は提供されたテキストの要約です。

  • Kotlin特化フレームワークの利用: 開発チームはKotlinの使用経験が豊富になり、JavaフレームワークをKotlinで使うのではなく、Kotlin専用に設計されたフレームワークを好んで使用しています。
  • Exposedの注目: 軽量なORM（オブジェクト関係マッパー）であるExposedに注目しています。
  • Exposedのデータベースアクセス方法:
    • SQLをラップした型安全な内部DSL（ドメイン固有言語）。
    • DAO（データアクセスオブジェクト）パターン実装。
  • Exposedの機能: 多対多参照のハンドリング、Eager Loading（即時ロード）、エンティティ間の結合（Join）サポートなど、成熟したORMに期待される機能を提供します。
  • パフォーマンス上の利点: プロキシを使用せず、リフレクションに依存しない実装である点がパフォーマンス上有利です。

感想: ScalaのSlickみたいなものかな。他には

Kotlinの主なORM/データベースアクセスライブラリ

  1. Ktorm:

    • Exposedと同様に、Kotlinに特化した軽量なORMフレームワークです。
    • 強力な型付けされたSQL DSL（Domain Specific Language）とシーケンスAPIを提供し、Kotlinの標準ライブラリのシーケンス関数に似た形でクエリを記述できます。
    • 直接JDBCの上に構築されており、SQLの自動生成を行います。
    • Exposedと同様に、SQL DSLとエンティティオブジェクト（ORM的なアプローチ）の両方をサポートします。
    • ドキュメントが充実していると評価されることがあります。

  2. SQLDelight (Cash App開発):

    • SQLファイルから型安全なKotlin APIを生成するライブラリです。
    • ORMというよりは「SQLを第一に考える」データアクセスライブラリと言えます。SQLクエリを直接記述し、それをコンパイル時に検証してKotlinコードを生成するため、実行時エラーのリスクを減らせます。
    • 特にSQLiteデータベースに強みがありますが、他のデータベースへのサポートも拡張されています。
    • よりSQLを直接制御したいが、型安全性を確保したい場合に非常に強力です。

  3. jOOQ (Java Object-Oriented Querying):

    • Javaで開発されたライブラリですが、Kotlinでも非常に快適に利用できます。
    • 「SQLを可能な限り型安全に扱う」ことを目指しており、データベーススキーマからKotlin（またはJava）のクラスを生成し、それを使って型安全なクエリを構築します。
    • SQLの全機能をほぼ完全にカバーしており、複雑なSQLクエリも型安全に記述できます。
    • ORMというよりも、高度なSQLビルダーと考えるのが適切です。SQLの知識が豊富で、複雑なクエリを多用する場合に非常に強力です。

  4. Hibernate (with Kotlin):

    • Javaの世界で最も広く使われているORMの一つですが、Kotlinでも利用できます。
    • 成熟しており、豊富な機能と広範なドキュメント、巨大なコミュニティを持っています。
    • ただし、アノテーションベースのエンティティマッピングやプロキシの利用など、Javaの慣習に強く依存している部分があります。KotlinネイティブなDSLとは異なり、JavaのAPIをKotlinから使う形になります。
    • 大規模なエンタープライズアプリケーションや、既存のHibernateプロジェクトにKotlinを導入する場合に検討されます。

  5. KotliQuery:

    • ScalikeJDBCに影響を受けた、Kotlin向けの軽量なデータベースアクセスライブラリです。
    • ORMというよりは、より低レベルのJDBC操作をKotlinらしく、より使いやすくするためのヘルパーライブラリという位置づけです。
    • 生のSQLを記述しつつ、結果のマッピングなどをKotlinの構文で簡潔に行いたい場合に適しています。

  6. Kapper:

    • Dapper（.NETのマイクロORM）にインスパイアされた軽量なORMライブラリです。
    • SQLを抽象化するのではなく、SQLを最大限に活用しつつ、Kotlinでの実行とマッピングに便利な機能を提供します。
    • 「Abstraction Trap（抽象化の罠）」を避け、SQLの透明性を重視する設計思想が特徴です。
選択のポイント
  • 型安全なDSLを重視するか: ExposedやKtorm、SQLDelight、jOOQがこれに該当します。
  • SQLを直接記述したいか、ORMに任せたいか:
    • SQLを直接制御: SQLDelight, jOOQ, KotliQuery
    • オブジェクト指向で操作: Exposed (DAO), Ktorm (エンティティオブジェクト), Hibernate
  • 軽量性を重視するか、機能の豊富さを重視するか:
    • 軽量: Exposed, Ktorm, SQLDelight, KotliQuery, Kapper
    • 高機能: Hibernate, jOOQ (SQL機能が非常に豊富)
  • 既存のJavaプロジェクトとの互換性: HibernateはJavaエコシステムとの親和性が非常に高いです。
  • 学習コスト: ExposedやKtormは比較的Kotlinらしい記述で学びやすいですが、HibernateやjOOQはより専門的な知識が求められる場合があります。

抽象化の罠ってのは重要なポイントかも。SQLが嫌われつつも何十年も生き残っている理由をちゃんと理解すべき時期である。

83. Karate

  • テストの重要性: テストは唯一信頼できるAPI仕様であるという経験から、新しいテストツールを常に探しています。
  • Karateの特徴:
    • APIテストフレームワークであり、その独自の特徴はテストがGherkinで直接記述され、汎用プログラミング言語に依存しないことです。
    • HTTPベースのAPIテストを記述するためのドメイン固有言語（DSL）です。
  • チームの評価と推奨:
    • チームは、このツールで得られる読みやすい仕様を好んでいます。
    • テストピラミッドの上層部（高レベルのテスト）でKarateを使用し、非常に詳細なアサーションを行うことで過度に使用しないよう推奨しています。

感想: 未だにTrialのまま…

GitHubで編集を提案

Discussion