 I had the idea to do a very German thing at the beginning, so I wanted to start on time. Didn't work out, but it wasn't about me, it was about you. You weren't here then. All right, 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? 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 legs 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. 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 human scripts collection, but all of a sudden it was a big collection of batch files. It does all different things regarding servers, adding new ones, deleting ones, all kinds admin related. Chat rooms are awesome. And chat rooms are awesome for three main reasons. And my first reason is their asynchronity. So chat rooms 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 product manager, knows that. So they're very likely to just disturb you while you're in the tunnel, right? You're very focused working. And then, you know the situation? They step up right behind you, and you see them stepping up. And they think they are so friendly, not tapping on your shoulder, but they are annoying as hell, just waiting there, tipping with a feed. Oh my god. So this is synchronous communication, and this is so annoying. So chat rooms 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, chat rooms 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 chat rooms 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 a cure. 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 OK 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. Deployment 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 beside the fact that I'm a programmer at my company, I did ops and on-call for about a year at Gymnu. So I want to share my experience. I'm 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 those assumptions, how they could conclude to that. So they still come back to the chat, but you're missing an important part. And then we have tools like Nages. Do you know Nages? I think it's even written in something really crude. I don't know, it's nothing hip. And it considers itself as a web app, but it's still using frames. So I don't know, this is just a crazy thing, but it's still in the web. So I can use it with more or less good in a browser. You can't copy URLs. So if you ever use that, you cannot copy URLs because it has a frame set. Oh my god, that's so shitty. Anyway, so 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's almost half of the audience. It's cool. So Hubert is written in JavaScript and I'm 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 Twig, written in Ruby, so RubyConf, so Lita and Twig on Ruby based on Ruby. But for this talk, I like more to talk about the basics concept of a chat bot. So it's not about the language they're 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, your alerts suddenly arrive at a central place, also your chat. When these things lands 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 Ngu. So when we have a big farm or service, likely 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 if the server is up or down. I have a demo on that later on as well. Also, it's preserved history, right? Everything is recorded. Everyone can search for recent outages or posting or imagine your tooling or your chat bot could posting links directly to your Yammer or whatever you use for your communication. Directly linking to the corresponding chat line. And my favorite feature, collaborating. You have a direct place to collaborate. So let's think about the example of a server outage I mentioned before. The server is down. What we had before, everyone was like SSH'ing into the machines and then pulling stuff out of there. But now if you have the tooling in the chat room, you could ask your chat bot 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 and you could easily pull log lines with Hubot and then you can make this assumptions together. Teaching by doing. This is a quote from Jesse Newland. He gave a talk and Ruby Fuza 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 that 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 and 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, gives videos or doing whatever kind of bullshit you have in your head just in the chat together with your colleagues. This is 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 our door buzzer. So what we did is, so we had a pretty big office back then and we are way too lazy to walk all up to the door to ring the buzzer. I don't know, we were programmed to be lazy. So what we did is we connected this Adreno to the door buzzer and then we wrote or a co-worker of mine back then wrote a script which you could consider as an HTTP server. Whenever 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 bookmark led and Mac status bar bookmark led, app led, 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 stack. 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 and 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 Hubot. 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 freaked out software architectures for this. It's just 10 lines of JavaScript and you can make something work. I wanted to show you how a basic Hubot script looks like. So as good engineers we start with the documentation. This part is pretty, it's necessary because Hubot 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 this line is pretty important. You have to fetch the instance of a Hubot. 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 use 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 line two. And the next, the robot.respond is for direct commands to the bot. So you have to write Hubot open the damn doors for example and then he would actually reply almost a second line. Over the first. Hubot also has an HTTP interface which is pretty cool for all kind webhooks. So imagine Travis CI or GitHub, everything which basically has a webhook can communicate to your bot and then in your chat room. 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 little 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 emitting the event and then everyone could just implement that 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, querying logs 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 bit 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 our admins to keep our old hip chat open because I didn't have the time to move our chat bot 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, sometimes not. 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. So we have this bots channel here and it happened that these bots started to 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. It's similar, another thing we did and that's one of the things I mentioned before. So 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 status is back and based on that you can judge whether a server's health is good or not. So we can ask Jimbaud for this web server or we can also ask for this W server or we need an object 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 Jimdu 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 Ila about that and I'm like who's that? So I can ask our bot who's Ila and he will actually post me an image, hopefully. Yay, so there's Ila, she's one of the Spanish team. So this works not only for Ila 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, oops, this script isn't like too intelligent because if I just search for my first name it would actually find Johanna Zulike sometimes and because my name is, 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. 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 node 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 because Node.js is JavaScript and with JavaScript it unites different backend and front end programming languages so in the JavaScript 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 our 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 these answer were our issue tracker is track and the chat program was jubber. Somehow I still joined out of other reasons obviously but for me this 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 times with communicating 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. And I think the hardest challenge was and still is to get everyone on board also the non-technical people. Because for technical or people with a technical background it's pretty obvious that chat programs are cool and asynchronous 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, right? Imagine I'm working on something and they interrupt me and then it would send them away and say, no, no, no, you have to write me on chat and this would be so stupid and we obviously don't do that, right? So it's kind of hard to educate them. But we really want to do that or I really want this to happen. So my idea is to make this chat as attractive as possible with all this little neat things the chatbot can do so that the 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 Doe and you can find me at COSAS. That's all I got. Thank you very much.