I'm going to briefly introduce the team, what we do working as RSEs, which is an acronym you see coming up a lot for research software engineers inside the library, and what we do to support the work of RSEs outside the library. So research computing at St Andrews, bit of history, it started over 10 years ago, I've asked around, tried to find an actual date and it's lost in the middle of time. The Arts and Humanities Computing Service, and it was really in research computing, and it widened all researchers in 2012. I joined the team in the summer of 2014, and then in 2015 we moved from where we had been with the IT services to the new digital research division of the library. So this is a small team, St Andrews is quite busy in lots of ways, but three are what we are officially application developers. But as a research software engineer it's growing in acceptance, it's a term to be used to describe those people whose contribution to research, whether it's an essential service or in an academic context, is the development of software, and we report to the senior librarian, Digital Humanities and Research Computing, and to the developers and analysis at the senior librarian. And just a bit of context in the digital research division, we have open access teams, research data management, research systems are primarily concerned with our pure instance, digital humanities service and the research computing team. So research computing supports research into principal ways. There's a development resource available to researchers across the university, and by supporting research engineering across the university, I'm going to talk about the first one first. As we start with we'll assist with funding applications, and this could be as simple as advising academics on the appropriate technologies they want to be using in their research project, and what they need to take into consideration working within the St Andrews IT context. Ideally what we really want is to be specifying software development to be carried out during the project and getting us costed into the funding applications. We also do a lot of work for unfunded projects, helping PhD students or pilot projects, but obviously funded work needs to take priority. Then we'll actually develop the development work to the most common kind of support provider, even if we're doing something more complex we'll simply provide a project website, we've got our own hosting platform. We generally use WordPress for that. This is a library conference of repositories, may have specific context, I'm using it in a rather general sense here. We have an instance of Islandora, which is a repository stack based on the Fedora repository software and the Trouble content management system. We use that as a back end for a number of web applications, both within the library and outside. The Image Database is a long-standing application that was developed in-house over 10 years ago, in which images are described using the Visual Resource Association metadata schema, and it's used a lot to support teaching and art history in particular, and again as the back end for a number of research project websites. Then we do the fun stuff, I guess. The custom applications, these are the technologies we use which happen to have colourful icons, which work on a slide. Typically the kind of stuff we do, and in principle we do almost anything, lots of databases, work with TEI indexing documents and generally the outputs are web applications. I'm going to run just some examples. We're working with Dr Ian Fife on the publication of the philosophical transactions. The philosophical transactions that are on society is the longest running still active scholarly publication. It's 350 years, it was 2012. We have a virtual registry of papers which got a lot of data from the Royal Society about all the articles ever published in the philosophical transactions of the Royal Society and the proceedings of the Royal Society, and they're all in this database. The research team are going through expanding on those with details of the publication process, dates articles were received, when they were read at the committees, the refereeing process, and then they're also putting in all the information which didn't in that initial set about papers which never made it to publication for whatever reason. As we set up this database for Alien Hunter team and we have developed the interfaces that the researchers are working with to input the data, and we've also done a bit of work to augment, to improve the data, so just recently I was grabbing stuff from virtual international authority files about gender information, about the various people in the database and sucking that in, which is interesting. We used to be sat upside the cataloging team in the library and chatting with them, but virtual international authority files there, there's certainly synergies there. And then the key fact generator is sort of what will be the initial public facing part of this, which is drawing on this data and pulling another economic data that the Royal Society has provided about the various costs and so on that involved in the publication of the journals and displaying that to users, pulling it together and synthesising it in a digestible form. So the Islamisation of Anatolia is another one, which is a, my colleague was working on this, and I can't claim to know a whole lot about the history of Anatolia, but apparently there is an extensive body of evidence about the Islamisation of Anatolia in the Middle Ages, which hasn't been studied, and we've built an index, a searchable index of this evidence, characterised in various ways, which can be searched. And Arab cultural semantics in transition, which is, again, the pivotal role of language consciousness in the history of Arab culture, I can just about begin to understand that sentence, that's what the description of the project is. But this interface here, you can select a root from the left-hand side, and you're shown the corresponding lamata, and you pick one of those, you see a sense, and then you can see that in context in the corpus of poetry, which is used to construct a database. And then you can click through the other words in the lines of the poem and so forth. This work has been a core function of the team since before moving to the library. This is what we're doing when we're in IT circles. But it's not difficult to think about it in the library terms. So we're enabling researchers to identify and address new questions. There's a significant research data management component to all this. And we're facilitating the collaboration and the dissemination of research. And I'm not a librarian. These sound like quite library things to me. The relationship with academics, I think there's something we've been striving for, even before moving to the library, but it has developed. There is more of a conversation, more working in partnership, with less simply the demand of the services when we were in IT services. And the other development work we're doing is for actually library applications for digital mandate service. And I'll run to these very quickly. The Digital Collections is using the Alangora platform to expose content from our Special Collections, stuff that's either unique to or particularly relevant to Synandru's. The Biographical Register holds details of Synandru's alumni, officers and graduates from 1747 to 1897, and has drawn from a number of sources in Special Collections. And we recently set up a transcription platform, actually, for when an interns come in and set it up quite quickly, to sell transcription material from Special Collections. And we're potentially looking at building on this for it as a crowdsourcing platform. That's what we do as developers. And then what do we do to support research engineering across, research software engineering across the university? And it's come from, we realised it's obvious, but nobody had really been thinking about it before, but we aren't the only RSEs at the university. Essentially, at least, there was no sense of who else was developing software for research, what kind of work they're doing, how they're doing it, and how well supported they are. There was very little, we knew even when we were in IT services, and we continued to work closely with IT services, that there aren't really central services geared towards helping developers across the university. So, I'm going to step outside just to think about it, because these aren't original questions, I'd say. Torsten mentioned the Software Sustainability Institute yesterday. Supporting, which supports UK's research software community, and Torsten mentioned, yes, it has 7 out of 10, I think is the figure in that post from Time Hedrick. 7 out of 10 researchers rely on software for their research. So, I mean, there are these external things going on supporting this work, and then spun out of that is the Research Software Engineers Association. So, if the software sustainability institute is about making sure that the software is as good as possible, the RSE association is about the people, and making sure that they're properly recognised for the work that they do. And then finally, I just mentioned software carpentry, which is, this has been around for coming up in 20 years, I guess out of North America in the first instance, but teaching researchers the computing skills that they need to get more done in less time and with less pain in their work. So, it's been around for nearly 20 years. So, these are not entirely new questions about new issues. So, what do we do? Well, we started by putting something up on our library blog, and standard is quite a small place. These are big numbers, these are not, for something on the library blog. I wrote the blog post and I won't claim too much credit, so that was, we did go out of our way to share it, make sure it got in front of people. So, we just used just to test the waters, get a sense that there were people interested in this sort of thing. So, we had 50 people coming back saying, yes, we do something like this. And we started mailing this at the moment, we got about 75 subscribers on that. And then in June of last year we had a launch event for what we were calling the research computing network, we had about 30 people there. And several issues raised, and the first one was the availability of appropriate version control systems, in order to try and avoid getting into too detailed a conversation about nature of version control systems. But they are quite crucial for making sure that software is being developed in the appropriate manner. And the lack of training, especially for, which respects PGRs and early career researchers. So then, as part of the just research data shared service pilot, which we're involved in as a research data management survey, conducted last summer and it was sent out to 2,000 research staff and students. And we have 300 responses covering every school. You're not going to be able to read that, but it's just to show those segments are all in the different schools at the university. So the big ones there are chemistry, biology and physics, medicine and mathematics, but we've got responses from every school that's in the university. And we managed to get a couple of questions about software tacked on to the end of it for our purposes. It's an intentionally broad question. Not quite as broad as, you know, do you rely on software for research, but are you actively involved with it? A lot of these people won't suspect that lots of people would not characterise themselves as software developers. They would be reluctant to think of themselves in those terms, but they do do work, which could be characterised like that. And 41% of the people who responded do this kind of stuff. I wouldn't claim that's representative of the total population. I mean, I mentioned the research computing willingness and the survey was promoted through that and so on. But regardless, there's certainly a significant number of people who are doing something, things which could broadly speaking be characterised as software development as part of their contribution to research. And the other question to be asked was about whether they use a code repository version control system. And it's as interesting as it is of itself to say to come up previously about the lack of availability of suitable systems, but it's also useful as a proxy for whether or not people are engaged in good practice in developing their software. Are they developing software in a sustainable manner, which would allow us to, which would allow people to, which would allow eventually the library to do the sort of things that Torstein was talking about yesterday about bringing in and preserving software for research reproducibility. And only 35 people said yes. That's only 28% of those 124 people who self-identified as software development, which we would like to be higher. So there are clear needs there. And we had a follow-up survey at the end of last year. And we can just mean this was more targeted and sent about 100 people from that period who set to give us permission in the previous survey that would follow-up them and also sent to the mailing list. We had 29 responses from that. I'm not going to go into too much detail on the results from that, but I will say in version control we established that github.com, which is a big free, a big commercial hosting platform for github repositories for managing software, is good enough for most people most of the time, particularly because anybody can have as many public repositories as they want on github, but if you're an academic, you can send off a request and for free you can have private repositories. So in that context, github becomes good enough for most people most of the time, but there are some requirements around access controls. If you've got something on github.com and you want to give access to a new member of staff and you do that manually, you can't tie it to the organisational structures at your institution, for example, through LDAP or any other mechanism. And also github, it's a commercial third party, it's a servicer in the United States. There are going to be cases, in the case of software it's more likely to be where there are commercial sensitivities rather than personal, but having those things on a third party server in the US is not necessarily going to be appropriate. So I'm working on a project proposal to get such a system in place and the procedures are such that may take a little bit of time, but I'm going to be working through that and I'm sure there'll be more requirements going as part of that. 45% of the respondents to our survey were self-taught or learned on the job with regard to software development or programming. And we had details of the software carpentry lessons and we had a lot of interest from the people who responded. So we've been working with K-Pod, our professional development service, and with Alex Knovlov, who is a fellow in computer science and he is a certified software carpentry instructor. If you want to call your workshop software carpentry, you need to have certified instructor of this. And we're going to be running two software carpentry workshops this semester. In fact, this time two weeks, I'll be helping out on the second day of the first one. And the plan then is to offer more of these on an ongoing basis. We haven't quite worked out the frequency on a basis, say, one a semester. And then we're developing, there's no central resources in these things, so we're developing guidance and good practice for RSEs. I think good practice rather than best practice in particular, because sometimes talking about best practice gets in the way of the good practice. But if the RSEs are engaging in good practice we can make our software better, which will make research more reproducible. It can allow you to demonstrate impact on sharing software. If you develop an R script in it, an R package that's made available on Cran or a Python script in it, a Python library that's made available on PiPi, there's a so-called DEPSI which you can get, which will mine papers for references to your software. And look at where that software is being used in other repositories in GitHub and allow you to demonstrate the impact this work you've done. And in the long-term, engaging in good practice should save effort. And we're just starting to develop this openly on GitHub, seeking contributions. It's mostly been me inviting stuff at the moment, but we're doing it openly and inviting others to contribute. So none of it, we weren't doing any of this before moving to the library. And there wasn't really an appetite for it before we came to the library. But it fits, to my mind, it fits in a continuum of open research support. So we've been moving from open access through research data management and then to research software engineering because you need the software. You can have your data well managed, well preserved, but if you don't have the software that was used to process that data, can you reproduce the experiment? And it also complements the support that was provided by the Digital Humanities Service within our division. So that's slightly over the 20 minutes. But that's what we do. We are research software engineers in the library working with academics to develop what they need and supporting RSEs across the university to develop their own solutions. Thank you.