Reykjavík University 13 May 2016

Final Report

Receptor - Applicon B.Sc Computer Science, Spring 2016

Steinunn Marta Friðriksdóttir

Svava Dögg Björgvinsdóttir

Sveinbjörn Guðjohnsen

Instructor: Hlynur Sigurþórsson

Examiner: Hannes Pétursson

Receptor

Table of Contents Introduction

Receptor

The Original Project Description

What Did the Team Manage to Finish?

What Does the System Look Like?

System architecture

The architecture

Database

Back-end

Node.js Server

Front-end

New Technologies

React.js and Flux

Webpack

Other

Project Management

Original Team Roles

Tools

Documentation

Source Control

Scrum

Results

Risk Analysis

Discussion

Future Works

Conclusion

Appendix

1

Receptor

Introduction This report is part of a B.Sc. final project in Computer Science at Reykjavík University in the spring of

2016. The project was done in collaberation with Applicon, a subsidiary of Nýherji which is placed in

Borgartún 37.

Most large companies today, such as Nýherji have to follow strict security standards.

Companies need to have receptionist to keep track of everyone entering their buildings in order to

fulfill set standards.

In Borgartún 37 there are four different companies, including Nýherji and Applicon. Where

each company has individual employees, all receiving visits from multiple guests and customers

throughout the day. This causes a great amount of people passing in and out of the building every day,

workers or not. This leads to a bit of a problem: it can be difficult to keep track of every outsider that

enters the building. This can be a burden for the reception as they have to call each employee to notify

them when a guest they were expecting shows up etc. Often employees get several visits over the

course of one day, so it can be easy to forget and miss meetings with guests. The project’s goal was to

design and develop Receptor which is a guest reception solution that solves the above-mentioned

problem. Receptor is a platform (which includes a front-end web-app) which will run on a tablet in the

reception of the building. When a guest enters the building, he/she logs in to the system with their

name. If the party in question has a pre-booked meeting, the meeting will show up on the tablet with

the possibility to confirm their arrival and the employee who registered the meeting will get a

notification by SMS and/or an email about the guests arrival. On the other hand if the guest has not

already booked a meeting, the guest can search for the employee he/she wishes to meet, by company

and name and send the employee a notification about their arrival.

In the following chapters, a further description of Receptor and its development can be found

as well as an overview of tools used to develop the system.

2

Receptor

1. Receptor In this chapter you will find general information about the Receptor system including how much of the

project the team managed to finish.

1.1. The Original Project Description

The initial description of the project the team received from Applicon was stated as follows: A

functional reception solution which runs on a tablet or a touch screen inside the Nýherji building. A

reception solution that keeps a record of all guests who enter the building and notifies employees when

their guests arrive. Most companies today aim to ensure that no outsider wanders around in their

building without surveillance. A reception solution like this should also make the reception of guests

quick and efficient.

Hereafter is a more detailed description of the requirements:

● Guest login

● Overview of guests registered in a database

● Be able to somehow import employees into the system.

● An email or SMS notification for an employee when a guest arrives

● Pre-registration of meetings that handle more than one guest.

● Pre-registration email for each guest in the registration with meeting information

● Electric ID / Ísland.is - not required but would be nice

● Sticker printer - not required but would be nice

● Active Directory - not required but would be nice

1.2. What Did the Team Manage to Finish?

Through the development of Receptor some changes were made to the initial description. In the

initial description it was requested that the team developed the front-end for Receptor as well as a

back-end system where a building admin could access an overview over the guests who enter the

building. A few weeks into the project, in consultation with Applicon a decision was made to add a

second back-end system for the employees of the company. This allows employees to login to the

back-end of the system and register meetings. The employee is also provided with an overview of

upcoming meetings.

3

Receptor

The front-end of Receptor allows a guest to login whether the guest has a pre-booked meeting

or not. If the guest has a pre-booked meeting the guest will login with his/hers name and consequently

notify the relevant employee. On the other hand if the guest arrives without having a booked meeting,

the guest can choose from a list of companies in the building and is then provided with an overview of

the company’s employees. The guest is then able to register a new meeting and the employee is

notified.

Originally the team planned on developing the system with a connection to Active Directory

but during a meeting with one of the product owners the idea of making Receptor a multi-tenant 1

solution came up. A multi-tenant software solution means that many customers can be served with a

single instance of an application. By making Receptor multi-tenant we had to add a third back-end to

the system named the core. That means there are two admins. The Receptor admin (owner) and a

company admin. (customer) That allows the Receptor admin to register new customers to the system

