OK, I’m a little late at getting to this but I have just posted the code for my recent talk: Creating Awesome Chat Bots with the Bot Framework and C#.

To all that attended, thanks for joining me. I had a lot of fun preparing and presenting.

The code is here: https://github.com/schwammy/bot-demo

Unfortunately, this isn’t the easiest sample to get running. I think the code serves as a good example of some great things you can do with bots. However, if you want to actually use it, there are several steps that need to be done in advance. I’ve copied the text below from the readme file. As I say in a lot of my presentations, each step is pretty easy. However, putting them all together, especially for the first time, can be tricky. There are lots of good articles and videos on the web already for getting started with Bot Framework (and LUIS and QnA). I suggest reading up a bit and then follow my very basic instructions to get the code sample running.

Contact me if you have any questions or issues. Have Fun!

Getting Started

Before using this code you need to get set up

  1. Follow the instructions in the Prerequisites section here: https://docs.microsoft.com/en-us/azure/bot-service/dotnet/bot-builder-dotnet-quickstart
  2. Install the emulator. The link is on the same page as above in the section: “Test your bot”

  3. You will also need:

Resources Setup

  1. After you create a LUIS account, create a LUIS app. You can leave it blank if you want. TechBashBot.sln contains a file LuisModel.json that can be imported to get started quickly.

  2. After you create a QnA Maker account, create a QnA service. You can import the questionsn and answers from TechBashBot.sln using the QnAMaker.tsv file.
  3. After you create your Azure Account, create a Web App Bot. Just add a resource and search “bot”, then choose Web App Bot

App Configuration

Once all of your resources are set up, you need to configure the code:

  1. Update the web.config file with the MicrosoftAppId and MicrosoftAppPassword for your new Web App Bot

  2. Update LuisDialog.cs by setting the new LUIS model id and subscription key
  3. Update QnADialog.cs by setting the QnA Service subscription key and knowledgebase id

Not a lot has changed with LINQ over the years. But I still find that developers aren’t completely familiar with the differences with some of the methods. In this post I’ll show the differences between:

  • Single()
  • SingleOrDefault()
  • First()
  • FirstOrDefault()

Of course these methods are similar but there are times when using the wrong one could lead to big problems with your application. The obvious similarity between these methods is that they are meant to return a single item. This is quite different from methods like Where() which returns a collection of items.

Now let’s focus on the differences.

I have noticed that in most cases, developers tend to use First() as the go to method for returning a single item from a collection. In my opinion, this is a bad idea. I tend to use Single() more often but of course there are times when each is appropriate. Here’s why…

Let’s start with a data set to work from. Here are some members of two great bands:

	List<Person> list = new List<Person>();
	list.Add(new Person {Id = 1, FirstName = "John", LastName = "Lennon"});
	list.Add(new Person {Id = 2, FirstName = "Paul", LastName = "McCartney"});
	list.Add(new Person {Id = 3, FirstName = "George", LastName = "Harrison"});
	list.Add(new Person {Id = 4, FirstName = "Ringo", LastName = "Starr"});
	list.Add(new Person {Id = 5, FirstName = "Jimmy", LastName = "Page"});
	list.Add(new Person {Id = 6, FirstName = "Robert", LastName = "Plant"});
	list.Add(new Person {Id = 7, FirstName = "John", LastName = "Bohnam"});
	list.Add(new Person {Id = 8, FirstName = "John Paul", LastName = "Jones"});

Let’s assume that the Id field is unique.

First, the method Single()

If I want to select a user by Id, I could use Single()

Person x = people.Single(p => p.Id == 1);

That will return the Person object for John Lennon.

For Single, the big difference comes when things aren’t as I expect them to be. Consider the following examples.

Person x = people.Single(p => p.Id == 9);

In this case, there is no person with an Id of 9. So Single() will throw an exception: “Sequence contains no matching element”.

Here’s another scenario

Person x = people.Single(p => p.FirstName == "John");

This too will throw an exception. This time it is “Sequence contains more than one matching element”.

