Foreword

序文

EndjinのReaqtorとの旅は、2016年に、熱いお茶とシンプルな質問から始まりました。

Endjin’s journey with Reaqtor started in 2016, with a hot cup of tea and a simple question:

"どのような行動をとれば、顧客満足度に最大のプラスの影響を与えることができるでしょうか？"

“What single action could you take which would deliver the biggest positive impact on customer satisfaction?”

この質問は、英国の通信会社Talk Talkのインフラ、コンテンツ、オペレーション部門の責任者であるIlario Corna氏とのBrain Trustセッションで飛び出した。この会社は、英国で「最も推奨されるプロバイダー」になるという目標を掲げたばかりでした。この戦略的な取り組みの一環として、私たちはAzureベースのソリューションを設計・導入し、1日あたり2億件以上のネットワーク遠隔測定イベントを取り込み、異常な動作を分析することができました。この成功に気を良くした私たちは、「次はどんな難しい問題に取り組もうか」と考えていました。

The question popped up in a Brain Trust session with Ilario Corna, Head of Infrastructure, Content & Operations at Talk Talk (a UK Telco). The organisation had just rolled out an objective to become the UK’s “most recommended provider”. As part of this strategic initiative, we had designed and implemented an Azure based solution capable of ingesting and analysing over 200 million network telemetry events per day for anomalous behaviour. Feeling buoyed by success we were wondering “which hard problem could we tackle next?”

イラリオはすぐに答えを出した。「フィールドエンジニアを各顧客の家に派遣して、ブロードバンド接続やハードウェアの診断を行い、ファームウェアをアップグレードして、その他必要な調整を行うのです。しかし、100万人以上のお客様がいる中で、それを実行するのは商業的に不可能です」。

Ilario had the answer immediately. “Oh, that’s easy” he said, “I would send a field engineer out to each customer’s house, run diagnostics on their broadband connection and hardware, upgrade their firmware and implement any other tweaks required. But with over 1 million customers that’s not commercially feasible to implement.”

お茶を一口飲んでしばらく考えた後、私はこう答えました。「つまり、解決策はあるのですが、それを数桁も安く実装して拡張する方法を見つける必要があるのです。もし私があなたの立場で魔法の杖を使えるとしたら、『Cortana（コルタナ）、顧客の各接続のサービス品質を監視して、もしSLAを下回っていたら、トラブルシューティングを実行して原因を診断し、いくつかの自動修復戦略を適用してくれ』と言えるようにしたいですね。それはネットワークを管理する素晴らしい方法だと思いませんか？"

After taking a sip of tea and pondering for a few moments I responded “So we have a solution, but we need to find a way to implement and scale it several orders of magnitude more cheaply. If I were in your shoes and could wave a magic wand, I’d want to be able to say something like ‘Cortana, monitor the Quality of Service for each of my customer’s connections, and if it’s below our SLA, then run a trouble-shooter to diagnose why and then apply a number of automatic remediation strategies’. Wouldn’t that be a great way to manage the network?”

彼は笑いながら、「Sure would! と答えた。その時は、まるで遠いSFファンタジーのようで、二人で笑ってしまいました。

He responded with a chuckle, “Sure would! When can I have it?!?” We both laughed then, because it sounded like a far-off sci-fi fantasy.

帰りの電車の中で、その話が何度も頭をよぎりました。お客さまの端末だけでなく、お客さまの家につながるネットワークのあらゆる部分を監視することができるデジタルエージェントを作ることはできないのか？膨大な量のデータを人間が理解できるように整理するという従来のビッグデータの問題とは異なり、この種の問題は信号分析に近いものです。

On the train home, that part of the conversation kept coming back to me. Why couldn’t we create some type of digital agent that could monitor not only the customer’s device, but every part of the network infrastructure that led to the customers home? The nuance was that unlike traditional “big data” problems, whereby you need to reduce vast amounts of data into a format a human can comprehend, this type of problem is more akin to signals analysis: you need to process the full fidelity raw data in a stateful way.

100万人の顧客がいる場合、2億のメッセージを100万のクエリに分解する必要があります。各クエリはメッセージを見て「これは私に当てはまるか」と尋ねる必要があり、当てはまる場合はイベントを処理してサービス品質指標を更新し、それがしきい値を満たしているかどうかを評価し、満たしている場合は新しい「しきい値を超えた」イベントをトリガーします。このように問題を明確にすることは、アクターモデルやRxクエリに似ていると思います。

