feed.rss

<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
	<channel>
		<title>@tthiery's Journal</title>
		<link>http://tthiery.github.io/</link>
		<description>Welcome Builders!</description>
		<copyright>2023</copyright>
		<pubDate>Sun, 10 Dec 2023 14:49:16 GMT</pubDate>
		<lastBuildDate>Sun, 10 Dec 2023 14:49:16 GMT</lastBuildDate>
		<item>
			<title>Native interop: Where .NET beats the competition in app development</title>
			<link>http://tthiery.github.io/posts/2023/11/20/why-dotnet-for-apps</link>
			<description>&lt;p&gt;In the recent days Visual Studio for Mac was killed of and again the fears that .NET's MAUI is silverlighted by Microsoft comes up.&lt;/p&gt;</description>
			<guid>http://tthiery.github.io/posts/2023/11/20/why-dotnet-for-apps</guid>
			<pubDate>Mon, 20 Nov 2023 00:00:00 GMT</pubDate>
			<content:encoded>&lt;p&gt;In the recent days Visual Studio for Mac was killed of and again the fears that .NET's MAUI is silverlighted by Microsoft comes up.&lt;/p&gt;
&lt;blockquote class="blockquote"&gt;
&lt;p&gt;to silverlight - verb&lt;/p&gt;
&lt;p&gt;the process of hyping a product, onboarding developer masses and then abondon it&lt;/p&gt;
&lt;p&gt;-- Windows Developer Community&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;But &lt;strong&gt;why we need MAUI in the first place&lt;/strong&gt;. Is not Flutter the hot thing. Is not React Native awesome. And even the old work horse Cordova has awesome perks when it comes to sharing the UI styling and the app itself with the Web. Why MAUI?&lt;/p&gt;
&lt;p&gt;Popular opinion about MAUI is that you can stay in your language when you develop your full stack app. You write your service, your logic, your app in C# and also your web page .... wait ... no you do not. Blazor is awesome but no. There is JavaScript. So you are anyway polyglot. Why then not go React Native?&lt;/p&gt;
&lt;p&gt;Some years ago I evaluated the market for app frameworks. React Native was hot, Flutter was not there yet, Cordova just let PhoneGap behind it. Some smaller hot ones were around. We did fancy weighted comparison charts but there was a single line item which was crucial for us and MAUI - then Xamarin - beat everyone else by a length. And this still holds true to today: &lt;strong&gt;Native Interop&lt;/strong&gt;.&lt;/p&gt;
&lt;p&gt;Application development frameworks are typically bringing your favourite programming language (C#, JavaScript, Java, ...), UI toolkit (HTML, Widgets, ...) or paradigm (React, ...) onto a set of platforms (iOS, Android, MacOS, Windows, Linux). The frameworks typically expose a set of functionality and &lt;strong&gt;rely on plugins&lt;/strong&gt; to expose more and more of the platforms into a targeted programming language. And that is the crux.&lt;/p&gt;
&lt;p&gt;The .NET app framework (via the orignal startup/product Xamarin, founded by legendary Miguel de Icaza) and later extensions, consists roughly of these products:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;.NET for Android&lt;/li&gt;
&lt;li&gt;.NET for iOS&lt;/li&gt;
&lt;li&gt;.NET for macOS&lt;/li&gt;
&lt;li&gt;.NET for Windows (via C#/WinRT)&lt;/li&gt;
&lt;li&gt;MAUI (previously Xamarin Forms)&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;MAUI is a shared UI toolkit similar to React Native (not Flutter because Flutter renders its own Material Design controls). The others however, were exposing the native APIs of Android, iOS and MacOS into .NET (and a .NET runtime / compilation mode for these targets 😀). &lt;strong&gt;The native APIs. The full native APIs.&lt;/strong&gt; This unfolds into very critical aspects when it comes to accessing platform functionality (programmed in language X) from the application development framework (programmed in language Y, here in .NET):&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;you do not need to master a programming language for each platform&lt;/strong&gt; (Objective-C/Swift for iOS/Mac, Kotlin/Java for Android and C++/.NET for Windows) when writing plugins. This matters when you assemble your team and do not need to hire specialists and can keep your team setup simple even if you go into the depths. Basically the full stack within the app itself.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;&lt;p&gt;you can &lt;strong&gt;avoid abstractions introduced by plugins&lt;/strong&gt; and can access the original platform SDK or third party SDK in its original behavior and to its full extend. Do not brush this of easily. When you need to capture the first three Bluetooth LE frames within 10ms after a connection establishment of Bluetooth LE and your abstraction is not allowing you to register a handler before that (looking at you WebBluetooth) then you cannot integrate the product with the abstraction / plugin.&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Now you may argue: But I do not need that! Or: I have plugins for everything in my framework! Well, indeed, most apps will never need this. But if you need it, like we do, &lt;strong&gt;this single argument sorts out all the competition&lt;/strong&gt;. React Native, Flutter and Cordova all have their plugins written in other languages by other awesome people. Most of them will abstract the original SDKs, maybe to unify, maybe to simplify. In .NET on Android, iOS and MacOS native development for plugins is not necessary and abstraction is an optional choice (e.g. using Xamarin.Essentials).&lt;/p&gt;
&lt;p&gt;Looping back to .NET MAUI. MAUI is a UI toolkit on top of that (based on native controls). Blazor Hybrid is another UI toolkit (based on web view controls, HTML/CSS) using MAUI. There is still theoretical hope that MAUI one day will render its own control to go to places where Flutter and QT go. I hope Microsoft understands its chance here. Especially when you combine it with a Visual Designer. Partially they &lt;a href="https://devblogs.microsoft.com/dotnet/why-dotnet/#net-design-point"&gt;do&lt;/a&gt;, but then, they completely forget to advertise this in context of MAUI.&lt;/p&gt;
&lt;p&gt;Summary: .NET MAUI has a unique but largely overseen selling point, Native Interop.&lt;/p&gt;
</content:encoded>
		</item>
		<item>
			<title>How the Omnisharp roadmap affects .NET in Cooperations</title>
			<link>http://tthiery.github.io/posts/2022/06/18/dotnet-omnisharp-roadmap</link>
			<description>&lt;p&gt;The &lt;a href="https://github.com/OmniSharp/omnisharp-vscode/issues/5276"&gt;announcement&lt;/a&gt; to make the LSP server host of OmniSharp closed source hits me hard. I cannot understand why the DevDiv leadership of Microsoft is so willingly and ongoingly destroying the reputation of .NET (Core). .NET Core is one of the three core pillars (VS Code, TypeScript and .NET Core) which generated respect for Microsoft in the wider programming community within the last 10 years.&lt;/p&gt;</description>
			<guid>http://tthiery.github.io/posts/2022/06/18/dotnet-omnisharp-roadmap</guid>
			<pubDate>Sat, 18 Jun 2022 00:00:00 GMT</pubDate>
			<content:encoded>&lt;p&gt;The &lt;a href="https://github.com/OmniSharp/omnisharp-vscode/issues/5276"&gt;announcement&lt;/a&gt; to make the LSP server host of OmniSharp closed source hits me hard. I cannot understand why the DevDiv leadership of Microsoft is so willingly and ongoingly destroying the reputation of .NET (Core). .NET Core is one of the three core pillars (VS Code, TypeScript and .NET Core) which generated respect for Microsoft in the wider programming community within the last 10 years.&lt;/p&gt;
&lt;p&gt;I am a .NET fanboy but I have a perspective on the broader spectrum of programming languages. I am an architect, decision maker/influencer and regularly involved in questions on whether Visual Studio Subscriptions are needed. I am not in a Microsoft shop, I am not in the silicon valley and I am in a conservative polyglot business.&lt;/p&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;Note&lt;/strong&gt;: See Update in Appendix U&lt;/em&gt;&lt;/p&gt;
&lt;h2 id="what-defines-a-state-of-the-art-programming-language"&gt;What defines a state of the art programming language&lt;/h2&gt;
&lt;p&gt;In the past, programming languages consisted of a runtime, compiler and debugger. Microsoft's own Anders Hejlsberg (of Pascal, C#, TypeScript) explained in an awesome video named &amp;quot;&lt;a href="https://docs.microsoft.com/en-us/shows/seth-juarez/anders-hejlsberg-on-modern-compiler-construction"&gt;Modern Compiler Construction&lt;/a&gt;&amp;quot; how previously considered IDE features like code completion, syntax highlighting, code analysis or code refactoring are now part of the compiler. C# (Roslyn) and especially TypeScript have been (modern day) forerunners of this. This combined with the general industry adoption of the &lt;a href="https://github.com/microsoft/language-server-protocol"&gt;language server protocol&lt;/a&gt; developed by the VS Code (Monaco?) team basically defines what a modern programming language is:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;A modern, modular, non-black-box compiler&lt;/li&gt;
&lt;li&gt;A debugger&lt;/li&gt;
&lt;li&gt;A rich out-of-the-box library and runtime&lt;/li&gt;
&lt;li&gt;A LSP server written in the same programming language&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;.NET is awesome in all of them: The compiler is awesome, the debugger is awesome, the base class library is awesome and the LSP server ... well ... is there. But make no mistake: The other languages have this whole portfolio as well or are on the way there (Java, JavaScript/TS, Python, Go, Rust, PHP, ...).&lt;/p&gt;
&lt;p&gt;The core attribute of most application programming languages is &lt;strong&gt;developer productivity&lt;/strong&gt;. But that is a full spectrum reaching from simple auto-completion to AI-guided auto-coding. For me the hierarchy is the following&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Basic Productivity&lt;/strong&gt;&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;Syntax Highlighting&lt;/li&gt;
&lt;li&gt;Meaningful errors during compilation / editing&lt;/li&gt;
&lt;li&gt;Debugging (stepping, breakpoints, ...)&lt;/li&gt;
&lt;li&gt;Correct context specific auto-completion (as in IntelliSense)&lt;/li&gt;
&lt;li&gt;Code Navigation&lt;/li&gt;
&lt;li&gt;Refactoring / Code Fixes&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;&lt;strong&gt;Advanced Productivity&lt;/strong&gt;&lt;/p&gt;
&lt;ol start="7"&gt;
&lt;li&gt;Advanced Debugging (as in IntelliTrace, break and edit, hot reload, ...)&lt;/li&gt;
&lt;li&gt;AI / statistical guidance (as in GitHub CoPilot, IntelliCode, ...)&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;&lt;strong&gt;Super Advanced Productivity&lt;/strong&gt;&lt;/p&gt;
&lt;ol start="9"&gt;
&lt;li&gt;Visual Designers (remember why we bought &lt;strong&gt;Visual&lt;/strong&gt; Studio in the 90s)&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;Everything in basic productivity is in 2022 elementary state of the art and comes for free (rhetorically up to here: free as in beer).&lt;/p&gt;
&lt;h2 id="what-makes-a-programming-language-adopted-in-a-coorperation"&gt;What makes a programming language adopted in a coorperation?&lt;/h2&gt;
&lt;p&gt;When making decisions about programming languages, we decision makers have to consider ...&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;hard factors&lt;/strong&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;The Architect asks: Does the programming language fullfill the needs?&lt;/li&gt;
&lt;li&gt;The R&amp;amp;D lead asks: Can I hire easily for this programming language? Does my team know this language?&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;strong&gt;soft factors&lt;/strong&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;The Apple, Linux, Web, or Windows fanboy / IT admin asks: Does it run on my platform?&lt;/li&gt;
&lt;li&gt;The R&amp;amp;D lead asks: Do I need licenses for it?&lt;/li&gt;
&lt;li&gt;The careful person asks: Is it free software? Is it Open Source Software? Can I own it? Can I rely on it?&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;So in a free choice situation it boils down to these soft decision factors.&lt;/p&gt;
&lt;p&gt;On &lt;strong&gt;platform coverage&lt;/strong&gt;: The gigantic success of VS Code and .NET Core have opened up the platform coverage topic for C#/F#. .NET can freely compete with Java due to this.&lt;/p&gt;
&lt;p&gt;✅ &lt;em&gt;The actual trigger for the announcement is further investment into that. That is good and everyone likes it.&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;On &lt;strong&gt;licenses&lt;/strong&gt;: For C#/F# we could always argue that there is VS Code and Omnisharp and &amp;quot;everything&amp;quot; is MIT licensed. We decision maker buy anyway the Visual Studio licenses because of increased productivity. The same applies with Java on the Eclipse / JetBrains IntelliJ split.&lt;/p&gt;
&lt;p&gt;✅ &lt;em&gt;And the trigger for the announcement is further investment into that. That is good and everyone likes it.&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;However, there is the fundamental split between &lt;em&gt;basic productivity&lt;/em&gt; and &lt;em&gt;advanced productivity&lt;/em&gt; and our willingness to pay for it.&lt;/p&gt;
&lt;p&gt;✅ Are we willing to pay for &lt;em&gt;advanced productivity&lt;/em&gt;? Answer: Yes! Evidence: Many many Visual Studio and JetBrains subscription.&lt;/p&gt;
&lt;p&gt;❌ Are we willing to pay for &lt;em&gt;basic productivity&lt;/em&gt;? Answer: No! Evidence: Adoption of Omnisharp and Creation of Visual Studio Community.&lt;/p&gt;
&lt;p&gt;Why we do not pay for basic productivity features: because it is 2022 and there are excellent alternatives out there. Java has all the whistles and most others have at least the basic productivity features.&lt;/p&gt;
&lt;p&gt;On &lt;strong&gt;open vs. closed&lt;/strong&gt; source: How deep can I inspect it when something misbehaves? Can I fix it? Am I dependent and locked on a single vendor (for price hickups, discontinuations, ...)? Can I archive the package for 30 years and fix it myself? Is it secure?&lt;/p&gt;
&lt;p&gt;❌ All of these questions flip with this announcement. There is no &lt;strong&gt;trust&lt;/strong&gt; in big cooperations to either discontinue a product, not care about a product or extort money from us developers. We developer got burned by Apple, Google and Microsoft on every opportunity when it comes to this. &lt;strong&gt;The only trust establishing situation is real open source&lt;/strong&gt;. For &lt;em&gt;basic productivity&lt;/em&gt; the full end to end stack needs to be open source (incl. debugger and &amp;quot;LSP Tools Host&amp;quot;) as in MIT/Apache/GPL licensed or &lt;strong&gt;viable&lt;/strong&gt; alternatives needs to be present (as in Eclipse for Java). &lt;em&gt;Advanced productivity&lt;/em&gt; can be always be optional from this safeguarding perspective.&lt;/p&gt;
&lt;h2 id="a-way-out"&gt;A way out&lt;/h2&gt;
&lt;p&gt;This is the simple part&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;Make the &amp;quot;LSP Tools Host&amp;quot; and the .NET debugger open source (license wise).&lt;/li&gt;
&lt;li&gt;Make both of them pluggable with Microsoft commercial plugins for the &lt;em&gt;advanced productivity&lt;/em&gt;. I know, especially for the debugger, that this is an hard thing.&lt;/li&gt;
&lt;li&gt;Sell us a &amp;quot;C# (Commercial)&amp;quot; with &lt;em&gt;advanced productivity&lt;/em&gt; edition next a fully free &amp;quot;C# (Community)&amp;quot; with &lt;em&gt;basic productivity&lt;/em&gt; edition (free as in beer AND in open source license).&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;I do not see how Microsoft can loose intellectual property, thought leadership or market share to anyone else. Not on the short term and not on the long term when trust is established. We talk here communication bridges and adapters.&lt;/p&gt;
&lt;p&gt;Considering, what happenend with Pylance (and IMHO PHP language server): The above should be a playbook for any language not only .NET/C#/F#.&lt;/p&gt;
&lt;h2 id="appendix-a-an-architecture-side-note"&gt;Appendix A: An architecture side note&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;There is an awesome LSP protocol client/server library as part of the OmniSharp library. No matter what, do not close source this even if it is extended by proprietary Microsoft extensions. It is a human readable protocol. The .NET community builds language servers beyond just the languages C#/F#.&lt;/li&gt;
&lt;li&gt;Do not break the Roslyn project and the public availability of code analyzers/fixes (and other aspects of the &amp;quot;Modern Compiler Construction&amp;quot;). It is a modern compiler and not only an AST exporter.&lt;/li&gt;
&lt;li&gt;I assume the &amp;quot;LSP Tool Host&amp;quot; is nothing else than interacting with and editor based on text via LSP/DSP and then forwarding the events into the commercial and non-commercial plugins. Why is a stable, reliable, easy, multi-provider language/debugging server such a secret. Especially when the DSP and LSP are such a thin wrapper around human-eye visible, standardized text editor features.&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="appendix-d-disclaimers"&gt;Appendix D: Disclaimers&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;I am not speaking for my employer&lt;/li&gt;
&lt;li&gt;I am not advocating in favor of free software vs. open source software. MIT is for me, in this local context free software.&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="appendix-e-an-ethical-side-note"&gt;Appendix E: An ethical side note&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;There are countless contributors who have contributed to OmniSharp, Hot Reload and the .NET Foundation (as an entity). Do not screw them. Do not steal their work (intelectionally, morally, reputation or physically).&lt;/li&gt;
&lt;li&gt;We developers very well accept Microsoft's need to earn money. Go Open Core with .NET. Be open about it, be smart about it (see all of above) and include the community on the road. We developer have zero tolerance for this kind of messaging (remember: we deal with a CPU who is not ambivalent in its outcome: it is either true or false) where we are told half of the relevant information. We are now in the third communication debacle within a year (.NET Foundation, Hot Reload, &amp;quot;LSP Tools Host&amp;quot;) just because Microsoft management is not willing to tell us their roadmap and real intention.&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="appendix-u-update-in-december-2023"&gt;Appendix U: Update in December 2023&lt;/h2&gt;
&lt;p&gt;A year into the new license change and the release of the C# Dev Kit, I am happy to oberserve that &lt;strong&gt;Microsoft seems to have listened to the community&lt;/strong&gt; and kept the LSP Server Host open source, and released a MIT licensed &amp;quot;C#&amp;quot; plugin and a commercial &amp;quot;C# DevKit&amp;quot;. This is really good. I am still in hope they realize that the money is with visual designers and one day we get model Apps like we did for WinForms.&lt;/p&gt;
&lt;p&gt;We are &lt;strong&gt;still waiting for the debugger&lt;/strong&gt;.&lt;/p&gt;
</content:encoded>
		</item>
		<item>
			<title>Extension Methods</title>
			<link>http://tthiery.github.io/posts/2021/07/10/extension-methods</link>
			<description>&lt;p&gt;Extension Methods in C# are a crucial element of modern .NET. They are the foundation of LINQ and used everywhere. However, the are sometimes considered as a bad smell when it comes to code reviewing. In this article I want to discuss the concept of extension methods and its position in the OO patterns &amp;amp; principles.&lt;/p&gt;</description>
			<guid>http://tthiery.github.io/posts/2021/07/10/extension-methods</guid>
			<pubDate>Sat, 10 Jul 2021 00:00:00 GMT</pubDate>
			<content:encoded>&lt;p&gt;Extension Methods in C# are a crucial element of modern .NET. They are the foundation of LINQ and used everywhere. However, the are sometimes considered as a bad smell when it comes to code reviewing. In this article I want to discuss the concept of extension methods and its position in the OO patterns &amp;amp; principles.&lt;/p&gt;
&lt;blockquote class="blockquote"&gt;
&lt;p&gt;&lt;strong&gt;Note&lt;/strong&gt;: Extension Methods are often used to build domain specific languages (might it be a SwiftUI-alike, a mocking specification system, ...). Everything goes in this space. The target there is the newly constructed language. In this article, I discuss the integration into the regular C# programming language and not a specialization of it.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;h2 id="solid-principles"&gt;SOLID Principles&lt;/h2&gt;
&lt;p&gt;SOLID principles are a corner stone of object oriented design.&lt;/p&gt;
&lt;blockquote class="blockquote"&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;S&lt;/strong&gt; ingle Responsibility Principle (&lt;em&gt;SRP&lt;/em&gt;): &amp;quot;There should never be more than one reason for a class to change.&amp;quot; In other words, every class should have only one responsibility.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;O&lt;/strong&gt; pen Closed Principle (&lt;em&gt;OCP&lt;/em&gt;): &amp;quot;Software entities ... should be open for extension, but closed for modification.&amp;quot;&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;L&lt;/strong&gt; iskov Substitution Principle (&lt;em&gt;LSP&lt;/em&gt;): &amp;quot;Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it&amp;quot;. See also design by contract.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;I&lt;/strong&gt; nterface Segregation Principle (&lt;em&gt;ISP&lt;/em&gt;):  &amp;quot;Many client-specific interfaces are better than one general-purpose interface.&amp;quot;&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;D&lt;/strong&gt; ependency Inversion Principle (&lt;em&gt;DIP&lt;/em&gt;): &amp;quot;Depend upon abstractions, not concretions.&amp;quot;&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;-- via &lt;a href="https://en.wikipedia.org/wiki/SOLID"&gt;Wikipedia&lt;/a&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;h2 id="soft-skills-of-code"&gt;Soft Skills (of Code)&lt;/h2&gt;
&lt;p&gt;Under the world of patterns and principles there are also soft skills 😀.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Readability&lt;/strong&gt;: Code is read 100 times as often as it is created or modified. It is read in full fledged editors or in a diff tool on the command line without even syntax highlighting. Regular (as in 99% of) code has to be optimized for readability.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Usability&lt;/strong&gt;: When writing function with the intention of other developers using it, usability is a concern. The definition of the function as well as its integration into the workflow of the user in the IDE matters here.&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="the-evaluation"&gt;The Evaluation&lt;/h2&gt;
&lt;p&gt;So are exension methods violating these principles? Are they a bad thing in software design?&lt;/p&gt;
&lt;p&gt;Let us dissect different use cases!&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Extending fundamental base types&lt;/strong&gt;: Adding an extension method to a base type.&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;string foo = &amp;quot;Hello World&amp;quot;;

var hash = foo.HashSha1();

// vs. static method
var has = Sha1.Hash(foo);
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;❌ Single Responsibility: There is no space for hashing in strings. &lt;code&gt;.WordCount()&lt;/code&gt; or &lt;code&gt;.IsASCII()&lt;/code&gt; maybe, because the contribute to the responsibility to represent text. But Hash is a different domain. The responsibility of hashing and the responsibility of text representation does not intersect. This usage only moves the argument from the braces to the context.&lt;/p&gt;
&lt;p&gt;❌ Readability: There is no gain versus the usage in traditional static methods. The extension method feels like a transformation, the static method invocation like a function call. Both are fundamentally well understood concept when reading code. Both are valid patterns in object oriented programming and functional programming. The significant negative thing the extension method does is hiding the ownership of the function.&lt;/p&gt;
&lt;p&gt;❌ Usability: There is no benefit in the general usability either. Auto-Completion would be cluttered with suggestions of countless domains. Namespace (and by extend static class names) with &lt;code&gt;using&lt;/code&gt;, &lt;code&gt;static using&lt;/code&gt; and &lt;code&gt;global using&lt;/code&gt; have a rationale to exist, which is de-cluttering the global namespace and resolving potential conflicts in naming. Extension methods are typically attached to more generic namespaces to unfold their availability.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Throw helpers&lt;/strong&gt;: Simplify your parameter guards by using one-line-extension methods.&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;public void Execute(string command, int count)
{
    command.ThrowIfNullOrEmpty();
    count.ThrowIfSmallerThan(0);
    // ...
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;❌ Single Responsibility: See above.&lt;/p&gt;
&lt;p&gt;❌ Readability: See above.&lt;/p&gt;
&lt;p&gt;❌ Usability: See above. It is even worse here, since the contributed functions are only for a special purpose which is only used at the beginning of a function.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Extending the capabilities&lt;/strong&gt;: Adding new capabilities to a type.&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;public interface ILogger { void Log(string text); }

ILogger log = GetLogger();
log.LogDebug();
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;✅ Single Responsibility Principle: Not violated. LogDebug contributes to the responsibility of &lt;code&gt;ILogger&lt;/code&gt;.&lt;/p&gt;
&lt;p&gt;✅ Open-Close Principle: &lt;code&gt;ILogger&lt;/code&gt; is not modified (it remains closed). However, C# extension methods make it Open for &lt;strong&gt;extensions&lt;/strong&gt;.&lt;/p&gt;
&lt;p&gt;✅ Liskov Substitution Principle: Another implementation of &lt;code&gt;ILogger&lt;/code&gt;  (or another derived class of a default logger) can be provided without being influenced by the extension mehtod. The extension methods, like other consumers expect an unchanged behavior. Another consumer of &lt;code&gt;ILogger&lt;/code&gt; interface (old and new implementation) would not be influenced.&lt;/p&gt;
&lt;p&gt;✅ Interface Segregation Principle: &lt;code&gt;LogDebug&lt;/code&gt; and &lt;code&gt;Log&lt;/code&gt; are contracted separately from each other (they come from different types), so the interface was segregated and can be modified independently.&lt;/p&gt;
&lt;p&gt;🕵️‍♀️ Dependency Inversion Principle: There is no abstraction here. The extension method cannot be provided by a third party (like a DI container) and abstracted by an interface. It is a static method.&lt;/p&gt;
&lt;p&gt;✅ Readability: The contributed extended method intents to extend the capability of the original type. It belongs to the type in regards of the &lt;em&gt;SRP&lt;/em&gt;. Additionally - in this example and as a recommendation - the extension method naming is adjusted to the target type helping the reader to understand the purpose.&lt;/p&gt;
&lt;p&gt;✅ Usability: The extension method improves the usability by making the functionality available with Intellisense.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Bridging Domains&lt;/strong&gt;: Adding capabilities to one domain by attaching another domain.&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;void Configure(IServiceCollection services)
{
    services
        .AddLogging()
        .AddMvc();
}
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;✅ Single Responsibility Principle: &lt;code&gt;.AddLogging()&lt;/code&gt; contributes to the DI Container building capability of &lt;code&gt;IServiceCollection&lt;/code&gt;. It also has the responsbility of initializing the &lt;code&gt;ILogger&lt;/code&gt; infrastructure withing the Logging subsystem. Therefore, &lt;code&gt;.AddLogging()&lt;/code&gt; has no place in implementation or the interface of &lt;code&gt;IServiceCollection&lt;/code&gt; but is an ideal candiate for extension methods (even in the same assembly and direct next to the extended type).&lt;/p&gt;
&lt;svg height="210" width="500"&gt;
  &lt;rect  x="185" y="10" rx="10" width="305" height="180" style="fill:blue;opacity:0.3" /&gt;
  &lt;text x="280" y="25" style="fill:white;font-size:8pt;text-decoration:underline;opacity:0.5"&gt;Assembly: Logging&lt;/text&gt;
  &lt;rect  x="10" y="10" rx="10" width="170" height="180" style="fill:red;opacity:0.3" /&gt;
  &lt;text x="20" y="25" style="fill:white;font-size:8pt;text-decoration:underline;opacity:0.5"&gt;Assembly: DependencyInjection&lt;/text&gt;
  &lt;circle cx="100" cy="100" r="70" style="stroke:green;stroke-width:3px;fill:transparent"&gt;
  &lt;/circle&gt;
  &lt;text x="60" y="70" style="fill:white;font-size:8pt;text-decoration:underline;"&gt;IServiceCollection&lt;/text&gt;
  &lt;text x="60" y="85" style="fill:white;font-size:8pt;"&gt;+ AddSingleton&lt;/text&gt;
  &lt;text x="60" y="100" style="fill:white;font-size:8pt;"&gt;+ AddTransient&lt;/text&gt;
  &lt;text x="60" y="115" style="fill:white;font-size:8pt;"&gt;+ BuildServiceProvider&lt;/text&gt;
  &lt;ellipse cx="150" cy="100" rx="130" ry="100" style="stroke:red;stroke-width:2px;fill:transparent" /&gt;
  &lt;text x="190" y="85" style="fill:white;font-size:8pt;"&gt;+ AddLogging&lt;/text&gt;
  &lt;circle cx="400" cy="100" r="70" style="stroke:green;stroke-width:3px;fill:transparent"&gt;
  &lt;/circle&gt;
  &lt;line x1="260" y1="82" x2="330" y2="82" style="stroke:gray;stroke-width:2" /&gt;
&lt;/svg&gt;
&lt;p&gt;✅ Open-Close Principle: &lt;code&gt;IServiceCollection&lt;/code&gt; is not modified as Logging does not contribute to its domain and there is no need to change it since consumers can only use &lt;code&gt;.AddSingleton()&lt;/code&gt; or &lt;code&gt;.AddTransient()&lt;/code&gt;. The interface remains closed. However, C# extension methods make it Open for &lt;strong&gt;extensions&lt;/strong&gt;.&lt;/p&gt;
&lt;p&gt;✅ Liskov Substitution Principle: See above.&lt;/p&gt;
&lt;p&gt;✅ Interface Segregation Principle: See above. Extension methods are an valid method to segregate the interface into smaller parts (here the segregated specialization into the bridged technology). Extensions methods also do not contribute to the single-inheritance limitation (which extension derives in which order and are all known) and effectively form segregated interfaces.&lt;/p&gt;
&lt;svg height="300" width="500"&gt;
  &lt;rect  x="185" y="10" rx="10" width="120" height="180" style="fill:blue;opacity:0.3" /&gt;
  &lt;text x="200" y="25" style="fill:white;font-size:8pt;text-decoration:underline;opacity:0.5"&gt;Assembly: Logging&lt;/text&gt;
  &lt;rect  x="10" y="10" rx="10" width="170" height="180" style="fill:red;opacity:0.3" /&gt;
  &lt;text x="20" y="25" style="fill:white;font-size:8pt;text-decoration:underline;opacity:0.5"&gt;Assembly: DependencyInjection&lt;/text&gt;
  &lt;rect  x="10" y="200" rx="10" width="170" height="90" style="fill:orange;opacity:0.3" /&gt;
  &lt;text x="20" y="215" style="fill:white;font-size:8pt;text-decoration:underline;opacity:0.5"&gt;Assembly: AspNetCore&lt;/text&gt;
  &lt;circle cx="100" cy="100" r="70" style="stroke:green;stroke-width:3px;fill:transparent"&gt;
  &lt;/circle&gt;
  &lt;text x="60" y="70" style="fill:white;font-size:8pt;text-decoration:underline;"&gt;IServiceCollection&lt;/text&gt;
  &lt;text x="60" y="85" style="fill:white;font-size:8pt;"&gt;+ AddSingleton&lt;/text&gt;
  &lt;text x="60" y="100" style="fill:white;font-size:8pt;"&gt;+ AddTransient&lt;/text&gt;
  &lt;text x="60" y="115" style="fill:white;font-size:8pt;"&gt;+ BuildServiceProvider&lt;/text&gt;
  &lt;ellipse cx="150" cy="100" rx="130" ry="100" style="stroke:red;stroke-width:2px;fill:transparent" /&gt;
  &lt;text x="190" y="85" style="fill:white;font-size:8pt;"&gt;+ AddLogging&lt;/text&gt;
  &lt;ellipse cx="100" cy="150" rx="100" ry="130" style="stroke:red;stroke-width:2px;fill:transparent" /&gt;
  &lt;text x="60" y="235" style="fill:white;font-size:8pt;"&gt;+ AddMvc&lt;/text&gt;
&lt;/svg&gt;
&lt;p&gt;🕵️‍♀️ Dependency Inversion Principle: See above.&lt;/p&gt;
&lt;p&gt;✅ Readability: See above.&lt;/p&gt;
&lt;p&gt;✅ Usability: See above.&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;Not all extension method use cases are really good usages when it comes to object-oriented programming. However, there are plenty of good ones.&lt;/p&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;Note&lt;/strong&gt;: I will continually update this article when I see proper use cases which are interesting to document.&lt;/em&gt;&lt;/p&gt;
</content:encoded>
		</item>
		<item>
			<title>On Building a Middleware Framework</title>
			<link>http://tthiery.github.io/posts/2021/06/05/on-building-middleware</link>
			<description>&lt;p&gt;I am fascinated by Middleware Stacks. Middlewares help us to customize a function invocation (typically a request handler) with additional behavior before and after the invocation of function. Popular examples are authentication, logging or exception handling middlewares. Often they handle non-functional requirements (like logging, security, ...).&lt;/p&gt;</description>
			<guid>http://tthiery.github.io/posts/2021/06/05/on-building-middleware</guid>
			<pubDate>Sat, 05 Jun 2021 00:00:00 GMT</pubDate>
			<content:encoded>&lt;p&gt;I am fascinated by Middleware Stacks. Middlewares help us to customize a function invocation (typically a request handler) with additional behavior before and after the invocation of function. Popular examples are authentication, logging or exception handling middlewares. Often they handle non-functional requirements (like logging, security, ...).&lt;/p&gt;
&lt;p&gt;As a .NET developer I use daily the prominent middleware stack in ASP.NET Core. While beautifully abstracted and designed, there is however one big caveat: It is bound to HTTP request/response. Due to that limitation I built &lt;a href="https://github.com/violetgrass/middleware"&gt;violetgrass/middleware&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;In this article I try to discuss the various elements of a ASP.NET Core inspired middleware stack implemented in pure .NET.&lt;/p&gt;
&lt;h2 id="the-delegate"&gt;The delegate&lt;/h2&gt;
&lt;p&gt;A middleware is a stackable function. The function definition is called the &lt;code&gt;MiddlewareDelegate&lt;/code&gt; (ASP.NET Core: &lt;code&gt;RequestDelegate&lt;/code&gt;).&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;public delegate Task MiddlewareDelegate&amp;lt;TContext&amp;gt;(TContext context) where TContext : Context;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;The function expose the following characteristics:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Is is &lt;strong&gt;asynchronous&lt;/strong&gt;, since most likely, some part of the stack needs to access slowlier resources (e.g. a file system).&lt;/li&gt;
&lt;li&gt;It receives an invocation &lt;strong&gt;context&lt;/strong&gt; (essentially the input and output of the function). (ASP.NET Core: &lt;code&gt;HttpContext&lt;/code&gt;).&lt;/li&gt;
&lt;li&gt;It is a call without a return value.&lt;/li&gt;
&lt;li&gt;It is stateless on its own (it is a function not an interface for a class).&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;A simple message handler can be represented in the &lt;code&gt;MiddlewareDelegate&lt;/code&gt;.&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;async Task HandleAsync(Context context)
{
    var message = GetMessageFromContext(context);
    Console.WriteLine(message)
}

MiddlewareDelegate&amp;lt;Context&amp;gt; messageHandler = HandleAsync;

var message = GetMessage();
await messageHandler(message); // process the message.
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;A middleware however, is not only the final handler, but essentially everything in the &lt;strong&gt;middle&lt;/strong&gt; between the dispatching invoker and the terminal handler.
In simple cases, this could be added programmatically.&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;async Task HandleAsync(Context context) { /* see above */ }
async Task LogAsync(Context context)
{
    Log.Write(&amp;quot;Before&amp;quot;);
    await HandleAsync(context);
    Log.Write(&amp;quot;After&amp;quot;);
}
async Task CatchExceptionAsync(Context context)
{
    try
    {
        await LogAsync(context);
    }
    catch { /* ... */ }
}

MiddlewareDelegate&amp;lt;Context&amp;gt; messageHandler = CatchExceptionAsync;

var message = GetMessage();
await messageHandler(message); // try-catch, log and process the message.
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;This method of coding exposes some issues&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;The composition of the functions influences the actual code of the functions.&lt;/li&gt;
&lt;li&gt;There is not methodology to integrate third parties or have out-of-the-box functionality.&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="the-building-of-the-middleware-stack"&gt;The building of the middleware (stack)&lt;/h2&gt;
&lt;p&gt;The purpose of using a middleware framework is to enable second and third party integrations into an efficient invocation stack. This includes all attributes of regular method stacking (like controlling the code before and after the invocation and handlings exceptions).&lt;/p&gt;
&lt;p&gt;In a first step, the invocation of the next wrapped function needs to be parameterized.&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;async Task LogAsync(MiddlewareDelegate&amp;lt;Context&amp;gt; next, Context context)
{
    Log.Write(&amp;quot;Before&amp;quot;);
    await next(context);
    Log.Write(&amp;quot;After&amp;quot;);
}
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;However, that would imply that the delegate is recursive and would differ between middleware (which need &lt;code&gt;next&lt;/code&gt;) and the terminal handler (which does not need &lt;code&gt;next&lt;/code&gt;). Closures to rescue which can bind additional variables not represented as function parameters. Closures need to be created by another function which holds the &amp;quot;closured&amp;quot; scope ...&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;MiddlewareDelegate&amp;lt;Context&amp;gt; LogFactory(MiddlewareDelegate&amp;lt;Context&amp;gt; next)
{
    return async (Context context) =&amp;gt; // = MiddlewareDelegate&amp;lt;Context&amp;gt;
    { 
        Log.Write(&amp;quot;Before&amp;quot;);
        await next(context);
        Log.Write(&amp;quot;After&amp;quot;);
    };
}

// or in modern C# with local functions instead of lambdas.
MiddlewareDelegate&amp;lt;Context&amp;gt; LogFactory(MiddlewareDelegate&amp;lt;Context&amp;gt; next)
{
    return LogAsync;

    async Task LogAsync(Context context)
    {
        Log.Write(&amp;quot;Before&amp;quot;);
        await next(context);
        Log.Write(&amp;quot;After&amp;quot;);
    }
}

// or if you like expression bodied member
MiddlewareDelegate&amp;lt;Context&amp;gt; LogFactory(MiddlewareDelegate&amp;lt;Context&amp;gt; next)
    =&amp;gt; async context =&amp;gt; {  Log.Write(&amp;quot;Before&amp;quot;); await next(context); Log.Write(&amp;quot;After&amp;quot;); };

// or currying and first class functions
Func&amp;lt;MiddlewareDelegate&amp;lt;Context&amp;gt;, MiddlewareDelegate&amp;lt;Context&amp;gt;&amp;gt; LogFactory = next =&amp;gt; async context =&amp;gt; {  Log.Write(&amp;quot;Before&amp;quot;); await next(context); Log.Write(&amp;quot;After&amp;quot;); };
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;This function which builds the middleware is called a &lt;strong&gt;middleware factory&lt;/strong&gt; (&lt;code&gt;Func&amp;lt;MiddlewareDelegate&amp;lt;TContext&amp;gt;, MiddlewareDelegate&amp;lt;TContext&amp;gt;&amp;gt;&lt;/code&gt;). It is a function which receives the &lt;code&gt;next&lt;/code&gt; element in the middleware stack to built and emits a function which represent the current middleware and all middleware later in the stack.&lt;/p&gt;
&lt;p&gt;You can now write ..&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;var messageHandlerStep3 = HandleAsync;
var messageHandlerStep2 = LogFactory(messageHandlerStep3);
var messageHandlerStep1 = CatchExceptionFactory(messageHandlerStep2);

var message = GetMessage();
await messageHandlerStep1(message); // try-catch, log and process the message.
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;So now let us build a fancy builder infrastructure for it.&lt;/p&gt;
&lt;p&gt;A &lt;code&gt;IMiddlewareBuilder&amp;lt;TContext&amp;gt;&lt;/code&gt; (ASP.NET Core: &lt;code&gt;IApplicationBuilder&lt;/code&gt;) collects a set of middleware factories.&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;public IMiddlewareBuilder&amp;lt;TContext&amp;gt; Use(Func&amp;lt;MiddlewareDelegate&amp;lt;TContext&amp;gt;, MiddlewareDelegate&amp;lt;TContext&amp;gt;&amp;gt; middlewareFactory)
{
    _factories.Add(middlewareFactory);

    return this;
}
public MiddlewareDelegate&amp;lt;TContext&amp;gt; Build()
{
    _factories.Reverse();

    MiddlewareDelegate&amp;lt;TContext&amp;gt; current = context =&amp;gt; Task.CompletedTask; // safeguard

    foreach (var middlewareFactory in _factories)
    {
        current = middlewareFactory(current);
    }

    return current;
}
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;Note&lt;/strong&gt;: Ignoring all the interface definitions and additional features beyond middleware, this above is the complete business logic of violetgrass/middleware.&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;The above Build method iterate each factory (in reverse order) and throw the built middleware function of the current factory as an input to the factory method of the next layer. An Build invocation might look like that ...&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;var messageHandler = new MiddlewareBuilder&amp;lt;Context&amp;gt;()
    .Use(CatchExceptionFactory)
    .Use(LogFactory)
    .Use(next =&amp;gt; HandleAsync) // no use of next
    .Build();
    
var message = GetMessage();
await messageHandler(message); // try-catch, log and process the message.
&lt;/code&gt;&lt;/pre&gt;
&lt;h2 id="configuring-the-middleware"&gt;Configuring the Middleware&lt;/h2&gt;
&lt;p&gt;With the use of C# extension methods, first and third party logic can be added to the &lt;code&gt;MiddlewareBuilder&lt;/code&gt;. The builder extension methods can be influenced by parameters, Dependency Injection and other sources of information.&lt;/p&gt;
&lt;p&gt;Also, helper methods can be added to simplify the creation of middleware.&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;// Typical third part integration
public static class MiddlewareBuilderExtensions
{
    public static IMiddlewareBuilder&amp;lt;TContext&amp;gt; UseLog(this IMiddlewareBuilder&amp;lt;TContext&amp;gt; self, bool verboseLogging = false)
    {
        // this block is run when the builder (extension) methods are invoked (one-time).
        // .. allows to perform configuration and collect metadata (e.g. via parameters or DI)
        return self.Use(LogFactory);

        MiddlewareDelegate&amp;lt;Context&amp;gt; LogFactory(MiddlewareDelegate&amp;lt;Context&amp;gt; next)
        {
            // this block is run when the middleware stack is actually build (one-time).
            // .. the shape of the middleware is known at this moment
            // .. has closure of configuration
            return LogAsync;

            async Task LogAsync(Context context)
            {
                // this block runs when the middleware stack is invoked (each-request)
                // .. has closure of configuration
                // .. has closure of shape

                // as a middleware it encapsulates the next from the building time
                if (verboseLogging) { Log.Write(&amp;quot;Before&amp;quot;); }
                await next(context);
                if (verboseLogging) { Log.Write(&amp;quot;After&amp;quot;); }
            }
        }
    }
}

// simple helper functions
public static partial class IMiddlewareBuilderExtensions
{
    public static IMiddlewareBuilder&amp;lt;TContext&amp;gt; Use&amp;lt;TContext&amp;gt;(this IMiddlewareBuilder&amp;lt;TContext&amp;gt; self, MiddlewareDelegate&amp;lt;TContext&amp;gt; middleware) where TContext : Context
        =&amp;gt; self.Use(next =&amp;gt; async context =&amp;gt; { await middleware(context); await next(context); });
}

var messageHandler = new MiddlewareBuilder&amp;lt;Context&amp;gt;()
    .UseExceptionHandling()
    .UseLog(verbose: true)
    .Use(HandleAsync)
    .Build();
    
var message = GetMessage();
await messageHandler(message); // try-catch, log and process the message.
&lt;/code&gt;&lt;/pre&gt;
&lt;h2 id="conclusions"&gt;Conclusions&lt;/h2&gt;
&lt;p&gt;This article hopefully gave an introduction into how the &lt;a href="https://github.com/violetgrass/middleware"&gt;violetgrass/middleware&lt;/a&gt; and ASP.NET Core middleware stack work. While sometimes it looks over-engineered, it is actually quite simple and a powerful extensibility framework.&lt;/p&gt;
&lt;p&gt;There is more to typically middleware scenarios like dispatching and endpoint routing, however, this is material for other articles.&lt;/p&gt;
</content:encoded>
		</item>
		<item>
			<title>LEGO Powered UP - Motor Modes POS and APOS</title>
			<link>http://tthiery.github.io/posts/2020/08/01/lego-powered-up-motor-modes-pos-and-apos</link>
			<description>&lt;p&gt;The LEGO Control+ motors - Technic XLarge Linear Motor and Technic Large Linear Motor - have internally the modes &lt;code&gt;POS&lt;/code&gt; (reporting a position) and &lt;code&gt;APOS&lt;/code&gt; (reporting an absolute position). Further does the LEGO Wireless Protocol specify methods &lt;a href="https://lego.github.io/lego-ble-wireless-protocol-docs/index.html#output-sub-command-startspeedfordegrees-degrees-speed-maxpower-endstate-useprofile-0x0b"&gt;&lt;code&gt;StartSpeedForDegrees&lt;/code&gt;&lt;/a&gt; and &lt;a href="https://lego.github.io/lego-ble-wireless-protocol-docs/index.html#output-sub-command-gotoabsoluteposition-abspos-speed-maxpower-endstate-useprofile-0x0d"&gt;&lt;code&gt;GotoAbsolutePosition&lt;/code&gt;&lt;/a&gt;.&lt;/p&gt;</description>
			<guid>http://tthiery.github.io/posts/2020/08/01/lego-powered-up-motor-modes-pos-and-apos</guid>
			<pubDate>Sat, 01 Aug 2020 00:00:00 GMT</pubDate>
			<content:encoded>&lt;p&gt;The LEGO Control+ motors - Technic XLarge Linear Motor and Technic Large Linear Motor - have internally the modes &lt;code&gt;POS&lt;/code&gt; (reporting a position) and &lt;code&gt;APOS&lt;/code&gt; (reporting an absolute position). Further does the LEGO Wireless Protocol specify methods &lt;a href="https://lego.github.io/lego-ble-wireless-protocol-docs/index.html#output-sub-command-startspeedfordegrees-degrees-speed-maxpower-endstate-useprofile-0x0b"&gt;&lt;code&gt;StartSpeedForDegrees&lt;/code&gt;&lt;/a&gt; and &lt;a href="https://lego.github.io/lego-ble-wireless-protocol-docs/index.html#output-sub-command-gotoabsoluteposition-abspos-speed-maxpower-endstate-useprofile-0x0d"&gt;&lt;code&gt;GotoAbsolutePosition&lt;/code&gt;&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Strange thing: When using &lt;code&gt;GotoAbsolutePosition&lt;/code&gt; does not work as expected and goes to strange positions and not the expected absolute physical position!&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt;: &lt;code&gt;GotoAbsolutePosition&lt;/code&gt; does not orient itself on the &lt;strong&gt;physical&lt;/strong&gt; &lt;code&gt;APOS&lt;/code&gt;. It is aligned with &lt;strong&gt;virtual&lt;/strong&gt; &lt;code&gt;POS&lt;/code&gt;.&lt;/p&gt;
&lt;p&gt;And to put it in context, a memorable quote:&lt;/p&gt;
&lt;blockquote class="blockquote"&gt;
&lt;p&gt;There are only two hard things in Computer Science: cache invalidation and naming things.&lt;/p&gt;
&lt;p&gt;-- Phil Karlton&lt;/p&gt;
&lt;/blockquote&gt;
&lt;h3 id="the-modes"&gt;The Modes&lt;/h3&gt;
&lt;p&gt;Let us start with the simple mode: &lt;code&gt;APOS&lt;/code&gt; is the absolute position in degrees measured from a zero point. It goes from 0, 1 .. 179, 180 then to -180, -179, .., -1, 0. Simple, straight forward. For the current Control+ motors the zero point is physically not marked.&lt;/p&gt;
&lt;p&gt;&lt;code&gt;POS&lt;/code&gt; on the other hand is more complicated. The value 0 is aligned with the position of the motor was when the device was activated (most likely: put under power). From that moment on, it counts the degrees moved away from that position. And that number can get quite high (it is a &lt;code&gt;Int32&lt;/code&gt;) and exceeds the traditional 0-360 degree range.&lt;/p&gt;
&lt;p&gt;An example&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;Motor is put under power: &lt;code&gt;POS: 0&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;Motor is moved by 30 degrees: &lt;code&gt;POS: 30&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;Motor is moved by -70 degrees: &lt;code&gt;POS: -40&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;Motor is further moved by two full turns (aka. -720 degrees) : &lt;code&gt;POS: -760&lt;/code&gt;&lt;/li&gt;
&lt;/ol&gt;
&lt;h3 id="output-commands"&gt;Output Commands&lt;/h3&gt;
&lt;p&gt;&lt;a href="https://lego.github.io/lego-ble-wireless-protocol-docs/index.html#output-sub-command-startspeedfordegrees-degrees-speed-maxpower-endstate-useprofile-0x0b"&gt;&lt;code&gt;StartSpeedForDegrees&lt;/code&gt;&lt;/a&gt; moves the motor by the amount of degrees &lt;strong&gt;relative&lt;/strong&gt; to the current position. If the motor is at &lt;code&gt;POS: 20&lt;/code&gt; and the command is invoked with 5 degrees the motor is afterwards in &lt;code&gt;POS: 25&lt;/code&gt;.&lt;/p&gt;
&lt;p&gt;&lt;a href="https://lego.github.io/lego-ble-wireless-protocol-docs/index.html#output-sub-command-gotoabsoluteposition-abspos-speed-maxpower-endstate-useprofile-0x0d"&gt;&lt;code&gt;GotoAbsolutePosition&lt;/code&gt;&lt;/a&gt; moves the motor to a given &lt;strong&gt;absolute&lt;/strong&gt; position &lt;strong&gt;within the range of &lt;code&gt;POS&lt;/code&gt;&lt;/strong&gt;. An example: If the position is &lt;code&gt;POS: -760&lt;/code&gt; and command is invoked with -40 the motor will make &lt;em&gt;&lt;strong&gt;two full turns&lt;/strong&gt;&lt;/em&gt; and is &lt;em&gt;&lt;strong&gt;not oriented&lt;/strong&gt;&lt;/em&gt; 40 degrees of the physical zero but -40 degrees of the initial position of the motor. Consequently it takes an &lt;code&gt;Int32&lt;/code&gt; as a parameter.&lt;/p&gt;
&lt;p&gt;These &lt;strong&gt;two unexpected behaviors&lt;/strong&gt; are traps when programming against the LEGO Wireless Protocol / Powered UP. They are a horrible user experience in regards to their naming (developer perspective). &lt;strong&gt;However, they are the correct interface and the right thing to do&lt;/strong&gt;.&lt;/p&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;Note&lt;/strong&gt;: This reflection is based on the Technic Control+ L/XL Linear Motors. There might be a different handling with different motors. I will update the post if I become aware of a difference.&lt;/em&gt;&lt;/p&gt;
&lt;h3 id="adjust-the-mental-model"&gt;Adjust the mental model&lt;/h3&gt;
&lt;ol&gt;
&lt;li&gt;For most use cases, an (physical) absolute position (&lt;code&gt;APOS&lt;/code&gt;) is useless. A Technic axle can be connected in 3 wrong offsets compared to the pyhsical zero point of the motor (remember: unmarked). Even more interesting for gears.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;GotoAbsolutePosition&lt;/code&gt; should be (mentally and in SDKs) named &lt;code&gt;GotoPosition&lt;/code&gt; to better reflect the fact that it is aligned with the &lt;code&gt;POS&lt;/code&gt; range and not the &lt;code&gt;APOS&lt;/code&gt; range.
&lt;ul&gt;
&lt;li&gt;The two full turns can then easily be explained as the amount of degrees as a delta between the current pos and the targeted position the motor should go-to.&lt;/li&gt;
&lt;li&gt;The 40 degrees of the original motor position are also now okay, because that aligns with the understanding of &lt;code&gt;POS&lt;/code&gt;.&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;Note&lt;/strong&gt;: As an alternative: Maybe &lt;code&gt;APOS&lt;/code&gt; is wrongly named 😀. Or maybe we just need a proper documentation.&lt;/em&gt;&lt;/p&gt;
&lt;h3 id="practical-usage-reset-zero"&gt;Practical Usage: Reset Zero&lt;/h3&gt;
&lt;p&gt;Assume a Technic Model with a steering. Magically it was calibrated to the center of your steer. The motor is at &lt;code&gt;POS: 254&lt;/code&gt;.&lt;/p&gt;
&lt;p&gt;The question here is: What use does &lt;code&gt;GotoAbsolutePosition&lt;/code&gt; bring? Well, there is the method &lt;code&gt;PresetEncoder&lt;/code&gt;. It resets &lt;code&gt;POS&lt;/code&gt; to zero. Applied here, &lt;code&gt;GotoAbsolutePosition&lt;/code&gt; can now comfortable control the steering around the middle position (0) without doing complicated math otherwise needed when using &lt;code&gt;StartSpeedForDegrees&lt;/code&gt;.&lt;/p&gt;
&lt;h3 id="conclusions"&gt;Conclusions&lt;/h3&gt;
&lt;p&gt;Naming is hard. Documentation is sometimes a good idea.&lt;/p&gt;
&lt;h3 id="appendix-users-of-sharpbrick.poweredup"&gt;Appendix: Users of SharpBrick.PoweredUp&lt;/h3&gt;
&lt;p&gt;The mentioned modes and commands are exposed using the following methods:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;code&gt;POS&lt;/code&gt; =&amp;gt; &lt;code&gt;TachoMotor.PositionObservable&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;&lt;code&gt;APOS&lt;/code&gt; =&amp;gt; &lt;code&gt;AbsoluteMotor.AbsolutePositionObservable&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;&lt;code&gt;StartSpeedForDegrees&lt;/code&gt; =&amp;gt; &lt;code&gt;TachoMotor.StartSpeedForDegreesAsync&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;&lt;code&gt;GotoAbsolutePosition&lt;/code&gt; =&amp;gt; &lt;code&gt;AbsoluteMotor.GotoAbsolutePositionAsync&lt;/code&gt;.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;PresetEncoder&lt;/code&gt; =&amp;gt; &lt;code&gt;TachoMotor.SetZeroAsync&lt;/code&gt;.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;There might be a change coming which &lt;a href="https://github.com/sharpbrick/powered-up/issues/74"&gt;renames&lt;/a&gt; and &lt;a href="https://github.com/sharpbrick/powered-up/issues/75"&gt;moves&lt;/a&gt; &lt;code&gt;GotoAbsolutePosition&lt;/code&gt;.&lt;/p&gt;
</content:encoded>
		</item>
		<item>
			<title>xUnit Theories with Type Parameters</title>
			<link>http://tthiery.github.io/posts/2020/07/01/xunit-with-generic-paramter</link>
			<description>&lt;p&gt;When unit testing generic protocols like the &lt;a href="https://lego.github.io/lego-ble-wireless-protocol-docs"&gt;Lego Wireless Protocol&lt;/a&gt; input values might be lead to different expected values. Sometimes, however, not only the value changes but also the data types of what to expect. xUnit's &lt;code&gt;Assert.Equal(expected, actual)&lt;/code&gt; methods has overloads for countless basic data types like &lt;code&gt;short&lt;/code&gt;, &lt;code&gt;double&lt;/code&gt;, &lt;code&gt;bool&lt;/code&gt; and elementary support for enums. To activate these, the expected argument would need to be parameterized with the right data type.&lt;/p&gt;</description>
			<guid>http://tthiery.github.io/posts/2020/07/01/xunit-with-generic-paramter</guid>
			<pubDate>Wed, 01 Jul 2020 00:00:00 GMT</pubDate>
			<content:encoded>&lt;p&gt;When unit testing generic protocols like the &lt;a href="https://lego.github.io/lego-ble-wireless-protocol-docs"&gt;Lego Wireless Protocol&lt;/a&gt; input values might be lead to different expected values. Sometimes, however, not only the value changes but also the data types of what to expect. xUnit's &lt;code&gt;Assert.Equal(expected, actual)&lt;/code&gt; methods has overloads for countless basic data types like &lt;code&gt;short&lt;/code&gt;, &lt;code&gt;double&lt;/code&gt;, &lt;code&gt;bool&lt;/code&gt; and elementary support for enums. To activate these, the expected argument would need to be parameterized with the right data type.&lt;/p&gt;
&lt;p&gt;While this works quite nice when using fixed unit tests where the actual/expected data type is part of the method, for xUnit &lt;strong&gt;theories&lt;/strong&gt; it need some more infrastructure in form of adding a type parameter to the unit test method.&lt;/p&gt;
&lt;p&gt;Here an extract from the unit testing from the &lt;a href="https://github.com/sharpbrick/powered-up"&gt;sharpbrick/powered-up&lt;/a&gt; library.&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;[Theory]
[InlineData(&amp;quot;06-00-01-02-06-00&amp;quot;, HubProperty.Button, HubPropertyOperation.Update, false)]
[InlineData(&amp;quot;06-00-01-02-06-01&amp;quot;, HubProperty.Button, HubPropertyOperation.Update, true)]
[InlineData(&amp;quot;06-00-01-05-06-61&amp;quot;, HubProperty.Rssi, HubPropertyOperation.Update, (sbyte)97)]
[InlineData(&amp;quot;06-00-01-06-06-64&amp;quot;, HubProperty.BatteryVoltage, HubPropertyOperation.Update, (byte)100)]
[InlineData(&amp;quot;06-00-01-07-06-00&amp;quot;, HubProperty.BatteryType, HubPropertyOperation.Update, BatteryType.Normal)]
[InlineData(&amp;quot;06-00-01-07-06-01&amp;quot;, HubProperty.BatteryType, HubPropertyOperation.Update, BatteryType.RechargeableBlock)]
[InlineData(&amp;quot;06-00-01-0B-06-80&amp;quot;, HubProperty.SystemTypeId, HubPropertyOperation.Update, SystemType.LegoTechnic_MediumHub)]
[InlineData(&amp;quot;06-00-01-0C-06-00&amp;quot;, HubProperty.HardwareNetworkId, HubPropertyOperation.Update, (byte)0)]
public void HubPropertiesEncoder_Decode_UpdateUpstream&amp;lt;T&amp;gt;(string messageAsString, HubProperty expectedProperty, HubPropertyOperation expectedPropertyOperation, T payload)
{
    // arrange
    var data = BytesStringUtil.StringToData(messageAsString).AsSpan().Slice(3);

    // act
    var message = new HubPropertiesEncoder().Decode(0x00, data) as HubPropertyMessage&amp;lt;T&amp;gt;;

    // assert
    Assert.Equal(expectedProperty, message.Property);
    Assert.Equal(expectedPropertyOperation, message.Operation);
    Assert.Equal(payload, message.Payload);
}
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;The &lt;code&gt;payload&lt;/code&gt; parameter has a data type bound to a generic. When invoking the &lt;code&gt;[Theory]&lt;/code&gt; xUnit will actually instanciate the function with the suitable type parameter. As above, sometimes the &lt;code&gt;[InlineData(...)]&lt;/code&gt; entry needs to be hinted (e.g. &lt;code&gt;(sbyte)97&lt;/code&gt;), when C# defaults might lead to a wrong data type (e.g. &lt;code&gt;97&lt;/code&gt; is of data type &lt;code&gt;int&lt;/code&gt;).&lt;/p&gt;
&lt;p&gt;When the &lt;code&gt;Attribute&lt;/code&gt;s of C# do not allow to instantiate a data type (typically classes), a adapter shim might help:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;[Theory]
[InlineData(&amp;quot;09-00-01-03-06-00-00-00-11&amp;quot;, HubProperty.FwVersion, HubPropertyOperation.Update, &amp;quot;1.1.0.0&amp;quot;)]
[InlineData(&amp;quot;09-00-01-04-06-00-00-00-07&amp;quot;, HubProperty.HwVersion, HubPropertyOperation.Update, &amp;quot;0.7.0.0&amp;quot;)]
[InlineData(&amp;quot;07-00-01-0A-06-00-03&amp;quot;, HubProperty.LegoWirelessProtocolVersion, HubPropertyOperation.Update, &amp;quot;3.0&amp;quot;)]
public void HubPropertiesEncoder_Decode_UpdateUpstream_VersionShim(string messageAsString, HubProperty expectedProperty, HubPropertyOperation expectedPropertyOperation, string payload)
    =&amp;gt; HubPropertiesEncoder_Decode_UpdateUpstream(messageAsString, expectedProperty, expectedPropertyOperation, new Version(payload));
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;Disclaimer:&lt;/strong&gt; I google. This feature was surely somewhere mentioned before. I do not reference the material I googled, because I lost the link.&lt;/em&gt;&lt;/p&gt;
</content:encoded>
		</item>
		<item>
			<title>ReactiveX Middlewares</title>
			<link>http://tthiery.github.io/posts/2020/06/12/reactivex-middlewares</link>
			<description>&lt;p&gt;While implementing &lt;a href="https://github.com/sharpbrick/powered-up"&gt;sharpbrick/powered-up&lt;/a&gt; an interesting problem came up to solve: How to handle the incoming messages of the Bluetooth Low Energy based communication protocol. On top of the Bluetooth abstraction there is a simple callback which would receive roughly 50 different message types which would need dispatching to several locations, some locations would even spawn up dynamically over time. I needed an infrastructure! I needed a middleware 😀.&lt;/p&gt;</description>
			<guid>http://tthiery.github.io/posts/2020/06/12/reactivex-middlewares</guid>
			<pubDate>Fri, 12 Jun 2020 00:00:00 GMT</pubDate>
			<content:encoded>&lt;p&gt;While implementing &lt;a href="https://github.com/sharpbrick/powered-up"&gt;sharpbrick/powered-up&lt;/a&gt; an interesting problem came up to solve: How to handle the incoming messages of the Bluetooth Low Energy based communication protocol. On top of the Bluetooth abstraction there is a simple callback which would receive roughly 50 different message types which would need dispatching to several locations, some locations would even spawn up dynamically over time. I needed an infrastructure! I needed a middleware 😀.&lt;/p&gt;
&lt;h2 id="possible-solutions"&gt;Possible Solutions&lt;/h2&gt;
&lt;p&gt;Within the tighter .NET ecosystem (a.k.a. everything what Microsoft and close friends throw at us) there are the following libraries for push based messaging:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;&lt;code&gt;System.Reactive&lt;/code&gt;&lt;/strong&gt;: The .NET implementation part (and godfather) of the ReactiveX project (e.g. JavaScript: &lt;code&gt;rxjs&lt;/code&gt;). The library is push-based, threading/buffering is optional, allow optional subscription, supports LINQ, allow building dynamic pipelines but is heap based.&lt;/li&gt;
&lt;li&gt;ASP.NET Core &lt;strong&gt;middleware&lt;/strong&gt; stack. Unfortunately, in the current state bound to HTTP. Standalone implementations like &lt;a href="https://github.com/violetgrass/middleware"&gt;violetgrass/middleware&lt;/a&gt; (disclaimer: another side project) make the basic concept available to other server/dispatcher applications.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;System.Threading.Channels&lt;/code&gt;: A part of the ASP.NET Core stack, focused on channeling data between separate producer and consumer threads. The library is push- and pull-based, buffering is including, requires active consumers and does not support LINQ.&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="middlewares"&gt;Middlewares&lt;/h2&gt;
&lt;p&gt;Ignoring &lt;code&gt;System.Threading.Channels&lt;/code&gt; for now, both &lt;code&gt;System.Reactive&lt;/code&gt; and ASP.NET Core compiled middlewares are basically methods to build a series of functions between the place of source and an ultimate target&lt;/p&gt;
&lt;p&gt;A compiled middleware is build upfront and is optimized on efficiency&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;public class QueueMessageContext : Context
{
    public Message Message { get; set; }
}

var stack = new MiddlewareBuilder&amp;lt;QueueMessageContext&amp;gt;()
    // middleware step
    .Use(async (context, next) =&amp;gt; {
        // do something with the context.Message
        await next(context); 
    })
    // middleware step
    .Use(async (context, next) =&amp;gt; {
        // do something with the context.Message
        await next(context); 
    })
    // final handling of message
    .Use(async (context, next) =&amp;gt; {
        // do something with the context.Message
    })
    .Build();

// invoke
var x = new QueueMessageContext() { Message = msg, };

await stack(x); // the whole stack is essentially a stacked function delegate. no magic anymore. no overhead despite millions of requests.
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Using &lt;code&gt;System.Reactive&lt;/code&gt; middlewares can be dynamically constructed&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;var source = new Subject&amp;lt;Message&amp;gt;();

var firstPart = source
    .Select(msg =&amp;gt; { /* do something */ return msg; }); // middleware step

// somewhere else (e.g. on demand)
var d = firstPart
    .Select(msg =&amp;gt; { /* do something */ return msg; }) // middleware step
    .Subscribe(msg =&amp;gt; /* do something */); // final handling of message

// invoke
source.next(msg); // subscriptions are checked, data is boxed, heap is allocated, ...
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;While a compiled middleware has the benefits of performance, a reactive stream can be dynamically composed, filtered and combined (like known from LINQ). It also allows multiple subscriptions which an ASP.NET Core middleware does not. However, there is also a disadvantage: It does not support async/await and will block the producer (exept explictely configured with &lt;code&gt;.ObserveOn&lt;/code&gt;). It does not naturally fit to the common &lt;code&gt;async/await&lt;/code&gt; programming pattern in C#.&lt;/p&gt;
&lt;p&gt;Within &lt;a href="https://github.com/sharpbrick/powered-up"&gt;sharpbrick/powered-up&lt;/a&gt; there is a critical requirement to dynamically compose pipelines of the incoming upstream messages to models representing PoweredUP hubs and devices.&lt;/p&gt;
&lt;blockquote class="blockquote"&gt;
&lt;p&gt;&lt;code&gt;System.Reactive&lt;/code&gt; is therefore the right choice to use within the library. The library behaves similar to a user interface (PoweredUP devices &amp;lt;-&amp;gt; UI controls) with external influences. In the world of UI progamming, the reactive programming model is used by all currently popular frameworks  (React (Native), Angular, ...).&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;For consumers of the library however, the &lt;code&gt;SharpBrick.PoweredUp&lt;/code&gt; library exposes an async/await based interface for invocations. Internally, the library converts the subscriptions to the reactive stream into an &lt;em&gt;awaiter&lt;/em&gt; using &lt;code&gt;.GetAwaiter()&lt;/code&gt; as seen below in a request/response matching algorithm:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;public static async Task&amp;lt;TResultMessage&amp;gt; SendMessageReceiveResultAsync&amp;lt;TResultMessage&amp;gt;(this IPoweredUpProtocol self, PoweredUpMessage requestMessage, Func&amp;lt;TResultMessage, bool&amp;gt; filter = default)
{
    // UpstreamMessages is an IObservable
    var awaitable = self.UpstreamMessages
        .OfType&amp;lt;TResultMessage&amp;gt;()
        .Where(responseMessage =&amp;gt; filter == null || filter(responseMessage))
        .FirstAsync() // only the first message observed is forwarded
        .GetAwaiter(); // make sure the subscription is present at the moment the message is sent.

    await self.SendMessageAsync(requestMessage);

    var response = await awaitable; // subscription is discarded

    return response;
}
&lt;/code&gt;&lt;/pre&gt;
&lt;h2 id="conclusion"&gt;Conclusion&lt;/h2&gt;
&lt;p&gt;When building an application or a library with many variable exit points - may it be UI controls or other model endpoints - for an incoming data stream, using &lt;code&gt;System.Reactive&lt;/code&gt; is the right choice.&lt;/p&gt;
</content:encoded>
		</item>
		<item>
			<title>Using PlatformIO and Git</title>
			<link>http://tthiery.github.io/posts/2020/05/21/platformio-with-git</link>
			<description>&lt;p&gt;When working on my private PlatformIO project for a watertank sensor, I repeatingly struggled with how to manage the source code. PlatformIO is unfortunately not very clear explaining this topic.&lt;/p&gt;</description>
			<guid>http://tthiery.github.io/posts/2020/05/21/platformio-with-git</guid>
			<pubDate>Thu, 21 May 2020 00:00:00 GMT</pubDate>
			<content:encoded>&lt;p&gt;When working on my private PlatformIO project for a watertank sensor, I repeatingly struggled with how to manage the source code. PlatformIO is unfortunately not very clear explaining this topic.&lt;/p&gt;
&lt;p&gt;Simplified, the &lt;code&gt;platform.ini&lt;/code&gt; contains references to the utilized SDKs and library dependencies. The only PlatformIO artifact are the &lt;code&gt;platform.ini&lt;/code&gt; and the entry in the &lt;code&gt;extensions.json&lt;/code&gt;.&lt;/p&gt;
&lt;p&gt;&lt;code&gt;.gitignore&lt;/code&gt; however, will have to contain some entries to avoid commiting the cached PlatformIO is using in form of &lt;code&gt;.pio&lt;/code&gt;.&lt;/p&gt;
&lt;h2 id="file-to-add-to-source-control"&gt;File to add to source control&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;.vscode
&lt;ul&gt;
&lt;li&gt;extensions.json&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;src/* (your source code)&lt;/li&gt;
&lt;li&gt;headers/* (your header)&lt;/li&gt;
&lt;li&gt;platform.ini&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="files-in.gitignore"&gt;Files in &lt;code&gt;.gitignore&lt;/code&gt;&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;.pio (excluding all the cached libraries and board files)&lt;/li&gt;
&lt;li&gt;.vscode/c_cpp_properties.json (cache over all C artifacts)&lt;/li&gt;
&lt;li&gt;.vscode/launch.json (hardcoded to local directory by default)&lt;/li&gt;
&lt;/ul&gt;
</content:encoded>
		</item>
		<item>
			<title>First Post</title>
			<link>http://tthiery.github.io/posts/2019/01/23/first-post</link>
			<description>&lt;p&gt;This is my first post!&lt;/p&gt;</description>
			<guid>http://tthiery.github.io/posts/2019/01/23/first-post</guid>
			<pubDate>Wed, 23 Jan 2019 00:00:00 GMT</pubDate>
			<content:encoded>&lt;p&gt;This is my first post!&lt;/p&gt;
&lt;script src="https://gist.github.com/tthiery/2426b191135b4403c5f305727366cecf.js?file=Bar.cs"&gt;&lt;/script&gt;
</content:encoded>
		</item>
	</channel>
</rss>