Comment on page
Very Best Project Guide
Your primary objective is to start with a half-completed codebase and make it match this target. Note: your job is not to make the tests pass; your job is to match the target. Do not ask about test failure messages until you manually test the functionality in your browser and it is working.
Here are some things to do along the way that might be helpful:
The primary goal of this project is to give you experience with a real software development workflow. To that end, it will be more realistic if you collaborate with others and see how that is managed.
You can form a team of up to three people; any more than that will be cumbersome for beginners to the Git-based collaboration workflow that we'll learn.
One of the team should fork the repository to their own account. By clicking on the assignment in Canvas, it should fork automatically, just like any other homework.
Under "Settings" of your fork on GitHub.com, add your other team members as collaborators.
All three of you should now be able to see the repository under your list on Cloud9. You should each set up your own workspace as usual.
bin/setup, click "Run Project", and navigate to the live app. It's the code that was generated by the Ideas tool, with some dummy data pre-populated. Click around and exercise the app, and study the generated code.Click through the target and try to identify discrete tasks required to bring your app to parity with it; e.g., "Remove extraneous links from navbar". Try to break these tasks down into pieces that are as small and bite-sized as possible.
Once you've agreed on and fleshed out the list of tasks, move them to Next Up and sequence them.
Each person should take a card from Next Up and "put their face on it" (i.e. add yourself to it as a Member). From the
/git page, create a branch off of the master branch, and start making commits as you work on your assigned feature. (It's a good idea to get in the habit of always Pulling the latest version of master down from GitHub before creating a new branch off of it.)When you're ready for feedback on your task, open a Pull Request and add your teammates as Reviewers.
Review each others code carefully and ask questions about it and/or suggest improvements. You can leave line-by-line questions/comments in the "Files Changed" tab of the Pull Request.
Watch this great talk about the importance of a strong Code Review culture:
There are a few
rails grade:all automated tests in this project, but they don't cover every single behavior that is in the target. It's up to you each to QA one another's work and make sure it's doing the right thing(s), the way that a client or project manager should. Ultimately, when you're satisfied, you can approve (or "Accept") the feature.It's very common as you QA a feature to realize some additional functionality that is required, beyond the work initially identified in the card. Resist the temptation to expand the scope of this card.
Instead, make a new card for the additional functionality, put it in Next Up, and sequence it according to its priority versus the other pending tasks. There may well be much more important tasks to do before fine-tuning this one.
Once everyone has signed off on the feature, merge your branch into
master:If you've modified a line in a file that was also modified by someone else in the meantime, then you might have to resolve the conflict. That might involve just discarding one version or the other, or it might involve writing some new code that intelligently combines both sets of changes. GitHub's interface should walk you through it.
Go back to the Next Up column and grab a card near the top and put your face on it.
Very important: Whenever you start a new branch off of
master, be sure to first Pull so that you have the latest starting point. Otherwise you'll have more Merge conflict headaches later.Last modified 4yr ago