Zenn
⛳

Technology Radar vol.25(2021年10月版)を読む

に公開
Technology Radar
tech

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

    1. CBOR/JSON bilingual protocols
    1. レガシーシステムにおける生きたドキュメント
    1. Pulumi
    1. Lens
    1. Micoo
    1. lifelines
    1. ksqlDB

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

Techniques

1. Four key metrics

Adopt

ソフトウェアデリバリパフォーマンスを測定するために、ますます多くの組織がDORA研究プログラムによって定義された4つの重要なメトリクスに注目している。この調査とその統計分析により、高いデリバリーパフォーマンスとこれらのメトリクスとの間に明確な関連性があることが示されています。これらのメトリクスは、チーム、あるいはデリバリー組織全体がどのような状態にあるかを示す優れた先行指標となります。

私たちは今でもこれらの測定基準の大きな支持者ですが、最初に監視を開始して以来、いくつかの教訓も学びました。そして、チームが純粋に継続的デリバリー（CD）パイプラインに基づいてこれらのメトリクスを測定するのを支援するツールで、誤った測定アプローチを目にすることが増えている。特に安定性メトリクス（MTTRと変更失敗率）に関しては、CDパイプラインのデータだけでは、実際のユーザーに影響を与えるデプロイの失敗を判断するのに十分な情報を提供できません。安定性メトリクスは、ユーザーのサービスを低下させる実際のインシデントに関するデータを含んで初めて意味を持つ。

そして、すべての測定基準と同様に、測定の背後にある最終的な意図を常に念頭に置き、それを振り返り、学ぶために使用することを推奨する。例えば、洗練されたダッシュボードツールを構築するために何週間も費やす前に、チームのレトロスペクティブでDORAクイックチェックを定期的に実施することを検討する。これによってチームは、メトリクスを改善するためにどの機能に取り組めばよいかを考える機会を得ることができる。

4. CBOR/JSON bilingual protocols

Trial

CBORは以前から存在していたが、データ交換のためにCBOR仕様を使用することが理にかなっているユースケースを目にする機会が増えている。私たちがCBORエンコーダー／デコーダーのScala実装であるBorerで便利だと思ったことの1つは、クライアントがバイナリ表現と古いJSONフォーマットの間でコンテンツをネゴシエートできることです。簡潔なバイナリ形式だけでなく、ブラウザで表示可能なテキスト形式があるのは非常に便利だ。CBOR／JSONバイリンガルプロトコルは、IoTやエッジコンピューティングの継続的な台頭や、その他の環境制約が厳しい状況において、人気が高まることが予想されます。

感想: バイナリ形式を使いたい場合も多いよね。

6. レガシーシステムにおける生きたドキュメント

Trial

動作駆動開発（BDD）コミュニティに由来するLiving documentationは、しばしば、実行可能な仕様を持つよくメンテナンスされたコードベースの特権と考えられている。我々は、この手法がレガシーシステムにも適用できることを発見した。ビジネス知識の欠如は、システムの近代化を行う際にチームが遭遇する一般的な障害である。スタッフの入れ替わりや既存のドキュメントが古くなっているため、コードは通常、唯一の信頼できる真実の情報源である。そのため、レガシーシステムを引き継ぐ際には、ドキュメントとコードの関連性を再構築し、チーム内にビジネス知識を広めることが非常に重要だ。実際には、まずコードベースを見て、簡単なクリーンアップと安全なリファクタリングを通じてビジネスへの理解を深めるようにする。その過程で、後で生きたドキュメントを自動生成できるように、コードに注釈を加える必要がある。これは、グリーンフィールドプロジェクトでBDDを行うのとは大きく異なるが、レガシーシステムでは良いスタートとなる。生成されたドキュメントに基づき、いくつかの仕様を実行可能な高レベル自動化テストに変換しようとする。これを繰り返し行うことで、最終的には、コードと密接に関連し、部分的に実行可能な、レガシーシステムにおける生きたドキュメントを手に入れることができるだろう。

感想: ドキュメントを書いても、書いたそばからグチャグチャにする開発者が多いからこういうのは欲しい。

Platforms

26. Pulumi

Trial