outside of Nýherji. When new customers are registered they get a token which they need to enter to

get access to the main guest-view of the Receptor platform.

1.3. What Does the System Look Like?

The goal was to make Receptor visually appealing since it will be the first thing people see when they

enter the building. In a way, this is the “front” of the company. Although the use of the front-end is

quite different from the back-end we managed to keep the style consistent overall.

The platform is responsive, meaning that the user interface will adapt to the screen size,

making it look nice on both tablets or larger displays, which are both intended to be used when

interacting with Receptor. The guest will be using Receptor solely on a tablet when entering the

building but employees who use the back-end will be able to choose whether they use their smart

device or a larger display. The welcome screen is shown on figure 1.

More screenshots of the system can be found in Appendix A.

1 https://en.wikipedia.org/wiki/Multitenancy

4

Receptor

Figure 1 - The Receptor welcome screen

2. System architecture In this chapter we will cover the Receptor system architecture. Which technologies were used and how

the system works, interacts and communicates with the client or the front-end.

2.1. The architecture

The Database and the .NET back-end communicate together in an environment which is restricted 2

from all outside connections, except for our node.js server, which acts as a proxy. The client or

front-end only gets to interact with the node.js server which then relays the information according to

rules.

By giving each component in the platform, such as the node.js , as few and simple tasks as possible we 3

get a modular pretty platform.

Figure 2 represents the system architecture graphically.

2 https://www.microsoft.com/net 3 https://nodejs.org

5

Receptor

Figure 2 - The Receptor Architecture

2.1.1. Database

The database is an MSSQL server hosted on Microsoft Azure . It is normalized to some form and 4 5

contains all information needed by the receptor platform. It stores data about companies, employees,

guests and registered meetings etc.

2.1.2. Back-end

The back-end was developed in Microsoft .NET and C#. The back-end contains all the logic of the

system as well as it sends and receives data from the database.

The back-end contains a notification interface which uses reflection. Reflection allows users to

dynamically load classes which makes it easy to implement a new notifier and then import it to the

4 https://www.microsoft.com/en-us/server-cloud/products/sql-server/ 5 https://azure.microsoft.com

6

Receptor

system as a DLL file and loaded into the system during runtime. Notifications by SMS and Email have 6

already been implemented, but if a company wants to get notification by some other way such as a

service like Slack , a new notifier can be implemented in a simple way as mentioned before. We also 7

implemented a login interface in a similar way, except it doesn’t use reflection, but it allows to adding

new ways to log in e.g. with Facebook , Google etc. 8 9

2.1.3. Node.js Server

As mentioned earlier on the node.js server is the only thing that can communicate with the back-end,

from the front-end.

Authentication is handled by the node.js server using cookie-based authentication.

When a user needs to be authenticated, the node.js asks the back-end if the credentials provided are

valid and issues a signed cookie to the user accordingly. So each time a client/user makes a request, the

server verifies the cookie passed by the client and if the cookie is valid the server will proxy the

requests to the back-end and add appropriate information to the HTTP header of the request

(customer ID and employee ID).

The server also handles bundling (See chapter: Webpack) and static resources such as images

or css. There server serves four different bundles, a “guest” bundle and “staff” bundle which are then

split in two: authenticated and unauthenticated depending on if the client is authenticated or not.

2.1.4. Front-end

Last but not least, there is the front-end or web-app. The front-end is written in React.js. For UI we

used the Foundation CSS framework. 10

React.js is a library recently published by Facebook for front-end development and is used with the 11

Flux design pattern. What makes developing a front-end with React.js so great among other things, 12

are the composable and reusable components. These reusable components decrease the repetition of

code and consequently the loading time of the website is faster. Another mention is the Virtual DOM,

which is structured as a tree graph makes it possible to render only the components that actually need

6 https://en.wikipedia.org/wiki/Dynamic-link_library 7 https://slack.com/ 8 https://developers.facebook.com/docs/facebook-login 9 https://developers.google.com/+/web/signin/ 10 http://foundation.zurb.com/ 11 https://facebook.github.io/react/ 12 https://facebook.github.io/flux/docs/overview.html

7

Receptor

to change at the time but the code can be written as if the entire page is rendered on each change. Last

but not least there is the one-way data flow in React.js that sends data down the application as in the

parent component passes new data to the child component, simplifying the application. Flux gives the

possibility of a cycle in the flow, the data goes down to child components in a form of an action, the

action calls the dispatcher which updates the store and the store informs the parent component that

there is new data. The parent component gets the data and passes it down to the child component via