So which is the best to use? It really depend on the situation. Often when you are selecting an item by Id, it is because you already know the Id. And if you do, I think it is safe to expect that the object with that Id exists. So I use Single(). In this case, the exception will be thrown if the user doesn’t exist but maybe that is ok because exceptions are for when things go wrong and in this case, something must have gone wrong. I also showed using Single(p => p.FirstName == “John”). But why would I do that? What reason could I have for selecting a Single item by a field that is not unique? Was I just curious to know if we had any Johns in the system? Would I have been better off with Any(p => p.FirstName == “John”) that returns a boolean?

Another option is SingleOrDefault()

Person x = people.SingleOrDefault(p => p.Id == 1);

This too will return the object for John Lennon.

Person x = people.SingleOrDefault(p => p.Id == 9);

SingleOrDefault() is safer. This time instead of an exception, x will be Null. Of course, as the developer, only I can decide which is better (Single or SingleOrDefault). It really depends on what I expect to happen and what other code exists to deal with unexpected results.

Person x = people.SingleOrDefault(p => p.FirstName == "John");

And SingleOrDefault() will still throw an exception if there is more than one “John”: “Sequence contains more than one matching element”

Next, a look at First() and FirstOrDefault()

Often, First() will give similar results but I find it misleading and using First() where inappropriate may actually hide problems. Consider the following:

Person x = people.First(p => p.Id == 1);

This too returns the object John Lennon.

Seems like everything is fine. But what if our data was bad. What if somehow we had two people with Id 1. Before you say “that would never happen”, think about some of the systems that you have supported. What if there was a mistake in the data entry validation? What if there was a bad import. My point is, it could happen. So now, if we use First(), we will get the first item in the collection that has the matching Id. It seems to me like in this case, I’d rather have Single throw an exception for me!

Unlike Single(), First() will NOT throw an exception if there is more than one matching element. Consider this:

Person x = people.First(p => p.FirstName == "John");

You can’t just assume that the result is John Lennon. It could depend on your data source and how the data was entered. Also, if a statement also had an OrderBy()

Person x = people.OrderBy(o => o.LastName).First(p => p.FirstName == "John");

Now I’m getting John Bohnam.

Yes, there are definitely cases when this is OK. But most of the time, I’d bet it is not. Why would I ever want the First() John?

Person x = people.FirstOrDefault(p => p.FirstName == "John");

This would have the same result as above. I could get John Lennon or John Bohnam depending on other factors.

Person x = people.FirstOrDefault(p => p.FirstName == "Pete");

Here, I get Null again (no exception). Sorry Pete Best, you’re not in the list.

So which to use?

There are circumstances for all of these. It’s great that we have 4 options. The important part is that as the developer, you understand that these are different. Please just don’t fall back on First() and use it all the time. Think about which is right for the circumstances you have at the moment.

One last tip

These statements may work correctly but they are just wasting keystrokes. I always say “less is more” with code.

Person x = people.Where(p => p.Id == 1).Single();
Person x = people.Where(p => p.Id == 1).First();

Please don’t do that. It’s much simpler to just say:

Person x = people.Single(p => p.Id == 1);
Person x = people.First(p => p.Id == 1);

Do you know what a Tuple is? Have you ever used a Tuple in C#? Have you heard of Tuples but assumed they were some complicated language feature? Tuples are very useful and very easy to use.

A Tuple is a very easy way to create objects that have multiple properties. Sure, creating classes is pretty easy too. But sometimes you just want to pass around a few pieces of information and not create a class just for that. And yes, I know you can use a struct instead. But both of those are very permanent. Do I really need to create a new Type in my project for something so simple? Here’s an example.

Today I was writing a method that returned some XML as string. The XML was going to be combined into a larger XML document. Sort of like this:

string xml = "<OuterNode><Section1>{0}</Section1></OuterNode>";
string inner = someService.GetXml();
string.Format(xml, inner);

Pretty simple right? But then I found out that I actually needed to get 2 portions of XML and they went into two different places:

