But automation can be tough and can sometimes prove to be costly. How can Github Actions help harden our code and give us more time to work on features instead of bugs?

• What are Github Actions?
• What is CI/CD?
• What are we going to build?
• Part 0: Setting up a project
• Part 1: Automating tests
• Part 2: Post new pull requests to Slack

What are Github Actions?

Actions are a relatively new feature to Github that allow you to set up CI/CD workflows using a configuration file right in your Github repo.

Previously, if you wanted to set up any kind of automation with tests, builds, or deployments, you would have to look to services like Circle CI and Travis or write your own scripts. But with Actions, you have first class support to powerful tooling to automate your workflow.

What is CI/CD?

CD/CD stands for Continuous Integration and Continuous Deployment (or can be Continuous Delivery). They're both practices in software development that allow teams to build projects together quickly, efficiently, and ideally with less errors.

Continuous Integration is the idea that as different members of the team work on code on different git branches, the code is merged to a single working branch which is then built and tested with automated workflows. This helps to constantly make sure everyone's code is working properly together and is well-tested.

Continuous Deployment takes this a step further and takes this automation to the deployment level. Where with the CI process, you automate the testing and the building, Continuous Deployment will automate deploying the project to an environment.

The idea is that the code, once through any building and testing processes, is in a deployable state, so it should be able to be deployed.

What are we going to build?

We're going to tackle two different workflows.

The first will be to simply run some automated tests that will prevent a pull request from being merged if it is failing. We won't walk through building the tests, but we'll walk through running tests that already exist.

In the second part, we'll set up a workflow that sends a message to slack with a link to a pull request whenever a new one is created. This can be super helpful when working on open source projects with a team and you need a way to keep track of requests.

Part 0: Setting up a project

For this guide, you can really work through any node-based project as long as it has tests you can run for Part 1.

If you'd like to follow along with a simpler example that I'll be using, I've set up a new project that you can clone with a single function that has two tests that are able to run and pass.

A function with two tests

If you'd like to check out this code to get started, you can run:

git clone --single-branch --branch start git@github.com:colbyfayock/my-github-actions.git

Once you have that cloned locally and have installed the dependencies, you should be able to run the tests and see them pass!

Passing tests

It should also be noted that you'll be required to have this project added as a new repository on Github in order to follow along.

Follow along with the commit!

Part 1: Automating tests

Tests are an important part of any project that allow us to make sure we're not breaking existing code while we work. While they're important, they're also easy to forget about.

We can remove the human nature out of the equation and automate running our tests to make sure we can't proceed without fixing what we broke.

Step 1: Creating a new action

The good news, is Github actually makes it really easy to get this workflow started as it comes as one of their pre-baked options.

We'll start by navigating to the Actions tab on our repository page.

Github Actions starting page

Once there, we'll immediately see some starter workflows that Github provides for us to dive in with. Since we're using a node project, we can go ahead and click Set up this workflow under the Node.js workflow.

Setting up a Node.js Github Action workflow

After the page loads, Github will land you on a new file editor that already has a bunch of configuration options added.

We're actually going to leave this "as is" for our first step. Optionally, you can change the name of the file to tests.yml or something you'll remember.

Adding a new Github Action workflow file

You can go ahead and click Start commit then either commit it directory to the master branch or add the change to a new branch. For this walkthrough, I'll be committing straight to master.

To see our new action run, we can again click on the Actions tab which will navigate us back to our new Actions dashboard.

Viewing Github Action workflow events

