Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。サービススタックを利用せずに、価値の高いビジネスサービスを実現する方法について説明します。移動する機能から生まれたものです。サービスの例と対比するのが最もよい方法です。メソッドを露出するような単純な気象サービスについて考えてみましょう。おいて相当するJAVAツールをポイントし、スタブメソッドを生成するだけで十分です。残念ながら、物事はそれほど単純ではありません。実際に、自由に解釈できるほどに広範です。ツールがその逆の役割(RPC)を果たすことがわかりました。分解するスキーマやツールの包括に関する問題点も判明しました。要するに、テクノロジーは、当社が解決しようとしている実際の問題点から離れ始めたということです。サービス用のツール内に不整合性があることも判明しました。物とには部分的にしか互換性がありません。メソッドが必要になった場合、明日になったら機能しなくなるかもしれないという状況にほとほと嫌気がさしていました。上述のアプローチでは、2つの重要な仮定を行ないました。サービスを通じてそのサービスに到達できるのではないかという仮定です。要求のパラメータや戻りのタイプについて考えるのではなく、要求のタイプとそのパラメータを組み込む文書を要求とみなすことができます。その文書を、モデル化しようとしているビジネスプロセスの契約の一部を表すものであると考えてみましょう。要素に記述すると、以下のようになります。文書としても、戻りのタイプは以下のようになります。これで、文書と同じフィールドを表す単純なクラスの設計を以下のように定義することができるようになりました。どちらにおいても、いずれの文書も比較的簡単にシリアル化、非シリアル化できるということです。シリアル化(コメント付き)がうまく機能する。場合は、それほど都合よくはいきません。シリアル化するためのツールが組み込まれていません。(英語)といううってつけのオープンソースのツールがあります。利用することができます。このような移行によって、システムへの同じエントリーポイントを使って、複数の文書タイプについて考えることができ、さらに拡張性の高いアプローチが可能になります。テクノロジーとサーブレット内のサービスをホストするために選択した任意のサーブレットコンテナです。いずれかを使うことができます。使ってもかまいません。メソッドを実装すべきです。本体全体を使いました。クライアントとサーバー上で同じ結果になるのであれば、これは単なる好みの問題となりますが。非シリアル化してコマンドオブジェクトに変換し、それをしかるべく処理します。サーバーテクノロジーはもっと単純です。シリアル化を利用しました。要素としてマークする必要があります。ポートがあり、これを使うと状況をさらに単純化することができますが、このポートはまだ使ったことはありません。オープンソース界で別のポートが発表されるという噂があります。ライブラリ(およびその付属品)を使っています。処理をプログラム構築してから実行できます。あることを忘れてはなりません。フォームを作成したいのであれば、前者がよいかもしれません。クライアントの場合は、フレームワークのみが必要です。2.0でもかまいません。クラスと組み込みのシリアル化機能を利用できます。することのメリットは、メッセージ実装を変更せずに、あとからコマンドを増やすことができることです。処理できるかどうかを実行時に決定することができます。ブロックを回避するのがよいでしょう。利用する場合、関係するスキーマ上で過度な中継をしたくなってしまでしょう。スキーマの検証と顧客が実際に必要としているであろう情報との違いを理解するように注意する必要があります。実行時にスキーマの検証を実行すると、開発担当者は安心感を覚えますが、これは間違った安心感です。エラーが発生している可能性があります。送信されている可能性があるということです。どのような事態が発生するのでしょうか。スキーマ無効例外メッセージが発生している可能性があります。正しいオブジェクトがあった、または欠落しているフィールドがあった可能性もあります。返信メッセージに簡単に変換することができます。重要な違いは、必要な情報が欠落しているとき以外は、除外は発生しないということです。それ以外は変更可能です。1段階前に移動することが可能になります。慎重なテストを行なうことによって、古いバージョンの要求文書を送信する消費者にサービスが対応することができます。変更および「特別なフィールド」のレベルであることもほとんどありえないことです。組み入れるのがよいかもしれません。サービスの要求を受け入れることを阻止するものは何もありません。指定した以下のような1つのメソッドを記述するだけで十分です。コンテナのいずれかに対応した組み込みアダプター用を利用できます。コードに任せることができます。することで、企業標準ポリスを回避することもできます。表現を送信して、暗黙的に非同期のサービスに対して実行することができました。シリーズは試していないが、機能するはずです。当社の例の場合、気象の詳細の要求は直ちに満たされないということです。その代わり、あとで応答が返ってくる可能性もあります。対して持っている単純な考えの一部を変えたり放棄したりすることになる可能性を秘めた大きな移行です。あとに続く見せかけのメソッドは、以下のように記述しなければならないかもしれません。所定の場所に、それぞれ1つのメソッドを持つ2つのインターフェイスが適切かもしれません。メッセージングのパターンに関しては習得しなければならないことが数多くありますが、ここでは詳細には触れません。考慮すべき全体的な考え方が2つあることを覚えておくとよいかもしれません。1つはキューに関する考え方で、ユーザーからの要求は、そのユーザーに当てられた応答以外は受け取らないということでしょう。1つはマルチキャストという概念で、ケーブル上には多くの加入者に送信されているイベントがあるということです(pub/sub)。暗黙的に、訂正された詳細をある期間にわたって継続的にストリーミングするようなキューを設計できる可能性もあります。若干異なる機能を果たします。サービス考え方の発見段階に固有の仕様チェックが欠落しています。仕様チェックは、必ずしも必要ではないと私たちは暗に考えています。考えに完全に従って、統合テスト用の総合的な常時統合スイートを持っていればよいのです。サービスの非互換性は、運用を開始する前に発見されます。仕様ではなく、プロバイダーと消費者の両方の観点からサービスに関する表明を行なう一連のユニットテストを持っていることになります。リカバリーが非常に困難な場合、実行時に非互換性にフラグを立てるに過ぎません。プラットフォームに依存せずに、このようなテストを作成する1つの方法です。デバッグや文書作成を簡単にするために、以下のようにいくつかのサンプル文書をホストすることをお勧めします。スキーマ(XSD)で、文書フォーマットを制御してもかまいません。対する考え方は異ります)。問い合わせを行なえるということです。サンプル文書はどちらもオプションであり、簡単に作成できることも覚えておく必要があります。要素ノーマルな文書交換を行なったことです。これまで、ほとんどすべてのことがブログの記事として取り上げられ、報告書化されてきました。行なわれということでした。使うほうがよいことがわかります。サーバーが結果をキャッシュできる場合は。キャッシュする試みが無意味なやり取りの場合、おそらくわたしたちのやり方がベストでしょう。使ったアプローチには、私たちのアプローチで失くしてしまったその他のメリットがあります。おかげで人間がブラウザを使ってテストできることは明らかです。実現できる柔軟性を欠いています。ペイロードは、任意に複雑にできます。チームに、(パッチによって)必要に応じて属性に対応できる能力を増大させることができる提案を行ないました。シームレスな相互運用が実現します。同様、このアプローチは非同期移送で機能することも示唆しました。仕様ツールはこの点に関する機能とはほとんど関係ありません。新しい用語も作られていないのです。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員��して、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。