Microsoft Cognitive Services Emotion API First Impressions

I am always interested and looking for new libraries to put to use in Xamarin.Forms. I recently stumbled upon Microsoft Cognitive Services Emotion API and wanted to see what it was all about. After a quick look at some sample code, I knew I needed to sign up and try this library out for myself.

The sample code I had been looking at can be found here Xamarin.Forms Emotion API sample code. The sample has some other services built into it but what really interested me the most was the Emotion API.

According to comments in the code, which I am always skeptical of, the API can detect happiness, sadness, anger, fear, contempt, disgust, and neutral. It is amazing that it can determine these emotions and with great accuracy. What is even more amazing is that it basically is one line of code.

This one simple line gets the first (highest percentile) emotion recognized from a picture. Using the sample code you can easily take a beautiful selfie, send it with the single API call, and within seconds get an emotion back. I am not sure yet what factors cause it to take longer but sometimes I get results back in under a second.

From my dozen or so attempts at taking a picture of myself, it gave quite accurate results. I have yet to fake fear in a picture but will see if I can one to happen.  I am very impressed with the Emotion API’s ability to analyze and image and produce an emotion result. Looking forward to Microsoft adding even more emotions.

The free tier for using the API is quite impressive in terms of the number of calls available. I hope to be writing a post soon showing off an app I have made in Xamarin.Forms incorporating the emotion API.

Xamarin.Forms Microsoft Emotion Api

Programming Better and Easier With The Happy Path

When I start down a new solution or looking at how to solve a problem one of the first things to jump into my head are all the crazy edge cases that may or may not ever occur. I see it as a blessing in disguise because, in the long run, it helps out tons to be able to think about the crazy things a user may do. But when just trying to get a proof of concept together it can make the work that much more daunting.

When putting together a proof of concept stick with the happy path. Hard code values, expect perfect reproducible input, and for the proof of concept even lower the security levels a bit. Make sure if using lowered security settings you are in some sort of development environment. Do not go lowering your security on production.

But the key is to make it as easy on yourself as possible. What if you took the happy path and find out your solution did not even work anyway? You do not want to have wasted your time making your ability to accept input the most robust known the man if your strategy to submit the code is

A more real world time when the happy path saved me much time and effort was when the team and I at work were attempting to setup up a cloud solution using AWS. We had a couple different strategies in our minds as to how to build out our cloud solution. It involved security, databases, IoT, Lambda functions. It was going to be an extensive cloud system.

First thing we did was throw security out the door. We knew it needed to be done but would only complicate things. We did not set up a database because again takes time and we had a lot of database knowledge on our team so that did not pose too much of a risk. We just hard coded the data we would receive back when we did end up making the database.

Now we could take a look at the happy path for our proof of concept. Perfect user input, interaction, no confusing security. We found that our first model would not scale well so we threw it out the door. Our second model was not easily supported due to library limitations imposed on us. Our third solution found a happy medium of ability to scale, performance, and ease of implementation. This all did not happen overnight it actually took a few weeks. But imagine if we had added the extra complexity of security or the database. It would have taken months.

Taking the happy path saved us time and frustration. The process of making application development as easy for you as possible. Ignore the edge cases, ignore security, hard code values. Made us more productive and let us explore multiple solution strategies in a shorter amount of time.