On Thursday 14th of August, the Imperial College London Research Software Engineering community hosted the third session of the “Research Software Conversation Series: Tools and techniques for modern research in different domains” titled "Research Software Documentation". This meetup explored the importance of documentation in research software, the challenges faced in writing it, and the best practices to follow.
Last Tuesday 17th of June, the Imperial College London Research Software Engineering community hosted a session of the “Research Software Conversation Series: Tools and techniques for modern research in different domains”. This event explored how research software is used for hardware control and automation, and specially the challenges and lessons learnt when doing so.
Several members of Imperial's central RSE team recently attended the Collaborations Workshop 2025 (CW25) online and in-person at the University of Stirling, UK. The Collaborations Workshop is the annual flagship event of the Software Sustainability Institute, which brings together delegates to explore best practices and the future of research software. The official theme for CW25 was “Future-proofing research software: evolving together as a diverse community”.
Alongside keynote talks, the event included lightning talks, workshops, and sessions dedicated to collective idea generation. The last day of the event was dedicated to a collaborative hacking session, where participants were encouraged to get together and work on software projects.
In this blog post, we share our experiences of attending CW25.
In this blog post we explain how you can acknowledge contributions from collaborators in
your software (or other version-controlled project) development with git via commit
messages. This is a great way to encourage and reward collaboration in your projects,
and acknowledge efforts that may otherwise go unnoticed.
We assume that you are already familiar with version control - in particular with git;
if this is not the case, feel free to check out our introductory course on using git
and GitHub.
A lot of modern research requires custom software to be written, either to do some calculations, analyse experimental data or something else. Creating good quality, sustainable software is always desirable, but ticking all the boxes that are often described as necessary to accomplish this can be a daunting task for people - researchers - who often have other priorities in mind.
Reproducibility is, however, not an optional feature of a piece of research - including software or otherwise - and that is something that researchers are fully responsible for addressing. Luckily, out of the many requirements of good quality and sustainable software, only a handful are necessary, or can go a long way, to support the reproducibility of the results.
In this post we describe these absolutely essential steps that researchers should take in order to support the reproducibility of their software. The recommendations in this blog post are for software developed using Python. It might not apply to all cases, and it is not fool proof as reproducibility is a really complex business, but it is a good start and will narrow the chances of things going wrong when other people try to use the software.
Writing your first full R package can feel overwhelming, but {fusen}
can help support at this stage (Even if you are an experienced developer, there is something for you too in this blog. Please read on!). "Fusen" is a type of
Japanese origami in which
a flat piece of paper, when folded in a specific way and inflated, turns
into a nice paper box/balloon. Similarly, the {fusen} package inflates a
flat .Rmd template (which is filled in a specific way) and returns a
nice package. In this blog post, I am sharing my experience of
exploring {fusen} for the first time.