string xml = “<OuterNode><Section1>{0}</Section1><Section2>{1}</Section2></OuterNoded>”; //simplified for the example

Sure there are lots of ways to do this:

  1. I could create a second method to return the second section of XML. Sure I could. But as much as I like single responsibility, the method I am using really is the right place to return both pieces of information. You’ll have to trust me on that :)
  2. I could create a class to hold both pieces of information like the one below. But, well, I am lazy. Plus, it just feels like a lot of overhead for this.
public class XmlHolder
{
    public string FirstPart {get; set;}
    public string SecondPart{ get;set;}
}

This is a use case where a Tuple can come in handy. A Tuple is a data structure that has a specific number of arguments, each of a specific Type and in a particular order. Please don’t be mislead by the word “structure”; a Tuple is a Class, not a Struct. Here is how you create a Tuple:

var firstTuple = Tuple.Create(xmlPartOne, xmlPartTwo); //Both of those arguments are strings.

Cool huh?

To get the data out:

var foo = firstTuple.Item1;
var bar = firstTuple.Item2;

OK, cool. But not super cool. “Item1”, “Item2”??? To me that seems sort of cheesy. But keep in mind, this is not a Dynamic Type object so you can’t name the properties. So I guess “Item1”, etc, will be ok.

Using the Create() method is cool. But what exactly does it create? Here is another way to write it that gives us some more insight:

Tuple<string, string> firstTuple = Tuple.Create(xmlPartOne, xmlPartTwo);

or

Tuple<string, string> firstTuple = new Tuple<string, string>(xmlPartOne, xmlPartTwo);

Now you can see what is really going on… Generics! I love Generics.

Do you have more than two items? That’s no problem:

var foo = Tuple.Create(string1, string2, string3, string4, string5); // assume these arguments are all strings please.

Got items of different types? Easy:

var foo = Tuple.Create(someString, someInt, someDecimal, somePersonObject, someThingElse);

That last one is the same as this:

Tuple<string, int, decimal, Person, SomeThingElse> firstTuple = Tuple.Create(someString, someInt, someDecimal, somePersonObject, someThingElse);

Easy right? And of course, thanks to Generics it is strongly typed.

These guys are really easy to use. Plus unlike an anonymous object, you can pass them around. Here I have a method that takes a Tuple as an argument.

public void DoSomething(Tuple<int, string, DateTime> input)
{
    int age = input.Item1;
    string name = input.Item2;
    DateTime hireDate = input.Item3;
}

The problem with the example above is that the developer who calls the method cant really tell what arguments the method really wants. It would probably be better to do this:

public void DoSomething(int age, string Name, DateTime hireDate)

So, Tuples are classes that should be used with some caution. Not because they are “bad” but they may not be the best kind of object to pass around because, while strongly typed, the properties aren’t “strongly named”. Certainly not a great choice for a public API. I think they should really be used sparingly. Certainly great for prototyping. And good for real applications too. But as a team lead, I wouldn’t want to see my team start using Tuples in place of regular classes all over the place!

Some more information:

Tuples were introduced in .Net 4.0.

Tuples are immutable. You can’t change the value once it is defined.

Items in the Tuple can be value or reference types.

Tuples are classes, not structs so they are on the heap, not the stack. That means they are garbage collected.

You can use Create() for Tuples with 1 item to 8:

  • Create(T1); // called a singleton
  • Create(T1, T2); // called a pair
  • Create(T1, T2, T3); //called a triple
  • Create(T1, T2, T3, T4); // called a quadruple
  • Create(T1, T2, T3, T4, T5); // called a quintuple
  • Create(T1, T2, T3, T4, T5, T6); // called a sextuple
  • Create(T1, T2, T3, T4, T5, T6, T7); // called a septuple
  • Create(T1, T2, T3, T4, T5, T6, T7, T8); // called an octuple
  • Plus you can pass another Tuple in as the 8th argument to make even larger Tuples!

Check them out, I hope you will enjoy using Tuples in your code.