Continuous Group Report - TNM090, Software Engineering

Emil Axelssonemiax775@student.liu.se

Jonas Zeitlerjonze168@student.liu.se

January 14, 2014

1

Contents

1 Introduction 3

2 Original Goals 32.1 A usable application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Animation of arbitrary mathematical parameters . . . . . . . . . . . . . . . . . . . . . . . 32.3 Support for more graphics representing mathematical objects . . . . . . . . . . . . . . . . 3

3 Agile Development 33.1 Routines and meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33.2 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33.3 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

4 Technical Solutions 44.1 Architecture of Continuous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44.2 Modules in large JavaScript apps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44.3 “Just because JavaScript is classless, doesn’t mean you have to be”[4] . . . . . . . . . . . 44.4 Module design / Packages and their subpackages . . . . . . . . . . . . . . . . . . . . . . . 54.5 Program design inside the modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4.5.1 Kalkyl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54.5.2 MathGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64.5.3 Application layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74.5.4 Visualizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4.6 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84.6.1 Unit testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84.6.2 Performance and benchmarking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.6.3 User testing and feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.7 Dependency management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5 Reviews and refactoring 95.1 Application layer/visualization interface architecture . . . . . . . . . . . . . . . . . . . . . 9

5.1.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95.1.2 Misleading assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105.1.3 Roll your own . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5.2 Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105.2.2 What to expect from a transition API . . . . . . . . . . . . . . . . . . . . . . . . . 115.2.3 An agile approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5.3 Module dependency management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115.3.2 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115.3.3 New convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

6 Accomplishments 12

2

1 Introduction

Continuous is an interactive math visualization tool for university students. It is written, almost exclu-sively, in JavaScript using WebGL[1] technology. During fall 2013 the software has been developed byEmil Axelsson and Jonas Zeitler in the course TNM090, Software Engineering.

2 Original Goals

The Continuous project plan, written in October 2013, described the current state of the project and thescope of the fall’s work. The main goal was to produce 5-10 interactive presentations of mathematicalconcepts from multivariable calculus. To accomplish this, the already-existing graphics engine and itsAPI had to be improved and the project also needed to be extended with the following:

2.1 A usable application

A graphical application, preferably based on a JavaScript application framework for example AngularJS[2]should be written. It should serve as a platform for building interactive visualizations utilizing the un-derlying graphics engine.

2.2 Animation of arbitrary mathematical parameters

To build step-by-step visualizations where the content transforms smoothly between the steps, it mustbe easy to express animation logic. For example: seamless transformation of a curved surface to a planeshould be able to be expressed with ease only using a few lines of code. An API to express the steps in avisualization and functionality to jump forward and backward is also important to minimize the amountof boilerplate code that has to be written every time a new visualization is created.

2.3 Support for more graphics representing mathematical objects

In October, the graphics engine was able to draw parameterized surfaces, but lacked support for curvesand vector arrows, which both are important graphical entities used in calculus. Support for at leastthese two kinds of objects should be added.

3 Agile Development

3.1 Routines and meetings

During the development, scrum was used as project methodology. Iterations were bundled as two weeksprints. Sprint demos were being held on fridays odd weeks when possible. The next sprint planningmeeting took place after the weekend.

Development was mostly carried out during full days (approximately 8 h) with the team sitting aroundthe same desk. It was always possible to ask the other developer questions and keep good communicationwithin the team.

3.2 Clients

Continuous is owned by the developers and it is ultimately their responsibility to make decisions regardingcritical functionality. That aside, there are several other people involved. George Baravdish and OlofSvensson are two lecturers at Linkopings Universitet that the team has worked close to. A long termgoal is to incorporate Continuous into the lecturers’ courses during fall 2014. Therefore, George and Olofhas acted as clients in this project. They have provided valuable information on how Continuous wouldbest fit into their courses.

3

3.3 Backlog

The Backlog was maintained in a Google spreadsheet. When committing to a sprint, tasks derived fromthe user stories were submitted into the GitHub issue tracker. This enabled the use of a combined versioncontrol- and project management system.

4 Technical Solutions

4.1 Architecture of Continuous

Like any other web application, Continuous is based on the client-server pattern at its highest level.The server’s role is currently limited to delivering files upon request of the browser, where most of theapplication’s logic is being executed. In the future, the server’s role is planned to become extended tohelp the client perform more complicated algebraic calculations as well as to serve as a database for thevisualization library.

