|
|
#  Project #3: Group Project
|
|
|
|
|
|
## Overview
|
|
|
|
|
|
For your 3rd project, you will be collaborating to make an application using Angular.
|
|
|
|
|
|
Use your imagination! You get to create whatever you want for this app. Everyone will get a chance to **be creative**, and work through some really **tough programming challenges**, but you'll have a partner to help you carry the load.
|
|
|
|
|
|
## Technical Requirements
|
|
|
|
|
|
Your app must:
|
|
|
|
|
|
* Use a **Angular** as a front-end framework.
|
|
|
* Reference a third-party API.
|
|
|
* Be deployed online where the rest of the world can access it.
|
|
|
|
|
|
|
|
|
## Requirements before you get started
|
|
|
### Please put these in your `README.md` file:
|
|
|
|
|
|
* **User Stories** -
|
|
|
* **Wireframes** - One for each page / view of your application.
|
|
|
* **MVP** - A minimum viable product which has just those core features sufficient to deploy the product, and no more.
|
|
|
* **Stretch Goals**
|
|
|
* **Github Repo** and use of **branches** - This should be outside of your wdi-remote class repo. One person should create this and then make their partner a "Contributor".
|
|
|
|
|
|
## Once your project is approved
|
|
|
* Creat a **daily tracker** with a day-by-day breakdown of what features will be worked on to meet the MVP and any stretch goals that you would like to tackle
|
|
|
|
|
|
### Suggestions on how to get started
|
|
|
* **Break the project down into different components** (data, presentation, views, style, DOM manipulation) and brainstorm each component individually.
|
|
|
* **Use your Development Tools** (console.log, inspector, alert statements, etc) to debug and solve problems
|
|
|
* Work through the lessons in class for help and inspiration! Think about adding relevant code each day; COMMIT OFTEN. We will be looking at your commit dates and comments are part of your scoring.
|
|
|
* **Commit early, commit often.** Don’t be afraid to break something because you can always go back in time to a previous version.
|
|
|
* **Consult documentation resources** (MDN, jQuery, etc.) at home to better understand what you’ll be getting into.
|
|
|
* **Don’t be afraid to write code that you know you will have to remove later.**
|
|
|
|
|
|
|
|
|
## Deliverables
|
|
|
|
|
|
By the time the project is over, we will expect the following from you:
|
|
|
|
|
|
* A **working app, built by you**, hosted somewhere on the internet
|
|
|
* A **link to your hosted working app**
|
|
|
* A **git repository hosted on Github** NOT inside your wdi-remote repository. Frequent commits dating back to the very beginning of the project
|
|
|
* **A ``readme.md`` file** with explanations of the technologies used, the approach taken, a link to your live site, a link to your daily tracker, your user stories, mvp, stretch goals, installation instructions, unsolved problems, etc.
|
|
|
|
|
|
Most importantly a **technical demonstration** of your app which:
|
|
|
|
|
|
* Is 5 minutes in length
|
|
|
* Shows off all features of the app
|
|
|
* Explains the technical details
|
|
|
* Explains the technical challenges
|
|
|
* Explains which improvements you might make
|
|
|
|
|
|
## Project Feedback + Evaluation
|
|
|
|
|
|
* __Project Workflow__: Do you have a Github respository for your project (not inside your wdi-remote repo) and make good use of branching? Did you complete the user stories, wireframes, and the README.md file as specified above? Did you use the daily tracker and split the work load appropriately?
|
|
|
|
|
|
* __Technical Requirements__: Did you deliver a project that met all the technical requirements? Given what the class has covered so far, did you build something that was reasonably complex?
|
|
|
|
|
|
* __Creativity__: Did you add a personal spin or creative element into your project submission? Did you deliver something of value to the end user (not just a login button and an index page)?
|
|
|
|
|
|
* __Code Quality__: Did you follow code style guidance and best practices covered in class, such as spacing, modularity, and semantic naming? Did you **comment your code** as your instructors have in class?
|
|
|
|
|
|
* __Deployment__: Did you deploy your application to a public url?
|
|
|
|
|
|
* __Collaboration__: Did you contribute to the project as much as you should have (did you pull your weight)?
|
|
|
|
|
|
* __Total__: Your instructors will give you a total score on your project between:
|
|
|
|
|
|
|
|
|
Score | Category | Expectation | Expectation | Expectation | Expectation | Expectation |
|
|
|
:-----: | ------------ | ---------------- | --- | --- | --- | --- |
|
|
|
**7** | Project Workflow | Do you have a Github respository for your project (not inside your wdi-remote repo) and make good use of branching? (0-2) | Did you complete the user stories, wireframes, and the README.md file as specified above? (0-3) | Did you use the daily tracker and split the work load appropriately? (0-2) |
|
|
|
**10** | Technical Requirements | Did you use Angular as a front-end framework? (0-2) | Did you use a third-party API? (0-2) | Did you deliver a project that met all the technical requirements? (discussed in your MVP (a score between 0-3 will be given))| Given what the class has covered so far, did you build something that was reasonably complex? (complexity will be given a grade 0-3) |
|
|
|
**5** | Creativity | Did you add a personal spin or creative element into your project submission? (0-2)| Did you deliver something of value to the end user (not just a login button and an index page)? (0-3) |
|
|
|
**2** | Code Quality | Did you follow code style guidance and best practices covered in class, such as spacing, modularity, and semantic naming? (1) | Did you comment your code as your instructors have in class? (1)|
|
|
|
**1** | Deployment | Did you deploy your application to a public url? (1)|
|
|
|
**3** | Collaboration | Did you contribute to the project as much as you should have (did you pull your weight)? (0-3) |
|
|
|
**2** | Technical demonstration | Is 5 minutes in length & shows off all the features of your app. (1)| Expalins technical details, technical challenges, and any improvements you might make. (1)|
|
|
|
_Maximum possible points_ | **30** |
|
|
|
|
|
|
|
|
|
---
|
|
|
# Project Week
|
|
|
|
|
|
## Attendance
|
|
|
You are required to be present by 10:00 am EDT and again at 2:30 pm EDT each day during the project.
|
|
|
|
|
|
## Standups
|
|
|
We will have student-run stand-ups each morning at 10:15 am EDT where you will answer the following questions:
|
|
|
- What did I work on yesterday
|
|
|
- What am i trying to get done today
|
|
|
- What is preventing me from getting this done.
|
|
|
|
|
|
This meeting should take no longer than 15 minutes.
|
|
|
|
|
|
If you have ideas on how you can help a fellow-student with work that they are stuck on, please follow-up with information AFTER the stand up.
|
|
|
|
|
|
## Meetings with instructors
|
|
|
_Your instructor will contact you to setup a meeting time_
|
|
|
|
|
|
**Tuesday, June 7**<br>
|
|
|
15 minute meeting to get your project approved. You will come with your [MVP](https://en.wikipedia.org/wiki/Minimum_viable_product) and an initial wireframe.
|
|
|
|
|
|
**Wedesday, June 8**<br>
|
|
|
15 minute progress check-in
|
|
|
|
|
|
**Thursday, June 9**<br>
|
|
|
Whole class instruction on how to deploy your project to the world wide web.
|
|
|
|
|
|
**Friday, June 10**<br>
|
|
|
15 minute check in to see where you are before you go into the weekend. Help you to decide what to finish and what features should be stretch goals.
|
|
|
|
|
|
## Where to go for help during project week
|
|
|
1. Seek out help online
|
|
|
2. Seek out help with your classmates
|
|
|
3. Seek out help with Derek (TA)
|
|
|
4. Submit a Github issue **on the wdi-remote** class Github account to receive help from an instructor
|
|
|
|
|
|
## Formatting your GitHub Issue for wdi-remote to ask for help
|
|
|
|
|
|
*PUSH OFTEN! Your code on GitHub should be up to date. Submiting an issue and linking us to old, out-of-date code will hinder the process.*
|
|
|
|
|
|
1. **WHAT YOU ARE TRYING TO SOLVE:**
|
|
|
- Write a detailed explanation of the feature or user story you're working on.
|
|
|
|
|
|
2. **DETAILED DESCRIPTION OF THE BUG/ERROR:**
|
|
|
- A detailed description of the problem, the bug, and/or the error. This means: the full steps to reproduce, a link to the file on github, and the line number of where the relavent code is.
|
|
|
The error(s) returned, copy and pasted/typed out/screenshot, not paraphrased.
|
|
|
- If there is other code in a different file that is also essential to the functioning of the code that currently works point us to that and explain the relationship.
|
|
|
|
|
|
3. **WHAT I'VE TRIED**
|
|
|
- List everything you've done to solve the bug on your own in detail. list all resources you've looked up and tried to implement and provide links. Providing code if you have it surrounded by the md syntax to display nicely is very helpful.
|
|
|
|
|
|
4. **QUESTION**
|
|
|
- After going through all this what is your questions specifically, more specifically than how can I make this work?
|
|
|
|
