*The Part one of this series, was appeared on the RSE blog.

Code written for research, and particularly in an academic context can (by my own admission…) often be a mess of comments, temporary sections, and poorly-named variables that only runs correctly whilst the researcher who made it is still around. This, despite the fact that most code-writing researchers know exactly the sins we are commiting at the time. But reproducibility is one of the central tenets of science - so why in our coding have researchers been prepared to cobble together barely working assemblages of script that can often lead to unmaintainable projects?

In modern research (do the 70s count as modern?) computing is an essential tool - perhaps even more so than the humble lab book - so how can we improve our situation and, moreover, what’s in it for us? Code is written in research for a huge variety of tasks, from instrument control to simulations to simple plotting scripts; where does best practice really apply?

In this blog post, I’ll plant the seed of what this approach really entails and what effect it can have on research, inspiring readers to dive more deeply into the topics discussed and forming a foundation for future blogs here.

The weekend saw November 3 pass, and gives me an opportunity to claim that Unix is 50 years old and hence to write this blog post.

48 years ago, on November 3, the 1st edition of the Unix Programmer’s Manual was published.

But Unix itself had been around a little longer, starting in the Computing Science Research Center of AT&T Bell Laboratories in 1969. We lack a definitive date for that, so let us celebrate 50 years of Unix, and 48 years of its manual.

I worked in commercial I.T. for a few years before doing an PhD and spending many years in scientific research. Coming back to software full time is a bit like coming out of cryo-stasis: Technology has moved on in ways I could not possibly have imagined and I must adapt like some kind of sci-fi person. One of the big changes over the last few years has been the increased use of virtual machines (e.g. using Virtualbox) and containers (Docker is a popular choice, Singularity may confer advantages in High Performance Computing (HPC)). I now feel ready to talk about this with others.

A huge amount of research code has been written in Matlab (Matrix laboratory), a paid-for product from Mathworks, and the Research Software Engineering (RSE) team here at the University of Sheffield have recently had a few enquires about either getting some of this code to work with Python or to translate it into Python altogether. I’m going to talk a bit here about the motivation for this and the technical strategies that we’re thinking about using. To be clear up-front, this is not a Matlab vs. Python tech-off. It mostly applies equally to if one were doing this the other way round.

*This blog post first appeared on the OpenACC blog.

Conference Summary

Research Software Engineering (RSE) Sheffield, the Sheffield Bioinformatics Core and the Sheffield R User Group are organising a series in of hackathons during October as part of Hacktoberfest 2019, a global initiative to encourage participation in open-source software projects. Hacktoberfest is all about encouraging meaningful contributions to the open-source ecosystem and Hacktoberfest meetups are for beginners and veterans alike!

We recently hired two more Research Software Engineers (RSEs) (including Bob Turner, who started last week) but are already looking for another teammate!

The RSE team has a recurring interest in learning Python: Because we take on new staff and we want to train them, because we want to enhance the skills of our existing staff, because we deliver training courses, and because we are often asked for our advice on how others should learn Python.