My Tanda Hack Lyf
This guest post was written by Harris Jubb, a participant at the 2017 Tanda Hackathon.
The first hackathon I ever experienced was the Tanda Open Data Hackathon, in 2015, and since then the format of Tanda’s annual event has always been a refreshing change of pace to a full blown weekend spent writing code into early hours of the morning; having a recovery day really pays off before starting back up again on Monday.
The theme for Tanda’s 2017 Brisbane Hackathon was centred around their new webhook features, and having not worked a lot with webhooks I saw it as an opportunity to quickly skill up and work with some people I perhaps haven’t worked with before. Hackathons are a really great atmosphere to try something new that still has a business application in a fail-safe way, and more often than not, you learn a tremendous amount and share the experiences with some great people.
Coming into Friday night I really had no idea what kind of idea I’d work on, but after hearing a few pitches and talking with some other attendees I realised the clock-in webhooks had a huge utility (and were easily tested). I realised that whichever idea we came up, we could rely on these hooks and build almost any idea out of people clocking in and out of work.
Out of all the ideas, I tried to draw on the experiences I’d had in previous hackathons to figure out just how much we could get done in (now less than) 24 hours while also trying not to overwork ourselves by going 100% overnight and into the next day. After all, I was focused on enjoying the time and learning some new things, not burning out. We settled on an idea that we thought was easy enough, yet interesting enough for everyone on the team to have a good experience doing something new, enjoyable and most importantly achievable. The idea was pretty simple, using the clock-in webhook information as well as webhooks from the messaging platform, Slack, to be able to provide a better metric of “availability” when communicating within a business.
The Problem
When people communicate on Slack, potentially around the globe in the case of a remote team, they get an alert if the person they’re messaging is away or it’s outside of a regular business hours depending on their time zone. A great indicator based on some intuitive and basic metrics, however we thought we could do better. Talking to other developers, there was a common case where “available” doesn’t exactly mean that, someone could get mentioned or an automated message from a CI service or any other application in Slack and upon opening the Slack mobile application from push notification and be shown as “available”, able to respond to messages, but not get a chance to work on anything until they’re in the building next. That’s where Tanda’s clock-in webhooks came in; being able to know exactly when someone steps into the building, ready to work on something, meant we could queue messages / reminders for people to continue the conversation with someone at the right time. Simple enough idea to nail down the basics and go as far as we wanted to in the time we had.
The Solution
Being heavily driven by webhooks and outside services, we ended up requiring an implementation that didn’t need to run all the time. As the “frontend” consisted of messages being delivered to and through Slack, we didn’t need a dedicated instance serving HTML either. Because of this, and because the folks at Amazon helped us out with everything we’d need to get it all up and running for the weekend, we figured that an AWS Lambda application invoked through an API Gateway endpoint would be the best approach to take. We could generate a basic application to echo input while we figured out how the message formats were going to come in as, then decide how to tackle the communication between the two inputs to determine the appropriate output, which in our case was deciding whether to let the person trying to mention someone whether they were available according to tanda, and when they did clock in, to let anyone trying to reach them on Slack know they’d come back online.
Amazon’s Lambda product has the added benefit of having a JVM execution environment, so I thought this would be a good place to test out a serverless and 100% Kotlin implementation — the JVM language developed by JetBrains and now officially supported in Android. Writing Kotlin at a high level is basically shorthand Java code, with the added benefit that you skip a lot of the ceremony for basic data classes you would otherwise have to generate or just write out. The Serverless framework can get a Kotlin function deployed to Lambda in minutes with a couple of modifications to the Java / Gradle template they include in the project examples.
We set up three functions with API Gateway endpoints in the Serverless YAML config, all part of the same gradle project, as different classes implementing a RequestHandler with different inputs and outputs depending on the function they served. We had a service for setting up / linking your Tanda account with Slack through a simple slash command from our Slack bot, as well as two functions that would serve as the webhook endpoints both Slack and Tanda would call for new message and clock-in events respectively. Implementing these endpoints as potentially a single handler class could save resources / deployment cost but as we were playing multiplayer for the duration of Saturday there were less conflicts merging each other’s code before re-deploying to AWS. Between these handlers to deserialize and serialize the incoming messages, we used a shared object to provide a common API between the handlers that would deal with saving / retrieving various state between the calls.
We used DynamoDB for intermediate state, keeping a list of users who had mentioned someone if they were offline, and clearing that cache when the Tanda clock-in came in, messaging those stored users on slack. This allowed us to just create a table and set the access through the roles in the Serverless configuration, using Amazon’s Java SDK from Kotlin, usable without any additional setup. We still had to create the table through the AWS console, which could in theory have been baked into the shared code, but creating tables if they don’t exist programmatically takes up to a few minutes and for a weekend project we didn’t really see the point in the extra hassle.
Unfortunately there was an unforeseen bug in the handling code for clock-ins, coming down to not traversing the input properly to get a nested object inside the Tanda webhook object from the API Gateway object, which gave us a huge headache an hour before the presentations started meaning we were unable to test everything until right as we went up to pitch our idea, so no live demo. Right as we started talking we got a clock in triggering properly and everything was back on track, but none of the code that talked between the services was working or tested. Fortunately though the only problems were really that input bug so testing everything and making sure it was able to post properly was easy enough to get working after the weekend was over. We really wanted to make sure it all worked so we could share with everyone at Tanda and anyone interested in Kotlin & Serverless on AWS Lambda.
After 24 great hours of hacking with some great company the event had finally concluded, seeing some amazing pitches and ideas come to life was inspiring and educational and I think everyone got something out of it. As always the great folks at Tanda have continued to raise the bar for what could be the best hackathon in Brisbane and I’m looking forward to the next one!