Justification of usage for chosen languages, frameworks and APis

Foreword

Due to the nature of the project undertaken and our choice of both design and development methodologies, the choice of the technologies used was just as important as we felt it should naturally reflect our methodology selections.

People rarely learn unless they are having fun in what they're doing - Dale Carnegie

---

Contents

• Ruby
• Ruby on Rails
• Ruby Gems
• Postgresql
• Javascript
• jQuery
• React.js
• Materialize.css
• RSpec
• Rubocop
• ESlint
• CircleCi
• Heroku
• GitHub

---

###Ruby

From the Ruby docs:

Ruby is a dynamic, open source programming language with a focus on simplicity and productivity. It has an elegant syntax that is natural to read and easy to write.

The biggest reason for selecting Ruby was due to the ease of writing and reading which was particularly important as many of the members in our team had primarily focussed on Java and we needed a language that wouldn't be too intimidating at first glance.

In addition to this, the ruby documentation has comprehensive guides on how to install and set up ruby and how to adjust to Ruby when coming from another language.

Ruby on Rails

To go with our chosen back end language, we needed a reliable framework to go with it. Enter Rails

As the web application was to act as a content management system and be able to interface with our mobile application via a custom made API, we felt that Rails was perfect for achieving this as Rails is naturally restful which we then applied to our API query format allowing the mobile devices to retrieve information with ease.

Furthermore, Rails, despite its large file structure, is surprisingly beginner friendly and inexperiences members of the team were able to get started quickly thanks to the use of Rails Generators to create models and controllers, preventing the need to create them individually themselves.

Alternative options we were looking of utilising was Node.js. The benefit of this would be a pure Javascript environment for both the client-side and server-side therefore requiring developers to only use one language, one that is more similar to Java than Ruby is.

The overwhelming drawback of this is that Node is not beginner friendly and requires a well-grounded knowledge of Javascript and its quirks, from callback functions for asynchronous programming to the lower level of abstraction of networking that Node has.

###Ruby Gems A Ruby Gem is essentially a plug-in that comes with pre-defined functionality out of the box and helps with speeding up development in a Ruby application and are synonymous with Ruby and the Rails framework.

A list of the gems we opted to use can be found in the repository's Gemfile

A list of the most significant ones can be found below

• aws-sdk - Allowed for easy communication with our S3 bucket
• rqrcode - Used for generating QR codes to be point at various points on a tour
• wicked-pdf - Used to produce a document of a compilation of all data for a particular Tour
• random-word - Generates a random passphrase used to query a tour from a mobile client and retrieve its data, that would be available for a specified time
• streamio-ffmpeg and fastimage - For media compression to store on Amazon S3 service
• quill-rails - Allows the user to make notes about the tour for compilation into the PDF.
• pg - Allowed for easy interfacing with our Postgresql datastore
• [react-rails] (https://github.com/reactjs/react-rails) - Allowed for the use of React components in our asset pipeline
• thin - Lightweight http web server for hosting it locally, opted for thin over Webbrick due to its higher responsiveness
• rubocop - Our Ruby code linter to ensure the code is conforming to Ruby standards.
• materialize-sass - For compilation of the Materialise css framework into the asset pipeline
• jquery-rails - Allowed us to utilise Materialise's Javascript componenets and made Ajax calls from within React components much easier
• bcrypt - Used for encrypting the passwords of CMS users.
• figaro - For securely configuring the rails app for each platform (development, testing and production).
• sendgrid-ruby - Used to send emails through the Sendgrid Web API to Tour participants and Users of the CMS for account confirmation, password reset and tour enrolment.
• pry-rails - Our debugger with a nice console interface that allows us to step through code, in order to iron out bugs
• rspec-rails - Our Ruby testing framework.

###Postgresql We opted to use Postgres as for our storage system due to its reliability and natural interfacing that it allows with the Ruby programming language. Ruby has a gem, called pg for this, which makes installation and setup even easier.

A viable alternative would have been SQLite3, for which ruby also has a gem, sqlite3. However, under heavy traffic, databases running on sqlite3 have been known to slow down considerably, whereas Postgresql does not, and scales well for larger applications.

###Javascript Javascript is a scripting language that runs on the client's browser or more simply known as a client-side scripting language. Javascript is the most common language to use for manipulating the Document Object Model (DOM) allowing for a more immersive and seamless experience.

All of our input validation written in Javascript was backed up on the server-side with Ruby, since clients can opt to turn Javascript off in their browser.

Novice web programmers in our team were able to pick this language up quite quickly with its Java-like syntax and support of objects. Much of the Javascript used was written in the new standard in the form of ES6 which is resembles Java even more than it's predecessor ES5.

###jQuery jQuery is a library built using Javascript which simplifies DOM traversal and manipulation. We chose to use this since Materialize.css's Javascript components use this library in order to function properly. A nice benefit of utilising this was the ease of defining and executing HTTP AJAX requests, in order to manipulate data in the database by asynchronously sending new and updated data to the Rails Controllers.

###React.js Facebook's React.js introduces itself as the V in MVC. During development of our V layer of our application, we were forced to think the React Way where views are made up of reusable stateful components that can be updated asynchronously by setting new states as new or updated data becomes available.

Since a many pages on the content management system were centralised around providing lists of information, we were able to extract this into a React component and abstract away the functionality of pulling data from the server, via AJAX requests, at a specified interval defined in the component's props.

Since "React doesn't make assumptions about your technology stack" - Facebook, we were able to build our interface in such a way that the components, that the interfaced were composed of, are able to communicate with our own API for retrieving and sending data.

###Materialize.css Material Design is a design specification created by Google which attempts to unify user experience across applications and devices. We tried to unify the user experience across, not only the devices that could be used but platforms too, with the exception of iOS which has its own set of design guidelines that must be adhered to in order for your application to be eligible for submission to the App Store. So both the content management system and Android application both are implemented using Material Design, and the Ruby gem for Materialize made including the materialize framework into the application's asset pipeline very simple.

###RSpec RSpec is a TDD framework used for writing comprehensive unit tests that output results in a readable format in the console, which we used for testing model validations, controller action responses and ensuring the correct prop values are being passed through to the view layer of our application.

###Rubocop Rubocop is a static code analyser, but is more commonly known as a Linter, whose purpose is to pick up and raise warnings about lines of code that are not in line with the Ruby style guide. The obvious benefit of this is that the code across the repository would be of a consistent style and to the correct standard.

###ESlint ESlint, much like Rubocop, is a linter for Javascript which allows the developer to specify what rules are enforced through the use of a .eslintrc file.

###CircleCi CircleCi is a continuous integration platform which was put in place to prevent code being merged into production when tests are currently failing on the branch. Configured through a circle.yml file, which specifies the course of action CircleCi should take upon tests passing, we were able to seamlessly perform all migrations and updates automatically along with pushing the new feature into master.

###Heroku Heroku is our choice of hosting platform which we were able to integrate seamlessly with both GitHub and circleci. This allowed us to host our web app in development and create staging areas for our app to test new features in a live environment. Paid options will be available should the client want to increase the scale of the application to deal with more data and traffic

###GitHub GitHub allowed us to track the progress of the app and enabled us to work on features concurrently and code reviewing through the use of branches and pull requests. We will continue to host the code for our app here when the project goes open source to allow other developers to create branches of their own in order to contribute.

To contribute a new feature to the repository, we follow the convention off creating a branch for a feature, opening and pull request and marking it with the "Work in Progress" label and then swapping it for the "Ready for Review" label when it is complete, with testing, for another contributor to test, review and then merge into master to be pushed to production.