4.2 Modules in large JavaScript apps

JavaScript has no native module management system and has not been used for large application devel-opment traditionally. The naive solution would be to list all script files in the index.html file and let themregister their objects and functions on the global namespace. This easily becomes an unmaintainablemess.

Instead Continuous makes use of a third party library called RequireJS[3] to manage its modules. Thisway, modules and their dependencies can be dynamically requested from the server. RequireJS ensuresthat each module is requested only once even if it is used by multiple other modules.

4.3 “Just because JavaScript is classless, doesn’t mean you have to be”[4]

This is a quote from a talk by Nicholas Zackas, author of several popular JavaScript books. A mod-ule loader system like RequireJS is one of the building blocks needed to do software development inJavaScript. It provides a handy way to divide the application into multiple files (modules) in the firstplace. But it does not set any standard on how to structure the modules themselves. A logical way tothink about modules would be to always declare one class per file.

However, JavaScript does not have classes. Natively JavaScript has prototypal inheritance, that is,objects inherit directly from other objects. The new -operator is present but the operand expected onthe right hand side of it is not a class, but a function (a constructor). Continuous uses the tiny librarycalled quack.js[5], written by Emil in spring 2013, that provides a way to easily structure an object’sprototype chain to make it behave similarly to a class, with features such as method inheritance, abstractmethods and interfaces.

4

4.4 Module design / Packages and their subpackages

kalkyl format

simpleglmatrix

javascript

glsl

mathgl engine

app js

img

css

partials directives

controllers

filters

services

visualizations

visualization interface

test

kalkyl mathgl app

Continuous – System Overview

Figure 1: Continuous - System Overview

Figure 1 shows (almost) all current JavaScript packages and their sub-packages. Arrows from A to Bindicate a dependency where A requires B. In Continuous, a sub-package is generally dependent on itscontaining package. To avoid circular dependencies, it is strongly discouraged to create classes in packageA that depend on classes from a subpackage inside A. In the same way, if one class in package A requiresa class from package B, classes in B should never require any class from A.

4.5 Program design inside the modules

4.5.1 Kalkyl

The majority of the currently existing classes in Kalkyl were developed outside the scope of the courseproject. In its format/simple subpackage lives basic functionality for parsing mathematical expressionsinto expression trees. Kalkyl’s expression tree components (Operators, Numbers, Vectors, Matrices,Variables etc) are all derived from the base class called Expression.

The Kalkyl package makes heavy use of the visitor pattern. The visitors can traverse an expressiontree, to fetch or modify its content. Among these are the Substitutor that replaces all occurrences of a

5

certain variable with another expression tree, and the Differentiator which performs symbolic differenti-ation using basic rules from calculus.

Apart from handling parsing, the Format sub-packages also have Visitors that can convert expressiontrees to GLSL and JavaScript source code. Kalkyl’s GLSL output is required by MathGL’s dynamicshader generation process to render mathematical entities on screen.

4.5.2 MathGL

MathGL is Continuous’s graphics engine. The classes in the MathGL root package (all shown in Figure2) are designed to be used as building blocks to create the “scene graph”-like data structure representinga visualization scene. The public methods of these classes serve as the absolute majority if the MathGLAPI.

The base class that represents a node in the scene tree is called Scope. In the UML-diagram, theyare marked with green colors. A Scope may store two kinds of properties: expressions and primitives.Expressions are stored as a map from strings to Kalkyl.Expressions, and are used to define relationshipsbetween mathematical symbols. Primitives are defined as a map from strings to primitive JavaScriptnumbers. Both definitions of expressions and primitives are inherited down to child scopes.

Entities, which inherit properties from Scope, are mathematical objects than can be drawn on thescreen. All entities need a graph of Appearances in order to be rendered. These graphs can be composedin various ways in order to create combinations of i.e. gradient fills and checker patterns.

The MathGL.Engine subpackage only contributes to the API with one class – the View. To rendera scene it requires being fed with a canvas element, a MathGL.Space and a MathGL.Camera. The Viewacts a facade for the Engine package, whose other classes handle rendering and should never have to betouched from outside.

