THIRD YEAR PROJECT

A Notebook-Style SQL IDE

James Peach

supervised byAlvaro. A. A. FERNANDES

3rd May 2016

Abstract

Developers require an understanding of the task at hand in order to do their job. Sometimesthis information comes from documentation, other times it comes from code and comments.Having separate code and documentation means developers have to read and update two sets ofinformation. This duplication of effort can lead to mistakes, especially when switching betweencode and notes. The goal of the project is to create a tool in which both the code and thedocumentation can coexist and solve some of the problems that can occur when using existingsolutions.

Acknowledgements

This project was developed at the University of Manchester, I would like to thank my tutorAlvaro for his help and support throughout all of these years and for his patience through thelengthy discussions on those occasions where my understanding needed expanding.

Thanks also goes to my patient editors, my dad Anthony and my friend George.

Contents

1 Introduction 31.1 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Overview of the report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Background 52.1 Analysis of existing solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Microsoft SQL Server Management Studio . . . . . . . . . . . . . . . . . . 62.1.2 MySQL Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.3 phpMyAdmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.1.4 IPython / Jupyter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3 Problem summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Requirements 143.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2 Use cases of the system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.1 Priority of requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Design 184.1 Structure of the information in the solution . . . . . . . . . . . . . . . . . . . . . 18

4.1.1 List of files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.1.2 Folder structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.3 Simplified folder structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.4 Tagged files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.1.5 Choice of file organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2 Search capability in the system . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2.1 Simple text search / serial scanning . . . . . . . . . . . . . . . . . . . . . 234.2.2 Full text index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2.3 Extraction of keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.2.4 Reasons for selecting simple text search . . . . . . . . . . . . . . . . . . . 24

4.3 Type of user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.3.1 Native solution for operating system . . . . . . . . . . . . . . . . . . . . . 254.3.2 Mobile solution for Android / IOS . . . . . . . . . . . . . . . . . . . . . . 254.3.3 Browser based solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3.4 Reason for selecting browser . . . . . . . . . . . . . . . . . . . . . . . . . . 264.3.5 JavaScript MVC library React.js . . . . . . . . . . . . . . . . . . . . . . . 264.3.6 Future React Native . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

1

4.4 Choice of interface - Notebook metaphor . . . . . . . . . . . . . . . . . . . . . . . 274.5 Detachment of the SQL interface through custom web API . . . . . . . . . . . . 27

5 Implementation 295.1 Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1.1 Design the API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.2 JavaScript application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.2.1 React.js development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.2.2 Storage of data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.2.3 Data store interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.2.4 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6 Results 346.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.2 Binder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.2.1 Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.2.2 Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.2.3 Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.3 Workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.3.1 Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.3.2 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.3.3 Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.3.4 Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386.3.5 Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

7 Evaluation and Future developments 407.1 Testing the project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407.3 Future developments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7.3.1 Multiple database engines . . . . . . . . . . . . . . . . . . . . . . . . . . . 417.3.2 Query explanation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417.3.3 Different result formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417.3.4 Resizing windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

8 Conclusion 42

2

Chapter 1

Introduction

Developers use documentation to aid their understanding of code, however the documentationis often constructed and viewed on paper or in a web browser. An example of this for Javaapplications is Java-doc[12]. While the use of a documentation tool provides a good overview ofthe code, it shouldn’t exist in isolation. Developers can not rely on the documentation alone, theymust also have an understanding of the other components of the system and their interaction.

This is also true for database applications. Database applications are often the backing storefor the data of the system and also provide a centre for the business logic for the application.They are often at the centre of large applications and as a result they can be complicated. Thisis because databases are designed to store and validate large amounts of data. They also providemany useful mechanisms for integrating with a large number of other technologies.

It is therefore important that the developers that develop and manage these applications knowexactly the effects of the code and what their changes mean in terms of the system as a whole.

1.1 GoalThe project’s goals are to create an application that will help database developers document andcode in a more consistent and interactive manner. The result should try to accomplish this withinone tool, both for coding, and for documenting.

The project will cover methods for identifying the problems with existing applications, andformalising them. The project then aims to provide an evaluation of the different approaches tosolving the problems along with reasons for any choices made.

1.2 UsersIn order to understand the application we first need to understand the users of the application.These users are developers. The developer’s days could consist of many different types of tasks,including developing new applications, new features, and maintaining old applications and services.These are just a few of the most common tasks required.

This poses problems when creating software for these developers to use; while they requireplaces to document code and other items, they do not do so with a common structure. The toolsthey use must support their individual ways of working. However they still need ways of helpingthem to manage the information.

3

Creating an application for this purpose will require the consideration of many problems thatexisting applications have attempted to tackle and their success.

One example of the type of problems an organisation application would look to solve is this:A developer is working on more than one application and is responsible for supporting olderapplications. The developer receives notice that a problem exists with a project he worked onpreviously. His current progress needs to be noted so he can continue at a later date. Thedeveloper then must find details about the problem. The process of switching projects and findingthe required information is a problem this project aims to solve.

The problem above is just one problem and there are many more that would need to beidentified. This report details how they were found and their solutions designed and built.

1.3 Overview of the reportThis report explains how the final solution was developed from an idea into the final product. Itdoes so with some guidance from standard software development techniques. First, some problemsare identified, then a formal set of requirements is derived. These requirements guide the designof the application and after the application is built the requirements are again used to verify thatthe end product does indeed solve the original problems identified.

The problems that the application hopes to address will be a collection of things that occurin every day life as a developer and other problems identified with existing tools available.

4

Chapter 2

Background

In this chapter the reason for a documentation tool is outlined and some existing solutions aredescribed. Each existing solution will be analysed for its strengths and weaknesses.

If code is written without comments or detail about what is to be achieved, it is possible thatwhen the code is read again in the future, the original intent will have been lost.

There are many different ways to document code ranging from completely offline to completelydigital and many different methods for integrating code. The most simple offline approachesconsist of simple notepad pages with notes and diagrams. This offers a totally free-form approachto note taking for, as with pen and paper, there is no limit to what you can make notes about.Tables diagrams and hand written pseudo code can be easily drawn and annotated. While this issuitable for some circumstances it is not for others. For example, if you had an email you wantedto include in your notes it would have to be printed and filed in the notes. This leads to problemsof printing and loosing the loose pages.

One solution for this problem is use of a electronic or digital note taking application. Ever-note[3], is a popular choice for notes and offers a wide range of platforms for note creation,however, it is not designed with code documentation specifically in mind. While it is a very goodsolution for taking notes, as is evident in the number of usersii, the lack of specific features aimedat developers e.g. version control makes it difficult to use for documentation.

