Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。ワークフロー)(参考記事・英語)では、新しい言語機能ワークフローを紹介しました。今回の記事では、非同期ワークフローと呼ばれるワークフロー機能の面白い使用法を考察しますが、非同期ワークフローは.NETの非同期プログラミングモデルを単純化することを目的としています。Frameworkをターゲットとした静的型付け関数型プログラミング言語です。人気が高い別の関数型言語OCamlと共通のコア言語を持ち、HaskellやErlang、C#など、他の多数のプログラミング言語からアイデアを採り入れています。簡単に言えばF#は、インタラクティブにコードの実行が可能なことから、いささかスクリプティングのような感じもしますが、コンパイラ型言語のすべての型安全性とパフォーマンスを持つ、素晴らしく簡潔なシンタックスを有するプログラミング言語です。この記事はF#の紹介を意図したものではありませんが、Web上にはF#を簡単に習得することを目的とした情報資源がたくさんあります。Resources」をご覧ください。BCLを扱っていると、すべてのI/Oオペレーションで同期モデルあるいは非同期モデルの2つのうちどちらかのモデルを使います。非同期モデルは共通のプログラミングパターンを通じてサポートされますが、このパターンでは1対のBeginXXXとEndXXXのメソッドが提供され、プログラマーがBeginXXXを呼び出すと、BeginXXXがオペレーションを開始させ、復帰します。プログラマーは、非同期オペレーション終了を知らされたら、直ちにEndXXXメソッドを呼び出す必要があります。私の経験では、ほとんどのプログラマーが同期モデルを使う傾向にありますが、その理由は単純性と、BCLの多数のクラスが同期モデルだけをサポートしているからです。多くの場合、非同期プログラミングモデルを使えば、より応答性の高い、いっそうスケーラブルなアプリケーションを制作できます。非同期モジュールの難しさを例証するために、ファイルを開き、そのファイルからバイトを読み取るという単純な例を見てみましょう。以下は同期モデルでのコード例です。openFile()BCLには「File.ReadAllBytes」など、より単純な方法がありますが、非同期に同等のやり方があるものとしては、上記が最も単純な方法です。ファイルから読み込むオペレーションは非常に単純で、ファイルストリームを開き、データを保持するための配列を作成し、そして最後にその配列にすべてのデータを読み込みます。ファイルストリーム作成時にどのようにして「use」バインディングを使うかに注目してください。C#におけるusingステートメントにほぼ相当し、ファイルストリームが範囲外になったら配置されることを意味します。次に、非同期プログラミングモデルを使った同等物を見てみましょう。openFile()ファイルを開くこの単純な例は、今のところはかなり理解できるものですが、事態は確かに複雑化しています。最初の2段階はおおかた同じであり、ファイルストリームを開き、データ保持のための配列を作成しています。その後は事態が悪化し、「EndRead」メソッドの呼び出しを処理するためにコールバックを定義しなければならず、そしてこのコールバックを状態オブジェクト(ここでは必要ないのでnull)と一緒に「BeginRead」メソッドの中に渡す必要があります。「use」バインディングを使えないことも重要です。「BeginRead」メソッドの存在時には、ファイルストリームが範囲外になり、つまりファイルストリームの配置が早すぎて、「EndRead」メソッドが呼び出される時には使用不可であることを意味するからです。blockの中で呼び出していた安全性を失うことを意味します。ファイルを開くような単純な例では、こうした余分な複雑性も合理的に思われますが、アプリケーションにより多くの機能や、非同期の読み取りを追加していくにつれ、すぐに問題に直面することになります。非同期ワークフローは、特にこの問題に対処するために導入されてきました。非同期ワークフローバージョンを見てみましょう。openFileワークフローバージョンで最も重要なことは、同期バージョンとの相違がわずか数文字という点です。}」というワークフロー宣言が追加されていますが、もっと重要なことは、ファイルから読み込む行を以下のように変えたことです。data.Length)letキーワードに感嘆符(!)も追加し、「Read」ではなく今度は「ReadAsync」を呼び出しています。非同期ワークフローで「let!」が命じているのは、非同期にバインドを作成し、また、BeginReadとEndReadメソッドがどのように呼び出されるかという仕様をReadAsync関数が提供するということです。非同期関数を使わないと、コンパイルタイプエラーになることに注意してください。「ReadAsync」は一体どこからやって来たのでしょうか。「FileStream」クラスで通常利用可能な関数ではありません。Microsoft.FSharp.Control.CommonExtensions」に気付かれるでしょうが、これによりF#型拡張を多数含んだネーム空間が開きます。これはC#の拡張メソッドに非常に類似しており、既存のクラスにさらに関数を追加できるようにし、ネーム空間「Microsoft.FSharp.Control.CommonExtensions」により、非同期ワークフローで使用する多くの拡張機能が提供されます。ファイル配置に今までどおり「use」バインディングを使えることも重要であり、ファイルが別のスレッド上に配置されることを意味するとしても、別に気にすることはなく、useが機能するというだけのことです。他の注目に値する変更はその実行方法です。「fileOpen」識別子は直ちにファイルを開いたりはしませんが、それはこれがワークフローであり、これから発生するアクションを待っているからです。このアクションを実行するために、「Async.Run」関数を使う必要があり、この関数がワークフローを1つ実行し、その結果を待ちます。呼び出された「ReadAsync」の両側に小さなデバッギング関数の呼び出しを追加すると、非同期がどのように機能するかを理解するのに役立ちます。プログラムがどのスレッドを実行中かを把握し、また、スレッドスタックトレースを理解できるようになりますが、これについては読者への課題として残しておきます。StackTrace()).ToString())ワークフローに関する私の元々の記事(http://www.infoq.com/articles/pickering-fsharp-workflow)に戻って、「let!」が継続関数にシンタックスシュガー化された経緯を理解するのも良いでしょう。非同期ワークフローがどのようにして「let!」後の別のスレッドで、とりたてて何もしないのに再度開始できるのかを理解するのに役立つでしょう。パフォーマンスゲインの数量化では、非同期ワークフローを使うと、どのようなパフォーマンスゲインを期待できるのでしょうか。ほとんどすべてのパフォーマンス関連の疑問がそうであるように、実験もしないで回答するのは難しいことです。プログラムは概して計算バウンドか、I/Oバウンドかのどちらかであり、非同期ワークフローを使うことにより、一般に両ケースで改善が見られるでしょう。これには使用するハードウェアが大きな影響をもたらし、タスクがI/Oバウンドであるなら、ディスクの同時アクセスが良くない限り、あまり改善が見られないことを指摘しておくべきであり、非常に良い同時アクセスを提供するディスクも出回ってはいますが、ラップトップやデスクトップよりもむしろ、高仕様のサーバー向けという傾向にあります。タスクがプロセッサバウンドなら、一般にパフォーマンスゲインは良くなるでしょう。ほとんどの最新ラップトップやデスクトップがデュアルコアプロセッサを装備しているからで、間もなく登場するクアドコアモデルを注文しようと考えている読者も多数いるかもしれません。非同期ワークフローを正しく使うことは、割増の処理能力を活用できることを意味するのです。I/Oと計算の両方を行うタスク例を最初から最後まで処理し、どのようなパフォーマンスゲインが得られるのかを見てみましょう。分析したいアスキーのテキストがあるとします。最初のステップで総単語数を数え、次に固有の単語数を数えるとしましょう。ファイルを開いて読むのはI/Oの仕事であり、単語を数えて固有の単語を計算することにより、計算のオーバーヘッドが発生します。Gutenberg(プロジェクト・グーテンベルグ)からヘンリー・フィールディングのすべての作品(リンク)をダウンロードすることに決めました(フィールディングを選んだ主な理由は、シェークスピアやディケンズとは異なり、すべてダウンロードしても腹が立たないほど、フィールディングの作品数が少ないからである)。作品を同期的に分析するスクリプトが必要です。filePathお分かりのように、このスクリプトは非常に単純で、最初にファイルを開いて読み込み、次に正規表現を使ってすべての単語を数え(ここでは、1つ以上の連続した文字を単語として定義)、次にセットを作成することにより、固有の単語を数えます。「Set」型はF#ネイティブのライブラリの一部であり、計算でセットをモデル化する不変のデータ構造であって、ドキュメント内の固有の単語を計算する上では効率のいい仕事をするでしょうが、それでも計算上かなり無骨なやり方でしょう。非同期バージョンを考察してみましょう。}」ワークフローで関数をラップし、「ReadToEnd」の代わりに「ReadToEndAsync」関数を呼び出している以外、ほとんど変わっていません。「主要」関数に対する変更の方がより興味深く、ここでは最初にファイルのリストを非同期ワークフローのリストにマップした後、「tasks」識別子にそれをバインドします。この時点ではワークフローがまだ実行されていないことに留意し、ワークフローを実行するために、「Async.Parallel」を使ってタスクのリストを単一のワークフローに変換しますが、このワークフローが並行実行されることになります。次に「Async.Run」を使い、並行でタスクを実行します。F#をインタラクティブに使い、優秀な計時機能を備えた自分のラップトップ(デュアルコア)でテストを行いました。両スクリプトを1度走らせた後、その結果を破棄し(ディスクキャッシング効果を排除するため)、その後、各スクリプトを3回走らせました。13.114デュアルコアマシンでは、非同期バージョンは同期バージョンより約22%高速で動作していますが、わずか2行変えただけの修正ということを考慮すると悪くない結果だといえます。100%の高速化にならないのでしょうか。答えは非常に簡単です。このタスクは完全な計算バウンドではないということであり、各単語の発生数を数えるとか、類似単語のグループを作ってみるなど、アルゴリズムにさらに計算タスクを加えたなら、高速化のパーセンテージが増加するでしょう。ファイルの読み取りと処理だけが非同期ワークフローが役に立つ唯一のタスクというわけではなく、ネットワークプログラミングにも使えます。実際、ネットワークデータアクセスの方がディスクアクセスより遅い傾向にあるため、ネットワークアクセスが完了する間、スレッドのブロックを回避するために非同期ワークフローを使えば、ファイルアクセスに非同期ワークフローを使うより、多数のメリットをもたらすことができます。Framework上で利用可能な最も洗練された解決策を提供することにより、非同期ワークフローは、.NET非同期プログラミングモデルをいかにして正しく使用するかという、非常に特化した問題に対処します。非同期プログラミングモデルを使えば、アプリケーションがいっそうスケーラブルになり、また、非同期ワークフローにより、さらに容易にできるようになります。Richter氏が、C#を使って非同期プログラミングモデルを実装する場合の非同期プログラミングモデルやその問題、解決策を取り上げています(リンク)。F#』(APress、2007年12月刊)の13章で取り上げており、14章ではさらに例が掲載されています。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員��して、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。