Sunday, July 1, 2012

Introduction to Rx on Amazon


We finally got the book published on Amazon in Kindle format. So if you use Kindle and want that quick & easy way to get offline content in your hands, then this is for you. If you don't own a kindle, you can still read the book offline with Kindle for PC/Mac/iOs/Android.

Sorry about the 99c (77p) price tag, but I couldn't find a way to get it up there for free, while keeping the agreement non-exclusive.

Introduction to Rx @ Amazon.com

Introduction to Rx @ Amazon.co.uk

It should also be available on the other Amazon sites.

The completely free version is available for manual download at www.IntroToRx.com

Thursday, June 21, 2012

Rx v2.0 release candidate is available

Last night at the LDNUG meetup, Bart De Smet gave his presentation on Rx. At the end of the presentation he announced that Rx v2.0 was now officially a release candidate. He then went to go on and release to Nuget in front of the team. You could feel the nerdy excitement in the room.

The release notes can be found on the Rx team blog. The post is huge (~48 printed pages).

Now I have a race to update the Introduction to Rx book to have all the v2 features before they actually release it.

Introduction to Rx online book is available

I am super excited to announce that the book I have been working on is now live at www.IntroToRx.com

I have been working hard over the last 6 months taking the content from the blogs and giving it a good coat of paint to make it a little more professional than my "thought bombs" that I put up on the blog. This is the main reason why this blog has been quiet for the first half of the year. The content from the blog series is 9 chapters/posts, the book however is 17 chapters and has some extra pre/post content too. I cover more (almost all) Rx operators, show you how to think in a functional way to really get Rx working for you, provide more examples and give guidance of best practices.

I still have some small updates from my editor to make, and then I will submit it to Amazon. This means that you should be able to get the offline version straight to your kindle. The book will be free, the website is too, obviously. The content in both is exactly the same so don't feel like there may be little hidden gems that are in one and not the other.

I have already been getting good feedback from the small group that have seen it pre-release, so I hope you find value it too.

Tuesday, May 29, 2012

But it is not our competitive advantage!

The financial industry (Capital Markets specifically) is a fiercely competitive arena of high risk, high return and space age technology. The competition between banks, hedge funds and exchanges leads to a very closed-source style of application development. IT secrets are closely guarded. Non-compete clauses are common place and Non Disclosure Agreements are taken very seriously. Like in other industries, time-to-market and rich feature sets increase the likely hood of an application or platform making profit.

To get the best product delivered in the fastest time, the best of breed developers and consultants are wheeled in and money is generally thrown at the problem. All the same old stuff is built from ground up hidden away from prying eyes to protect any market secret getting out. Features start getting built; Security (Authentication/Authorization/Auditing), Low latency Messaging, Blotters/Grids controls, Concurrency frameworks, Modular UIs, Blotters, Order books, Matching algorithms, Blotters, Pricing engines, Discounting curves, JSON/Fix/ProtoBuf Serializers, Risk Visualizers, Blotters, Search tools, Research tickers and of course we should build a blotter!

It is most certainly the case that all of these things are being done by the direct competitor, by a group of similar people, with similar skill sets, falling into the same problems and building the same bugs. All behind closed doors. All at consultant rates.

Managers and business owners feel the need to carefully guard their babies (the project source code) because it is the sum of the effort and more importantly the money invested in the project. To let it out in to the public would be (in their minds) the same as leaving a chest of gold open in a public park or their password to the company bank account on a post-it note. But this is not the case.

Let's enumerate the silly realities of the scenario:

  1. For the consultant to get the job they must exhibit the requisite experience delivering said technology. This means the consultant may be just reproducing their effort. Surely you are hiring the consultant to succeed on their last project right? So to get ahead of the competition you have hired the guy that has finished building their competing product.
  2. Once the consultant has built their part of the product, they either have to document it at huge cost, train the team in how it works, or just leave the project keeping all the knowledge of how it works. They move on to the next project, build another blotter, rinse and repeat.
  3. Consider the need to apply any modifications (improvements or bug fixes) to the code base.  The consultant could be applying their new features to their new version of the feature at competitor X. Your current team of developers could be applying it to your product. Either way, the same general concept is being refined either at twice the necessary cost, or features are being added to one leaving the other behind.