The engine reads the defined expressions from the MathGL API and generates custom shader pro-grams that displaces vertices according to the expressions. Changing an expression definition requiresa shader program to be recompiled, which takes some time. However, when a primitives changes, theEngine simply updates the corresponding GLSL uniform. This provides a way to edit mathematicalproperties and get visual feedback in real time.

6

MathGL– Class diagram

new Scope({ expressions: string -> (string or Kalkyl.Expression) expressions, primitives: string -> number primitives, visible: bool visible})

+ number id()+ bool visible([bool visible])+ bool chainVisible()+ Scope parent()+ Scope[] children()+ Space space([Space s])+ void add(Scope child)+ void remove(Scope child)

+ void definePrimitives(string symbol -> number value)+ void definePrimitive(string symbol, number value)+ number primitive(string symbol [, number value])+ void primitives(string symbol -> number value)+ string->value allPrimitives()

+ void defineExpressions(string symbol -> Kalkyl.Expression expr)+ void defineExpression(string symbol, Kalkyl.Expression expr)+ Kalkyl.Expression expression(string symbol [, Kalkyl.Expression expr])+ void expressions(string symbol -> Kalkyl.Expression expr) + string->Kalkyl.Expression allExpressions()

+ bool defines(string symbol)+ void undefine(string symbol)+ Kalkyl.Expression flat(string symbol)+ number value(string symbol)+ bool definesExpression(string symbol)+ bool definesPrimitive(string symbol)

~ void forEachChild(void f(Scope child))~ void traverse(void f(Scope child))

- Kalkyl.Substitutor substitutor()- Kalkyl.Format.Simple.Parser simpleParser

- number _id- string->Kalkyl.Expression _expressions- string->number _primitives- Scope _parent- Scope _space- number->Scope _children- string -> Kalkyl.Expression _flats- Kalkyl.Substitutor _substitutor- Kalkyl.Format.Simple.Parser _simpleParser - bool _visible

- void notifyObservers(string type)

new Space({ expressions: string -> (string or Kalkyl.Expression) expressions, primitives: string -> number primitives, visible: bool visible})

+ void addObserver(SpaceObserver o)+ void removeObserver(SpaceObserver o)+ void notifyObservers(Scope s, string type)

Scope

+ number id()~ Entity[] entities()~ void traverse(void f(Appearance input))~ Appearance[] bottomUp()~ void forEachInput(void f(Appearance input))~ void forEachOutput(void f(Appearance output))# string{} symbols()# Appearance input# Appearance{} inputs# Appearance[] outputs()# void registerOutput(Appearance output, string slotName)# void unregisterOutput(Appearance output, string slotName)# void registerEntity(Entity entity)# void unregisterEntity(Entity entity)# void notifyObservers()- number id- string->Appearance _inputs- string->Appearance _outputs- number->Entity _entities

Appearance

+ string blendMode(string blendMode)+ Appearance background([Appearance bg])

Fill

new Threshold({ parameter: string parameter, value: string or number value, above: Appearance a, below: Appearance b})

# string{} symbols()+ string parameter(string symbol)+ string or value value(string or number value)+ Appearance above([Appearance a])+ Appearance below([Appearance b])

Threshold

new Color (number color) ornew Color ({ background: Appearance bg, color: number color [, blendMode : string mode]})

# string{} symbols()+ number color(number color)+ number[] floatVector()

Color

new Gradient ({ background: Appearance bg, stops: number -> Appearance map [, blendMode: string mode]})

# string{} symbols()+ string parameter(string symbol )+ Appearance stop(number value, Appearance a)+ Appearance stop(number -> Appearance map)+ void clearStops()

Gradient

new CheckerPattern({ background: Appearance bg, parameters: string -> number stepSizes inputA: Appearnace a, input B: Appearnace b, [, blendMode : string mode]})

# string{} symbols()+ string parameter(string symbol, number stepSize)+ string -> number parameters(string -> number parameters)+ Appearance inputA([Appearnace a])+ Appearance inputB([Appearnace b])

CheckerPattern

Diffuse

new Surface({ domain: string -> number[2] symbols] expressions: string -> (string or Kalkyl.Expression) expressions, primitives: string -> number primitives, plot: string -> (string or Kalkyl.Vector3) p, style: string wireframeOrSolid = ”solid”, appearance: Appearance a, visible: bool visible = true})

string -> number[2] domain([string -> number[2] symbols])string[] parameters()string -> number stepSize(string -> number sizes)str style(string style)Kalkyl.Vector3 plot([Kalkyl.Vector3 plot])string->Kalkyl.Vector3 tangentExpressions()

