 As my introducer already said, I'm Georgiana. I'm originally from Romania, but I lived in a lot of places, including London, Amsterdam, a lot of places in Romania. I also have a six-year-old kid, and I've been doing enterprise-scale PHP for, I don't know, 17 years. Lately, I've been cheating and doing more of Python, but a few years ago, I even organized Romania PHP, which was an amazing adventure, I would say. I didn't even organize my own wedding, so I was faced with this thing. Let's organize a conference, because why not? So that was a very fun thing to do. When I don't play with my kid, I don't do PHP or Python or conferences, I am trying to complete my PhD studies. I'm trying to do systems engineering with machine learning. Quite an interesting topic. Let's grab a cup of tea later if you want to hear more. One year and a half ago, I moved in Brabant, which is a historical province south of the Netherlands. In Einhoven, it's a very, very big technical hub, and I'm working for ASML, which is one of the largest companies in the world. So we have around 24,000 colleagues, out of which 12,000 are located in Einhoven. What we do is produce machines that Intel, Samsung, and any other manufacturer is using to make chips and memories for all the devices that you already have in your pockets or on your labs, in some cases. So what we do there is change the world one nanometer at a time. That's our measurement unit. But today, I'm going to talk about the project that is very dear to my heart, which is solving this kind of problem. So before CICD completely automated was a thing, our teams were interacting on the human level with a lot of questions. So the project manager would ask, hey, what's the status? Are we good for the next release? And then the QA team would go to the developers and ask them, do you have anything for me to test? And then can you install it somewhere? Yeah, these kind of things. In some companies and some groups, this is still the case. So that is why we, many, many, many years and projects ago in 2012 actually decided to use Skype. We found this Sevabot tool that would allow us, you could hook it as a participant in a group conversation. And then you would have a keyword that you put in the beginning after the exclamation mark. And that one would be your bot. And then these are the commands. So in this case, discover all environments would give us the staging, development, QA, and so on. And then this is a naming convention that we used for scaling. You can see here the 12, meaning how many elastic items you will have. And you would say, just provision it, put the latest stuff in there. So this was actually very, very easy to do from a chatbot point of view. You would just go as a project manager in Skype and start typing all these things, which was not very funny, but it would take the burden of answering these kind of questions to the QA or the PM department. And what I can also show you here is a versioning and installation done automatically. So we trigger this one. We would have a hook and just use it. So if you go and search on GitHub, this still exists as a code base. Of course, Microsoft acquired Skype and started to kill all the good features about it. So for one year, I think, we didn't upgrade our Skypes because we had this chatbot up and running. So we were like one year behind. So what I'm going to show you today, a small introduction chatbot. I will showcase a little bit on the technical side of Johnny and if time allows, we will do a demo. But I want to start with the show of hands who has written a chatbot that is being used more or less in production by others. Two people are very nice. So this is a very hooky audience. So I insist more on the first part. Are your chatbots technical or no? OK. Thank you. So for those who haven't written any chatbots yet, let's learn a little bit of history when did the first chatbot actually appear? A very long time ago, 1966. It was called ELISA and it appeared at the MIT Artificial Intelligence Laboratory. They were using regular expressions, pattern matching, to identify certain things and mimic understanding. Much later, 1993, this is also before I started programming, so quite a while ago. In IRC, Slack is written on top of IRC, but the original IRC, right? Somebody wrote a couple of TCL scripts and C code modules and so on. So a complex thing to do user management, channel management, game starts, and all sorts of things. In 2001, have you ever heard of Smarty Child? Of course, because this was a chatbot that was written for the AOL instant messaging platform which died successfully a long time ago. But this is the actual chatbot that resembles what we are used to get today. So if you want to look a little bit at what other people are doing, I suggest you start with bot directories, bot list, or there is a bot for that dot com, or chatbotel. You go there and see categories of chatbots, and some of them allow you to start interacting with them directly. So this is a good starting point to get the feeling of what people are building. My current employer is an on-prem shop. Therefore, I will always come up with these kind of slides. Today, if you want to do a cloud-based chatbot, you have quite a good shopping list. IBM offers Watson Assistant. Google has Dialogflow. Microsoft has the bot framework and the engine that recognizes and does NLU, which is called LUIS. Facebook acquired with .ai. So when I first started doing this, with .ai was a small independent thing, not yet purchased by the big guys. And Amazon has in AWS something called Lex. Have you ever heard of it? Yeah? So Lex is quite connected with Alexa, uses some of those things, and also allows you voice interaction, which is a bit more modern. I must say I tried to change this particular demo using Lex, and it took more than two days. So I consider the training part to be more complex than the Watson that I will show you later. If you are happily living on-prem with your code bases, you have perhaps very secure data that must not leave your prems, you can still install Watson Assistant there, which is very nice. It's a pre-trained model. It's the best one that you can do as a starting point. There is a company in Berlin, a startup called Rasa, which was the first one to actually productize an on-prem bot. They have two components, the chatting part and the natural language processing part. Again, just like for Lex, the NLP part, you need to train it really well. I did deliver one bot for a company here in London, Formula One team. And the training part for Rasa took quite a solid week, I would say. So I'm just trying to show you that a lot of investment needs to be spent in this part. So my recommendation is to start with one of the cloud-based solutions and then slowly move if you need to go on-prem. What Rasa does have is you can do a Watson chatbot and then you can export it and import it into Rasa so you don't need to start from scratch. So these two guys work really well together. Snips is the on-prem for voice. Really check it out. It works on your phone. It works any way you need it offline. Snips is the tool for you if you want voice. Now, because this kind of audios didn't really build chatbots, I will start with a bird eye view on what pieces you would need. Let's say you have a consumer that needs to interact with your chatbot. They will need to go to a conversational interface to actually input their queries and get the output from it. And you would need a more complicated part to do processing. Now, in the conversational interface, you would have the entry point. Let's say Slack, Twitter. I will use it later in the example. But there are Telegram and Facebook Messenger and whatnot. And a bot framework. Why is the bot framework part important? Because it completely abstracts the entry point from the actual communication. And we will talk about it a little bit later on the processing part. Whatever the person input in the entry point, we want to understand what they're doing, which is the NLU part. And then we want to tap into the knowledge base and actually do the job. So if we go and start doing it in more depth, on the left-hand side, you could see the entry points, like Slack, Twitter, et cetera, et cetera. That does nothing for you, other than allows you to type in, text, and get messages back. Botmaster is the part that abstracts all these formats. Because of course, the JSON that comes from Slack is completely different from the one that comes from Twitter and completely different from the one that comes from Telegram. Which is why a bot framework is a solid choice at this point. It completely cleans the entire pipeline for you. One word of advice. Botmaster, which we use for journey, exists. The code is there. But the project is not really maintained anymore. If I would start right now, I would go for the Microsoft solution. And I'm not proud to say I would go for the Microsoft solution. But the bot framework seems to be the best one. Because it's not only a good abstraction for these things, but also interacts with Skype, particularly. So that is one of the reasons Skype is not yet dead. So that would be my advice. Now for Botmaster, which again we still use, this was the good part about it. It allowed you to do a Facebook messenger, Slack, any socket IO interaction, which we specifically used for monitoring dashboards. So we would trigger queries in Slack. And we would update certain dashboards using socket IO. Again, Twitter and Telegram. So go shopping for a bot framework. Not Botmaster, unfortunately. So you can see how easy it is. You create the bot, and then you just add the various interactions that you need here, which means that either of these channels sends a message. You get them centralized in one place, which is very, very nice. Now, if Botmaster is just the mediator of these channels, we need some powerful thing, which is the brains. And the brains is the part that we do in PHP, because we all love PHP. But the brains, the orchestration part, doesn't really understand what the customer is saying, which is why we need a natural language understanding platform to help us with that. As I said before, there are multiple alternatives that you can try. The market leader is Watson. And it's the one that uses the best pre-trained model. Does anybody know Watson? Where does the name come from? A detective maybe? No. There was a guy called Thomas Watson, which was the first CEO of IBM. And they used his name to designate the entire umbrella OVA technologies that they offer. So this guy was a teacher, and he just gave up and decided, yeah, let's take a course in accounting and do business. He was a bookkeeper. So that Watson, not detective and other things. Today, if you want to search for documentation, you have to search for Watson Assistant. But before, it was called Watson Assistant. It was called Watson Conversation. So you might find very good tutorials under the previous name. And when it was first launched, of course, it had a completely different name. It was Watson Dialogue. So don't be confused. It is the same product that evolved over time. It does have a free tire. You can really, really play with it. And even if you move into the paid tire, it's not very expensive. If I'm not mistaken, the free tire allows you like 10,000 NLU calls more than enough to boot start and even use in your team. The Watson umbrella offers a lot more products. For example, if you want to do really, really advanced NLU, you might want to move into studio and other things. So that is why another reason for which Watson is a good point to start. So did you get bored with all the technical introduction part? Not really. If we move into the more fun part, Johnny, let's try to break it down a little bit. I don't really like sequence diagrams, but I understand people resonate with them better than any other kind of diagram. So here we go. We have a teammate trying to communicate with our bot. We have the Botmaster framework. We have our PHP brains that connects everything together by communicating with Watson. And in our case, Jenkins for the build. So I want to ask a question and receive an answer. Let's see what happens in between. The Botmaster will try to figure out meaning by asking the brains that is going to give us that answer. Now the NLU part is, OK, whatever question was placed, do you have an idea what it means? Can you please break it down for me? The language for NLU is intent and entities. So what was the user intention? And entities, what are the topics that you can extract from that sentence that was asked in the chat? Once we are sure of the intent, we can go and operate on our knowledge base. In this case, Jenkins, JIRA, or anything else. Now the intent can be recognized by Watson in this case with a certain threshold of certitude. What you can do is say, OK, if the certitude is less than 0.8, which is like 80%, it means the NLU engine is not really sure it figured out what you tried to say. And then instead of going and operating on the knowledge base, you can come back and ask for clarifications and more things. So going away from the sequence diagram into a normal flow, you can see that we have the entry points. The knowledge base, everything else is the boat. So the boat is multiple components. Just to make sure we can see it. Let's move to the first one, entry points. I have some slides explaining how to set up in Slack because we are all technical. We want to go through something that works. So in Slack, you have to make a Slack application in the API online. You have to choose the organization. And this one will give you authorization tokens and bot user auth token. These two are different. And then you will go and subscribe to events. You can say, OK, I only want messages. I want group messages. I want Slack allows you to split it down. And you have to provide the URL of your bot. In this case, I used Ngrok. Do you know what Ngrok is? You see, people doing chatbots. If you want to work locally, because we are developers, first we want to test it, not just put it in the cloud. Ngrok allows you to create a tunnel from your machine to an endpoint on the internet and use that endpoint in your bot. In this case, I have a prefix. You can see here, join your bot. This means I'm using the paid plan. If you use the free tire, which is perfectly fine, you will have a number that gets changed every time you restart the tunnel. You can keep the tunnel open for weeks, like sometimes we do. Or you can move on to the paid version and use the same name. And then you don't have to come here and update it too often. I just wanted to show you that this is a manual process that you will need to do. So in Slack in particular, you can see if somebody sends a personal message to the bot, it can react or it can react to a certain group conversation or channels. Pick your poison here. In the beginning, you'll probably talk to the bot all by yourself. And with time, you will move to the next levels. The next component is the mediator, the bot master part in here for the Slack setup. So we can do multiple setups. I'm outlining the Slack one. You grab from the online team identifier. This is your journey bot user identifier. No, this is the team identifier and the bot ID with the authorization token. If you remember from the previous slide, you had two access tokens, one for the organization and one for the bot. So that's why you need both from that screen. Now here, it's the piece of JavaScript code that shows you how to set up Slack. It's not very complicated. You just need to say, OK, which one of these is the webhook endpoint? And I will go back because I want to show you. It's this part. So your endpoint, your domain of the bot, and then Slack. And then this part is the webhook that you are calling. Everything else is fixed. And the credentials. Now in the mediator, you have incoming and outgoing. So what you do here is the middleware incoming from Slack. I decide to make sure that the bot doesn't talk to itself. Because if the Slack bot user ID is exactly the same one coming from the event, the bot will get into an infinite loop. It will try to talk to itself, not very funny. And then we just prepare request options and we pass them forward to the brain, very straightforward. But you can see that in here, the Slack incoming middleware can be completely separated or can be the same as the Twitter one or any other platform. So this is the part where you decide how your bot is going to react. React to all channels the same or not. And then you have exactly the same for outgoing. So you can very finely grain configure how your bot behaves on every single entry point. PHP time. This is a very, very skinny Symphony application because I love Symphony more than Laravel. Any Laravel lovers here? Yeah? Any Symphony lovers here? Thank you. More enterprise people. So my demo is quite good. You can see it's very easy. We don't have a full-sized application, a conversational controller. And then these entities are automatically mapped with the GMS serializer from the JSON into an object. So we put them in this small way. So let's see how we do it. We just receive that text thing from JavaScript, from the botmaster part. We deserialize it directly into this entity. We know it was a JSON incoming. So now we can look into the API request and see no message, no response. So defensive programming first. Now we can focus on the interesting part. I made a small service called ask, which is the part where, OK, now I want to go to the NLU Watson in this case, just ask this question for demo purposes. We also log it because we want to have a look at it. And then we send it back. Now if you can see here in the response that we got here from Watson, we don't have any intent. It means the NLU engine didn't figure out any kind of meaning in the text that was being said. If we do have intent, we can iterate over them. Please, in production, do not use switch and case. Use normal injection. Yes, this is not something that you want to take home for usage in production because your employer will not like it. But it's much easier to fit it on a slide like this. So if the first intent is, OK, tell me how many tickets you have ready for QA, do this thing. If you want me to prepare a release candidate and deploy it, pick these two items that were identified by the NLU engine and send them as parameters to the corresponding job. If you want to ask historical questions, what happened when was something last performed, like an update or something else, then we're going to do this third action. How do we interact with Watson? Even easier. We have a ready-made request. We place a string in the constructor. It will make all the rest for us with all the environmental variables that are required. We'll civilize it as a JSON and give it to the Watson client to post it. Super easy. APIs one-on-one. And then we get back a body that we respectively civilize in the response entity. So the PHP part was just gluing things together. And then that's where you can see, yeah, do I trust this from the NLU and so on. Let's see. How do we do the NLU setup? As I said, this thing changed like a million times in the naming, in UIs. You will find all sorts of stuff. Nowadays, it's called assistant. And an assistant can have one or multiple skills. So this is your actual and natural language understanding part. You can see, I'm actually keeping this screenshot from a while back because this was an example for customer care chatbot. And you can see how few examples are fed here. So the examples that are given are just free text things. And then you say, OK, I want, I don't know, find business hours. So they give 38 possible ways in which a person can ask about business hours or chatbot. But if they want to say goodbye, they only give like six alternatives. If you want to make an appointment, they don't need more than 19. So this is the part where you train your bot. In Watson, the numbers are quite small. In the other ones, who don't have such a good pre-trained model, you will need a lot more. So this is why I'm keeping this slide. Because these numbers, if you think maintaining 47 examples is easy for this one, I can guarantee you that in the other platforms, you will need to provide more alternatives so that the training is improving. The newer interface. So that one, although I keep it for that kind of explanation, you can see with five, six examples, we can do this kind of understanding. So what is involved here in tents are the things that, as I said before, do we recognize what the person is asking from us? And it's one of these things, or you can have multiple, like in the previous example. This is what our bot knows what to do. And then entities, which are of two types, user defined, called my entities and the system ones. The system ones can detect time ranges, locations, all sorts of things. The system entities used by the Facebook with AI are better. So that's where you get confused. There are fewer in Watson, so it doesn't understand everything. But it allows you to create better user defined ones. So you can see here that in the environment, I have my keywords. This is what I'm going to pass as parametrized items to Jenkins. By the way, we upgraded to CircleCI. But don't tell anyone. So you can see here. When I'm saying dev or development, it's the same thing. If I want to use production, it will be like prod production, live, whatever you want to say. This is how it recognizes the entities. The intents are comprised of various entities and combinations of those into a sentence. So you have code that you can play with. You have a video tutorial how to set up JIRA and online a demo video. But I will do something better if time allows. We have some more time. I will show you a couple of pre-recorded videos just to show you how all these complicated things work together. Remember, it's not complicated. A person interacts with the conversational interface. We already know the conversational interface has two components. And we do a processing part, which has two different components, our brains and the NLU engine. OK, let's show you the first one. So the first intent is ready for QA. The text that's been written here is saying, do you have tickets ready for QA? And you see here, the dockerized version of JIRA that I prepared. So you can see in this column, there is nothing. So now I just moved the ticket. I'm done. And now I'm going to ask different, with different wording, are there issues ready for testing? OK, it found one. I can even click it if I craft my response correctly so that it provides the link. I'm just going to skip and move both of them. What tickets? This was me learning how to do a proper demo, are ready for testing, probably. But you can see tickets and JIRAs and all sorts of slang that we use. This was not provided with synonyms. We provided it in the five or six examples of the centers. And of course, it found both of them. OK, the next example is this one, more complicated. And I also want to show you that in the Watson conversation, you can try it out here. So this is where you train it. And then so you don't go through the whole component setup if you don't need to. OK, I'm going to do something really hacky. I found a tool that completely deletes Slack history. Please don't delete your company's Slack history like this. But it can be done. OK, and I'm just going to copy paste some text. It's not in the right place. I need you to build an RC for the CMS and deploy it to QA. And you see here, I need you to deploy to integration. I did not specify I need you to build an RC because that one is in another training sentence. So what I'm typing here is not the same thing that I did for training. It's completely different things. And you see it started the build. And it passed on to variables, an environment, and a component that were identified from the NLU engine. Build a new release candidate of the front line and deploy it to integration. Refresh shows we have a next build with two parameters. The environment is integration and the component is front end. This one and another one. And in this particular Jenkins instance, which is for demo purpose, I have a random thing that fails the builds once in a while. Because in real life, not everything is green. So you see this one is marked as a failure or something. Prepare an API build and deploy it to production. Again, two actions. So now that we created history in Jenkins, who here still uses Jenkins? Yes, how easy it is to find anything there in the history? Not very right. So this is one of the reasons for which I made this thing. There were many frustrations, but this was one of them. So finding out things in a parameterized log, you have hundreds of builds. You can never find anything. So this one is telling me when the website was last deployed in staging. And it will go use the API of Jenkins, scrape it, and find the result, and put the link in Slack. OK, this is the part where we take the debugging part. This is what Watson said. And we're going to have a look at it. You can see it has a degree of confidence of 92%. So we can really make this action. There are other cases when the confidence level, we found like 50%, 60%, and then we keep on asking questions. This is a nicer way to scrape your Jenkins history. This is the example that is not so confident. Let's see. It's like 0.54, 54%. We wouldn't really want to execute this if it was an action. You can find this one on YouTube.