(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
public static class AwaitExtensions | |
{ | |
/// <summary> | |
/// Provides await functionality for ordinary <see cref="WaitHandle"/>s. | |
/// </summary> | |
/// <param name="handle">The handle to wait on.</param> | |
/// <returns>The awaiter.</returns> | |
public static TaskAwaiter GetAwaiter(this WaitHandle handle) | |
{ | |
Contract.Requires<ArgumentNullException>(handle != null); |
public static IObservable<T> Conflate<T>(this IObservable<T> source, TimeSpan minimumUpdatePeriod, IScheduler scheduler) | |
{ | |
return Observable.Create<T>(observer => | |
{ | |
// indicate when the last update was published | |
var lastUpdateTime = DateTimeOffset.MinValue; | |
// indicate if an update is currently scheduled | |
var updateScheduled = new MultipleAssignmentDisposable(); | |
// indicate if completion has been requested (we can't complete immediatly if an update is in flight) | |
var completionRequested = false; |
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
error_page 500 /500.html; | |
location /500.html{ | |
return 500 '{"error": {"status_code": 500,"status": "Internal Server Error"}}'; | |
} | |
error_page 502 /502.html; | |
location /502.html{ | |
return 502 '{"error": {"status_code": 502,"status": "Bad Gateway"}}'; | |
} |
################################################################## | |
### The following parameters are provided by Octopus Deploy. ### | |
### Uncomment these with default values for testing. ### | |
################################################################# | |
#$SSRSReportServerUrl = "http://ssrs/reportserver/reportservice2005.asmx" | |
#$SSRSDynamicDataSourceCredentialsUsername = "" | |
#$SSRSDynamicDataSourceCredentialsPassword = "" | |
#$SSRSReportFolder = "Project Folder" | |
#$SSRSSharedDataSourcePath = "/Data Sources/dsShared" |
using System; | |
using System.Collections.Concurrent; | |
using System.Fabric.Replication; | |
using System.Reflection; | |
using System.Reflection.Emit; | |
using Microsoft.ServiceFabric.Data; | |
internal static class TransactionExtensions | |
{ |
JSON Schema is a versatile tool for defining the structure of JSON data and ensuring its validation. However, as powerful as it is, complex scenarios can sometimes lead to paradoxical constraints, especially when used in combination with code generation tools. In this article, we'll take an in-depth look at one such paradox that emerged while defining message structures for various protocols and discuss a practical solution.
Imagine a system where messages are passed using different protocols, such as AMQP, HTTP, MQTT, Kafka, and CloudEvents. Each protocol has a distinct message structure but shares certain common attributes. These shared attributes are consolidated in a base message definition, called definition
in our JSON Schema.