If you have 1 million customers, you need demultiplex those 200 million messages into 1 million queries, each query will need to look at the message and ask “does this apply to me?” if so it would process the event and update its quality of service metric, evaluate if that had met a threshold and if so, trigger a new “threshold exceeded” event. Articulating the problem this way sounded a bit like the Actor Model, or perhaps an Rx query.

数年前、私たちは英国の大手オンライン小売業者のDevOpsプロジェクトに携わりました。私たちはRxを使用して、データセンター内のすべてのサーバーからのセマンティック・ロギング・イベントを集約し、分解しました。私たちが実装したRxクエリは、シンプルかつエレガントで、驚くほどパワフルなものでした。これはRxのデザインの証であり、私たちがendjinでRxの大ファンである理由でもあります。

A few years previously we had worked on an DevOps project for a major UK online retailer. We used Rx to aggregate and disaggregate semantic logging events from all the servers in the data centre. The Rx query we implemented was simple, elegant, and incredibly powerful; a testament to the design of Rx, and a reason we’re huge fans of it at endjin.

100万個のRxクエリを同時に実行することは可能なのだろうかと思い、Bart De Smet氏が前年のNDC 2015でCloud Event Processingに関するセッションを行ったことを思い出し、録画を見つけて見てみました。その講演の中で、彼はBingの組織でCortanaの体験を実現するためのRxの進化に取り組んでいて、それにはステートフルで耐久性のある高密度のRxクエリが必要だと述べていました。これは非常に有望だと思います。

I wondered if it would be possible to run 1 million Rx queries concurrently, and remembered Bart De Smet has presented a session at NDC 2015 about Cloud Event Processing the previous year, so I found & watched the recording. In that talk he mentioned that he was working in the Bing organisation on an evolution of Rx which powered Cortana experiences, and this involved stateful, durable, high density Rx queries. This sounded very promising indeed!

この技術がオープンソース化されていないか調べていたところ、マイクロソフトの「Bing Cortana」に関するケーススタディ（残念ながら現在は公開されていません）で、毎秒5億件のクエリを評価するために使用されたReactorという技術について言及しているのを見つけました。もしこれが同じ技術であれば、私たちのブロードバンドQoS監視のシナリオを解決するためには、その500分の1の容量しか必要ありません。

While researching to see if this technology had been open sourced, I came across a Microsoft case study about “Bing Cortana” (unfortunately no longer public) that mentioned a technology called Reactor, which was used to evaluate 500 million queries per second. If this was the same technology, we only needed 1/500th of that capacity in order to solve our broadband Quality-of-Service monitoring scenario.

私は、マイクロソフトのパートナーマネージャーであるDavid Goonに連絡を取り、状況を説明して「この技術にアクセスすることは可能だと思いますか」と尋ねた。彼は、「これは非常に魅力的なユースケースであり、他の分野でも利用される可能性がある」と答えました。バート・デ・スメット氏に連絡を取り、彼が何と言うか聞いてみましょう。やってみるしかありません。" 2週間後、バートと1時間ほど電話をして、私たちが描いたシナリオを説明し、Reactorが実行可能なソリューションになるかどうかを尋ねました。彼は、それが適しているようだと言い、私たちはコンセプトの証明に向けて共同作業を始めることに合意しました。

I reached out to David Goon, who was our Partner Manager at Microsoft, explained the situation and asked “do you think it would within the realms of possibility for us to get access to this technology?” He responded “It’s a really compelling use case, and I can see there being lots more across other sectors. Let me reach out to Bart De Smet and see what he says. We can only try.” Within a couple of weeks, we had an hour long call with Bart where we took him through the scenario we had elaborated, and asked if he thought Reactor would be a viable solution. He said that it seemed to be a good fit, and we agreed to start collaborating on a proof of concept.

バートと一緒に仕事ができたことがどれほどの名誉であり、特権であるかを伝えるのは難しい。言うまでもなく、彼なしでは以下の内容はまったく実現しませんでした。ReaqtorはBartの子供であり、私たちはそれを世に送り出す特権を得ただけです。

It’s hard to convey what an absolute honour and privilege it has been to work with Bart, and I will be forever grateful for the amount of his incredibly valuable time he dedicated to this endeavour. It goes without saying that without him, absolutely none of what follows would have been possible. Reaqtor is Bart’s baby; we’ve just had the privilege of delivering it into the world.

