Tag Archives: Build

Microsoft Chat Bot Framework – Up And Running

Some time ago (think early to mid-nineties), I used to run a BBS. One Christmas, I logged onto another BBS based in Manchester, and they had a “Santa Chat”. I tried it for a while, and was so impressed by it, that I decided to write my own; it was basically the gift that kept giving: you put this thing on your BBS (basically an Eliza clone) and it records the responses of the unsuspecting users to a text file (or log).

These days there are laws against recording such things, but those were simpler times, and once they realised the joke, everyone was happy, and life went on (albeit at 14.4k bps).

A few years ago, I decided to relive my youth, and wrote an app for the Windows Store – this one didn’t keep logs, although I imagine, had I added a “Post Log to Facebook” button, it probably would have got some use. It has since removed by MS in their wisdom. There was very little difference between it and Eliza.

Now, Microsoft seem to have jumped on this bandwagon, and they have released a framework for developing such apps. Clearly their efforts were just a copy of mine… well, anyway, this is a quick foray into the world of a chat bot.

You’re first step, in Azure, is to set-up a Web-App bot:

This will actually create a fully working bot in two or three clicks; select “Test in Web Chat” if you don’t believe me:

Okay – it doesn’t do much – but what it does do is fully working! You can download the code for this if you like:

The code doesn’t look too daunting when you download it:

In fact, looking inside MessagesController, it appears to be a simple API controller. In fact, the controller selects a dialog to use, and the dialog is the magic class that essentially controls all the… err… dialog. The default is called “EchoDialog”.

For the purposes of this demo, we can change the part we want using the web browser; select Online Code Editor:

The bit we’re interested in for the purpose of this is the EchoDialog. Let’s try changing the text that gets sent back a little; replace the test in MessageReceivedAsync with this:

public async Task MessageReceivedAsync(IDialogContext context, IAwaitable<IMessageActivity> argument)
{
    var message = await argument;
 
    if (message.Text == "reset")
    {
        PromptDialog.Confirm(
            context,
            AfterResetAsync,
            "Are you sure you want to reset the count?",
            "Didn't get that!",
            promptStyle: PromptStyle.Auto);
    }
    else
    {
        if (message == "test")
        {
            await context.PostAsync("Testing 1, 2, 3...");
        }
        else
        {
            await context.PostAsync($"{this.count++}: You said {message.Text}");
        }
        context.Wait(MessageReceivedAsync);
    }
}

So, we are checking the input, and where it’s “test”, we’ll return a slightly different response. You’ll need to build this; select the “Open Console” button down the left hand side of the screen and type “build”:

When it’s done, open up your test again and see what happens:

Remember that the bot itself is exposed as an API, so you can put this directly into your own code.

References

https://blogs.msdn.microsoft.com/uk_faculty_connection/2017/09/08/how-to-build-a-chat-bot-using-azure-bot-service-and-train-it-with-luis/

https://github.com/Microsoft/BotFramework-Emulator

Lock a TFS branch through builds

One of the things that is necessary if you subscribe to the feature branching method of source control in TFS is that, once a release is cut, it needs to be locked. There are other reasons that you might want to lock a branch, but this was my specific use case when I came up with this.

There are a dozen ways to do this; you can simply delete the branch, you can remove check-in permissions; however, you could also create a custom build, which prevents check-ins. This isn’t perfect, but it does give you a lot more flexibility that some of the other options.

How

Create a new build definition:

lockbranch1

Then remove all the standard components. As a base level, it probably looks something like this:

lockbranch2

Now, set the build as a gated check-in for your branch, and the next time you try and check something into that branch, you’ll end up with a build failure:

lockbranch3

Why?

The advantage of this method is mainly flexibility. When someone attempts to check into this branch, you execute a custom workflow; so you can send an e-mail, give a custom message, connect to an IoT device that administers a small electric shock, etc. You don’t have to blanket reject check-ins, you can call call the TFS API, interact with services; you could even implement some kind of rudimentary approval system for it.

Caveats

There are a couple of issues with doing this: firstly, if someone tries to check into two gated branches at the same time, they are given the option of a build – as far as I’m aware, there’s no way around this (obviously this means that this solution is not water-tight). Although, again, one of the advantages of the flexibility, is that you could probably check for this in the build.