LLM 以外の注目すべき 5 つのソフトウェア トレンド

Engineer’s Codex は、現実世界のソフトウェア エンジニアリングに関する出版物です。

2022 年 11 月に ChatGPT がリリースされて以来、LLM はテクノロジー界で大流行しています。それがほぼ 2 年前にリリースされたと考えると、気が狂いそうです。しかし、同じ時期に、LLM の誇大宣伝のせいで、当然の宣伝を受けていないソフトウェア エンジニアリングの他の多くの刺激的な進歩がありました。

LLM が革新的であることは事実であり、私は LLM を毎日扱っていますが、他にも非常に多くのことが魅力的に進歩しています。以下でいくつかのトピックについて説明し、さらに詳しく知りたい人のために各トピックのリンクを多数提供します。私は、これらのトピックは時間の経過とともに増加する傾向であると考えています。

ローカルファースト ソフトウェアは何十年も前から存在していますが、ここ数年はローカルファースト ソフトウェアに関する開発者のエクスペリエンスを向上させる活動が活発になっているようです。ローカルファースト ソフトウェアは、リモート サーバーのみに依存するのではなく、ユーザーのローカル デバイス上でのデータの保存と処理を優先します。

ローカル ファースト ソフトウェア パラダイムへの最良の入門書は、Ink と Switch によるものです。 ローカルファースト ソフトウェア: クラウドにもかかわらず、データはお客様が所有します。

React-Query、PouchDB、InstantDB、Legend-State、PowerSync、ElectricSQL などの企業やパッケージは、クライアントとサーバー間の同期プロセスを容易にすることに重点を置いています。

ローカルファーストは、ユーザー エクスペリエンスの自然な次のステップです。ローカルで永続化すると、インターネット接続がほとんどない、またはまったくない場合でも、インタラクションの遅延がほぼゼロになり、ユーザー エクスペリエンスが向上し、クライアントの回復力が向上します。ソフトウェアに対するユーザーの期待は今後も高まり続けるため、これは特に重要になると私は予想しています。

この分野での興味深い取り組みとしては、競合の解決があります。競合の解決は、ローカルの変更とサーバー側の変更が互いに競合しており、解決が必要な場合に必要です。最も一般的な競合解決方法の簡単な概要を以下にまとめました。 (注: 一部のシステムでは、単純なデータ型には CRDT を使用し、より複雑なドキュメントには 3 方向のマージを使用するなど、複数の戦略を組み合わせています。)

CRDT は、競合することなく自動的かつ決定的にマージされるように設計されたデータ構造です。彼らは数学的原理を使用して、変更が適用される順序に関係なく、すべてのレプリカが最終的に同じ状態に収束することを保証します。 CRDT は、テキスト エディター、共有 To Do リスト、またはユーザーがオフラインで頻繁に更新を行うシステムなどの共同作業アプリケーションに最適です。

私がこれまでに見た CRDT に関する最高の記事は次のとおりです。 CRDT の対話型入門 そして CRDT への優しい入門。

特定のエクスペリエンスについて CRDT に反対する別の記事は次のとおりです。 共同作業エクスペリエンスには CRDT は必要ありません。

操作変換は、Google ドキュメントなどの共同テキスト エディターでもよく使用されます。 OT には、同時編集が一貫した方法で適用されることを保証するために、共有ドキュメントに対する変換操作 (挿入や削除など) が含まれます。 OT を使用すると、複数のユーザーがデバイス間で同時に編集している場合でも、データの一貫性を維持しながらリアルタイムのコラボレーションが可能になります。

これは、競合が発生した場合に、最新の変更 (タイムスタンプに基づく) が最終バージョンとして受け入れられる、より単純なアプローチです。この戦略は単純で実装が簡単ですが、競合する変更がほぼ同時に行われた場合、データ損失が発生する可能性があります。これは、最新の更新が通常正しい更新であるか、推奨される更新であるシナリオに最適です。

