We switched to Slack and built a Slackbot in 2 weeks: Here is How [feedly]

----
We switched to Slack and built a Slackbot in 2 weeks: Here is How
// Server Density Blog

Want to be less busy? Fancy sprightly, candy-looking bots beeping your tasks to oblivion while you bask in idle glory?

"Yes I do," said millions of email-burdened workers, who couldn't ditch last season's tools fast enough. What's not to like about Slack? Integrations are second to none. File sharing? You bet. Mobile? Duh. Design? Reportedly, the interface makes you want to lick it.

Great teams switched and made noise about it. But we didn't see reason enough to change our current setup. After years of using HipChat we'd customized everything. All commits, builds, and customer upgrades, fused with internal messages, keeping vital information at arm's length without adding noise. The hassle of switching seemed like a mountain to us.

As months rolled by, we kept hearing from teams who made the move. Very few of them talked about the interface. What made them stick to Slack, apparently, had more to do with search, synchronisation, and simple file sharing. You know, solid features.

It dawned on us, eventually, that Slack might amount to more than last year's fad. We owed it to ourselves to give it a try. And so we did. In August 2015 we turned HipChat off and set up a trial account with Slack. After using it for a week, we cast a vote.

The result of that vote was a "no".

Perhaps not surprisingly, the interface was the most contentious feature. In any case, comfortable with our evaluation and subsequent vote, we returned to HipChat. And that would've been the end of it.

But last autumn, Slack launched Posts, adding support for longform entries. Here was a feature we sorely missed. For team status updates we were using a private Google+ page. The allure of Slack Posts was in the potential of consolidating two collaboration tools into one. So, in January this year we decided to run another trial of Slack.

Making the Move

Our status update experiment soon hit an insurmountable wall. There was no easy way we could track and manage our check-ins. The entire Posts feature just didn't function or feel right. Within 24 hours we ditched Posts and went back to Google+ for our status updates.

At the same time, something interesting happened. As we crossed the 2000 cumulative message milestone (Slack's magic number), we began to appreciate the smaller things in Slack. The mobile client felt intuitive. The reconnection logic felt solid. We were able to integrate richer data, and stretch that data to get better stats. We also figured out how to get the noise level right, and liked how do not disturb functions in Slack.

As part of the transition, we asked everyone to pare down their private chats. Everything had to happen in public channels. As a result, discussions became more useful, because they happened out in the open.

Slack didn't offer more features (it doesn't do video conferencing, for example). But our decision wasn't based on the number of features. Rather, it was the compound effect of various small things that Slack gets right.

What's more, the richness of the community-built integrations is a testament to the quality of the platform. We had no trouble finding just the right extensions; which was no surprise as most developers invest their time on Slack first.

So it didn't take long before Jonathan—one of our developers—took it upon himself to build a Server Density Slackbot. Aptly named SDBot.

Building a Slackbot

Slackbots lessen the productivity cost of context switching.

Want a list of all your open alerts from Server Density? You can do this within Slack. Without interrupting your chat. With SDBot, your information gathering becomes interactive, dynamic. Most importantly, it stays "in context". That's invaluable for remote engineering teams, like ours.

Building a Slackbot is not hard. The Slack API is really easy to use. And there is a wealth of community-built software out there. You're not building things from scratch and there is plenty of help along the way. All you need is a few lines of code, and somewhere to deploy them. "While building a Slackbot I could see each line of code translate into real-time messages in a Slack channel. It's a great feeling," says Jonathan.

For our tests we hosted SDBot on BeepBoopHQ. We registered our project on their website, and they pulled the respective code straight from GitHub. That's about it. In fact, we built SDBot to work with Beep Boop out of the box, but you can pick any hosting platform and customise SDBot accordingly.

Once SDbot is installed, all you need to do is invite it to your Slack channel. And enjoy heaps of monitoring bliss from then on.

Developing SDBot

At its core, Server Density is a Python company. So, it's no coincidence that SDBot is a Python bot.

It took us 2 weeks to develop a prototype. Mind you, we didn't start from scratch. One of the first things we did was head to the Community-built Integrations page, scroll down to the Python section and fork the Limbo chatbot. Limbo provides a great plugin architecture we could built upon.

In order to pull monitoring data from Server Density we obviously made use of our own API. As with any API, we had to call methods for login and query, create requests, parse responses, et cetera. We did all that while keeping track of potentially complicated URL paths.

To circumvent those hurdles Jonathan created a Python API wrapper that abstracts all this detail (and drudgery). So, instead of:

import requests    r = requests.get(    'https://api.serverdensity.io/inventory/devices',    params = {    'token': token    }    )

We accomplished the same thing with a wrapper, and saved on unnecessary keystrokes:

from serverdensity.wrapper import Device    device = Device(token)    device.list()

Check out our Server Density API wrapper, and send us your feedback. When installing SDBot as an app, you will be asked for your Server Density token. If you use the GitHub version, you will need to set an environment variable (SD_AUTH_TOKEN) to your token. SDBot will take it from there.

Summary

Slack seems to deliver on the promise of transparent, lateral team communication—attributes we believe and depend upon.

Slackbots play a key role here. They preserve conversation context, and save time for remote teams, like ours. As part of our transition we invested some time in building a Slackbot, called SDBot. SDBot provides all the monitoring metrics you need and places them at the core of your conversation, where they belong.

Clearly, we're not the first to build a Slackbot. So we want to hear from you. Have you built one yet? What's your experience with API wrappers?

SDBot is open source and you can get it here. We encourage you to make pull requests and tell us what you'd like SDBot to do.

The post We switched to Slack and built a Slackbot in 2 weeks: Here is How appeared first on Server Density Blog.

----

Shared via my feedly reader

Sent from my iPhone