Tag Archives: software

CQRS by example – Introduction

I’m doing some R&D for a future project at work and I’m currently exploring some architectural prototypes. In the last few weeks I explored the CQRS pattern.

CQRS thanks to the separation of the read/query services from the action/command services enables us to do many things.

Continue reading

ALM DOs & DON’Ts – Definition of done

We all have been in this kind of situation: someone in the team states that a feature is done but in reality there is that little thing to figure out and the coding is completed the day after. Why is that? Because every person has a different definition of done inside his mind.
How can we protect a team from this? Simple! With a Definition of Done.


A good definition of done explicits what activities has to be done before declaring that our coding activites are over.
For example:

  • All unit tests are green
  • Coding style and conventions are respected
  • UI respects the specs validated by the Customer.

Every team and every project will create a different definition of done. The very important thing is that you and your team discuss such a definition to remove wrong expectaions about the status of work in progress.

SOLID principles by examples: single responsability

This blog post will explain with simple examples the Singe Responsabily Principle of SOLID agiles principles to better understand how we can improve our daily coding activites. In future post I’ll cover the other four priciples.

The Definition

A class should have only one reason to change.

Defined by Robert C. Martin in his book Agile Software Development, Principles, Patterns, and Practices it is the first of the five SOLID agile principles. What it states is very simple, however achieving that simplicity is not so obvious.

Continue reading

UWP Prism Unit Test

I’m sure we all hear about unit testing, test driven development and so on. These practices are useful and provide a long list of benefit like writing low-coupled and mantainable code to name a few.

We want to write unit test for our UWP Prism application and we’d like, for example, to put our ViewModels under tests to make sure the logic they implement is correct. Unit testing is possible only if we can get rid of all the dependencies in our class under test because we want to run our test every time we want (for exemple when the service library our teammate is writing is not yet finished) and as fast as we can.

Continue reading

Only the code tells the truth

Treat your code like any other composition, such as a poem, an essay, a public
blog, or an important email. Craft what you express carefully, so that it
does what it should and communicates as directly as possible what it is doing;
so that it still communicates your intention when you are no longer around.
Remember that useful code is used much longer than ever intended. Maintenance
programmers will thank you. And, if you are a maintenance programmer
and the code you are working on does not tell the truth easily, apply the
aforementioned guidelines in a proactive manner. Establish some sanity in the
code, and keep your own sanity.

– Peter Sommerlad (from “97 things every programmer should know”)

Integrate Azure Cognitive Services in UWP app

Azure Cognitive Services are an amazing tool than enables developers to augment users’ experience using the power of machine-based intelligence. The API set is powerful and provides lots of features that are organized in categories: vision, speech, language, knowledge, search, and labs.image

In this post we learn how to leverage the Emotion API to get our user mood and set a background of our app accordingly.

Get API key

