The Incredibles: A graduate final demo

From left: me, Laila, Matt, Dom and Viren

Hi! My name is Linh and I am an ASOS graduate with less than two months left on the programme. I joined in September 2017 and for the first four months we were given the chance to learn ‘all the things’, before joining the established teams at ASOS.

I meant things.

I spent my first three weeks at ASOS in ‘bootcamp’, preparing for the graduate project. This involved various sessions across multiple teams to introduce us to software engineering at ASOS. These were: agile methodologies, the cloud, system architecture, learning C# and JavaScript, to name a few.

The graduate project brief

Our project task was to make a mini full stack ASOS website (a demo is further down the post), using .NET Framework (C#) for the back-end, and SQL database, and React.js on the front-end. We used Microsoft Azure for our deployment, and Visual Studio Team Services (VSTS) for continous integration. As the project timeline was limited to 11 weeks, we worked in one-week sprints to increase iteration. By accelerating the pace of our work, we sped up both the learning process and scrum ceremony experiences.

Why the graduate project?

You might wonder why we did this rather than join ASOS teams immediately after the initial bootcamp. ASOS wanted to enable us to work on a product from start to finish, in an agile way and to receive quick feedback. This also allowed us to ask other engineers questions when we got stuck, and thus get to know a lot of people at ASOS. The project also helped us to learn and experiment with ASOS technology before joining actual teams.

Our team name

We were required to come up with a team name, and decided on ‘The Incredibles’. It so happened that we had two females and three males on our team, so we matched the characters featured in the movie. Here’s who is who:

• Matt — Bob aka Dad
• Laila — Helen aka Mum
• Linh — Violet aka the daughter
• Viren — Dash aka the 10-year-old son
• Dom — Jack-Jack aka the infant son

We also felt that the name was positive and encouraged us to get through the tough times.

My attempt at Photoshop. Can you guess who’s who? Original photo credit: Pixar/Press.

Requirements

We were given functional and technical requirements to deliver this project.

Functional requirements:

Basic all products page

• A minimum of five products should be shown on the page
• Each product should have a name, image and a link to a product details page

Product details page

The following information about the product must be shown to the user:

• Product name
• Product description
• Product brand
• List of materials used in the product
• Brand description
• Variants of the product i.e. size and colour
• Price of the product — the price is the same for all variants
• If the product has been discounted, the original and discounted prices must both be displayed
• The user should be able to select a specific variant i.e. their preferred size or colour
• Multiple images of the product, which the user can view
• When the user selects their preferred colour, if there are different images that represent this specific colour, these must be displayed
• If the variants of a product are in stock or not
• The user must be able to add the product to their bag. Only a valid variant with stock can be added to their bag

Bag page

• Display the items in the user’s bag on a simple bag page
• The simple bag page has no design and no user features
• Store the details of the user’s bag, making it available during their visit to the website
• When an item is added to the bag, the stock level for that item is reduced by one
• Items in a bag are automatically removed one hour after they have been added, if the user has not already checked out
• When an item has been removed from the bag, the stock level for that item is increased by one

Site furniture/architecture

Each page should show a common header and footer.

The header must contain:

• Logo
• Link to show a list of all products
• Link to the bag page

The footer must contain:

• A copyright statement
• The name of the team that built the application

Technical requirements:

Unit tests

We were required to write code in a Test-Driven Development (TDD) way as much as possible. This helps to keep the code clean and reduce any bugs that can creep up along the way. We used a Jest testing framework to test our JavaScript and Enzyme to test our React components. We decided to use Jest for its wide API, meaning it didn’t require us to install any additional plugins/libraries. We chose Enzyme because it made it easier to assert and manipulate our React components. NUnit was used for the back-end because it allowed us to write tests without the concern of setting them up.

End-to-end tests

We used Selenium to cover end-to-end test scenarios. We also used SpecFlow to test our acceptance criteria. Both of these tools allowed us to complete browser-automated testing.

Code quality

To make sure our code was of the best quality, we used ESLint and StyleCop for the front-end and back-end, respectively.

Continuous Integration (CI)

We have set up a CI pipeline to automatically build and test our code when we push to master branch. We used Visual Studio Team Services (VSTS) because it’s also where our code lived, so it was convenient to use a technology that is already integrated with it.

Continuous Delivery (CD)

We set up a CD pipeline so that, when we pushed up to master, everything was released up to the pre-production environment. There was also a manual switch to deploy it to production. We used Visual Studio Team Services (VSTS) to set up our CD pipeline for the same reason as we did above.

Source control

We had to choose between git flow or git trunk for the development. After speaking to several engineers at ASOS, we chose git trunk as this was the easiest to use, allowed us to integrate our changes and get feedback more quickly. Having worked with git flow, I also found it to be fiddly.

Libraries

For the back-end we used .NET framework with ASP.NET Web API. On the front-end we used React. ASOS is using these at the moment, so it was beneficial for us to become familiar with them in preparation for joining ASOS teams.

Build

We set up a coherent build toolchain using Webpack and Babel. We decided to write our JavaScript code in ES6 since most browsers support this now. As there are still some browsers that do not, we had to use Babel to compile our code to ES5. We used Webpack to bundle and package our code. Not only did we need to bundle our code, but also our static assets such as CSS, images and fonts. Webpack allowed us to use require() on local static assets (non-JavaScript files). Babel also helped to transpile our React code (JSX) into JavaScript. On the back-end we used NuGet as this is standard for .NET applications.

Code review

We set up our merge to master to be via pull request, with at least two people reviewing the code. This ensured that our code was the best quality it could be, and anything that could be improved would be noted in the comments. This is also the way ASOS handles pull requests.

Browser support

The front-end had to be properly optimised for mobile, tablet and desktop devices, including iOS 11 on iPhone 6, 7 or 8, Chrome on Android (device as per availability), Chrome, Firefox, Edge (latest versions only) and Internet Explorer 11. To do this, we used the Google Chrome emulator and various devices that we had to hand.

Back-end monitoring

We used Microsoft Azure Application Insights to set up a monitoring dashboard for the back-end. Everything we were deploying was out from Azure, so it was easy for us to use their other services. This was also useful to set up logging, including error details for our back-end processes.

Front-end monitoring

We used New Relic for front-end monitoring. We set this up to show all AJAX requests, page response times and visits per minute, to name a few. New Relic is quite flexible and can show various data, which is why we decided to use it.

System architecture

Overview of our project system architecture.

We decided to go with a microservice architecture to separate our APIs for product, stock and bag. There were several reasons for this:

• ASOS has a microservices ecosystem, so it was beneficial for us to build our product this way to understand how it works
• In the case that one service fails, it will not affect other services. Consider this to a monolith architecture where if one part fails, everything fails!
• The ease of deployment. It can have a separate build for each API
• To replicate the ASOS ecosystem and learn why it uses a microservices ecosystem
• It’s easily scalable — it allows you to scale each service independently

Importance of the Cloud

Setting up servers in Microsoft Azure was quicker than if we were required to do this in-house, which allowed us to concentrate more time on building our product.

The cherry on the cake — demo! 🎉 🎊

Here is the walk-through of our mini ASOS website :)

