On December 7 and 8, we organized our first ever cBioPortal Hackathon. For those unfamiliar with cBioPortal, it’s a web-based platform for analyzing and visualizing large-scale cancer genomic data sets. Earlier this year, cBioPortal went fully open source, and we now have a cross-institutional team from DFCI, MSKCC, Princess Margaret Cancer Centre, and The Hyve working on the continued development of the portal.
The Hackathon was hosted at DFCI in Boston. All told, they were 15 of us, broken out into four teams.
Pieter Lukasse from The Hyve and Adam Abeshouse from MSKCC presenting performance improvements to the cBioPortal.
Team 1: Data Validation and Importing. Tasked with improving the validation and loading of new data sets into the cBioPortal. Succeeded in extending the existing validator, adding an HTML report option, and made good progress to an overall single script for validating / importing new data sets.
Team 2: Performance. Tasked with identifying performance bottlenecks in the current code, and working their way through these bottlenecks. Succeeded in identifying and fixing a number of front-end performance bottlenecks.
**Team 3: Virtual Cohort Front-End. ** Tasked with building a new “virtual cohort” feature for selecting samples across multiple cancer studies or across multiple cancer types. Succeeded in defining RFC 16, and building first prototype of functionality.
Team 4: Web API and Scalable Data Store. Tasked with building the next generation of the web API for cBioPortal, and scaling to accommodate the expected rapid future growth of data sets. Succeeded in building a first version of cBioEngine, a new MongoDB backed web API.
I think we learned a lot from our first hackathon. I share these for others contemplating hackathons of their own.
Keep the teams small: we capped all our teams at 3-4 people. We reasoned that small teams could make real progress.
**Pre-Hackathon meetings: ** we tried to defined the teams and priorities ahead of time. Each team was also tasked with meeting 2-3 times before the actual hackathon, so they could hit the ground running.
One big room: On the first day, we were split out into four separate team rooms. This seemed to prevent informal communication between the teams. On the second day, we therefore moved to one large conference room. The energy and buzz definitely went up.
Shared results at the end: we reserved the last 1.5 hours of the hackathon for each team to report back and show code. This was definitely the highlight.
I think the hackathon was a huge success, and we are planning our next one in late February, to be hosted by MSKCC.