さまざまな組織でPulumiを使うチームが増えているのを目にするようになった。Pulumiは、Terraformが確固たる地位を保っているインフラコーディングの世界で、ぽっかりと空いた穴を埋めてくれる。Terraformは試行錯誤の末に完成されたものだが、その宣言的な性質は抽象化機能が不十分で、テスト可能性が限られているという問題を抱えている。インフラが完全に静的な場合はTerraformで十分だが、動的なインフラ定義には本物のプログラミング言語が必要だ。Pulumiは、TypeScript/JavaScript/Python/Goでコンフィギュレーションを記述できる点が特徴だ。Pulumiは、コンテナ、サーバーレス機能、データサービスなど、クラウドネイティブなアーキテクチャにしっかりとフォーカスしており、Kubernetesをしっかりとサポートしている。最近、AWS CDKが挑戦しているが、Pulumiはこの分野で唯一のクラウドニュートラルなツールであり続けている。

感想: TerraformってIaCというだけなら使えても、やっぱり機能不足な部分が目につく。

35. Thought Machine Vault

Assess

市販のソフトウェアをRadarで取り上げるのは珍しい。しかし、Thought Machine Vault（Thoughtworksとは無関係）は、テスト駆動開発、継続的デリバリー、Infrastructure as Codeといった優れたソフトウェアエンジニアリングの実践をサポートするように設計された、このクラスの製品の一例である。開発者はPythonコードでスマートコントラクトを記述することで、Vaultで銀行商品を定義する。これは、カスタマイズがグラフィカル・インターフェースや独自の設定ファイル、あるいはその両方を通じて行われる標準的なノーコード・アプローチとは明らかに異なる。商品は通常のPythonコードで定義されるため、開発者はテストフレームワークやバージョン管理などのさまざまなツールを利用し、作業の安全性と正確性を確保することができる。より多くの金融サービスプラットフォームが、開発者の有効性を念頭に置いて設計されることを望む。

Tools

39. Batect

Trial

Batectは開発者の間で支持され続けており、多くの人がローカルの開発環境とテスト環境を設定するためのデフォルトのアプローチだと考えている。このオープンソースツール（偶然にもThoughtworkerによって開発されている）は、Dockerベースのビルド環境を簡単にセットアップして共有できる。Batectはその後、ビルド・システムのエントリー・ポイントとなり、「チェック・アウト・アンド・ゴー」アプローチの基礎として、どこにでもあるgoスクリプトに取って代わる。Batectは開発者からのフィードバックに応えて進化し続けており、最近ではDockerのBuildKitとシェルタブ補完のサポートを追加しました。

41. Contrast Security

Trial

Contrast Securityは、静的アプリケーション・セキュリティ・テスト（SAST）、対話型アプリケーション・セキュリティ・テスト（IAST）、オープンソース・スキャン、ランタイム・アプリケーション・セルフ・プロテクション（RASP）など、複数のコンポーネントを備えたセキュリティ・プラットフォームを提供している。数年前から存在しており、複数のプロジェクトで使用してきました。Contrastプラットフォームの気に入っている点の1つは、ライブラリのランタイム分析です。これは、使用されていないライブラリを特定するのに役立ち、ひいては私たちのチームが脆弱性に優先順位をつけたり、使用されていないライブラリを削除したりするのに役立ちます。これは、ソフトウェアのサプライチェーンを保護することの重要性が増していることを考えると、特に適切なことです。継続的デリバリー（CD）パイプラインでは、誤検出を減らし、幅広い脆弱性を検出することができます。

43. Lens

Trial

我々のチームでは、Kubernetesクラスタを可視化・管理するためにLensを使用すると良い結果が得られると報告し続けている。KubernetesのためのIDE」と称されるLensは、コマンドやマニフェストのファイル構造を覚えることなく、クラスタと対話することを可能にする。Kubernetesは複雑である可能性があり、クラスタメトリクスとデプロイされたワークロードを視覚化するツールがあれば、時間を節約し、Kubernetesクラスタの保守に関わる労力を軽減できることを私たちは理解しています。Lensは、シンプルなポイント＆クリック・インターフェースの背後に複雑さを隠す代わりに、管理者がコマンドラインから実行するようなツールをまとめている。しかし、どのようなメカニズムであれ、実行中のクラスタに対話的に変更を加えることには注意が必要だ。私たちは一般的に、インフラストラクチャの変更はコードで実装されることを好みます。そうすることで、再現性があり、テスト可能で、ヒューマンエラーが起こりにくくなります。しかし、Lensはクラスタの状態を対話的にナビゲートし、理解するためのワンストップツールとして優れています。