The above solutions are not tailored to suit the specific task of making notes for SQLdevelopers. Tools used by developers can both develop new code and help document it for futurereaders. Commenting code is often the closest notes get to the code. Well commented code canhelp developers to both remember the code they wrote in the past and understand new code.Comments provide an excellent opportunity to pass details of previous attempts from programmerto programmer.

Comments on code will often not last the test of time as they do not force you to updateyour note when the code they refer to changes. For example, over time the commented functionmight offer more options or deviate from its original purpose. Unless the developer remembers toupdate the comment then, over time, this could lead to confusion.

2.1 Analysis of existing solutionsThe different applications vary with programming language and operating system. They eachhave positives and negatives.

iiThe current ranking of Evernote by Alexa is 397 http://www.alexa.com/siteinfo/evernote.com

5

Figure 2.1: SQL Server Management Studio, Microsoft: Main workspace with open queries andresults

Each is analysed below with a brief overview of the functionality provided and details onspecific positives and negatives. After the analysis of the existing solutions, the problems will besummarised before requirements are set out.

2.1.1 Microsoft SQL Server Management StudioSee fig 2.1 for a screenshot.Product URL[10] https://msdn.microsoft.com/en-us/library/hh213248.aspx

The official IDE for Microsoft SQL Server has been available for many years. It has manyfeatures aimed at the SQL developer. The ability to open multiple connections to databasesand have many open files in an IDE powered with the Microsoft Visual Studio Shell[11]. Theapplication offers no management of files within the tool, it does however, offer the ability toopen files from the filesystem. The tool allows for the execution of queries and the result viewingpane shows a table containing the output. The results in the result pane can not be stored in theapplication or with the query for later review. If this is a requirement for the user it must bedone manually with the export function.

As with many database servers, the functions and procedures are stored within the databasesso any files on the local system might not be in sync with the ones on the server. The applicationis a native Windows application and offers no alternatives for other operating systems. Developershave the ability to connect via TCP, Shared memory, and named pipes. This allows for connections

6

Figure 2.2: MySql Workbench, Oracle: Home screen

to be made from anywhere with a suitably open internet connection however it poses manyproblems when on a restricted network and limits users to use Microsoft’s own operating systemas the application is for Windows only.

‘Windows 10, Windows 8, Windows 8.1, Windows 7 (SP1), Windows Server 2012 (64-bit),Windows Server 2012 R2 (64-bit), Windows Server 2008 R2 (64-bit)’

From SSMS 2016 preview download page [9].

2.1.2 MySQL WorkbenchSee fig 2.2 for a screenshot.Product URL[14] https://www.mysql.com/products/workbench/

The MySQL Workbench offers a multi-platform solution for accessing a MySql database. Thetool also offers a model management tool (fig 2.3) for designing a logical model of the databaseentities and relations. This provides a way to easily view a high level overview and make usefulannotations that go above and beyond simple comments written separately. For more informationOracle have published a paper detailing the creation of the tool[13].

The Workbench also offers multi-platform capability. Providing more ways for the users toaccess the application, this helps integrate a tool into the workflow of the developer. Having toswitch between operating systems, when your database management software is not available onthe same operating system as your application development environment, can be very disruptiveto a development workflow. The development of this project should aim to support commonplatforms.

7

Figure 2.3: MySql Workbench, Oracle: Visual Database Design feature

8

Figure 2.4: phpMyAdmin: home page

9

Figure 2.5: IPython Notebook, example notebook

2.1.3 phpMyAdminSee fig 2.4 for a screenshot.Product URL[2] https://www.phpmyadmin.net/

The alternative to the official MySqlWorkbench is an open source web based solution for easyaccess to the database from anywhere you have an internet connection. phpMyAdmin is a PHPweb application and needs a hosting server to provide access. The application, once running, hasa secure login system and the ability to view and edit data in the system.

However the tool offers little in the way of editing for scripts and database code. Bulkmanipulation of data is not offered in the application but instead through the export of multipledifferent file types.

The application also analyses the foreign keys in the database and provides access to thereferenced rows in the related tables. This feature can make viewing the data in the system moreintuitive as related data need not be separately queried for.

Unlike the MySql Workbench, there is no designer for models and all changes are done to thedatabase “live”. Additionally there is no design and publish as offered in MySql workbench.

2.1.4 IPython / JupyterSee fig 2.5 for a screenshot.Product URL[15] http://ipython.org/

10

Figure 2.6: Markdown: example markdown source (left) and output (right)

IPython, now Jupyter, differs from other solutions evaluated above as it is not a SQL IDEand, as such, it doesn’t show any specific features for SQL code in particular, however, theintegration between the code and the text in the editor is done in an intuative and simple tounderstand way.

IPython provides an interactive browser based coding tool, the “notebook”. The notebookprovides the ability to create cells for code and text. These code cells can then be executed andresults are shown below the code. This provides a visual relationship between the code and itsoutput. The text cells are formatted with Markdown[17].

Markdown (fig 2.6) is a simple written markup language for textual documents. Markdownprovides simple ways to create headings and lists paragraphs while balancing this with simpleeasy to read minimal formatting.

The mix of executable code within the text notes provides a unique experience: The ability tosee and tweak code and have a well presented explanation of the code.

Interactive code and results as done in an IPython notebook provide a quick way to see theresults of the code. This allows and promotes the testing and exploration of the code and canhelp the developer to understand exactly what effects each part of the code has on the end result.This is important because developers who understand the impact of the existing code and theirchanges to it will create fewer bugs in code and are more productive.

The notebooks reside on files on the local disk of the system, much like any other file. Assuch the organisation of the files is left up to you, the creator, to file them in folders etc. Thiscan be a problem for long term users of the application as, while the individual files might beorganised, if the collection of files is haphazard then the organisation problem has just moved toanother part of the process.

11

2.2 Problems

Problem 1. Keeping notes of important things

As developers work on their projects and as these projects evolve there becomes an increasingnumber of things that need to be understood in order to develop / maintain the project. Theproblem is to provide an easy flexible way to make notes on different topics and allow access tothe notes in an organised way.

Problem 2. Notes are only useful when they are read

The notes / code stored need to be accessible for developers, they are read more times thanthey are modified. This shows the importance of the time spent documenting the code when it isfirst written.

The notes as discussed do not have an implicit structure and so a helpful search is difficult tocreate. Most solutions just offer full text search of the data.

The notes might have had several revisions over time and might need the information accessiblefrom the past.