Git などのバージョン管理システムにヒントを得たこの方法には、さまざまなデバイスからの変更に合わせてデータの基本バージョンを維持することが含まれます。競合が検出された場合、システムは競合をマージしようとするか、ユーザーに競合を解決するよう求めます。このアプローチは柔軟性を提供しますが、ユーザーの介入が必要になる場合があるため、データを解決するためにユーザーからの入力があっても問題ない場合に使用するのが最適です。それでも、このマージはすべてを自動マージするために最善を尽くします。 「より単純な」非マージ ソリューションがあります。このソリューションでは、競合がユーザーに表示されるだけで、ユーザー自身が正しい側を選択できます。

現在の状態を保存する代わりに、システムはその状態に至った一連のイベントを保存します。競合が発生した場合、システムはイベントを再生して、最も正確または意味のある解決策を決定できます。イベント ソーシングは監査証跡を提供し、複雑な競合解決戦略を可能にしますが、実装はより複雑になる可能性があります。

—

読むリンク:

WebAssembly は、ネイティブに近い速度でコードをブラウザーで直接実行できるバイナリ命令形式です。

WASM の可能性は非常にエキサイティングです。

WASM を使用すると、開発者はサーバー側の処理の必要性を回避し、ブラウザ自体内で複雑なアプリケーションを実行できます。これは、完全にクライアント側で動作できるようになったコード エディター、開発環境、リアルタイム シミュレーションなどのツールに最適です。

