Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。採用することにより,この問題も現在は解決されている。2つの提案の不一致に関しては,当初から次のような意見や議論があった。同じである第2のアノテーションセットを導入するのは,大きな誤りだと思う。扱っているような数百万規模の接続を扱うアプリケーションには不向きである。すべての動作を行うことはできない。我々には切り替えるべき理由がないのだ。個人的には,299は革新的なことを狙いすぎていて,ユーザコードのメンテナンス性の意味が十分理解できていないのではないかと思っている。領域を侵しかねないものだ。294)との間で行われたような,新たな戦いの幕開けでないことを願いたい。アノテーションのような総称的なものではなく,ターゲットとするオブジェクトのスコープを特定できるようなアノテーションを我々は選択する。レビュー投票をパスしたが,投票者の多くはこの2つの仕様間の調和の必要性を強調している。それぞれの成果の調整を図り,SEとEEプラットフォームに対して単一かつ一貫性・包括性のある依存性注入の標準が提供されるよう要求する。調整のための作業は公開レビュー以前に実施されるべきである。当社は本提案をサポートするコミュニティの存在を認識しており,それゆえ専門家グループが公開ドラフトを作成するまで最終的な結論表明は差し控えたい。対して,更なる賛意を示したいと思う。自らの役割を果たすことをここに約束する。調整の重要性を強く主張したい。SEアプリケーションの依存性注入に関する仕様定義の必要性については同意する。プラットフォームに関して定義済あるいは現在定義中のものと一致していない。SE/EEのインジェクション・プログラミング・モデルは,SE向けに機能のコアセットを定義し,EE機能を拡張部分とするような,拡張性のあるプログラミングモデルに統一されるべきである。ともに最終段階への移行を支持することはできない。乖離を引き起こしかねない重大な状況に関しても大きな懸念を持っている。これはプラットフォームの分化という重大な問題に結びつくものだ。間の調整作業が実施されることを希望する。リビジョンあるいはメンテナンスリリースが適切な配布方法であると確信している。このような調整の努力が,すべてのニーズを満足する標準的な依存性注入の機構を提供する上で,SEとEEプラットフォームに渡る一貫性の実現という形で結実することを希望し,期待する。2つの仕様間にあった矛盾はすでに解決されている。エンタープライズエディション6への採用が予定されている。