Problem 3. Notes that include code are often not updated

The notes, in some note taking applications that store code, are often not in an executableformat. This code will have dependencies as code does not exist in isolation. For example thefunctions used or the tables referenced may be modified. If the code in the note cannot be directlyexecuted, these changed in the context can create bugs in the code that wont be immediatelyvisible and could mislead the reader.

This is a problem because the code is only useful in a note when it is up to date and bug free,often at the time of writing it is correct but as the system changes the code can become out ofdate.

The problem is how to ensure or help the user to keep this code up to date within the note.

Problem 4. Data always changing

The data in database systems is always changing. When the system was written the datamight have looked significantly different to what it is now. This makes things hard to compare astime goes on.

The problem is how to ensure that, even if the underlying data is changed, the note and codewithin is still useful for other developers in the future.

Problem 5. System access

Developers need easy access to the information and the database from in or out of theoffice. Current solutions for IDEs are often system specific and don’t offer good cross platformcompatibility.

The problem is providing access to the data and system from whatever system, and whereverthe developer is in a secure way.

Problem 6. Cross referencing

When writing documents, often it is required to provide context. This is done by referring toother parts of the same or different document. Providing a solution to this problem will benefitboth the readers and writers and help communicate the information.

12

2.3 Problem summaryThe problems identified above fall into different categories:

• Organisation of notes• SQL specific problems• Searching notes

Each of the above categories of problems could be tackled in many different ways. The nextstage in the development of a complete solution is to identify some concrete requirements anduse cases for the application and discuss the different approaches available. Each approach hasdownsides, these need to be properly analysed and evaluated to provide a solution.

13

Chapter 3

Requirements

The existing solutions have provided a basis for identifying the potential problems the systemmust overcome. Along with other sources and other base requirements a set of more formalrequirements are listed below.

3.1 RequirementsThe requirements will be detailed below, along with a brief reason for the importance.

Requirement 1. Storage of files

The application must store notes about the project in various separate “files” within the system.The files can take on any form however it is required that they are separate entities.

The files must exist in separate items so that each can have a well defined topic. This will aidthe user in placing notes in the correct locations.

Requirement 2. Types of files

The “files” stored within the system must be able to store code and also notes in a formateasily read.

For example, these files should have the ability to contain syntax highlighted code and alsoheadings and lists.

Requirement 3. Accessibility

The application should be easily accessible from multiple operating systems.The targeted operating systems should include Windows, Popular flavors of Linux, and Mac

OSX.

Requirement 4. Results

The application should have the ability to view the results of queries executed on the systemin table form.

This is the de-facto representation of the results from a SQL query, although it may be possibleto view the results as plain text, the requirement is to display them in tabular form.

14

Requirement 5. Result display (Optional)

The ability to detect the type of result and view it in a more suitable form. The more suitableform could be anything from a graph to folder structure to a specific viewer for XML documents.

This could be implemented in a way that automatically selects the best result format for theresults. However, this could also be completed with a manual selection of the result type thatchanges the display format.

Requirement 6. File organisation

The application should have a mechanism for organising related files in a hierarchy. Files thatare about a part of the system should be stored in the same place in the system.

This requirement is non specific so as to not restrict the choice of possible implementations.The need to organise files is an old requirement. Many existing systems both specifically relatedto code and in general have mechanisms in place for this.

Requirement 7. Versioning

The application should save the previous versions of the files stored within. These versionsshould allow editing and saving over newer versions if needed.

Developers often have to revise code and often new features are added to existing systems.The ability to see previous versions of code is necessary in order to provide adequate context todevelopers.

Requirement 8. Editing multiple files

The application should allow for multiple files to be open at once and viewed at the sametime. This can be done in a free sized window mode or windows listed vertically or horizontally.

The ability to work on multiple files at the same time will help the developer to rememberthe details of the different tasks without the possibility to forget one entirely.

Requirement 9. File searching

The application should allow for searching for strings in files.When searching through documents the ability to find a single occurrence of a word or phrase

in many documents can drastically decrease the time needed to continue working. When tryingto complete an action, the time taken to find a file needed, determines the chance of forgettingthe task.

Requirement 10. Viewing search matches (Optional)

The ability to view, in each of the search results, where the search phrase was found. And theability to open the file from the search result.

When searching, the context around the match is often very important and can help identifythe right instance of the phrase. Because when searching, in most cases the searcher is onlyinterested in one location of the phrase.

Requirement 11. Result comparison

15

The application should allow for the easy comparison of results. Historic results of the queriesshould be shown as a diffior side by side with newly executed results.

Within the database, the data can change frequently. The ability to save previous versionsof the results of the queries and then compare them with new versions can have many differentuses. For example a query might not be as performant as required. The developer will need somemethod to verify that the results from before the changes is the same as the optimised version.

3.2 Use cases of the systemThe use cases of the system will detail how the system is intended to be used. The specific andimportant use cases will give context to the requirements.

The primary users of the system, as discussed, are the developers of the projects themselves.The uses will be performing some tasks more than others and some will have more of an impacton the use of the application than others. The important use cases are captured below to aiddevelopment and evaluation.

Usecase 1.

Developer wishes to document information about a development.The correct file must be found in an existing project and amended with details of the new

development.

Usecase 2.

Developer needs to view all documents pertaining to a project in the system.The collection of files for a project must be identified within the application.

Usecase 3.

Developer needs to find reference to a particular item within the system but is unfamiliarwith the specific location or other detail

Usecase 4.

Developer has to find specific details of a system previously worked on in order to maintain it.

Usecase 5.

Developer wants to view and compare previous versions of some code within the database

Usecase 6.

Developer wants to view the versions of files within the notebook.The different states of a piece of code (query) in the system need to be identified and the

saved results compared.

Usecase 7.

The developer wants to find the places a particular entity is used within the system to betterunderstand how the changes planned could effect the system as a whole. ii

iSee https://en.wikipedia.org/wiki/Diff_utility for an explanation of diffiiThis is known as impact analysis

16

3.2.1 Priority of requirementsSome of the above requirements and use cases are more important than others. For exampleproviding a method for finding files in the system will have to come after the ability to create files.The priority of the requirements and use cases will be determined in the development process.

17

Chapter 4

Design

The design of the application will draw from the above requirements and the associated use casesto form a final application. There are many decisions to be made when designing an applicationand each decision needs to be solved in the best way possible given the conditions, availablesolutions and development time.

In this chapter some design problems are listed and a discussion is provided for each on aselection of solutions. Each candidate solution is evaluated and compared to other solutions, anda summary of the chosen approach is given in conclusion.