From there, you can click on Node.js CI and select the commit that you just made above and you'll land on our new action dashboard. You can then click one of the node versions in the sidebar via build (#.x), click the Run npm test dropdown, and we'll be able to see the output of our tests being run (which if you're following along with me, should pass!).

Viewing logs of a Github Action workflow

Follow along with the commit!

Step 2: Configuring our new action

So what did we just do above? We'll walk through the configuration file and what we can customize.

Github Action Node.js workflow file

Starting from the top, we specify our name:

name: Node.js CI

This can really be whatever you want. Whatever you pick should help you remember what it is. I'm going to customize this to "Tests" so I know exactly what's going on.

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

The on key is how we specify what events trigger our action. This can be a variety of things like based on time with cron. But here, we're saying that we want this action to run any time someone pushes commits to master or someone creates a pull request targeting the master branch. We're not going to make a change here.

jobs:
  build:
    runs-on: ubuntu-latest

This next bit creates a new job called build. Here we're saying that we want to use the latest version of Ubuntu to run our tests on. Ubuntu is common, so you'll only want to customize this if you want to run it on a specific environment.

    strategy:
      matrix:
        node-version: [10.x, 12.x, 14.x]

Inside of our job we specify a strategy matrix. This allows us to run the same tests on a few different variations.

In this instance, we're running the tests on 3 different versions of node to make sure it works on all of them. This is definitely helpful to make sure your code is flexible and future proof, but if you're building and running your code on a specific node version, you're safe to change this to only that version.

    steps:
    - uses: actions/checkout@v2
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v1
      with:
        node-version: ${{ matrix.node-version }}
    - run: npm ci
    - run: npm run build --if-present
    - run: npm test

Finally, we specify the steps we want our job to run. Breaking this down:

• uses: actions/checkout@v2: In order for us to run our code, we need to have it available. This checks out our code on our job environment so we can use it to run tests.
• uses: actions/setup-node@v1: Since we're using node with our project, we'll need it set up on our environment. We're using this action to do that setup for us for each version we've specified in the matrix we configured above.
• run: npm ci: If you're not familiar with npm ci, it's similar to running npm install but uses the package-lock.json file without performing any patch upgrades. So essentially, this installs our dependencies.
• run: npm run build --if-present: npm run build runs the build script in our project. The --if-present flag performs what it sounds like and only runs this command if the build script is present. It doesn't hurt anything to leave this in as it won't run without the script, but feel free to remove this as we're not building the project here.
• run: npm test: Finally, we run npm test to run our tests. This uses the test npm script set up in our package.json file.

And with that, we've made a few tweaks, but our tests should run after we've committed those changes and pass like before!

Logs of passing tests in Github Action workflow

Follow along with the commit!

Step 3: Testing that our tests fail and prevent merges

Now that our tests are set up to automatically run, let's try to break it to see it work.

At this point, you can really do whatever you want to intentionally break the tests, but here's what I did:

Code diff - https://github.com/colbyfayock/my-github-actions/pull/1

I'm intentionally returning different expected output so that my tests will fail. And they do!

Failing status checks on pull request

In my new pull request, my new branch breaks the tests, so it tells me my checks have failed. If you noticed though, it's still green to merge, so how can we prevent merges?

We can prevent pull requests from being merged by setting up a Protected Branch in our project settings.

First, navigate to Settings, then Branches, and click Add rule.

Github branch protection rules

We'll then want to set the branch name pattern to *, which means all branches, check the Require status checks to pass before merging option, then select all of our different status checks that we'd like to require to pass before merging.

Setting up a branch protection rule in Github

Finally, hit Create at the bottom of the page.

And once you navigate back to the pull request, you'll notice that the messaging is a bit different and states that we need our statuses to pass before we can merge.

Failing tests preventing merge in pull request

Note: as an administrator of a repository, you'll still be able to merge, so this technically only prevents non-administrators from merging. But will give you increased messaging if the tests fail.

And with that, we have a new Github Action that runs our tests and prevents pull requests from merging if they fail.

Follow along with the pull request!

Note: we won't be merging that pull request before continuing to Part 2.

Part 2: Post new pull requests to Slack

Now that we're preventing merge requests if they're failing, we want to post a message to our Slack workspace whenever a new pull request is opened up. This will help us keep tabs on our repos right in Slack.

For this part of the guide, you'll need a Slack workspace that you have permissions to create a new developer app with and the ability to create a new channel for the bot user that will be associated with that app.

Step 1: Setting up Slack

There are a few things we're going to walk through as we set up Slack for our workflow:

• Create a new app for our workspace
• Assign our bot permissions
• Install our bot to our workspace
• Invite our new bot to our channel

To get started, we'll create a new app. Head over to the Slack API Apps dashboard. If you already haven't, log in to your Slack account with the Workspace you'd like to set this up with.

Creating a new Slack app

Now, click Create New App where you'll be prompted to put in a name and select a workspace you want this app to be created for. I'm going to call my app "Gitbot" as the name, but you can choose whatever makes sense for you. Then click Create App.

Configuring a new Slack app

Once created, navigate to the App Home link in the left sidebar. In order to use our bot, we need to assign it OAuth scopes so it has permissions to work in our channel, so select Review Scopes to Add on that page.

Reviewing Slack app scopes

Scroll own and you'll see a Scopes section and under that a Bot Token section. Here, click Add an OAuth Scope. For our bot, we don't need a ton of permissions, so add the channels:join and chat:write scopes and we should be good to go.

Adding scopes for a Slack app Bot Token

Now that we have our scopes, let's add our bot to our workspace. Scroll up on that same page to the top and you'll see a button that says Install App to Workspace.

Installing Slack app to a workspace

Once you click this, you'll be redirected to an authorization page. Here, you can see the scopes we selected for our bot. Next, click Allow.

Allowing permission for Slack app to be installed to workspace

At this point, our Slack bot is ready to go. At the top of the OAuth & Permissions page, you'll see a Bot User OAuth Access Token. This is what we'll use when setting up our workflow, so either copy and save this token or remember this location so you know how to find it later.

Note: this token is private - don't give this out, show it in a screencast, or let anyone see it!

Copying OAuth Access Token for Slack bot user

Finally, we need to invite our Slack bot to our channel. If you open up your workspace, you can either use an existing channel or create a new channel for these notifications, but you'll want to enter the command /invite @[botname] which will invite our bot to our channel.

Inviting Slack bot user to channel

And once added, we're done with setting up Slack!

Slack bot was added to channel

Create a Github Action to notify Slack

Our next step will be somewhat similar to when we created our first Github Action. We'll create a workflow file which we'll configure to send our notifications.

While we can use our code editors to do this by creating a file in the .github directory, I'm going to use the Github UI.

First, let's navigate back to our Actions tab in our repository. Once there, select New workflow.

Setting up a new Github Action workflow

This time, we're going to start the workflow manually instead of using a pre-made Action. Select set up a workflow yourself at the top.

Setting up a Github Action workflow manually

Once the new page loads, you'll be dropped in to a new template where we can start working. Here's what our new workflow will look like:

name: Slack Notifications

on:
  pull_request:
    branches: [ master ]

jobs:
  notifySlack:

    runs-on: ubuntu-latest

    steps:
    - name: Notify slack
      env:
        SLACK_BOT_TOKEN: ${{ secrets.SLACK_BOT_TOKEN }}
      uses: abinoda/slack-action@master
      with:
        args: '{\"channel\":\"[Channel ID]\",\"blocks\":[{\"type\":\"section\",\"text\":{\"type\":\"mrkdwn\",\"text\":\"*Pull Request:* ${{ github.event.pull_request.title }}\"}},{\"type\":\"section\",\"text\":{\"type\":\"mrkdwn\",\"text\":\"*Who?:* ${{ github.event.pull_request.user.login }}\n*Request State:* ${{ github.event.pull_request.state }}\"}},{\"type\":\"section\",\"text\":{\"type\":\"mrkdwn\",\"text\":\"<${{ github.event.pull_request.html_url }}|View Pull Request>\"}}]}'

So what's happening in the above?

• name: we're setting a friendly name for our workflow
• on: we want our workflow to trigger when there's a pull request is created that targets our master branch
• jobs: we're creating a new job called notifySlack
• jobs.notifySlack.runs-on: we want our job to run on a basic setup of the latest Unbuntu
• jobs.notifySlack.steps: we really only have one step here - we're using a pre-existing Github Action called Slack Action and we're configuring it to publish a notification to our Slack

There are two points here we'll need to pay attention to, the env.SLACK_BOT_TOKEN and the with.args.

In order for Github to communicate with Slack, we'll need a token. This is what we're setting in env.SLACK_BOT_TOKEN. We generated this token in the first step. Now that we'll be using this in our workflow configuration, we'll need to add it as a Git Secret in our project.

_Github secrets including SLACK_BOTTOKEN

The with.args property is what we use to configure the payload to the Slack API that includes the channel ID (channel) and our actual message (blocks).

The payload in the arguments is stringified and escaped. For example, when expanded it looks like this:

{
  "channel": "[Channel ID]",
  "blocks": [{
    "type": "section",
    "text": {
      "type": "mrkdwn",
      "text": "*Pull Request:* ${{ github.event.pull_request.title }}"
    }
  }, {
    "type": "section",
    "text": {
      "type": "mrkdwn",
      "text": "*Who?:*n${{ github.event.pull_request.user.login }}n*State:*n${{ github.event.pull_request.state }}"
    }
  }, {
    "type": "section",
    "text": {
      "type": "mrkdwn",
      "text": "<${{ github.event.pull_request._links.html.href }}|View Pull Request>"
    }
  }]
}

Note: this is just to show what the content looks like, we need to use the original file with the stringified and escaped argument.

Back to our configuration file, the first thing we set is our channel ID. To find our channel ID, you'll need to use the Slack web interface. Once you open Slack in your browser, you want to find your channel ID in the URL:

https://app.slack.com/client/[workspace ID]/[channel ID]

Channel ID in Slack web app URL

With that channel ID, you can modify our workflow configuration and replace [Channel ID] with that ID:

with:
  args: '{\"channel\":\"C014RMKG6H2\",...

The rest of the arguments property is how we set up our message. It includes variables from the Github event that we use to customize our message.

We won't go into tweaking that here, as what we already have will send a basic pull request message, but you can test out and build your own payload with Slack's Block Kit Builder.

Follow along with the commit!

Test out our Slack workflow

So now we have our workflow configured with our Slack app, finally we're ready to use our bot!

For this part, all we need to do is create a new pull request with any change we want. To test this out, I simply created a new branch where I added a sentence to the README.md file.

Code diff - https://github.com/colbyfayock/my-github-actions/pull/2

Once you create that pull request, similar to our tests workflow, Github will run our Slack workflow! You can see this running in the Actions tab just like before.

As long as you set everything up correctly, once the workflow runs, you should now have a new message in Slack from your new bot.

Slack bot automated message about new pull request

Note: we won't be merging that pull request in.

What else can we do?

Customize your Slack notifications

The message I put together is simple. It tells us who created the pull request and gives us a link to it.

To customize the formatting and messaging, you can use the Github Block Kit Builder to create your own.

If you'd like to include additional details like the variables I used for the pull request, you can make use of Github's available contexts. This lets you pull information about the environment and the job to customize your message.

I couldn't seem to find any sample payloads, so here's an example of a sample github context payload you would expect in the event.

Sample github context

More Github actions

With our ability to create new custom workflows, that's not a lot we can't automate. Github even has a marketplace where you can browse around for one.

If you're feeling like taking it a step further, you can even create your own! This lets you set up scripts to configure a workflow to perform whatever tasks you need for your project.

Join in the conversation!

What do you use Github actions for?

Share with me on Twitter!

Teamwork in Slack happens in channels — a single place for messaging, tools and files — helping everyone save time and collaborate.

One of the awesome features of Slack is Slack Apps, integrations and Slack Bots.

A Slack bot is a type of Slack App designed to interact with users via conversation. Your bot can send DMs, it can be mentioned by users, it can post messages or upload files, and it can be invited to channels. Cool right?

If you use Slack already, you should be familiar with some creative Slack bots like Standupbot, Birthdaybot and more.

In this article, I'll walk you through building your first Slack bot from start to finish with Node.js and SlackBots.js

PS: This article was published on my blog first.

SlackBot Description

We're going to build a simple Slackbot that displays random inspiring techie quotes and jokes for developers/designers.

I built a chrome extension that displays random inspiring techie quotes for developers/designers on your new tab (you can download it here). We'll be using the quotes JSON from this extension as our quotes API and the Chuck Norris Jokes API for the jokes.

When a user mentions our bot and adds inspire me, the bot returns a random quote from inspireNuggets. When the user types random joke, it returns a random joke from the Chuck Norris API. And when the user types help, it returns the instruction guide.

@inspirenuggets inspire me

@inspirenuggets random joke

@inspirenuggets help

This article is not really about what we'll be building - it's just to show you the concept behind Slack bots and how to build yours. After you go through it, you can think about something else and build a different bot, as there're many possibilities.

You can clone or fork the final project here.

Pretty interesting right? Let's get started.

Prerequisites

We'll build this bot with Node.js and SlackBots.js. You don't need to know how to write Node.js, since I'll walk you through it. Still, knowing it is an advantage. You should also have

• Basic JavaScript knowledge

• ES6 JavaScript

• Slack workspace

• Some experience with Slack

• Some version control skills

Setup environment

Let's set up and install Node.js and Npm first.

• Download node here. If you have it installed already, skip this step. If you prefer to use a package manager to install, read this for all operating systems.

• Check if you have Node installed

node -v

• Node.js comes with Npm, so you don't have to install that again.

npm -v

Now that we have Node.js setup, let's initialize our project.

Create your project directory (I called mine Slackbot) and initialize git:

git init

Next, create an index.js file:

touch index.js

And initialize Npm:

npm init

Simply answer all questions that come afterwards. If you're having issues, here's my own package.json:

{
  "name": "slackbot",
  "version": "1.0.0",
  "description": "A simple Slackbot that displays random inspiring techie quotes for developers/designers.",
  "main": "index.js",
  "scripts": {
    "start": "index.js"
  },
  "repository": {
    "type": "git",
    "url": "git+https://github.com/BolajiAyodeji/slackbot.git"
  },
  "author": "Bolaji Ayodeji",
  "license": "MIT",
  "bugs": {
    "url": "https://github.com/BolajiAyodeji/slackbot/issues"
  },
  "homepage": "https://github.com/BolajiAyodeji/slackbot#readme"
}

Install Dependencies

Now let's install and setup all the libraries we need.

SlackBots.js

SlackBots.js is a Node.js library for easy operation with the Slack API.

npm install slackbots

In index.js:

const SlackBot = require('slackbots');

Axios

Axios is a promise-based HTTP client for the browser and node.js. If you know Fetch or AJAX, this is just a library that does the same thing with way cooler features. You can see them here.

npm install axios

In index.js:

const axios = require('axios')

Nodemon

To run a script in Node.js, you have to run node index.js. Whenever you make changes to this file, you have to rerun node index.js. This sucks when you're making so many changes like we'll be doing. That's why we need nodemon, a tool that helps develop node.js based applications by automatically restarting the node application when file changes in the directory are detected.

npm install -g nodemon

In package.json, locate the scripts section and add a new start script:

"scripts": {
    "start": "node index.js"
  }

If you run npm start, the file will run but won't restart on change. To fix this, use the nodemon we installed instead of node like so:

"scripts": {
    "start": "nodemon index.js"
  }

Dotenv

I won't explain this in-depth. In a few days, I'll publish an article around environmental variables, but for now just know that we use this to hide secret keys and tokens like the Slack Access Token we would be using. This way you don't have to push your secret keys to GitHub.

There are several ways to do this, but I prefer using dotenv. Dotenv is a zero-dependency module that loads environment variables from a .env file into process.env.

npm install dotenv

In index.js:

const dotenv = require('dotenv')

dotenv.config()

After all installation, your package.json should look like this:

{
  "name": "inspireNuggetsSlackBot",
  "version": "1.0.0",
  "description": "A simple Slackbot that displays random inspiring techie quotes and jokes for developers/designers.",
  "main": "index.js",
  "scripts": {
    "start": "nodemon index.js"
  },
  "repository": {
    "type": "git",
    "url": "git+https://github.com/BolajiAyodeji/inspireNuggetsSlackBot.git"
  },
  "author": "Bolaji Ayodeji",
  "license": "MIT",
  "bugs": {
    "url": "https://github.com/BolajiAyodeji/inspireNuggetsSlackBot/issues"
  },
  "homepage": "https://github.com/BolajiAyodeji/inspireNuggetsSlackBot#readme",
  "devDependencies": {
    "dotenv": "^8.0.0"
  },
  "dependencies": {
    "axios": "^0.19.0",
    "slackbots": "^1.2.0"
  }
}

Create your Slack workspace

Now that we have that all set up, we need a Slack workspace to run our bot in development. Creating a workspace is pretty easy, read this to learn more.

Register your Slack Bot

Now that you have a workspace, you should have a Slack URL with your workspace name. Mine is mekafindteam.slack.com.

Now you'll need to create a Slack App. Create one here.

Enter your App name and ensure you're in the workspace you created if you're in multiple workspaces.

Now you'll see the settings > Basic Information page. Click the first tab Add features and functionality:

Since we're building a bot, select the Bots field.

Now you'll see the Bot user page:

Click the Add a Bot User button.

Your display name will automatically be filled in from your already chosen App name. You can update it, but I'll advise you use the same name everywhere with the same alphabet case to avoid errors.

Now, toggle the Always Show My Bot as Online switch to always show your bot as Online. Remember this bot is just like a user in your workspace. Afterwards, click the Add Bot User button.

Save all changes now:

Next, return to the Basic Information page and select the Install your app to your workspace tab.

Click the Install App to Workspace:

Click allow and wait to be redirected back to the Basic Information page.

Note the Manage distribution tab: this section is needed when you want to make your Bot available for installation by others. For now we're just building in development and I won't be covering distribution in this article. In my next article, I'll show you how to deploy your Slack bot and make it available as an App to other workspaces.

If you check your Slack workspace now, you should see the App installed in the Apps section.

For now, it's offline - once we start building the bot, we'll turn this on.

Customize your Slack bot

Now we've created our bot, let's do some customization.

Still, on the Basic Information page, scroll down to the Display Information section:

This is basic stuff: just upload a logo, change your background color, and add a short description.

Your icon should be 512x512px or bigger and your background color should be in HEX. Read more on the App guidelines here.

Here's what mine looks like after customization:

Slack bot OAuth Tokens

Now that we have our Slack bot setup, let's grab out token keys.

In the navigation bar, locate the Features section and click the OAuth & Permission tab:

You'll see two Access Tokens:

• OAuth Access Token

• Bot User OAuth Access Token

Copy the Bot User OAuth Access Token.

This will change every time you re-install this app or when you install it in another workspace. The token should start with xoxb-.

Keeping credentials secure is important whether you're developing open source libraries and tools, internal integrations for your workspace, or Slack apps for distribution to workspaces across the world. - Slack

This is why we have installed Dotenv - we'll set that up in the next section.

Building the bot

Now let's build our bot :).

First, let's keep our Access Token somewhere.

Create a .env file and add this:

BOT_TOKEN=YOUR_SLACK_ACCESS_TOKEN_HERE

Now let's start our SlackBot.js:

const bot = new SlackBot({
    token: `${process.env.BOT_TOKEN}`,
    name: 'inspirenuggets'
})

We've just created a bot variable that initializes a new SlackBot instance which has two values, our token and app name.

I used the ES6 template string syntax to bring in our token key from our .env file. dotenv has this covered for us.

Make sure you use the same name you used while creating your Slack app, or else you'll have authentication errors.

Now start the app:

npm start

nodemon should be running now and our Slack app should be online too.

Start handler

Our Bot does nothing now even though it's running. Let's return a message.

bot.on('start', () => {
    const params = {
        icon_emoji: ':robot_face:'
    }

    bot.postMessageToChannel(
        'random',
        'Get inspired while working with @inspirenuggets',
        params
    );
})

The bot.on handler sends the welcome message. We passed two parameters, the 'start' and a function which holds a params variable which also holds the slack emoji. Slack emoji have codes, and you can find them here. I used :robot_face:, but you can change this to your preferred emoji.

We also initialized the bot.postMessageToChannel function which is a SlackBot.js method to post a message to a channel. In this function, we pass the channel name we want to post to, the message in a string, and the params variable we declared earlier for the emoji. I used the #random channel and sent Get inspired while working with @inspirenuggets to it. Your app should restart automatically and your bot should do this:

Cool right?
You can also post messages to users and groups.

    // define existing username instead of 'user_name'
    bot.postMessageToUser('user_name', 'Hello world!', params); 


    // define private group instead of 'private_group', where bot exist
    bot.postMessageToGroup('private_group', 'Hello world!', params);

Error Handler

Let's also write a function to check for errors and return them:

bot.on('error', (err) => {
    console.log(err);
})

Message Handler

Now let's build the main bot functionality.

Like I said earlier, we'll be using the quotes JSON from the extension I built as our quotes API. The JSON can be found with this URL: https://raw.githubusercontent.com/BolajiAyodeji/inspireNuggets/master/src/quotes.json

When a user mentions our bot and adds inspire me, the bot returns a random quote from inspireNuggets. When the user types random joke, it returns a random joke from the Chuck Norris API. And when the user types help, it returns the instruction guide.

First, let's check for our command words from the user message (inspire me, random joke, and help):

function handleMessage(message) {
    if(message.includes(' inspire me')) {
        inspireMe()
    } else if(message.includes(' random joke')) {
        randomJoke()
    } else if(message.includes(' help')) {
        runHelp()
    }
}

Now let's create the three function we need

inspireMe()

Our demo JSON is not really an API, it's just some JSON I used in the Chrome Extension. We're only accessing it from GitHub raw contents. You can use any API you prefer, you'll just have to iterate differently to get your data depending on if your API returns an array or object - whichever it returns, it's not a big deal.

Check out my previous articles on:

• Manipulating Arrays in JavaScript and

• Iterating through JavaScript Objects  -  5 Techniques and Performance Tests.

function inspireMe() {
    axios.get('https://raw.githubusercontent.com/BolajiAyodeji/inspireNuggets/master/src/quotes.json')
      .then(res => {
            const quotes = res.data;
            const random = Math.floor(Math.random() * quotes.length);
            const quote = quotes[random].quote
            const author = quotes[random].author

            const params = {
                icon_emoji: ':male-technologist:'
            }

            bot.postMessageToChannel(
                'random',
                `:zap: ${quote} - *${author}*`,
                params
            );

      })
}

We just used Axios to get the JSON file which returns some data:

[
    {
        "number": "1",
        "author": "Von R. Glitschka",
        "quote": "The client may be king, but he's not the art director."
    },
    {
        "number": "2",
        "author": "Frank Capra",
        "quote": "A hunch is creativity trying to tell you something."
    },
.
.
.
.
]

This JSON currently contains 210 quotes and I update them frequently. So we want to get a random quote plus the author name every time the user request it. From our Axios response, we just do this:

const quotes = res.data;
const random = Math.floor(Math.random() * quotes.length);
const quote = quotes[random].quote
const author = quotes[random].author

And just like we did with the welcome message, we just return the quote and author instead of a string message:

`:zap: ${quote} - *${author}*`

Let's test this:

Type @inspirenuggets inspire me

Yayyy! It worked!

PS: You can always change the emoji type for every request. If you noticed I changed the inspireMe() to :male-technologist:

randomJoke()

We're getting the jokes from the Chuck Norris API from this endpoint https://api.chucknorris.io/jokes/random.

{
"categories": [],
"created_at": "2016-05-01 10:51:41.584544",
"icon_url": "https://assets.chucknorris.host/img/avatar/chuck-norris.png",
"id": "6vUvusBeSVqdsU9C5-ZJZw",
"updated_at": "2016-05-01 10:51:41.584544",
"url": "https://api.chucknorris.io/jokes/6vUvusBeSVqdsU9C5-ZJZw",
"value": "Chuck Norris once choked a wildcat to death with his sphincter muscle."
}

This is a real API that returns a random joke on every request, so we don't have to do Math.floor() again.

function randomJoke() {
    axios.get('https://api.chucknorris.io/jokes/random')
      .then(res => {
            const joke = res.data.value;

            const params = {
                icon_emoji: ':smile:'
            }

            bot.postMessageToChannel(
                'random',
                `:zap: ${joke}`,
                params
            );

      })
}

By now, you should understand how this works already. Make a post with the channel name, message and params.

runHelp()

This is similar to our welcome message: we just want to return a custom text when the user adds help to the request.

function runHelp() {
    const params = {
        icon_emoji: ':question:'
    }

    bot.postMessageToChannel(
        'random',
        `Type *@inspirenuggets* with *inspire me* to get an inspiring techie quote, *random joke* to get a Chuck Norris random joke and *help* to get this instruction again`,
        params
    );
}

Now let's test all three commands:

Everything works fine now, congratulations!!!! You just built your SlackBot.

There are an endless number of possibilities of Bots you can build with this to automate your own work or teamwork.

You can build a bot that:

• Fetches your tasks from somewhere and reminds you when you type hey what next,

• Welcomes every user to your workspace (I built this during one of the HNG Internship's),

• Gives you football matches updates while you're working,

• Tells your team when you hit a milestone in number of registered users,

and many more...

It's just about having somewhere to get the data from, and some basic iteration skills and the bot.postMessageToChannel() method.

Automation is one thing we should learn as developers. We have a lot to do, so we should automate the simpler tasks so we have time for the more difficult ones. I hope with this you can automate your tasks and I look forward to the creative ideas you'll bring to life.

Final Code

Here's our final index.js

const SlackBot = require('slackbots');
const axios = require('axios')
const dotenv = require('dotenv')

dotenv.config()

const bot = new SlackBot({
    token: `${process.env.BOT_TOKEN}`,
    name: 'inspirenuggets'
})

// Start Handler
bot.on('start', () => {
    const params = {
        icon_emoji: ':robot_face:'
    }

    bot.postMessageToChannel(
        'random',
        'Get inspired while working with @inspirenuggets',
        params
    );
})

// Error Handler
bot.on('error', (err) => {
    console.log(err);
})

// Message Handler
bot.on('message', (data) => {
    if(data.type !== 'message') {
        return;
    }
    handleMessage(data.text);
})

// Response Handler
function handleMessage(message) {
    if(message.includes(' inspire me')) {
        inspireMe()
    } else if(message.includes(' random joke')) {
        randomJoke()
    } else if(message.includes(' help')) {
        runHelp()
    }
}

// inspire Me
function inspireMe() {
    axios.get('https://raw.githubusercontent.com/BolajiAyodeji/inspireNuggets/master/src/quotes.json')
      .then(res => {
            const quotes = res.data;
            const random = Math.floor(Math.random() * quotes.length);
            const quote = quotes[random].quote
            const author = quotes[random].author

            const params = {
                icon_emoji: ':male-technologist:'
            }

            bot.postMessageToChannel(
                'random',
                `:zap: ${quote} - *${author}*`,
                params
            );

      })
}

// Random Joke
function randomJoke() {
    axios.get('https://api.chucknorris.io/jokes/random')
      .then(res => {
            const joke = res.data.value;

            const params = {
                icon_emoji: ':smile:'
            }

            bot.postMessageToChannel(
                'random',
                `:zap: ${joke}`,
                params
            );

      })
}

// Show Help
function runHelp() {
    const params = {
        icon_emoji: ':question:'
    }

    bot.postMessageToChannel(
        'random',
        `Type *@inspirenuggets* with *inspire me* to get an inspiring techie quote, *random joke* to get a Chuck Norris random joke and *help* to get this instruction again`,
        params
    );
}

What Next?

Our bot only runs in development now, and to use it we always have to npm start.

This isn't cool, right? We'll want to host it somewhere it can run every time. In my next article, I'll show you how to host this on either Heroku, Zeit or Netlify and publish it to the Slack Apps store so anyone around the world can use it.
Also, don't forget to add this in your .gitignore before pushing to GitHub:

/.env
/node_modules

Subscribe to my newsletter to get updated.

Useful Resources

• Slack API

• Slack API Docs

• SlackBot.js

• Slack Apps

• Slack Apps Guidelines

• An introduction to Slack apps

• inspireNuggets

• inspireNuggetsSlackBot

Serverless architecture is the industry's latest buzzword and many of the largest tech companies have begun to embrace it.

In this article, we'll learn what it is and why you should use it. We'll also set up AWS, create our serverless app, and create a slack app!

What is Serverless?

Serverless is a cloud computing paradigm in which the developer no longer has to worry about maintaining a server – they just focus on the code.

Cloud providers, such as AWS or Azure, are now responsible for executing code and maintaining servers by dynamically allocating their resources. A variety of events can trigger code execution, including cron jobs, http requests, or database events.

The code that developers send to the cloud is usually just a function so, many times, serverless architecture is implemented using Functions-as-a-Service, or FaaS. The major cloud providers provide frameworks for FaaS, such as AWS Lambda and Azure Functions.

Why Serverless?

Not only does serverless allow developers to just focus on code, but it has many other benefits as well.

Since cloud providers are now responsible for executing code and dynamically allocate resources based on event triggers, you typically only pay per request, or when your code is being executed.

Additionally, since cloud providers are handling your servers, you don't have to worry about scaling up – the cloud provider will handle it. This makes serverless apps lower cost, easier to maintain, and easier to scale.

Setting up AWS Lambda

For this tutorial, I will be using AWS Lambda, so first, we'll create an AWS account. I find AWS's UI hard to understand and difficult to navigate, so I will be adding screenshots for each step.

Once you log in, you should see this:

Main screen

Next, we'll set up an IAM user. An IAM (Identity and Access Management) user interacts with AWS and its resources on your behalf. This allows you to create different IAM users with different permissions and purposes, without compromising the security of your root user account.

Click on the "services" tab at the top of the page, and type "IAM" into the bar:

Click on the first result, and you'll see, on the left-hand sidebar, that you're at the dashboard. Click on the "Users" option to get to create our new IAM user.

Click on the "Add user" button to create a new user. Fill in the details as follows:

You can name your user anything you'd like, but I went with serverless-admin. Be sure that your user has "Programmatic access" to AWS, not "AWS Management Console Access". You'd use the latter for teammates, or other humans who need access to AWS. We just need this user to interact with AWS Lambda, so we can just give them programmatic access.

For permissions, I've chosen to attach existing policies since I don't have any groups, and I don't have any existing users that I want to copy permissions for. In this example, I will create the user with Administrator access since it's just for a personal project; however, if you were to use a serverless app in an actual production environment, your IAM user should be scoped to only access Lambda-necessary parts of AWS. (Instructions can be found here).

I didn't add any tags and created the user. It's vital to save the information given to you on the next screen - the Access ID and Secret Access Key.

Don't leave this screen without copying down both! You won't be able to see the Secret access key again after this screen.

Finally, we'll add these credentials to command line AWS. Use this guide to get aws cli setup.

Make sure you have it installed by running aws --version. You should see something like this:

Then run aws configure and fill in the prompts:

I have the default region as us-east-2 already set up, but you can use this to determine what your region is.

To make sure that you have your credentials set up correctly, you can run cat ~/.aws/credentials in your terminal.

If you want to configure a profile other than your default, you can run the command as follows: aws configure --profile [profile name].

If you had trouble following the steps, you can also check out AWS's documentation.

Set up serverless

Go to your terminal and install the serverless package globally using npm: npm i -g serverless. (More info on serverless here)
and your terminal should look something like this:

Next, navigate to the directory where you want to create the app, then run serverless and follow the prompts:

For this application, we'll be using Node.js. You can name your app anything you want, but I've called mine exampleSlackApp.

Open your favorite code editor to the contents in exampleSlackApp (or whatever you've called your application).

First, we'll take a look at serverless.yml. You'll see there's a lot of commented code here describing the different options you can use in the file. Definitely give it a read, but I've deleted it down to just:

service: exampleslackapp

provider:
  name: aws
  runtime: nodejs10.x
  region: us-east-2

functions:
  hello:
    handler: handler.hello

I've included region since the default is us-east-1 but my aws profile is configured for us-east-2.

Let's deploy what we already have by running serverless deploy in the directory of the app that serverless just created for us. The output should look something like this:

And if you run serverless invoke -f hello in your terminal, it'll run the app, and you should see:

{
    "statusCode": 200,
    "body": "{\n  \"message\": \"Go Serverless v1.0! Your function executed successfully!\",\n  \"input\": {}\n}"
}

For further proof that our slack app is live, you can head back to AWS console. Go to the services dropdown, search for "Lambda", and click on the first option ("Run code without thinking about servers").

And here's your app!

Next, we'll explore actually using serverless by building our slack app. Our slack app will post a random Ron Swanson quote to slack using a slash command like this:

The following steps don't necessarily have to be done in the order that I've done them, so if you want to skip around, feel free!

Adding the API to our code

I'm using this API to generate Ron Swanson quotes since the docs are fairly simple (and of course, it's free). To see how requests are make and what gets returned, you can just put this URL in your browser:

https://ron-swanson-quotes.herokuapp.com/v2/quotes

You should see something like this:

So, we can take our initial function and modify it as such:

module.exports.hello = (event) => {
  getRon();
};

and getRon looks like:

function getRon() {
  request('https://ron-swanson-quotes.herokuapp.com/v2/quotes', function (err, resp, body) {
    console.log('error:', err)
    console.log('statusCode:', resp && resp.statusCode)
    console.log('body', body)
  })
}

Now, let's check if it works. To test this code locally, in your terminal: serverless invoke local -f hello. Your output should look something like:

Spoiler: There was a wrong way to consume alcohol

serverless invoke -f hello would run the code that you've deployed, as we saw in previous sections. serverless invoke local -f hello, however, runs your local code, so it's useful for testing. Go ahead and deploy using serverless deploy!

Create your Slack App

To create your slack app, follow this link. It'll make you sign into a slack workspace first, so be sure you're a part of one that you can add this app to. I've created a testing one for my purposes. You'll be prompted with this modal. You can fill in whatever you want, but here's what I have as an example:

From there, you'll be taken to the homepage for your app. You should definitely explore these pages and the options. For example, I've added the following customization to my app:

Display information can be found from the "Basic Information" tab on the app

Next, we need to add some permissions to the app:

To get an OAuth Access Token, you have to add some scope and permissions, which you can do by scrolling down:

I've added "Modify your public channels" so that the bot could write to a channel, "Send messages as Ron Swanson" so when the message gets posted, it looks like a user called Ron Swanson is posting the message, and slash commands so the user can "request" a quote as shown in the screenshot at the beginning of the article. After you save the changes, you should be able to scroll back up to OAuths & Permissions to see:

Click the button to Install App to Workspace, and you'll have an OAuth Access Token! We'll come back to this in a second, so either copy it down or remember it's in this spot.

Connect Code and Slack App

In AWS Lambda, find your slack app function. Your Function Code section should show our updated code with the call to our Ron Swanson API (if it does not, go back to your terminal and run serverless deploy).

Scroll below that to the section that says "Environment Variables", and put your Slack OAuth Access Token here (you can name the key whatever you'd like):

Let's go back to our code and add Slack into our function. At the top of our file, we can declare a const with our new OAuth Token:

const SLACK_OAUTH_TOKEN = process.env.OAUTH_TOKEN.

process.env just grabs our environment variables (additional reading). Next, let's take a look at the Slack API to figure out how to post a message to a channel.

The two pictures above I've taken from the API are the most relevant to us. So, to make this API request, I'll use request by passing in an object called options:

  let options = {
    url: 'https://slack.com/api/chat.postMessage',
    headers: {
      'Accept': 'application/json',
    },
    method: 'POST',
    form: {
      token: SLACK_OAUTH_TOKEN,
      channel: 'general', // hard coding for now
      text: 'I am here',
    }
  }

and we can make the request:

  request(options, function(err, resp, body) {
    console.log('error:', err)
    console.log('statusCode:', resp && resp.statusCode)
    console.log('body', body)
  })

Finally, I'll wrap the whole thing in a function:

function postRon(quote) {
  let options = {
    url: 'https://slack.com/api/chat.postMessage',
    headers: {
      'Accept': 'application/json',
    },
    method: 'POST',
    form: {
      token: SLACK_OAUTH_TOKEN,
      channel: 'general',
      text: quote,
    }
  }

  request(options, function(err, resp, body) {
    console.log('error:', err)
    console.log('statusCode:', resp && resp.statusCode)
    console.log('body', body)
  })
}

and we can call it from getRon like this:

function getRon() {
  request('https://ron-swanson-quotes.herokuapp.com/v2/quotes', function (err, resp, body) {
    console.log('error:', err)
    console.log('statusCode:', resp && resp.statusCode)
    console.log('body', body)
    postRon(body.substring(2, body.length - 2)) // here for parsing, remove if you want to see how/why I did it
  })
}

So our code should all in all look like this:

'use strict';
let request = require('request');

const SLACK_OAUTH_TOKEN = process.env.OAUTH_TOKEN

module.exports.hello = (event) => {
  getRon();
};

function getRon() {
  request('https://ron-swanson-quotes.herokuapp.com/v2/quotes', function (err, resp, body) {
    console.log('error:', err)
    console.log('statusCode:', resp && resp.statusCode)
    console.log('body', body)
    postRon(body.substring(2, body.length - 2))
  })
}

function postRon(quote) {
  let options = {
    url: 'https://slack.com/api/chat.postMessage',
    headers: {
      'Accept': 'application/json',
    },
    method: 'POST',
    form: {
      token: SLACK_OAUTH_TOKEN,
      channel: 'general',
      text: quote,
    }
  }

  request(options, function(err, resp, body) {
    console.log('error:', err)
    console.log('statusCode:', resp && resp.statusCode)
    console.log('body', body)
  })
}

Now let's test! Unfortunately, our environment variable in AWS Lambda isn't available to us when we run serverless invoke local -f hello. There are a few ways you can approach this, but for our purposes, you can just replace the value for SLACK_OAUTH_TOKEN with your actual OAuth Token (make sure it's a string). But be sure you switch it back before you push it up to version control!

Run serverless invoke local -f hello, and hopefully you should see a message like this in your #general channel:

Please note that I put down my channel name as 'general' since it's my test workspace; however, if you're in an actual workspace, you should create a separate channel for testing apps, and put the message there instead while you're testing.

And in your terminal, you should see something like:

If that works, go ahead and deploy it using serverless deploy. If it does not, the best way to debug this is to adjust code and run serverless invoke local -f hello.

Adding slash command

The last and final part is adding a slash command! Go back to your function's home page in AWS Lambda and look for the button that says "Add trigger":

We're going to add an API Gateway (as I already have).

Click on the button to get to the "Add trigger" page, and select "API Gateway" from the list:

I've filled in the information based on defaults mostly:

I've also left this API open for use – however, if you're using this in production, you should discuss what standard protocol would be with your team. "Add" the API, and you should receive an API endpoint. Hold on to this, because we'll need it for the next step.

Let's switch back over to our slack app and add a slash command:

Click on "Create New Command" and it should pop up with a new window to create a command. Here's how I filled mine out:

You can enter anything you want for "command" and "short description" but for "request URL", you should put your API endpoint.

Finally, we'll go back to our code to make some final adjustments. If you try to use the slash command, you should receive some kind of error back – this is because slack expects a response and AWS expects you to give a response when the endpoint is hit. So, we'll change our function to allow a callback (for reference):

module.exports.hello = (event,context,callback) => {
  getRon(callback);
};

and then we'll change getRon to do something with the callback:

function getRon(callback) {
  request('https://ron-swanson-quotes.herokuapp.com/v2/quotes', function (err, resp, body) {
    console.log('error:', err)
    console.log('statusCode:', resp && resp.statusCode)
    console.log('body', body)
    callback(null, SUCCESS_RESPONSE)
    postRon(body.substring(2, body.length - 2))
  })
}

where SUCCESS_RESPONSE is at the top of the file:

const SUCCESS_RESPONSE = {
  statusCode: 200,
  body: null
}

You can put the callback here or in postRon – it just depends on what your purposes are with the callback.

Our code at this point now looks something like:

'use strict';
let request = require('request');

const SLACK_OAUTH_TOKEN = OAUTH_TOKEN

const SUCCESS_RESPONSE = {
  statusCode: 200,
  body: null
}

module.exports.hello = (event,context,callback) => {
  getRon(callback);
};

function getRon(callback) {
  request('https://ron-swanson-quotes.herokuapp.com/v2/quotes', function (err, resp, body) {
    console.log('error:', err)
    console.log('statusCode:', resp && resp.statusCode)
    console.log('body', body)
    callback(null, SUCCESS_RESPONSE)
    postRon(body.substring(2, body.length - 2))
  })
}

function postRon(quote) {
  let options = {
    url: 'https://slack.com/api/chat.postMessage',
    headers: {
      'Accept': 'application/json',
    },
    method: 'POST',
    form: {
      token: SLACK_OAUTH_TOKEN,
      channel: 'general',
      text: quote,
    }
  }

  request(options, function(err, resp, body) {
    console.log('error:', err)
    console.log('statusCode:', resp && resp.statusCode)
    console.log('body', body)
  })
}

You should be able to use the /ron command in slack now and get a Ron Swanson quote back. If you don't, you can use Cloudwatch logs to see what went wrong:

The way our code works now, we've hardcoded in the channel name. But, what we actually want is for the quote to get posted in the message where you used /ron.

So, we can now use the event portion of our function.

module.exports.hello = (event,context,callback) => {
  console.log(event)
  getRon(callback);
};

Use /ron to run the function, and then check your Cloudwatch logs to see what gets logged to the console (you may need to refresh). Check on the most recent logs and you should see something like this:

The first item in this list (where it says "resource", "path", etc.) is the event, so if you expand that, you'll see a long list of things, but what we're looking for is 'body' all the way down at the bottom:

where's waldo: spot the param edition

Body is a string with some relevant information in it, one of them being "channel_id". We can use channel_id (or channel_name) and pass it into the function that creates our slack message. For your convenience, I've already parsed this string: event.body.split("&")[3].split("=")[1] should give you the channel_id. I hardcoded in which entry (3) the channel_id was for simplicity.

Now, we can alter our code to save that string as a variable:

let channel = 'general' (as our fallback)

module.exports.hello = (event,context,callback) => {
  console.log(event)
  channel = event.body.split("&")[3].split("=")[1]
  console.log(context)
  getGoat(callback);
};

and in postRon:

  let options = {
    url: 'https://slack.com/api/chat.postMessage',
    headers: {
      'Accept': 'application/json',
    },
    method: 'POST',
    form: {
      token: SLACK_OAUTH_TOKEN,
      channel: channel,
      text: quote,
    }
  }

Finally, if you use a slack command in any channel in your workspace, you should be able to see a Ron Swanson quote pop up! If not, as I mentioned before, the most common tools I use to debug serverless apps are serverless invoke local -f <function name> and Cloudwatch logs.

Hopefully you were successfully able to create a functioning Slack application! I've included resources and background reading dispersed throughout the article and I'm happy to answer any questions you may have!

Final Repo with code: https://github.com/lsurasani/ron-swanson-slack-app/

Update: code and tutorial updated on June 28 to reflect Slack API changes.

Slackbots: Why use them?

Before we get into the tutorial part of this post, let’s take a look at why this can be a worthy project and tool.

Slack is an increasingly popular tool for team-wide communication. It’s grown to include plugins for other widely used project management tools, like JIRA, Google Drive, and the likes. Any slack user knows — the more you can do from within the conversation, the better.

Common uses for a slackbot range from a simple notifier for when a task is complete (like a test build, or when your lunch is ready) to interactive, button-based bots that execute commands at the user’s will. You can build polling mechanisms, conversational bots, and more.

Setting up a python programming environment

If you’re a windows user and you haven’t used python before, you’ll need to install it. Linux/Mac users: Unix comes with python!

Once installed, fire up your terminal and type python or python3 (if you have multiple installations) to make sure it works and is there.

Also check to see you have a good text editor for code: sublime and atom are great choices.

Optional: It might also be useful to work in a virtual environment — it’s good practice for when you have a lot of dependencies.

pip install virtualenv
virtualenv tutorial
source tutorial/bin/activate

You should also fork the tutorial GitHub repo and clone to your local machine, as we’ll be using that code as a framework for this tutorial.

To do this, go to the repo and click Fork on the top right. The forked repo should be /slackbot-tutorial. Hit the green Clone or download button on the right under the stats bar, and copy the url. Return to the terminal to clone the repository:

cd Desktop/
git clone https://github.com/yourusername/slackbot-tutorial.git
cd slackbot-tutorial/
sublime . (or open your text editor and open this directory)

Slack Apps

There are two ways to go about creating your slackbot: standalone bots, or Slack apps. Apps allow a wider range of functionality going forward, and is Slack’s recommended route for creating a bot user.

Go to https://api.slack.com/apps and hit Create New App on the top right. Give it a name and pick a workspace where you can create a channel to test your bot in. You can always reconfigure your bot for another workspace later, or even post it to the Slack App Directory.

I recommend making a #test channel in a workspace you create just for development purposes, or one that has relatively few users who wouldn’t mind you testing something out there.

The first thing you’ll want to do is get the bot token. When you get to the above page, click Bots. Add some scopes; these determine what permissions your app’s bot user will have. To start, chat:write and im:write are probably enough.

Now, to actually get your tokens, you’ll want to go to OAuth & Permissions on the left sidebar.

Here, you’ll be able to Install the App to the Workspace and generate the necessary tokens. As a rule of thumb, bot tokens start with xoxb-.

You’ll also want the signing secret, which is located under Basic Information > App Credentials.

Acting as your Bot

Now you have the credentials necessary to make API calls and act as your bot. To test this out, fire up a terminal and run this (with the correct token and channel name):

curl -X POST \
     -H 'Authorization: Bearer xoxb-your-token' \
     -H 'Content-type: application/json;charset=utf-8' \
    --data '{"channel":"#test","text":"Hello, Slack!"}' \
https://slack.com/api/chat.postMessage

If you go to that channel in your slack workspace, you should now see a message from your bot! You just made an HTTP POST request — asked a server to post a message somewhere.

Programming the Bot

We want to do the above programatically. There are a few different ways you can set up a slackbot. I’ll cover the following:

• Triggered periodically (on a schedule) to say something
• /slash commands

The second requires a server running, while the first does not.

Scheduled Messages

Let’s say you want to periodically send a message somewhere — maybe every Monday morning. Go to the text editor where you opened up slackbot-tutorial.

You should see a file scheduled.py. Take a look: sendMessage is a function that fires off the API call to slack and posts a message. At the bottom, you’ll see the main method: what executes when you run the script. Here, you’ll see a few things to note:

• SLACK_BOT_TOKEN is pulled from os.environ['SLACK_BOT_TOKEN'] — how? Run export SLACK_BOT_TOKEN="xoxb-your-token" in your terminal to set this variable.
• a scheduler is used here, and there’s an infinite loop that checks for events on the scheduler. By default here, I’ve scheduled the sendMessage function to be called every minute.

To test this out, go back to the terminal where you’re in the slackbot-tutorial directory and run

export SLACK_BOT_TOKEN="xoxb-your-token"
python scheduled.py

You should see the log messages print. Make sure you’ve changed **channel=#test** in the code to your test channel name (if different) and added your bot (in the slack channel, type /invite @botname. Let it run for a couple minutes and watch the messages show up on Slack!

This is, of course, a super basic implementation of a scheduled message sender — you can actually do this just with slackbot /remind #test “Hello, Slack!” every Monday at 9am.

The true power here is that you can substitute in any function for sendMessage, leveraging the power of interfacing with external services through APIs, doing math, etc and then constructing a message to post.

Slash Commands

This one requires a little more setup — go back to your app settings > Slash Commands. Create a new slash command: for example, /test. For the request URL, you’ll need to either deploy this web server (I use Heroku), or run a local ngrok instance to test it. The latter will run it locally, and is best for testing. You can brew install ngrok or get it from here.

In the starter code repo, look for slashCommand.py to start understanding this method. To start the server, run python server.py. The Request URL to put in Slack will be given by your ngrok instance and the @app.route in your code — it would be something like http://a1234b5cde6f.ngrok.io/slack/test (the bold part comes from the route defined in the code). You should be able to test the slash commands in your Slack workspace. From the tutorial code, try /test.

Moving Forward

Now you have a very basic slackbot that either operates on a command or runs every so often. Be creative with how you use it! Think about what else you can link this skeleton to to make it more useful.

Other ways your bot might respond

1. Actions/responses could be triggered by mentions or certain phrases. This requires running a server and listening the messages somewhere.
2. You bot could be conversational, and might contribute to threads. Check out some NLP to get started on having intelligible conversation! Word2Vec + TensorFlow or Keras might be a place to start. DialogFlow is also great.
3. Link it up with some other APIs. Maybe you want to be able to interact with a Google Sheet and run some calculations. You might want to send other users a message based on some actions. Integrate buttons. Perhaps you want to trigger messages based on something else.

Why create a Slack Bot ?

I am an HR professional. More specifically I am a Human Resources Information System (HRIS) Consultant. I work with Application Tracking Systems, Learning Management Systems, and Core HR. But I have never had the opportunity to work with an HR Bot. Which may be the Future of HR.

I read a lot about bots on Slack and Messenger, and used some of them in my daily life — Product Hunt, GitHub and Trello. But for HR purposes, I have never had the opportunity to work with a tool tailored for my needs.

That’s why I decided to work on my own bot.

Me starting to work

My Goals

My bot should be able to manage all the needs a small company could have on Slack:

• Onboarding
• Putting people in touch
• Reminders
• Announcements
• Birthdays /Anniversary
• And many more

Reviewing the basics

For this program, I’ll use:

• Botkit
• Node JS
• Express Server
• MongoDB
• Slack API & of course

Botkit is:

One easy way to build bot users, especially if you already work with Node.js, is Howdy’s Botkit. Botkit is a framework that takes care of most these API gymnastics, so you can focus on your bot’s behavior.

Exactly what I was looking for :-)

Botkit provides a boilerplate for Slack. But I have chosen to start from scratch to have a better understanding of my bot. However, it’s a good idea to train yourself with a bot created on Glitch.

How do Slack bots work?

I am not an expert. I have read again and again Slack and Botkit’s official documentation. I’m still not sure I understood everything. Here is my understanding of a Slack bot’s behavior:

Every App on Slack has a “scope” which is a perimeter on which an app can read or perform actions. A bot is part of an application created and installed on Slack.

Therefore, when you install an app on Slack, you give access to some information and permissions to it. For your bot, you want it to be, at least, able to send and reply to messages of other users.

There are then two cases:

1. You want your bot to react to events happening directly in Slack
2. You want your bot to react to events happening on your server

We will view both of them in this post!

Getting Started

Before anything else, you will need a server. In my case, Express.

Below you’ll find my server.js file:

var express = require('express');
var app = express();
var http = require('http').Server(app);
var dotenv = require('dotenv');

// configuration ===========================================
//load environment variables,
dotenv.load();

// public folder for images, css,...
app.use(express.static(__dirname + '/public'))

//parsing
app.use(bodyParser.json()); // for parsing application/json
app.use(bodyParser.urlencoded({
    extended: true
})); //for parsing url encoded

// view engine ejs
app.set('view engine', 'ejs');

// routes
require('./routes/routes')(app);

//botkit
require('./controllers/botkit')


//START ===================================================
http.listen(app.get('port'), function() {
    console.log('listening on port ' + app.get('port'));
});

This port must be public and accessible, not just on a localhost.

For the moment, this server is a blank page, showing and processing nothing.

You’ll then need a Slack App: just follow this link to create one.

Then, you’ll have to configure your controller. The controller is the brain of your bot. It contains every skill and configuration. Below is my botkit.js file. It has almost the same content found in Botkit’s Starter kit available here: https://github.com/howdyai/botkit-starter-slack

var mongoUri = 'mongodb://localhost:27017/nameofyourDB'
var database = require('../config/database')({
    mongoUri: mongoUri
})
var request = require('request')

if (!process.env.SLACK_ID || !process.env.SLACK_SECRET || !process.env.PORT) {
    console.log('Error: Specify SLACK_ID SLACK_SECRET and PORT in environment');
    process.exit(1);
}

var controller = Botkit.slackbot({
    storage: database,
    clientVerificationToken: process.env.SLACK_TOKEN
})

exports.controller = controller

//CONNECTION FUNCTIONS=====================================================

exports.connect = function(team_config) {
        var bot = controller.spawn(team_config);
        controller.trigger('create_bot', [bot, team_config]);
    }
    // just a simple way to make sure we don't
    // connect to the RTM twice for the same team
var _bots = {};

function trackBot(bot) {
    _bots[bot.config.token] = bot;
}

controller.on('create_bot', function(bot, team) {
    if (_bots[bot.config.token]) {
        // already online! do nothing.
        console.log("already online! do nothing.")
    } else {
        bot.startRTM(function(err) {
            if (!err) {
                trackBot(bot);
                console.log("RTM ok")
                controller.saveTeam(team, function(err, id) {
                    if (err) {
                        console.log("Error saving team")
                    } else {
                        console.log("Team " + team.name + " saved")
                    }
                })
            } else {
                console.log("RTM failed")
            }
            bot.startPrivateConversation({
                user: team.createdBy
            }, function(err, convo) {
                if (err) {
                    console.log(err);
                } else {
                    convo.say('I am a bot that has just joined your team');
                    convo.say('You must now /invite me to a channel so that I can be of use!');
                }
            });
        });
    }
});

//REACTIONS TO EVENTS==========================================================
// Handle events related to the websocket connection to Slack

controller.on('rtm_open', function(bot) {
    console.log('** The RTM api just connected!')
});

controller.on('rtm_close', function(bot) {
    console.log('** The RTM api just closed');
    // you may want to attempt to re-open
});

Unlocking the first case: react to the events happening on Slack

When you give the right permissions to your app, every time a message is sent on a channel, Slacks sends a request to your server with some information — the channel ID, the user, the timestamp and most importantly, the content of the message.

If we want our bot to react to a simple message like “Hi”, we have to give Slack an address to send the information to.

In a routes.js file write:

var Request = require('request')
var slack = require('../controllers/botkit')
module.exports = function(app) {
 app.post('/slack/receive', function(req,res){
//respond to Slack that the webhook has been received.
    res.status(200);
// Now, pass the webhook into be processed
    slack.controller.handleWebhookPayload(req, res)
  })
}

We now have a webhook : http://your-ip-or-domain:port/slack/receive

Once Slack is informed of this route via the Event Subscriptions page of your Slack App, it will be able to send it JSON. You will be able to receive it thanks to the parsing part of the server.js file above.

Here is a (simple) schema to explain the process behind it:

1- SLACK « Here is a JSON file with the latest event on your Slack Channel »

2- SERVER « Okay well received, I send it to Botkit»

3- BOTKIT «Here is a temporary answer, wait a second»

4- BOTKIT « Yeah! I hear a keyword, here is a JSON object with the action to perform »

If we want our bot to react every time it hears “Hello”, we can simply add this .hears() function to our controller:

controller.hears(['hello', 'hi'], 'direct_message,direct_mention,mention', function(bot, message) {
controller.storage.users.get(message.user, function(err, user) {
        if (user && user.name) {
            bot.reply(message, 'Hello ' + user.name + '!!');
        } else {
            bot.reply(message, 'Hello.');
        }
    });
});

Notice the storage.users.get() part in this snippet. Botkit is compatible with almost all the database systems available on the market. I have decided to use MongoDB because it was on my learning list for a long time. Plus the documentation with Botkit is detailed.

Now, we have to let our imagination do the work and find some fun features to create.

Second Case: initiate a conversation with your bot

For this feature, I wanted my bot to react to events which were not initiated on Slack. For example, do a daily routine. If it’s someone’s anniversary in the company, send them a survey asking their feelings about their first months/weeks.

I have decided to use node-cron: https://github.com/kelektiv/node-cron to manage the daily check.

Here is below a cronjob firing every weekday at 9:00 am. Thanks to the Date() method, the bot gets today’s date and can compare it to the “joinedDate” of the user.

To get only the right users and avoid a forEach loop, we can use a query on our Database:

var dailyCheck = new CronJob('00 00 9 * * 1-5', function() {
        /*
         * Runs every weekday (Monday through Friday)
         * at 09:00:00 AM. It does not run on Saturday
         * or Sunday.
         */
        console.log(`DailyCheck triggered ${new Date()}`)

        //Gets today's date
        let d = new Date()
        d.setUTCHours(0, 0, 0, 0)

        let threeMonthsAgo = new Date()
        threeMonthsAgo.setUTCMonth(d.getUTCMonth() - 3)
        threeMonthsAgo.setUTCHours(0, 0, 0, 0)


        let sevenDaysAgo = new Date()
        sevenDaysAgo.setUTCDate(d.getUTCDate() - 7)
        sevenDaysAgo.setUTCHours(0, 0, 0, 0)


        controller.storage.users.find({
            "joinedDate": {
                "$eq": +sevenDaysAgo
            }
        }, function(err, user) {
            user.forEach(function(member) {
                console.log(`Message was sent to ${member.name}(${member.id})`)
                bot.startPrivateConversation({
                    user: member.id
                }, Conversations.sendSurvey7)
            })
        })
    }, function() {
        /* This function is executed when the job stops */
    }, true,
    /* Start the job right now */
    timeZone = 'Europe/Paris' /* Time zone of this job. */ )

And… Tada!

_“A robot named Pepper holding an iPad” by [Unsplash](https://unsplash.com/@agkdesign?utm_source=medium&utm_medium=referral" rel="noopener" target="_blank" title="">Alex Knight on <a href="https://unsplash.com?utm_source=medium&utm_medium=referral" rel="noopener" target="blank" title=")

Conclusion

After more than a year of being a camper and learning to code, I am really happy to be able to start and finish a project like this one. I now have a bot working and performing almost all the actions I had in mind at the design phase. And I still have a lot of ideas!

I am still working on this bot. The GitHub repository is available here: https://github.com/alexandrobin/hrbot. Some of the commits are in French, but the codebase is commented in English. :-)

Besides, it’s quite easy to deploy it on Heroku with a Mongolab database if you don’t have a server!

If you have some suggestions or are interested by this article and project, feel free to leave a comment ! I would be happy to discuss with you.

What is Slack?

If you are new to Slack, it’s a great platform for team collaboration and instant messaging used in and out of organizations to help team communication and collaboration.

I first used Slack for a study group. You can create different channels to separate messages and discussions. You can create private channels as well to keep messages private in a team.

The best functionality is that it also allows integrations on it’s platform. And this is what makes it different than other messaging and collaboration platforms.

You can integrate Google Calendar, Twitter, Trello, and more. It also let’s you create custom applications like bots.

Project

In this post, I will walk you through building a MeetupBot for Slack using Node.js. It will give you list of meetups going on near your location based on your interest.

Feeling excited?

It will use Slack’s slash commands. You can type /meetupbot from within Slack to call the MeetupBot and it will greet you along with the list of commands.

I built this project as part of Chingu cohort with my 2 team members Zameer and Linus

You will need basic knowledge of Node.js and how APIs work. Let’s get started.

Steps for building MeetupBot for Slack

Step 1 — Project Setup

my repo URL : slack-meetup-bot
Glitch : glitch.com
Meetup_api : meetup.com/meetup_api

• First fork my repository here.
• Then go to glitch.com and create a project and edit the project name to a shorter name.
• Click on the Project Name &gt; Advanced Options. Then click Import from GitHub. You first need to grant access of the GitHub repo to import your repositories into Glitch.
• Go to Meetup Api here and click on API Key tab and save that as you will pass it with every request to Meetup API.
• In your Glitch project open **.env** file and set a variable SECRET as Your Meetup API Key as SECRET=<MeetupApiKey>
• Click on Show Live in Glitch and you will get your Glitch project URL.

Step 2 — Create a Slack App

• Go to Slack apps and then click on Your Apps &gt; Create New App.
  It will show you following screen:

Enter the App Name and select Development Slack Workspace and click on Create App. Now we need to do 3 things to see it working in our Slack workspace.

On the next screen you will see your App Configuration page with following things:

1. Activate incoming webhooks.
2. Create Slash commands.
3. Install your app to your workspace.

• Now click on Incoming Webhooks and activate it.
  Incoming Webhooks allows you to post messages into Slack.
• Next thing click on Slash Command” and create one as /meetupbot. Command as /meetupbot, Request URL as **<glitch-project-url>/mee**tupbot, and add a Short Description and a Usage Hint.

• By activating Incoming Webhooks and creating Slash Commands you should have already got a green tick on Permissions.
• Now click on Install your app to your workspace and that will take you to next screen to confirm and authorize before installing. And now you are good to go.

Step 3 — Test it in your channel

Open your Slack team channel and type /meetupbot and you should be able to see your commands popping up. Click Enter and you will see a greeting message from MeetupBot and a list of commands that you can use.

Since you have created only one slash command go to your App page and create 1 more commands as /meetupbot-show with Request URL as <glitch-project-url>/meetupbot-show (Follow step 2 — create Slack Command).

Now try this command, type **/meetupbot-show San Francisco and JavaScript** then hit Enter and you will see list of JavaScript meetups in San Francisco with details like Name of Event and Meetup Group, Date of Meetup, Status, Venue and Rsvp Count. Click on Event and it will take you to their Meetup Event page.

So that’s it, Congratulations you have successfully created a MeetupBot for Slack using Node.js.

Lets understand the code.

We are using the Google Geocode API to get Latitude and Longitude from location/address parameter that is passed in the command. This latitude and longitude along with interest parameter is then passed to the Meetup API to get a list of meetups.

Also we are using Express.js and JavaScript Promises, npm packages Moment.js for parsing dates and Request to make API calls.

What happens when you call **/meetupbot** ? It makes a Post request to glitch-project-url/meetupbot.

The request body contains user_name, text and other info. The reply object is the JSON response format for the Slack API.

What happens when you call **/meetupbot-show** ? It makes a Post request to glitch-project-url/meetupbot. The request body contains the user_name, text (such as location and interest separated by “&”) and other info.

We first make sure the location and interest parameters sent with the command are not blank.

Then we pass location to getGeocode method which is a JavaScript Promise that make calls to Google Geocode API and returns Latitude and Longitude, which is then passed to getMeetupEvents Promise to get list of meetup by making a call to Meetup API.

The Meetup API returns an array of meetup event objects and we iterate through this array to make an array of event objects in Slack response format and keep pushing it in the attachment array which we created in the start.

And that reply with event attachments is then returned as response and is shown in your Slack.

This response will only be visible to you (the user who calls the bot ) and won’t disturb other members of channel.

In the above code we have 2 Promises as follows:

• getGeoCode() — This take location as parameter and makes an API call to Google Geocode API with location as query string and returns latlong.
• getMeetupEvents() — This takes location and interest as parameters and makes API call to Meetup API containing the API Key, Latitude, Longitude, text or interest and radius as query string parameters.

The above code uses JavaScript Promise which is basically used to handle asynchronous operations. It allows you to write asynchronous code that is similar in style to synchronous code.

Also helps in avoiding nested callbacks by using chainable then. If you have nested callbacks in code then it looks like pyramid structure also known as “callback hell”.

Official MeetupBot

The official MeetupBot has one more command as /meetupbot-find to get list of meetup group in your location/area and also has Oauth code so that you can install it by clicking add to slack button.

You can find it here MeetupBot landing page and MeetupBot github repo. Start using it now.

Did you find this article useful? Write your comments below.

If you found this article helpful, do share with your friends and give this couple of claps.

— Thank you :)

Originally posted here.

Build a real-world serverless application on AWS with Serverless framework and ready-to-use functions from StackStorm Exchange open-source catalog.

Episode One | Episode Two | Episode Three | Episode Four

Read on if you are:

• A serverless developer using Serverless framework who wants to check out ready-to use functions from the StackStorm Exchange open-source catalog,
• A StackStorm user who lives in AWS and misses the breadth of StackStorm Exchange integrations there.
• Anyone who has 2 hours to follow-along and learn serverless with something more elaborate and real-life than a Hello-world example.

If you only got 8 minutes to spare, skim the text and examples, spend an extra 30 seconds browsing StackStorm Exchange to see the potential, and bookmark this post to get back to it when you need it.

Intro

When I explored Serverless with Python, StepFunctions, and Web Front-end, one thing I missed is a catalog of reusable integrations. Something like 200 connectors for Azure Logic apps. Or 130 integration packs for StackStorm.

When we need to wire in Slack, Jira, Stripe, or Nest, could we skip digging into their APIs and authentication intrinsics, and just grab a ready-to-use function?

Now we can do exactly that: StackStorm just announced a plugin for Serverless framework that turns integrations from StackStorm Exchange into AWS Lambda functions.

In this tutorial, I’ll show how to use the plugin and Exchange integrations, in the context of building a serverless community on-boarding application from a ground-up. Let’s make this conversational and fun.

I assume no familiarity with either Serverless framework nor StackStorm. But you should know how to code, and be smart to compensate for mistakes and omissions I’ll inevitably make.

We will be going slow, with excruciating details, thus it is going to be four episodes.

In this first episode, I’ll set everything up and deploy my first StackStorm Exchange action.

In the next episode, we’ll add more actions.

In the third episode I’ll wire them together with a AWS StepFunction.

In the fourth episode we’ll add Web Front-end with the Reflection and Summary. Each episode will take about an hour to follow.

Ready? Let’s rock.

The application

We will build a community on-boarding application. Actually, rebuilding from scratch the one we run at StackStorm. It’s like SlackIn with a multi-step customizable on-boarding workflow. The app presents a registration web-form, which passes new user info through API Gateway to the StepFunction workflow that carries on-boarding steps.

In my case, the steps are 1) invite users to Slack 2) create contact record in ActiveCampaign CRM tool and 3) put a user record into internal DynamoDB table. Here is how it looks:

