Devoxx Voting, A retrospective

02 December 2015

Written by Jon Mort

Devoxx

Over the last 10 years or so a group of Adaptavist engineers have attended Devoxx BE regularly. Dan Hardiker is a member of the steering committee, one of the founding members of Devoxx UK and heavily involved in Devoxx4Kids along with many other Adaptavist employees (including myself). Often we have been involved in providing support in running the conference, from helping with moving tables to creating interactive screens outside session rooms that can be interacted with using a Kinect gesture tracker. This year was no exception as we provided an API to record votes for sessions and a UI to view the top talks.

Why Voting?

Organising an event as large as Devoxx BE (over 3500 attendees) takes some serious planning and feedback from people attending sessions is vital to ensuring the success of the event and future events. Speakers are also interested in feedback on how their talk went and what people want to hear about. A star rating, as coarse as it is, is a useful data point for determining the popularity of sessions and topics, and can be used to establish trends.

In previous years voting has been performed by presenting RFID badges at readers on the way out of rooms which sometimes caused queues on the way out and prevented those that were staying in the room from voting as they would have to leave and re-enter in order to record a vote. This year Stephan Janssen, who runs Devoxx BE and oversees the Devoxx family, wanted to experiment with voting from the schedule apps available on iOS, Android and Windows Phone devices.

As it happens Dan and Mark Hazel, who organises Devoxx UK and co-founded Voxxed, had wanted to do something similar for Devoxx UK which a few Adaptavist Engineers had worked on...

Vote API

The vote API was conceived over a few conference calls and a decision was made to write a microservice in Go. The service needed to:

  • Accept Votes
  • Display the top talks
    • Overall
    • By Day
    • By Track
    • By Type
  • Cope with the conference load

Session and speaker information needed to be fetched from the CFP REST service and returned to the UI. The UI needed to:

  • Display the top talks
  • Refresh regularly
  • Cope with network failures (conference wifi)

Some Stats

Voting:

Vote Stat Value
Valid Votes 13,337
Mean Vote 3.9
Median Vote 4
Mode Vote 5

Performance:

Performance Stat Value (as measured by reverse proxy)
Total Requests 1,701,003
Peak Load per Hour 40,246
Peak Load per Minute 839
Peak Load per Second 103
Mean response time 8ms
Median response time 8ms
Maximum response time 152ms

So how did it go?

Go is a very interesting language that has lots of opinions. Some parts of the language feel quite modern whilst others are like stepping back in time. I was particularly happy with the ease with which the application could be deployed (we used Heroku for hosting but it was easy to run dev environments and in a Docker container). Performance was also impressive. The app was able to cope with a peak of 600 requests per minute on a single node using only 7MB of RAM (as reported by Heroku's monitoring), with a median response time of 8ms and a 95th percentile of 50ms.

I'll summarise quickly my experience with go:

Things I like about go

  • Dev Speed and tools
    • Compiler is fast
    • Code formatter - all go code looks the same
  • Concurrency
  • Speed with which other picked up the code
  • Multiple return values
  • Consistency. Code looks like same (as long as go fmt is used) in pretty much every repository
  • Inheritance model feels well thought out
  • Lots of libraries

Things I don't like

  • Dependency Management - this is a disaster
    • godeps helps, but URIs to git repositories is not really sufficient for stable dependency management
  • Tabs for indentation (flame war)
  • The Type System - or lack there of. interface{} === Object in Java
  • Error handling
    • How do I determine if I can handle an Error?
    • Stacktrace is elusive, which makes debugging and root cause analysis difficult
    • Error handling code often gets in the way of logic
    • Convention says no value returned when an Error is not nil
    • Note I am not arguing for try/catch blocks everywhere

Would I use go again?

I'm undecided right now. It feels like a good language for a mass participation open source project due to the consistency and the low barrier to entry. I would also use it on a project that required deployment to constrained systems, both in terms of resources or ability to install dependencies. Go's deployment is highly elegant. Would I write the vote API in Go again? probably not. One reason is that it was an opportunity to learn and I'd go for another new language or library next time out.

blog comments powered by Disqus