4.1 Structure of the information in the solutionThe application will store notes and code (files) created by the user, however there are manydifferent ways to store these files. Here are a few of the different ways to store this informationwith some positive and negatives of each approach.

4.1.1 List of filesThe application could store the notes as a list of simple files in the system. Each file would have aname and a collection of other attributes: date created, date modified. This method is the mostsimple of solutions discussed here however, it does rely on the user to correctly name the fileswith discipline. If this is done correctly then the list of files solution could be viable.

For example, the following is an idea of how this might look.

- Project A - Overview - Project summary- Project A - Overview - Change log- Project A - Users - User login module- Project A - Users - User login module version 2- Project B - Overview - Project summary- ...

Each line in the above example is a file and each has been named with a logical structure of

PROJECT − CATEGORY −NAME

For many reasons this is not an ideal way to view files for a single section of a system. Typicallydevelopers work with a single project at once and within that project only a limited subset. This

18

means when the developer has to navigate to a particular file in the system they have to find justone file in what can be a large list.

As a positive consequence of choosing a simple list, when the developer needs to access filesacross multiple projects, they can see the entire list of files without the need to change betweenfolders. This can be important because often, when performing complicated tasks the smallest ofinterruptions, like searching folders, can cause cause the user to make mistakes.

4.1.2 Folder structureThere are already existing methods for storing files into folders or directories. Most mainstreamoperating systems use a hierarchy of foldersi to contain files and more folders. This acts like atree, each leaf is a file and each subtree is a folder.

This approach still offers the users free reign over the organisation and naming of each file inthe system, however, it also provides the ability to focus on single parts of the tree at once.

- Project A/- Overview/

- Project summary- Change log

- Users/- User login module- User login module version 2

- Project B/- Overview/

- Project summary

In the example above the items ending with / are the folders (subtrees) and the other itemsare the files (leaf nodes).

This organisation into folders can take time to complete and can be done in many differentways. Within each project, unless managed correctly, there could exist different ways of creating/ naming the folders. This problem of uniformity crops up in many places within the topic oforganisation and in general, the more uniform the structure, the less the user has to rememberfor each case and less effort to understand it.

There is another problem with a simple tree folder structure, each file in the folder tree canonly exist in one place at once.ii Some files could belong in multiple places at once. This causesambiguity and can make finding these files take longer. Each ambiguously located file that needsto be found needs to be searched for in (worst case) all the locations it could be in.

Both of the two above problems are lessened by putting sensible limits on the depth of thefolder structure. The reason for this is discussed below.

4.1.3 Simplified folder structureIn a simplified folder structure, there are a limited number of levels that can exist. If viewed as atree it would have limited depth and contains leaf nodes (here notes) at the bottom level of thetree.

iWindows has Explorer, and OSX has FinderiiThis can however be solved, as with the UNIX file system for example. Symbolic links can allow for files to

exist in multiple places at once.

19

This simplified structure can help make the choice of folders at each level more apparent forthe user. They have limited choice of where to place folders and files and as such, the ambiguityproblems of a full folder structure are lessened.

This technique also implicitly limits the user to a set number of levels. This, although limiting,reduces the number of cases where files have more than one obvious location.

4.1.4 Tagged filesIn a tagged file organisational system, files are not placed in folders but instead have each anassociated set of “tags”. Each of these tags has a name and can be applied to many files.

For example, you might have the following set of files and their tags:

- Project summary {Project A, overview}- User login module {Project A, Users}- Overview {Project A, overview}- Project summary {Project B, overview}

The user can then find subsets of files they are interested in by filtering for the items thathave the tags specified:

Filter: file has all {Project A, overview}Result:- Project summary {Project A, overview}- Overview {Project A, overview}

Filter: file has overviewResult:- Project summary {Project A, overview}- Overview {Project A, overview}- Project summary {Project B, overview}

N.B. The folder structure as discussed above 4.1.2 can also be represented with a tagged listof files. This can be achieved by adding a single tag to each file with the path of the folder thatcontains it. However the tagging system allows for more flexibility by allowing multiple tags toexist on the same file.

For some applications, a tagged file system can be both faster and more simple to understandfor the users. The paper by Bergman, Ofer et. al.[1] has a detailed analysis of this technique.

4.1.5 Choice of file organisationThe simplified folder structure was chosen because of the balance between the flexible organisationof the tagging system and the simplistic file list. The simplified folder structure proved to besimple to implement and provides the required functionality.

Fig 4.1 shows the implemented simple folder structure. The names given to the levels are asfollows:

• Binder: top level container

• Tab: second level container

• Page: items in the Binder

Fig 4.2 shows how the second level container is displayed.

20

(a) (b)

Figure 4.1: Binder, top level container for tabs. fig 4.1a and 4.1b show empty and full bindersrespectively

21

(a)

(b)

Figure 4.2: Tabs, the second level container. fig 4.2a and 4.2b show an empty and full tabrespectively. This is shown when a tab is selected, the pages are listed with the ability to edit thelist, and add new items.

22

4.2 Search capability in the systemThe requirements gathering process clearly identified in multiple places the need for the systemto provide a quick and simple search function.

There are multiple ways to provide search functionality within a document managementsystem, some of which are suitable for the application and some are not. The below is a summaryof a few of the options and an evaluation of each.

The search feature should take the users query and provide access to the matching files inthe system. This part of the searching experience will be the same for all the discussed methods.However, the parts that differ in the compared methods are:

• the format of the users query

• the searching method

• the time taken to perform the search

• the presentation of the results

4.2.1 Simple text search / serial scanningThe simplest method for searching in a collection of documents is takes a simple query from theuser (the search term), and searches for the occurrences of the term in each file. Each matchresults in an item in the result list displaying the name of the file, and the position within thedocument.

For example:

search term: testresults:- File A, line 13, chars 34-38

- ... the users will then report on test ing ...- File A, line 13, chars 10-13

- Chapter 2: Test ing ...

This technique is simple and for small amounts of files and content is fast to compute. However,due to the fact that the algorithm is loosely linear in the number of files this technique would beimpractical for large numbers of files. This technique, called “serial scanning”i, is only typicallyused for smaller amounts of text due to this problem.

‘ However, when the number of documents to search is potentially large, or the quantity ofsearch queries to perform is substantial, the problem of full-text search is often divided into twotasks: indexing and searching. ’[16]

This technique that Wikipedia refers to is discussed below.

4.2.2 Full text indexWhen the simple method of searching through all the files becomes too slow, one alternative is tocreate a concordance ii. This is a table of words in a publication (a note) and where those wordsappear within the document. By using this concordance in place of searching the text directly,