You can find the previous implementation on github, or use it and join StackStorm community on Slack for questions about StackStorm Exchange integration.

Getting Ready

First, you’ll need AWS account, NodeJS, Docker, and Serverless framework. And Slack! As our first action will be inviting users to Slack.

1. Make sure Node.JS is installed, and it’s version is 8.4.0 or higher.
2. Install Serverless framework, and setup AWS credentials for it following this guide.
3. Install Docker. The plugin uses it for build environment to make the lambdas binary compatible to AWS execution environment no matter what OS you’re using for development. There is a way to make it work without Docker but don’t take chances.
4. Slack! Our action will require admin access and will be using undocumented Slack API (docs here, pun intended) to invite new users. The easiest is to just go ahead create a new team. Takes 4 min. Slack won’t mind — they’ll show growth to their VC.
5. Once the workspace is created, time to get an authentication token. Go to api.slack.com/custom-integrations/legacy-tokens. Fear not the “Legacy Warnings”: this tutorial will turn legacy before they do. Do what they say, get your token.

PRO TIP: Use this quick hack to get and use your own user’s auth token. Much faster, good for playing and debugging. But please never, never use it for production!

Create a project, add a first action

Try sls --help to make sure that at least something works. sls is a shorthand for serverless, the Serverless framework CLI. Now put your coffee aside, time to create a project. Some folks like using templates that come with serverless: sls create --template. I prefer to start from scratch:

