The initiative that will probably shake the entire Capital Markets Industry...

A new Open Source foundation will probably change the face of the entire Capital Markets industry IT working model (sourcing, costs, time to market...). Its name? The Lodestone foundation.

Extract: 

The foundation will focus on delivering shared implementations of core services that Banks find themselves implementing time and time again. For example the foundation could deliver enterprise grade reference data platforms, market data platforms, OMSs, algorithm containers, trade repositories, grids for risk, pricing, etc. Some of those services could even be offered as a shared infrastructure, on the cloud.

The idea: to reverse the trend of innovation within the banking industry, by attracting some of the top  worldwide class experts you can find in technology today in an open source foundation dedicated to work on common financial blocks, and sponsored by some of the major actors of the Capital Market industry.

I bet that once the first tier-one sponsors names will be published, it will motivate lots of other financial actors (in order to have the opportunity to influence and participate with the foundation workgroups).

Check yourself the concepts with the nice sliderocket introduction of the Lodestone foundation during the latest Euromoney conference in London, and the Lodestone foundation web site (beta version).

Thanks to my friend Olivier, for having shared with me this amazing initiative.

Answers and thoughts about the Windows 8 Metro style Applications

I just come back from 2 days of MS tech days in Paris, and I would like to publish what I've heard & understood related to the Windows 8 / WinRT topic.

In fact, nothing is really new since the latest "build" conference in California, since it seems that the MS guys in France are STRICTLY TIGHT to respect the drastical and confidential planning imposed by Steven Sinofsky (head of Windows team).

Anyway, here is a recap of the previous episodes, and some answers to questions related.

Previously on Windows

WPF was proposing developers to reinvent the UI application experience with the power of declarative programming (the advent of XAML), rich composition, customization and GPU boost. At the end of the day, it’s a fact that very few developers have leveraged this option. Indeed, most of us continued to build old-fashion-style-full-of-data-grids applications requested by our users (or what we thought) with this technology that wasn’t fit for that (don’t even get me started with WPF DataGrids performances ;-)

Now what?

With the new Windows 8 to come, developers may be able to develop two different types of applications: Metro style Apps, and Desktop Apps.

• Desktop Apps are the classical ones (.NET, Silverlight, Win32 or web 2.0 ones), fortunately still supported by Windows 8.
• Metro style Apps are the new way of doing applications for Windows 8. This new way relies on a methodology and on the new windows Runtime (a.k.a. WinRT). We can summarize the “Metro” style in 4 recommendations:

1. Provide a full screen experience tailored to your users’ needs: no more chromed frames around your app since the technical plumbing should be definitively hidden
2. Align your content within the screen: it’s clearer for humans
3. Don’t use 50 different colors or {font|image} sizes within your application. The size of the elements should be used to drive the user's focus accordingly
4. The user experience SHOULD BE fast and fluid. The widgets should always dynamically but subtly inform us that something is going to happen, and every code-behind that take more than 15 milliseconds should be executed asynchronously

Whereas WPF came with recommendations only, the new “Metro” style application for Windows 8 aims now to regulate developers more strictly. The idea here is to force them to fall into the pit of success (Windows team version ;-)  Without other choices (in the case you want to leverage on the new windows runtime WinRT, instead of continuing to build classical Desktop Apps).

Looking at the Metro Apps demos, I had the feeling that the pit of success won't be easy to reach, even with more control achieved by the development ecosystem (whether at build or run time). Indeed, a lame interpretation of the metro style may be an application with tons of pages to slide (it'll worth to have a touch device in that case ;-).

I definitively think that the adoption of the Metro style guidelines and constraints won't save us to rely on real ergonomy specialists & BAs in order to provide relevant tailored experiences for our users (message for IT managers ;-).

Q&A

Is every Metro style Applications forced to be released on the MS market place? Even my enterprise private applications?