To get starded we need to get an API key to be able to access the Cognitive Services. So, let’s go to this address (https://azure.microsoft.com/en-us/try/cognitive-services/?api=emotion-api) and click on the Create button next to Emotion API.


After that the website will ask to accept the trial term of services and we accept:


After the login we get access to our keys:


Now we’re done with Azure web site and we can start coding.


We fire up Visual Studio and create a new UWP project.


To achieve our goal (get our user mood and change the background) where’re going to develop a simple UI where the user press a button, we take a picture of him/her, send that picture to Azure, and based on the result load a background image.

Before we write code we need to setup our application capabilities in the manifest and download some NuGet packages. We double click on the Package.appxmanifest file in Solution Explorer and Visual Studio, go to the Capabilities tab and check the webcam and microphone boxes.


Then we download the Microsoft.ProjectOxford.Emotion NuGet package that contains some helper classes to deal with the Azure Cognitive Services. In the Solution Explorer we right click and select Manage NuGet Packages. In the search box we type “Microsoft.ProjectOxford.Emotion”. We download the package.


With the following XAML we draw a simple UI with a Button to trigger the camera.

<Page x:Class="IC6.EmotionAPI.MainPage"       xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"       xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"       xmlns:local="using:IC6.EmotionAPI"       xmlns:d="http://schemas.microsoft.com/expression/blend/2008"       xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"       mc:Ignorable="d">

    <Grid Name="myGrid">
            <Button Click="Button_Click">Take a camera picture</Button>


At the handler of the click event we write

  private async void Button_Click(object sender, RoutedEventArgs e)

                using (var stream = new InMemoryRandomAccessStream())
                    await _mediaCapture.CapturePhotoToStreamAsync(ImageEncodingProperties.CreateJpeg(), stream);


                    var emotion = await MakeRequest(stream.AsStream());

                    if (emotion == null)
                        await new MessageDialog("Emotions non detected.").ShowAsync();


                    var imgBrush = new ImageBrush();

                    if (emotion.Scores.Sadness &amp;amp;amp;gt; emotion.Scores.a)
                        imgBrush.ImageSource = new BitmapImage(new Uri(@"ms-appx://IC6.EmotionAPI/Assets/sad.jpg"));
                        imgBrush.ImageSource = new BitmapImage(new Uri(@"ms-appx://IC6.EmotionAPI/Assets/happy.jpg"));

                    myGrid.Background = imgBrush;


            catch (Exception ex)
                await new MessageDialog(ex.Message).ShowAsync();

In this method we’re leverging the power of the MediaCapture class that provides functionality for capturing photos, audio, and videos from a capture device, such as a webcam. The InitializeAsync method, which initializes the MediaCapture object, must be called before we can start previewing or capturing from the device.

In our exercise we’re going to put the MediaCapture initialization in the OnNavigatedTo method:

        protected async override void OnNavigatedTo(NavigationEventArgs e)

            if (_mediaCapture == null)
                await InitializeCameraAsync();


InitializeAsync is a helper method we write to search for a camera and try to initialize it if we find one.

  private async Task InitializeCameraAsync()

            // Attempt to get the front camera if one is available, but use any camera device if not
            var cameraDevice = await FindCameraDeviceByPanelAsync(Windows.Devices.Enumeration.Panel.Front);

            if (cameraDevice == null)
                Debug.WriteLine("No camera device found!");

            // Create MediaCapture and its settings
            _mediaCapture = new MediaCapture();

            var settings = new MediaCaptureInitializationSettings { VideoDeviceId = cameraDevice.Id };

            // Initialize MediaCapture
                await _mediaCapture.InitializeAsync(settings);
            catch (UnauthorizedAccessException)
                Debug.WriteLine("The app was denied access to the camera");

        /// Attempts to find and return a device mounted on the panel specified, and on failure to find one it will return the first device listed
        /// </summary>

        /// <param name="desiredPanel">The desired panel on which the returned device should be mounted, if available</param>
        /// <returns></returns>
        private static async Task<DeviceInformation> FindCameraDeviceByPanelAsync(Windows.Devices.Enumeration.Panel desiredPanel)
            // Get available devices for capturing pictures
            var allVideoDevices = await DeviceInformation.FindAllAsync(DeviceClass.VideoCapture);

            // Get the desired camera by panel
            DeviceInformation desiredDevice = allVideoDevices.FirstOrDefault(x => x.EnclosureLocation != null && x.EnclosureLocation.Panel == desiredPanel);

            // If there is no device mounted on the desired panel, return the first device found
            return desiredDevice ?? allVideoDevices.FirstOrDefault();

Let’s focus on the MakeRequest method we called in the click event handler because here we make use of the Project Oxford library to detect emotions.

private async Task<Emotion> MakeRequest(Stream stream)
            var apiClient = new Microsoft.ProjectOxford.Emotion.EmotionServiceClient("f1b67ad2720944018881b6f8761dff9a");
            var results = await apiClient.RecognizeAsync(stream);

            if (results == null) return null;

            return results.FirstOrDefault();

We need to create an instance of the Microsoft.ProjectOxford.Emotion.EmotionServiceClient class. In the constructor we pass the key obtained from the Azure portal at the beginning of this post. Then, we call the RecognizeAsync method. Here we’re using the overload with the Stream parameter because we have our picture saved in memory. There is also an overload that accepts a URL string. With this call the Azure platform is now doing its magic and soon it’ll deliver the result. The RecognizeAsync returns an array of Emotion. An Emotion is made by a Rectagle reference and a Score reference. The Rectagle instance tells us the coorindates of the face detected while the Score instance tells us the confidence of every mood that Azure can detect: sadness, neutral, happiness, surprise, fear, and anger. Based on this data we can make “ifs” to do some funny things like changing the background of our main window.


In this post we learned how to detect the current mood of our user. We achieved that by using our front camera to take a picture and then make a call to Azure Emotion API to guess if our user is happy or not. We had to set the app manifest to inform the OS that we need to use the Webcam to ask the user for the privacy settings.

If you want to learn more about the MediaCapture class, visit MSDN (https://docs.microsoft.com/en-us/uwp/api/windows.media.capture.mediacapture) and the Azure Cognitive Services (https://azure.microsoft.com/en-us/services/cognitive-services/) website. The source code of the app developed in this post is available on my GitHub (https://github.com/phenixita/IC6.EmotionAPI).


If you have questions you can use the comment section below or you can find me on Twitter! If you liked this post, share!

Pollice verde

Per me il software è come una pianta.

Una delle metafore più diffuse per descrivere ai non addetti ai lavori come avviene la costruzione di un software e la sua complessità è quella di paragonarla alla costruzione di una casa. È una metafora che regge, niente di sbagliato. Tuttavia è limitata perché a un certo punto la casa finisce e diventa “rigida”. Non è più così modificabile, non è più possibile fare determinate aggiunte o togliere pezzi.

Proprio per evitare questa sensazione di rigidità io preferisco la metafora della pianta. L’inizio dello sviluppo è come piantare il seme. Poi arriva un minimo di arbusto ma perché si regga dritto è necessario aiutarlo con un bastone di sostegno. Poi si comincia ad avere un certa solidità, con un tronco e i primi rami più importanti. Il processo avviene con calma, con cura, dobbiamo amare la nostra piantina e sfoggiare le nostri doti migliori da pollice verde. Poi è un’esplosione di rami, foglie, che possono sempre crescere in ogni direzione e in ogni momento. Ma attenzione. Alcuni rami si possono ammalare, altri vanno potati. La pianta va continuamente curata, sfrondando dove c’è bisogno.

Per questo il software è come un albero. È un qualcosa che continua a mutare e il buon team di sviluppo ne conosce pregi e difetti. Sa quali sono le parti da potare e lo fa senza indugi. Sa quali sono le parti che si reggono su un sostegno e le fa crescere per renderle più robuste.

E voi? Che paragone usate per spiegare come si costruisce e mantiene un software?


Uno degli ultimi acquisti in ambito di manuali: Software Project Survival Guide di Steve McConnell.


Conosciamo tutti Steve McConnell per il suo super famoso Code Complete 2.

In questo testo McConnell ci spiega come gestire un progetto software che richiede dai 3 mesi a un paio di anni. L’autore ci fa capire quanto alcune attività che dai manager mediocri vengono considerati sprechi sono in realtà necessarie e sane. Inoltre ci fornisce delle check-list di controllo e propone dei metodi di controllo.

Calza a pennello, a mio avviso, il paragone che fa subito all’inizio tra la piramide dei bisogni di un essere umano di Maslow e quelli di un progetto.




Se un progetto non riesce a soddisfare i suoi bisogni di sopravvivenza e sicurezza non sarà possibile raggiungere i più alti livelli di stato dell’arte del software.

È ricco di molti altri spunti di riflessione e mi senti di consigliare a chiunque sia coinvolto in progetti software (anche se non strettamente un programmatore) a studiare questo testo.

Tu non fai la differenza

Come nasce un software? Facile. Lo scrive un programmatore, appunto, programmando. È quindi il programmatore che fa la differenza se il software è buono o meno. Giusto? Io rispondevo sì finché non ho letto quest’articolo su un gruppo software della NASA.

Non siamo noi programmatori che facciamo la differenza.

È il processo.

È il processo che crea un software, che decide come il software deve fare qualcosa, che ne scova i bug e che è pensato per migliorare continuamente. Le persone sono degli esecutori di un processo. Il software sarà buono tanto quanto lo è il processo. Il software e la numerosità dei suoi difetti sono rispettivamente l’output e la misura della qualità del processo.

Le persone non devono essere creative quando scrivono software, devono essere creative nel pensare un processo.

Può essere un punto di vista che annienta il nostro ego, il nostro sentirci creativi e potenti quando programmiamo: almeno in parte io mi sono sentito così. Ma noi programmatori dobbiamo smetterla di pensare che è tutto merito nostro. Non facciamo la differenza e il codice che scriviamo è pieno di bug. Perciò dobbiamo pensare e contribuire a un processo che ci salvi dai nostri stessi errori, che li prevenga e che tuteli l’intero team di sviluppo. È questa la differenza tra chi fa software “tanto per” e chi lo fa seriamente.

Un appunto. Il gruppo di sviluppo del software per il sistema di bordo dello Shuttle non fa le nottate a programmare. Iniziano alle 9 della mattina e finiscono alle 17, gli straordinari sono rari. Sono persone normalissime con famiglia e figli. Magari con 8 lauree e 2 Phd ma a parte questo sono l’antitesi dell’hacker o del programmatore che i media ci propinano. E loro scrivono software perfetto.