Day 8 – Th, Jan 31, 2013¶
Rough schedule for today, summary:
- reviewing git & taking questions
- version control principles
- back to drinkzing
- use cases!!
- minute cards
Note: mailing list archive is at http://lists.idyll.org/pipermail/cse491-spring-2013/
Reviewing git and taking questions¶
See Day 6 – Th, Jan 24, 2013, “Resolving conflicts during merge”, and Day 7 – Tu, Jan 29, 2013.
At this point, I’m assuming wrt git –
- you know enough git to handle many things
- you can work through most problems
- you’ll ask questions if you need help
Also see the various e-mails recommending git tutorials - here, here, and here.
Some version control principles¶
- Commit often
Divide your work up into small discrete chunks, and every time you complete a chunk, commit. This is simply good practice.
In collaborative work, remember: the last person to merge has the most work to do, so if you’re working collaboratively, try to get complete “chunks” of work (new features) committed at a high level of granularity, so that other people have to do the work of merging.
- Only add/commit files that aren’t automatically generated.
For example, Python compiles .py files into .pyc files; don’t commit those to your repository! (Also see .gitignore, in the root directory; this will tell git which files it should ignore when you do ‘git status’.)
- Don’t commit any unnecessary files or changes.
I use ‘git status’ and ‘git diff’ liberally to make sure that only intentional changes get committed. This should not include “whitespace” changes, commented out code, etc.
- Run your tests before committing, and again before pushing.
Never commit/communicate code that you know is broken, unless you have a reason to do so.
New functionality in drinkz¶
What do the merges you merged last week actually do?
Use cases!!!¶
Check out the README for drinkz:
To guide development of new features, software developers often design what use cases. These are, at a high level, little stories about what users or customers want to do. For example,
Brian has a liquor cabinet and a bunch of drink recipes that use various types and amounts of liquor. He wants the ‘drinkz’ site to output a shopping list for him based on a set of drink recipes he selects.
This use case drives a number of design considerations for the site database:
- The site has to be able to store Brian’s drink inventory.
- The site has to be able to store Brian’s recipe inventory.
- The site has to be able to correlate Brian’s drink inventory with the recipe.
It also drives a number of user interface considerations, but we’ll get to those in the new weeks.
Brainstorming¶
Individually or in a group, brainstorm a bunch of use cases that center around activies based on one or more liquor cabinets, and one or more recipes. Remember that “customers” in this case can also include business-to-business customers like markets that want to advertise on your site, offer discounts, etc. Any way that you can make a buck ;). (Ignore all privacy and ethical concerns for now.)
Prepare to present three use cases as a table. They should be different from the use cases presented by the other tables ;).
Minute Cards¶
In the last 5 minutes of class, please fill out this minute card survey.