Yes ;-( as it is done with the Apple Store. It may change, but there is today only one public store to release Metro style applications.

It took me time to learn the WPF way (XAML, M-V-VM pattern, etc). Is all my knowledge lost?

Nope. If you look at the Windows 8 Platform and Tools diagram below, you can see that XAML is still the declarative language for UI (whether you develop your code behind in C++, C# or VB.NET). WinRT aims to provide a better and more performant XAML based engine for our UIs.

I heard that HTML5 was the first-citizen language for building Metro style applications. Is it correct?

Nope. It is a fact that HTML5 (with JavaScript as Code behind language) makes the buzz and is currently mostly implemented today. But MS claims during those tech days 2012 that WinRT will be fair and provide the same capabilities to the 3 existing citizens: XAML-C++, XAML-C# and HTML5-Javascript. In fact, all WinRT APIs are natives and according to the MS guys, WinRT is like a “modern COM”.

Is .NET dead?

Nope. .NET will be still supported by Windows 8 for Desktop Apps or Server Apps. And if you decided to build Metro style applications, you will still be able to develop them in C# (instead of HTML5 or C++). In fact, you’d rather use C# as language for your Metro style applications if you want to ease the “every code-behind that take more than 15 milliseconds should be executed asynchronously” recommendation via the amazing async-await C# language extension (not available in C++).

For the record, the .NET framework is partially loaded when running a Metro style application developed in C#. I said partially, since some APIs are filtered/prohibited within a Metro style context. Whether at build or run time (e.g. no MessageBox is allowed for instance; the compilers will raise errors if you try, whether in C# or C++).

Anyway, I'm looking forward to see the next Windows 8 user preview (end of February).

Low latency framework: the must read presentation of Richard Croucher

I've just read a very informative document written by Richard Croucher about how to build low latency systems. One of the best paper I've ever read on my favorite topic (very synthetic and clear).

It's available here.

The scientific wisdom of Martin Thompson

I really like the concept of Mechanical Sympathy (Hardware and software working together in harmony) pushed by Martin Thompson. Saying it quickly: you can't design very performant systems by simply relying on abstractions (that surround us in IT todays) and if you ignore the details of how TODAY's underlying things work.

Note: underlying things stands here both for software-level stuffs (java/.NET GC, native memory allocators, OS, ...), and hardware-level ones (today's CPU, memory cache lines, and kernell-passing network for instance).

But when I attended one of his session at the A-Team low latency summit in London last monday, I was even more enthousiast with one particular point he made during 3-4 minutes. That was something like:

Adopt a scientific and rational approach. Make a guess if you want, BUT confirm it by some real and serious experimentation. For instance: everybody told you that functional programming is the best option to make high performant and scalable systems? Test it by yourself, make the experience and measure it concretely. You will discover -like me- that all those memory copies (to ensure message passing immutability) have a cost. Ok, this cost should be acceptable for some scenarii, but you will be blocked at some point if you push further your objectives regarding performances. Don't listen what (most of the) people say: Test and measure by yourself! This is how we discovered what led us-after- to the Disruptor pattern.

I fully agree. Sometimes IT deals more with religion and dogma than concrete objectives and facts. You find some guys that blindly repeat (silly) statements that you can find on the street: "there is no such language for performance than this one", "there is no such platform/middleware than the...", "we should use this tool cause everybody...", etc. 

Since this mouton de Panurge effect is not limited to the pure IT ayatollahs and may also affect all of us in some tiredness-distraction moments, I find the advise and the approach promoted by Martin Thompson very healthy.

Ok then: it's time to experiment and measure things more frequently in order to make our IT architectures and assertions more factual!

About WinRT and .NET in Windows 8

A very informative post of Sasha Goldshtein here.

As a bonus here: a diagram of the Windows 8 platform layers per application type.

Has Microsoft initiated its own Nokia-ization?

Some MS officials, by recently saying that Windows 8 apps will be created in HTML5 and JavaScript and by deciding not to mention anything about .NET and Silverlight have fostered speculation and have introduced some confusion and chaos (see here, here, but mostly here).

Here is my thought about this Jupiter/windows 8 buzz/fiasco:

1. XAML is not dead: even if the future of WPF seems highly compromised by the advent of Jupiter & windows 8, I think that the pattern of its declarative langage is not dead. The Windows team and their IE peers certainly want to kill Silverlight or WPF for different reasons, but Jupiter seems more like a "Next Generation" XAML-based framework, than a uniquely dedicated and optimized for HTML 5/Javascript UI platform. In that context, I found also very interesting to notice that the XAML team has recently joined the Windows one.
2. .NET is not dead either: While it seems now realistic that the Windows 8 team will provide an alternative to WPF or Silverlight (with the help of their IE classmates, and surfing on the HTML5 wave), I don't buy the option where the Windows team may be confident enough to initiate the dismantling of the .NET platform (I wish them good luck if they want to offer an alternative to the entire .NET ecosystem built ​since 2002 ;-)
3. But it's really time to adopt an SOA model for our desktop applications: The volatility of MS UI technologies is so important than we definitively have to avoid from putting all eggs in one (fragile) basket. Here is my advice for desktop applications: wherever it is possible, avoid from embedding business layers whithin them and limit them to consume services instead (whether web/WCF, or through a MOM). The responsibility of our rich desktop applications should only to provide the information in a nice, efficient and ergonomic way (which is all but simple). Note that I'm not talking about web app here (maybe within another post?).
4. It seems now wise to wait the "Build Conference" in September, in order to have concrete and reliable information on this subject (and not rumors or blog noises)

Anyway, the future don't looks bright for MS with its internal wars/clans (Windows team vs Dev team) and the lack of legibility of its strategy (Silverlight? WPF?).

Microsoft sorely lacking a leader able to provide a vision and to bring every team into line. They definitively need a leader. Moreover, they probably need a designer at the head of their organization. Someone that will try to change people's lifes -whether for good or bad reasons-like Steve Jobs with Apple.

Otherwise it could be the beginnings of a (long) Nokia-ization for the Redmond giant...What a pity!

About Rx performances

James Miles recently shared some performance figures and explanations related to the latest Rx Performance Improvements.

With this latest v1.0 stable release, Rx seems to enter in a new era. It's a very good news for .NET developers...

Continuous delivery at Facebook

Chuck Rossi is explaining in a video how the Release management is handled at Facebook; it allows them to push daily updates to their site without production outage or service interruption.  This video is very informative and the announced KPIs are very impressive...

watch the video here

While we are talking about release management, I also highly recommand you to dig into the "continuous delivery" book and blogs of Jez Humble and Dave Farley.

Release management is definitively not only about process and tools; it is about changing our culture.

Handle your technical debt with SQALE!

You should try SQALE; a generic, language and tools independent method for assessing the quality of source code.

In a nutshell, SQALE aims to manage the Technical debt within your projects; its classification allows you to analyze the impact of the debt and to define the priority of code refactoring/remediation activities. SQALE is also pragmatic and result-oriented: it is a requirement model and not a set of best practices to implement. Based on this requirement model, SQALE will also allow you to produce ratings for all your projects (from A to E).

Even if SQALE is tool independent, the method target for an automated implementation and you can already find some existing concrete solutions (see the SQALE plugin for SONAR for instance).

You should definitively have a look on SQALE.

'REWORK': a must read by the founders of 37signals

'Meetings are toxic', 'Don't be a hero', 'Fire the workaholics', 'Interruption is the enemy of productivity', 'Build an audience', 'Good enough is fine', 'Go to sleep', 'Pick a fight', 'Planning is guessing' ... are some of the topics explained within the 37signals founders work manifesto.

This irreverent, but very concrete and clever book is definitely a must read.
It tastes like 'The Pragmatic Programmer' manifesto, but applied to the company level.

• http://www.amazon.com/Rework-Jason-Fried/dp/0307463745
• http://37signals.com/rework/

Write performant code: keep some fundamental figures in mind

It's funny to see the amount of time spent (i would say lost) by some developers to optimize their code in some location... where the ROI will be peanuts at the end of the day ;-(

Worse: premature optimizations. The real ones, I mean (I heard you Joe, and I agree ;-). The ones where  peoples sacrify readability and evolutivity to the hostel of performance (really? did you measured it concretely?). In most cases, a simple but wise choice of relevant types and datastructures within our code save us lots of time and energy without creating maintenability nightmares.

If you want to develop low latency and scalable solutions, it is obvious that you should know the core mechanisms of your platform (.Net, Java, C++, windows, linux, but also processors,  RAM, network stacks and adapters...). How the GC works, how the memory and proc cache lines are synchronized, etc.

But do you have in mind the cost of some elementary operations (in term of time and CPU cycles) when you are coding? How long it takes to make a classic network hop? How long it takes to make a typical I/O read? How long to access the memory depending on its current state?

As a reminder, here is some figures (some are borrowed to Joe Duffy's blog) that you should definitely post-it in front of your development desktop. If you don't want to improve your code blindly, it's important to know what things cost.

• a register read/write (nanoseconds, single-digit cycles)
• a cache hit (nanoseconds, tens of cycles)
• a cache miss to main memory (nanoseconds, hundreds of cycles)
• a disk access including page faults (micro- or milliseconds, millions of cycles)
• a local network hop with kernel-bypassing RDMA & 10GigEth (sub 10 microseconds)
• a LAN network hop (100-500 microseconds)
• a WAN network roundtrip (milliseconds or seconds, many millions of cycles)

The ultimate MOM?

I've never had faith in silver bullets ;-) but I have to admit that Solace (appliance-based) solution is very attractive for a pre-trade (but also post-trade) financial entreprise messaging system.

Pros

Because Solace use silicon instead of software for their "hub and spoke" oriented messaging solution (fully compliant with JMS standard, but with much more features) , there is no OS interrupts, context switching nor data copies between kernel and user space for the "hub" part.

I still didn't had the chance to evaluate it, but on the paper and according to some of my ex-colleagues that had made evaluations,  Solace looks like a kind of ultimate solution for financial entreprise messaging system.

"Reliable delivery with average latency of 22 microseconds at 1M msgs/sec", "Guaranteed delivery with average latency of 98 microseconds at 150,000 msgs/sec",  "10 million topics with support for multi-level, wild carded topics", "9,000 client connections"... (http://www.solacesystems.com/docs/solace_corporate-intro.pdf). Such figures make me dream and remind us that software can't win over hardware for those message-oriented middleware (MOM) use cases...

Their several white papers are very relevants and informatives. In particular, the one that explain how to build a single dealer platform 

(meaning: a web oriented application produced by an investment banking in order to allow all its clients to directly cope/deal with it). Oh Yes, because the future version of their appliance will also allow to bridge with http clients (one more killer feature ;-)

This particular white paper is available from here: http://www.solacesystems.com/solutions/financial-services/single-dealer-platform

Cons
More than the (high) price of such a solution, and even if it is increasingly used in some banks, perhaps risks regarding the sustainability of such hardware-based solutions that has to be lifted.

Indeed, what would happen if their (unique?) appliance production factory get burnt? how long would it take to Solace to replace this mass production to fulfill contracts, etc.?