ソートワークスのテクノロジー レーダー 27 からの開発者トレンド

Thoughtworks の Technology Radarは、経験豊富な業界の専門家が、ツール、プラクティス、およびテクノロジの次の波である可能性があると考える、または使用を停止するものを検討する定期的な時間です。

リストに多くの新しい「ブリップ」を追加するか、最後に見た後にどれが採用されているかを確認することを常に楽しみにしています.

バージョン 27 がリリースされましたが、「サービスとしてのプラットフォーム」やグループ プログラミングの形式など、レーダーがしばらく追跡してきたいくつかの傾向が続いています。このまとめは包括的とは言えませんが、私が興味を持った、またはあなたにアピールするかもしれないと思ったブリップだけです.

それらのいずれかに興味がある場合、または私が取り上げたものについて意見がある場合は、プロフィールにアクセスして、読者に知らせてください!

機械学習の主流化

過去 6 か月ほどの間に、機械学習は、主に開発者とデータ サイエンティストだけがやり取りするものから、一般の人々が認識できるものになったように感じます。

何かを入力すると何らかのメディアを吐き出す別の ML または AI ベースのツールの発表が次々と発表され、何千もの奇妙に見える有名人の画像やビデオに圧倒されました。

これはまた、ML の実験に関心のある開発者は、データ セットとそれらのデータ セットを使用するためのフレームワークの形で、より多くのリソースを利用できることも意味します。

実験的な開発者に関連するのはTinyMLです。これは、さまざまな常時オンのユースケースを可能にし、バッテリー駆動のデバイスを対象とする機械学習の分野です。

もう 1 つは機能ストアです。これは、ML パイプラインを作成するための方法であり、他のバックグラウンドを持つ開発者にはなじみがあるかもしれません。

このレーダーは、モデルの構築とトレーニングの開発者エクスペリエンスを向上させるための ML 関連ツールも対象としていました。たとえば、初期モデル テスト用の処理または合成データのためにマシン間でモデル データを集約するための「フェデレーション マシン ラーニング」の実践などです。

継続的な可観測性

比較的新しい用語であるにもかかわらず、「可観測性」は、実行中のシステムのより良い全体像を構築するための実践と標準の緩いコレクションから急速に成長し、あらゆる種類のことを意味するより広い用語になりました。

インサイトを受け取る開発者ワークフローの最新の領域は、継続的インテグレーションとデリバリー パイプラインのオブザーバビリティであることに驚くほど時間がかかりました。

CI と CD は確かにメリットをもたらしますが、試行するまで再試行するまで、何についての洞察がほとんどなく、プロセスがうまくいかないことがよくあります。

現在、少数の既存のオブザーバビリティ ベンダーとオープンソース プロジェクトが、継続的なプロセスのトレース スタイルの視覚化を提供しており、うまくいけば、何が起こっていたかを完全にデバッグするのに役立ちます。

ソフトウェア部品表

開発者が作業のために半匿名のコンテナーとパッケージにますます依存するようになると、セキュリティと合法性に焦点を当てている開発者は、「これを信頼できるか?」と見て疑問に思いました。

この懸念により、（特に企業では）「ソフトウェア部品表」の標準化と標準化が急がれるようになりました。これは、コミカルな頭字語である SBOM と呼ばれることがよくあります。

理論的には、「誰でも」オープンソース プロジェクトを掘り下げて、そのコンポーネントが何であるかを確認できますが、これは一般的に言うは易く行うは難しであり、クローズド ソース プロジェクトではまったく不可能です。

最近注目を集めたソフトウェアの脆弱性により、わずかな依存関係がいかに大きな問題を引き起こすかが明らかになりました。 SBOM は大いに役立つ可能性がありますが、どれだけの企業が内部の仕組みを明らかにし、正直になりたいと思うでしょうか。

持続可能なコーディング

これは、Thoughtworks のカーボン クラウド フットプリント ツールについて誰かと話した後、自分自身をカバーすることに触発されたトピックです。

新しいフレームワーク、ツール、クラウド フレームワークを問題に際限なく投入する傾向があるため、これらすべてのコード行が実際に何かのどこかで実行されていることを多くの人が忘れています。

そして、それは二酸化炭素の排出につながります。水は利他的な理由や経済的な理由で動機付けられ、エキュメニックな不況はコスト削減につながります。これは、より多くの話題になり、考えられています。

プロジェクトとそのインフラストラクチャの環境コストに密接に関連しており、運用チームで使用されているのを私が見たオプションは、Terraform 定義に加えた変更のコストへの影響を見積もるインフラコストです。

コードとしての責任

どの SaaS 企業も、クライアントが期待できるサービス レベル指標 (SLI) とサービス レベル目標 (SLO) を定義しています。

しかし、企業がこれらをどのように定義したかは、しばしば少しでたらめで非標準的であり、成文化されたパイプラインで他の多くが定義されているのに、なぜこの基本的なコンポーネントも定義しないのでしょうか?

現在、いくつかの可観測性プロバイダーがこのオプションを提供しており、もちろん、人々のグループが標準のOpenSLOを開始しました。

ノードへのノー

私は JavaScript と TypeScript に手を出していますが、最近、Node に代わるランタイムがいくつか出現していることに気付きました。 Node の何が問題なのかはわかりませんが、現在はかなり古いため、代替手段を保証する必要がありますが、競争は良いと思います 🤷‍♂️?

Bunは、私が数か月前に試した新しい代替手段の 1 つであり、それがどのような利点をもたらしたかはよくわかりませんでしたが、Chrome の V8 エンジンの代わりに WebKit の JavaScriptCore を使用しています。

繰り返しますが、多様性は悪いことではありません。 Bun は、私がこれまで聞いたことのないZigで書かれており、「ドロップイン」の C/C++ 置換であると主張しています。

これは…にうまくつながります

C+++

Zig、Rust、およびその他の言語に問題があるとすれば、C++ にはより現代的な代替が必要であると多くの人が感じています。 Google は、 Carbonの候補リストに別のオプションを追加しました。

この言語はまだ実験段階ですが、理解しやすく、使いやすいと主張しています。 Google は多くの実験的プロジェクトを立ち上げてから再び捨てる傾向があるため、Thoughtworks の提案は現在のところ「様子見」です。