Surface

new Curve({ domain: string -> number[2] symbols] expressions: string -> (string or Kalkyl.Expression) expressions, primitives: string -> number primitives, plot: string -> (string or Kalkyl.Vector3) p, style: string wireframeOrSolid = ”solid”, appearance: Appearance a, thickness: number t, visible: bool visible = true})

string -> number[2] domain([string -> number[2] symbols])string[] parameters()string parameter()string -> number stepSize(string -> number sizes)number thickness(number t)Kalkyl.Vector3 plot([Kalkyl.Vector3 plot])string->Kalkyl.Vector3 tangentExpressions()

Curve

+ number thickness(number t)+ Kalkyl.Vec3 position([Kalkyl.Vector3 p])+ Kalkyl.Vec3 value([Kalkyl.Vector3 v])+ string[] parameters()

VectorArrow

Space

+ Appearance appearance([Appearance a])+ string[] parameters()

Entity

new Camera({ position: Kalkyl.Vector3 or string p , subject: Kalkyl.Vector3 or string s, up: Kalkyl.Vector3 or string u})

+ Kalkyl.Vec3 position([Kalkyl.Vector3 or string p])+ Kalkyl.Vec3 subject([Kalkyl.Vector3 or string s])+ Kalkyl.Vec3 up([Kalkyl.Vector3 or string u])

Camera

new Diffuse({ [blendMode : string mode]})

# string{} symbols()

Figure 2: MathGL - Class Diagram

4.5.3 Application layer

Continuous’s application layer is responsible for providing a landing page when the user starts the app,as well as handling navigation between visualizations. It defines routes, renders views and handles input

7

from the user.

The application layer is written in AngularJS, a modern web application framework that implementstwo-way data binding, templating and routing functionality. AngularJS has its own module- and depen-dency manager. In Continuous, however, the system has been configured to use RequireJS instead, forconsistency.

The basic AngularJS application consists of:

• An App module, declaring the namespace and container for the application.

• A Controller module, executing the logic of the application

• An Angular/HTML-template, which gets parsed by the framework and is bound to models in thecontroller.

AngularJS has several concepts which makes it both unique and somewhat unintuitive. A standarddevelopment paradigm is to keep logic and presentation separated. When working with dynamic webapplications, however, there must be some logic having knowledge about elements in the browser’s Doc-ument Object Model (DOM). AngularJS solves this via directives. A directive is a module that can betied to a template to update the DOM.

An example of a directive in Continuous is the equation formatter. This directive uses MathJax[6],another third party library, and formats data from AngularJS models. Other directives are canvasresizer, mouse listener etc.

4.5.4 Visualizations

Visualizations are the modules that defines specific mathematical presentations. The required parts of avisualization has been defined as a script file and a html-template.

A primary goal for visualizations in Continuous is to be as decoupled from the logic in the applicationlayer and underlying libraries as possible. Visualizations should be considered interchangeable pieces,which can be plugged in without any reconfiguration in other parts of the system.

4.6 Testing

4.6.1 Unit testing

Jasmine[7] is a testing library for JavaScript which implements methods for unit testing. In Continuous,Jasmine is used for all unit tests. An example of a unit test written in the course project is one for theKalkyl package, listed below.

1 describe("Basic kalkyl operations", function () {

23 // ...

45 function testMatrixMultiplication(a, b, reference) {

6 a = new Kalkyl.MatrixNM(a);

7 b = new Kalkyl.MatrixNM(b);

8 reference = new Kalkyl.MatrixNM(reference);

9 var result = (new Kalkyl.Multiplication(a, b)).evaluated ();

10 expect(result.identicalTo(reference)).toBe(true);

11 }

1213 it("should be able to perform matrix multiplication", function () {

14 var a = [[1, 2, 3], [4, 5, 6], [1, 2, 3]];

15 var b = [[2, 4, 1], [5, 23, 1], [4, 5, 6]];

16 var reference = [[24, 65, 21], [57, 161, 45], [24, 65, 21]];

17 testMatrixMultiplication(a, b, reference);

18 });

19

8

20 // ...

21 });

Listing 1: Jasmine unit test example

When testing AngularJS components Karma[8], a test runner, is used. Karma has some extendedfunctionality and a command line interface but uses Jasmine as it’s testing library.