Bart氏がReactorのサンプルコードへのアクセスを提供してくれたので、Mike Larah氏と私は、Bart氏が共有してくれたNDCトークのコードサンプルに基づいて、コンソールアプリでホストされている完全にインメモリバージョンのReactorという「シンプルなシナリオ」でペアを組みました。私たちは、RADIUSネットワーク遠隔測定のストリームを処理し、ブロードバンドネットワークに問題があることを示す特定のイベントを検出することで、ブロードバンド異常検出問題を解決できるかどうかを確認したいと思いました。このプロトタイプでは、ネットワークをグラフとしてモデル化し、問題が顧客の自宅に限局して発生しているのか、あるいはローカルノードレベル（道路の停電）やリージョナルノードレベル（町の停電）で発生しているのかを判断することができました。これがうまくいったので、私たちは興奮しました。

Once Bart provided us with access to some sample Reactor code, Mike Larah and I paired on a “simple scenario”; an entirely in-memory version of Reactor hosted in a Console App, based on the NDC talk code sample Bart shared with us. We wanted to see if we could solve the broadband anomaly detection problem by processing a stream of RADIUS network telemetry and detecting the specific events that indicate there were problems in the broadband network. In this prototype we modelled the network as a graph, which allowed us to determine if an issue was localised to the customer’s home or was occurring at a local (an outage for a street) or regional node level (an outage for a town). It worked, and we were fizzing with excitement.

理解すべき重要なポイントの1つは、Reactorは166以上のプロジェクトと90のNuGetパッケージを持つReactive Extensionsよりも桁違いに大きな存在であり、なおかつプラットフォームではなくフレームワークであるということです。フレームワークの設計において、状態、耐久性、信頼性は定義されていますが、これがホスティング環境に結びついているため、実装が欠けています。

One of the key points you need to understand is that Reactor is orders of magnitude bigger than Reactive Extensions with over 166 projects, and 90 NuGet packages, and yet it is still a framework, not a platform. While state, durability and reliability are defined in the design of the framework, the implementation is missing, as this is tied to the hosting environment.

ReactorはBingで生まれ、M365や他の製品チームで採用されました。バートは、Reactorをホスティング環境からきれいに分離するという素晴らしい仕事をしてくれましたが、それは、信頼性の高い独自のホスティングプラットフォーム、ステートストア、入出力アダプタ、管理・制御プレーン、そしてReactorと対話するためのワークベンチを構築するという茨の道に取り組まなければならないことを意味します。私たちには登るべき山がありました。

Reactor was born into Bing and adopted by M365 and other product teams. Bart had done a fantastic job of ensuring a clean separation of Reactor from the hosting environment, but it meant that we had to tackle the thorny problem of building our own reliable hosting platform, state store, ingress & egress adapters, management & control plane, and workbench for talking to Reactor. We had a mountain to climb.

難しい問題を解決するとき、私たちが最初に声をかけるのはイアン・グリフィスです。彼は創業以来、endjinのアソシエイトとして活躍しています。彼がオライリー社の『Programming C#』シリーズにRxに関する章を設けていたので、彼がRxにとても情熱を持っていることは知っていましたし、何度も話をしていました。数ヶ月の間に、私たちは信頼性の高いホスティングプラットフォームの初期スパイクを実装し、それを実行している間はとても楽しかったです。その後間もなく、イアンは初のテクニカルフェローとしてendjinにフルタイムで参加し、この試みを続けていくことになりました。

When it comes to solving hard problems, Ian Griffiths has always been our first port of call; he’s been an endjin associate since we founded the company. I knew he was very passionate about Rx as he’d included a chapter about the subject in his Programming C# series of books for O’Reilly, and we’d had many conversations about it. Over a few months we implemented an initial spike of a reliable hosting platform, and had an absolute blast while doing it. Shortly afterwards Ian joined endjin full time as our first Technical Fellow, so that he could continue to work on the endeavour.

その後の数年間で、Reactorテクノロジーの様々な側面を探求するために、いくつかの技術的なスパイクを構築しました。ReactorのクエリにML.NETモデルを組み込み、停電を示すブロードバンドのサービス品質イベントを正しく特定できる異常検知の一時的なクエリ（仮想時間を使用）の概念実証を行い、1日分（約40GB）の遠隔測定を90秒以下で処理しました。過去のデータセットを使って "what-if "シミュレーションを行うことができ、それがスイッチを入れるとリアルタイムのデータに対して実行されるライブクエリに変わるという機能は、私たちを圧倒しました。この概念実証のために匿名化されたデータセットを提供してくれたBen DyerとAlex KeySmithに感謝の意を表したいと思います。

