Cloud computing, Economic intelligence & Patriot act

Recently discussing with some colleagues, I realized that very few of us know the risks of National Economic Intelligence related to the usage of public cloud solutions provided by US companies.

Indeed, the Patriot Act, enacted in 2001 in US, gives full powers to the United States in investigating. Thus, any U.S undertaking must provide "sensitive data" required by the Federal government (NSA for instance), and that, whatever the place where they are stored. 

Worst: all of that may be done without notifying it to the authorities of the country or the company that has been investigated.


My point here is not to make us fall in a fully paranoid mode. But I think it is important to have these risks in mind when we advise our companies to move towards any public cloud solution (mostly provided by american companies: Amazon, google, Microsoft, etc.).

Of course, public cloud solutions are still valuable for most of the companies and data. But for other companies with crucial and highly competitive advantages, it's important to think it twice before moving into such public cloud solutions...

In a nutshell: public cloud not for everyone, not for every kind of data.

Some posts or newspapers articles about it:

• Defense giant ditches Microsoft's cloud citing Patriot Act fears (zdnet)
• The Patriot Act and Your Data: Should You Ask Cloud Providers About Protection? (cio.com)
• Snowden link to encrypted email service closes

and in french:

• Patriot Act : vos données lui appartiennent (from my friend Stephane Bellec @01net.com)
• USA Patriot Act : un risque majeur pour la confidentialité des données dans le Cloud (lemonde.fr)

Last update: August 18th, 2013

wiked! the solution to DRY all our projects KM

Since my latest post: It's really time to DRY our apps' Knowledge Management! I had the occasion to share this topic with several mates, and thus to discover that the maven site plugin was perfectly fine for what I intended to do (thanks to Christophe LALLEMENT & Alexandre NAVARRO by the way).

Thus, no need to reinvent the wheel for that (which is perfect fine for me).

So I started to play with maven (quite new for the .NET expert I am), and especially with the maven site plugin ecosystem. At the end, it took me several hours in order to fully understand how to use it properly. With some questions like:

• Which maven plugins (and versions) should I configure within the pom.xml I intend to use in order to generate the web site for my project (which is not a java project by the way)?
• Which minimal pom.xml could I set in order to generate a web site with the mvn site command-line (important for non-java project, and to KISS)
• Where should I put images and other resources in order to be able to reference them properly from my markdown pages
• Why and when should I have to call `mvn clean` before the `mvn site` command-line in some rare cases (like when changing the project name whithin the pom.xml file)
• How to set a better look n feel to the overall generated web site?
• Which markdown syntax was working, and which one was not well supported by the tools (i.e. the atx-style headers)?
• etc.

I finally intended to package something that would help me (and others) to quickly setup such web site generation solution for every new project Knowledge Management.

Thus, i'm proud to present you the wiked! solution,  now available on gitHub.

More than a simple bootstrapper that will ease you to earn some time when setup-ing such a solution for your project, wiked! also offers you a structure and some content for all your projects web sites (see the values and practices section for instance).

And since the DRY principle was one of my driver, I won't fully describe here what wiked! is all about. If you are interested, you can have a look at the wiked! ReadME.md

Hope this help.

It's really time to DRY our apps' Knowledge Management!

While I was reading the amazing Pragmatic Programmer manifesto, several years ago from now, I really enjoyed the "Keep Knowledge in Plain Text" principle (tip 20).

Unfortunately, I never really took the time to apply this principle seriously for the Knowledge Management (KM) of the various projects on which I worked. Every time, I lazily put all the team/application related informations whether in a wiki, or as MS Office documents stored on a Sharepoint... (sad panda ;-)


Last time, while I was having a lunch with a colleague of mine (a well-known and passionate french craftsman), I realized how lazy I was so far regarding this KM topic. With 2 or 3 words only (read-only wiki, Markdown documentation, SCM), Cyrille starry-eyed the dormant craftsman in me.

Indeed, since:

• wiki web sites for DEV teams usually finishes badly (e.g.: lots of different wikis/sections for the same component/teams, no proper knowledge of what is still relevant and what is deprecated, structure mess, etc)
• documentation created separately from code or components is less likely to be correct and up to date
• it’s not easy to compare/diff MS Office documents
• it’s important for every piece of knowledge to have a single, unambiguous, authoritative representation within a system (DRY principle)
• the text documentation has becoming more important than ever since the advent of the blue book (to express the ubiquitous language of our projects, to clarify some large-scale design intents, etc)

It would be a good idea for us to find a way to get rid of traditional team wiki site, and instead to write every documentation in:

• text files written in Markdown format (we may benefit from any Markdown existing tool/editors)
• stored within the SCM of our project (e.g.: SVN, git)
• and to make our Software Factory (re)generate a static web site (like a read-only wiki) every time we changed those Markdown text files from within our SCM. 

As benefits, our team/application documentation will:

• always be up-to-date and versioned
• easily diff-able (text files with Markdown format)
• respect the dry principle (with our SCM as its golden source)
• easily browsable by everyone in a readonly but readable wiki-like web site (DEV, QA, Support teams, …)
• easily modifiable by team members in a well know and official location (as easy as creating/modifying a text file in a SCM)

Of course, the idea here would be not to reinvent the wheel, but to reuse any existing Markdown renderer & static web site generators instead (the step beyond the github Readme.md file). But if I can’t find something and make it out quickly, I would probably initiate an open source project to implement such system.

Cyrille was right: it's probably time for us now to kill wikis! and to reinvent them.

Last but not least: a very interesting post of Cyrille about Collaborative Artifacts as Code.



BREAKING NEWS: I found a solution for my use cases, described here.

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.