ihttps://en.wikipedia.org/wiki/Full_text_search#Indexinghas more details on this.iihttps://en.wikipedia.org/wiki/Concordance_(publishing) for more information

23

the application is able to search a smaller amount of data to find the results and hence speed upthe search process.

This requires that there is a pre-processing step before a search can be completed. This needsto be recalculated each time a user changes a document so that all subsequent queries can findthe new content.

This is the trade off with the more complex methods for searching. This method requires theindex to be built / rebuilt before any searching can take place. However this can be done “offline”and cached for later use.

4.2.3 Extraction of keywordsAnother method of searching the documents is by analysis of keywords. Indexing a select fewwords per note instead of all the words as in 4.2.2 means smaller indexes and faster searches.Either a list of keywords is created and left static or, machine learning algorithms can learn whichwords are important within the page and index only those words.

This is however only applicable when the user’s search terms can be limited as such. Thisis because if the user searches for a word that is contained within a file in the application, itwill only be found if the word is in the keywords list. In the case of a note taking application, asearch method that can fail to find a word that exists in the document is of little use. Howeverindexes of the popular search terms can help to find preliminary results for a query, or providecaches of common queries.

4.2.4 Reasons for selecting simple text searchWhile many of the different search methods focus on the performance and accuracy, the mostbasic search technique, Simple text search 4.2.1 can offer the features required by most users ofthe application. It does this while also remaining simple to implement. This implementationcould always be replaced or enhanced as a future development of the project.

4.3 Type of user interfaceThe different types of user interface that designers can choose from when designing applicationscan be categorised into a few main categories:

• Command line

• GUI / WIMPS (windows, icons, menus, and pointers)

For visualising text, popular command line applications for editing text like Vimi or GNUEmacsii do exist , however, the richer environment of GUI applications are predominately preferredwith their ability to customise fonts and other attributes of the layout and style. They alsoprovide a better experience for users with the use of menus and visual reminders on how toperform actions. These can provide a more simple to use application than an alternate commandline program with many shortcuts to memorise.

There are many different types of GUI application that can be built and an important decisionthat needs to be made before selecting the layout of the application is what platform to build theapplication on.

ihttp://www.vim.org/iihttps://www.gnu.or/software/emacs/

24

4.3.1 Native solution for operating systemThe first option is to develop a “desktop first” application. This would mean developing anapplication for a chosen operating system. This would require selecting one of the nativewindowing APIs for the operating system. Some of these APIs are cross platform enabledi,others are proprietary, more integrated and tied down to the selected operating system. Apple’swindowing API Cocoaii is an example of this.

One advantage of using the manufacturer built API is in the level of support from themanufacturer that is available. However a downside of this is that often proprietary libraries areclosed source. These closed source API’s impose a limitation towards changing and tweaking thesystem.

As one of the requirements of the project is that the system should be accessible to allplatforms iii the proprietary method is not an option for a time constrained development like this.In order to complete a cross platform version using operating system specific (non cross platform)APIs, Multiple versions would have to be created, one for each different API.

4.3.2 Mobile solution for Android / IOSThe production of a mobile application for either the Android or IOS operating systems wouldeither require two versions of the application, or the use of tools like Xamarin.

Xamerin’s goals are as follows:

"Deliver native Android, IOS, and Windows apps, using existing skills,teams, and code."

[18]Tools like this allow for applications to be built for a variety of mobile platforms with a single

code base. In the case of Xamerin, in C#. The ability to “write once run anywhere” is a bigselling point for these tools. However it would still restrict users into using mobile only to accessthe application.

4.3.3 Browser based solutionWith modern advances in browser technology it has become more feasible to create full desktopreplacement applications as website-applications. These websites are truly cross platform, theycan be viewed on any platform with access to a web browser. Desktop OS or mobile OS’s haveaccess to many of the most recent browsers.

• Chrome (Windows, Mac OSX, IOS, Android)

• Safari (Mac OSX, IOS, Windows)

• Opera (Windows, Mac OSX, IOS {opera-mini}, Android {opera-mini})

• Firefox (Windows, Mac OSX, IOS, Android)

There are many different libraries to help develop applications with JavaScript. However it isstill possible to create more traditional client-server applications and have a simple lightweightJavaScript free front end. These applications tend to be slower in terms of latency between user

ifor example, see “qt” for a popular choice. http://www.qt.io/iihttps://en.wikipedia.org/wiki/Cocoa_(API)

iii see 3 for the requirement

25

action and application response because of their need to communicate every action with a serverover HTTP.

An alternative to the more traditional client-server architecture is the now popular “singlepage JavaScript application” or SPA. This blurs the lines between the user perceived differencesof the desktop and browser experience.

An SPA is a single web page that functions like a native desktop application. These applicationshave all the features of a desktop application, they can make use of windows, buttons, andanimations etc.

External data is gathered in background HTTP calls (called Ajax requests) and does notnecessitate a full page reload. The absence of these full reloads and the flash of white as the pageloads give the user a much better experience.

For more information about the use of Ajax replacing client server applications refer to thepaper “Single Page Web Applications” by Michael S. Mikowski and Josh C. Powell[5].

4.3.4 Reason for selecting browserFor the application being built the choice of platform is between a cross platform library for anative desktop application and a web-based solution. For reasons including: experience withtechnology and programming languages, developing for the browser was selected as the platform.

The browser application will be accessible from any platform and device and provides an easyway to update the application in the future.

There are many different libraries that can help when building a JavaScript application inthe browser. The libraries have some things in common and other unique points that set themapart from each other. Most of the libraries cover the standard principles of MVC “Model ViewController” or some similar variant. i

4.3.5 JavaScript MVC library React.jsIn this section, the choice of JavaScript library React.js will be explained along with a briefdescription of how it works in order to help understanding.

React.js is a fairly new open source library from Facebook.

A JAVASCRIPT LIBRARY FOR BUILDING USER INTERFACES

[4]React.js brings the notions of pure functions to the problem of creating and updating views.

In React.js the headache of updating the view when something happens in the application ishandled automatically. This is accomplished by having the view hierarchy be a result of a purefunction of the application’s current state. This has the important consequence of removing theneed for the developer to detail how an action should update the UI. Instead, the developer needsonly to to update the state and React.js will work out what changes are required by calculatingthe difference in the old and new view hierarchies.

4.3.6 Future React NativeReact.js has a new related project created by the same team called “React Native”ii. ReactNative takes the principles of React.js and allows the same React.js code, with slight tweaks, torun as a native application on both IOS and Android.