Over the next few years, we built several technical spikes exploring different facets of the Reactor technology; we embedded ML.NET models into Reaqtor queries, we created a proof-of-concept anomaly detection temporal query (using virtual time) that could correctly identify broadband quality of service events that indicate outages; processing a days’ worth of telemetry (around 40GB) in under 90 seconds. The ability to do “what-if” simulations over historic datasets, which we could then flip a switch and turn into live queries running against realtime data blew us away. I want to express my thanks to Ben Dyer and Alex KeySmith for providing us with the anonymised dataset for this proof of concept - they were early believers.

2018年5月、endjinの共同創業者であるMatthew Adamsと私は、Microsoft Buildカンファレンスのためにシアトルに飛び、旅行の最終日をBartと過ごすことができました。午前中、BartはReactorの誕生秘話を話してくれました（この内容は、ホームページで無料ダウンロードできる電子書籍「A Little History of Reaqtor」で詳しく説明されています）。素晴らしい昼食をとりながら、データ処理の将来について話をし、BartはIComputationProcessingのビジョンについて話しました（これについては電子書籍で詳しく説明しています！）。そして午後には、Reactorをオープンソース化できるかどうか、そのプロセスには何が必要かについて話しました。

In May 2018 Matthew Adams, my co-founder at endjin, & I flew over to Seattle for the Microsoft Build conference and we managed to spend our last day of the trip with Bart. In the morning Bart told us the story of how Reactor came to be (this is covered in detail in the “A Little History of Reaqtor” ebook you can download for free on the homepage). Over a fantastic lunch we waxed lyrical about the future of data processing, and Bart talked about his vision for IComputationProcessing (more about this in the ebook!) and then in the afternoon we talked about whether we could open source Reactor and what that process would entail.

前年にインターンシップを経験したCarmel Eveは、endjinのアプレンティスシップ・プログラムに再び参加しました。イアンとカーメルは、私たちが特定したさまざまな顧客シナリオをカバーする他の概念実証とともに、Reactorの研究を開始しました。この間、CarmelはRxとハイパフォーマンスC#の書き方について学んだことを、人気のブログ記事シリーズにまとめました。Reactorを調べれば調べるほど、私たちは感銘を受けました。

Carmel Eve, who had interned with us the previous year, re-joined endjin on our Apprenticeship Programme. Ian and Carmel started exploring Reactor with other proof of concepts covering different customer scenarios we had identified. Throughout this time Carmel documented her learnings about Rx and writing high performance C# in popular blog post series. The more we investigated Reactor, the more impressed we became.

2019年3月、私はレドモンドで開催されたMVP Summitに参加し、当時.NET FoundationのExecutive Directorを務めていたJon Galloway氏とバッタリ会いました。私は彼にReactorのエレベーターピッチをできる限り簡潔に伝え、endjinは.NETエコシステムへのコミットメントを示したいので、是非とも.NET Foundationのコーポレートスポンサーになりたいと言い、一方で、MITライセンスの下で.NET FoundationにReactorをオープンソース化するために必要な法的プロセスを遂行するために、Microsoftからの投資を正当化するためのホワイトペーパーとビジネスケースをBartと共同で作成しました。

In March 2019 I attended the MVP Summit in Redmond, and I bumped into Jon Galloway, who at the time was the Executive Director of the .NET Foundation. I gave him as brief a Reactor elevator pitch as I could, and said that endjin would love to become .NET Foundation Corporate Sponsors, as we wanted to demonstrate our commitment to the .NET ecosystem, while we also collaborated with Bart to create whitepapers and a business case in order to justify the investment from Microsoft to carry out the legal processes required to open source Reactor to the .NET Foundation under The MIT License.

年末までに私たちは書類に記入し、スポンサー料を支払い、.NET FoundationのホームページのAWS、DevExpress、Microsoft、Octopus Deploy、Telerik、Uno Platform、VMWareの横に掲載されました。

By the end of the year we’d filled out the paperwork, paid our sponsorship fee, and were featured on the .NET Foundation homepage alongside: AWS, DevExpress, Microsoft, Octopus Deploy, Telerik, Uno Platform and VMWare.

この時点で、私たちはこの3年間避けてきた問題に直面しなければなりませんでした。それは、この製品を何と呼ぶかということです。"Reactor "という名前はあまりにも使い古されています。Microsoft Reactorは、世界中のMicrosoft Communityのミーティング会場の名前です。Project Reactorは、VMWare社のJVMプロジェクトの名前で、Rxに触発され、Reactive Streamsをベースにしています。Reactは、Facebookが提供する大人気のリアクティブユーザーインターフェースライブラリです。Reactorを支えるキーコンセプトの一つがIQbservableです。私たちは、この奇妙な名前のインターフェースをずっと愛してきました（BartがI-Cub-servableと発音していることも理由のひとつです）。Carmelは、名前に "Q "を含めることを提案し、Reaqtorが書き出されるとすぐに、満場一致で同意されました。

