Meeting Minutes for Group A – January 27th, 2013


  • This is the first official meeting of meeting group “A”. We’re having to split the team up into two groups due to free times not lining up with everybody. The second meeting time will be announced soon, hopefully.
  • If you asked for a VMWare Workstation license key from ChipX86 during the hackathon, get in touch with him – he’s able to send them to you now.
  • Just a note that the form of these meetings is still fluid, and their form and purpose might change as the semester rolls onward.

Q / A:

Q: How can we review the code of other students when we’re still getting familiar with the codebase?

A: It’s true that this will be difficult at first, and is part of the challenge. This will become easier as the semester moves forward and you get used to our codebase and our style. Remember that code reviews don’t always have to find defects. You can also ask questions about the code if something is not clear enough for you. Perhaps this is indicative that the reviewee needs to add more documentation to make it more clear. Questions about “why did you choose to do X instead of Y?” are perfectly valid. It’s also valid to simply compliment a piece of good, clean code.

What will happen is that you’ll quickly start to get a sense of how the application works, both by working on your projects, and by viewing the code that other people submit. This gives you a broader opportunity to get the “big picture” of how everything fits together. Seeing how your peers and mentors review code is also a good learning opportunity.

So don’t be shy. Get in there. Review code. Ask questions.

Q: Git question – I made a branch, and committed some code to it. Then, I pushed that branch to my Github fork. Then I checked out master, pulled from origin, and rebased my branch on the new pull of master. Now I can’t seem to push to my fork. What happened?

A: Basically, you changed history. Rebasing disrupts the orderly flow of commits on top of a branch and allows you to manipulate them in somewhat destructive ways. When you rebased your branch on top of master, you rearranged the commits in your tree in a way that your fork has no notion about. Because you changed history (instead of merging in the changes from master, which adds commits instead of rearranging old commits), Github says that you can’t push. It does, however, give you the option of force pushing (with –force or -f when pushing). This essentially blows away your forks branch, and overwrites it with your new branch. This is a bad idea if you’re sharing this repository with other people (in which case you should merge), but it’s fine if it’s just your backup fork / branch.


  • Check out this handy list of curated blog posts. Learn from the wisdom of previous students! These are also great examples of students blogging not because of a course requirement, but because they had something they wanted to share.
  • About getting reviews – inevitably, you’re going to get reviews that are really large, or say things like “Can you restructure this to do <…>”. It may feel frustrating to hear that something you wrote needs to be rewritten in some way. Try not to let that get you down. That’s going to be a common thing in professional software development.  You can mitigate this somewhat with WIP patches, a or a quick sanity-check e-mail / IRC discussion to get early feedback and redirection.
  • Also, remember, your mentors are only human. We don’t have an answer book. Sometimes we don’t have the right answer and have to mull about it too.
  • Send actions in IRC with “/me action”, for example, “/me does backflips” looks like “mconley does backflips”


  • Greg is waiting on review for his two review requests.
  • Greg mentions that the review editor (the screen that comes up when a reviewer chooses to “Edit Review”) is ugly and needs some re-work. Everyone else heartily agrees. Might make a good student project if anybody wants to take that on.
  • If you haven’t already sent mconley your WordPress account email (or username), please do so now.
  • The blog posts that you write on this blog are yours to own. You own the copyright. Similarly, the code that you contribute to the project is MIT licensed, meaning that you can take the code and use it for other things if you’d like.
  • mflores looked at the project list and is tentatively looking at extensions sandboxing, and mobile device support.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s