4.6.2 Performance and benchmarking

After profiling the application, using Google Chrome’s built in JavaScript profiler, the evaluation ofexpression trees stood out as a operation consuming a lot of CPU time. To see if this could be improved,a small experiment was made:

Kalkyl was extended to be able to output its expression trees to JavaScript source code. It may seemunnecessary to output JavaScript for evaluating expression trees since the trees already are living in aJavaScript environment. However since evaluation of expressions are often performed in tight loops (i.e.when tessellating a function surface) there can be huge performance gains when executing a generatedoptimized javascript function instead of traversing the tree for each sample.

Benchmarks that were made by repeating thousands of evaluations using the optimized and non-optimizedversions of the code, revealed a gain of approximately 300 times faster processing.

4.6.3 User testing and feedback

In october, Continuous’s first appearance in a live lecture was conducted. The team was there to collectfeedback from the audience as well as observing how a non-developer approached the software. A notableinsight were that design decisions regarding color and contrast when projected onto a screen made thevisualizations hard to see. Another issue is that projectors in lecture rooms often have lower resolutionsthan desktop and laptop screens.

Continuous was also presented during Innovationsdagen in Linkoping. The visitors could test the appli-cation and give feedback to the developers.

4.7 Dependency management

To keep track of third party libraries in Continuous, two package managers have been used during thedevelopment. The first is the standard NodeJS[9] package manager, npm[10], which has been used formanaging the test frameworks. The second is Twitter’s Bower[11], used for client side libraries. Bothpackage managers are able to run through NodeJS, which is an implementation of Google’s V8 engineto run JavaScript in the terminal.

5 Reviews and refactoring

In the development of Continuous, a seminar based approach to reviewing has been applied. In practicethis has been carried out as discussion sessions after each task has been implemented. The following aresome examples of reviewed tasks and sprint meeting topics.

5.1 Application layer/visualization interface architecture

5.1.1 Description

To make visualizations as interactive and easily developed as possible, a clean, fast interface betweenvisualization logic, user input and user feedback is required.

9

5.1.2 Misleading assumptions

The original architecture draft was too much based on the assumption that AngularJS’s “magic” two-waydata binding[12] would be able to subscribe to changes in visualization variables and objects (and updatethe view accordingly). It turns out this is restricted to models defined inside the Angular container. Sincevisualizations were written outside of AngularJS, using Continuous’s own libraries, this would not havebeen an option.

5.1.3 Roll your own

Instead of relying on Angular to watch variables, an explicit visualization state was introduced alongwith a custom observer utility[13]. Both the visualization and the application layer could then observeand update the state without relying on each other. The illustration below depicts a sequence diagramshowing interaction with the visualization state.

Open Visualization ViewCameraSceneStateAngularJS directiveDOM

new Scene(...)new Scene(...)

User input mouseDrag()DOMEvent() setMouseState()

notifyObservers()

publish(’MouseState’)rotateCamera()

primitives({ x: x, y: y, z: z})

allPrimitives()

startRendering()

render()

allPrimitives()

render()

State interaction – sequence diagram

requestAnimationFrame()

Figure 3: State interaction sequence diagram

5.2 Transitions

5.2.1 Description

One of the goals for the course project involved to investigate how to implement step-by-step transitionsinto Continuous’s visualizations. A main consideration has been about where this functionality shouldbe implemented, i.e. what part of the system that should be responsible for the transitions betweenscene states. It turns out that this is a difficult problem to solve considering that many different partsof the system are involved in a transition.Typically it is initiated by some user input and then requiressome kind of action by the MathGL engine. On top of that, transitions with animations should be highlycustomizable in visualizations.

10

5.2.2 What to expect from a transition API

Below are illustrations of how transitions between visualization stages could be handled.

Figure 4: Transitions between visualization stages

In Figure 4, entities A, B and C are stages, or states, in a visualization. The first case depicts alinear sequence where a user can only progress in a predefined manner during a visualization. This maybe intuitive in many cases and may also bring a dimension of consistency throughout the visualizations.It would also be the most straightforward to implement. On the other extreme (case 3) is a layout wherethe user has maximum freedom to navigate throughout the visualization. On top of this, the transitionsthemselves (illustrated as arrows above) could be more complex. For example, a transition could be acomposite of several “keyframed” animations.