感想: やっぱりKubernetesの構成って複雑になるから可視化するツールが欲しくなるよね。

44. Nx

Trial

何年もの間、レーダーにモノレポを搭載するかどうか何度も議論してきました。そのたびに、モノレポがもたらすトレードオフには微妙な議論が必要であり、このテクニックは 「blipするには複雑すぎる 」という結論に至りました。例えば、このポッドキャスト・エピソードで議論されているように、マイクロ・フロントエンドで構成されるアプリケーションの構築のためなどだ。これが良いアイデアかどうかは、あなたの状況によって大きく異なるので、一般的な推奨をするつもりはない。我々がコメントしたいのは、ツールについてだ。私たちのチームでは、Lernaからシフトし、JavaS criptベースのモノレポを管理するためにNxを使うことを強く希望しています。

49. Comby

Assess

今回のレーダーでは、抽象構文木（AST）表現を使ってコードを検索・置換するツールを2つ紹介する。これらはjscodeshiftと同じような空間を占めているが、幅広いプログラミング言語用のパーサーを含んでいる。共通点もあるが、異なる点もいくつかある。これらのツールの1つであるCombyは、awkやsedといったUnixツールの精神に基づいて設計されたシンプルなコマンドラインインターフェイスが特徴だ。Unixのコマンドは正規表現に基づいてテキストのマッチングを行うが、Combyはプログラミング言語の構成要素に特化したパターン構文を採用し、検索前にコードを解析する。このため、開発者は大規模なコードベースから構造的なパターンを探し出すことができる。sedのように、Combyはマッチしたパターンを新しい構造に置き換えることができる。これは、大規模なコードベースへの全体的な変更を自動化したり、一連のマイクロサービスリポジトリ全体で反復的な変更を行ったりするのに便利だ。これらのツールはかなり新しいので、まだ発見されていない様々な創造的な使い方があることを期待している。

54. Micoo

Assess

Micooは、ビジュアル回帰ツールの混雑した空間への新しい参入者である。オープンソースのソリューションであり、自己完結型で、簡単で迅速な環境設定を可能にするDockerイメージを提供する。また、Node.js、Java、Python用のさまざまなクライアントとCypressプラグインを提供しているので、一般的なフロントエンドのUI自動化テストフレームワークやソリューションのほとんどと簡単に統合できる。Micooは、SaaSベースのソリューションや他の商用ソリューションの全ての機能を提供しているわけではありませんが、私たちのチームは幅広く使用しており、ポジティブな経験をしています。特に、ウェブだけでなく、モバイルやデスクトップアプリでも動作することが評価されています。

感想: ビジュアル回帰テストはやっていきたい。

Languages and Frameworks

66. Jetpack Compose

Adopt

AppleがSwiftUIを導入したのと同じような動きとして、GoogleはJetpack Composeを導入した。Composeは、より強力なツールと直感的なKotlin APIをもたらす。ほとんどの場合、必要なコードは少なくなり、データで埋められる静的なUIを定義するよりも、実行時にユーザーインターフェイスを作成する方が簡単になりました。Compose MultiplatformとKotlin Multiplatformにより、開発者はデスクトップ、ウェブ、ネイティブAndroidアプリを構築するための統一されたツールキットを手に入れることができる。Wear OS 3.0+も含まれており、Kotlin Multiplatform MobileではすでにiOSがサポートされているため、将来的にはiOSもComposeでサポートされることになるだろう。

67. React Hooks

Adopt

React Hooksは、ステートフルなロジックを管理するための新しいアプローチを導入した。Reactコンポーネントは常にクラスよりも関数に近かったため、Hooksはこれを受け入れ、メソッドでステートへの関数を取るためにクラスを使用する代わりに、関数にステートをもたらした。Reactアプリケーションにおける状態管理のもうひとつの定番はReduxだが、Reduxの複雑さがそれに値しないこともあり、そのような場合はHooksを使ったシンプルなアプローチが望ましいことを示唆している。そのため、React ContextとuseContextフックとuseReducerフックの組み合わせを、このブログポストで説明されているラインに沿って検討することをお勧めします。

