 Thank you everybody and welcome to my talk. It's about time to take your medication or how to write a friendly reminder board. So I also work at Blue Yonder, so normally I'm more like a data scientist guy and yeah, the last Europe Python in Berlin, I gave a talk about how you can extend scikit-learn with your own estimators or quite mathy stats talk and there were about 15 people thought, okay, so this year I try something different and well, okay, it's a little bit better at least. So surely the question that you all have is why would anyone write chatbot and there's a little story behind it, so a friend of mine was diagnosed with diabetes, so you surely all know diabetes, so you have to take insulin the whole time and he said that yeah, so there's two kinds of insulin, there's one you take before you eat something or while you eat something and then there's the long acting in insulin, this is something you have to take at a specific time during the day and he said that he's always like forgetting about this or taking it one hour too late or too early and of course he sets alarm on his smartphone but it would be really cool if someone would somehow remind him just like use a chat or call him or somehow remind him and then the idea was born, okay, why not write a little bot that uses Google Talk or Facebook or any kind of chatting engine and reminds him to actually please take your long acting insulin now and to also wait for an answer that he really did it and otherwise like remind him again and all over and I thought well, that's also good for me, it's not only that I'm like helping a friend, it's also for me good because it's a good use case to actually start learning something new, learning more about event-driven, asynchronous programming, something where there's a real hype right now, I mean everyone's talking about Async.io, there were a lot of talks about Async.io, I don't know if you've seen the talk by Niklas about the distributed hash table which was I think a really great talk about Async.io so I took this as like yeah, a use case, I wanna learn something about it, also a little bit about XMPP and about how one can write a Google app because in the end I used Google Hangouts to actually implement it and of course, yeah, to help a friend. So the first thing I wanna talk about is what is event-driven programming and what it has to do with asynchronous programming. So event-driven programming, this is the definition of Jessica McKellar from the Twisted Network Programming Essentials. In an event-driven program, program flows is determined by external events, it is characterized by an event loop and the use of callback to trigger action when events happen. So this is basically the definition and it just stated that any kind of event, an event could be like a user triggers an action or a message is received over a network and then you have predefined actions, the so-called callbacks that are then triggered and that actually do something. And in most cases, this is implemented as a kind of event loop, as a main loop that listens for events then triggers the callbacks and callbacks are just continuation. So it's just like, what do I do if I get a message or if I have received something? And event-driven programs can be single-threaded but also multi-threaded architecture exists. So you do the GIL in Python, so async.io is mostly single-threaded but you could also imagine that you had for each callback, you could start a new thread or something then you would have a more multi-threaded event-driven program but this is mostly not, it's not what it's done in most implementation. And to differentiate this a little bit from what is blocking and non-blocking, you could think of an event-driven program itself purely from the definition could be blocking or could be non-blocking. That means, for instance, if you have a GUI and you click on a button then an event is triggered, some action is gonna process and during that action, your whole GUI could be blocking. I mean, this is sometimes things you see on Windows, for instance, that the whole GUI blocks and is unresponsive or while evaluating this callback could be non-blocking so that other things can happen at the same time. Or for instance, another example would be some kind of 3D computer game. I mean, while the engine is waiting for user input, it's still calculating the physics engine and it's updating the graphics. So what is asynchronous programming then? Asynchronous IO or non-blocking IO is a form of input-output processing that permits other processing to continue before the transmission has finished. So this is also a bit like a form of cooperative multi-tasking because you kind of, at certain points during your execution, you kind of give away the processor to other things and to let it, yeah, to, you give it away so other tasks can use your, can use the processor. So, but it's cooperative in contrast to primitive in the sense that it's really at specific points and we will see that later. And the concept can also be implemented as an event loop. So since a picture says more than 1,000 words, so I'll have this graphic. So if we have a program, something really simple program that basically consists of three tasks and the tasks have different colors and if you see the gray boxes are actually like waiting times, this is when the task reads in a file or maybe waits for a network socket or message or an event of the user, then it kind of suspends its work, it waits and the total time of the program is the sum of all those blocks. So in multi-threaded, you would like conically put each task in on thread and execute them in parallel. So this is something you would not do like this in Python, you would more or less use processes because of the global interpreter lock, but in this case, it's sort of important. The point here is that you still have the gray blocks and the tasks are still waiting until some IO is ready, for instance. And in asynchronous, there it is that you have only one thread again, but during the gray blocks, there's actually a switch to another task and something is done. So here we start with the blue, then during the waiting time here, we start working on task number two and even on task number one, since you also have a task number three because here we also have a waiting block and then it's in a concurrent way and in a way that can't be like really deterministic as I told, so the colors could also change on the right side and I think this is an important point, so concurrent and event-driven programming, you don't know beforehand what the path, the thread through your program is gonna be. So when to actually use asynchronous event-driven programming, if you have many tasks, of course, you should have at least two, otherwise it makes no really sense. If the tasks are largely independent, so there's no much intercommunication between two tasks, you could imagine if two tasks are the whole time talking to each other, then this could be difficult. Then, of course, when your tasks wait for IO, when they normally would block and you think you could do it during that time, you could do other things and if your tasks share a lot of mutable data that would need to be synced if you do it in a multi-threaded or multi-processing way, this is also like an indicator that you could think about using something asynchronous or something event-driven and this is especially for network application and user interfaces. This is like a natural that you have, you use asynchronous event-driven programming. So some examples I wanna show to better get the idea. So easy tasks, just fetch some URLs and print them and check the elapsed time. So how would this look like in a single-threaded version? So we have some hosts, just a list. We set our timer and for east host, we use the URL lib to request the host and then we print it. We also do a little transformation to make it a little bit more interesting. We just make everything uppercase and print the first 20 characters and the host where we got the webpage from and print the elapsed time. So this would be like a normal thing of the program in Python, how you would do it and of course, what here is like the blocking. So here is actually the gray block that we've seen before in our diagram because we are waiting here for the request to be fulfilled and we wait for getting the request and also here we wait to like read the HTML. So now let's do this in a multi-threaded way. Here it gets only a little bit more complicated. So we also do just the request and the reading in one function and now we generate some threads. So each task is just now a thread and it's listed in the chops list and we start here with our timer. So I skip the overhead of creating the threads. Then for each job we start it, we wait until they're joined, so until they're finished and we see that there was a speedup. So this is just more or less a direct translation of the single-threaded program in a multi-threaded program. So how would this look like in an asynchronous style and I used here Twisted, which is right now only available for Python 2 but they're just working on a migration to Python 3. So here it gets a bit more complicated because we kind of have to separate the different parts of the program much more and we use now callbacks. So we have here the capitalized functions, so we just use capitalized and strip it down to 20 characters and we print the lapse time and now here it's the interesting part. So for East host in our host list, we get the page and this is now a non-blocking operation. So this will directly return and we'll get us a deferred result. And a deferred result is what in Python async I always call the future. So it's actually just a proxy for future result and you can say what should happen if the result is retrieved and this is what you do with the add callback. So you say, if I have a deferred result ever becomes the real result, then please print, call the print capitalized function with it and this is, yeah, so we registered our callback. So we, and then we add everything to the list and then we say, okay, now for all lists, if they're all, if all deferred results actually fired, then we also wanna fire the print elapsed time function and we call it with a task react, the main function. So this is now the event loop. So to say, so we say, okay, run this loop and run the function and we see, yeah, that it worked. But what you can see from this example is it gets really complicated. So adding the callbacks, it's like, you have to think, okay, I have deferred result and I add callbacks and if those fired, I group them and add another one. So it gets really complicated. And this is also a statement that Gito van Rossum supposedly once said, so I found it on the net, this quote, and the net never lies, right? So it requires superhuman discipline to write readable code in callbacks and if you don't believe me, look at any piece of JavaScript code. And so the question is, how would this now look if you would, for instance, use async IO? So in async IO, you would use a coroutine. So coroutine, so how many of you know what a coroutine is? So, okay, I would say most. So it's just a function where you can, like, it's not a functional coroutine, it's like a more general idea of a function, but you can stop at that one point, return and come back. And here, I use the AIO HTTP, which is based on async IO and at that point, we yield from the request and so we give away the execution here for other tasks to do something at the waiting time, but what we get in return is the real response. So if the function here, so you yield from, if the function after yield from returns of future, you wait until the future gets like realized or if it's a coroutine until the next result is generated and then we yield from the response and read and we directly get the HTML and now for each in host, we have a task list again, we append this print page function, we get the event loop and we run the task until they're done and we also see the speedup. So this, the point here is that using async IO and avoiding callbacks in this example, it's much more readable and it much more looks like the single threaded version actually and yeah, it avoids this complicated grass of callbacks. So I think this gets you like a good idea about asynchronous event-driven programming. So now back to our actual tasks so how to build now a bot based on this. So the ideas, we notify a friend at 8 p.m. as agreed about taking his long acting insulin using Google Talks or Google Hangout, then we wait 20 minutes for reply, then we ask again, did you really take it and ask again after another time? During the whole time we check if there's a message which starts or is equal to yes. If we get this message, we praise him, we say, yeah, well done, good job. And if the message is any other to yes, we just say, we just ignore it. Of course, we could also send something like I didn't get it or so. Yeah, and after having three times asked in total, we wanna send the give up message like, okay, now I'm giving up and ask again tomorrow. So when actually stating something like this, it's for me at least it was helpful to come up first with the state graph because what we are actually doing with the abstraction is that we are changing between different states and there are also libraries for this in Python. But before I build it, I just wanted to know, okay, so how many states do I actually have to make it, yeah, to make the solution simple as possible. So during the day, we are in a no message send state. So this is the initial state and what happens if we for instance get any kind of message. So this is the event from my buddy, from a friend at that time, then we just do nothing. So to avoid things that he for instance writes yes before I even have asked. I mean, this is a situation to consider. And so at the event at 8 p.m., we send a message. We are now in the message send state. So if he replies then with a yes, we send, okay, that's good, send the praise and go back. After another 20 minutes, we ask again and I think you'll get the idea until that point and there's also if he then repeats with yes, it's still okay, but after one hour we send, okay, you've done not so good and we give up. And this is how it can be translated in a program. But which protocols are actually used? So first I thought about or I started to implement it in XMPP. So XMPP is the extensible message and presence protocol which is based on XML or formerly it was known as Jabber. And Google Talk, so G Talk used it, but it was deprecated quite lately. So Google switched to Hangout which is proprietary protocol which is yeah, not that good. Even Facebook, they had an XMPP AP until just recently May 2015 where they stopped it. So this is not so good, but still G Talk is working. And I also did the implementation for this. And so if you wanna ever do something with XMPP I would recommend the Sleek XMPP library and you also get a lot of good documentation about it. But since it was deprecated, I switched to Google Hangouts as I said, the proprietary protocol and a really good library that was this kind of reverse engineering of Google Hangouts is Hangouts by Tom Dreyer and yeah, it's a quite active project at the moment and it also already provides interactive chat client and there's a lot of bots already based on Hangouts. So this is a really interesting project. So the implementations to two can be found on the Gluyonder website, not Gluyonder website but Gluyonder Group GitHub account. And I wanna just show some code examples. So where it all starts is like the run of the bot class. So it's really not that much code actually. So you can later just look it up. But so the interesting part is that you, that the client is now the hang up protocol client and you say what should happen on a connect, you connect different functions to the events that are then called. So this is the observer pattern and we have here the event loop. We get the seconds to the next alarm. So it's just the function that calculates from now to next 8 p.m. today or tomorrow and says later I'm gonna call the function set alarm and then it's like calling the connect function of the client to do some more registering of callbacks. So how does the set alarm function look like? It's a little bit more interesting. So here's the message. We get the conversation with the recipient. So because I mean, you could chat to too many people at the same time, we yield from the message. So this is also again a point where we give away the execution to do something others like waiting for an answer or for doing other kind of network transmissions. We set here the state that we are now in the ask state. We sleep and since we yield from async IO sleep here, it's also we give away the execution to other tasks that can be run concurrently. And here it's just this three times asking and here is the giving up question, the giving up. And in the end, we just set the timer, set it back to the next time. I think the code is quite easily readable and it more or less avoids the registering a lot of callbacks on some kind of deferred results like you would have done it maybe with twisted. And now handling a message. So on event when the message is received, we get from the message the conversation, we get the user ID, we get the text what was actually sent. We check if the user ID is equal to the same, to the recipient ID, to the one we wanna talk. We check if the text is positive, a positive answer. And if everything is fulfilled, we are in the right state, it is positive. And it's from our body, we just send the message that's great and go back in the ask equals false date. So we go back to the initial state in our state diagram. All right, that much about the source code. As I said, you can just check it up online. Maybe one more thing about authorization. If you write a bottle like this, you don't wanna like provide your credentials and put it somewhere in the files. So this is where the all authentication to standard comes into play. And this allows that you as a resource owner, give special rights to your application. So, and it works by using user tokens. So how does this work? Your application, all it wants to do is to use your Google account to actually send some messages and it doesn't need to know all your contact, it's just sending messages. So it requests a token with a scope of sending messages, then you get a URL, you can display to the user. This is then basically you all know this kind of screens where you then just click accept. And you get the authorization code back and you can use this code to get a token. And with this token, your application can then without knowing your password of your Google account use the Google API to work, yeah, to send messages over hangups or yeah, Google talk. All right, so just a picture to show how it looks like in the end. And yeah, it's just an easy use case but it worked in the end and he's quite happy with it. Thanks to Tom Dreyer. So this was the guy from hangups who also helped me a bit and yeah, all the pictures I took are creative comments. And thank you for your attention. And yeah, so. Hi, thanks for your talk. I actually have two small questions. Like, have you thought of implementing this on other communication supports? Like for example, Telegram, WhatsApp, all this kind of stuff. What, sorry. Have you thought of other communication supports apart from hangouts? Like WhatsApp, Facebook, Telegram, are you implementing it? And the other question is, I actually thought of making something like this, having a chronic disease myself to force to just remember stuff. But what I thought would be really interesting in this would be to have some kind of AI or machine learning to actually, for having the computer knowing when I'm more keen to forget to take it or this kind of stuff. So is it some kind of idea you have in the future? Because I would be really interested in participating then. Yeah, I also thought about this because I mean, now I now get the messages. So when he took it and maybe over the weekend, he if it's more easy to forget, right? I mean, maybe you're in a party or whatever and it's not just not the right time. You're like, you don't do anything. And of course, you could then run a lot of statistical analysis on it. And I mean, since I work as a data scientist, of course, if you would have a lot of information about this, you could do some statistics. You could even predict that on a weekend. Yeah, but on the other end, it's always with private information, right? Because, yeah, but I think this is a good idea. And I think the basic ideas, and so to your first question, could also be easily done on Facebook. And so there are a lot of libraries, if you start looking for it. And there are also a lot of bot libraries that could help with finding the right answers or making maybe the conversation a lot more interesting. So there are stuff like this. I wanted to keep it simple as a first try, but yeah, now one could definitely build on it. More questions? Hi, yeah, that's really great. Have you thought of putting any kind of link back to maybe something physical, like opening a packet or so that you both have proof as well as his yes command that he has taken his insulin? Excuse me, Lagos. So say he had to open a packet that moved a switch and that was recorded that he had. I'm more thinking about say people of Alzheimer's who need to be reminded to take tablets. Have you thought of expanding it in that kind of way? So I mean, in the physio world, they're really keen on making sure that people do actually take their tablets as opposed to just saying, yes, they've taken them. So have you thought of expanding it so that you can have a switch that saw that someone had opened a pill box, say? Ah, okay, now I understand, yeah. I mean, then it gets, of course, more complicated. You would need to have the device or put those insulin pumps, for instance. Some already have some technique in it. And if one could access that protocol and then you could maybe even, yeah, he could connect his smartphone to that device. I know that there's a lot going on. For instance, the measurement of the blood sugar is now just like three months ago, there was a new device from Libre, which is constantly measuring your blood sugar. You have it on your right arm and you can just read it out and on a second-by-second basis, which is much better than doing it a conventional way. And of course, one could trigger back. So if you took it, then you will also get from this sensor that the blood sugar goes down. And so there's endless possibilities, but then I would need to like, I mean, it was not a commercial idea or something, it was just for me a use case, but I think it's definitely possible in a technical sense and one could follow up on that, yeah, definitely. More questions? Right, that was fascinating. Thank you very much again, Brian. Thank you.