Chat Robots Next Level Tooling
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Michaelis, Ole
Developers are lazy! So we are great in creating tooling for our daily work. But it has its weaknesses, we are creating a tons of scripts on our local maschine, sometimes we share them via git or other vcs systems. But all over all this tooling sucks when it comes to collaboration. We developers also love hanging out in chat rooms like campfire or jabber. Why not combine this via chat robots. Our tooling would be available to everyone without installing wired shell scripts plus we can get rid if questions like: Do you have the deploy lock?
 Music Alright everyone. I had the idea to do a very German thing at the beginning, so I wanted to start on time. It didn't work out, but it wasn't about me, it was about you. You weren't here then. Alright, so we are running three minutes late, I think that's fine. I'd like to start with a question. Why do you program and review? Oh, actually this is more an historic question. I want you to think about it, and not to answer it to me. I hope that one of your answers is because it's optimized for developer happiness. And if that is right, why is your tooling so shitty? Laughter I came up with a question on my own, because I found myself in this situation, and this is basically the story of this talk. So it's about chat robots and the likes of a tooling. You can find me at coasters on Twitter. So if you got any feedback, especially the positive one, please just tweet me. The negative one I'd rather likely to be a receiving person. As developers, we are hanging around in chat rooms since ever, but why do we do it? I think, no, let me phrase it this way. I'd like to start, or I'd like to answer this question with a quote. This one is from Chris Wandsprout, CEO of GetUp. And he said, if you have a sick day, you're not going to miss everything if your communication is set up to be distributed. I think this is one very good reason to hang around in chat rooms. I don't know if you have ever experienced that as well, but if you're not in the office one day, and the more you're relying on mediums which are replayable, the less likely you're going to miss something important. Like most of the companies in the world, my company is not GetUp. So we are not completely distributed. We have a branch office in San Francisco, our headquarters in Hamburg, Germany, and we have one office in Tokyo. So we are distributed as well, but we are not like all over the world. We are just a little bit distributed in three different locations. But still, if I'm sick, I don't want to miss something which is going on in the office. When I joined Jim Nu, I found a repository which is named Admin Server Scripts. This one should rather be a Hubard Scripts collection, but all of a sudden it was a big collection of bash files. It does all different things regarding servers, adding new ones, deleting ones, all kinds, admin related. Chatrooms are awesome. And chatrooms are awesome for three main reasons. And my first reason is their asynchronity. So chatrooms are asynchronous. What does it mean? I think for us developers, it's pretty clear what asynchronous communication means, right? If you want to know something from me, and I'm focused working, I do not want you to interrupt me. Very unlikely other people, especially the product manager, know that. So they're very likely to just disturb you while you're in the tunnel, right? You're very focused working, and then they, you know, the situation, they step up right behind you, and you see them stepping up, and they think they're so friendly, not tapping on your shoulder, but they are annoying as hell, just like waiting there, tipping with a feed. Oh, my God. So this is synchronous communication, and this is so annoying. So chatrooms take that part away from us. You can ask me something, and I can come back to you if I'm ready answering. Second reason, chatrooms are persistent. So whatever you write, I can read whenever I want to. If you're using the more hip toolings like Slack or HipChat, you can even search whatever was up later or was up before. On other solutions, your client might implement that as well. So, and actually the third reason is chatrooms make you collaborate better, and this is the most important thing for this talk. So you can collaborate with your coworkers. You know, there's something going on, and everyone is in the room, everyone is writing, and you can't just go straight solving that problem, which is occurring. On the other hand, we are putting more and more services into the web, right? We are all, I think, most of us, are web developers. So this kind of clashes, right? So we are so used to chat, but then we are moving everything into web. And I think this is okay because not everything fits into the chat pattern. Some things might require a slider, radio buttons, checkboxes, or this stuff you do not have in chat. Like deployments. There are so many good deployment tools out there, but most of them are somehow bound to a web interface. Deploying an error from Etsy is bound to a web interface. Or even worse, tools like Capistrano, they utilize the shell or bash. This is not collaborative at all. I like to talk about incidents. So, besides the fact that I am a programmer at my company, I did ops and on-call for about a year at Gemnu. So I want to share my experience about alerting and monitoring. So what happens if there is an incident? Usually people SSH into a machine and then based on their experience and their knowledge, querying log files, and making assumptions based on what they know and based on their experience. Then they come back to the chat and report their assumptions. So you have no idea how they made these assumptions, how they could conclude to that. So they still come back to the chat, but you are missing an important part. And then we have tools like Nages. Do you know Nages? I think it is even written in something really crude. I do not know, it is nothing hip. It considers itself as a web app, but it is still using frames. So, I do not know, this is just a crazy thing, but it is still in the web. So I can use it more or less good in a browser. You can not copy URLs. If you have ever used that, you cannot copy URLs because it has a frame set. Oh my God, that is so shitty. Anyway, we are talking about, on the one hand, we have this chat stuff, and on the other hand, we have this web. So, both is cool. So we need something to bridge the technologies together, the web and the chat. Here, Hubert kicks in. Who of you have ever heard about Hubert? That is almost half of the audience. It is cool. So Hubert is written in JavaScript and running a node on the V8 engine. And for this talk, I like to take Hubert just as an example. There are similar chat robots like Lita or Twyke written in Ruby. So, you are at RubyConf, so Lita and Twyke on Ruby based on Ruby. But for this talk, I like more to talk about the basics concepts of a chatbot. So it is not about the language they are written in. Hubert is a bridge between everything which happens outside of the chat and tries to bring it back to the chat. Imagine all your deployments can be triggered from the chat. All the alerts suddenly arrive at a central place also your chat. When these things land in your chat rooms, that brings several advantages. First, sharing is caring. Everything is directly shared with your coworkers. Let me tell you a little story of Jim. So, when we have a big farm of servers, like 300 of them, and when one is down and has an outage, our support staff is dropping in and asking what is going on with that server. If our tool would report into the chat room, they could just hang around there and they would know the server is up or down. I have a demo on that later on as well. Also, it is preserved history, right? Everything is recorded. Everyone can search for recent outages. Imagine your tooling or chatbot could post links directly to your Yammerer or whatever you use for your communication. Directly linking to the corresponding chat line. My favorite feature is collaborating. You have a direct place to collaborate. Let's think about the example of a server outage I mentioned before. The server is down. Everyone was like SSHing into the machine and pulling stuff out of there. But now, if you have the tooling in the chat room, you could ask your chatbot for the corresponding log lines, and then you can make assumptions right in the chat with your colleagues together. So, they would know what kind of files you were asking for. I think this is a super powerful tool. You could easily pull log lines with HuWod, and then you can make assumptions together. Teaching by doing. This is a quote from Jesse Newland. He gave a talk in RubyFusa last year. It's called ChatOps by GitHub. You will find a link to this video at the end of my deck if I upload it later. And I think this pattern of doing it collaboratively in the chat is a really cool thing to onboard people. This is a war room. This is another war room. This is the old war room of GitHub HQ2, as far as I know. And I want to symbolize a certain chat pattern, which is again related to all this op stuff, because I did this for quite a while. So when there's an incident, and you can judge by the incident or by the error message, what is, the problem is kind of a bigger one. You're going to open up a new chat room, gather everything who can contribute something in this chat room, and then you can fix it together. So people who are interested in this pattern or in this incident can just join and silently watch whatever is going on and check whatever is up. And even later, people could have the possibility to follow up on to check what was going on. And you can use this transcript of the chat for a later post-mortem analysis. But enough about failures. I think one of the biggest reasons why Hubert is around is for fun. So you can post images, give videos, or doing whatever kind of bullshit you have in your head, just in the chat, together with your colleagues. It's pretty cool. So imagine everything Node can do. TCP, HTTP, network, email, it's up to you. Everything you can do with Node, you can do with your chatbot. You can give it a chat interface and work on that together with your colleagues. In my old company, we did a pretty cool hack. This is what it looked like. So what you see here is an Adreno, a breadboard, and an Adobozer. What we did is, so we had a pretty big office back then, and we were way too lazy to walk all up to the door to ring the buzzer. I don't know, we had a problem, we were lazy. So what we did is we connected this Adreno to the Adobozer, and then we wrote, or a co-worker of mine back then, wrote a script which you could consider as an HTTP server. After the TCP handshake, the next line was HTTP something, get slash, we would consider this as a valid request, and then open the door with a bot. So what we did was we were putting an HTTP interface to our door, and with that, we could write all kind of apps. So we had an Android app, an iPhone app, a bookmarklet, a state-aspire bookmarklet, applet, whatever, and I wrote a script for our bot. So our bot could basically open the office door. This was pretty cool. If you're interested in this particular kind of stuff, it's still open source and get up, and you can find this also at the end of this deck. It turned out that my old CDO really loved this setup, so when he joined this next company, he created an improved version of that, but it's basically, it's still running the same code, and it's just a better case without the breadboard. All that is done with the power of CoffeeScript, and with that, everyone can easily extend it. That is the basic part of Hubo. There are tons of scripts already available, pre-built, but due to the fact that it is all CoffeeScript or JavaScript, everyone can contribute pretty easily. So customizing your bot is easy. You don't need to be a CS computer engineer. If you know how to get a few lines of JavaScript working, you can make it work, and you can write your own scripts. You don't need the most freak-out software architectures for this. It's just ten lines of JavaScript, and you can make something work. I wanted to show you how a basic Hubo script looks like. So as good engineers, we start with the documentation. This part is pretty... It's necessary because Hubo uses that to generate the documentation. So you need the description, dependencies, configuration, commands, nodes, and the order. Whatever. Who does documentation anyway? But then the sign is pretty important. You have to fetch the instance of a YoBot. You do it with a module, exports, and then you get the instance of the bot. Here, we're going to start. Here we can do this very first interaction with the bot. I'll give you some sex read through code. I mean, it's pretty easy, right? At the first line, you see robot.here. So whenever someone is writing something badger, he would actually just send out the line, too. And the next, the robot.respond is for direct commands to the bot. So you have to write Hubo, open the damn doors, for example. And then he would actually reply with a second line. Or the first. Hubo also has an HTTP interface, which is pretty cool for all kinds of webhooks. So imagine Travis.ei or GitHub. Everything which basically has a webhook can communicate to your bot and then in your chatroom. Think your application can also do this. Your application could report with this webhooks to the bot and make some kind of magic happen. This is pretty cool as well. And it also has an event system inbuilt. This is to decouple components. I wrote this event system because there was one thing which annoys me. So there's a command called ship it, which actually just posting motivational squirrel. I want this command to actually ship my code. So what I did was just admitting the event and then everyone could just implement their deploy logic on their own in a different module. The only limit is your imagination. Think of how you could improve your team's workflow with automating things. You could run configuration management from chat, mitigating DDoS attacks from chat, varying locks or databases from the chat, or display graphs. Whatever comes into your mind and whatever could improve your team's workflow could be done from the chat. And you can get rid of all the shitty tooling you have somewhere else which is not collaborative in most of the times. So I also wanted to show something. Can we get this a little less noisy? Does it work? Okay, I think this works. So let's see. I hope the live demo gods are with me. My company last week while I was in San Francisco already switched to Slack. So I was talking to Artnitz to keep our old hipchat open because I didn't have the time to move our chatbot over. So here's the gym bot, which is our keyword. Let's start with some very basic commands. So I want the bot to image me RubyConf. What's that? Sorry. Good point. All right. Okay, so I asked the bot up here to image me RubyConf and then he's replying with an image link. So I have to write this at gym bot, which is his actual name, and then I could write the command. So let's try it again. Sometimes it's a different image. So here you see it's a different image. I hope I have some stuff set up here. Okay, so you could also, and this is one of my favorite features. You might guess what's happening now, right? So you could ask the bot to mustachify one of your coworkers or anyone else. This was funny though. The first time I tried this, this was working all the time and now it works sometimes. Another feature, and now we're getting to the parts we wrote on our own. When I having a discussion in a channel, I could ask my coworkers on what is going on with this ticket. And then posting the link and Hubert will check that this is a link to our issue tracker. And then hopefully he will reply with the issue title. So it saves me to click on the link and to do this shitty HTTP basic out, which is usually in front of our issue tracker. So he's just replying on what the issue is about, even if there's just a link. This also works the other way around, but I think we have disabled it. So if he found an issue number, he might look it up and then reply back. But again, I think we have disabled it because it happened in a different channel. There's a spot channel here. It happened that these bots started talking to each other. Because the Jenkins bot was reporting that there was something wrong and then Hubert replied, and oh my God, that's why we disabled that. Similarly, another thing we did, and that's one of the things I mentioned before. Imagine you're a supporter in our company and you want to know the status of a server. So you could basically ask the bot what is the status of any given server. So in our web platform, everything has a default in a route, which is slash common slash status, which just reports HTTP statuses back. And based on that, you can judge whether a server's health is good or not. So we can ask Jim for this web server or we can also ask for this W server. We need a number of objectives there. So at least these two servers are up. I could bet there is something down at the moment, but I don't know. Okay, the last thing I want to show is one of my favorite features. At Jimloo, we are 180 people at the moment. We grew pretty fast and it happened that there were people hired. I have no idea who they were. So it happened that people walked into our office and told me, oh, you actually have to talk to Ayla about that. I'm like, who's that? So I can ask our bot who's Ayla and he will actually post an image. Hopefully. Yay. So there's Ayla. She's one of the Spanish team. So this works not only for Ayla, so I want to prove that it's actually not a fake thing. Also for our founders, for example, or also for me, but for me, I have to use my last name because this, whoops, this script isn't like too intelligent because if I just search for my first name, it would actually find Johanna Zulike sometimes. Because my first name is part of her name whatsoever. This is complicated. But actually this was pretty useful for most of us. And this is also one of the most features we have at our bot. Let's see. Presentation view. I don't see anything. What about that? Good. Okay, this was just to give you an idea on what you actually can do with your bot. Again, it's just programming. It's just nodes. So whatever you can do with node, you can actually implement in your bot and give it a chat interface. Developers love tooling. So we tend to spend a good amount of work time with this. And I think this is not necessarily bad. And I think this is also what is awesome about Node.js is Java script. And with Java script, it unites different back and front and programming languages. So in the Java script community, there are people out of the Ruby community, but also of the Python community, the PHP community, and whatever you can think of, whoever does web, and now even more people who are not related to web, they are all uniting in this community, and everyone is bringing in his or her best tools, which I think is pretty neat. And this is pretty unique to this language. I have another quote. This one is from Garin Means, and she wrote a blog post about tooling. We need more engineers and more productive engineers. We don't need to send people on quests through the dark woods of an issue tracker. When I started at a company, my first two questions are, what is your issue tracker and what is your chat program? At Gemnu, the answer was our issue tracker is track, and the chat program was Java. Somehow I still joined, out of other reasons, obviously. But for me, these are very important questions. These are the tools I work the most with. And even if we don't want to admit that, but as developers, we are spending not the amount of time we want to, and our editors, right? We spend a lot of our time communicating with people. So our issue tracker and the chat software are pretty important pieces in the whole workflow. So I wanted to share also the challenges we had in implementing this company-wide chat workflow with everyone. I think the hardest challenge was, and still is, to get everyone on board, also the non-technical people. Because for people with a technical background, it's pretty obvious that chat programs are cool, and as for communication is cool, and the fact that I do not have to reply instantly is a cool thing. But for other people, they might prefer the way that they have direct replies when they just step up to you and asking you questions. So this is also a thing we are still fighting with, and sending people away would be so stupid. Imagine I'm working on something, and they interrupt me, and then it would send them away, saying, no, no, no, you have to write me on chat. And this would be so stupid, and we obviously don't do that. So it's kind of hard to educate them. But we really want to do that, or I really want this to happen. My idea is to make this chat as attractive as possible with all these little neat things that chatbot can do, so that people actually want to do this as well. So I want you to level up your tooling. You can document your deployments, coordinate your work, and have a ton of fun with these chatbots. So that's a pretty cool thing. My name is Ole Michieles. I'm a web nerd from Hamburg working with Jim Doop. And you can find me at Kostas. Thank you very much.
 Music  Alright everyone.  I had the idea to do a very German thing at the beginning, so I wanted to start on time.  It didn't work out, but it wasn't about me, it was about you.  You weren't here then.  Alright, so we are running three minutes late, I think that's fine.  I'd like to start with a question.  Why do you program and review?  Oh, actually this is more an historic question.  I want you to think about it, and not to answer it to me.  I hope that one of your answers is because it's optimized for developer happiness.  And if that is right, why is your tooling so shitty?  Laughter  I came up with a question on my own, because I found myself in this situation,  and this is basically the story of this talk.  So it's about chat robots and the likes of a tooling.  You can find me at coasters on Twitter.  So if you got any feedback, especially the positive one, please just tweet me.  The negative one I'd rather likely to be a receiving person.  As developers, we are hanging around in chat rooms since ever, but why do we do it?  I think, no, let me phrase it this way.  I'd like to start, or I'd like to answer this question with a quote.  This one is from Chris Wandsprout, CEO of GetUp.  And he said, if you have a sick day, you're not going to miss everything  if your communication is set up to be distributed.  I think this is one very good reason to hang around in chat rooms.  I don't know if you have ever experienced that as well,  but if you're not in the office one day,  and the more you're relying on mediums which are replayable,  the less likely you're going to miss something important.  Like most of the companies in the world, my company is not GetUp.  So we are not completely distributed.  We have a branch office in San Francisco, our headquarters in Hamburg, Germany,  and we have one office in Tokyo.  So we are distributed as well, but we are not like all over the world.  We are just a little bit distributed in three different locations.  But still, if I'm sick, I don't want to miss something which is going on in the office.  When I joined Jim Nu, I found a repository which is named Admin Server Scripts.  This one should rather be a Hubard Scripts collection,  but all of a sudden it was a big collection of bash files.  It does all different things regarding servers,  adding new ones, deleting ones, all kinds, admin related.  Chatrooms are awesome.  And chatrooms are awesome for three main reasons.  And my first reason is their asynchronity.  So chatrooms are asynchronous.  What does it mean?  I think for us developers, it's pretty clear what asynchronous communication means, right?  If you want to know something from me, and I'm focused working,  I do not want you to interrupt me.  Very unlikely other people, especially the product manager, know that.  So they're very likely to just disturb you while you're in the tunnel, right?  You're very focused working, and then they, you know, the situation,  they step up right behind you, and you see them stepping up,  and they think they're so friendly, not tapping on your shoulder,  but they are annoying as hell, just like waiting there, tipping with a feed.  Oh, my God.  So this is synchronous communication, and this is so annoying.  So chatrooms take that part away from us.  You can ask me something, and I can come back to you if I'm ready answering.  Second reason, chatrooms are persistent.  So whatever you write, I can read whenever I want to.  If you're using the more hip toolings like Slack or HipChat,  you can even search whatever was up later or was up before.  On other solutions, your client might implement that as well.  So, and actually the third reason is chatrooms make you collaborate better,  and this is the most important thing for this talk.  So you can collaborate with your coworkers.  You know, there's something going on, and everyone is in the room,  everyone is writing, and you can't just go straight solving that problem,  which is occurring.  On the other hand, we are putting more and more services into the web, right?  We are all, I think, most of us, are web developers.  So this kind of clashes, right?  So we are so used to chat, but then we are moving everything into web.  And I think this is okay because not everything fits into the chat pattern.  Some things might require a slider, radio buttons, checkboxes,  or this stuff you do not have in chat.  Like deployments.  There are so many good deployment tools out there,  but most of them are somehow bound to a web interface.  Deploying an error from Etsy is bound to a web interface.  Or even worse, tools like Capistrano, they utilize the shell or bash.  This is not collaborative at all.  I like to talk about incidents.  So, besides the fact that I am a programmer at my company,  I did ops and on-call for about a year at Gemnu.  So I want to share my experience about alerting and monitoring.  So what happens if there is an incident?  Usually people SSH into a machine and then based on their experience  and their knowledge, querying log files,  and making assumptions based on what they know and based on their experience.  Then they come back to the chat and report their assumptions.  So you have no idea how they made these assumptions,  how they could conclude to that.  So they still come back to the chat,  but you are missing an important part.  And then we have tools like Nages.  Do you know Nages?  I think it is even written in something really crude.  I do not know, it is nothing hip.  It considers itself as a web app, but it is still using frames.  So, I do not know, this is just a crazy thing,  but it is still in the web.  So I can use it more or less good in a browser.  You can not copy URLs.  If you have ever used that, you cannot copy URLs  because it has a frame set.  Oh my God, that is so shitty.  Anyway, we are talking about, on the one hand,  we have this chat stuff, and on the other hand, we have this web.  So, both is cool.  So we need something to bridge the technologies together,  the web and the chat.  Here, Hubert kicks in.  Who of you have ever heard about Hubert?  That is almost half of the audience.  It is cool.  So Hubert is written in JavaScript and running a node on the V8 engine.  And for this talk, I like to take Hubert just as an example.  There are similar chat robots like Lita or Twyke written in Ruby.  So, you are at RubyConf, so Lita and Twyke on Ruby based on Ruby.  But for this talk, I like more to talk about the basics concepts  of a chatbot.  So it is not about the language they are written in.  Hubert is a bridge between everything which happens outside of the chat  and tries to bring it back to the chat.  Imagine all your deployments can be triggered from the chat.  All the alerts suddenly arrive at a central place also your chat.  When these things land in your chat rooms, that brings several advantages.  First, sharing is caring.  Everything is directly shared with your coworkers.  Let me tell you a little story of Jim.  So, when we have a big farm of servers, like 300 of them,  and when one is down and has an outage,  our support staff is dropping in and asking what is going on with that server.  If our tool would report into the chat room,  they could just hang around there and they would know the server is up or down.  I have a demo on that later on as well.  Also, it is preserved history, right?  Everything is recorded.  Everyone can search for recent outages.  Imagine your tooling or chatbot could post links directly to your Yammerer  or whatever you use for your communication.  Directly linking to the corresponding chat line.  My favorite feature is collaborating.  You have a direct place to collaborate.  Let's think about the example of a server outage I mentioned before.  The server is down.  Everyone was like SSHing into the machine and pulling stuff out of there.  But now, if you have the tooling in the chat room,  you could ask your chatbot for the corresponding log lines,  and then you can make assumptions right in the chat with your colleagues together.  So, they would know what kind of files you were asking for.  I think this is a super powerful tool.  You could easily pull log lines with HuWod,  and then you can make assumptions together.  Teaching by doing.  This is a quote from Jesse Newland.  He gave a talk in RubyFusa last year.  It's called ChatOps by GitHub.  You will find a link to this video at the end of my deck if I upload it later.  And I think this pattern of doing it collaboratively in the chat  is a really cool thing to onboard people.  This is a war room.  This is another war room.  This is the old war room of GitHub HQ2, as far as I know.  And I want to symbolize a certain chat pattern,  which is again related to all this op stuff, because I did this for quite a while.  So when there's an incident, and you can judge by the incident or by the error message,  what is, the problem is kind of a bigger one.  You're going to open up a new chat room,  gather everything who can contribute something in this chat room,  and then you can fix it together.  So people who are interested in this pattern or in this incident  can just join and silently watch whatever is going on and check whatever is up.  And even later, people could have the possibility to follow up on to check what was going on.  And you can use this transcript of the chat for a later post-mortem analysis.  But enough about failures.  I think one of the biggest reasons why Hubert is around is for fun.  So you can post images, give videos,  or doing whatever kind of bullshit you have in your head,  just in the chat, together with your colleagues.  It's pretty cool.  So imagine everything Node can do.  TCP, HTTP, network, email, it's up to you.  Everything you can do with Node, you can do with your chatbot.  You can give it a chat interface and work on that together with your colleagues.  In my old company, we did a pretty cool hack.  This is what it looked like.  So what you see here is an Adreno, a breadboard, and an Adobozer.  What we did is, so we had a pretty big office back then,  and we were way too lazy to walk all up to the door to ring the buzzer.  I don't know, we had a problem, we were lazy.  So what we did is we connected this Adreno to the Adobozer,  and then we wrote, or a co-worker of mine back then,  wrote a script which you could consider as an HTTP server.  After the TCP handshake, the next line was HTTP something, get slash,  we would consider this as a valid request, and then open the door with a bot.  So what we did was we were putting an HTTP interface to our door,  and with that, we could write all kind of apps.  So we had an Android app, an iPhone app, a bookmarklet,  a state-aspire bookmarklet, applet, whatever,  and I wrote a script for our bot.  So our bot could basically open the office door.  This was pretty cool.  If you're interested in this particular kind of stuff,  it's still open source and get up, and you can find this also at the end of this deck.  It turned out that my old CDO really loved this setup,  so when he joined this next company, he created an improved version of that,  but it's basically, it's still running the same code,  and it's just a better case without the breadboard.  All that is done with the power of CoffeeScript,  and with that, everyone can easily extend it.  That is the basic part of Hubo.  There are tons of scripts already available, pre-built,  but due to the fact that it is all CoffeeScript or JavaScript,  everyone can contribute pretty easily.  So customizing your bot is easy.  You don't need to be a CS computer engineer.  If you know how to get a few lines of JavaScript working,  you can make it work, and you can write your own scripts.  You don't need the most freak-out software architectures for this.  It's just ten lines of JavaScript, and you can make something work.  I wanted to show you how a basic Hubo script looks like.  So as good engineers, we start with the documentation.  This part is pretty...  It's necessary because Hubo uses that to generate the documentation.  So you need the description, dependencies, configuration, commands, nodes, and the order.  Whatever. Who does documentation anyway?  But then the sign is pretty important.  You have to fetch the instance of a YoBot.  You do it with a module, exports, and then you get the instance of the bot.  Here, we're going to start.  Here we can do this very first interaction with the bot.  I'll give you some sex read through code.  I mean, it's pretty easy, right?  At the first line, you see robot.here.  So whenever someone is writing something badger,  he would actually just send out the line, too.  And the next, the robot.respond is for direct commands to the bot.  So you have to write Hubo, open the damn doors, for example.  And then he would actually reply with a second line.  Or the first.  Hubo also has an HTTP interface, which is pretty cool for all kinds of webhooks.  So imagine Travis.ei or GitHub.  Everything which basically has a webhook can communicate to your bot and then in your chatroom.  Think your application can also do this.  Your application could report with this webhooks to the bot and make some kind of magic happen.  This is pretty cool as well.  And it also has an event system inbuilt.  This is to decouple components.  I wrote this event system because there was one thing which annoys me.  So there's a command called ship it, which actually just posting motivational squirrel.  I want this command to actually ship my code.  So what I did was just admitting the event and then everyone could just implement their deploy logic on their own in a different module.  The only limit is your imagination.  Think of how you could improve your team's workflow with automating things.  You could run configuration management from chat, mitigating DDoS attacks from chat,  varying locks or databases from the chat, or display graphs.  Whatever comes into your mind and whatever could improve your team's workflow could be done from the chat.  And you can get rid of all the shitty tooling you have somewhere else which is not collaborative in most of the times.  So I also wanted to show something.  Can we get this a little less noisy?  Does it work?  Okay, I think this works.  So let's see.  I hope the live demo gods are with me.  My company last week while I was in San Francisco already switched to Slack.  So I was talking to Artnitz to keep our old hipchat open because I didn't have the time to move our chatbot over.  So here's the gym bot, which is our keyword.  Let's start with some very basic commands.  So I want the bot to image me RubyConf.  What's that?  Sorry. Good point.  All right.  Okay, so I asked the bot up here to image me RubyConf and then he's replying with an image link.  So I have to write this at gym bot, which is his actual name, and then I could write the command.  So let's try it again. Sometimes it's a different image.  So here you see it's a different image.  I hope I have some stuff set up here.  Okay, so you could also, and this is one of my favorite features.  You might guess what's happening now, right?  So you could ask the bot to mustachify one of your coworkers or anyone else.  This was funny though.  The first time I tried this, this was working all the time and now it works sometimes.  Another feature, and now we're getting to the parts we wrote on our own.  When I having a discussion in a channel, I could ask my coworkers on what is going on with this ticket.  And then posting the link and Hubert will check that this is a link to our issue tracker.  And then hopefully he will reply with the issue title.  So it saves me to click on the link and to do this shitty HTTP basic out, which is usually in front of our issue tracker.  So he's just replying on what the issue is about, even if there's just a link.  This also works the other way around, but I think we have disabled it.  So if he found an issue number, he might look it up and then reply back.  But again, I think we have disabled it because it happened in a different channel.  There's a spot channel here.  It happened that these bots started talking to each other.  Because the Jenkins bot was reporting that there was something wrong and then Hubert replied,  and oh my God, that's why we disabled that.  Similarly, another thing we did, and that's one of the things I mentioned before.  Imagine you're a supporter in our company and you want to know the status of a server.  So you could basically ask the bot what is the status of any given server.  So in our web platform, everything has a default in a route, which is slash common slash status,  which just reports HTTP statuses back.  And based on that, you can judge whether a server's health is good or not.  So we can ask Jim for this web server or we can also ask for this W server.  We need a number of objectives there.  So at least these two servers are up.  I could bet there is something down at the moment, but I don't know.  Okay, the last thing I want to show is one of my favorite features.  At Jimloo, we are 180 people at the moment.  We grew pretty fast and it happened that there were people hired.  I have no idea who they were.  So it happened that people walked into our office and told me,  oh, you actually have to talk to Ayla about that.  I'm like, who's that?  So I can ask our bot who's Ayla and he will actually post an image.  Hopefully. Yay.  So there's Ayla. She's one of the Spanish team.  So this works not only for Ayla, so I want to prove that it's actually not a fake thing.  Also for our founders, for example, or also for me,  but for me, I have to use my last name because this, whoops,  this script isn't like too intelligent because if I just search for my first name,  it would actually find Johanna Zulike sometimes.  Because my first name is part of her name whatsoever.  This is complicated.  But actually this was pretty useful for most of us.  And this is also one of the most features we have at our bot.  Let's see.  Presentation view.  I don't see anything.  What about that?  Good.  Okay, this was just to give you an idea on what you actually can do with your bot.  Again, it's just programming.  It's just nodes.  So whatever you can do with node, you can actually implement in your bot  and give it a chat interface.  Developers love tooling.  So we tend to spend a good amount of work time with this.  And I think this is not necessarily bad.  And I think this is also what is awesome about Node.js  is Java script.  And with Java script, it unites different back and front and programming languages.  So in the Java script community, there are people out of the Ruby community,  but also of the Python community, the PHP community,  and whatever you can think of, whoever does web,  and now even more people who are not related to web,  they are all uniting in this community,  and everyone is bringing in his or her best tools,  which I think is pretty neat.  And this is pretty unique to this language.  I have another quote.  This one is from Garin Means, and she wrote a blog post about tooling.  We need more engineers and more productive engineers.  We don't need to send people on quests through the dark woods of an issue tracker.  When I started at a company, my first two questions are,  what is your issue tracker and what is your chat program?  At Gemnu, the answer was our issue tracker is track,  and the chat program was Java.  Somehow I still joined, out of other reasons, obviously.  But for me, these are very important questions.  These are the tools I work the most with.  And even if we don't want to admit that,  but as developers, we are spending not the amount of time we want to,  and our editors, right?  We spend a lot of our time communicating with people.  So our issue tracker and the chat software are pretty important pieces  in the whole workflow.  So I wanted to share also the challenges we had  in implementing this company-wide chat workflow with everyone.  I think the hardest challenge was, and still is, to get everyone on board,  also the non-technical people.  Because for people with a technical background,  it's pretty obvious that chat programs are cool,  and as for communication is cool,  and the fact that I do not have to reply instantly is a cool thing.  But for other people, they might prefer the way that they have direct replies  when they just step up to you and asking you questions.  So this is also a thing we are still fighting with,  and sending people away would be so stupid.  Imagine I'm working on something,  and they interrupt me, and then it would send them away,  saying, no, no, no, you have to write me on chat.  And this would be so stupid, and we obviously don't do that.  So it's kind of hard to educate them.  But we really want to do that, or I really want this to happen.  My idea is to make this chat as attractive as possible  with all these little neat things that chatbot can do,  so that people actually want to do this as well.  So I want you to level up your tooling.  You can document your deployments, coordinate your work,  and have a ton of fun with these chatbots.  So that's a pretty cool thing.  My name is Ole Michieles.  I'm a web nerd from Hamburg working with Jim Doop.  And you can find me at Kostas.  Thank you very much.