non mutable props which pass it down to their children and so on. No controllers, no directives, no

viewmodels, no problems.

A graphical representation of the flux lifecycle can be found in section 2.2.1

2.2. New Technologies

During the development of Receptor the team had to overcome a few obstacles concerning technology

none of the team members had ever used before. This chapter covers general information about these

technologies.

2.2.1. React.js and Flux

The Receptor front-end is written in React.js. In the beginning of the Receptor project the team had

no experience whatsoever with React.js. So before starting development Receptor the team had to get

familiarize with React.js along with Flux which caused the project to go off to a slow start and in early

stages of the project the team was already behind schedule. In the beginning of sprint four, the team

started to understand the Flux pattern and how the two, React.js and Flux work together. This is

when the wheels started turning and the team started to get back on track.

8

Receptor

Figure 3 - The flux pattern 13

2.2.2. Webpack

Webpack is a module bundler. It bundles modules with dependencies into static assets. Using Webpack

with React.js is very important since using React.js means having to create many files, when in fact

every component is stored in an individual file. Using webpack to pack our code plus the modules

together, allows us to serve the client a single, isomorphic platform in a one single file.

2.2.3. Other

During development the team came across some libraries and frameworks that we think are worth

mentioning in this report. First of all we would like to mention Superagent , a javascript HTTP 14

request library, that simplified client-server requests and sped up development time.

One of the objectives of Receptor is to allow registration of meetings. This requires dealing

with date and time, so a good date/time parser was necessary. That is when the moment.js a 15

javascript time/date parser, manipulator and validator.

For the background of Receptor we use the beautiful particles.js library. 16

Last but not least we would like to mention Reactable , a React.js table component. It proved 17

to be very flexible and powerful, which saved us a lot of hassle dealing with displaying data in a

structural format.

3. Project Management The team followed the Scrum methodology since it is the methodology the team is most familiar with.

Applicon also utilizes Scrum in their development so we thought it was most applicable. It was decided

that each sprint would take two weeks and having 15 weeks to finish the project the team had seven

and a half sprints to develop the project.

Feature freeze was activated in the last sprint. The last sprint was used to give the final touch to

Receptor such as to fix bugs or the CSS.

13 https://facebook.github.io/flux/docs/overview.html 14 https://visionmedia.github.io/superagent/ 15 http://momentjs.com/ 16 http://vincentgarreau.com/particles.js/ 17 https://github.com/glittershark/reactable

9

Receptor

3.1. Original Team Roles

The set Scrum roles were set as follows:

- Product Owner: Erla Andrea Pétursdóttir og Gunnlaugur Th. Einarsson

- Scrum Master: Steinunn Marta Friðriksdóttir

- Development Team: Steinunn Marta Friðriksdóttir, Svava Dögg Björgvinsdóttir &

Sveinbjörn Guðjohnsen

Applicon provided the team with an office space to work in along with computers and external

monitors to be used when working on the project. The team decided to meet 3 - 4 days a week for 8

hours each day, but stayed longer if needed. The team had heavy course load over the semester so the

schedule had to be flexible but at the same time at least 26.5 hours had to be spent on the project each

week per person. The team agreed on working on the project whenever they had the time for

maximum efficiency. Each sunday the team met up with their supervisor, the meetings lasted on

average around 1-2 hours.

Given that the team planned on spending 26.5 hours a week on the project the capacity was

150 hours per sprint. [26.5 hours * 3 persons * 2 weeks] During the final exams, the plan went a little

of track so the team decided to abate the capacity to 90 hours per sprint.

When the final exams were over the team had more time available and it was decided that each

member worked at least 8 hours, or more if needed, a day on the project, every day of the week. This

extended the capacity to 336 hours per sprint. This gave the team an opportunity to compensate for

lost hours during final exams.

3.2. Tools

This chapter contains an overview of tools used for the planning and development of Receptor.

3.2.1. Documentation

For documentation the team used Google Docs. The reason Google Docs was chosen over other text

editors is that Docs is a part of Google Drive which makes all documents available to all team 18

members at all times and everyone can work on the same document at the same time.

18 https://drive.google.com/

10

Receptor

3.2.2. Source Control

All code was stored in a private repository on BitBucket , a free cloud based git solution. 19

3.2.3. Scrum

To keep track of the backlog and sprint information the team prepared a Google Sheet document.

Work hours were logged into Toggl , a time tracker, and each member was responsible for logging 20

their own time.

3.3. Results

Overall the team finished all A requirements and 7 out of 8 B requirements. That means that the team

