Wednesday, May 18, 2016

Creating a Hubot friend and deploy from local to Slack

For a hackaton at my company this week, a couple of coworkers and myself decided to create some cool (and yes, useful) bots for the company's Slack channel.
However, I couldn't find one clear guide on how to do this and had to read basically half of the net, especially to make sense of how to do this without using Heroku - which is not completely free for our intended use.

So here is how I did it (on MacOS x), thought I'd share for the ones out there with the same problem.

1) Install nodejs, npm

So first of all we need nodejs. I have no idea about nodejs, so I used the installer. Npm should be installed automatically as well.
Then I updated npm with yeoman:

npm install -g yo generator-hubot

2) Create a folder for hubot
Then I made a folder for my new friend. He needs a home, after all. From that 'home' I created a basic Hubot setup, like this:

yo hubot --owner="OWNER <>" --name="BOT_NAME" --description="BOT_NAME" --adapter=slack

Please note: it should also be possible to omit these arguments and provide these settings when prompted, but for me it didn't work, as well as for many others, see here. So I used the above with parameters and it was fine. It should look something like this:

3) See if Hubot is alive

In your hubot's home folder, try


and type '[BOT_NAME] help' see the available commands if you wish to interact with your basic new friend already
- if you've had enough type ' /q'  to exit

4) Scripting!
Now the fun part.
I looked at the example script in the scripts folder.
If you have no idea what happens in this script, you may want to check this out first for some explanation.

After this I used SublimeText (which is by the way not too convenient out of the box when working with a new scripting language) to create a new .coffee file in the same folder as the example. Then I scripted a bot that will listen in on the chatroom, and provides the office address of the company I work for, as such:

# Description:
#   Give the office address
# Commands:
#   addressbot: address rotterdam - gives back the adres details

module.exports = (robot) ->
  robot.respond /address rotterdam/i, (msg) ->
    msg.send "The adres of the Rotterdam office is StreetyMcStreetFace 12, 1234XD Rotterdam"

5) Trying locally
I tried the script locally first by starting the bot as done above in step 3). It should respond when you type '[NAME_BOT] address rotterdam'.

6) Trying in Slack with the script locally
Now I wanted to try this in a real slack chatroom.
In Slack I went to Apps & Integrations and searched for Hubot.

I added a new configuration and copied the API key that Slack gave me.

Now in my terminal I started the bot like this:

HUBOT_SLACK_TOKEN=[yourtoken] ./bin/hubot -a slack

If all is well, it should work and be connected to you slack account. The addressbot entered my general channel and I could type '@addressbot address Rotterdam' to get the expected response from my dear new friend.

That's it actually, now all I still need to do is learn Coffeescript and write some more exciting bots ;)

Some of the many sources I used:

Wednesday, May 4, 2016

3 reasons I decided to learn about HTTP/2

You may or may not have heard about the approval of the new HTTP specification by the IETF in February of 2015. I have, and I would like to share what I found about HTTP/2.0 that piqued my curiosity.

1) Quick win webapp performance boost in no-time
There are already numerous small examples and tests on the web to show what HTTP/2 can do, out of the box. That is, if the client-side browser is HTTP/2 enabled and if the server supports the protocol.
Luckily the former mentioned is mostly all set and ready to go but server support is not quite there yet although growing steadily.
Have a look at the Gophertiles example. A less known but nonetheless spectaculair example is Cloudfare’s demo.

2) Security not optional
Yes, of course, clear text is, technically, still possible according to the HTTP/2 specification. The use of TLS is not mandatory. However the main players in the browser industry (Google, Microsoft, Mozilla Foundation) decided against allowing this and only enable HTTP/2 over secure connections. I am aware HTTPS has weaknesses of its own, but more eye for security in itself in this respect cannot hurt. Especially as more and more personal data is going over the wire and security breaches can bankrupt companies, hurt governments and citizens and kill potentially interesting applications. 

3) Server Push
On top of all this HTTP/2 throws a new functionality in the mix by the name of server push.
This enables the server to already send resources before the client even requested them. 

For this there is still a lot that needs to be figured out - but it is clear that this will not work out of the box and needs developers' attention. That, in addition to the promising future uses of this mechanism, made me want to find out more. A lot more. More about that later!