Chat_Robots_Next_Level_Tooling_0_83.png Chat_Robots_Next_Level_Tooling_84_131.png Chat_Robots_Next_Level_Tooling_132_239.png Chat_Robots_Next_Level_Tooling_240_347.png Chat_Robots_Next_Level_Tooling_348_455.png Chat_Robots_Next_Level_Tooling_456_515.png Chat_Robots_Next_Level_Tooling_516_659.png Chat_Robots_Next_Level_Tooling_660_1907.png Chat_Robots_Next_Level_Tooling_1908_2315.png Chat_Robots_Next_Level_Tooling_2316_8063.png Chat_Robots_Next_Level_Tooling_8064_11951.png Chat_Robots_Next_Level_Tooling_11952_18203.png Chat_Robots_Next_Level_Tooling_18204_18659.png Chat_Robots_Next_Level_Tooling_18660_20663.png Chat_Robots_Next_Level_Tooling_20664_21071.png Chat_Robots_Next_Level_Tooling_21072_21587.png Chat_Robots_Next_Level_Tooling_21588_22667.png Chat_Robots_Next_Level_Tooling_22668_22715.png Chat_Robots_Next_Level_Tooling_22716_22763.png Chat_Robots_Next_Level_Tooling_22764_22859.png Chat_Robots_Next_Level_Tooling_22860_22919.png Chat_Robots_Next_Level_Tooling_22920_25463.png Chat_Robots_Next_Level_Tooling_25464_26627.png Chat_Robots_Next_Level_Tooling_26628_27407.png Chat_Robots_Next_Level_Tooling_27408_28415.png Chat_Robots_Next_Level_Tooling_28416_30383.png Chat_Robots_Next_Level_Tooling_30384_33035.png Chat_Robots_Next_Level_Tooling_33036_33203.png Chat_Robots_Next_Level_Tooling_33204_33851.png Chat_Robots_Next_Level_Tooling_33852_33935.png Chat_Robots_Next_Level_Tooling_33936_34427.png Chat_Robots_Next_Level_Tooling_34428_39659.png Chat_Robots_Next_Level_Tooling_39660_39863.png Chat_Robots_Next_Level_Tooling_39864_39923.png Chat_Robots_Next_Level_Tooling_39924_40019.png Chat_Robots_Next_Level_Tooling_40020_40163.png Chat_Robots_Next_Level_Tooling_40164_40171.png