Projects, General
You will build a distributed implementation of a board game over the course of this semester. You will get a chance to plan the project and its milestones, but the instructor will post the actual specifications that you must implement.
By reflecting on the differences between your ideas and the actual weekly milestones, you can gather some insights on how to manage your first project.
Most project assignments will require (1) the design of a component interface and (2) the implementation of some (other) component to a given interface. As in the real world, the project assignments will become available only a short time before they are due. As you rush to complete your projects, don’t forget, however, that performing tasks systematically and according to a design plan increases the likelihood you produce software that you can read and improve four weeks later.
Pair Programming You must work on all projects in pairs. Pair programming means that you do everything together, jointly in front of a single computer.
Once you confirm your partnership with an email to the TA of your section (see General), the two of you will get a joint account on the College’s github.
Scheduling Exchange contact information with your partner immediately, and write it down in your Lab Book.
Project Submission All of your work will live on your github account. On the specified due date and time, a script will harvest your work.
Your assigned github account is your only means to submit projects.
Code of Conduct You must perform all work with your chosen partner. You must not discuss the weekly projects outside of this partnership. Once you see other people’s solutions to weekly projects in class, you may choose to modify your own in response to these presentations.
Delivery, General
login-students
This machine might get overloaded during the semester so you should avoid it. As of this semester, the Systems group no longer provides physical Linux machines, only Virtual Machines. For a list of those, see below. You can log into those via SSH or virtual desktops (probably especially useful for the Windows users among you).
For general knowledge about the CCIS Systems world, see their knowledge base page. If you are unfamiliar with Linux, you may wish to peruse the following parts of the page:
the topics below the Unix/Linux tab (bottom of the page),
the virtual machine (VM) tab, and
the networking tab for how to log into "headless" VMs.
Design Reviews, Code Walks
The goal of a design review/code walk is to obtain an overview of a specification or code base and to discover its problematic parts.
Introduce yourself.
Remind the readers of the task for which you present a design/code repo.
Start with an overview; the README is often helpful here.
Run the unit tests.
Present the components and their functionality in a top-down fashion, that is, start with the important one and navigate to those that you think are complicated and possibly broken.
Refine as the panel requests.
the presentation suggestions from above;
the desire to work with the panel on the most difficult parts of the project. For example, a presenter should never ask "what do you want to see next".
the presenter’s ability to work with the panel in an interactive manner. In particular, a presenter should never discuss problems abstractly but always direct the attention of the panel to concrete pieces of design documents, comments, or lines of code.
the presenter must know when to acknowledge a potential problem in the code and, equally important, must realize when it is time to reject criticism with concrete justifications (point to a test, highlight a part of your specification).
each presenter is in obvious command of all the code, because the code is created in pair-programming sessions.
head reader; as such you are responsible to keep the presentation on track;
assistant reader; you and the head reader find mistakes, omissions, and questionable design decisions;
secretary; you keep track of the questions that the readers ask, note discoveries of problems, take notes, and summarize the to-do items as a memo.
OK+ means the reader discovers solid problems and articulates them well. This appears to depend on the quality of the code bases. Because all code bases are somewhat flawed, however, the quality of the presented code doesn’t really affect your ability to get this grade.
OK means the reader asks pertinent questions and discovers some problems.
OK- means the reader asks questions and some of them are pertinent.
ZERO means the reader didn’t ask any questions or asked too few questions pertinent to the code/design at hand.
When you are secretary you are responsible to get a copy of the written notes to the TA of your section within 24 hours. Once the report is acceptable, we will forward it to the reviewed pair; until then, we will request edits.
the presenters
the panelists
the title of the project presented
the date and time
a bullet list of problems discovered. Describes those problems in enough details so that the presenters can reconstruct it and fix it from the information specified.
If the panel discussed potential solutions with the presenters, include these suggestions with the appropriate bullet.
The evaluation of a memo will take into account the timely delivery of the first draft, its format, its information content, and basic English writing (typos, grammar mistakes). The latter will affect your grade in a serious manner if the mistake allows a misinterpretation of a sentence or if the mistake makes an interpretation extremely difficult.