For a concrete example, consider the feature we are talking about is a grid control (commonly called a blotter in finance). Many will argue that the cost of a blotter is just not even enough to warrant even considering. Not true. I have been on 4 projects now where the Blotter or central grid has been the number one development cost. You can argue that we can just buy a control, but those 3rd party controls are lousy. My position is not a case of Not Invented Here mentality; I do advocate 3rd party tools like Rx, Moq, Prism, charting tools, Messaging layers etc...but only when they pay for themselves. Adopting large 3rd party libraries for a single feature or needing competing libraries installed because neither quite fits the requirements needs to be a thing of the past. I have worked with amazing developers that get pulled off otherwise critical work to help work on the blotter. With all that money that is poured into the blotter, we had better keep that blotter source code a trade secret! or should we.....?

But it is not our competitive advantage!

None of the four projects I worked on wanted to be defined by their blotter; they wanted to be defined by

  • Speed of user input
  • Quality of context sensitive research
  • Timeliness of data
  • User experience
  • Competitive prices
  • Depth of research data
  • Breadth of data across assets
  • Liquidity

So now considering that a blotter is not your competitive advantage and you as a manager were brave, and smart enough, to split your code base into code that is not sensitive and code that contains actual trade secrets. Now when that super expensive consultant builds that blotter for you, it may already be half built because it was open source in the first place. Consider when the consultant leaves and re implements that at the competitor, they may find bugs and fix them. Great! You just got that hugely expensive consultant to upgrade your product for free! Sure the competitor got the fix too, but you have tighter spreads, right? Lower latency, right? Better customer service, right? Why pour money into another blotter, another concurrent collection library, another export to Excel feature, another login system, another drag-n-drop feature? Spend your money on your competitive advantage.

Leaders in the field are coming together now to banish this kind of wasteful behaviour. The Lodestone Foundation is looking to open source much of what is burning a hole in capital market IT budgets around the world. They have a sort of rough road map of features and areas that they want to address. This is not a silver bullet but it is a huge step in the right direction. With people like Martin Thompson involved, it is likely to get traction at least with lowly developers. Martin has already proved that you can open-source key parts of the system while still keeping trade secrets and remaining competitive.

Microsoft, lead by Herb Sutter, is pushing for the same kind of collaboration in the C++ space. Projects like Casablanca are aiming to reduce the same wasteful practices in the C++ world by providing portable libraries for general consumption.

From what I understand (via rumours mainly), the thinking is; if we as an industry can spend less money and time reinventing the same wheel for each project, real effort can be put into valuable technical advancement. The beauty with this is the huge IT budgets the capital market projects have can now effectively fund R&D for the greater good. If all the code produced is Open-Source, well maintained and has a thriving community, all will benefit regardless of industry. Imagine advances in risk analysis simulations being used to help design safer cars, order matching algorithms used to help DNA research, financial time-series predication techniques used in speech recognition software.

I personally have been working on my own (much smaller scale) project that fits in with these ideals. Time will tell if they end up being complementary (I hope they do). Until then, go sew the seed with your manager that if your data-access layer, unit testing framework and logging framework are all open source, why can't your blotter* be too?

*blotter is my bugbear. Use whatever industry agnostic thing your project is building that really is just the same as the competitions as your focal point.

Technorati Tags: ,

Friday, March 23, 2012

Rx v2.0 Beta released

Some good news recently that the Rx team have released the beta of Rx 2.0.

It is a move forward and will leave .NET 3.5, .NET4.0, Silverlight 3 and Silverlight 4.0 behind. For this release the supported platforms are .NET4.5 beta (+ Metro), Silverlight 5 and Windows Phone 7.1.

There is a channel9 video (+1hr) with Bart De Smet explaining the new release. Bart also has a blog post on the release too.

As the underlying platform has moved rather drastically there are some surface/api changes. So some old code may break. The good news is that the Rx team have worked hard to squeeze even more performance out of this release. Part of this is support for async/await pattern (which was in experimental releases already).

I am looking forward to giving it crack. Win8 seems faster, Visual Studio 11 seems faster and now Rx is faster. Happy days!

Tuesday, June 21, 2011

The definitive list of Rx sites

Over at the Rx forums, Eamon_OTuathail has created what seems to be the list of Rx sites. It is a list of Blogs and open source projects.
Great stuff. This should save a lot of time for a lot of people.
http://social.msdn.microsoft.com/Forums/en-US/rx/thread/2cbd3b1c-d535-46ba-a9cf-3cd576a8e7c2
Humbled to make the grade.

EDIT: Hopefully www.IntroToRx.com will also make the grade. It is the online book that evolved from the blog series.

Saturday, June 18, 2011

Isolating custom Library dependencies versions from consumer dependency versions

This post is more about the CLR and dependency management than it is about Rx. However at this point in Rx’s lifecycle it seems relevant to comment on. The same principles could obviously be applied to open source projects et. al.