At this point, we had to face the problem that we had been avoiding for the past 3 years; what do we call it? “Reactor” as a name is too overused. Microsoft Reactor is the name of the Microsoft Community meet up venues around the world. Project Reactor is the name of a JVM project from VMWare, inspired by Rx, and based on Reactive Streams. React is the hugely popular reactive user interface library from Facebook. One of the key concepts that powers Reactor is IQbservable. We’ve always loved this weirdly named interface (partly due to how Bart pronounces it - I-Cub-servable). Carmel came up with the suggestion that we include the “Q” in the name and as soon as Reaqtor was written down, it received unanimous agreement.

これにより、私たちが直面していた他の2つの命名問題もすっきりと解決しました。Reaqtorは3つの概念的な層で構成されています。一番下の層は、コンパイラー、JSON、LINQ、高性能/低メモリの拡張機能とユーティリティを提供する再利用可能なコンポーネントのセット（Reaqtorとは独立して使用可能）で、これをNuqleonと名付けました。中間層には、Rxのコンセプトの多くを進化させて、信頼性の高いステートフルな分散型リアクティブ処理を可能にするリアクティブプリミティブが含まれており、これをReaqtiveと名付けました。そして最後のトップレベルは、信頼性の高いステートフルな分散型リアクティブソリューションを構築するためのプラットフォームレベルのサービスで構成されており、これをReaqtorと呼んでいます。

This also neatly solved two other naming problems we faced. Reaqtor consists of three conceptual layers; at the bottom a set of reusable components (that can be used independently of Reaqtor) which provide compiler, JSON and LINQ, and high performance / low memory extensions and utilities, which we named Nuqleon. The middle layer contains reactive primitives that evolve many of the concepts found in Rx to enable reliable, stateful and distributed reactive processing, which we named Reaqtive. And finally the top level consists of platform level services for building reliable, stateful, distributed reactive solutions, called Reaqtor.

私たちは、.NET Foundationと協力してプロジェクトを進めていきました。クレア・ノボトニーには特に感謝しています。彼は、.NET Foundationのインフラ上でのDevOpsプロセスの設定や、プロジェクトを公開するために必要なその他の管理作業を手伝ってくれました。

We started to collaborate with the .NET Foundation to onboard the project. Special thanks to Claire Novotny who helped us set up the DevOps processes on the .NET Foundation infrastructure and all the other bits of administrivia required to prepare the project to be released to the public.

また、ロドニー・リトルズ氏や.NET Technical Steering Groupと協力して、式木サブシステムを近代化するためのRFCを作成しましたが、これは式木サブシステムが長年にわたって投資されておらず、最新の言語機能との整合性が取れていないためです。これらの改善は、Reaqtorの将来にとって基本的なものです。幸いなことに、Entity Frameworkチームもこの近代化を望んでいるため、この分野ではいくつかの進展があるようです。

We also worked with Rodney Littles and the .NET Technical Steering Group to elaborate an RFC to modernise the Expression Tree subsystem, as it has not been invested in for many years and does not have parity with the latest language features. These improvements are fundamental to the future of Reaqtor. Fortunately there seems to be some progress in this area as the Entity Framework team would also like this modernisation to occur.

式ツリーの問題の一つは、それが.NETの最も複雑で最も文書化されていない部分の一つであり、また、LINQ（およびLINQプロバイダ）を強化するためだけに存在すると考えられていることです。Reaqtor（特にNuqleon層、つまりExpression TreeとBonsaiサブシステムが存在する場所）で見られるように、Expression Treeは本当に.NETの超能力の一つであり、心を揺さぶるメタプログラミングのシナリオを可能にします。

Part of the problem with Expression Trees is that they are one of the most complex and least well documented parts of .NET; they are also perceived only to exist to power LINQ (and LINQ Providers). As you’ll see with Reaqtor (an in particular the Nuqleon layer, which is where the Expression Tree & Bonsai subsystem lives), Expression Trees really are one of .NET super powers and enable mind-bending meta-programming scenarios.

