This is the backend to the RAPTIDE tool. If you are looking for the frontend repository then click here.
For a short demo of the working product see our YouTube Demo
This architecture document outlines the structure of both parts of the RAPTIDE program.
Author: Daniel Parker
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.
git
RAPT Toolchain: RAPT is a private project. Contact me if you're interested in gaining access.
git clone https://github.com/rlgod/SSD2-Backend.git
cd SSD2-Backend
play run
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.
“Review - 12345”
.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>
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
Author: Zakariah Chitty
Keywords are words that classify the change being made. These appear at the beginning of a commit message.
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.
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.
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.
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.
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.
Improving execution rates of existing features.
Example:
PERFORMANCE: Improvement for Module X when doing task X.
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.