When I started here at Unacast on Monday I got thrown at the deep end right away.

Could you please write a blog post about some interesting tech stuff by Thursday? — Romet Kallas

Approach #1: Apple Wallet aka. Passbook

I found out that a really simple and straight forward way to interact with iBeacons is via the Wallet app (formerly know as Passbook) in iOS.

A card in Wallet can be associated with one or several iBeacons via it’s UUID (and optionally the major and minor values for better precision). My contrived use case for this was that we could make Wallet based business cards for our selves that we could send to/share with potential business partners. When they later come to visit us at the Unacastle something like this would happen:

The white cube you see in the GIFs is an iBeacon with a on/off switch that I use to simulate that I'm entering the office and get in range of our welcome message beacon.


The Google Chrome notification center scheme

An alternative to Apple’s iBeacon standard is the new kid on the block; Google’s Eddystone. Contrary to iBeacons which only broadcast a data packet identifying the beacon with an UUID, the Eddystone specification supports URL and telemetry packets as well. The iOS version of Google Chrome has some limited support for interacting with so called Physical Web objects broadcasting Eddystone-URLs, and a (somewhat useless) example of a Unacastle greeting using this approach could look something like this:


These notifications doesn’t trigger a notification of any kind, so it wouldn’t be much of a greeting.

Behind door number 3

Last but not least, we have the full-fledged native app way of doing things. If you develop a native iOS app, you’re in full control of the beacon interaction (both iBeacons and Eddystone), and you could trigger notifications or modals to get the users attention when the encounter a beacon of interest. For my greeting experiment I chose to implement a mock Unacast employee app that would gives us small motivational quotes when we get in to the office in the morning. I used Facebook’s React Native with iBeacon support to make this rather crude example (skipping notifications or modals for simplicity)


Wrapping up

Out of the three techniques I’ve described in this post I would only consider the native app one to be usable for my Unacastle greeting use case. That’s the only way I could give the user a real notification, not just a silent card on the lock screen (or worse, in the notification center). But if Chrome or Opera takes their Eddystone-URL support a bit further and ads notification possibilities of some kind, it would be an easy and wide-reaching alternative to native apps. These are examples of the kind of interactions that Unacast helps integrate into the digital world.

The Unacast tech team has invested heavily in ChatOps, this post gives an overview over our deployment system and the advantages it gives us both in a short, and longer term.



ChatOps is a term often credited to GitHub, and it is all about putting the tools in the middle of the conversations. At Unacast most of our conversations go through Slack, and when we integrated ChatOps into our workflow we got the tools closer to the conversation.

So, what is ChatOps? For us it is the the action of triggering stuff from Slack instead of pressing buttons on a dashboard or runing shell scripts from the command-line. It is your monitoring tool posting alerts to chat instead of sending you an email. It is about deployment, monitoring and operation in the context of a conversation. It also democratises the deployment process, so the Product Owners can do the actual deployment to production.

Kjartan deploys

Why are we doing ChatOps, and why should you?

You all know the case when something critical breaks. The “go-to” guy fires up the SSH-console and enters a selection of different commands to fix the issue. Unless you actually go and SSH into the box and hit the arrow keys to replay the sequence of commands, this critical knowledge will be lost until next time the excrements hit the air-moving device. Which in this case, probably will be the next time the application is deployed.

If we were to place ourself in this situation it would be a huge liability for us as a young tech company. We just cannot afford that the knowledge about our systems resides in the brain of only one developer.

This is why ChatOps is huge for us. By showing everyone else what you are doing, through the chat, you are at the same time spreading the knowledge on how to deploy and run the different applications.

This is especially important to us, who are now hiring our next 10 developers. This means that from the day they log in to our Slack will see what everyone else is doing, and most importantly: How they are doing it.

heim deploys

From deploying an app to production, to splitting traffic between versions and to cancel processing jobs, everything is documented in real-time as it happens.

Our development process

We are using a version of GitHub Flow for our development process. That means all new features goes in a branch, a pull request is opened and we merge continuously from master into the feature branch. When we have something that is ready to deploy to a server we trigger a deploy of the branch to a test environment. When the new feature is verified it is deployed to production, verified again, and then merged back into master. This enables us to maintain a clean master branch so we can roll back in case something fails.

Our deployment mechanism consists of a few discrete parts: Hubot, GitHub Deployments API, Heaven, and CircleCI.

This is how it works:

  • Someone tells our Hubot to deploy something to some environment
  • Hubot creates a new deployment in the GitHub Deployments API
  • The affected repo triggers a webhook with the deployment-information and sends it to Heaven
  • Heaven triggers a parameterized build on CircleCI
  • CircleCI handles the actual deployment

This setup is very powerful and we can use it to deploy any type of application on any cloud provider. It also enables us to limit deployment to our system from individual accounts to prevent someone from deploying something by mistake.

How do I start?

It may be daunting to try to chew over too much at once, so our general advice is to start small and build from there. The thing that brought us immediate value was bringing in deployments and health checks, and we are currently working on bringing creation of ephemeral environments into our flow.

There is literally hundreds of plugins to Hubot, so you should be able to find something that will suit your needs. If not, it offers flexible scripting through CoffeScript so to integrate with an existing API you only need some time and elbow grease.