The new home page has just gone up
http://rx.codeplex.com/
Scott Hanselman himself is plugging it
http://www.hanselman.com/blog/ReactiveExtensionsRxIsNowOpenSource.aspx
And we even get a mention for the IntroToRx.com site (Yay!)
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.
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.
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:
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
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.
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!