October 26: Final Team Project Demo: In-class app demos and wrap up discussion.
October 17: Google visit
October 9: Start of weekly coaching meetings and Retrospective reports
September 26: First demo!
September 21: Hybrid setup report and four-panel storyboard.
September 19 Day One -- What each team needs to prepare for the first day of class!


TTh 11am - 12:20am


Tech M164


Chris Riesbeck


Github Setup Tips

If you want one technical skill that every employer looks for, it's experience using source control. They specifically look for experience with:

Versions of git exist for Linux, Windows, and MacOS.

A popular alternative to github is Bitbucket. Bitbucket lets you have private repos for free, but limits you to five team mates. Since your code needs to be available to me, your team, the class, and your clients, do not use Bitbucket. Even if you think this might be the germ of the next great app, open-source your startup. If you have to hide your idea, it's not a good one.

If your client for the client project wants a private repo, their best option is for them to purchase a private Github micro repo. These are cheaper than Bitbucket. This way, the client owns the repo and maintains control when the project ends. If the client does this, they need to add both the team and me to the repo.


There are lots of tutorials. The basic actions you need to take for this class are:

Tips and Warnings

Be careful with the git for Windows GUI.

Some teams in Fall 2012 had synchronization issues with this GUI when swarming and making frequent commits. They had better luck just using the command line.

Use .gitignore

Keep .gitignore up to date in order to

  • avoid storing things like compiled binary source files that can slow down push and pull operations
  • make sure all important files, including installation scripts, to-do lists, etc., are available to everyone on the team, and even the client

Pull often.

Don't work with out of date code.

Branch briefly, push often.

Keep branches to a day or so. Otherwise, you will have integration problems at the worst possible time, when you're trying to deliver to the client or end users.

Never push untested code.

Break big scary changes into harmless little ones.

For example, adding the ability for users to have multiple email addresses by replacing an "email" column in the user table with a new "user email" table. This is a classic scary change to database structure that can break a lot of your code. But you can easily make the changes in a series of safe, non-disruptive, testable substeps, any one of which could be rolled back easily. Remember to pull often.

  1. Add the new table, but change no existing code, remove no columns. Run existing tests and push.
  2. Write code to copy data from existing column to new table. Still change no existing code or columns. Write tests to verify data matches. Run tests and push.
  3. Change existing code that updates existing column to also update new table. Run tests and push.
  4. Change existing code that reads existing column to instead read new table. Run tests and push.
  5. Drop existing column. Run tests and push.