was able to finish 955 story points out of 1056 or 90% of all requirements. In Figure 4 you will find

how much the team spent on each sprint. Table 1 shows an overview of all the sprints. Note that the

each sprint is named after a presidential candidate.

Estimated time for the project was 1260 hours, but the team spent altogether 1393 hours on

the project. The reason for this is because we spent so much time in the beginning in work that we had

not planned on doing, such as learning React.js and Flux. Figure 4 shows how many hours the team

estimated to work on each sprint (blue line) and how much they actually spent (red line).

Table 2 shows the overview of spent time and how much time each member spent on the

project.

A more detailed overview of the project management like the Release Burndown Chart can be

found in Appendix B

19 https://bitbucket.org/ 20 https://toggl.com/

11

Receptor

Figure 4 - Hours spent in each sprint

Table 1 - Sprint overview

Table 2 - Hours spent by team member

12

Receptor

3.4. Risk Analysis

It is important to think ahead of time when working on a project of this size to minimize damage in

the case of an unforeseen event. Table 3 shows the risk analysis for the development of Receptor.

Table 3 - Risk Analysis

3.5. Discussion

Utilizing Scrum made the project planning estimation relatively easy and gave us a more visual

overview of how the project was going.

The team calculated that if we only wanted to finish all A requirements we would have to burn

at least 100 story points a sprint, but of course we aimed to finish as much as possible. The average

burndown each sprint was 120 story points, which made it possible for us to finish all A requirements

along with most of the B requirements. The team started off using JIRA to keep track of the sprints 21

but early on we found that it wasn’t very flexible so we quickly moved over to Google Sheets. We came

up with a really good system which gave us a good overview of the sprints.

The not so great part about Scrum is probably the fact that it’s not allowed to change a sprint

after it begins, which is quite unfortunate when you suddenly remember something important that

needs to be done in the middle of a sprint.

21 https://www.atlassian.com/software/jira

13

Receptor

4. Future Works Since we only got a certain amount time to finish the product we were not able finish all the features

we would have wanted to. Here are a few things that we think could be done in the future to make the

product even better.

Firstly, an employee can only create a meeting with one guest at a time. Employees often have

meetings with more than one guest at a time so it would have been nice to make it possible to create a

meeting with more than one guest at a time. This feature could also be used when there is a conference

going on. On the other hand, we made the architecture support this so it should be easy to implement

it.

A second feature we would love to add is if the admin of each company/customer could see an

overview graph over all the guests who have been in the building, which company they were meeting

up with and how long they were in the building.

Thirdly, the product as it is, is a functional multi-tenant platform. It should not be a problem

developing it to a full software as a service (SaaS) or even a platform as a service (PaaS) solution. 22 23

One reason for the product not being completely a Saas or a PaaS is, as an example, it doesn’t offer the

possibility for a customer to service himself since an admin has to register all new customers before

they can start using the product.

5. Conclusion We hope this report has given insight into the development and given an image of what the Receptor

platform is. This project has been both fun and challenging, and we have learned so much. Overall the

project went really well, but it could have gone off to a better start. We are happy to have had the

opportunity to learn React.js and Flux and we will definitely be using them for future web-app

development. The React+Flux pattern definitely requires a whole new way of thinking, different from

the “regular” MVC web-apps that we were used to, such as Angular.js or Microsoft MVC 24 25 26

22 https://en.wikipedia.org/wiki/Software_as_a_service 23 https://en.wikipedia.org/wiki/Platform_as_a_servic 24https://en.wikipedia.org/wiki/Model–view–controller 25 https://angularjs.org/ 26 http://www.asp.net/mvc

14

Receptor

Utilizing scrum for this project was alright, but not great. We were familiar with the

methodology from before. Scrum gives you a good visual overview over what you have to get done

and a good idea of when you will be able to finish each task . We haven’t used any other methodology

before so we can’t compare it to anything else, but it would be nice to use something more flexible in

the future.

We would like to thank:

- Applicon for giving us the chance to work on this project, and also providing us with

the necessary resources. Erla, Ingimar, Elfar, Björgólfur, Úlfar, Gunnlaugur and

Jóhannes thank you for your help and input.

- Our instructor, Hlynur, we really would not have been able to finish this project if it

weren’t for him. He pushed us in the right direction whenever we started getting off

track and on our weekly Sunday meetings we often came in crawling, tired and

confused after the week he gave us the motivation needed to keep on going.

- The coffee machine at Applicon as well as Guðjón the coffee barista downstairs.

6. Appendix A. Developer Guide

B. Project Management

15