Team Incredibles’ Desktop Demo

Team Incredibles’ Mobile Demo

Retrospectives and key takeaways

Thanks to the project, we are fully fledged Software Engineers at ASOS, going from no C# experience to gaining some and becoming more comfortable with Visual Studio, learning front-end testing etc.

One thing that we did differently compared to the other groups was to use SQL for our database instead of NoSQL. The main reason for this was because we did not know how to set this up in Microsoft Azure, and since we were quite familiar with SQL, it was an easier option for us. This proved to be difficult to manage down the line because we weren’t exactly sure of the data structure at the outset. Having to change it frequently, the NoSQL option would probably have been better as there is less setup associated with NoSQL.

Working in an agile way was also new to some of us, but we quickly saw the value in it. We received quick feedback and knew exactly what we needed to do. Breaking down big tasks into smaller ones made work more attainable.

Biggest challenges

1. TDD — this was extremely difficult at the beginning because we didn’t know how to write tests and we also needed to learn the testing framework
2. Meetings — took up alot of our time, which left us with less time to code. These were important to make sure we knew what we were doing, as well as an opportunity to discuss how we should go about building our features
3. Sprint planning — as we were new to the nature of the work, our story estimates were very vague and we over-committed. We had a lot of stories rolled over to the next sprint (mainly because we didn’t anticipate how long proper testing would take!)

Biggest learnings

1. Technical skills — we’ve definitely gained a lot of technical skills. Some of us were doing back-end but came from a front-end background and vice versa, so this project has boosted our skills in the other!
2. Maintaining code quality — everyone has their own way of coding but adhering to style guides helped to keep our code consistent and we learned the value in having them
3. Software development principles — DRY (don’t repeat yourself) was one of the principles we lived by and has become an integral part of our coding
4. Importance of sharing knowledge — at times we had silos being created, so we always tried making pairing a priority. We also employed the concept of ‘mobbing’ where we sat down together to work on a problem, and micro-learning sessions, which involved one member of the team presenting something they had learned or solved back to the rest of the team. This helped everyone to stay on the same page

From left: Dom, Viren, Laila, Matt and me.

We all learned so much throughout this project and we’re all very grateful for the help we have received from various people at ASOS.

Special thanks to AJ, James Norton, Matt Turner and my manager Arjun for proofreading!

Linh is a graduate Software Engineer at ASOS. When not coding at work, she codes at home or at meetups (coding is her hobby). She also likes fat cats.