68. Arium

Trial

Ariumは、Unityで書かれた3Dアプリケーションのための自動テストフレームワークである。機能テストは健全なテストピラミッドの重要な部分です。Unity Testフレームワークのラッパーとして構築されたAriumは、複数のプラットフォーム上の3Dアプリのための機能テストを書くことができます。私たちは、いくつかのプロジェクトでこれを使用して成功している。

70. DoWhy

Trial

DoWhyは、因果推論と分析をエンドツーエンドで行うためのPythonライブラリである。機械学習モデルは、その時点で存在する変数の相関関係を利用することで、事実データに基づいた予測を行うことができますが、What ifやWhyを問う必要があるシナリオでは不十分です： もし変数が変化したら？ある変数が変化したらどうなるか？因果推論は、このような質問に答えるためのアプローチである。これは因果効果、つまり原因変数の1つを変えた場合に結果が変わる大きさを推定します。このアプローチは、実験のコストや制限のために、観察やA／B検定によるデータ収集では答えにたどり着けない場合に適用されます。DoWhyライブラリは、過去に収集された事実やデータ、およびその領域を知っている仮定を使用するプロセスに基づいて因果効果を推定します。仮定に基づいて因果関係グラフをモデル化し、結果の原因を特定し、因果効果を推定し、最後に結果に反論することで仮定に挑戦するという4段階のプロセスを使用します。私たちはこのライブラリを実運用でうまく使っており、因果関係推定のユースケースでよく使われるライブラリの1つです。

74. lifelines

Trial

lifelinesはPythonで生存分析を行うためのライブラリです。もともとは出生と死亡のイベントのために開発されましたが、あらゆる期間を予測するための完全な生存分析ライブラリへと進化しました。医学的なユースケース(例えば、この集団は何年生きられるのか？)にとどまらず、小売業や製造業で、ユーザがサービスに加入している期間はどれくらいか、次の予防保守はいつ行うべきか、といった質問に答えるために使ってきました。

感想: 業務のSaaSの分析に使える？

77. pydantic

Trial

もともと型アノテーションは静的解析をサポートするためにPythonに追加された。しかし、型アノテーションや一般的なアノテーションが他のプログラミング言語でも広く使われていることを考えると、開発者がPythonの型アノテーションを他の目的で使い始めるのは時間の問題でした。pydanticを使えば、実行時のデータ検証や設定管理に型アノテーションを使うことができます。データが例えばJSONドキュメントとして送られてきて、Pythonの複雑な構造にパースする必要があるとき、pydanticは送られてくるデータが期待される型と一致するかどうかを確認し、一致しない場合はエラーを報告します。pydantic を直接使うこともできますが、多くの開発者は最も人気のある Python Web フレームワークの一つである FastAPI の一部として使っています。実際、FastAPIでpydanticを使うことは必要不可欠であると考えられており、最近提案されたPythonの変更案では、アノテーションされたコードをメモリにロードするコストを削減することが目的でしたが、実行時に型アノテーションを使うことができなくなるため、再検討されました。

80. React Query

Trial

React Queryは、Reactに欠けているデータフェッチライブラリだとよく言われる。サーバーの状態をフェッチ、キャッシュ、同期、更新することは、多くのReactアプリケーションで共通の要件であり、要件はよく理解さ
れているが、実装を正しく行うことは難しいことで知られている。React Queryは、フックを使った簡単なソリューションを提供する。アプリケーション開発者としては、データを解決する関数を渡すだけで、あとはすべてフレームワークに任せることができる。すぐに使えるが、必要なときに多くの設定ができる点が気に入っている。開発者ツールは、残念ながらReact Nativeではまだ利用できないが、フレームワークの仕組みを理解するのに役立ち、React Nativeを初めて使う開発者にはメリットがある。私たちの経験では、フレームワークのバージョン3は、私たちのクライアントと本番で使用するために必要な安定性をもたらした。

81. Tailwind CSS

Trial