mkdir slack-signup-serverless-stormlesscd slack-signup-serverless-stormless

npm init

# Once you answer questions, the project is set up.

Next, install [serverless-plugin-stackstorm](https://github.com/StackStorm/serverless-plugin-stackstorm), the one that plugs in the StackStorm Exchange actions.

npm install --save-dev serverless-plugin-stackstorm

… and create a minimal serverless.ym file so that sls command will pick up the plugin:

Now, create the first action. I’ll use a battle-tested Slack pack from StackStorm Exchange. Which action, you say? Ok, StackStorm Exchange is not smart enough yet to show pack’s action list, but sls stackstorm will rescue us.

sls stackstorm info --pack slack

Oh my! There’re so many! what are they? I guess I need a PR to print action description. Meantime, | grep admin will get us the one we need: slack.users.admin.invite. Let's query the action for it's parameters:

$ sls stackstorm info --action slack.users.admin.inviteslack.users.admin.invite ...... Send an invitation to join a Slack OrgParameters  attempts [integer]  ......... description is missing  channels [string]  .......... Channels to auto join.  email [string] (required) ... Email address to send invitation to.  first_name [string]  ........ Users first name  set_active [boolean]  ....... Should the user be active.  token [string]  ............. Slack API token.Config  action_token [string]  ...... Slack Action token.  admin [object]  ............. Admin-action specific settings.  post_message_action [object]   Post message action specific settings.  sensor [object]  ............ Sensor specific settings.

Awesome! We can see that there is only one required parameter, email, but I'll add first_name to stay conversational. The token can be passed as parameters, or as config. And if I choose to use config, my prior tribal knowledge hints that the admin [object] requires only admin_token. The very one I asked you to remember when you were setting up Slack workspace.

PRO TIP: While we are still polishing the plugin to expose all the Config details, you can find it out by exploring StackStorm Exchange pack config schema in config.schema.yaml file. For example, here is config.example.yaml for our Slack pack.

Now we have all we need to create the heart of any Serverless project: the serverless.yml. Here it comes:

This is a good time to learn a bit of Serverless. Take a quick break to skim Core Concepts and bookmark Serverless.yml Reference.

I threw in the events section in lines 9:12 so that we can invoke the function with REST call through AWS API Gateway endpoint. Serverless framework will do all the Gateway magic.

Note that this default configuration instructs API Gateway to pass the REST POST call with POST body under the body key (details here. When we POST {"first_name": "Santa", "email": "santa@mad.russian.xmas.com"}, the event passed to the Lambda is:

..."body": {    "first_name": "Santa",     "email": "santa@mad.russian.xmas.com"}

Knowing the input data structure is important to map it to the action input parameters. It’s intuitive: input represents event parameter of AWS Lambda programming model(BTW should we call it event? Vote with a PR!).

Jinja is used to map the inputs; our JavaScript friends who're less familiar with this common Python tool find it intuitive enough in simple cases; and Stack-overflow is full of magic Jinja tricks.

In lines 16:17 of serverless.yml I map the two parameters from input body to desired action input parameters. Optionally, you can also form a function output from action results. I’ll keep it simple for now (line 20:22) and save more tricks for later.

To keep the config separate, I created a file env.yml that and put my config parameters in it:

# ./env.yml# WARNING: Don't commit to Github :)slack:  admin_token: "xoxs-111111111111-..."  organization: "my-team"

Then I used it in serverless.yml like this: admin: ${file(env.yml):slack}. Note how this syntax puts the object from the key in the file to the key in serverless.yml.

Ok, that’s it! The function is ready to fly to AWS with sls deploy. But I take it sloooow. Step by step. First, I’ll package it locally.

sls package

The very first time takes a long time as this is the time when the plugin installs its runtime dependencies. It pulls the Docker images from the Hub. It installs StackStorm runners — the code that knows how to run StackStorm Exchange packs. It pulls the slack pack from Exchange. It installs slack pack python dependencies. It does a lot of work for us, and it takes time. Good news: it's only the first time.

Oh, did I mention that you must be connected? Or do we assume internet connection a basic commodity like breathing air and electric power? At least before FCC repeals Network Neutrality? So yes, you need internet connection to live in the serverless world.

Now let’s run this locally.

sls stackstorm docker run --function InviteSlack --verbose \--data \'{"body": {"first_name": "Santa", "email": "santa@mad.russian.xmas.com"}}'

Local runs happen in a container — you’ll see Spin Docker container to run a function CLI output. It takes a bit longer, but ensures that the execution environment matches AWS lambda very closely, so better safe than sorry.

When I debug input and output parameter transformations, I may not want to call the actual function, like in case of Slack rate-limiting API. Use --passthrough parameter that tells the plugin to do the dry-run and skip the action invocation.

Now we are really ready. Let’s deploy the function to AWS, and run it “serverless”.

sls deploy

It will take some while — now it’s serverless (and honestly, our bundle is a bit bloated, patience! plugin developers are currently busy solving other problems, we will optimize it as soon as we can)

PRO TIP: if something goes wrong at this point, most likely something is not right with your AWS setup. Go back to “Getting Ready, step 2”. Read Serverless Installation doc. Google, Stack-overflow, Serverless Gitter channel or Forum.

You might be curious to see how it looks in the AWS console. If the PRO in you is saying “no, you should stay cool and use CLI”, don’t listen. Go indulge yourself, open a browser and take a good look at your Lambda. While there, you might also inspect the API Gateway endpoint that sls created for you.

But to test it, we’ll go back to terminal. Here is how to run your Lambda with sls:

sls invoke --function InviteSlack --log --data '{"body": {"first_name": "Santa", "email": "santa@mad.russian.xmas.com"}}'

Finally, let’s POST to the API endpoint. The endpoint was printed at the end of sls deploy and you should have taken notice, but it's OK if you didn't: you can always get it by typing sls info.

You curl lovers go ahead use it to POST; be sure to set Content-Type=application/json header. Me - I'll show off with httpie, aka CURL for humans:

# DON'T copy-paste! Use YOUR endpoint!

http --json POST  https://YOUR-ENDPOINT.amazonaws.com/dev/invite \email=test@example.com first_name=Dmitri

How did it go? Everything worked, at least for me. Let’s fire yet another most useful slscommand to check the CloudWatch logs:

sls logs --function InviteSlack

Success! And the end of the first episode. Enough for now: Christmas time is here, take it slow, enjoy!

The code example so far is on Github at 1-add-first-action.

Episode 2: Adding more actions

Hope this helped you learn something new, find something interesting, or provoked some good thoughts. Please share your thoughts in the comments here, or tweet me @dzimine.

I’m 15, and I recently signed up for the Global Hackathon by Product Hunt. It runs for the month of November and there are 7,950 people participating from around the world ?. Crazy!

From what I’ve seen in my 3 years as a student programmer, developers love hackathons. They’re an opportunity for product makers meet up, drink Red Bulls, and stay up all night coding.

It’s kind of like a triathlon for developers, who often go for days with minimal sleep. It’s a hard-fought race to the finish (if you even manage to finish). And it’s a chance to compete under pressure.

The three stages of a hackathon

Shortly after I registered for the month-long event, I realized that competing in this hackathon is similar to entering a real triathlon. Just like in a regular triathlon, there are 3 stages, which all require a lot of skill and endurance:

• The first stage is about coming up with the idea (the swim).
• The second stage is about turning the idea into something real (the cycle).
• The third and final stage telling everyone how helpful your product is and convincing them to try it (the run).

Compressing all of these stages into a short moment in time

I’ve already built something that started out as an idea. It’s called Christopher Bot, a Facebook Messenger bot that helps high school students remember their homework, and it’s been written about here and here and here. It also got acquired! But, you can read about that in my other Medium story here.

Before choosing to work on Christopher Bot, I had lots of ideas for products to build. My dad and I talked about how some ideas catch on, and some don’t. The ideas that catch on always seem to solve a problem.

If enough people have a problem and your product solves it well, and you can find a way to share your solution with those people, it has a good chance of succeeding.

I followed that advice when I chose to work on a homework bot. Students often forget what homework they’re assigned during the day, so I needed to build something that would stop people from forgetting their assignments. Christopher Bot was born.

I’m using that same advice in the Product Hunt hackathon.

I needed to find a problem. And in that problem, there would be a solution.

But where to begin?

Swimming for an idea

In the Product Hunt competition, there are a bunch of existing platforms you can build for: Google Assistant, Slack, Blockchain, Artificial Intelligence and Augmented Reality. You don’t have to build for any of them, but some cool prizes are awarded within these specific categories.

Seeing these options actually made things easier for me. It narrowed down the list of possible problems to solve. All I had to do was find a problem in one of these categories.

I’m not yet familiar with blockchain technology… or AR or AI. So that made things even easier. Google Assistant is cool and could be interesting to develop for, but it turns out I’ve spent a fair bit of time using Slack.

I think Slack is pretty awesome and I’ve tried out a bunch of Slack apps. So I decided to build something in the Slack category.

At first, I thought about building something that would remind you about all your mentions in public channels — because once you click on a channel with a notification for you, the notification disappears and you have to respond right away or you might forget that you were mentioned.

But then came some bad news. My dad (who likes to talk these things through with me) experiences this notification problem, but he showed me that Slack already has a built-in solution.

You can mark important messages where you’re mentioned as “unread”, and you can even tell Slack bot to remind you about an important message after a specific period of time.

So it was back to the drawing board for me. ☹️

During the same conversation where I found out that bit of disappointing news, I also noticed that there’s no easy way to DM multiple people at the same time.

Was this even a real problem? It turns out (based on some quick Google searches) that people have asked about how to do this in Slack — and even in products that compete with Slack.

If you’re part of a big team and you want to ask multiple people the same question, but you don’t want everyone in a channel (or in a group DM) to see their responses, there’s no easy way to do it in Slack.

I checked hundreds of existing apps in the Slack app directory — and couldn’t find anything to solve this particular problem. But I found that the most popular slack apps are the ones that solved other problems for teams… another reminder that I needed to work on solving a real problem.

For example, getting everyone on your team to vote on something (like where to go for lunch) is a pain. So the people behind Simplepoll decided to solve that problem by enabling someone on a Slack team to easily create a quick poll, ask their team to vote, collect the responses, and count up the votes.

They found a problem common to many teams and built a nice simple solution. Which is exactly what I wanted to do.

My hackathon project is an idea that’s based on a real problem for Slack teams…

The problem: You want to ask multiple people the same question but you don’t want the entire team — or even a portion of the team — to see the question OR the responses. You can’t use a group DM or public channel… because everyone will see what you wrote, and see the responses (unless people are instructed to respond privately in a DM). It’s not very ideal.

Another less than ideal solution is to go down the list of team members and create a new DM, one after the other, by pasting the same message for each person. It’s so tedious that I think most people wouldn’t even bother.

So my entry for this hackathon is called MultiDM, a very simple Slack app that gives you and your team the ability to DM multiple people at the same time — using a single message, sent from any channel.

(Swim stage finished!)

Let’s say you think of an important HR-related question you want to ask 5 people on your team. And let’s say you’re already in the #general channel.

From the channel, you would just type “/multidm @john @jane @henry @samantha @jake I need your birthdate for HR — can you please let me know ASAP?”

Nobody will see the message you typed into #general. Instead, each of the 5 team members will receive a normal-looking DM from you — which they can respond to normally, and you’ll receive their answers without anyone else seeing the answers or even knowing that you asked multiple people the same question.

So that’s it. Next up is the long, difficult cycling stage. ??

If you’re interested, you can sign up to be one of the first to try MultiDM.

Thanks for reading about my process for choosing a product idea. Most ideas aren’t successful because they don’t solve a real problem. People use products that fix a problem.

So for your next product (or hackathon idea), first find a problem, and then go build something to solve it!

This post walks through the creation of a serverless Slack command written in Golang, and deployed to AWS Lambda in seconds with Up.

You’ll be creating a /time <url> command used to check how long a website takes to respond. Up uses your own AWS account. You can host a large number of custom apps for free while still utilizing the AWS free tier (1 million requests/m).

Check out the installation instructions as well if you’re new to Up.

Registering the Slack command

The first step is to create a Slack app, allowing you to register commands, among other things.

Once created, click “Slash commands” in the menu on the left, and register the /time command. You’ll need to keep this page open for a minute since we need a Request URL so Slack knows where to send requests.

Creating the Slack command

In your project’s directory create a file named up.json. Make sure to replace PROFILE with your AWS profile name (read more).

{  "name": "slack-cmd-test",  "profile": "PROFILE"}

Now we need a little HTTP server to process the Slack command POST request. Create a main.go file with the following net/http server.

Deploy it with up .

NOTE : The first deploy may take roughly 60s to set up resources.

Now you need to grab the URL and paste it into the Slack command page so Slack knows where to send requests. Copy the command’s URL to the clipboard using:

$ up url -cCopied to the clipboard!

Paste it in the Request URL field, then you’re good to give it a test run:

With any luck, you’ll see a Hello World response!

Performing the request

Slack sends a POST request with form inputs, otherwise known as application/x-www-form-urlencoded (a tragically named mime type, turned standard-ish).

To access the form values, parse the form with the ParseForm() method. In this case all we need is the “text” field from r.Form, the parsed form.

Now that the request is portion is complete, import the time package and wrap the request with time.Now() and time.Since() to record the request duration.

Deploy again with up and immediately after the deploy you’re ready to test out the real version:

Two files and a few commands later, you’re done! Repeat for as many Slack commands as you need.

Testing locally

One of Up’s strengths is deploying traditional “vanilla” HTTP servers. This means there is nothing new to learn when testing on your machine, develop the app as you always would.

Here’s an example of this application tested via curl :

$ PORT=3000 go run main.go$ curl -d 'text=https://apex.sh' http://localhost:3000/

https://apex.sh took 19.33542m

Hope that was helpful! Check out the documentation for more help, and follow on Twitter for updates and various software rants.

Powered by a complete serverless stack

_Group of Developer Advocates watching developers coding — Credits: [Pixabay](https://pixabay.com/en/meerkat-snout-baby-mammal-guard-275967/" rel="noopener" target="blank" title=")

Developer Advocates or Evangelists are often asked how they measure success.

One could argue that GitHub ⭐️’s on repositories are great. And Ash Hathaway shares her thoughts here.

Others could say that Stack Overflow questions give a good sense of an API popularity. I would agree with this statement.

If you don’t have a forum for your product, developers may end up asking questions directly on Stack Overflow.

I would not encourage companies to redirect all their support questions there or pushing for their brand tags, this is just bad. You are hijacking a community for your own needs instead of contributing to it.

But :

What happens when someone is posting a question there?
How do you get notified?
How can you react quickly?

In my experience, you can only receive notifications when there are new questions on a particular tag. This might not cover all the questions posted about your API.

You can also use tools like Mention. It covers more than Stack Overflow, but it’s not instantaneous.

To be more reactive, I hacked together something for our team at 3scale a long time ago. I recently rewrote it using serverless technologies. It monitors questions about 3scale and posts them on our #support Slack channel. The support team can jump on it and answer quickly.

I want to share this project, so you too can monitor Stack Overflow directly in Slack.

The tools?

To fit in 2017 trend, we will only use serverless technologies, which will make this tool free to use:

• AWS Lambda to host the logic of our app
• FaunaDB to store databases
• Serverless Framework to simplify deployments
• Slack to be notified when a new question is asked

The logic⚙️

Stack Exchange API has an endpoint to search for questions. You can look for a term in tags, in the title, in the body of the question or all at the same time. In the example, we will search in all attributes.

You should create a key to access Stack Exchange API here.

Our function will regularly call this endpoint to check if there are new questions posted. We will use the Schedule Events feature offered natively by Lambda, it’s a similar behavior as a cron job.

We will store the questions in a database to keep track of the ones we already sent to Slack and avoid duplicates.

If a Stack Overflow question is not in our database, we add it to the database and send details to Slack.

FaunaDB

I discovered FaunaDB a few months ago at Gluecon. They present themselves as the first serverless database engine. Everything is hosted on their end. FaunaDB is a globally distributed database that doesn’t require any provisioning. Capacity is metered and available on demand, so you only pay for what you use.

If you are familiar with Firebase, you will recognize a similar data structure and routes to access resources. But it comes with more features, which makes it easier for example to query the database.

Example: How to create an entry in FaunaDB

For this app, you will need a database, with a questions class. We will also add an index questions_by_id on terms data and question_id. This will let us query the questions class by the Stack Overflow id.

If you are concerned about your database usage, you can add TTL to the questions class. This will automatically delete instances older than the TTL value.

Finally, you will need to create a server key for the questions class. This key will be used to authenticate our function to FaunaDB servers.

Example: How to retrieve an entry in FaunaDB

Slack

To post to Slack, we would just need a simple incoming web hook. Create one here.

Configure the project

Make sure you have installed Serverless framework and configured the AWS CLI tool.

You can now clone this project locally.

git clone git@github.com:picsoung/stackOverflowMonitor.gitcd stackOverflowMonitor

In serverless.ymlyou will modify the environment variables to your own values.

FAUNADB_SECRETis the secret we created earlier to access FaunaDB
STACK_EXCHANGE_KEY is the API key to access Stack Exchange API
SLACK_WEBHOOK_URL is the URL of the Slack incoming webhook you’ve created
SLACK_CHANNEL should be an existing channel name in your Slack team such as #support or #stackoverflow
SEARCH_KEYWORD is the keyword you are interested in monitoring such as Node.js or Angular2

Once you have changed all the variables to your own values, we can test if everything works. We invoke the function locally with the following command:

serverless invoke local — function getStackOverflowQuestions

As it’s the first time you are launching the function, it should post a message to your Slack channel. It should look like this:

How the notification should look like in your Slack channel

If you are happy with the result you can now deploy the function with the following command:

serverless deploy

By default, the function is called every 20 minutes. You can customize it by changing the schedule property in serverless.yml file.

Extend the project

For now, we are only monitoring one term. You can launch multiple instances of this function to watch more terms or tags on Stack Overflow.

If you are interested in near to real-time solution, I encourage you to check Streamdata.io. Their tools turn pulling API into streaming API.

If you want some nice dashboards that show how active your community is on Stack Overflow, I recommend Keen.io. You can send all your Stack Overflow data there. Keen offers a variety of libraries to build beautiful dashboards.

We can also add more features in Slack, like buttons or menus. So people can claim a question or get assigned a question to answer.

Conclusion

This was a small project that led me to discover how to use FaunaDB. Using AWS Lambda it’s way more efficient that the Heroku instance that I had in the past.

I hope you’ve found this serverless example useful. The code is open on GitHub so feel free to contribute and add new features.

If you are working for a company that is selling to developers I am sure you already heard the “Be where the developers are.”

In the online world you have a good chance to find developers on websites like Hackers News, Stack Overflow, or GitHub. It’s important to measure what people say about your product or technologies on those sites.

This was a small project that led me to discover how to use FaunaDB. Using AWS Lambda is way more efficient than the Heroku instance that I had in the past.

I hope you’ve found this serverless example useful. The code is open on GitHub so feel free to contribute and add new features.

Or, Everything Old Is New Again

The phenomenon of breaking the fourth wall is well known in the world of theater and cinematography. The breaking of the so-called ‘fourth wall’ is typically brought about by one of the protagonists in the movie suddenly turning toward the camera and addressing the viewing audience, thus breaking the illusion that we’re witnessing a real-life event.

But how does breaking the fourth wall work in software?

Early Human-Computer Interfaces

The first computers were big and expensive and finicky. The way humans interacted with computers at that time was typically by feeding it a stack of punched cards.

Early Interfaces Were Intimidating

You obviously needed a university degree in order to operate computers.

Early Interfaces Were Clunky

A lot of buttons and switches and dials and levers. Intimidating and clunky.

Breakthrough — Text!

Late 1960s — early 1970s witnessed the introduction of the so-called computer terminal. Emulating a typewriter for entering commands, and then displaying the results of the evaluated text on the monitor that looked like a TV screen.

Text Is Intuitive

Pretty much all people find text to be very intuitive — close to the way we think and speak. It feels much more natural to speak to the machine than it is to twoddle the knobs, flip the switches, and pull the levers (not to mention punch the cards or rewire the circuits).

But Computers Are Clunky

In the early days of computers, if you type a wrong command or use wrong syntax, the computer used to throw a tantrum. Temperamental beasts!

Only These People Knew How To Talk To Computers

You may recognize some faces on the group photo below.

Replace Text With Graphical Interface — The Desktop Metaphor

Use pictorial representation to shield people from having to memorize awkward commands and syntax when operating computers. The idea was to present users with some familiar scenery — for example, their desktop. Everyone is familiar with the idea of having a desktop with file folders containing files and also a trash can at the side of the desk etc.

This Graphical User Interface (GUI) was deemed as being even more intuitive than text.

GUIs Quickly Mushroomed Into Something Scary and Non-Intuitive

How is the interface below intuitive? It is as frustrating as the arcane and awkward syntax that the early computers insisted on when processing text.

A Picture Is Worth A Thousand Words

True. But what if most of those thousand words are gibberish? What’s the worth of that?

Bottom Line: People Find GUIs Frustrating

GUIs typically present us with too much information at once. Then the onus is on us to digest all that and try to make sense out of it.

GUIs also tend to enforce ‘one size fits all’ approach, which is not very user-centric.

So What’s The Solution Then?

What if, instead of this poorly thought out buffer that consists of intermediary graphical representation, we were to revert to plain text again? It is, after all, much easier to focus and follow simple discussion threads than it is trying to navigate hairy, convoluted GUIs.

But Computers Are Brittle And Will Not Be As Forgiving As GUIs

We have grown to depend on GUIs as we would depend on training wheels. Installing training wheels gives us a sense of safety — we cannot fall, and yet we can somehow move forward and get to our destination.

Can’t Get Very Far Using Training Wheels

Training wheels are okay for peddling around our back yard, but we can’t use them effectivelly in real life situations.

How To Remove Training Wheels And Learn To Ride Properly?

Break the fourth wall!

How do we break the fourth wall? Stop pushing pixels!

How can we stop pushing pixels?

Frustrating Example

Say we order something online. The next week we may be wondering about the status of our order (hasn’t, for some reason, arrived yet). Frustrated, we open the browser, go to the online store, log in, and then try to navigate to the order status page.

To reach the order status page, we have to navigate through the veritable jungle of confusing menus, shifting layouts, poorly styled links (often barely visible on the page), and so on. To add insult to an injury, these elements keep constantly changing, so we cannot rely on our muscle memory from previous navigation sessions.

Less Frustrating Example

What if, instead of doing all of the above gymnastics and acrobatics, we just do the following:

Go to the command line (say in Messenger or Slack etc.) and type ‘_@merchantname what’s the status of my order?’

That way, we let the merchant service (i.e. Amazon or Etsy or Ebay etc.) do the legwork on our behalf.

Which of the two ‘check order status’ experiences is more intuitive?

Guess What — We Just Broke The Fourth Wall In Software!

By foregoing the GUI, we have switched to interacting with some online service using plain text. And it felt quite natural. Notice how, by doing that, we were not expected to undergo any training.

How’s that possible? Simple — instead of interacting with the bare metal computing machinery, we got in touch with a sophisticated chatbot whose role is to know how to parse and interpret colloquial English text.

How Do We Get Involved With A Chatbot?

We /invite it to our channel. For example, say we find out there is a chatbot that specializes in restaurant recommendations. We wish to get in touch with that bot, and after finding out the name of the bot (say, restobot), we ‘hire’ that bot to work for us by typing:

/invite @restobot

Once invited to your channel, this bot will remain always online, listening attentively for its name to get mentioned.

The Bot Is The Buffer

Similar to how a GUI was the buffer between us, human users, and the cold, bare computing machinery, bots are now replacing GUIs as that warm and fuzzy buffer. Bots are shielding us from having to deal with the temperamental machinery by translating our plain English commands into something that the underlying computing services can understand and work with.

What’s The Value Proposition Of Bots?

Bots are attentive to human needs and sensitive to human frailty.

So Is This A Revolutionary Change?

Not really. It’s the natural outcome of the advancements we’ve made in the field of human-computer interaction. So it’s more of an evolutionary change.

In actuality, this conversation-based interface is not all that different from operating computers via GUIs. Because, if we examine a bit closer what’s going on behind the surface of a typical GUI processing, we’ll find the following scenario:

• A user wants to ask the computer to do something
• User goes to the screen/page where they get presented with one or more input fields
• These input fields, sometime referred to as text boxes, accept text from the user
• The GUI then listens to the user’s gestures, such as ‘send’ or ‘submit’ gesture
• Once the event signalling the expected gesture occurs, the GUI turns around and sends text to the underlying servers

GUIs Are Also Text-Driven

Similar to how bots operate, GUIs also posses the knowledge of how to collect text from users and then formulate the collected values using the strict syntax that the back-end computers can understand.

So if that’s the case, where do pixels come into play?

Most of the time, pixels are being used as decoration. They typically sugarcoat the screen, or a web page, and dress it up in a robe that looks more familiar to the users. Such as, for example, dressing up a web form to look similar to the paper form.

Doing that decompresses the tension users may feel when attempting to work with computers. The intent is to demystify the interaction, and make it feel similar to everyday interactions one may encounter when dealing with various non-virtual services.

Remove Pixelated Decorations, And What Are We Left With?

One word — microcopy.

What is microcopy?

In the above example, microcopy is any text placed next to the GUI control. In a GUI form, we may ask users to enter their phone number. Often times, people are not sure if they want to do that, and also why would we need their personal information? So we place a simple, direct sentence in the brackets, right next to the caption asking for the phone number, explaining the purpose of that request. For example, “we need your phone number for shipping-related questions”.

Or, we may offer a microcopy that is a bit more verbose, such as in the example below:

Conversational Thread

If we imagine removing all pixels and with it the graphical user interface, what we’re left with is a simple conversational thread that gets recorded between the user and the computer.

What Are The Advanatages Of Conversational Interfaces?

• Intuitive
• Sensitive to human frailty (the bot will try to clarify human request if initially not clearly understood)
• Familiar (everyone is already fully accustomed to chatting with family/friends/coworkers)
• Consistent experience across all devices (immune to any concerns/issues related to layouts, fonts, colors, etc.)
• Guarantees full user ownership of the conversation — fully personalized discussion thread is forever recorded and owned by the human user (full transparency, complete audit)

Conversational Commerce

As we’re moving into the post-web 2.0 world, the universal slogan ‘content is king’ now becomes ‘commerce is king’. In the web 2.0 world, when a user completes a transaction via GUI, all the steps that transpired between the user and the online service may have been recorded by the back-end service, but are opaque to the user. In the world of conversational commerce, every step that transpired between the user and the online service is recorded in the conversational thread and is fully owned by the user.

Conversational Interface Experience Is Similar To Regular Customer Support Experience

Similar to how calling a 1–800 number was a mainstream customer support channel before the emergence of web 2.0 and the mobile apps, we’re moving back into conversing directly with the customer suport. Only this time, instead of being put on an indefinite hold and forced to listen to horrible muzak, we’re conversing with bots which are always on and are much faster and more accurate, more detialed than human workforce.

And same as with the 1–800 scenarios, if our call for some reason cannot get resolved in satisfactory manner, we can easily escalate. In the old regime we would ask the customer service representative to talk with their supervisor, and in the new regime we would ask the bot-agent to put us in touch with the human operator.

Let’s Create Our Own Bot Now!

Perhaps the best way to grasp this transition from graphical to text-based user interface is to roll up our sleeves and create a bot from ground up. Creating a bot is quite easy, because the tools necessary for building bots have been largely commoditized. Still, I feel that merely creating a bot would not be an efficient nor convincing demonstration of the importance of conversational commerce. That’s why I’m proposing that we here learn not only how to create a bot, but also how to create a bot that is capable of doing something useful for us.

For example, let’s create a bot that will help us get in touch with some e-commerce service by using plain text as the user interface.

Create Online Commerce Service First

For the sake of brevity, let’s create a simple e-commerce site that will host an inventory of products. Those products will be offered for sale, and some of the products on sale will also be offered at a discount price.

We will use state-of-the-art web development framework (Ruby on Rails) for building this service. If you don’t have the Rails framework installed, please refer to the Rails site for instructions on how to get it installed on your computer.

Once installed, we use Rails to create a new site. Open the terminal and type:

rails new your_site_name

Rails will then create the new project for you, and once you navigate to your new project (by typing _cd your_sitename), you are ready to create the inventory of products to be hosted on the new site. We will create a resource called Product, and will then assign several attributes to it:

rails generate scaffold Product name:string price:decimal on_special:boolean discount_percentage:integer description:text

The above command will create the resource called Product and will implement product attributes, such as product name, its price, whether or not it’s on special, and the discount percentage.

Now is the time to create a database where the inventory of products will get stored. We do that by using the specifications that got created with the previous command. The command to create and install the products database is as follows:

rake db:migrate

The only thing left to do is to start the server and verify that the web site we’ve just created is working as expected:

rails s

Maintain Inventory Of Products

Now that we’ve created our products database and our web site, we should navigate to it and add some products. Open up the web browser and navigate to the http://localhost:3000/products URL.

Of course, the product inventory page will be empty, because we haven’t added any products yet. Let’s do that by clicking on the ‘New Product’ link.

After entering some values, we click on the “Create Product” button and the product is now added to the inventory. Let’s enter a few more products (remembering to click on the “On special” checkbox for some of them).

Now that we have several products in our inventory, time to build a conversational commerce bot. What will be the usefulness of that bot? In order to keep things simple, we will endow this bot with the ability to answer text commands enquiring about the products that are on special.

Where Will Our Bot Live?

A bot must be able to listen to text messages arriving from users, and the best way to make that happen is to add the bot to some messaging platform. Currently, the most attractive messaging platform for adding bots is Slack, so we’re going to use it to demonstrate how to build conversational commerce.

Signup with Slack (if you’re not a member already), and then go to:

https://yourteam.slack.com/services/new/bot

You will be asked to specify the name of your bot. Let’s call our bot ‘gofer’.

After clicking the “Add bot integration” button, we will be able to set our gofer up on Slack. First thing first, let’s choose the icon that will represent our bot. I choose my favourite robot, Bender.

We can also add bot’s first and last name and a description outlining bot’s capabilities.

After saving the integration, we notice the API Token; this token is extremely important, as it allows the integration between our hand crafted bot and the Slack platform. Let’s copy the value of that API Token for future reference.

Final Step — Crafting Our Bot

Now’s the time to open the source code of our e-commerce product inventory site. We must add bot to this site, because the bot will be able to utilize the services built into our inventory site and aswer the questions coming from the Slack users.

First thing we need to do is navigate to the config folder in our product inventory site and create a new file. That file will contain the Slack API Token. We can name this file anything we want; I prefer to keep its name simple, so I call it api.rb. This file will consist of only one line of code:

ENV[‘SLACK_API_TOKEN’]=’xoxb-23830295172-r5CzhzDnUSZQfUfXWmR’

Next we need to tell Rails framework to load that API Token during the intialization phase. We open the config/environment.rb file, and add the following two lines of code:

api = File.join(Rails.root, ‘api.rb’)
load(api) if File.exists?(api)

Now that we have declared Slack API Token and instructed Rails to load it, we need to add our bot to the project. The best way to do that is to navigate to the app folder, and create a new folder simply named bots.

Create a new file in the app/bots folder, and name it _real_timemessaging.rb. This file will deal with the thread used for our bot to listen for the incoming messages. Add these lines to the file, and save it:

$:.unshift File.dirname(FILE)

Thread.abort_on_exception = true

Thread.new do
Gofer.run
end

You have probably noticed that in the file above we have mentioned Gofer; we managed to get ahead of ourselves by mentioning the bot we havent created yet. But that’s okay, because we’re not ready yet to kick start the bot service listening on the channel.

So the real challenge now is to figure out how to craft our bot named Gofer. For the sake of brevity, we will cheat here by leveraging the commodity service known as Slack Ruby Bot. Leveraging this commodity allows us to save time that would’ve otherwise be spent on coding the low level web sockets processing, which is a fairly involved exercise.

The quickest way to leverage this commodity is to open the Gemfile found in the root of the project, and add the following line to it:

gem ‘slack-ruby-bot’

Save the file and then go to the command line to the root of the project and run:

bundle install

When the installation completes, will will have baked in our Slack Ruby Bot commodity service, which we will leverage when creating our Gofer bot.

But before we jump into crafting the bot logic, we need to complete one more step related to the underlying plumbing needed for the Slack bot to work properly. Navigate to the config/initializers folder, and create a new file simply called bot.rb. This is a simple file consisting of only one line of code:

require File.join(Rails.root, ‘app/bots/real_time_messaging’)

It is simply instructing Rails to load the _real_timemessaging.rb file on initialization. And if we look back into the contents of the _real_timemessaging.rb file, we will see that, once the web site boots, it will also run a thread that is responsible for running the Gofer bot.

And finally, on to creating the bot logic! Create a new file in the app/bots folder, and name it gofer.rb. This file will declare Gofer bot as inheriting its capabilities from the commodity we’ve just installed — SlackRubyBot::Bot.

class Gofer< SlackRubyBot::Bot

This bot inherits some rudimentary capabilities from SlackRubyBot, such as the ability to respond to commands. And these commands is what we’ll be teaching this bot, telling it how to respond to each command it receives.

Let’s start with something extremely simple — let’s teach our Gofer bot how to handle the ‘help’ command. Add the following command definition to the gofer.rb file:

command ‘help’ do |bot, thread|
bot.say(channel: thread.channel, text: “Help is on its way.”)
end

This command is going to use the bot to get it to display the text ‘Help is on its way.’ to the channel from where it was asked for help.

Save the file, go to the command line and start the server (rails s). You will now notice additional messages on the command line when the server starts:

Now that our bot Gofer is successfully connected to our Slack team, we can test it. Go to your Slack team, and you will see that gofer bot is online (there is a green semaphore ligh next to its name). Click on its name, and then type ‘help’. You will see that the bot immediately responds with the text we’ve given it above.

OK, neat, so now we see that our bot is working. But how do we get it to tell us what products are offered on special at the moment? Simple — we just add a new command (let’s call it ‘promo’ for simplicity) and instruct the bot to gather information on the products with discounted prices and send us the list back.

Save the file, restart the server, and flip over to Slack to ask gofer what’s on special.

Just to verify that the bot is indeed working in real time, go to the product inventory and make some changes. Like, remove the discount for the Hat and maybe add discount for some other product. After you do that and ask gofer what’s on promo, it will tell you all the latest details.

Conclusion

Latest trends have shown that more and more people tend to spend majority of their online time chatting. As of the early 2016, almost 1 billion active users are spending time on Messenger and other chat apps. As people are getting familiar with texting with their friends, family, and coworkers, they are also slowly becoming acclimatized to chatting with bots. That experience is offering a more intuitive way to get things done, and all signs indicate that this new way of interacting with computers is what people at large seem to prefer.

We have attempted to illustrate how will this transition work by walking the readers through the hands-on session on how to create their own bots. Once the first trial bot gets created, we realize that sky is the limit — there are so many useful things these bots can do, so let’s get cracking!

Update

I was invited by the RED Academy to deliver the talk on Conversational Commerce and the Bot ‘revolution’. The talk was recorded and can be viewed below:

Intrigued? Want to learn more about the bot revolution? Read more detailed explanations here:

How To Build A Stateful Bot
The Age of Self-Serve is Coming to an End
Only No Ux Is Good UX
Stop Building Lame Bots!
Four Types Of Bots
Is There A Downside To Conversational Interfaces?
Are Bots just a Fad? Are GUIs really Superior?
How to Design a Bot Protocol
Bots Are The Anti-Apps
How Much NLP Do Bots Need?
Screens Are For Consumption, Not For Interaction

In December, Slack announced a $80 million fund to invest in software projects that complement its technology. As an early adopter of the Slack API, here are some “bets” that I’ve made on the Slack platform:

A bot that plays all of Star Wars Despecialized Edition (Han shoots first!) one frame every ten seconds. It takes about 20 hours to get through the whole thing.

A bot that hosts games of The Resistance (optionally with the Assassin Module from the Hidden Agenda expansion). Secret voting is conducted via DM with the bot, while public actions are done in the channel.

A bot that lets you play Wolfenstein 3D by issuing commands (left, right, up, down, open, and fire). You can optionally specify how many degrees to turn left and right, but by default you turn 45-degrees. I’ve never successfully completed the first level, but I have managed to kill several guards.

I’m happy to announce that I’ve completed my latest bot, Vandelay Industries. Vandelay Industries is a shameless rip-off of Frinkiac that lets you search for animated gifs from every episode of Seinfeld in Slack. It has every line of dialogue ever spoken in Seinfeld.

If you’d like to try it out in your Slack team, just go to Vandelay Industries and click Add to Slack. It will ask you for permission to add a new slash command, /vandelay and once authorized, it should be ready to use immediately within Slack.

If you’re interested in the technical details of how it works, keep on reading! If not, you’ve managed to beat the estimated reading time for this article. Congratulations!

Processing

I initially started with 91G of all nine seasons of Seinfeld in surprisingly high quality 720p. I ultimately ended up with 111G worth of animated GIFs which tells you everything you need to know about the efficiency of that file format. This section is all about how I went from one to the other.

The files were in MKV containers, so I was able to use MKVToolNix to extract the subtitles from them. You can use mkvinfo to list the various segment tracks:

mkvinfo Seinfeld.S01E01.The.Seinfeld.Chronicles.mkv

It’s a little hard to read, but the track that we’re interested in is Track number 3, the first subtitles track. After noting the track ID (2), we can extract the subtitles into an SRT file like this:

mkvextract tracks Seinfeld.S01E01.The.Seinfeld.Chronicles.mkv 2:S01E01.srt

The SRT format is fairly straightforward. It contains a counter, start time, end time, and the subtitle text. Using a parser like subtitles-parser, we can easily iterate over the subtitles.

The next step is to loop through each subtitle and extract that time range from the MKV into an animated GIF. There’s an excellent article about using ffmpeg to encode high quality GIF but if you don’t want to read that right now, the trick is to extract a specialized palette from the section of the video that you’re interested in and then use that to encode the GIF.

Here’s a script that I adapted for the purposes of this processing step:

320 refers to how many pixels wide the resulting GIF will be. You’ll notice that instead of specifying a start time and an end time, I instead specify a duration. Although ffmpeg claims to support end times, no matter which version I tried I could not get it to properly extract the right range, so I ended up calculating the duration by subtracting the start time from the end time and abusing the unix epoch like this:

After applying the gifenc.sh script, we’re left with a nice animated GIF of the correct extracted range like this:

But I wanted to display the subtitle text at the bottom of the GIF and after digging through the ImageMagick documentation, I came up with this:

It’s not the most elegant solution, but it gets the job done. Our final gif looks like this:

Now just do that about 104,782 more times and you’re done. Running an entire episode through ffmpeg and ImageMagick took about 30 minutes on my top-of-the-line-in-2011 Macbook Pro. This is the part of the story where I’d like to tell you that I managed to leverage Amazon Elastic Transcoder or made a hadoop job to distribute the load to all the computers in my house, but really what I did was put all of this on my reconditioned budget OVH server and let it run for 5 days while I continued to live my life.

Once it was done encoding all the GIFs, I just let Apache serve them statically with a long Expires header and put Cloudflare in front of the whole domain. Only time will tell if that will actually hold up with traffic demands.

Searching

I installed Elasticsearch and indexed the contents of the SRT files. Here’s where I encountered some non-technical snags: In Season 6, episodes 14 and 15 are an hour-long clip show called Highlights of a Hundred where Jerry Seinfeld shows you a bunch of old clips from previous episodes. And in the final episode of Seinfeld, Season 9, Episode 23, they do a ton of flashbacks to previous episodes. Both of these would routinely get returned in the search results, so I just excluded them from the search query. There’s probably a better way to just lower the quality of those episode scores, but the documentation for doing so in Elasticsearch is about as easy to read as the above mentioned ImageMagick documentation. And at the end of the day, no one wants to see clips from either of those two episodes. Sorry, Larry David, the last episode was terrible.

Slash Command

The final step was just to wrap it all together with a Slack slash command, which is just a simple Express app that acts as a client to the Elasticsearch instance. There’s some OAuth to package the command as a Slack App and handle the Add to Slack button, but I don’t really need to check for authentication when the requests come through so I’m not saving the authorization tokens. The code for the server is available here: vandelayindustries-slack-server.

That’s it! I hope this technical writeup helps the next person that wants to extract GIFs from an entire television show for little to no actual reason.