Welcome to Pull Digital's technology blog Syntax*.

Pull Developers Voted Most Disruptive in 24 Hour Hackathon

A treat for your inner geek! We went to a Hackathon, where we came up with an idea for a product, fleshed it out and then built it. All in 24 hours! And managed to win! Our developer Christopher Little gives you the low down.

Last weekend I attended Collabhack, a 24-hour hackathon organised by Swiftkey and EF. I went with a friend, and we picked up another two non-technical teammates on the day. Hackathons are a kind of extreme programming competition. At the start of the event, a theme is revealed after which participants have 24 hours to come up with an idea; flesh it out with a potential business plan; and crucially design and build a product which fits within the theme. As the name suggests, the theme of Collabhack was "collaboration" - a theme with space for a lot of ideas.

We quickly came up with a few potential ideas. My first idea was to try to bring the collaborative spirit of Google Docs to the programming world. I loved the idea of being able to see what other people in your team are working on as soon as they make changes. Programmers are often very attached to their customised editors, however, so the tool would need to integrate directly within the editors. We decided, though, that there would be too many potential complications with conflicts - how do we resolve concurrent edits to a particular line, for example? Although I'm still convinced these complications do have solutions, I agreed that it was ambitious to find them within 24 hours.


Instead, my friend Tom pointed out a problem within the world of academia. When researchers write a new paper, they must pay a journal for the privilege of having their paper reviewed and published. These journals are then only accessible to other academics who have paid for a subscription to the journal. The review process is often flawed, in that a paper from a prominent scientist will almost always be published, while a lesser known author may be rejected simply because he is unknown, regardless of the content of his paper. Our proposed solution to this was to create an open online academic journal. Authors could freely publish their material, and the process of reviewing would be crowdsourced to the entire academic community, rather than simply seeking review from a handful of selected academics.

The idea seemed good, and so it was time to start writing code. From my background in the web world, I've picked up strong JavaScript knowledge, so I was keen to make the most of that. Additionally, I wanted to use the opportunity to explore and learn about Node.js (, and thus we decided to embrace JavaScript both on the client and the server. I began on the backend, and decided to use MySQL for data storage (again, due to my own familiarity with it). I knocked up a simple REST API for data access remarkably quickly using express.js ( for routing. Meanwhile Tom built a prototype frontend using the Jade templating engine. We settled on the name "Aperio", meaning "I open" in Latin, to convey the idea of opening access to academia.


When we took a break for dinner, I was confident that we were in good shape, but I was concerned that we only had two developers on our team, while most other teams were entirely comprised of people with technical skills. After dinner, the non-technical half of the team decided to leave us to it, as there was little that they could add to the project overnight.

As darkness grew around us, Tom and I continued with determination. We needed an interface for users to add responses to a paper, for which needed a login mechanism. It would have been easy to compromise on this for the sake of a demo, and simply build a fake login form - but I wanted to do things properly. Rather than write a custom login system, however, I decided to try to save time by using OAuth with Google user accounts. This part of development ended up taking the longest. I found a project called passportjs ( which seemed to promise abstraction from the underlying details of OAuth. I am certain it was my tiredness rather than the complexity of Passportjs, but it was well past midnight when I finally had a functional login feature.

In that time, Tom had built a lot of the webapp front-end, and things were looking good. Around us, most of the other teams had lost people to sleep, but we didn't have the luxury of a full team. Instead of sleeping, we decided to swap roles for a change of pace. I took over styling and front-end while Tom worked on the back-end user management. The fact that we were able to do this comfortably is a testimony to how useful an all-JavaScript environment is!

One feature we hadn't quite fully planned was rating. We envisioned the system to one day contain all academic papers and the surrounding discussion. For this system to be of any use at all, we needed an intelligent rating system so that only the most relevant content would be displayed. At the same time, we wanted the process of rating responses to be as straightforward as possible, to maximally encourage users to rate posts. At 4:00 AM, the two of us designed the model as best we could, though I'm confident a better model could still be introduced! We settled on a simple up/down voting system, to allow one-click rating of responses. To make this rating more meaningful, however, we made votes from higher-ranked users carry more weight than lowly-ranked users. It makes sense, for example, that an endorsement form Stephen Hawking should carry more weight than one from a random undergraduate student.

When the other half of our team returned in the morning, we were tired but proud of what we'd built. We'd integrated a live HTML5 editor for writing responses, including in-browser rendering of LaTeX for mathematical or detailed scientific responses. The rating system worked, and above all - the app looked great! All that remained was to present our project and hope the judges liked it. I had no idea what the other teams had put together overnight, so I was also looking forward to seeing what their ideas were. We were only given three minutes to put forward our ideas in front of a panel of executive judges. When our time came, we zipped through a demo of the system, proudly demonstrating that every part of our app was fully functional. A lot of the other teams had good ideas, and it was great fun to see what everyone had built.


When the judges announced the winners, we were delighted to hear our name called out as winners of the main "Most Disruptive Potential" category.


The Finished Project

Title Page


Profile Page


Discussion Page


Link to full project and live demo 

Some Of Our Clients

  • First-Central
  • Boux-Avenue
  • Conversis
  • John-Lewis
  • EY
  • Kompan
  • Living-Streets
  • Meteor
  • OSI
  • Schwarzkopf
  • GoCycle
  • SSTL
  • Chaucer-Direct
  • TurtleMat
  • UK200Group
  • ASDA
  • Vinci
  • Zoggs

We Deliver Marketing CertaintyTM

Find Out More