を実行することで、 WASM を使用してブラウザで直接 SQLite データベースを使用する、Web アプリには、データをローカルに保存してクエリするための IndexedDB と LocalStorage の代替手段が用意されました。これにより、オフライン機能とデータ キャッシュの新たな可能性が開かれます。これは、一般的に人気が高まっている SQLite とともに、ローカルファーストの動きと非常によく結びついています。 (これについては後ほど詳しく説明しますが、 Notion は WASM SQLite を使用します）。

WASM はコンパイルされたコードのキャッシュをサポートしているため、その後のアクセス時の読み込み時間が短縮されます。これは、より速く、より良いユーザー エクスペリエンスを意味します。また、コードを繰り返し再ダウンロードすることなく、アプリケーションがネイティブ アプリと同等の高度な機能を提供できるようになります。これについては素晴らしい記事です: WebAssembly 開発者向けのコード キャッシュ · V8

はい、これは AI 以外のエキサイティングなイノベーションのリストだと言いましたが、これは非常に関連性が高く、特に有望です。 WASM により、バックエンド サーバーを必要とせずに、ブラウザーで機械学習モデルを直接実行できるようになりました。これにより、画像認識やテキスト分析などの AI 主導の機能が、クラウドにコストをかけることなく、ユーザーのデバイス上で迅速かつプライベートに機能するようになります。 WASM バックエンドを備えた TensorFlow.js のようなプロジェクトでは、純粋な JavaScript 実装と比較してパフォーマンスが向上した AI モデルを実行できます。 Google Chrome はこれに関して素晴らしい講演を行っています。 Web AI を高速化するための WebAssembly と WebGPU の機能強化、パート 1。

ほとんどの開発者は、どのデータベースを使用するかを考えるとき、MySQL/Postgres (リレーショナル) または Mongo/Dynamo (NoSQL) を思い浮かべます。多くの実稼働グレードのアプリケーションでは、これらのいずれかをデータベースの基盤として使用することをお勧めします。

しかし、常に必要というわけではありません。ケント・ドッズ氏はこう主張する。 おそらくSQLiteを本番環境で使用することもできます。 Ruby Conf での Stephen Margheim 氏も同様です。 あなたが同意するかどうかに関係なく、SQLite を支持する彼らの指摘は貴重です。

• ゼロレイテンシー

• 簡素化されたセットアップ

• 簡単な複数インスタンスのレプリケーション

• (思っている以上に) 大規模なデータベースを処理できる

• 開発とテストがはるかに簡単になります。

しかし実際には、SQLite には単に トレードオフ。 SQlite の創設者の私のお気に入りの言葉は次のとおりです。

「SQLite は次の代替品ではないと考えてください。 オラクル しかし、その代わりとして fopen()。」。

SQLite は最近、誇大宣伝の面でも多くの新たな活動を目にしています。なぜ？おそらく周期のせいだと思います。開発ツールは誇大宣伝と使用のサイクルを経て、SQLite の使用の背後に商業的な力がさらに強くなったことにより、 それを使用することを推進する公共の書き込みがさらに多くなりました。これは、SQLite が以前はあまり使用されなかったデータベースだったということではありません。

ハッカーニュースにはいくつかあります SQLite をプライマリ データベースとして使用している人々に関する興味深いディスカッション。

見えない間に 動きが多すぎる 一般的にプライマリ データベースとして SQLite を使用する場合、 SQLite に価値があると考えています のために ローカルファーストのソフトウェア (特に WebAssembly の進歩と組み合わせたもの)。

Expo (React Native) は常に新しいバージョンをリリースします。 expo-sqlite クールな新機能とアップグレードを備えています。 Expo v52 では、React Native の AsyncStorage に代わる新しいストレージ ドロップインが導入され、利便性のために同期 API が追加されています。ローカルファーストのモバイル アプリでは、SQLite は強固なローカル ストアであり、通常は SQLite よりも優れたオプションです。 非同期ストレージ。

Notion は 2021 年にデスクトップ アプリに SQLite キャッシュを実装し、その結果:

この成功に触発されて、Notion のチームは、WebAssembly (WASM) SQLite を使用して Web アプリにこれらのパフォーマンスの向上をもたらすことにしました。これにより、Notion は、 SQLite クライアント側。 (まとめ、 ブログ投稿）。

また、WASM SQLite の読み込みを最適化したり、低速デバイスでのディスク読み取りが遅い問題を修正したりする必要があるなど、直面したいくつかの興味深い問題についても取り上げています。

クロスプラットフォームは着実に進歩しており、パフォーマンス、開発エクスペリエンス、使いやすさなどにおいて大きな進歩を遂げています。たとえば、React Native は最近、 新しいアーキテクチャ、より洗練されたエクスペリエンスにつながります。

この最もクールな最近の例の 1 つは、 Shopify モバイルアプリ全体を React Native に移行。 (ソース) 現在、コードの 86% が iOS と Android 間で共有されています。それだけでなく、途中でパフォーマンスも向上しました。画面の読み込み時間が 59% 短縮され、アプリの起動が 44% 高速になり、Web ビューが 63% 高速になりました。

もちろん、これによってネイティブ開発の必要性が完全になくなるわけではありません。ムスタファ・アリは素晴らしいものを与えます 学んだ教訓 経験からも：

1. 「ネイティブ コードとネイティブ開発者は非常に重要です。高品質のモバイル アプリを構築した経験と味に代わるものはありません。」

2. 「100% React Native は目標に反するべきです。仕事に最適なツール（ウィジェット、Siri ショートカット、時計アプリやコンプリケーションなど）、または高いパフォーマンス要件がある場所では、ネイティブを使用してください。」

3. 「良いパフォーマンスを達成するには努力が必要であり、最初から優先すべきです。すべてを測定し、あらゆるレイヤーを絶え間なく最適化します。自動モニタリングを追加して回帰を検出します。」

自動推論はもう少しわかりにくいですが、非常に刺激的でもあります。自動推論は、論理と数学的証明を使用して、システムが意図したとおりに動作することを確認することに重点を置いています。特定のシナリオでシステムの動作を検証する従来のテストとは異なり、自動推論により、エンジニアは考えられるすべてのシナリオにわたって正しさを検証できます。基本的に、これは事後的なテストから事前的な検証への移行であり、(理想的には) 信頼性とセキュリティの向上につながります。 Amazon は、自動推論の穏やかな入門書を公開しています。

AWS は最近、自社のインフラストラクチャで自動推論技術をどのように使用しているかについて素晴らしいブログ投稿を書きました。 これらの技術を適用して 10 年以上にわたり、AWS は、正式に検証されたコードが、置き換えられる未検証のコードよりもパフォーマンスが優れていることが多いことを発見しました。これは、正式な検証のプロセスによりバグを早期に発見し、実行時のパフォーマンスを向上させる最適化につながるためです。

たとえば、IAM の正式な仕様を構築することで、1 秒あたり 12 億を超えるリクエストを処理するコードを最適化でき、その結果パフォーマンスが 50% 向上したことがわかりました。 S3 では、自動推論を使用して隠れたバグを発見し、四半期ごとから 1 ～ 2 か月ごとに、より頻繁にアップデートを配信できるようになりました。