Ucalgary_Baja/Baja-Charter
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(charter): seperated out software parts and allowed for further edits and additional subteam components

Browse Source
This commit is contained in:
darkicewolf50
2025-02-08 11:44:39 -07:00
parent 02dcb55669
commit ad8ca36232
5 changed files with 645 additions and 886 deletions
Download Patch File Download Diff File Expand all files Collapse all files

508
README.md
View File

@ -1,9 +1,13 @@
# Software Subteam in Baja
# Baja Charter
Developed in part by Brock
Competition Season Written in 2024 - 2025
# Subteam Sepcific
Your lead will go over this later with just your sub team
1. [Software](SoftwareSpecific.md)
## Overview of Whole Club
Based on the 2018 Baja Charter
@ -13,38 +17,6 @@ UCalgary Baja is a team comprised of students who want to expand and apply their
UCalgary Baja believes in the mantra You get out what you put in. We’re excited to have you and your unique individual skills and experience contributing to the mission of creating the best car possible. The lessons you will learn and the accomplishments you will make are up to you, and UCalgary Baja will gladly work alongside you to push you to your limits and beyond.
## How does Software Fit in?
### Purpose
#### What is Software at Baja
Software in Baja currently means the support team of the club through the development of software applications. This could be done by the use of our cloud to make running/operating the club cheaper, why pay for something when it can remade for free. Such projects include the BajaCloud which in itself contains the interview booking backend and the reimbursement backend. This does not mean the software can transform into a simulation, embedded programming team, data collection/transformation or cloud team. The options are up to what the lead decides/imagines best.
### The Future of Software
The Future of Software is in lidar track data collection and inputting into BEAMNG.drive and create a simulation of the car every year with current tracks, I hope that the team uploads the car cad/model and track to Steam and releases it for free.
The future could also be in embedded/testing systems on the physical car, as of right now I would suggest rust as a primary language due to its speed, safety and high-level features such as a formatter, inferring and package manager (crates).
### Core Beliefs of Software
Repeated again for Highlighting
```
You get out what you put in.
```
If you don't show up and do work you don't learn anything from more Senior Members.
```
Communication both written and oral is based on signals or promises with the receiving party obtaining those signals and promises.
```
This also applies to coding, particularly in HTTP requests.
### Who to Recruit especially in Software
This is directly taken from the 2018 Baja Charter and repeated again to highlight its importance.
```
It is important to note that UCalgary Baja does not exclusively recruit “car enthusiasts”. UCalgary Baja provides you with opportunities to realize your developmental aspirations.
```
I would look for anyone who is passoinate or wants to learn in their appilcation, this shows that they want to do software, you will be able to tell if it is a mech application, use your judgement to determine if you want the mech applicant
## What do you get out of Baja
This is based on the 2018 Baja charter
@ -138,105 +110,6 @@ We do not have a mandate, the only mandate is trying to fill a full hotel room i
ex. Fill a women's hotel room, ***PLEASE AVOID*** this situation, the worst is a half or quarter, please aim for as many full rooms if possible.
 
## Coding Coduct
This section outlines how programming and coding in all languages should generally be followed.
1. Readable code is valued above all else ie. Variable names that make sense, clear function names
1. Comment code even if it is obnoxious make it so that you or anyone besides yourself in 10 years can read what is going on.   Programs like ChatGPT are allowed to comment code automatically just as long as they make sense to you six months down the road
1. Use the Prettier extension as the default code formatter so that the code is consistent
1. Use git and use a new branch to create a new feature (be careful of the base of the branch)
1. Use pull requests to the dev branch to merge code
       
```
DO NOT MERGE TO THE PRODUCTION BRANCH (main or master normally)
```
1. Examples of base templates in most common languages are available below
1. Try to make code as modular and reusable as possible
1. Use ChatGPT but be warned you will spend more time on debugging than coding and ***most importantly YOU WONT LEARN***, USE IT FOR REGEX
1. Please include a permanent email and name if you write any code, this is just for questions on what x does (not mandatory)
    - If you write unreadable code you get emails in the future about it
    - Remove emails if completely refactored (75% of the code has been changed in some way)
