class03-final-project

Main repository for the final project for Class 03

Note that the project is split into two sub-projects. One for the client and one for the server. Further documentation in these folders.

Work stories

First iteration

1A: When I find interesting content I need to be able to share it so others can benefit.

1B: When I feel like learning something new I need to discover content so that I can learn.

1C: When I have selected an item I need to be able to learn more before I read it in full length so I don’t waste time on the wrong content.

Second iteration

2A: When I am selecting what content to read I need to see ratings so I don’t waste time on poor content.

2B: When I find a good learning resource shared by another user, I want to be able endorse (upvote) it, so others can make qualified decisions about what to read.

2C: When I have decided on a piece of content to read/watch I need to be able to go to it directly so I know for sure I am watching the right content.

Third iteration

3A: When I want to explore a specific topic I need to see a list of categories related to that topic so I don’t manually have to browse all of the content.

3B: When I am browsing a topic I need to be able to find content that match my current skill level so that don’t get overwhelmed.

Process

We suggest the following process for working on the project:

1. Understand the product. Why is it necessary? What does it do and how does it do it?
2. Decide on what your architecture will look like. This is mostly given, since all classes have been focusing on a single type of architecture, but make sure you understand what you are building and why you are building it.
3. Get a simple "hello world" style of prototype running utilizing the entire stack (i.e. have the React application query the API that will return a string of text fetched from the database). Don't try to implement the actual application yet. Make sure that functionality such as connecting to the database is
4. Break the UI into a component hierarchy.
5. Design a data-model for your database that will allow you to store and query the data you need.
6. Build a migration script that will allow you to easily set up any tables you need in your database and fill it with test data.
7. Build a static version of the UI. Don't worry about functionality yet. If you discover discrepancies in your component break-down as you build, update the breakdown.
8. Start thinking about what components should be stateful. Add container components as needed.
9. Start wiring up all of the functionality, fetching the data from the API and implementing real functionality as opposed to having just static components.
10. Plan development so you can stop developing any new features in the last 10-15% of the project (4-6 days). Use this time as a "feature freeze" period, where you focus on "hardening" the product by testing and fixing bugs.

Working with GIT and handing in iterations

We expect to see running code at a regular frequency, so the product has been broken up into iterations. You are expected to finish approximately one iteration per week. We expect to see each iteration as a pull request on github so we can give you feedback directly in code.

To hand in and get feedback on your iterations you must follow this process for working with git and github:

• One member in each group must make a fork of the original repository. A fork means that you are making a copy of the repository on your own github profile.
• The member who has made that fork must go to settings and add his team members and the mentors as collaborators
• Whenever you start working on an iteration make a new branch from the master branch and name it accordingly (ì.e. iteration-1)
• It is recommended that each team member make a branch off of the iteration-1 branch and name it based on the work he or she is going to be doing (i.e. work-story-1a-api-endpoints if you are going to be working on API endpoints for the work story 1A)
• When you have managed to make the new code work on your local computer, commit your work to your personal branch and push it to github.
• In the github interface find your personal branch and make a pull request towards the iteration-1 branch. Share the link with your team member(s) and ask for feedback.
• All team members should read through pull requests from other members and do as much as they can in terms of asking questions and researching in order to understand what other members have done. The team memebers should perform a review and either approve or request changes to the code before it can be merged.
• Once the other team members have reviewed the pull request, go to the github interface and merge the pull request.
• Once you have an iteration ready and need feedback from the mentors, make sure all work is merged to the iteration-1 branch and then create a pull request towards the master branch. Post the pull request link in the main Slack channel.

To get feedback before a sunday session, pull requests must be created saturday at midnight the latest.

If you are worried that only one member will have the project on his or her github, there is no need. People can see any contributions you make to open source repositories whether it is on your profile or not. After the project is finished we recommend that the remaining team members fork the finished repository from their teammate, to make it easier to showcase the project on their account.