ICT role in 21st century education and its challenges
The journey from ActionScript to TypeScript
1. The Journey from ActionScript
to TypeScript
By Dan Gwynne
dan@gwynne.co.uk
https://uk.linkedin.com/in/dangwynne
V 1.1
2. bet365, first, some numbers
£34 billion annual turnover
£60 million annual IT budget
1.5 million markets on site
600,000 concurrent users
600 IT employees
18 Languages
15 Data centres
6 Flash UI Devs
3. Flash, the end is near…
• 2005 - Introduced In-Play to the site using Flash ActionScript 2
• 2011 - Full Flash desktop site using ActionScript 3
• 2016 - Continues to be industry leading website
4. JavaScript
• In 2013 we started to look for alternatives to Flash…
• JavaScript was the only choice
5. • 1000’s of lines of code in one file
• Hard to govern the coding pattern
• ES6 (ECMAScript6, ES2015)
• Types
The problems with JavaScript
10. No time to wait around
• Mobile In-Play needed to be completed by the end of 2013
• In-Play was written in JavaScript with strict coding standards
• Deadline was achieved
11. • Was TypeScript still right for us
• What problems would we be solving by migrating
• Difficult to maintain large codebase
• Missing the features of strongly typed languages
• How would we approach converting 40,000+ lines of JavaScript?
• Carefully
• Code had good structure – one class per file
• Namespacing
• In-line comments
18 months later, decision time…
12. How did we do it?
• We’re a team of coders!
• Successfully converted 85% of the JavaScript automatically
• Conversion rate was around 6,000 lines per day
13. Did it work?
• Not only did it work it made the product better
• Compared output to focus our test efforts
• Manual QA team found zero bugs
• 10 days to convert, fix, test, update build tools and deploy to production
14. • Increase in quality
• Faster development time
• Happier developers
Was it worth it?
15. • Platform independent development environment
• Quality through tooling – linting, unit tests, Selenium, test harness
• Gaming product has adopted TypeScript
• TypeScript 2.0 – check out TypeScript roadmap on github.com
• Sportsbook rewrite
• Replace Flash Desktop site
• Rewrite remaining Mobile site
• Rewrite benefits developers as well as customers…
What next?
16. • TypeScript
• Guarantees quality
• Saves time
• Creates happy developers
• Assists us to react quickly to change
• Helps us maintain our market leading position
To conclude…
17. The Journey from ActionScript
to TypeScript
By Dan Gwynne
dan@gwynne.co.uk
https://uk.linkedin.com/in/dangwynne
Editor's Notes
Introduce myself as tech lead at bet365 currently working on the rewrite of the desktop sportsbook site. 8 years experience as a senior Flash developer before joining bet365 in 2010.
34 billion - The amount wagered on sports per year and still growing
60 million - Our annual IT budget
1.5 million - Markets on site
600,000 - Concurrent users on a saturday afternoon
650 - Employees in our IT arm
18 - Languages supported natively from stoke
15 - Data centres in 7 countries all bet365 managed
6 - Flash developers required to maintain the front end...
We have always had a strong relationship with Flash, it has powered our in-play apps since conception and powered our whole desktop site since 2011. It has helped make us the market leader by being able to react quickly to change.
In 2013 we started looking at moving over the front-end architecture of the site from Flash to a more future proof JavaScript solution. We needed to make sure the development environment was the same if not better than the robust environment we were used to on the Flash site. Microsofts Visual Studio was familiar to our ASP.Net developers and provided powerful IntelliSense that our Flash developers were accustomed to.
1000’s of lines of code in one file - We often end up with large files which are hard to read, review and merge.
Hard to govern the coding pattern - We can tell developers to follow our patterns, we can pick issues up in code reviews but it would be much better if a language enforced a pattern.
ES6 - The new ECMAScript 6 language definition is just round the corner so using ES5 could be creating legacy
Types - Javascript is a dynamically typed language which makes it easy to make mistakes as all types are inferred at run-time. E.g.
function sum(numberOne, numberTwo) {
return numberOne + numberTwo;
}
console.log(sum(10 + 10)); // returns 20
console.log(sum(“10” + “10”)); //returns “1010”
This can be problematic for a betting site where ensuring numeric calculations are always accurate.
ES6 - Adds structure to the code with Modules and Classes and includes new features such as Maps and Promises.
CoffeeScript - A more verbose way to write JavaScript
Dart - At the time this was a big gamble as Dart set out to replace JavaScript
TypeScript…
TypeScript is a strict superset of JavaScript, this means that we write our code in TypeScript and it compiles into JavaScript which can be run on all browsers.
At the time of review TypeScript was still in beta, it had the following major features:
Strict typing - Show updated sum function now with types
Classes - Allows us to split out our code into multiple files, easier to manage and maintain
Modules - Allows us to group our classes
Accessors - Functions & variables defined as private cannot be accessed outside of the class, this helps reduce spider web code
Type Definitions - Allows you to use 3rd party libraries with strict typing and accessors
JavaScript - Native JavaScript can be used within the TypeScript files, allows you to move codebase over slowly if required
Microsoft - As it was created by Microsoft we knew there would be some smart people working on it
function sum(numberOne:number, numberTwo:number):number {
return numberOne + numberTwo;
}
console.log(sum(10 + 10)); // returns 20
console.log(sum(“10” + “10”)); //This doesn’t even compile, the editor displays an error at dev time
Our mobile InPlay product was ready for an overhaul, it was retrieving odds on a 10 second poll which was inefficient and much slower than our desktop site which was receiving odds using our push systems. We also noticed that our desktop site was much easier to maintain than the mobile site and the quality of work delivered into QA was better. Our new aim was to not only create a better looking product but create a product which would be easier to maintain and be of a higher quality.
A small group of senior devs lead by our principal dev put together a document outlining the advantages, strategy and considerations for moving our mobile InPlay section over to TypeScript. We went to visit our CTO with this document to get his seal of approval, “This look very promising” he told us, “but it is still in beta, let's take a another look when they reach version 1.0”. He was right, using beta software on a site of our scale was too much of a risk. The TypeScript compiler could introduce bugs into our code which we would have to try to identify before that code got to production.
We still needed a new InPlay product and unfortunately it would not be written in TypeScript… yet. We had a plan. We knew the coding patterns the TypeScript compiler outputted, if we could base our coding standards around these patterns then i would make it easier for us to convert our codebase in the future. We wrote the product in JavaScript and it went live in 2013.
Around 18 months after the mobile site went live we decided to re-evaluate our TypeScript proposal as TypeScript was now at version 1.4. There were a number of factors to consider:
Was TypeScript still right for us? - Yes, it had great backing from Microsoft and it had become open source which greatly increased its rate of change and stability.
What problems would we be solving by migrating? - Our codebase was now fairly large and we were starting to miss some of the features strongly typed languages such as ActionScript and .Net gave us.
How would we approach converting 40,000+ lines of JavaScript? - We has followed a pretty strict set of coding standards, one class per file, name spacing, in-line documentation using vsdoc comments.
We’re a team of coders! When we have a problem we plan then we code. We wrote a program in a few days that would convert our existing JavaScript to TypeScript and obviously the program was written in… TypeScript.
The program successfully converted around 85% of the code, the rest we converted by hand fixing any bugs the TypeScript compiler found along the way! Our code conversion rate was around 6000 lines per day.
Not only did it work it made the product better by finding simple bugs that would have been hard to find by a developer. As our JavaScript coding style was so similar to the TypeScript compiled code we were able to compare the output of the compiler to our current codebase and focus our test efforts on any areas that had differences. When we sent it over to our manual QA team they found no bugs. In total it took 10 days to convert, fix, test, update build tools and deploy to production.
Yes.
Increase in quality - Less time required in QA, less bugs found in uat & live.
Faster development time - The code structure makes it easier to plan and execute solutions.
Happier developers - Flash devs have a new pathway in their careers, Java & C# developers find the transition easy. Having well structured code makes the coe enjoyable to work with.
Platform independent development environment - We have moved the development environment away from Visual Studio and MSBuild which only run on Windows. We are now running a custom build system using gulp and node which allows our developers to use their favourite operating system and whatever code editor they like, this really helps new starters to hit the ground running.
Quality through tooling - The tooling we have for developers is priceless in helping to guarantee quality. We have linting to help ensure our coding structure and standards are being followed. Unit tests are run on both local and CI builds to ensure previous work remains stable. We have created a test harness which allows individual components to be developed independently of the rest of the site. Selenium tests are run regularly to ensure there are no unexpected visual changes in between each build.
Casino product has adopted TypeScript - Due to the success of the mobile InPlay product a recent rewrite of the casino site has been written in TypeScript.
TypeScript 2.0 - The language is constantly evolving providing, we are staying on the upgrade path to make sure the developers get all the benefits of new releases as early as possible. Check out their github page to see the roadmap.
Sportsbook rewrite - All I have talked about so far has paved the way for us to rewrite our desktop Flash site to TypeScript. We are about half way through this project and it’s going really well, we have a great team who are passionate about the technologies they are working with and the product they are creating. We expect the product to have a shelf life of around 5 years so it’s important to get things right first time and we believe TypeScript is playing a key role in helping us achieve this.
We will also soon be starting a rewrite of the mobile site to make it 100% TypeScript leaving no trace of raw JavaScript in our codebase.
The re-writes introduce new and improved functionality and fresh design but the improvements below the surface are just as important as they benefit our whole development team. TypeScript has and will continue to guarantee quality in our products which saves time, makes a happy development team and helps us to react quickly to change and maintain our position as the market leader.
Platform independent development environment - We have moved the development environment away from Visual Studio and MSBuild which only run on Windows. We are now running a custom build system using gulp and node which allows our developers to use their favourite operating system and whatever code editor they like, this really helps new starters to hit the ground running.
Quality through tooling - The tooling we have for developers is priceless in helping to guarantee quality. We have linting to help ensure our coding structure and standards are being followed. Unit tests are run on both local and CI builds to ensure previous work remains stable. We have created a test harness which allows individual components to be developed independently of the rest of the site. Selenium tests are run regularly to ensure there are no unexpected visual changes in between each build.
Casino product has adopted TypeScript - Due to the success of the mobile InPlay product a recent rewrite of the casino site has been written in TypeScript.
TypeScript 2.0 - The language is constantly evolving providing, we are staying on the upgrade path to make sure the developers get all the benefits of new releases as early as possible. Check out their github page to see the roadmap.
Sportsbook rewrite - All I have talked about so far has paved the way for us to rewrite our desktop Flash site to TypeScript. We are about half way through this project and it’s going really well, we have a great team who are passionate about the technologies they are working with and the product they are creating. We expect the product to have a shelf life of around 5 years so it’s important to get things right first time and we believe TypeScript is playing a key role in helping us achieve this.
We will also soon be starting a rewrite of the mobile site to make it 100% TypeScript leaving no trace of raw JavaScript in our codebase.
The re-writes introduce new and improved functionality and fresh design but the improvements below the surface are just as important as they benefit our whole development team. TypeScript has and will continue to guarantee quality in our products which saves time, makes a happy development team and helps us to react quickly to change and maintain our position as the market leader.
Introduce myself as tech lead at bet365 currently working on the rewrite of the desktop sportsbook site. 8 years experience as a senior Flash developer before joining bet365 in 2010.