```
DO NOT USE THIS TO GET ALUMNI TO DO YOUR WORK
```
# Operation of the Team
##  Organization Structure
## Team Structure and Reporting Hierarchy
This document outlines the reporting structure within the Software Subteam. Each role has specific responsibilities and reports to different levels of the team.
### Captain of Baja
- Can overrule task approval
- Can suggest projects
#### Software Lead
- **Reports to:** Captain of Baja
- **Chosen by:** Software Subteam and approved by Captain or voluntold by Captain
- **Min Requirements:** Not a Junior in the same year
- **Roles:** Mentor, code reviewer, task giver, project scheduler, designer, project/design approver, sysadmin of cloud/NAS
- **Language Access:** Python, HTML, CSS, JavaScript, YAML, JSON, XML, Lua, Rust, C, C++/Arduino, Java (please avoid), Golang, Terraform, Bash, Docker, Kubernetes, GitHub Actions
- **Summary:** They run the Software Subteam, have lots of projects complete, ensure that the cloud runs smoothly, enforce good coding practices, give out tasks/projects to senior members and approve.
##### Future Software Lead
- **Reports to:** Software Lead
- **Min Requirements:** 2 years with the club
- **Roles:** Mentors, can be sysadmin of cloud/NAS, code reviewer, designer, task giver
- **Language Access:** Python, HTML, CSS, JavaScript, YAML, JSON, XML, Lua, Rust, C, C++/Arduino, Java (please avoid), Golang, Terraform, Bash, Docker, Kubernetes, GitHub Actions
- **Summary:** Experienced member, teaches others, enforces coding practices, and designs/feedback on projects, should run atleast one project with the support of the software lead, this is in order to get them comfortable with the role.
##### Senior Member
- **Reports to:** Software Lead and Future Software Lead
- **Min Requirements:** 2 years with the club
- **Roles:** Mentors, can be sysadmin of cloud/NAS, code reviewer, designer, task giver
- **Language Access:** Python, HTML, CSS, JavaScript, YAML, JSON, XML, Lua, Rust, C, C++/Arduino, Java (please avoid), Golang, Terraform, Bash, Docker, Kubernetes, GitHub Actions
- **Summary:** They have a lot of projects complete, they are here to teach, give out tasks, enforce good coding practices and design how a project should be made with their designs and feedback.
###### Intermediate Member
- **Reports to:** Senior Member
- **Min Requirements:** 1-1.9 years with the club
- **Roles:** Mentor (possibly), Mentee (probably), code reviewer (possibly), design input (probably), designer (possibly)
- **Language Access:** Python, HTML, CSS, JavaScript, YAML, JSON, XML, Lua, Rust, C, C++/Arduino, Java (please avoid), Golang, Bash (basic commands and git), Docker, Kubernetes
- **Summary:** They have a few project(s) completed, they are still mostly here to learn, they can give better feedback on designs than juniors (starting to understand)
##### Junior Member
- **Reports to:** Software Lead and Senior Member
- **Min Requirements:** New to the club this year
- **Roles:** Mentee (Need, dependent on year), design input
- **Language Access:** Python, HTML, CSS, JavaScript, JSON, XML, JSON, Lua, Golang, Bash (basic commands and git)
- **Summary:** They are new and here to learn, they can give limited amounts of feedback about designs (due to a lack of knowledge)
This structure aims to provide a guide to members of software.
This does not mean that it is rigid it is a general guide to how the team members should operate and the level of expectations on them.
***Lanaguage Access***
This does not mean that anyone on any level of the hierarchy is not able to code in those languages **Willingly** it is meant to be interpreted as a guard for those who are lower in the chain from going into more difficult languages such as C or rust where the understanding is not able to be taught by the university in their first or second years.
***Roles***
This gives the expectation of the person the newer one is to the club the less they are expected to know and do for the software subteam.
***Reports to***
This is the group who is in charge of you the lead is not able to handle 8 people all on their own they need help, your mentor is there to help the Lead and future Lead and filter out a lot of the questions and task giving.
**The Captain most likely cannot help with software please go to the Software Lead as a last resort**
***Pair Programming***
This is a technique in programming where a mentor and mentee are paired up the mentee is expected to write the code and the mentor is expected to drive/tell the mentee what to write.
This is in hopes of giving the mentee exposure to the language and general programming concepts so that they may level up their skills.
## Roles and Expectations
based upon the 2018 Baja Charter
@ -289,7 +162,6 @@ based upon the 2018 Baja Charter
- Act to the best of their ability to provide design insight to fellow system teammates under the direction of his or her system lead
## Seasons
There are multiple phases throughout the year. As UCalgary Baja is a competition team focused on performing well all members are expected to have full involvement in each phase. The Baja year can be broken down into the following cycle (It is important to note that each phase may feather into one another):
@ -383,373 +255,3 @@ We help where we can, that could be running the sim for the driver, fetching too
Summer is the transition phase, and Fall is the start of a new season
Prepare for the next phase as well as you can
# How To's
This can be found also in Baja Data Current Year/W - Software/Software Standardizations and Common Git Commands.md.
The most up-to-date is in the current year.
## Baja UofC Software Standards
### Git
The stupid content tracker.
No more need for V1, V2, V2 Final or V2 Final Final edit by Malik Final
This terminal-based program is a lightweight version control, that is highly useful for dealing with code/text activities.
This does not require a remote origin, a local repo will be fine with the use of the Baja Cloud, just upload any .git files with it.
This will track everything in the specified git directory (files, child directories, etc.)
#### Common Commands
###### Note
Need to be in a git repo directory to use git commands.
```bash
# change directory
cd <name/path>
# Go to the parent directory
cd.
# initialize a git repository (local only)
git init
# add (stage) all changes (in files)
git add -A
# Commit staged changes with a message
git commit -m "commit message"
# create a new branch and check into it
git checkout -b <branch-name>
# change the current branch to an existing branch
git checkout <branch-name>
# delete a branch
git branch -D <branch-name>
# set upstream (default remote branch) for a local branch
# (upload)
git push -u origin <branch-name>
# pull the latest changes from the remote repository
# (download)
git pull origin <branch-name>
# revert a commit
git revert <commit-hash>
# see commit logs (multi-line includes the date, who and other useless info)
# Is much longer
git log
# see logs in one line (with commit hash)
# shorter
git log --oneline
# see the list of both local and remote branches
git branch -a
# see the list of local branches
git branch
# see the status of the current local repository
# see what files/changes are uncommitted
git status
# rebase a branch with another one
git rebase <branch-name>
# see remote repositories linked to the current local repository
git remote -v
# add a new origin (remote repository)
git remote add origin <origin-url>
# cache GitHub credentials
git config --global credential.helper 'cache --timeout=36000'
# remove git cache
git rm -r --cached.
# config username and email for a git project
git config user.name "username"
git config user.email "email"
```
<h2>Git cheat sheet</h2>
<p>The commands discussed above–and more–are summarized in this cheat sheet available to <a href="https://wac-cdn.atlassian.com/dam/jcr:e7e22f25-bba2-4ef1-a197-53f46b6df4a5/SWTM-2088_Atlassian-Git-Cheatsheet.pdf?cdnVersion=691">download</a>.</p>
#### Type
Must be one of the following:
- **init**: A special case only for the very first commit (example: init(location))
- **build**: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
- **ci**: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
- **docs**: Documentation only changes
- **feat**: A new feature
- **fix**: A bug fix
- **perf**: A code change that improves performance
- **refactor**: A code change that neither fixes a bug nor adds a feature
- **style**: Changes that do not affect the meaning of the code (white space, formatting, missing semi-colons, etc)
- **test**: Adding missing tests or correcting existing tests
- **chore**:
- **added**: Added content but not a complete feature
- **removed**: Removed files or content only
- **merged**: Used when a branch's content is merged into another branch
#### Message
The subject contains a succinct description of the change (this will show up in the logs):
- use the imperative, present tense: "change" not "changed" nor "changes"
- don't capitalize the first letter
- no dot (.) at the end
#### Example Commit
```bash
git add -A # adds all of the files/changed files to the commit stage (pre-commit)
```
```bash
git commit -m"feat(DAQ)^: optimized algorithm" # the message that will show up in the logs
```
Another Example
```bash
git commit -m"Feat (API)^: send an email to the customer when a product is shipped"
```
#### How to Commit
```
"<type>(scope or file that has been changed): short description"
```
Replace <type> with just the type
^ for any breaking commits
#### Why?
How long do you think this code will be used? 1 year? 1 decade? 4 weeks?
You don't know so make life easier on yourself and new juniors comment on what your code does, it doesn't have to be line by line but at least explain a "block" or a related section of code to the purpose/what it does.
### Example Comments and Function Starters
Based off JSDoc standard can be found [here](https://jsdoc.app)
#### JavaScript
Uses [JSDoc](https://jsdoc.app) standard
```js
//More preferred arrow function just needs to call function and does function immediately
/**
* @param {Object} inputVar - one argument into the function should be its name
* @param {number} b - one argument into the function should be its name
* @returns {Promise<number>} c - what the program returns with type
* @description A brief description of what the function does
* @author Name <semiperminant@exmaplemail.com>
// semi-permanent email, do not need to respond but try to be a good alumni
*/
const exampleFunct = (inputVar) => {
// comments annotate the line below them
// constant variable cannot change, not strongly typed
const varExample0 = 0;
// local variable, not strongly typed can be any data type
let varExample1 = 0;
// global variable, not strongly typed can be any data type
var varExample2 = 0;
// example function does nothing significant
  return 0;
};
/**
* @param {Object} inputVar - one argument into the function should be its name
* @param {number} b - one argument into the function should be its name
* @returns {Promise<number>} c - what the program returns with type
* @description A brief description of what the function does
* @author Name <semiperminant@exmaplemail.com>
// semi-permanent email, do not need to respond but try to be a good alumni
*/
function exampleFunct2(inputVar) {
// comments annotate the line below them
// constant variable cannot change, not strongly typed
const varExample0 = 0;
// local variable, not strongly typed can be any data type
let varExample1 = 0;
// global variable, not strongly typed can be any data type
var varExample2 = 0;
// example function does nothing significant
return 0;
};
```
#### Python
```python
# comments normally annotate the line below, python functions/classes/methods are the only expection
def example_funct(input_var:type):
"""
What function does
`PARAMS`:
- Name_of_var `type` - Addtional details of what is required
`RETURNS`:
- Name_of_var `type` - Additional details of what is required
`AUTHOR(S)`:
- Your Name
`Contact`:
- semi-permanent email, do not need to respond but try to be a good alumni
- Example of two items
"""
# example variable can be anything not just an int
var_example = 0
# example function does nothing significant
return 0
```
#### Rust
```rust
fn exampleFunc () {
// I have not decided yet
}
```
#### C++
```cpp
/*
What function does
PARAMS:
- nameOfVar `type` - Addtional Detals (if applicable)
PROMISES:
- nameOfVar `type` - Additional Details (if applicable)
AUTHOR(S):
- Your Name
CONTACT:
- semi-permanent email, do not need to respond but try to be a good alumni
- Example of two items
*/
int exampleFunct (int inputVar) {
// comments annotate the line below them
int varExamlpe;
// example variable, is strongly typed. Can only be an integer
int varExample1 = 0;
// example function does nothing significant.
return 0;
};
```
#### C
```c
/*
What function does
PARAMS:
- nameOfVar `type` - Addtional Detals (if applicable)
PROMISES:
- nameOfVar `type` - Additional Details (if applicable)
AUTHOR(S):
- Your Name
CONTACT:
- semi-permanent email, do not need to respond but try to be a good alumni
- Example of two items
*/
int exampleFunct (int inputVar) {
// comments annotate the line below them
int varExample0;
// exampe variable is strongly typed. In this case can only be an integer
int varExample1 = 0;
// example function does nothing significant
return 0;
};
```
#### Java/C#
```java
// these languages is cursed and full of boilerplate
// use anything else if you can
// high memory overhead, use C++ instead
// you can add standard here just make it similar to the rest
```
#### Golang
```golang
// I dont know
// you can add standard here just make it similar to the rest
```
#### Lua
```lua
-- I dont know
-- you can add standard here just make it similar to the rest
```
#### Terraform
This will probably only used for cloud applications
```terraform
<!--
I dont know
you can add standard here just make it similar to the rest
-->
```
#### HTML
This is the same as any other page, not unique, should still vet in a html validator/best practices
author goes in human.txt, for more info please see [here](https://humanstxt.org)
```html
<!doctype html>
<html>
<head>
<title>Our Funky HTML Page</title>
<meta name="description" content="Our first page">
<meta name="keywords" content="html tutorial template">
</head>
<body>
Content goes here.
</body>
</html>
```
#### JSON, YAML, XML, CSS
These are more like data types/file format, follow rules of the language
#### Bash
Always starts with a shebang
```bash
#!
echo "Hello World!"
# I dont know
# you can add standard here just make it similar to the rest
```
#### Github Actions
Please find example in any baja repo under .github/workflows/*.yaml
star is a wildcard and in this case represents any name of the file