Stefano Tommesani

The CEB's Commercial Insight is based on three pillars:

1. Be credible/relevant – Demonstrate an understanding of the customer’s world, substantiating claims with real-world evidence.
2. Be frame-breaking – Disrupt the customer’s current logic, revealing an underappreciated aspect of the customer’s environment or a flawed assumption.
3. Lead back to your unique strengths – Refer customers specifically to areas where you outperform competitors

Points #2 and #3 are critical to avoid the commoditization of solutions, the worst scenario for suppliers, as the buyers are satisfied with a limited set of functionalities shared among several products of competing companies and trigger a price-based war. The CEB research shows that most times suppliers are asked for a proposal when the internal process is around 57%, usually very close to an official RFP, where the the project already has shaped up and it is increasingly difficult to steer it to the strong, distinguishing features of the product.

If you think this is bad, think of all the projects that are not even reaching 57% as the average 5.4 subjects involved in the purchasing decision are not agreeing and moving the project forward:

In the "2016 .NET Community Report" just released by Telerik, the answers to the question "What technology would you choose if building for Windows Desktop?" were as follows:

So roughly half of new desktop developments would be based on Windows Forms, a technology declared dead multiple times. The Telerik report states: 

This is somewhat surprising when you consider Windows Forms is under maintenance mode,with no new features being added. For larger organizations, which may havelonger iteration cycles or legacy OS requirements, Windows Forms remains aviable platform for building desktop applications.

It is not easy to monitor how our code behaves on a vast array of different machines. A myriad of different configurations can lead to errors that are difficult to reproduce and even more difficult to anticipate. And when the customer calls complaining about a crash, provided information on what lead to the problem is often incomplete or misleading. Fortunately, remote telemetry of software applications is here to help and is going mainstream even in the desktop area. Let's see how easy it is to monitor a desktop Windows application using the new Azure Application Insights service: this article on the Azure site explains all the necessary steps. Summing up, here is what we need to do:

1. create an Application Insights resource in the Azure portal
2. make a copy of the Instrumentation key, as we will need it later in our app
3. add one of the following NuGet packages: Microsoft.ApplicationInsights.WindowsServer for the full set of functionalities, including performance counter collection and dependency monitoring, or Microsoft.ApplicationInsights that includes the core API only
4. initialize the TelemetryClient object in your app
5. set the intrumentation key in the code of the app: TelemetryConfiguration.Active.InstrumentationKey = " your key ";
6. insert telemetry calls, like TrackPageView, TrackException etc.

For additional reference on these steps, check out the official ApplicationInsights repository on GitHub.

The AltaLux plugin for IrfanView is now open-source (here is the GitHub link) and it is worth analyzing the different methods used for parallelizing the computational kernel. The filter factory, contained in the CAltaLuxFilterFactory files, can create one of four possible instance types (actually there's a fifth one that you will never want to use, as we will see later). Most of the plumbing code is hosted in a base abstract class, named CBaseAltaLuxFilter, and there are four specific classes that implement the virtual Run method in different ways:

1. CSerialAltaLuxFilter
2. CParallelSplitLoopAltaLuxFilter
3. CParallelEventAltaLuxFilter
4. CParallelActiveWaitAltaLuxFilter

Let's start with the first one, the serial implementation, to have an idea of how the code works. Here is the whole Run method:

Dependency Injection (DI) and Inversion of Control (IoC) are popular patterns in modern software development that reduce coupling among modules and so improve the testability of the sames. As this article is not meant to be an introduction to DI / IoC, please refer to numerous introductory articles on the net before tackling this topic, as we will delve straight into the implementation's details. For these samples, we will use Castle Windsor as IoC container, and we will build the same sample three times, highlighting the differences in handling permanent and transient class instances with an IoC container. The aim is creating an implementation that has minimal coupling and is highly testable. 

Let's start by drawing the scenario: our simple app uses the IoC container for cross-cutting concerns, in this example only logging but in a real app there could be a lot more functionalities of this kind. e.g. data model access, telemetry and so on. The logging framework is a singleton that spans the whole life of the app, so once we register the interface in the IoC container, and let the container inject the instance into the objects that use it, we are golden. But temporary objects, like a child window, are created and then destroyed when needed, so the same instance cannot span the whole life of the app. At the same time, these temporary objects need to access the functionalities such as logging, so those instances must be injected into the freshly created object.

Let's start with the first implementation to see some real code (before proceeding, download the whole solution from GitHub). The project ManualIoC contains a poor man's implementation of DI, as we have to manually pass the instances to the transient objects. First, let's start with the main program, where we initialize the IoC container:

static void Main()
        {
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);
 
            // create IoC container
            IWindsorContainer container = CastleContainer.Instance;            
            container.Register(Component.For<ILogger>().ImplementedBy<ConsoleLogger>());            
            container.Register(Component.For<MainForm>());            
 
            //Application.Run(new MainForm());
            MainForm mainForm = container.Resolve<MainForm>();
            Application.Run(mainForm);
 
            container.Dispose();            
        }

There are several changes compared to a stock WinForms application: before creating the main form of the app, we create the IoC container, and we register the implementation of the ILogger service, and the MainForm class. Instead of creating directly the MainForm like it happens with the standard WinForms code, we ask the IoC container to resolve, that is returning an instance of the given class, the MainForm and then we run the application. The critical bit is that MainForm requires an ILogger instance in the constructor, and the IoC container knows about it, so it transparently creates a singleton for the ILogger interface using the ConsoleLogger implementation and passes it to the constructor of MainForm, without requiring any intervention from our side. With a simple demo it is hard to understand how an IoC controller can simplify a real project, but assume that there is not just one cross-cutting functionality like logging in the example, but many more and you will understand how the code gets clearer and simpler. Also, rewiring the app to use a different logging framework requires just creating a new implementation of the ILogger interface that uses the new framework, and changing just the registration of the ILogger interface in this bit of code.