STFC Sandwich Student Placement Software Engineer for ISIS Business Applications

Transcription

1 STFC Sandwich Student Placement Software Engineer for ISIS Business Applications Matthew Williams

2 Intro... 2 The Business Applications Team... 2 Technologies Used... 2 The Role... 4 Conclusion

3 Intro Undertaking an industrial placement as part of any degree can be a daunting prospect for many reasons, like not knowing if anything you have learnt so far will have any relevance in the workplace or if you will be given any tasks that are worth taking a year out for which is extremely relevant for a computer science degree as you may run the risk of losing some of your coding skills if you spend a year not writing much code. However, with the right placement, it can provide an incredibly invaluable experience and set you in very good stead for finishing you degree and securing a job after you have graduated. Having finished my placement year with STFC as a software engineer in the ISIS Business Applications team I will aim to provide a student s perspective on what you can begin to expect from a year in industry with STFC. The Business Applications Team There are a variety of Software Engineering placements available with STFC covering a range of departments, including those in teams which focus on analysing experimental data, to ones in teams responsible for systems that support a community of over 3000 scientists worldwide. The Business Applications team falls under the later as part of STFC s ISIS department. ISIS is a worldleading centre for research at the Rutherford Appleton Laboratory (RAL) near Oxford. Research covers subjects ranging from clean energy and the environment, pharmaceuticals and health care, through to nanotechnology and materials engineering, catalysis and polymers and on to fundamental studies of materials. The team develops, maintains and provides support for a suite of software applications that are used by both externally and in-house. These systems include, but are by no means limited to, a proposals system that scientists can use to submit applications for time at the facilities on the RAL site, a scheduling system to schedule the hundreds of experiments that are carried out each year and a visits system used by scientists to book accommodation, flights, taxis, etc. once their experiment has been scheduled. These systems are vital in underpinning the science at RAL by enabling the thousands of visiting scientists to make the most of their experiment time and helping staff operate an efficient and effective facility and research programme in a reliable, safe and cost effective manner. Technologies Used The majority of the systems developed by the Business Applications team are multi-layered interactive web applications. The fundamental architecture of many of these systems is a database layer utilising Oracle Database connecting to a Java EE business logic layer via the JPA (Java Persistence API) which is then exposed as a SOAP web service and finally consumed by an ASP.NET C# Web Forms application which the end user then interacts with. This basic outline only starts to name a very small selection of technologies and tools that the team uses on a day-to-day basis. At each layer there are a number of tools and supporting technologies required to aid development and pull everything together in order to provide a reliable service. 2

4 A lot of the database layer is managed by another department on site, but the team is still responsible for the structure and content of those databases, so SQL Developer is a key program used to search and manipulate them. Having this responsibility for the databases, being able to see the structure and having to frequently write considerably complex SQL queries has dramatically improved my database knowledge and SQL skills. One of the biggest curiosities heading into industrial development was how similar the Java I had been writing during my first two years of my degree would be to what I would be writing while on placement. As it turned out, apart from features of Java EE that are not in Java SE, it was comfortably similar, all of the basic design patterns and concepts that were taught at university were being used. This is possibly one of the most reassuring aspects of undertaking a placement year you can see how the skills and technologies you are learning through your degree will applicable once you take on a job after graduation. The predominant IDE for Java development in the team is NetBeans, which I did not personally have any previous experience with, but again, it eases the transition if you are using tools that are widely available rather than those which are specific to industry. One area of development that I had not had much exposure to at all while at university was testing, which in industry is a vital stage of the development life cycle. The team heavily tests the Java web service through both unit and integration tests. By developing a large system, rather than a small piece of code for an assignment, it is much easier to see the importance and benefits of a thorough testing suite. For unit tests the team makes use of the widely used JUnit alongside JMockit, which is a tool used to mock parts of code that you do not want to test e.g. mocking a call to a method that is not in the class that you are testing. The technology I was most unfamiliar with that the team uses was Glassfish. Glassfish is an application server that the team uses to deploy the Java package to in order to expose it as a SOAP web service. I had not had any exposure to Glassfish at university, so this was yet another new technology I could take back with me from this year. The team s chosen version control software is SVN, which we manage through TortoiseSVN. Our SVN repository is also hooked into a Jenkins Continuous Integration (CI) server. Jenkins (and CI in general) is something that I would never have come across at university, but I could not now imagine developing in any professional team that does not make use of any form of CI. On the front-end side of things there is a much smaller set of technologies that the team uses. At the core is an ASP.NET Web Forms with C# web application that consumes the SOAP web service. This alone what not be enough to create the user experience that the team desires from the application, so we also use a considerable amount of CSS and JavaScript, including external libraries such as Bootstrap and JQuery. Through my experience at university and talking to other computer scientists at other universities, most focus on using Java and very few touch on ASP.NET, so this was a completely new technology to me. My web development skills left a lot to be desired when I first started, but over the course of the year I have become much more competent and have a much better understanding of a lot of core web development concepts. Front-end functionality is much harder and more time consuming than back-end testing and as we are only a small team we cannot commit a large amount of time to continually performing front-end acceptance testing. Fortunately a member of the team developed a Java framework, making use of an API called Selenium that allows Browser Level Automated Acceptance Tests to be written. The Selenium replicates a web browser and provides an API let allows you to manipulate the DOM 3