i https://en.wikipedia.org/wiki/List of JavaScript libraries has a community populated list of libraries.iihttps://facebook.github.io/react-native/ for more information

26

This would provide a simple way to get the application onto mobile operating systems in anative environment. With a native environment the users would be able to access the applicationas they would any other app on the device and not through the browser.

4.4 Choice of interface - Notebook metaphorThe interface of any application needs to be simple and easy to understand. The more complicatedthe interface the more brainpower needs to be dedicated to using it. The most successful userinterfaces provide simple intuitive ways for users to perform the actions they require.

‘Metaphors are the fundamental concepts, terms, and images by which information is easilyrecognised, understood, and remembered.’

Metaphor Design for User Interfaces, Marcus, Aaron[7]The metaphor chosen for the application is the notebook. A physical notebook has pages,

tabs and other concepts. These are easily understood by anyone who knows what a notebook is.We can extend this notion of a notebook with concepts from the wider world of physical printmedia with indexes and contents pages. See fig 4.3 for a pictorial diagram.

The result of using a metaphor to guide the design of the application should be an intuitiveand simple interface. It should lead to a design that users will be able to explore with little to nointervention. Complicated non intuitive interfaces however, can be quickly judged by users andlead to the failure of the application.

An example of a popular interface with a strong use of a metaphor is the Facebook wall. TheFacebook wall is a public surface in which a user’s friends can see posts that have been placedthere. This interface is very easy to explain to users as they can understand the effects of theiractions with their intuition of how they think it should work.

Another example of a user interface with its roots in the physical world is a word processingapplication, Microsoft Word is a popular example. The physical page is used to give the user arepresentation of their work. With a real time view on the layout of the document the user cansee immediately the effect of any actions they perform.

4.5 Detachment of the SQL interface through custom webAPI

Selecting the browser as the platform for the application poses some specific problems for a SQLIDE. A SQL IDE needs to have access to the SQL server in order to execute queries and retrieveresults. There is no support in any of the mainstream browsers for direct integration with a SQLserver database, although they do have limited support for in browser databasesi.

This therefore requires the creation of some middle ware to connect the database to theapplication. The commonly used method for transferring data in the browser is via a JSON webAPI. There are many methods for connecting to a SQL server database however, the Microsoftdocumentation contains C#, VB, C++ documentation and libraries for querying the database.[8]I personally have experience using the C# connection methods and with this in mind the middleware was chosen to be a C# website providing a mapping from JSON to the database. See fig 4.4for a diagram.

ihttp://caniuse.com/#search=sql-storage shows a report for the support of in browser SQL in commonbrowsers

27

Figure 4.3: The notebook metaphor, real concepts mapped to UML diagram, Image under CC

Figure 4.4: The application architecture, shows the connection between browser and databasethrough the “SQL API” interface

28

Chapter 5

Implementation

This chapter in the report will detail how the application was implemented given the choicesmade in the Design chapter and the requirements. The application was developed with the agilemethodologies; Quick and small iterations where a small part of the application will be planned,implemented and tested. Ensuring the parts are kept to a consistent small size should result inthe development continuing at a methodical pace.

As always with development projects involving code, version control is an important part ofthe development process. For this project git has been used to keep track of the changes to thecode. This provides many benefits as can be seen in Version Control with Gitii.

Keeping the iterations small and using technologies like git allows for more agile development.Being agile means reacting to complications with development and delays that occur due to newlanguages and technologies will have less impact on the development process.

With this in mind, the application was broken down into smaller parts that fit together toform the application. The front end of the system is the part the users will directly be interactingwith. This would form the bulk of the development however; the back-end of the application isthe middleware component that will enable the JavaScript front end to talk to the database.

5.1 MiddlewareThe middleware was planned to be created first. It was a simple task and was well defined. Therequirements for this part of the application were as follows:

• Allow the caller to create a connection to a database.

– This will require the caller to pass connection parameters and in return they willreceive some connection token to represent the connection.

• Allow the caller to execute queries against a connected database.

– Given the connection token received in the above step and a query, the results of thequery need to be sent back to the caller.

• Allow the caller to receive context data regarding a query.

– Similar to executing a query, the application might need to receive details about theobjects mentioned in the query. Each object mentioned in the query, table, view,function etc. . . would be explained in the response.

iihttps://goo.gl/WqK6f2

29

5.1.1 Design the APIThe communication to the database is provided by use of the SqlConnection and SqlCommandclasses provided by C#. To execute a query you must first create a SqlConnection class with theconnection string. A connection string is a textual detail of the parameters required to connectto the database. This can contain many different types of connection however the more usualaddress, username and password will be used to connect to the database in the API.

public class ContextRequest{

public string Database { get; set; }public string Server { get; set; }public string Username { get; set; }public string Password { get; set; }

}

The ContextRequest class provides the definition for the parameters for the CreateExecution-Context when the /api/CreateExecutionContext method receives a HTTP post the parametersare extracted from the body of the post and a SQL connection is created, opened and a token isreturned to the user.

From JavaScript there are many different ways in which you can do a HTTP post. The librarythat is used in the application is called superagenti. This provides a set of functions that manageHTTP posts. Here is an example of how a HTTP post can be made to URL with parametersparams. When the post has completed the callback function is called with the response.

request.post(url).send(params).type(’application/json’).accept(’application/json’).end(newCallback(callback));

Here the response is the connection token. This token will be needed to execute all furtherrequests to this connection.

5.2 JavaScript applicationThe JavaScript application provides the user interface for the application. It is written inJavaScript and runs in the browser in a single web page. Requests to the SQL middleware APIare made over HTTP with the superagent package.

Applications built for browsers can have very large codebases; there are many differentproblems that arrive from having a large code base and there are tools available to help developersmanage the applications. With standard JavaScript there is currently no module system (althoughthis may change soon[6]) so when the application is separated into multiple files these must beloaded in the browser before being used. This can become difficult with many interdependentand third party modules.

ihttp://visionmedia.github.io/superagent/ has more details and documentation

30

There are ways to automate this process and automatically find all dependencies and bundlethem all into one file. This bundle file contains a compiled and compressed version of all of thedifferent modules. The browser can then load this single file. This enables developers to separatethe different parts of the application and not have to put time into loading each manually.

Browserify is one such program. The tool can be used from the command line to compilethe application into a single JavaScript file. The Browserify process can also be extended tooptimise our JavaScript code and also provide us with analysis to point out potential bugs andbest practices. These tools help to turn the JavaScript development process into somethingsimilar to ahead-of-time compiled code like C# and Java and C++. This is needed for largerapplications to be built in the browseri.

