From ec1fb001a181c424541ca46e4ebd3289d33a6e10 Mon Sep 17 00:00:00 2001 From: al6862 Date: Tue, 10 Oct 2023 20:18:30 -0400 Subject: [PATCH] edited readme for grammar --- README.md | 14 -------- instructions-0d-sprint-planning.md | 58 ------------------------------ instructions-1-front-end.md | 36 ------------------- instructions-2-back-end.md | 29 --------------- instructions-3-database.md | 27 -------------- instructions-4-deployment.md | 18 ---------- 6 files changed, 182 deletions(-) diff --git a/README.md b/README.md index cc661b4..607f7c1 100644 --- a/README.md +++ b/README.md @@ -1,20 +1,8 @@ # Project Repository ### Project Description -This web app is for music fans to rank and discuss music. - - Product Vision Statement: Our app is a music ranking app that allows users to view songs and leave rating and comments about their thoughts. Users are allowed to create accounts and choose to log in and log out. They can also search for individual songs that they want to rate as well as look at the current reviews for that song. Users can also comment under these posts or create a post of their own. Our app also allows for people to view other profiles to see what other posts and comments other users have left. The goal of our product is to create a community of users where they can actively share their thoughts on songs as well as see and communicate with other peoples views. This allows users to not only learn more about songs they might not have heard yet but also receive opinions from other users that may align or clash with their own thoughts. - Users can: - * login/logout - * search for individual songs - * rate individual songs - * post written reviews - * post comments on written reviews - * see other users' profiles - - - ### Team Members - [Athena Leong](https://github.com/aleong2002) - [Jaylyn Bido](https://github.com/jaylynb26) @@ -31,6 +19,4 @@ See [CONTRIBUTING.md](./CONTRIBUTING.md) for information on project contribution *to be updated at a later stage* ### Additional Links -*links to any additional Markdown documents or web pages that may be relevant to the project* - - [SpotifyAPI](https://developer.spotify.com/documentation/web-api) diff --git a/instructions-0d-sprint-planning.md b/instructions-0d-sprint-planning.md index 5a7df89..9a57c1f 100644 --- a/instructions-0d-sprint-planning.md +++ b/instructions-0d-sprint-planning.md @@ -4,25 +4,12 @@ Scrum follows a specific process by which teams plan the work that will be done ## Creating the Sprint Backlog -<<<<<<< HEAD -Each team will hold a [Sprint Planning session](https://knowledge.kitchen/Scrum_development_framework#Sprint_planning) to decide which User Stories from the Product Backlog to include in the Sprint Backlog for the upcoming sprint. The team must follow the established procedure for holding sprint planning sessions. - -View a [video overview of creating the Sprint Backlog in GitHub](https://youtu.be/-MBEnpAgmug). -======= Each team will hold a [Sprint Planning session](https://knowledge.kitchen/content/courses/agile-development-and-devops/slides/scrum/#71) to decide which User Stories from the Product Backlog to include in the Sprint Backlog for the upcoming sprint. The team must follow the established procedure for holding sprint planning sessions. ->>>>>>> 2b503b8d496e3059af152e2a078c2f0d478bcf30 ### Elaborating the User Stories Each User Story added to the Sprint Backlog must... -<<<<<<< HEAD -- include [Acceptance Criteria](https://knowledge.kitchen/Scrum_development_framework#Acceptance_Criteria) included in it [as a checklist](GitHub_for_team_collaboration#Creating_a_new_issue) -- be assigned the `Sprint N` Milestone, where N is the number of the current sprint, in GitHub's Issue tracker -- include an [Estimation of effort](https://knowledge.kitchen/Scrum_development_framework#Estimation_of_work), which teams calculate following the Planning Poker effort estimation processes - -User Stories in the Sprint Backlog must also follow the basic requirements for User Stories -======= - follow the basic requirements for User Stories - be assigned the `Sprint N` Milestone, where `N` is the number of the current sprint, in GitHub's Issue tracker @@ -30,47 +17,18 @@ User stories may optionally also... - include [Acceptance Criteria](https://knowledge.kitchen/content/courses/agile-development-and-devops/slides/scrum/#61) included in it [as a checklist](GitHub_for_team_collaboration#Creating_a_new_issue) - include an Estimation of Effort, which teams calculate following the Planning Poker effort estimation processes ->>>>>>> 2b503b8d496e3059af152e2a078c2f0d478bcf30 ### Breaking User Stories into Tasks Once the team has selected User Stories to include in the Sprint Backlog, the team must then create the individual Tasks and Spikes that are necessary to implement each the User Story. -<<<<<<< HEAD -Tasks are the smallest unit of work, and should typically be doable by one person in one day. In a class setting, we will define Tasks as completable by one person between one Standup meeting and the next Standup meeting. - -Tasks are those things that must be done to complete the implementation of the User Story - -- these include tasks for each of the things that are necessary according to your team's definition of done -======= A Task is the smallest unit of work. Together, the Tasks related to a single User Story are those things that must be done to complete the implementation of that User Story. Tasks should typically be doable by, at most, one person in one day. But in a class setting, we will define Tasks as completable by at most one person between one Standup meeting and the next. ->>>>>>> 2b503b8d496e3059af152e2a078c2f0d478bcf30 Each task must... - be made its own Issue in GitHub's Issue tracker -<<<<<<< HEAD -- be assigned the 'Sprint N' milestone, where N is the number of the current sprint. -- be labeled with the 'task' label to differentiate it within GitHub's Issue tracker from 'user story' Issues -- include in its initial description the Issue number of the User Story from which it was derived -- include the number sign, e.g. "This task is part of User Story #4" - -View a [video overview of creating the Sprint Backlog in GitHub](https://youtu.be/-MBEnpAgmug), which includes how to break up User Stories into Tasks. - -### Spiking the backlog - -This initial product backlog must include 'spikes' for investigating which technologies to use for the project as well as setting up each team member's local development environment. - -- These spikes are highest priority and must be completed as soon as possible during the Sprint - Spikes must be given the 'spike' label and the 'Sprint N' milestone, where N is the number of the current sprint, in GitHub's issue tracker - -### Planning poker cards - -Each team must agree on a way of estimating work. This can be any of the [work estimation methods](https://knowledge.kitchen/Scrum_development_framework#Estimation_of_work) that we have discussed. - -If a team chooses to go with the [Planning Poker](https://knowledge.kitchen/Scrum_development_framework#Estimation_of_work) estimation method, the team must agree upon a deck of cards that they like and will use for work estimation -======= - be assigned the '`Sprint N`' milestone, where `N` is the number of the current sprint. - be labeled with the '`task`' label to differentiate it within GitHub's Issue tracker from '`user story`' Issues - include in its initial description the Issue number of the User Story from which it was derived, e.g. `Related to user story #22` @@ -88,7 +46,6 @@ Spikes must be given the '`spike`' label and the '`Sprint N`' milestone, where ` Each team must agree on a way of estimating work. This can be any of the work estimation methods that we have discussed. If a team chooses to go with the Planning Poker estimation method, the team must agree upon a deck of cards that they like and will use for work estimation ->>>>>>> 2b503b8d496e3059af152e2a078c2f0d478bcf30 - it's ok to design your own cards if you have visually or conceptually creative team members - it is not ok to use Planning Poker software in place of physical cards - doing so goes against the raison d'être of Scrum @@ -97,24 +54,9 @@ If a team chooses to go with the Planning Poker estimation method, the team must ### Setting up the task board -<<<<<<< HEAD -Each team will maintain a shared Task Board for each Sprint [using -GitHub's Project Board functionality in the recommended -fashion](https://knowledge.kitchen/GitHub_for_team_collaboration#Project_boards). These -boards are available under the 'Projects' tab in GitHub - you will -have to set up the Sprint task board in recommended fashion. - -- Add all User Stories to be addressed during the Sprint into the - "Sprint Backlog (User Stories)" column - Add all Tasks for each User - Story into the "To Do (Tasks)" column - -Once you start working on tasks, you will move them to the other columns -depending on their current status. -======= Each team will maintain a shared Task Board for each Sprint [using GitHub's Project Board functionality in the recommended fashion](https://knowledge.kitchen/content/courses/agile-development-and-devops/scrum/github-project-management). These boards are available under the '`Projects`' tab in GitHub - you will have to set up the Sprint task board in recommended fashion. - Add all User Stories to be addressed during the Sprint into a "`Sprint N - Backlog`" table view. - Add all Tasks and Spikes for each User Story into the "`To Do`" column of a `Sprint N - Task Board` board view. Once you start working on tasks, you will move them to the other columns depending on their current status. ->>>>>>> 2b503b8d496e3059af152e2a078c2f0d478bcf30 diff --git a/instructions-1-front-end.md b/instructions-1-front-end.md index 2d517c9..3ebc882 100644 --- a/instructions-1-front-end.md +++ b/instructions-1-front-end.md @@ -1,10 +1,6 @@ # Front-End Development -<<<<<<< HEAD -Each team must have completed and [demo'd](https://knowledge.kitchen/Scrum_development_framework#Demo_for_Stakeholders) the working front-end of their group project by the end of the corresponding Sprint. -======= Each team must have completed and [demo'd](https://knowledge.kitchen/content/courses/agile-development-and-devops/slides/scrum/#91) the working front-end of their group project by the end of the corresponding Sprint. ->>>>>>> 2b503b8d496e3059af152e2a078c2f0d478bcf30 ## Technical requirements @@ -15,29 +11,6 @@ The following requirements outline what must be, must not be, and may be done du - All front-end code must be generated using React.js. - All component definitions must be written as **functions**, not as classes. - All component content must be written using **JSX**, not only plain Javascript. -<<<<<<< HEAD -- All styles must be custom-coded in external CSS files - one for each component. -- Basic layout of each screen must be accomplished using the CSS flexbox system. -- Front-end screens must be custom-designed to look clean, contemporary, and sharp, not like a wireframe. -- Any data that will ultimately come from a back-end server or API in the completed application must be mocked for now using the mock-API tool, [mockaroo](https://mockaroo.com/mock_apis), or another similar tool if Mockaroo is not sufficient for a justifiable reason. -- Any user-generated images that will be displayed by your app must be temporarily mocked with a random image API service, such as [Picsum](https://picsum.photos/). -- Front-ends must include all screens in the completed application and should closely match the clickable prototypes created previously, unless the team believes an alternate user experience is beneficial. -- Ay mismatch between the clickable prototypes and the front-end app code delivered must be explained during the stakeholder demo. -- If your app will eventually have user registration and login functionality, all front-end screens to support this must be created, although they should be non-functional for now. -- Instructions on how to set up and run the project must be included in the README.md file in version control. It must be possible for anybody to follow the instructions on the README.md to build and run the entire project on their local machines. - -### Must nots... - -- State managers, such as [Redux](https://react-redux.js.org/) or [Mobx](https://mobx.js.org/README.html#introduction) must not be used. -- Account registration or log in functionality must not be included - that can be added later during back-end development. But do include the non-functional screens for these. -- Any data that will be coming from a server or API must not be hard-coded within your front-end code... mock the API for now and fetch the data from the server within the front-end code. -- Any user-generated images must not be hard-coded in the front-end code, but must be mocked with a random image service for now. - -### May... - -- You may use front-end design frameworks, such as [Bootstrap for React](https://react-bootstrap.github.io/) or [Material UI](https://material-ui.com/). -- You may use a 3rd-party module, such as [react-burger-menu](https://github.com/negomi/react-burger-menu) for a hamburger menu or other [primary navigation](https://knowledge.kitchen/Navigation_components#Global_Navigation). -======= - Front-end screens must be custom-designed to look clean, contemporary, and sharp, not like a wireframe. - Any user-generated images that will be displayed by your app must be temporarily mocked with a random image API service, such as [Picsum](https://picsum.photos/). - Front-ends must include all screens in the completed application and should closely match the clickable prototypes created previously, unless the team believes an alternate user experience is beneficial. @@ -58,21 +31,12 @@ The following requirements outline what must be, must not be, and may be done du - You **must not** use [next.js](https://nextjs.org/) or any other server-side rendering framework. - You **must not** use the front-end frameworks [Material UI](https://material-ui.com/) or [Bootstrap](https://react-bootstrap.github.io/). - You **must not** hard-code any data in your front-end code that will eventually be provided by your application's back-end or other external source. ->>>>>>> 2b503b8d496e3059af152e2a078c2f0d478bcf30 ## Grading Individuals will be graded, in part, according to... - individual code contributions, as visible through git logs - make sure you commit your own work! -<<<<<<< HEAD -- proper adherence to the [Feature Branch git workflow](https://knowledge.kitchen/Feature_branch_version_control_workflow) -- the quality of the work -- a well written and thorough [Product Backlog](https://knowledge.kitchen/Software_engineering_project_kickoff#Create_the_initial_product_backlog) -- the [proper setup of a GitHub repository](https://knowledge.kitchen/Software_engineering_project_kickoff#Configure_GitHub_repository) -- the proper setup and use of a [Sprint Task Board](https://knowledge.kitchen/GitHub_for_team_collaboration#Project_boards) to indicate the Sprint Backlog and accurate status of all of their work at all times during the Sprint -======= - proper adherence to the [Feature Branch git workflow](https://knowledge.kitchen/content/courses/agile-development-and-devops/slides/feature-branch-workflow/) - the [proper setup and maintenance of a GitHub repository](./instructions-0c-project-setup.md) - the quality of the work as a whole ->>>>>>> 2b503b8d496e3059af152e2a078c2f0d478bcf30 diff --git a/instructions-2-back-end.md b/instructions-2-back-end.md index c6e196f..bb468c5 100644 --- a/instructions-2-back-end.md +++ b/instructions-2-back-end.md @@ -1,52 +1,23 @@ # Back-End Development -<<<<<<< HEAD -Each team must have completed and [demo'd](https://knowledge.kitchen/Scrum_development_framework#Demo_for_Stakeholders) the working back-end of their group project by the end of the corresponding Sprint. -======= Each team must have completed and [demo'd](https://knowledge.kitchen/content/courses/agile-development-and-devops/scrum/stakeholder-demos/) the working back-end of their group project by the end of the corresponding Sprint. ->>>>>>> 2b503b8d496e3059af152e2a078c2f0d478bcf30 ## Technical requirements ### Musts... -<<<<<<< HEAD -- All back-end code must be generated using **Express.js**. -- All dynamic routes must be completed and must respond with meaningful JSON data. -- All static routes must be completed and respond with the requested file. -- The front-end must be updated to make requests to the back-end for all data and functionality. The two must be completely integrated by the end of this sprint. -- Each developer must have written **unit tests** using the **mocha** and **chai** modules that provide at least 10% code coverage of the back-end code. Use the **istanbul nyc** module to verify code coverage. -- Instructions on how to set up and run the project must be included in the README.md file in version control. It must be possible for anybody to follow the instructions on the README.md to build and run the project on their local machines. - -### Must nots... - -- Back-end templating frameworks, such as Pug, Mustache, Handlebars, EJS, etc, are forbidden. -- Dynamic routes must not respond with React JSX, HTML, or anything but JSON data. -- Integration with a database must not be attempted yet. - -### May... - -- Any account registration or log in functionality may be begun during this sprint, but only if all other back-end tasks have been completed. It is okay to ignore account registration for this sprint and begin work on it in the next sprint. -======= - All back-end code **must** be generated using **Express.js**. - All dynamic routes **must** be completed and must respond with meaningful `JSON` data. - All static routes **must** be completed and respond with the requested file. - The front-end **must** be updated to make requests to the back-end for all data and functionality. The two **must** be completely integrated by the end of this sprint. - Each developer **must** have written **unit tests** using the **mocha** and **chai** modules that provide at least `10%` code coverage of the back-end code. Use the [c8](https://www.npmjs.com/package/c8) module to verify code coverage. - Instructions on how to set up and run the project **must** be included in the ` README.md`` file in version control. It **must** be possible for anybody to follow the instructions on the `README.md` to build and run the project on their local machines. ->>>>>>> 2b503b8d496e3059af152e2a078c2f0d478bcf30 ## Grading Individuals will be graded, in part, according to... - individual code contributions, as visible through git logs - make sure you commit your own work! -<<<<<<< HEAD -- proper adherence to the [Feature Branch git workflow](https://knowledge.kitchen/Feature_branch_version_control_workflow) -- the quality of the work -- the proper setup and use of a [Spring Task Board](https://knowledge.kitchen/GitHub_for_team_collaboration#Project_boards) to indicate the Sprint Backlog and accurate status of all of their work at all times during the Sprint -======= - proper adherence to the [Feature Branch git workflow](https://knowledge.kitchen/content/courses/agile-development-and-devops/slides/feature-branch-workflow/) - the [proper setup and maintenance of a GitHub repository](./instructions-0c-project-setup.md) - the quality of the work as a whole ->>>>>>> 2b503b8d496e3059af152e2a078c2f0d478bcf30 diff --git a/instructions-3-database.md b/instructions-3-database.md index c7dc611..e1d09cf 100644 --- a/instructions-3-database.md +++ b/instructions-3-database.md @@ -1,31 +1,11 @@ # Database Integration -<<<<<<< HEAD -Each team must have completed and [demo'd](https://knowledge.kitchen/Scrum_development_framework#Demo_for_Stakeholders) the integration of a database into their software application projects by the end of the corresponding Sprint. -======= Each team must have completed and [demo'd](https://knowledge.kitchen/content/courses/agile-development-and-devops/scrum/stakeholder-demos/) the integration of a database into their software application projects by the end of the corresponding Sprint. ->>>>>>> 2b503b8d496e3059af152e2a078c2f0d478bcf30 ## Technical requirements ### Musts... -<<<<<<< HEAD -- A MongoDB database hosted on a [free MongoDB Atlas](https://www.mongodb.com/cloud/atlas) instance must be used to store all dynamic data of the app. -- The database must be integrated into the Express.js back-end code using [mongoose](https://mongoosejs.com/). -- Any credentials used to log into a database or other remote service must be stored in a hidden file called `.env` that is excluded from version control by adding it to your .gitignore file. Load these credentials from environmental variables into your project using the [dotenv](https://github.com/motdotla/dotenv) module. -- When receiving data from the front-end to store into the database, always do data validation before sending that data to the database. Use the [express-validator](https://express-validator.github.io/docs/) module, or something similar to perform data validation prior to sending any data originating from the request to the database. - -### Must nots... - -- Do not host a MongoDB instance locally on your own machine, unless you plan to be working offline for extended periods of time. -- You are forbidden from storing any credentials used by your app to log into remote services, such as MongoDB or 3rd-party APIs in version control. -- You are forbidden from using **HTTP Basic Authentication** or session-based authentication for any account registration or log in functionality your app requires. - -### May... - -- Any account registration or log in functionality required by an app must use **JSON Web Tokens** (JWT) to validate authorization. -======= - A MongoDB database hosted on a [free MongoDB Atlas](https://www.mongodb.com/cloud/atlas) instance **must** be used to store all dynamic data of the app. - The database **must** be integrated into the Express.js back-end code using [mongoose](https://mongoosejs.com/). - Any credentials used to log into a database or other remote service **must** be stored in a hidden file called `.env` that is excluded from version control by adding it to your .gitignore file. Load these credentials from environmental variables into your project using the [dotenv](https://github.com/motdotla/dotenv) module. @@ -36,19 +16,12 @@ Each team must have completed and [demo'd](https://knowledge.kitchen/content/cou - You **must not** host a MongoDB instance locally on your own machine, unless you must work offline for extended periods of time. - You **must not** store any credentials used by your app to log into remote services, such as MongoDB or 3rd-party APIs, in version control. ->>>>>>> 2b503b8d496e3059af152e2a078c2f0d478bcf30 ## Grading Individuals will be graded, in part, according to... - individual code contributions, as visible through [git logs](https://github.com/bloombar/git-developer-contribution-analysis) - make sure you commit your own work! -<<<<<<< HEAD -- proper adherence to the [Feature Branch git workflow](https://knowledge.kitchen/Feature_branch_version_control_workflow) -- the quality of the work -- the proper setup and use of a [Sprint Task Board](https://knowledge.kitchen/GitHub_for_team_collaboration#Project_boards) to indicate the Sprint Backlog and accurate status of all of their work at all times during the Sprint -======= - proper adherence to the [Feature Branch git workflow](https://knowledge.kitchen/content/courses/agile-development-and-devops/slides/feature-branch-workflow/) - the [proper setup and maintenance of a GitHub repository](./instructions-0c-project-setup.md) - the quality of the work as a whole ->>>>>>> 2b503b8d496e3059af152e2a078c2f0d478bcf30 diff --git a/instructions-4-deployment.md b/instructions-4-deployment.md index b082fd4..b57da80 100644 --- a/instructions-4-deployment.md +++ b/instructions-4-deployment.md @@ -4,41 +4,23 @@ Each team must deploy their completed software applications to a [Digital Ocean ## Specific requirements -<<<<<<< HEAD -- Each project must include a functioning Continuous Integration workflow, where **Circle CI** or similar hosted continuous integration server, runs a build and test cycle every time a branch is pushed to GitHub or a new pull request is issued. -- Credentials for logging into databases, APIs, or other remote services, must never be shared in version control. They are usually stored in private settings files, such as `.env` or similar, which are not included in the version control repository. And so the continuous integration server will not have access to them when testing. Use Circle CI's or other similar server's method of setting [environmental variables](https://circleci.com/docs/2.0/env-vars/#setting-an-environment-variable-in-a-project) for passing such credentials safely to the CI server. -- Each project must deploy their application front-and-back-ends to a single Digital Ocean Droplet - sign up for Digital Ocean using [this referral link](https://m.do.co/c/4d1066078eb0) to receive $100 of credit (full disclosure, I would receive $25 of credit for anyone who winds up spending $25 on Digital Ocean, but there is no need for you to spend anything since the $100 credit will easily get you through the course). -- Submit a link to your front-end code live on the web, and include that link on your README.md document. -======= - Credentials for logging into databases, APIs, or other remote services, must never be shared in version control. They are usually stored in private settings files, such as `.env` or similar, which are not included in the version control repository. - Each project must deploy their application front-and-back-ends using Digital Ocean. Use the Digital Ocean referral link shared by the instructor, which should grant you far more than enough credits to use Digital Ocean without cost. - Submit a link to your front-end code live on the web, and include that link on your `README.md` document. ->>>>>>> 2b503b8d496e3059af152e2a078c2f0d478bcf30 ## Extra credit opportunities Include a note when submitting, if you have done any of the extra credit. -<<<<<<< HEAD -- Extra credit is given to teams that have deployed to a Docker container, although a non-containerized deployment to a Droplet is fine. -- Extra credit is given to teams that have a Continuous Deployment setup, although a manual deployment is fine. -======= - Extra credit is given to teams that have deployed to a [Docker container](https://knowledge.kitchen/content/courses/software-engineering/slides/containers/#49), although a non-containerized deployment is fine. - Extra credit is given to teams that have a functioning [Continuous Integration](https://knowledge.kitchen/content/courses/software-engineering/slides/continuous-integration/#1) workflow, where an automation server, such as [GitHub Actions](https://github.com/features/actions), runs a build and test cycle every time a branch is pushed to GitHub or a new pull request is issued. - Extra credit is given to teams that have a [Continuous Deployment](https://knowledge.kitchen/content/courses/software-engineering/slides/deployment/#54) setup, although a manual deployment is fine. ->>>>>>> 2b503b8d496e3059af152e2a078c2f0d478bcf30 ## Grading Individuals will be graded, in part, according to... - individual code contributions, as visible through [git logs](https://github.com/bloombar/git-developer-contribution-analysis) - make sure you commit your own work! -<<<<<<< HEAD -- proper adherence to the [Feature Branch git workflow](https://knowledge.kitchen/Feature_branch_version_control_workflow) -- the quality of the work -- the proper setup and use of a [Sprint Task Board](https://knowledge.kitchen/GitHub_for_team_collaboration#Project_boards) to indicate the Sprint Backlog and accurate status of all of their work at all times during the Sprint -======= - proper adherence to the [Feature Branch git workflow](https://knowledge.kitchen/content/courses/agile-development-and-devops/slides/feature-branch-workflow/) - the [proper setup and maintenance of a GitHub repository](./instructions-0c-project-setup.md) - the quality of the work as a whole ->>>>>>> 2b503b8d496e3059af152e2a078c2f0d478bcf30