An API which supports all of these features and that is simple to use would be optimal for developingvisualizations.

5.2.3 An agile approach

After discussing what should be the responsibilities of the different packages, the team decided that thefunctionality to step around in a visualization is too specific to be implemented in the MathGL library.Some visualizations may benefit from a completely different interaction pattern, which means that im-plementing a centralized API for transitions would risk being too constricting.

A decision was made to try an approach where a visualization implements transition functionality byitself, without the support from additional abstraction layers. This resulted in some code repetition, butgave the team a draft of the functionality. When the system is more mature some time in the future, itis possible that this will be rethought and refactored.

5.3 Module dependency management

5.3.1 Description

As already mentioned, JavaScript does not have any module system. This needs to be implementedexplicitly.

5.3.2 Review

Continuous groups several modules together as packages. In the original implementation, modules insidea package had to be aware of their complete path to include files in the same directory.

5.3.3 New convention

The solution was to reconfigure every existing module so that it takes advantage of RequireJS’s relativepath functionality. This was the largest refactor in the project seeing to the number of lines of codeaffected.

11

6 Accomplishments

An application layer has been created using AngularJS. It offers basic functionality for navigating be-tween visualizations and provides GUI components (css rules and AngularJS directives) that can be usedto create visualizations. The app is able to fetch the requested visualization by dynamically loading theadequate JavaScript package and present its contents to the user.

Before the course project no distinction between MathGL expressions and primitives had been made.After introducing this separation, it was possible to use an open source animation library, TweenJS[14],on top of MathGL, instead of implementing the whole functionality inside the package itself. This sat-isfies the original goal to achieve real time animation of mathematical properties.

Support for drawing both curves and vector arrows were added to MathGL. In addition to this, theshading of all available entities was improved to increase the feeling of depth in the scenes.

Some visualization content has also been created, mostly for testing and demo purposes. The goalto create 5-10 deliverable visualizations has not yet been reached as of January 2014. One motivation forthis is that the visualization interface to the application layer needs to become more more stable. Main-taining five production quality visualizations while redesigning the API would imply a disproportionateamount of work. Another reason that this was not prioritized is the fact that the client does not requirethis content until the next course start in fall 2014.

However, with the changes made during this fall, Continuous is indeed a usable visualization frame-work implementing a powerful, customizable 3D engine that can be used for rapid development of demovisualizations.

12

References

[1] Kronos Group / Jackson, D. (2013) WebGL Specification, [Online], Available:http://www.khronos.org/registry/webgl/specs/latest/1.0, [13 jan 2014]

[2] Google AngularJS Team (2013) AngularJS, [Online], Available: http://angularjs.org/ [13 jan 2014]

[3] Burke, J. / Open Source (2014) RequireJS, [Online], Available: http://requirejs.org/ [13 jan 2014]

[4] Zakas, N. (2012) Maintainable JavaScript, [Online], Available:http://chimera.labs.oreilly.com/books/1234000001640/ch01.html [13 jan 2014]

[5] Axelsson, E. (2013) Classes in JavaScript?, [Online], Available:http://emilaxelsson.se/posts/2013-07-15-Classes-in-JavaScript [13 jan 2014]

[6] MathJax Consortium (2013) MathJax, [Online], Available: http://www.mathjax.org/ [13 jan 2014]

[7] Pivotal Labs (2014) Jasmine, [Online], Available: http://pivotal.github.io/jasmine/ [13 jan 2014]

[8] Open Source (2014) Karma, [Online], Available: http://karma-runner.github.io/0.10/index.html [13jan 2014]

[9] Joyent, Inc. (2014) NodeJS, [Online], Available: http://nodejs.org/ [13 jan 2014]

[10] Joyent, Inc. / Nodejitsu, inc. (2014) Node Package Manager, [Online], Available:https://npmjs.org/ [13 jan 2014]

[11] Twitter, Inc (2014) Bower, [Online], Available: http://bower.io/ [13 jan 2014]

[12] Google AngularJS Team (2012) Data Binding in Angular Templates, [Online],http://docs.angularjs.org/guide/databinding [13 jan 2014]

[13] Stefanov, S. (2010) JavaScript Patterns, Sebastopol, California: O’Reilly Media: 171-174.

[14] Create JS (2014) TweenJS, [Online], Available: http://www.createjs.com/#!/TweenJS [13 jan2014]

13