5.2.1 React.js developmentWith React.js the UI is defined by React components. Each component can be thought of as anew HTML element. They can have attributes defined:

<NewElement attributeNo1="Ted" attributeNo2="123.4"/>

And each component has a render function, this render function takes each componentsinternal state and produces more HTML for the page.

var HelloMessage = React.createClass({render: function() {

return <div>Hello {this.props.name}</div>;}});

ReactDOM.render(<HelloMessage name="John" />, mountNode);

In the above example the HelloMessage component is created. In this simple component whenit is used it outputs just a simple HTML DIV element.

The use of React.Js in the project forces structure in the use of components. The layout ofthe application is as follows:

- controllers/- helpers/- stores/- ui/- app.js

The application is created in the app.js and this then uses the components in the UI folder tocreate the interface. The app.js file completely separates the UI into the binder (the left handside of the interface) and the workspace (where pages are opened).

iother tools such as https://en.wikipedia.org/wiki/Emscripten could have been used instead to transpilec++ or c into JavaScript

31

5.2.2 Storage of dataThe application will store the data for the open notebook in the browser until it is closed andsaved to disk. The data in the browser will form the state of the react components and anychanges to this state will cause React.js to re-draw the UI.

The pages are stored in the PageStore module. The tabs are stored in the TabStore moduleand the workspace in the WorkspaceStore module. Each of the stores contains the current stateof the objects. Components then access data and receive updates when items are created orupdated. This way we can separate the code that stores and modifies the data, and the code thatcreates the UI. This separation of concerns simplifies the details the developers needs to be awareof when writing code.

5.2.3 Data store interfaceThe interface that the application uses to change the data in the store should be as simple touse as possible in order to ensure that all the complicated logic to change the data is completelywithin the store. This should help to simplify the development process as the fewer places thestate is changed the easier it is to understand the interactions.

First the actions were planned out that the user might trigger.

- Create new page- Save page- Delete page- Create new tab- Change search text- Connect / Execute query

These actions form events. When these events are triggered, the data stores update theinternal state. The changes in the state then cascade down to the components that depend onthem and update the UI.

5.2.4 ComponentsThe application was split into small functional parts and a high level design for the applicationwas drawn out. See fig 5.1 for a diagram.

The left side of the application is dedicated to the navigation interface with tabs and pagesdisplayed with buttons to create new and remove old.

The workspace is a container for the open pages in the application, each page is a differentcomponent depending on what type the page is. For example a search page renders a Searchcomponent and an index page renders an Index component. This allows for easy addition of newwindow types to the system as each is implemented in a separate file.

The initial design was implemented with the standard HTML entities “li” for list and “button”for actions. Later in the design process these were replaced with components form a third partylibrary of elements. The library provides styled components that can be used in place of standardHTML. The styled components also follow the design specification called “material design”.i Thisdesign specification defined rules for positioning, colouring and other visual semantics that givethe application a professional feel and also giving the design consistency with other applicationsthat also use this style.

ihttps://design.google.com/spec/ for more information

32

Figure 5.1: Wire frame design, Shows the location of the functional elements of the design andtheir relative positions

Changing the visual design of the system proved to be a simple task, this is mostly due to thechoice of technology. Browserify and React.js both contributed by allowing a third party libraryi

to be easily imported and replace the unstyled components.

ihttp://www.material-ui.com/

33

Chapter 6

Results

In this chapter the results of the project will be shown. Annotated screenshots of the applicationwill be shown with details of the features and any interaction between components.

6.1 Overview

This screenshot shows an open notebook. The left hand side portion of the interface showsthe Binder the main navigational tool. Behind this is the workspace where the open pages aredisplayed.

6.2 BinderThe Binder is a navigational interface. It provides a listing for all the files in the system. Theinterface is separated into: the Menu bar, where the options are displayed, the Tabs list, and thePages list.

The main purpose is to provide the user with the ability to explore the documents and offercreation and deletion.

34

6.2.1 Menu

The Menu has only a single “search” option, this opens a new search window in the workspace.

6.2.2 Tabs

The Tabs section of the Binder lists the Tabs in the project. Each tab in the list can beselected, showing the pages within in the Pages section below.

6.2.3 Pages

35

The Pages section is populated when a tab is selected. This section shows options for addingnew code pages to contain SQL queries and text pages to contain notes. The edit buttion can beselected to toggle edit mode. When in edit mode, each page has a delete icon that can be used toremove the page.

The Index button at the bottom of the section when selected opens an Index page for the tab.

6.3 WorkspaceThe Workspace is where pages appear when they are opened. The open pages are displayedhorizontally with new pages opened on the right hand side of old ones. The user can have manywindow open at once.

6.3.1 Search

The Search page has a single text box for the users search phrase. When the phrase changes,the results in the bottom of the interface update to show the matches.

Each match has the name of the page, location of the match and the excerpt from the text.

6.3.2 Index

36

The index shows the pages contained within a tab. Each page has the last modified date andtime next to it from when it was last saved.

Here one of the pages shown in the index has a previous version stored.

6.3.3 Note

37

6.3.4 Code

The options available in the menu offer the ability to save, execute and reconnect the page tothe database.

38

The links view, accessed from the menu shows the links this page has to the other items inthe notebook.

6.3.5 Result

The result from a query are shown in a result page. A scrolling table shows the rows in eachresult set. The menu offers the ability to save the result to the notebook for future use.

39

Chapter 7

Evaluation and Futuredevelopments

7.1 Testing the projectTesting is an important part of developing an application. In order to achieve its goals, theapplication must function correctly, with testing and verification ensuring that each part of thesystem operates correctly.

The system was designed to be easily tested. The data store’s interface which provides themethods that the application uses was tested at the beginning of each run of the application.The application would initialise and then perform the testing procedure. The testing procedurecontained a simulation of a user performing some tasks, creating pages and adding content etc..

After the system had finished running the user’s commands the resulting UI could be checkedagainst the expected output and in this way regression could be detected early. The JavaScriptconsole also provides an excellent way to monitor the application for errors at runtime and debugto find their cause(s).

7.2 EvaluationFor the application to be successful the requirements and use cases need to be evaluated againstthe application. The application will be successful if each of the requirements are met and theuse cases can be shown to be completed by the users.

For my evaluation I presented the application to the users and asked them to complete somesimple tasks. The users had not seen the application before and also had not seen any of the datastored before. This test shows how easy the application is to learn and also provides feedback onhow real users interacted with the UI to find the information stored in the system.