I have recently heard of an interesting situation that no-doubt has proved troublesome to people before. This problem is particularly interesting with Rx and it’s recent rate of versions. If you are trying to incorporate Rx into a library of yours and you then want to publish that library, you are effectively forcing users to use the same version of Rx that you do. Considering that a version of Rx comes out say every two months and that often there are breaking changes, this can create quite a mess. It is also made more interesting that up until recently they have not specified if a release was experimental or considered stable.

To provide an example to better understand my particular point; imagine you have a library that wraps a messaging platform. You want to avoid the use of Events and APM, and expose things via IObservable<T>. You feel happy that IObservable<T> is exposed natively in .NET 4 so you should not have to expose your implementations of Rx. You do however, want to use Rx as it has features you need and don’t want to (re-)write yourself. Your standard approaches to package/deployment are:

  • deploy the parts of the Rx libraries you use with your code. Users can just put them all into a “lib\MyFramework” folder and reference them.
  • excluded the libraries from your code and set Specific Version = False and hope your code will work with the consumer’s version of Rx
  • use a package management tool like Nuget to publish your package and specify the valid versions of Rx your library will work with.
  • rely on things being in the GAC so you can utilise the side-by-side versioning it provides
  • just try and implement the parts of Rx you want and avoid DLL Hell.

I gave this some thought and I think I have come up with a solution that could help library authors protect themselves. While there is the obvious option of using Nuget as part of your dependency management, this does not solve the problem, it just eases the pain. If the customer wants to use the latest version of Rx and you only support the 3 previous versions, your customer is still in some trouble.

The theory i had was that I can specify the specific version of Rx I want to reference in my library, the problem being that it may be named the same as the client’s referenced version. Depending on where their references were built to, they could overwrite each other. It seemed the solution was to embed the dependency into my library.

This turns out to actually be quite easy. If you have a project in visual studio that references your version of Rx, you have to follow these steps:

  1. Ensure you have a file reference (not a project or a GAC reference) to the dependency, in this case System.Reactive.dll
  2. Set the reference to be Specific Version = True
  3. Set the reference Copy Local = False
  4. Embed the dependency into your library. I created a folder in my project called EmbeddedAssemblies. I “Add Existing…” to this folder, navigate to the dependencies (just System.Reactive.dll in this case), and then choose “Add as Link…
  5. Set the “Build Action” of  the newly added link to Embedded Resource
  6. Ensure that the resource is loaded correctly at run time…

The last part of that list proves to be not too hard. You can hook on to the AppDomain.AssemblyResolve event and load your embedded resource. You can return your embedded dependency by reading the byte stream and creating the assembly from it and then returning that in the event handler

internal static class DependencyResolver
{
  private static int _isSet = 0;

  internal static void Ensure()
  {
    if (Interlocked.CompareExchange(ref _isSet, 1, 0) == 0)
    {
      var thisAssembly = Assembly.GetExecutingAssembly();
      var assemblyName = new AssemblyName(thisAssembly.FullName).Name;
      var embededAssemblyPrefix = assemblyName + ".EmbeddedAssemblies.";

      var myEmbeddedAssemblies =
        Assembly.GetExecutingAssembly().GetManifestResourceNames()
          .Where(name => name.StartsWith(embededAssemblyPrefix))
          .Select(resourceName =>
                    {
                      using (var stream = Assembly.GetExecutingAssembly().GetManifestResourceStream(resourceName))
                      {
                        var assemblyData = new Byte[stream.Length];
                        stream.Read(assemblyData, 0, assemblyData.Length);
                        return Assembly.Load(assemblyData);
                      }
                    })
          .ToDictionary(ass => ass.FullName);

      AppDomain.CurrentDomain.AssemblyResolve += (sender, args) =>
                                                    {
                                                      Assembly assemblyToLoad = null;
                                                      myEmbeddedAssemblies.TryGetValue(args.Name, out assemblyToLoad);
                                                      return assemblyToLoad;
                                                    };
    }
  }
}

You can return null in the event handler to say I don't know how to load this assembly. This allows others to be able to have a go at loading the assembly in the same way.

Next, to ensure that my embedded dependency resolver is called, I opted to make a call to it in the static constructor of the key types in my library. eg

public class SomeProvider
{
  static SomeProvider()
  {
    DependencyResolver.Ensure();
  }

  //other stuff goes here...
}

Have a look at the example code by downloading this zip file

Caveats : This is a thought and the code and concepts are only demo quality. I have not used this in production quality code. I also have not verified that the license allows for this style of packaging.

Further links: