CSCI 265 Project resources

This page serves as a catch-all for resources/reference material that might be handy while working through the project (content on git/gitlab/github, markdown, etc).

Sample documentation

Sample versions of most of the core documents (proposals, requirements, team charters, etc) can be found here.

Gitlab/github details for team repos:

Details on use of your gitlab or github team repos is provided on the course gitlab page.

When it comes to inviting me to your gitlab/github project:
on gitlab.csci.viu.ca I'm @wesselsd (David Wessels), adding as a 'reporter' is fine
on github I'm DaveWesselsVIU
both use my David.Wessels at viu email address

Code standards
For full marks, all your submitted code and documentation must adhere to either the CSCI 265 standards or an alternative set of standards developed by your team and approved by the course instructor.

Obtaining and submitting the individual contribution assessments for the team project

Git recap for individual portions provided in contribution assessments.

Getting feedback on the project phases
I'll post feedback for each person individually, using a git repo named feedback.

The server-side repos have already been created (forked), you'll just clone your feedback repo once, then in the future go into it and run a git pull to grab any updates I've posted for you.

Getting the repo the first time:
git clone csci:csci265/$USER/feedback
then cd into the directory and have a look at file 'phase1'

Getting updates in the future:
cd into your feedback directory and run
git pull
and have a look at any files/file updates it pulled.

CSCI 265 project documentation using markdown (.md)

This semester, all of the documentation files for the project (both individual and team documents) will be submitted as markdown (.md) files. This is the only acceptable file format for documentation in the projects - if anything else is submitted you'll be required to resubmit using this format.

It's important we have an agreed file format for sharing content across the team and across the course, and a text-based format like markdown is much more suitable for tracking with version control systems (like git) than other formats (word, pdfs etc).

A discussion of basic and extended .md syntax can be found at these URLs:
- markdownguide.org/basic-syntax
- markdownguide.org/extended-syntax

Merlin's guide on how to configure your browser to display .md files can be found at URL
- csci.viu.ca/~wesselsd/technotes.html#markdown

Git-friendly diagrams in markdown:

Version control systems that track line-by-line differences between file versions (e.g. git) have a tendency to struggle with binary files (audio, images, pdfs, word docs, etc) since those don't store file content on a line-by-line text basis. This means either not tracking those files in the version control system (which causes a significant gap in our version control history) or storing an entire new, often large, binary over and over (consuming lots of storage).

Since our documentation (requirements, design, testing, etc) often makes heavy use of diagrams, it can be very handy to use tools that store diagrams as code: a language is used to describe the desired diagram as text within the document and then it can be rendered as an actual image when the reset of the document is rendered.

One such handy diagramming tool/language is mermaid: it's free, it's supported in markdown, and it can be rendered correctly in VScode, Github, Chrome, Firefox, and I'm sure in a variety of other browsers.

To include a mermaid diagram in your markdown, put ```mermaid at the start of the diagram code and ``` at the end, e.g. 
```mermaid
A BUNCH OF MERMAID CODE GOES HERE
```
The sample design document has a number of mermaid graphs in it (a rendered version is in the design pdf) and the mermaid syntax reference can be found on mermaid.js.org .