Being relatively new to SCAPE and these “hackathons”, I wasn’t entirely sure what to expect. In theory, I could see the benefits of the group collectively sitting together, jointly discussing and working on project issues, but in practice I wasn’t sure exactly how it would work. How prescriptive would the agenda be (or need to be)? Would there be enough time? Would people actually sit working together, or just sit next to each other working? Would there be that frank exchanging of ideas and knowledge that would make the outcome a success and bring the team closer together with everyone having learnt something – who they can go to for help on Tika, who knows about image anaylsis, etc.? It seems however, that many members have had good experiences with similar events in the past, even expressing positive comments about them, so perhaps the theory might translate into practice…

After a brief overview of the meeting’s aims, the agenda called for an initial 1 minute lightening talk from every participant, giving great insight into who was in the room, what perspective they were approaching SCAPE from, and what they have been up to. This could just have easily been done over skype, but actually being in the same room helps (me, at least) associate thoughts, tasks, activities etc. with the people whose thoughts, tasks and activities they are. Moreover, it lets you build up a rapport, something that is vitally important with such a geographically distributed team, and something which can’t easily be achieved over the phone (but is useful to have when using the phone). It also provides a good starting point for “coffee machine” conversations, “You mentioned about such-and-such…“, which invariably helps you learn contextual information, gain invaluable advice, or start discussing problems and potential solutions – all of which are a lot harder to casually chance upon if you’re not collocated in the same physical place.

Next, we split into 4 smaller groups to work on potential demo ideas for the 1st year review, mixing “techies” and “non-techies” alike. After some discussion time and group feedback, the developers split off into groups to work on creating these, with a view to having something demonstatable by day 3. I helped work on a demo to visualise mime-type counts of web-archive content generated from Markus Raditsch’s Taverna workflow, in particular creating a gnuplot script to generate a PDF barchart. The next morning, Per Møldrup-Dalum came with the idea to replace gnuplot with a (much more impressive) browser based bar chart, so as to avoid the necessary installation of gnuplot  (and cygwin on windows). He suggested using JavaScript InfoVis Toolkit (JIT), a library I have previously used to visualise data and so I was able to quickly demonstrate how I had linked my program’s data output to the HTML visualisation (JSON object in an included javascript file) and we had an end-to-end solution. Not bad for day 2.

Whilst this demo could have been created by a single developer on their own (and large parts of some demos were, for example, Markus’ Taverna workflow), it was the collaborative, collocated nature of the development that made it happen quicker.  More people looking at the same problem presents more viewpoints on potential solutions; Per saw the drawback of gnuplot and suggested an alternative, a library which I had previously used to similar effect and could quickly describe a workable approach. Furthermore, having learnt this approach it was easy to find other people at the event who were looking for similar solutions to their own problems, for example Carl Wilson, who wanted to show comparative outputs from Jpylyzer and other tools.

By working closely with others and drawing on their skills and experience, time and effort can be saved by not “reinventing the wheel”. This translates to code recycling, as much as it does from knowledge re-use. Erica Yang, for example, also participated in our development group and was interested in visualising data relating to various experiments using different scientific instruments. It seemed a close fit to what we had done so far, so we made a start by taking the original gnuplot script and adapting it for Erica’s data, with some initial results just before close of day 3. There’s still more work to be done though, and it is at this time, I think, where the benefits of these collaborative events really show their worth, but also when they will be tested; can the teams continue to work together, building upon this great start, to deliver great results? I’m sure we can, but it’s up to everyone to keep collaborating.