In a previous post, I looked at how Rx can be used to neatly track the status of service dependencies. In this post, I’ll look at how the same technique can be used to manage streams that update with a varying frequency, and a specific application – tracking market data staleness in financial applications.
When integrating independent services to build larger systems, it’s often important for services to keep track of the status of the other services that they depend on. Especially for a microservices approach, where services should expect their dependencies can be absent at any point in time. Services that cope with dependencies being unavailable make a less flaky and more resilient, hands off system.
Services can dynamically change their behaviour as the states of their dependencies change. If a dependency is offline, a service can decide to re-route work, buffer it until processing can resume, or explicitly reject requests. Doing this proactively by reacting to changes in dependencies’ statuses makes this much more fluid.
This post will look at a simple way of using Reactive Extensions to keep track of dependency status.
A while back I found the GCHQ Director’s Christmas card, which came in the form of a nonogram. GCHQ has a history of puzzle setting and even hiring people through puzzles. The WWII codebreakers were hired through crosswords and other puzzles in the newspaper, which was featured in The Imitation Game.
I was new to nonograms, but quickly found out they’re a “paint by numbers” puzzle where hints for rows and columns give you series of segments (of varying lengths) to colour in. Applying all the clues together logically lets you work out whether each cell is filled in or empty progressively until you reach the final solution.
Typically you then have a badly pixelated picture of something and a sense of accomplishment. With GCHQ’s puzzle, you end up with a QR code that leads you to the next puzzle. So the picture is not very pretty and the sense of accomplishment is short lived. Here’s what GCHQ’s best Christmas wishes look like:
And I thought I was bad at Christmas cards.
I recently ran a workshop on Rx, and as part of preparing I had to hunt down some useful resources for learning. I found that things had come a long way since the early days, when people mostly learned from videos of Wes Dyer, Jeff van Gogh and Bart de Smet drawing on whiteboards at Microsoft, and Lee Campbell’s blog.
Since the initial .Net release, a lot has changed for Rx – it’s become open source, and it’s now available for many platforms: .Net, Java, Javascript, plus quite a few more. It’s also being used and talked about by some big players outside Microsoft, like NetFlix (who are responsible for the RxJava port).
With all this new exposure, there are now a lot more resources for learning Rx. Here are some that I think are particularly useful.
StackOverflow, like Wikipedia, is a dangerous place. It’s a place where you go to learn something you didn’t know you wanted to learn. In both cases, the risk is: are you going to resurface, half an hour later, much the wiser on the French Revolution, or perhaps some nitty gritty feature of the Garbage Collector? Or are you going to come out with an enhanced knowledge of the manufacturing technique used to create left handed drinking straws in the early 20th century (and the life of the mother of the creator, and the university they went to, and the wartime history of the town they grew up in)?
So it was a lucky happening that I bumped into a thread on StackOverflow a while back regarding how Math.Pow is implemented in the .Net framework. It’s one of these methods which leave you cold when you navigate to their implementation with Resharper/dotPeek – because it’s just a stub with a MethodImplOptions.InternalCall attribute on it. It’s basically a marker saying “this code is implemented with magic”.
But, as Eric Lippert says – there is no magic. Magic is just a place holder for a deeper understanding, in the same way as MethodImplOptions.InternalCall is a place holder for a lower level implementation.
The post leads on to a discussion of how methods marked with MethodImplOptions.InternalCall are actually implemented, where the implementation is, and how the jitter can even substitute some functions directly with a single machine code instruction.
In the post you can see the Sin, Cos, Sqrt, Round functions are eligible to be implemented as a direct machine code instruction. As Hans points out, this can lead to C# floating point code that’s actually faster than the same code in C++ that uses library functions.
So on this case, I managed to escape from StackOverflow intact, and with an increased knowledge of MethodImpl.InternalCall, which is something I had been curious about for over 10 years.
The Reactive Extensions (Rx) library is one of those tools that opens up your mind to new ways of thinking about your how your data and application work together. In this post I’m going to talk about an easy technique you can use to replay time series data as if it were live.
Schedulers in Rx are a deep subject, but one of the things schedulers are responsible for is managing how time based operations run. All time based operations in Rx, like Timeout, Delay, etc allow you to provide your own scheduler.
HistoricalScheduler inherits from VirtualTimeScheduler, and that name gives us an idea what we can do with it. VirtualTimeScheduler gives us control of time – at least as far as our code goes. You can’t go back in time and buy stocks to become rich, but you can make your code think it’s doing that.
I had the opportunity to run a workshop on the Reactive Extensions library with the Sydney Women Who Code group earlier this year. Rx is something I’m passionate about – it really has the power to change the way you approach your data and application design to open up a lot of possibilities.
This post gives some details about the workshop, but is mostly about the process of creating it and some insights into how it went. The workshop and code are on github if you want to check it out.
Code and a glass of wine 