私たちの開発者は Tailwind CSS を使って生産性を上げ続けており、大規模なチームやコードベースにも対応できる拡張性に感心しています。Tailwind CSS は、低レベルのユーティリティCSSクラスによって複雑さを軽減する、CSSツールやフレームワークの代替アプローチを提供します。Tailwind CSSのクラスは、顧客のビジュアル・アイデンティティに合わせて簡単にカスタマイズできます。また、ヘッドレスUIと特に相性が良いことも分かっています。Tailwind CSSを使えば、自分でクラスやCSSを書かなくて済むので、長期的には保守性の高いコードベースになります。Tailwind CSSは、ビジュアル・コンポーネントを作成する上で、再利用性とカスタマイズ性のバランスがとれているようだ。

87. Headless UI

Assess

Headless UIは、Tailwind CSSを作ったのと同じ人たちによるReact.jsまたはVue.js用のスタイルなしコンポーネント・ライブラリだ。私たちの開発者は、他のコンポーネント・ライブラリに付属しているデフォルトのスタイルをカスタマイズしたり回避したりする必要がないことを気に入っています。コンポーネントの豊富な機能と完全なアクセシビリティが、摩擦のないスタイリングと組み合わさることで、開発者はビジネス上の問題とユーザーエクスペリエンスにより生産的に集中することができます。当然のことながら、Headless UI は Tailwind CSS クラスとの相性も抜群です。

90. ksqlDB

Assess

もしあなたがApache Kafkaを使ってストリーム処理アプリケーションを構築しているなら、ksqlDBはSQLライクなステートメントを使ってシンプルなアプリケーションを書くのに最適なフレームワークだ。しかし、軽量のSQLライクなステートメントを使用して、既存のKafkaトピックの上に新しいKafkaストリームやテーブルを構築することができる。クエリは、Kafkaトピックからデータを読み込むのと同じように、データを引き出すことができる。従来のデータベースや、増分的な変更が発生したときにアプリケーションに結果をプッシュすることもできます。既存の Apache Kafka インストールの一部としてネイティブにスタンドアロンサーバーとして実行するか、Confluent Cloud 上のフルマネージドサービスとして実行するかを選択できる。私たちは単純なデータ処理のユースケースで ksqlDB を使用している。アプリケーションに代数的な SQL クエリを超えるプログラミングコードが必要な、より複雑なユースケースでは、Kafka の上に Apache Spark や ApacheFlink などのデータ処理フレームワークを引き続き使用します。アプリケーションのシンプルさが許すシナリオでは、ksqlDBを試してみることをお勧めします。

感想: Event Sourcingで使える？

93. Qiankun

Assess

マイクロ・フロントエンドは登場以来、人気を集め続けている。しかし、スタイリング手法から状態管理に至るまで、チームがアプリケーション全体の一貫性を維持できなければ、マイクロフロントエンドは無秩序に陥りやすい。中国語で天と地を意味するQiankunは、この問題をすぐに解決するために作られたJavaScriptライブラリだ。Qiankunはsinglespaをベースにしているため、異なるフレームワークをひとつのアプリケーションに共存させることができる。また、マイクロアプリケーションのスタイルや状態が互いに干渉しないように、スタイルの分離とJavaScriptのサンドボックスも提供する。Qiankunはコミュニティで注目されている。我々のチームもまた、よりフレンドリーなデバッグをサポートできることを期待して、それを評価している。

感想: やっぱり、マイクロフロントエンドは無秩序に陥りやすいみたい。

94. React Three Fiber

Assess

ウェブブラウザでの3Dや拡張現実（XR）アプリケーションへの関心が高まり、その実現可能性が高まる中、私たちのチームはウェブ上で3D体験を開発するためにReact Three Fiberを試してきました。React Three Fiberは、React.jsコンポーネントとステートモデルをThree.jsライブラリでレンダリングされた3Dオブジェクトに変換するライブラリです。このアプローチにより、React.jsと豊富なエコシステムに既に慣れ親しんでいる幅広い開発者グループに、3Dウェブ・プログラミングを開放する。それを取り巻くツールやライブラリの数々 しかし、React Three Fiberでアプリケーションを開発する場合、我々のチームはしばしば3Dシーンを必然的に操作しなければならない。これは、Reactが提供するリアクティブ・コンポーネントのパラダイムとは相性が悪い。基本的な3Dレンダリングのメカニズムを理解する必要性から逃れることはできない。React Three Fiberが、その特異性を学ぶに値するだけの抽象化を提供しているのか、それともThree.jsで直接作業した方が良いのか、判断はまだついていない。

GitHubで編集を提案

Discussion