This blog post looks at the development and launch of the new London School of Marketing online platform.
This was one of the first major projects that I worked on after graduation. I had heard lots about Node.js and how it’s changing the world, so I was super excited to hear that I would be working with it on this project.
I have to admit that I felt a little daunted when I read the project spec. The new system was to be built in Node.js, which I would have to learn from scratch. The project had a tight, 12-week time frame. The project team was spread over six countries. The project leader was a ‘delivery architect’, an innovative concept by nearForm that replaces the traditional project manager. Just to make communications a little more complex, there was also a third party in the mix: InterLink, the company that had previously maintained the client system.
Let’s take a quick look first at the client, their existing system and what they wanted nearForm to do.
The client and their system
London School of Marketing (LSM) is a leading educational institution based in London, UK, offering accredited marketing and business qualifications. They had already developed an online learning platform for their own students. Now, the client wanted nearForm to develop the platform to make it fully generic and usable by any college or university around the world.
The platform comprises several systems, including the following:
- Academic management system
- Learning platform
- Content platform
- Online enrolment system
- Submission system
Some of the systems are a first of their kind for any online education platform, especially the learning platform, which enables content to be generated dynamically.
Steep learning curve
I thought I was going to learn about Node.js. And I did… plus a whole lot more.
At first, Node.js seemed difficult to learn. There were some concepts that took me some time to grasp. After a while, I started to see a pattern in the way things worked. When it comes to software development, I find that the best way to learn is by practical work, so I took many of the tutorials at nodeschool.io. These helped me get an understanding of how powerful Node.js really is.
Starting off, one of things that surprised me most was how Node.js allows you to set up a web server with about 10 lines of code. I also liked the community behind Node.js and saw that there’s a package available for almost anything via npm. Working on the LSM project helped me to learn about the features Node.js has to offer, as the project was entirely supported by the Node.js platform.
At nearForm, microservices go hand-in-hand with Node.js. I learned how to develop microservices using the Seneca platform. As the project progressed, I saw first-hand the advantages of using microservices as opposed to one large service that handles everything. As well as easy maintenance and easy deployment, these advantages also include system integrity—that is, if one microservice breaks, it’s not going to take down the entire application. The microservices I wrote included simple create, read and update methods, while others, such as searching, were more complex.
I worked mainly on the academic management system (AMS). The AMS is a single-page app built using AngularJS (see ‘Infrastructure’ below for more detail on the AMS).
I learned a lot about AngularJS and its features, including how directives can be used across several pages in the app, how controllers handle the view’s logic and how services interact with the API that Seneca exposes. I found that AngularJS made it easy to build up a web page quickly by making use of existing directives and services in the app.
AngularJS handled all of the front end of the app, while Seneca handled the back end. For example, if data needed to be retrieved from the app’s database (all of the microservices made use of the same database in this project), a microservice would have to be added with a ‘list’ action using Seneca. Seneca exposes this list action to AngularJS via a route, such as /courses/list. On making a get request to this route, a service in AngularJS can load all the courses and display them in a table on the front end. This list action only needs to be written once and can be used by any other page in the app.
This project used a formal code review process. This allowed me to improve the quality of my pull requests by getting feedback from other team members. On submitting work, another team member would review and leave comments on how certain code could be improved. Once a review was complete, the code was merged into master and made live during the next deployment.
As well as development skills, I also learned about the infrastructure side to a project. For this project we used Amazon Web Services (AWS). We made use of three different server groups: one for continuous integration (CI), one for staging and another for production. As well as using Jenkins to deploy to the AWS servers, we also made use of nearForm’s nScale to allow quick deployment and easy rollback. With the help of other team members, I configured nScale to deploy to the CI server.
Lastly, I gained knowledge about project structure; that is, where back-end services and front-end files should be stored. This is important as there needs to be consistency in how files are stored. Consistency in file storage makes it easy to maintain a project and also allows other developers to understand the architecture of the application.
This project was developed using the agile approach. This approach was selected due to the large number of systems that needed to be developed. The development methodology was as follows:
- The client provided nearForm with mockups and design requirements.
- Meetings were held with the client and all developers to discuss the implementation of these designs.
- Once the designs were agreed, the delivery-architect assigned work to each developer for each week.
- The delivery architect outlined goals to be achieved by the end of the week. The goals were visible in basecamp.
Development was carried out as follows:
- Repos are forked to each developer’s personal GitHub account. All new features are pushed to this repo. The developer then creates a pull request from their own repo to the client’s GitHub.
- All pull requests are reviewed by other developers on the project to maintain a high standard and also to achieve consistency across each system.
- Once a pull request has been reviewed and all comments and suggestions have been addressed, the pull request is merged into the master branch.
- The Jenkins build server then automatically builds and deploys the app to the continuous integration (CI) server.
Weekly client demos
The agile methodology also involved weekly demos with the client. These demos allowed the client to give feedback on each of the different systems. The client was able to use the application by viewing the latest version on the CI or staging server. This was a very effective way of development and ensured that the final product was exactly what the customer asked for.
Initially, deployment was set up using a traditional approach with Jenkins as the build server. Any change made to the master branch of each system was automatically deployed to the client CI server.
To deploy to the staging server, we created a new branch in the client repo and called it v0.1.0, for example. This gave our deployment a version number. We then ran a job on the Jenkins server called sync_repos. The sync_repos job took this version number as a parameter and then pushed that branch to lsmdeployment, a separate GitHub account.
To build the staging server, we set the parameter as the above version number and ran the build. The production server is built in the same way; however, it requires that the staging server be deployed first. Towards completion of the project, nScale was configured to replace the above method of deployment.
Students on the client’s previous learning platform had to be transferred to the new platform. This involved some complex migration scripts.
Once these scripts were run, students could log in to the new system. All the new platforms were launched successfully and are now in active daily use by London School of Marketing students and staff.
My main task during the product launch was to write a script that would email a certain set of students registered on various LSM courses to let them know that they could now log in to and use the new learning platform. Students were moved over to the new learning platform on a phased basis; therefore, it was important that the script only emailed students based on LSM’s requirements. This allowed us to test certain features and make sure everything was working correctly before migrating all of the students to the new platform.
My next steps
The finished London School of Marketing system is an example of how businesses are updating their existing systems to use Node.js. I’m proud of the contribution I made to it. Even though it was a baptism of fire in my career as a software developer, I already feel a lot more confident and relieved that my ‘newbie’ project went so successfully.
With my new knowledge of Node.js, AngularJS, Seneca and nScale, I’m already in the thick of my next project: a new community platform for CoderDojo. This platform is similar in many ways to the LSM project as it makes use of the above technologies. I’m using Seneca and AngularJS to implement both back-end and front-end features. The knowledge that I gained on the LSM project has helped me to hit the ground running with the CoderDojo platform and I’m learning more about these technologies every day.
Want to work for nearForm? We’re hiring.
Phone +353-1-514 3545
Check out nearForm at www.nearform.com.