最終的なパズルの1つは、コミュニティのための優れたドキュメンテーション体験をいかにして作るかということでした。イアンは、DevelopMentor、Pluralsight、O'Reillyの著書など、プログラミング教育の分野で長い経験を持っています。良い学習環境とはどのようなものか、何度も話し合ってきました。テキスト、画像、ビデオ、コードサンプルを含む一貫した物語を語ることができ、文脈の中で実行することができる（タスクの切り替えをなくすことができる）ことです。Microsoft Docsはこの点で優れた仕事をしていますが、小規模なオープンソースプロジェクトでは、どのようにして同様の体験を提供することができるでしょうか？

One of the final puzzle pieces was how we could create a great documentation experience for the community. Ian has a long history in teaching programming; DevelopMentor, Pluralsight and his O’Reilly books. We’ve had many conversations about what a good learning environment looks like: the ability to tell a cohesive narrative including text, images, videos and code samples that you can execute in context (to eliminate task switching). Microsoft Docs have done an excellent job in this respect, but how can you offer a similar experience when you are a small open source project?

最初はTry .NETを調査し、Jon Sequeira、Diego Colombo博士、Maria Naggaga、Brett Forsgrenと話をすることになりました。話はすぐに彼らの現在のプロジェクトである.NET Interactiveに移ったのですが、これはインタラクティブなドキュメントを作成するだけでなく、Reaqtorのクエリを作成、テスト、実行するためのIDEとしても、当社のニーズにぴったりだと思いました。

We initially investigated Try .NET which lead us to talking to Jon Sequeira, Dr Diego Colombo, Maria Naggaga and Brett Forsgren. Initial conversations quickly turned to their current project .NET Interactive, which seemed perfect for our needs, not only for interactive documentation but also as an IDE for writing, testing and running Reaqtor queries.

私たちはすぐに、.NET Interactiveはリクエスト／レスポンス（REPL）モデルを中心に設計されているが、プロセス中およびプロセス外のリアクティブなクエリを長時間実行することをサポートする必要があることに気づきました。私たちはチームと協力して、カスタムコマンドを定義してカーネル間で送信できるようにする、クライアントサイドコマンドパターンの設計を行いました。イアンはこの機能を実装し、PRは.NET Interactiveのコードベースにマージされました。これにより、Reaqtor、Reaqtive、およびNuqleonを理解するための優れたドキュメントや興味深いデモを作成することができました。

We soon realised that .NET Interactive was designed around a request/response (REPL) model, but we’d really need to support long running in-process and out of process reactive queries. We collaborated with the team on a design for a client-side command pattern that would allow us to define custom commands and send them between the kernels. Ian implemented the feature and the PR was merged into the .NET Interactive codebase, allowing us to create great documentation and interesting demos, that you can use to understand Reaqtor, Reaqtive & Nuqleon.

このプロジェクトの最後の重要な貢献者はFelix Corke氏です。彼はブランディングとクリエイティブアセットをデザインしましたが、これらはCreative Commons Attribution Share Alike 4.0 Internationalライセンスの下で提供されており、コミュニティがReaqtorに関するブログ記事、ビデオ、プレゼンテーションに使用できるようになっています。また、コミュニティプレゼンテーションのリポジトリを作成しました。ここには、既存のインタラクティブノートブックを使用した、ブランド化された、事前に準備されたプレゼンテーションやデモが含まれており、地域の.NETユーザーグループで簡単にプレゼンテーションやライトニングトークを行うことができます。

The final significant contributor to the project is Felix Corke who designed the branding and creative assets which we have made available under a Creative Commons Attribution Share Alike 4.0 International license, so that the community can use them in blog posts, videos and presentations about Reaqtor. We have also created a Community Presentations repository containing branded, pre-canned presentations and demos using the existing interactive notebooks, so that you can easily do a presentation or lightning talk at your local .NET User Group.

私たちのReaqtorとの旅は、Reaqtorの全体的な歴史の中で短い期間しかカバーしていません。この本の中で、Bart De Smetは2005年から始まるすべての物語を語っています。これは非常に魅力的な記述であり、読み終わる頃には、なぜReaqtorが.NETエコシステムの中で最もエキサイティングな技術であり、ゲームチェンジャーであると私たちが信じているのかを理解していただけると思います。

Our journey with Reaqtor only covers a short period in its overall history. In this book Bart De Smet tells the full story… starting in 2005. It is an absolutely fascinating account, and I hope by the time you finish reading it, you’ll understand why we believe Reaqtor is the most exciting technology in the .NET ecosystem, and that it’s a game changer.

Howard van Rooijen, co-founder, endjin. May 2021.”