The testers were only told a bare minimum of what the application was supposed to do. Theapplication should allow for the organisation of data and code for a SQL application.

Overall the testers were all able to find the various functions of the application by navigatingthe familiar UI features like the burger menu, “X” for closing windows. Finding the save optionswas similarly found by them.

The tools for executing and saving the results from queries were also quickly learned by theusers. This feature requires the most “clicks” in the application and so could be viewed as the

40

most complicated feature however, the users rarely got lost and the actions flowed naturally tothe users.

The testers also made some comments on what features they would like to see in the futurefor the application. These future features will be discussed below.

7.3 Future developmentsThe application as it is can be used for daily work by SQL developers and meets the requirementsset out initially. However there are some features that did not fit into the schedule of remainingtime. These features were not essential to completing a functional working application however,they would make the application more useful.

7.3.1 Multiple database enginesCurrently the application only supports Microsoft SQL Server however with the addition of moremiddle ware and a configurable settings window the application could be made to talk to anydatabase server.

This would enable the users to work on multiple systems across multiple database providers.It would also open the application to the users that solely use one of those databases.

7.3.2 Query explanationThe middle ware supports a method to explain the objects referenced in a query. This functionalitycould be used to provide code completions and also more data when the objects are hovered over.

The meta-data could also be saved in the file when the page is saved. This would then beavailable when the page was loaded. This could provide extra context when looking into oldqueries.

7.3.3 Different result formatsThe results from the queries are shown in a table. The results of queries are just arrays of n-tuplesbut they could represent more complex items like pi charts or folder hierarchies.

There could be some automatic classification of results to decide the best way to display theresults. Failing that, fall back onto manual selection for the results presentation.

7.3.4 Resizing windowsThe workspace shows the open pages and their controls. Currently the application sizes theseto have all the same width however, this might not be optimal for some files. The developerhas no control over how they are presented. It would be a valuable feature of the system to beable to reorder and resize the windows for each open page. This would make the system morecustomizable for each user.

41

Chapter 8

Conclusion

The application meets all the mandatory goals (11) set out in the use cases. Out of the twooptional requirements, only one was met by the application. This is due to the lack of remainingdevelopment time. The delays in the development of the features of the application were partiallydue to lack of experience with the workflow and the associated technologies.

The build process especially was time consuming to pick up. This was partially due to themany options available. The lack of up to date information is only apparent after a new buildstep is required. These delays and set backs only affect the momentum of the development at thebeginning of the project and after the changes have been implemented development speeds up.

The implementation of the application, after a change of method for storing the applicationdata, was extensible and offers a good platform for new features to be developed. The code is ofgood quality with good code separation. The separate modules have an average length of only 80lines, this short average file size is a good indicator of good quality code

The users who have seen the application have also offered thoughts on other uses of theapplication, most common is the view that the application could be used as an education tool fornew programmers to teach the code and the concepts behind database design.

The designing of the final solution was mostly influenced by personal issues identified frompersonal experience working on database projects. A more structured exploration into issues andsolutions with other developers could have come up with some more diverse ideas. These sameusers could have been consulted at various stages of the development and provided feedback.

Overall the project was a success and the final application has exceeded initial expectations ofwhat could be accomplished in a third year project.

42

Bibliography

[1] Ofer Bergman et al. ‘Folder versus tag preference in personal information management’.In: Journal of the American Society for Information Science and Technology 64.10 (2013),pp. 1995–2012. issn: 1532-2890. doi: 10.1002/asi.22906. url: http://dx.doi.org/10.1002/asi.22906.

[2] phpmyadmin contributors. phpMyAdmin: Bringing MySQL to the web. 2016. url: https://www.phpmyadmin.net/ (visited on 25/04/2016).

[3] Evernote. Evernote. 2016. url: https://evernote.com (visited on 22/04/2016).[4] Facebook. ReactJS. 2016. url: https : / / facebook . github . io / react/ (visited on

28/04/2016).[5] Jesse James Garrett et al. ‘Ajax: A new approach to web applications’. In: (2005).[6] Ecma International. ECMAScript version 6 standard. 2015. url: http://www.ecma-

international.org/publications/files/ECMA-ST/Ecma-262.pdf (visited on 28/04/2016).[7] Aaron Marcus. ‘Metaphor Design for User Interfaces’. In: CHI 98 Cconference Summary

on Human Factors in Computing Systems. CHI ’98. Los Angeles, California, USA: ACM,1998, pp. 129–130. isbn: 1581130287. doi: 10.1145/286498.286577. url: http://doi.acm.org/10.1145/286498.286577.

[8] Microsoft. Connecting to an Instance of SQL Server. 2016. url: https://msdn.microsoft.com/en-us/library/ms162132.aspx (visited on 28/04/2016).

[9] Microsoft. SQL Server Management Studio preview. 2016. url: https://msdn.microsoft.com/en-us/library/mt238290.aspx (visited on 25/04/2016).

[10] Microsoft. SQL Server Management Tools (including SSMS). 2016. url: https://msdn.microsoft.com/en-us/library/hh213248.aspx (visited on 25/04/2016).

[11] Microsoft. Visual Studio Isolated Shell. 2015. url: https://msdn.microsoft.com/en-us/library/bb685691.aspx (visited on 25/04/2016).

[12] Oracle. Javadoc Tool. 2004. url: http://www.oracle.com/technetwork/articles/java/index-jsp-135444.html (visited on 22/04/2016).

[13] Oracle. MySQL Workbench: Database Design. Development. Administration. Migration.Tech. rep. 2015. url: http : / / www . mysql . com / why - mysql / white - papers / mysql -workbench-database-design-development-administration/.

[14] Oracle. MySQL Workbench product page. 2016. url: https://www.mysql.com/products/workbench/ (visited on 25/04/2016).

[15] Fernando Perez and Brian E. Granger. ‘IPython: a System for Interactive Scientific Comput-ing’. In: Computing in Science and Engineering 9.3 (May 2007), pp. 21–29. issn: 1521-9615.doi: 10.1109/MCSE.2007.53. url: http://ipython.org.

43

[16] Wikipedia. Full text search — Wikipedia, The Free Encyclopedia. 2004. url: https://en.wikipedia.org/wiki/Full_text_search (visited on 26/04/2016).

[17] Wikipedia. Markdown — Wikipedia, The Free Encyclopedia. 2004. url: https://en.wikipedia.org/wiki/Markdown (visited on 25/04/2016).

[18] Xamerin. Xamerin. 2016. url: https://www.xamarin.com/platform (visited on 28/04/2016).

44