5 through Java, so once we have first written the test we can run it every time we make a change to the front-end to ensure no core functionality stops working. When developing small projects at university it can sometimes seem unnecessary and excessive to create detailed designs, but after having worked on much larger scale systems it is much easier to see their value. The team frequently held design meetings where we discussed mock-ups of front-end pages that had been created using balsamiq and occasionally produced UML diagrams when implementing a particularly complex new feature. The Role Although I was recruited as a placement student, as even the job title suggests, I wasn t labelled or treated as one. Of course the first few weeks were spent getting up to speed on the new technologies through a variety of tutorials and learning about all the systems the team is responsible for. After this, however, I was quickly working on code that would go into production, even if they were mainly minor alteration at first. As both my skills and understanding of the team s responsibilities developed I was viewed as just another member of the team and was given the same amount of responsibility as the rest of the team. This was fairly intimidating at first but ultimately meant that I got to develop vital features that had to be in place before the system could be replaced and that will be present when the system goes into production. Below are some screenshots of features that I got the chance to work on both jointly with other team members and by myself: Filter control on main scheduler page. Page for accepting or declining booked equipment 4

6 As it is a small team the exposure to new technologies is vast. When I first started the team required more front-end developers, so at first I was mainly developing with ASP.NET but as the needs of the team changed and more work was needed on the back-end, I switched to Java development. The rest of the year followed a similar manner, switching between front and back-end and developing both skill sets in the process. Another consequence, or benefit, of being in a small team is that everyone in the team is responsible for all stages of the development life cycle. There are not enough team members or separate teams to allow for some to focus just on development, others on testing and another on deployment, the team is responsible for all of it. Therefore I had the chance to be a part of and lead requirements capture meetings, produce both UML class designs and front-end screen mock-ups, implement the designs, test the code I had written, deploying the code and then maintaining and supporting the final systems. One of the other large responsibilities of the team is providing user support for the systems we develop. As providing support can sometimes be disruptive to development, one member of the team each week is designated as the Supporter of The Week (SoTW) and they handle all support queries. For our external systems this involves monitoring a shared inbox where queries get sent to and responding to any issues that come in. Our biggest customer is another team on site who use our systems to manage visiting scientists and as some of their issues can be vital to solve they can call a shared phone in the office that the SoTW will answer. Conclusion When I started my placement with STFC I could not have dreamed about being put in a better, more approachable and easy-going team. It was an incredibly supportive environment and has undoubtedly allowed me to learn as much as I have throughout this year. The incredibly wide variety of technologies I was exposed to across all stages of the development life cycle has given me a real insight into what professional software development is like and reassured me that what I am doing at university is what I want to do and that it will set me in good stead for when I graduate. I cannot be thankful enough for the amount of responsibility I was given as a placement student as although it was a trial by fire at first, the effect it has had on both my development as a person and software development has been profound. The decision to undertake a placement year, especially with STFC, has been one of the best decisions of my life. 5