Development - Gowiem/Sisyphus GitHub Wiki

Process Overview

Source Control

We used Git as our source code management system and Github for hosting our repository. Git was developed by Linus Torvald in 2005, and is distributed under the GNU General Public License. Git was an obvious choice for a few reasons:

  • Scalable and Fast
  • Compatible with Existing Protocols
  • Non-linear development cycle (Supports branching)
  • Not dependant on network access

Workflow

The project was developed using an iterative Agile methodology. The developers discussed weekly progress with the team, while designers documented bugs and development planned implementation goals for the next “sprint.” Development cycles varied in length depending on the feature or component in question.

The team used a traditional Git workflow. New features were delegated to a developer, who would create a branch off master as the working directory for that feature. Once development was complete the branch would be committed and pushed to the server. Any changes made were then tested and verified by the other dev before merging back into the master branch.

Similar to the treatment and usage of branches, developers tried to restrict the scope of individual commits to a single feature or modification. Modular use of git minimizes errors, quickly resolves new errors, and prevents rollbacks on large portions of code.

Tools

EmberJS

Used for: JavaScript Framework

EmberJS was our main JavaScript framework and it allows us to create a fast client-side experience by communicating with the backend via AJAX and therefore not reloading the browser. We chose to use this framework as it is cutting edge technology right now and we wanted to work on something innovative and young (just released their version 1.0 prior to the start of the project).

Ruby on Rails

Used for: Backend Server

Ruby on Rails was decided as our backend framework as it is reliable, allows for speedy development, and most importantly has a large development community. Rails large community provided us with multiple Gems which helped us develop quickly and with less bugs since we weren't reinventing the wheel. Specifically we used the following libraries (Gems) which helped us immensely:

  • Devise - Authentication Framework which helps handle registrations and sessions
  • Mongoid - MongoDB Object-relational Mapper (ORM) - Integrates our database with the Rails framework
  • Teaspoon - JavaScript Test Runner - Helps run our integration test suite
  • Active Model Serializers - Helps easily convert our Database models to JSON so we can serve them via our Rails API
  • A number of smaller Gems

MongoDB

Used for: NoSQL Database

We used MongoDB as our database as it's JSON/document object approach to NoSQL allows us quickly change our Schema without migrations. Using the Mongoid Gem mentioned above allows us circumvent writing a ton of SQL queries and write out queries via simple Ruby methods.

Schema

Development of the data model was a collaborative process between the entire team. After the initial concept came together we spent a class period whiteboarding out a first draft. From there we implemented and edited the database as needed.

Note: Current diagram and implemented data model does not take into account “Class” object, which will serve as the driving data for the “Faculty View.”

Schema Diagram