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 <owner@example.com>" --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

./bin/hubot

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:

https://hubot.github.com/docs/
http://cloudmark.github.io/Hubot/
https://github.com/slackhq/hubot-slack

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!

Luminis DevCon 2016

Tuesday I was honored with the opportunity to visit a software conference called DevCon in Cinemec, Ede (Netherlands). Even though I was only able to attend the afternoon session, I am glad I made the trip.  

Lonely painter
Having never been I was impressed by the size of the venue. For a minute I stood frozen and had no idea where to turn or look. After I decorated my blouse with the name sticker I received at the wardrobe, I finally made my way up one of the main stairs and found an artist in the process of painting. At first I assumed that I'd picked the wrong entrance. However, after having a closer look, I noticed long strings of zeros and ones in the margin of the canvas. Now that piqued my interest.
Not far from that situation I observed a quite serious coffee machine. The person hiding behind it knew what he was doing: within not too long one of the best double espresso's I'd ever had was in my hands. He reassured me that I've come to the right place.

Please, please, please

Printing 'Hello World' in INTERCAL

With an elevated caffeine score, I found myself a good spot for the next keynote speaker: Mark Rendle. His talk was about the history of the relatively young programming discipline and was crammed with British buffoonery. Mark explained how he would't be surprised if Kenneth E. Iverson's kids were called A-boy and A-girl. After all he invented APL - A Programming Language. 'He'd probably already used up all of his creativity by the time he got to Harvard'.

Additionally I never knew about the mere existence of so-called 'joke programming languages'. They are quite brilliant and solely reading the documentation is entertaining.  For example INTERCAL (http://www.muppetlabs.com/~breadbox/intercal-man/), for which the user somehow has to guess the right amount of times (determined by nebulous logic) to mention 'PLEASE' when instructing the compiler.


Help!
After the light-hearted keynote got me settled in, I was ready for a bit more substance. I chose to visit a session about Big Data by Richard Berendsen, amusingly called 'Help! They dumped a dataset on our doorstep'. I could have never imagined how much calculation is needed to prepare a dataset in order to even vaguely consider it prediction-material. Richard explained al these calculations step by step through Jupyter Notebook. I was impressed.

Soon after it was time for refreshments. Spread out before me was the full product line of Mars Incorporated, save for the pet food. When I thought nobody was looking I may have sort of stuffed my face just a tiny bit. Because I might've been a little hungry, just maybe.

Don't make the DBA cry
Anyway, I was more than ready for the final session about the evolution of software (architecture) by Xander Uiterlinden and Hans Gringhuis. The first part of the session dealt with complexity versus maintainability and how to control this as early in the lifespan of the software as possible. Then the audience's attention was turned to data, also an important part of software I heard... I love data and databases and I found it very inspiring to hear about the view that it is better to focus on events rather than simply mutating the one (up to date) copy we have of a relational database. Because data migration is just a recipe for making the DBA cry, when he or she finds out about the destruction caused in the wake of a migration script that was presumed to be tested so very thoroughly months ago.


After this it was time for a drink and an update of the traffic situation around Utrecht. Luckily there were no problems on my route.

I cannot wait till the sessions are uploaded so I can catch up with the talks I've missed.

Cinemec Ede, aerial view during the DevCon 2016