GeneralistDev / SSD2-Backend

SSD2 Project backend play framework
Apache License 2.0
0 stars 0 forks source link

README

This is the backend to the RAPTIDE tool. If you are looking for the frontend repository then click here.

Demo

For a short demo of the working product see our YouTube Demo

Tutorial

Architecture

This architecture document outlines the structure of both parts of the RAPTIDE program.

Setup and Dependencies

Author: Daniel Parker

Dependencies

  1. Play framework: Install the java version of the play framework on your system from the play website. Ensure that the play command is in your system path.

  2. git

  3. RAPT Toolchain: RAPT is a private project. Contact me if you're interested in gaining access.

Setup and Configuration

  1. Clone this repository to any directory
    git clone https://github.com/rlgod/SSD2-Backend.git
  2. Enter the directory and run the play framework
    cd SSD2-Backend
    play run

Code Review Process

This standard for code review is intended to improve both source code quality and also the cross-developer awareness. All development team members must follow this code review process and ensure that the process is followed at all times.

Roles:

Process:

‘Review Document’ Template

Author: <Developer Name> - <Developer Username>

Summary: <Summary of feature / changes to feature. ~ 2 Paragraphs>

Commits: <List of commits to review copied from ‘git log --pretty=oneline --abbrev-commit abcdefg..’ including the trailing dots to list all commits since abcdefg, or alternatively ‘git log --pretty=oneline --abbrev-commit abcdefg..hijklmnop’ for the log between two commits>

Example:

Author: Daniel Parker - rlgod

Summary: Implemented feature ‘A’ to satisfy the following requirements…
         etc.
Commits: 
      67898aa remove strict against null test
b8c028e Merge pull request #141 from Rovak/grunt/watchtask
81920bd moved building source to separate task to speed up build cycles
01110ec trigger build when source changes
32b973f added grunt-contrib-watch dependency
516f7dd jshint warnings
09573e1 trailing spaces

Commit Message Standard

Author: Zakariah Chitty

Key Words

Keywords are words that classify the change being made. These appear at the beginning of a commit message.

DOC

Changes that are related to documentation.

Rules: Doc must only be used in conjunction with another keyword. The two keywords are hyphenated together (e.g., Doc-New, Doc-Enhance).

Examples:

67898aa DOC-NEW: Architecture design document for module X.

b8c028e DOC-ENHANCE: Added a class diagram outlining characteristic Y to the architecture design document for Module X.

FIXED

Changes related to addressing issues, defects and/ or bugs.

Rules: If the fix is related to a documented issue, this should be referenced in the commit message. Otherwise if the fix had not been previously documented then it should be described to a level of detail that is suitable for the given context.

Example:

FIXED: Addressed issue #7 bug found in Module X.

NEW

Creating a new feature that did not already exist. This can also relate to doing basic plumbing.

Example:

NEW: Module X class to achieve feature Y

NEW: Screen to display information Z.

ENHANCED

Updating or improving a feature, or aspect of the code that is not looks, performance based or a fix.

Example:

ENHANCED: Module X to perform feature Y.

LOOKS

Non functional changes, i.e., prettifying. This will typically relate to the UI. Example:

LOOKS: Screen X now displays information Y in a cleaner way. 

PERFORMANCE

Improving execution rates of existing features.

Example:

PERFORMANCE: Improvement for Module X when doing task X. 

Other Practices

Changes can be related to the artifacts in a generic way (e.g., Fixed spelling mistakes in the UI on screen X) or if necessary changes can be related to artifacts at a file level (e.g., Commented File X to conform with commenting standards). It is up to the author to decide what is appropriate in a given scenario.