Archive for the ‘RSE’ Category
This interview with the University of Nottingham’s Louise Brown is part of my series of interviews on the new cohort of EPSRC Research Software Engineering Fellows.
Could you tell us a little about yourself and how you became a Research Software Engineer?
I’ve had a peculiar career path. I’ve worked as a software engineer for 25 years. I did my PhD in Mechanical Engineering and then moved to a CS department where I worked for a company whilst based in the Drawing Recognition Research Group. I was working on CAD systems for industrial embroidery machines implementing algorithms for automatically converting image data into embroidery machine input data. I worked there for four years until my daughter was born after which I returned part time.
My daughter was ill when she was small and when my son was born 2 years later, I stopped work completely for 2 years. I then worked part time from home for 13 years, firstly on ‘Easy Cross’ software for design of home needlecrafts. I designed and developed add-on modules for different crafts including bobbin lace making, patchwork and knitwear design. My second job during that time was working on a system for automatic reading of travel documents such as passports and air tickets.
I moved to my current post six years ago which advertised for an open-source software co-ordinator. The job entails running the TexGen project, working as a software engineer but with a Research Fellow job title. After a while I started to become aware of the issues surrounding being employed as a researcher but spending most of the time programming. For me the main issue was the lack of career progression, being employed at the top of the Research Fellow scale but with little chance of promotion because there was limited chance of fulfilling the criteria for Senior Research Fellow. (The fellowship fixed this!).
To try and address this I started doing some teaching (MATLAB course for postgrads and first year undergrad drawing and design tutorials). I also joined committees to attempt to broaden my work profile. I am a co-author on a few papers but not enough for academic promotion, although there is more effort being made now to include me when a specific piece of development has been carried out which enables the work described in the paper. I applied for a promotion last year but was turned down, mainly due to lack of publications but also due to my not having done any PhD supervision..
One problem was that my performance reviewer did not know what to suggest in order to move my career forward. One possibility which I was encouraged to look at was fellowships but, having returned to academia relatively recently, I came into the category of ‘Early Career’ fellowships. These normally specify a time limit since completion of a PhD and the 25 years since I completed made these unsuitable. This fellowship was suitable because despite being labeled ‘Early Career’, it had no such time limits and it didn’t matter that I don’t fit the normal early career pigeon holes.
What do you think is the role of a Research Software Engineer? Is it different from a ‘normal’ researcher?
The fundamental difference is the fact that I do work which underpins research and without which the research wouldn’t happen but isn’t necessarily publishable in its own right. Without the work carried out by the Research Software Engineer the papers wouldn’t get published but they don’t necessarily get the credit. The research gets the publication and the credit!
I often end up spending time doing lots of odds and ends that are significant in that they support researchers and facilitate research but aren’t really quantifiable in the sense of a research output.
The outputs of a RSE are different to a ‘normal’ researcher. For example, in performance review, the work done on outputting software isn’t one of the KPIs. I don’t fit the normal ‘money-in, papers-out’ model of many academics.
You’ve recently won an EPSRC RSE Fellowship – congratulations! Can you give a brief overview of your project?
The project is centred around TexGen software. This is open source software for generating 3D geometric models of textiles and textile composites The initial part of the project will be to develop a new major version of the software aimed at addressing the modelling requirements of the increasingly complex textiles and preforms used in composite materials. The project will identify new and emerging areas in textile technology and develop tools to meet the analysis needs of these new technologies and materials.
The Faculty have committed to fund a PhD student and a project has been proposed to research optimisation of 3D woven preforms with various cross-sectional shapes.
Also included in the proposal are elements surrounding programming education and outreach. I currently teach a MATLAB course for postgraduate students which is intended to be a conversion from other languages. The reality is that many of the students haven’t programmed before so the course could be split to better meet the needs of the varying requirements of the students.
How long did it take you to write your Fellowship application?
It was horrendous! It was really hard work. The Business development team in the Faculty were really helpful, giving very useful advice on how to write a proposal. It consumed all of my time for the weeks between acceptance of the intent to submit and the submission date.
One thing that really helped was that two weeks before the submission date, the Graduate School held a ‘Writing retreat’ – 3 days for research staff to ‘just write’. There was space set aside, refreshments, speakers/courses if you wanted them and one-to-one appointments available with a careers advisor and EndNote specialist. The research development team people came down for a couple of meetings but there was a no phones rule and we were encouraged to turn our email off.
Having academics who were willing to spend time reading (and rereading!) the proposal was really important, especially as it was the first proposal that I’d written. The first draft was shredded by one of them but in a way that was very positive.
Who are your project partners?
I don’t have any named on the proposal. For the last couple of years I have been a platform fellow for EPSRC Centre for Innovative Manufacturing in Composites (CIMComp) which has a large number of project partners, funding research projects underpinned by TexGen. It is anticipated that this collaboration will continue. Part of the aim of the project is also to seek out new project partners, particularly for areas of textile research other than composites.
Tell me about your RSE group.
We don’t have one at Nottingham! It’s just me. There are plans to identify other RSEs in the faculty to start building a community. Watch this space.
Which programming languages and technologies do you regularly use?
TexGen is written in C++ and has Python wrappers. A bit of MATLAB for teaching. OS – Windows. I work in Visual Studio and am comfortable in it.
TexGen is cross platform so I have to make sure it builds in Linux. It also makes use of open source libraries such as wxWidgets, SWIG, OpenCASCADE and VTK.
I tend to work on a ‘need to know’ basis, looking for new technologies when there’s a specific need. When you are the only person in a project, you don’t have the luxury of learning lots of technologies.
Are there any languages/technologies that you used to use a lot but have now moved away from? Why?
I used to use C but rarely use it anymore. I also did assembler many years ago. When I was an undergrad, I did a software engineering course that used PDP-11 assembler. It was the first time that the lecturer had taught the course and was incomprehensible! I got the textbooks out of the library and worked my way through them, discovering how much I enjoyed assembler programming in the process. On the back of that the lecturer invited me to do a PhD where I designed and built a filament winding machine. The control system was run from a PC using 286 assembler.
Is there anything on your ‘to-learn’ list?
Getting better at the Linux side of things. I can get by but I am aware that there is much that I don’t know and could learn much better from someone who’s expert at using it rather than hunting around myself to work out how to do things. There are people who run TexGen on the HPC system so I would like to be able to support them better.
I’m looking forward to becoming part of the RSE community and learning from the other members.
Yesterday saw the biggest highlight in the technical calendar so far for me… Microsoft has brought the Linux command line to Windows.
Excited by the command line
OK, so I’ll admit it….improvements to command line tools seriously excite me! Windows 10 brought in a couple of minor improvements to the command line last year and I acted like it was a second birthday. Imagine then, the excitement I felt while watching Microsoft’s announcement of linux integration into Windows (Spin to 2:24 to see it). I could barely form sentences! When my wife came into the kitchen to see what the commotion was, all I could manage was “Bash! On Windows!….GIT! OMG! Not a VM! vi..sed..awk…gcc! OMG!’
So why so much excitement?
Shell scripts are more than mere automation, they are repositories of knowledge – they do some task for you and also explain how that task is done. They are wonderful things that can educate, take the drudgery out of a researcher’s life and lead to more reproducible research. The problem is that Linux and Mac users speak a different scripting language (Bash) to Windows users (Windows batch or more, recently, PowerShell).
In short, a script written on a Linux or Mac machine wouldn’t run on a Windows machine unless you jumped through some hoops.
Bash just became a cross-platform scripting solution
Various solutions for running Bash scripts on Windows have existed for a while. Cygwin, for example, compiles linux tools to run on Windows which works very effectively for many situations. Additionally, the Windows version of git comes with an emulated Bash mode that’s good enough to teach the scripting lesson from Software Carpentry. Neither of these solutions are perfect, however, and to me they’ve always felt like slightly awkward patches. The resulting binaries in projects such as Cygwin are necessarily different from those used in Linux Land.
This new collaboration between Canonical and Microsoft changes the game! Now, Linux tools appear like first-class citizens in the Windows world. When you run Bash on Windows, it will be the exact same Bash that’s run on Linux. An automated research analysis developed on a Linux machine will work exactly the same way on Windows.
The same skills apply, from tablet to supercomputer
Furthermore, when we teach introductory shell scripting to researchers we will be teaching them tools that allows them to work on all operating systems and all hardware types.
The same skills will apply to Mac, Linux and Windows from tablets to High Performance Computing clusters and that’s a wonderful thing.
Getting academic credit for impactful software
The topic of this year’s Software Sustainability Institute Collaborations Workshop is Software and Credit where luminaries from the Research Software Engineering world will get together and examine the problem of getting academic credit for the development of software. An example of the problem at hand is the story of Michael Double and BoneJ. Quoting from the SSI’s Software and Credit article:
Michael Double of the Royal Veterinary College, London (RVC) is the lead on the BoneJ project, his 2010 paper describing BoneJ is the mostly highly cited paper at the RVC gaining 2 new citations per week on average(!). However it was not deemed the right shape to submit to the UK Research Evaluation Framework committee by the RVC management even though they admitted it was highly impactful.
It’s a huge problem! Software is essential for modern research but developing it isn’t often recognised as a valid research output. If developers of highly impactful software such as BoneJ struggle, what hope is there for those of us who are rather lower in the research software food chain?
Embarrassing rash? The code doctor will see you now!
When I attend these annual collaboration workshops I find that my imposter syndrome, a feeling that’s always lurking under the surface of my psyche, starts to reach a kind of fever pitch. I feel like a country-bumpkin doctor who suddenly finds himself thrust into an advanced medical research conference. Surrounded by specialist developers of new drugs, surgical techniques and high-tech scanning machines, I’m just the guy who applies ointment to patient’s embarrassing rashes.
My path to Research Software Engineer has been via the IT support route where I’ve had many job titles throughout a career defined by restructure after painful restructure. Whatever my job title was, my role has always been the same — Researchers come to me with their code problems and I do my best to solve them (or convince them that they really want a different but equivalent problem solved).
These problems include things like:-
- My code is too slow! Like 10,000 times too slow. Can you help?
- My code sometimes explodes spectacularly, can you help? It’s 10,000 lines of VBA…..with some Fortran thrown in for luck.
- How do I get my code to run on the supercomputer? Why isn’t it faster when it’s finally on it? What’s Linux?
- Um…Our paper says the answer is 0.435 but the current version of our code, the one on Bob’s pendrive, says its 3.6 Billion. Can you help us reproduce our own results?
- How the hell do you do <insert task here> in <insert inappropriate technology here>
- People keep talking about code but all I’ve ever needed is this spreadsheet. How do I make my spreadsheet do <insert thing that REALLY needs to be done some other way>. I’m a Prof who’s best friends with your boss — your answer had better be spreadsheet-y!
- I can’t code, can you help?
- We’ve got code written in <old technology> but now we want it in <new technology>, can you help?
- We do our research in <insert expensively licensed software> and now need to run it 1000s of times simultaneously. This will cost more than the GDP of China. Can you help?
- Our research is based on this thing that’s a Fortran 77 kernel wrapped in MATLAB that’s been wrapped in Perl that we call from Python. It’s been in development for over 10 years and the computer it worked on has died. We are struggling to get it working on our new machine…can you help?
- We wrote some experimental code and it worked. REALLY well! We’ve now got lots of users and suggestions for improvements but have no process to deal with all of this. Can you help?
…and so it goes on. I work with researchers from almost every field of study and at every career stage — from Undergraduate project student through to professor and everything in between. The role is something like a mix of IT support, sysadmin, software developer, teacher, consultant, alpine guide and therapist.
It’s hard, dirty work and I love it!
Doing the job that’s put in front of you
Like many of my Research Software Engineer colleagues I have Opinions (capitalisation intended! They are strong but weakly held!) on the way things should ideally be done in research software development. These opinions have been formed from years of working in the trenches, observing the trouble people get themselves into and what’s required to get them out of it. They’ve also been informed by listening to the latest research on good practice from masters of the field.
Just as your local doctor might prescribe a healthy diet, exercise and cutting down on alcohol, I prescribe things such as version control, automation and making your code open. Despite knowing all of this advice, of course, many choose to ignore it for one reason or another and get themselves in a bit of a pickle.
One of the reasons I am so proud of the United Kingdom’s National Health Service is that no matter what you’ve done to yourself, no matter how rich or poor you are, no matter how much advice you’ve ignored, their fantastic doctors and nurses will fix you. Sure, they wish that the world was a better place and that people would take better care of themselves but, ultimately, they’ll do the job that’s put in front of them — not the one they wish they had!
I guess that when I do my job, I try to emulate this behaviour.
But where’s the impact?
You’ll not find my name on any research papers and I don’t have a big project such as BoneJ to stand behind. It is exceedingly difficult to demonstrate impact, in the accepted academic sense of the word, of roles like this but I am convinced that they are vital part of the research community.
One ‘solution’ would be to only offer my services to those who have already sipped from the Research Software Engineering Kool-Aid. Now that I have my RSE fellowship to stand behind, I could easily take this route and only focus on helping projects that smell a certain way…the right way. I could work on projects that have RSE time costed in from the beginning, using only the finest, freshest ingredients and released in ways that make it easy to demonstrate impact.
This route is very tempting! I could use only the technologies I love and work in an environment where my contributions were recognised at every level — funding bodies and promotion panels in particular. Thanks to the efforts of organisations such as the software sustainability institute, I believe that developers of quality projects such as BoneJ will eventually get the recognition they deserve. By focusing on such quality, high profile projects, my career would be assured!
To my mind, however, this is akin to the NHS only providing its services to rich, well-informed patients who take heed of all the good advice leaving the rest of us to suffer.
So…I’m probably not going to do that
The Accident and Emergency of Research Software Engineering
Over time, I have come to think of my particular style of work as the accident and emergency of Research Software Engineering. It’s usually unglamorous work with little hope of formal recognition and the threat of cuts (or being reassigned to printer support!) hangs over your head every day. As anyone who’s desperately needed their services at 3am can attest, however, an A+E department is exceedingly impactful!
Despite the success of the Research Software Engineering idea, I believe that the need for the A+E type of work will increase over time along along with the percentage of researchers who need to write at least a little code. This tweet from Southampton University’s Ian Hawke, quoting Software Carpentry’s Greg Wilson, summarises my thoughts on this matter perfectly.
Here we go with @gvwilson : the gulf between the computing scientific “elite” and those emailing spreadsheets is growing, and that’s bad.
— Ian Hawke (@IanHawke) November 10, 2015
This observation closely matches my own experiences from the front-line of RSE support. Part of the role of practitioners such as me is to help close that gap by raising the game of those who email spreadsheets. I feel that I’m making progress in this area although I often wish I had more staff!
Another part of the role is to figure out how to get credit and demonstrate impact for this kind of work or we’ll risk losing it in the next round of cuts. I’m struggling with that aspect to be honest!
If you feel that your work has elements of an Accident + Emergency Research Software Engineer in it, feel free to speak up in the comments.
A couple of weeks ago, a small group of us hit on the idea of running research programming tutorials in a cafe. The ‘plan’ was that we’d develop some self-paced programming tutorial material, take over a section of the main campus Cafe (Coffee Revolution) for a couple of hours in the evening and invite some researchers to come and learn something new for free.
For our first session, we chose to do a very gentle introduction to R. The students worked through the material, which started right at the beginning with installing R and RStudio, while a group of volunteer facilitators walked the room answering questions, solving problems and forming collaborations.
I can’t stress the importance of the facilitators enough! There is no chance that this format would have worked well without a group of skilled facilitators. On the day, I was joined by
- Research Software Engineer, David Jones
- PhD Student, Claire Green
- Post Doc, Will Furnass
I also had support of a few other people in the development stages. Thanks so much to all!
It was a lot of fun to do and student feedback has been fantastic! My favourite comment came from a medical doctor who said ‘I had no idea about computer programming and I don’t think I would be brave enough to try it on my own. Yesterday, I realised that R can be something useful and not really hard to learn.’
I find interactions like this to be hugely motivational!
There was a real buzz in the room, everyone seemed to learn something useful and I walked away from the evening with a couple of interesting follow-up collaborations in the bag. There were lots of calls for future sessions on topics ranging from more advanced R through to Python, MATLAB, Mathematica and High Performance Computing. The self-paced, flipped-classroom style of teaching was also a great hit!
So, that’s what went right. What about what went wrong?
Installation Problems
We deliberately allowed time for the installation of R in the session. Ensuring that the attendees had a working install of R and RStudio on their own kit was part of the point. Before the session, I did trial installs on Windows and Mac and everything went without a hitch. Other members of the team tried fresh installs on Linux.
“Installation’s going to be a doddle…no worries” I thought.
The very first attendee who called me over for help couldn’t get RStudio started on her Mac. It crapped out with an error message I’d never seen before. A bit of googling determined that it was because she had several old versions of R already installed and RStudio took exception to this.
We also had Linux users of various flavours and most of them had problems. A user of Arch Linux gave up on trying to install RStudio and used the command line instead. One linux user called me over after he started installing the ggplot2 package asking ‘This has been compiling for ages, is that normal?’ Fortunately, we were in a cafe so he could go get himself a brew while waiting.
Some people already had versions of R and RStudio installed from waaaaay back and so didn’t feel it necessary to upgrade to the latest versions. These people discovered that they couldn’t install packages because ‘foo isn’t available for R version whatever’.
It was all rather painful to be honest! We were in full technical-support mode…but at least people left the session with working, up to date versions R and R Studio….mostly!
Power!
There wen’t many power sockets. We didn’t think much about this in advance. Ball dropped!
For a feeble attempt at a defence I’ll mention that the battery on my laptop is superb and I spend hours working in the host cafe without worrying about power. Since I’ve been so spoiled, I’ve forgotten how important a mains socket is when your battery sucks.
Next Steps
This session was an experiment — something quickly spun up to see if it might work. I’m happy to report that it did!
Our main problem is that we’ve now created demand. Demand for repeats of this session for new audiences, demand for new material and demand for further consultancy. How fortunate for us at Sheffield that we have a newly created Research Software Engineering group to help meet this demand.
I sometimes give a talk on basic research software engineering called ‘Is your research correct?’ (slides here). Near the beginning of this talk I refer to what I’ve modestly named ‘Croucher’s Law’
CROUCHER’S LAW
I CAN BE AN IDIOT AND WILL MAKE MISTAKES.
Croucher’s law has a corollary:
YOU ARE NO DIFFERENT!
The idea is that once you accept this aspect of yourself, you can start to adopt working practices to mitigate against it. In the context of programming, it includes things such as automation, version control, adopting testing and so on.
For me, this isn’t just a law for programming — it’s a law that can be applied to every aspect of life. Unlike my parents, for example, I automate the payment of my bills by using direct debit because I know I’ll eventually forget to pay something otherwise.
The genesis of Croucher’s law demonstrate’s its truth. While sat in a talk given by Jos Martin of The Mathworks, he suddenly stopped and said ‘Mike. We need to talk about Croucher’s law!’ before moving to his next slide which had the title ‘Martin’s Law’. It was very similar to ‘mine’ and it turns out that I had seen his talk years before and had subconsciously ripped him off!
The fact that I had forgotten this demonstrates to me that Croucher’s law is the stronger result :)
Other relevant posts from WalkingRandomly
- On failure – I fail all the time…and that’s OK.
- Is your research software correct?
Programmer writes documentation like this
User reads documentation like this
The Engineering and Physical Sciences Research Council (EPSRC) is the UK’s main agency for funding research in engineering and the physical sciences. In May 2015, the EPSRC made a funding call for a new type of 5-year fellowship – A Research Software Engineering Fellowship which indicated their commitment to the national Research Software Engineering movement. I am very happy to announce that I am one of the 7 successful EPSRC Research Software Engineering fellows.
The title of my fellowship project is Building Capability and Support in Research Software. The project summary is below
“Software is the most prevalent of all the instruments used in modern science” [Goble 2014]. Scientific software is not just widely used [SSI 2014] but also widely developed. Yet much of it is developed by researchers who have little understanding of even the basics of modern software development with the knock-on effects to their productivity, and the reliability, readability and reproducibility of their software [Nature Biotechnology]. Many are long-tail researchers working in small groups – even Big Science operations like the SKA are operationally undertaken by individuals collectively.
Technological development in software is more like a cliff-face than a ladder – there are many routes to the top, to a solution. Further, the cliff face is dynamic – constantly and quickly changing as new technologies emerge and decline. Determining which technologies to deploy and how best to deploy them is in itself a specialist domain, with many features of traditional research.
Researchers need empowerment and training to give them confidence with the available equipment and the challenges they face. This role, akin to that of an Alpine guide, involves support, guidance, and load carrying. When optimally performed it results in a researcher who knows what challenges they can attack alone, and where they need appropriate support. Guides can help decide whether to exploit well-trodden paths or explore new possibilities as they navigate through this dynamic environment.
These guides are highly trained, technology-centric, research-aware individuals who have a curiosity driven nature dedicated to supporting researchers by forging a research software support career. Such Research Software Engineers (RSEs) guide researchers through the technological landscape and form a human interface between scientist and computer. A well-functioning RSE group will not just add to an organisation’s effectiveness, it will have a multiplicative effect since it will make every individual researcher more effective. It has the potential to improve the quality of research done across all University departments and faculties.
My work plan provides a bottom-up approach to providing RSE services that is distinctive from yet complements the top-down approach provided by the EPRSC-funded Software Sustainability Institute.
The outcomes of this fellowship will be:
1. Local and National RSE Capability: A RSE Group at Sheffield as a credible roadmap for others pump-priming a UK national research software capability; and a national Continuing Professional Development programme for RSEs.
2. Scalable software support methods: A scalable approach based on “nudging”, to providing research software support for scientific software efficiency, sustainability and reproducibility, with quality-guidelines for research software and for researchers on how best to incorporate research software engineering support within their grant proposals.
3. HPC for long-tail researchers: ‘HPC-software ramps’ and a pathway for standardised integration of HPC resources into Desktop Applications fit for modern scientific computing; a network of HPC-centric RSEs based around shared resources; and a portfolio of new research software courses developed with partners.
4. Communication and public understanding: A communication campaign to raise the profile of research software exploiting high profile social media and online resources, establishing an informal forum for research software debate.
References
[Goble 2014] Goble, C. “Better Software, Better Research”. IEEE Internet Computing 18(5): 4-8 (2014)
[SSI 2014] Hettrick, S. “It’s impossible to conduct research without software, say 7 out of 10 UK researchers” http://www.software.ac.uk/blog/2014-12-04-its-impossible-conduct-research-without- software-say-7-out-10-uk-researchers (2014)
[Nature Biotechnology 2015] Editorial “Rule rewrite aims to clean up scientific software”, Nature Biotechnology 520(7547) April 2015
John D Cook published a great article on automation recently. He discusses the commonly-held idea that the primary reason to automate things is to save time. As anyone who’s actually gone through this process will tell you, this strategy can often backfire and John points to a comic from the ever-wonderful xkcd that illustrates this perfectly.
John suggests that another reason to automate is to save mental energy rather than time and I completely agree! This is a great reason to automate. When you are under pressure to complete a task that has to be done right first time, being able to simply push the big red button and KNOW that it will work is worth a great deal.
Automation as knowledge storage and transfer
Another use of automation is as a way to store and transfer the knowledge of how to get things done.
I work with a huge array of technologies, spending a large part of my working day poring through manuals, documentation, textbooks and google searches figuring out how to do some task, foo. By the end of the project, I’ll be an expert at doing foo but I know that this expertise won’t last. I’ll soon be moving onto the next project, the next set of technologies and my hard-won knowledge will leak from my brain-cache as quickly as it was filled.
I often find that the fastest way to distill my knowledge of how to do something is to write a script that automates it. It’s often more concise and quicker to write than documentation and is usually useful to me and possibly others. It also serves as a great launching point for relearning the material if ever I revisit this particular set of technologies and tasks.
Automate to improve your processes
Having an automated script also allows others to easily reproduce what I have done. You want what I have? Run this thing and it’s yours. A favour from me to you!
Initially, this looks and feels like an act of pure altruism. I put in a large amount of hard work and someone else benefits. In my experience, however, payback always comes my way when those who use my work give me feedback on how to do it better.
The Sheffield Open Data Science Initiative
The University of Sheffield Open Data Science Initiative (ODSI) is really starting to take off. So what is it?
From the website, the aims of the ODSI are:
- Make new analysis methodologies available as widely and rapidly as possible with as few conditions on their use as possible (see the ML@SITraN group software pages and the local software page).
- Educate our commercial, scientific and medical partners in the use of these latest methodologies (see http://gpss.cc)
- Act to achieve a balance between data sharing for societal benefit and the right of an individual to own their data. (see our summary of our efforts in public understanding and debate)
My role within this initiative is to work on various aspects of research software throughout the University of Sheffield (and beyond!). I am a fellow of the Software Sustainability Institute and you could sum up everything I try to do with their motto Better Software, Better Research.
Join us on October 20th 2015
We have just started a programme of events which aims to bring together a wide variety of people interested in data, machine learning and research software (my favourite part!). The first such event is at The Data Hide on October 2015 at University of Sheffield.
There will be talk on Research Data Management for Computational Science by @ctjacobs_uk as well as lightning talks: What Kind of AI are we Creating? by @lawrennd, Machine Learning for Chemical Simulations by Chris Handley and a demonstration of how great Reveal.js is by me.
This will be followed by food, beer and an opportunity to chat and geek out.
We would be honoured if you would join us.
- Register for a free ticket (Only 40 places currently and they are ‘selling’ out fast!)
- Details of the October 20th event
Would you like to present at a future event?
Contact me to see what we can do together.
I was recently invited to give a talk at a Machine Learning in Personalised Medicine summer school in Manchester and decided to expand my blog post Is Your Research Software Correct? into a full 1 hour presentation.
I’m happy to say that it was extremely well received – both by many people at the event and by a few people on twitter.