September Hack Day

Androids, boids, and other things ending in oid. Also load balancers and graphs and fancy sales-qualifying algorithms

Autumn is rolling on, and the team has been busy breaking in our nice new office. Never fear, though, for we still managed to fit in a Hack Day in September. Here’s what we got up to.

Chat, but on Android!

Having recently taken over development of our iOS Chat SDK, Ben began to wonder how much effort it would take to build out a much requested Android SDK. Whilst we are not new to Android (try out our Inbox beta today!) there were a lot of unknowns to consider.

Setting out to hack together a bare-bones implementation of Chat for Android, by the end of the day he had a working implementation that could show chat, send and receive messages and keep inline with the host apps styling.

It’s definitely early days for our Android SDK but this Hackday work led us to put it firmly on our roadmap so stay tuned!

Fancy customer intelligence

Qualifying prospects and identifying who are set up to get the most value out of your product or service can arguably be one of the most important steps in your sales process. You always want to make sure you’re spending the right amount of time with the right customers, but getting to that point can usually be quite a time consuming process.

There will be common characteristics of businesses who are set up to take a lot of value from GoSquared but qualifying them can be manual and repetitive.

With any tasks involving those attributes, there’s usually a better way to go about doing it. As a SaaS platform set up to help online businesses operate better, there are commonalities we can infer from a prospect’s websites to see which are currently set up to take the most value from GoSquared. If we can identify things on a business website such as a user systems and other analytics platforms and customer communication tools, we can make a reasonable assumption that they’ll be able to see a lot of value of having all of those tools centralised in one place.

Russell built a qualification tool in Ruby that is able to parse a website and identify any of these commonalities. Then based on a set of rules, programmatically qualify the likelihood of them seeing value in a GoSquared demo. In those cases we’re able to proactively reach out to make sure they’re set up to take as much value out of their GoSquared trial as possible. As a tool it has helped us streamline our sales process and ensured that we’re spending our time as effectively as possible with our clients.

A language that isn’t JavaScript!

Leo’s hackday was spent learning and hacking around in Elm, a functional language for the browser that, among other benefits, offers a very compelling guarantee that no runtime errors are possible. Rather than write a webapp, however, Leo used the language to implement a version of the ‘boids’ flocking simulation. Boids explores the concept of emergence, common to many natural systems, whereby complex behaviour arises out of much simpler interactions between individuals. In simulating flock behaviour, each boid follows just three rules: it avoids collisions; steers itself to match the general heading of nearby boids; and tends towards the perceived centre of the flock.

If you’re already familiar with React and Redux, the architecture of Elm apps is very similar (and in fact inspired Redux): your program defines a model; a function for rendering the model to the browser window; and various actions that update the model in order to drive the app forward. This makes implementing boids in Elm relatively straightforward: our model is just a list of boids, each of which has a position and velocity; the view function draws each boid to a canvas in the browser window; and finally we define rules that are called on every animation frame to update the velocity (and position) of each boid.

Hopefully you’ll agree that the result bears at least a passing resemblance to a flock of birds.

Graph many of the things

Geoff built on a previous hack day (link to the last one where we did smart group metrics) where we built Time Series graphs to show how many people are in a Smart Group over time and visualised them on a dashboard. During that hack day we built everything as rough-and-ready code that ran only on Geoff’s local machine. In this hack day, Geoff put together a proper API that can be access via public net to load time series graph for any Smart Group. This allows our team to plot metrics for any group they’d like to analyse over time, which has proved useful for visualising our internal DAU/WAU/MAU metrics for GoSquared Live Chat which we announced last week.

ELB Party

JT set about switching some of our Elastic Load Balancers over to AWS’s new Application Load Balancers. These new load balancers from AWS give us slightly imrpoved performance over the older ones, along with built-in support for HTTP/2 and WebSockets.

All requests to the GoSquared site, our CDNs and our API are now served over HTTP/2 via these load balancers where the client supports it (most modern browsers). You may recently have noticed a slight speed-up in the loading time of data in the GoSquared dashboards and apps – this is thanks to HTTP/2’s improved support for parallel requests.

Notably, we haven’t switched over our main tracking infrastructure to the new load balancers yet – JT experimented with this, but we were seeing some performance issues, so for the time being all tracking requests are still served via HTTP/1.1. We’ll probably follow up with further details here on the Engineering Blog once we have got to the bottom of these issues, with an explanation of how we’ve made things work.

Never miss a post