Search

Many companies have breakfast Friday morning (at least in Denmark) – so do we in Bluefragments. We’re a consultant company and have people running in and out of our office – so we always ended up buying to much breakfast and just throwing it out. A few months ago we decided to do something about it – so we invented “Emma, the breakfast bot”.

In the beginning of the week Emma contacts all employees and asks if they will be joining for breakfast. At the end of the day on Thursday she sums up how many that have signed up. She have a calculation for what is needed for the breakfast – 1 piece of bread per person, 0.2L juice per person etc. Finally Emma contacts a local baker and orders the breakfast for delivery next morning.

Friday morning the breakfast is delivered, no humans involved in the ordering process and we only bought the breakfast actually needed.

We have made an agreement with Kringlexpressen about the ordering and delivery. Emma can talk with Kringlexpressen out-of-the-box and hence handle all of the delivery. If you prefer you can choose to receive an email with the breakfast needed instead of having it delivered.

We expect to ship her to the public in a short period of time. Initially Emma is available in Teams, Skype, Slack – in the near future she will also be available in Skype for Business and Facebook Messenger. If you want to beta-test Emma, hear more about how we build her or if you have any questions about Emma, you’re always welcome to write to emma@bluefragments.com.

Last week I arrived at Orlando, Florida, to participate in Microsoft Ignite and to talk about our Readymade AI concept.

I’m a developer by heart, so I kicked of Ignite with an pre-event AI developer bootcamp – a full day of examples on how to use AI services from Microsoft presented by James Carpinter, Microsoft Regional Director in New Zealand. It is always great to see some real solutions using the Microsoft AI services – and not least how they are doing it.

First day of the actual conference started with a vison keynote by Satya Nadella. I spend the rest of the week together with companies and Microsoft employees talking about our Readymade AI concept. It was really great to see how well it was received, how people understood the concept and to hear how people could see it work in their company. So awesome! :)

Tomorrow I’m heading back home to Denmark, and will spend next week working on the feedback I received here at Ignite. Thank you to everybody that had time to meet with me – and have fun, Orlando – we might meet again next year :)

A few days ago, Microsoft made their platform for training AI agents using Minecraft public – the platform is called Project Malmo (formerly know as Project AIX). Project Malmo is a Minecraft mod and supports many different programming languages.

We often have the need for having both development, test and production version of UWP apps installed on our development and test machines. To accomplish this we modify the package.appxmanifest as part of the build and release process in VSTS.

The “Name”-attribute in the “Identity”-tag in the manifest file determine the unique identification of the app. This is what needs to be different in development, test and production.

Step 1 – associate app with Windows Store

Before doing any modifications, it can be a good idea to associate your app with the Windows Store. You’ll need the info generated later.

Step 2 – development

For development use you can set the value directly from Visual Studio (open package.appxmanifest in code view).

You can set the value of the “Name”-attribute in the “Identity”-tag to actually what you want. Copy and save the existing value – you’ll need this info in a bit.

You can set the “DisplayName”-attribute in “uap:VisualElements”-tag to a clear development name – I often add “(dev)” after the existing value.

Step 3 – test

For test, the modifications to the package.appxmanifest file should happen as part of the build process (in VSTS).

To make the modifications I use two powershell scripts – one for the identity name (SetPackageName.ps1) and one for the displayname (SetDisplayName.ps1). Add the scripts to your files (eg. in a resources-folder) and commit them.

Point the first task to the SetPackageName script. Set the new package name as argument to the script: “-packagename ‘MyAwesomeAppTest’”. Set the working folder to the folder where the package.appxmanifest is under the “Advanced”-section.

Point the second task to the SetDisplayName script. Set the new display name as argument to the script: “-displayname ‘My Awesome App (test)’”. Set the working folder to the folder where the package.appxmanifest is under the “Advanced”-section.

Step 4 – production

For production it is the exact same steps as for test. For production you should use the values you initially changed in the package.appxmanifest file.

Wrap up

You should now be able to install development, test and production versions of your app, without the apps interfering with each other.