- Dan S. Wallach, Associate Professor of Computer Science.
- Graduate teaching assistants:
- Michael Dietz, Shashi Shekhar, Yuliy Pisetsky, Caleb Spare
- Undergraduate labbies:
- Nick Bridle, Rick Manning
- Office hours:
- Any of the teaching staff will be happy to meet you by appointment; the instructors and TA have offices in Duncan Hall which make this particularly convenient.
- Help NOW:
- For some quick help, stop by the course's IRC server. The staff are likely to be trolling, especially during the IRC office hours (to be determined).
Introduction to Algorithms (Second Edition) [Required Text]
Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, and Clifford Stein
Hardcover - 1180 pages (2001)
Note: the third edition is now out. For our purposes, it covers the same material and you can use either book. The third edition only adds new material with respect to one lecture in comp314.
The Pragmatic Programmer [Required Text]
Andrew Hunt and David Thomas
Softcover - 321 pages (2000)
- 80%: three class projects
- 15%: homeworks
- 5%: professionalism (class participation, conduct, non-flakiness, etc)
Homeworks are (typically short) programming assignments for you to complete, individually, over the course of a week. You should consult your peers only for assistance on general concepts or mechanical issues (getting Eclipse to work, getting JUnit to run, using Subversion). At no point should you be looking at another student's code; see Honor Code below.
Projects (list) are large programming enterprises that span three weeks:
- Week 1: Specification. As described in the first lecture, you are to design your solution to the problem posed. Develop a technical specifications document for your solution and submit it by tagging in Subversion (that is, copying your trunk to tags/spec; see also the svn tutorial). The guidelines for your specification are found here. You will already have been assigned a grading team (your “liaisons“); you must schedule a meeting with your liaisons to “check-off” this milestone and get feedback.
- Week 2: Beta. You will turn in (by tagging beta) your entire codebase. Also included will be your spec, which must be updated to reflect your current implementation. Your program and test cases should be mostly fleshed-out, and highly functional, if not entirely complete (there may be test cases, bugs, or a few small pieces of implementation left). The beta milestone should convince us that you know what you’re doing and are in good shape for the final. You will include a plaintext README file which explains how to compile and run your program and tests. This guide on packaging your code may prove useful here. You must schedule another milestone check-off meeting.
- Week 3: Final. Final code, final spec, final README explaining how your project works and what you did and did not get finished. (No meetings this time, but come to class for a debrief.)
Project grading rubric:
Projects are worth 25 points. Each point comes out to 1% of your final grade, as well, so each project is essentially a quarter of your comp314 grade. The points break down as follows:
- Spec: 5 points
- Clarity [1 point]
- Schedule (present, believable) [1 point]
- High-level discussion (purpose, user interaction, I/O) [1 point]
- Low-level discussion (algorithms, complexity, testing) [1 point]
- On-time completion of the above [1 point]
- Beta: 5 points
- Significant functionality [1 point]
- Unit tests covering most submitted code [1 point]
- Javadocs covering most submitted code [1 point]
- Spec and estimates updated; complete README [1 point]
- On-time completion of the above [1 point]
- Final: 15 points
(Exact point values for the following will vary from project to project.)
- README: Present, showing how to compile and run the program, how to use any included input files, and any late hours used
- Spec: All required features described
- Spec: Correct efficiency/complexity discussion (big O)
- Spec: In sync with code
- Spec: Completeness (sufficient information for any other comp314 student to implement your design)
- Spec: Clarity of writing, presentation, etc.
- Spec: Schedule (estimates & actual figures)
- Javadocs: Present for all classes and functions
- Javadocs: In sync with code
- All required features implemented
- Correctness of implementation
- Organization: Modular, maintainable code
- Appropriate (tasteful) use of OOP, design patterns, &c.
- Correct handling of abnormal inputs
- Errors handled gracefully (no abnormal exit, e.g. RuntimeException with stack trace)
- Good code style (see also: lecture 5, slide 80)
- Testing (See also notes on testing)
- All major functionality covered in unit tests
- All included unit tests pass
- Automated testing
- On-time completion of all of the above [points: see “Lateness”]
README and code packaging:
Your code submissions (that is, both beta and final) should be organized in such a manner that they can be executed from a commandline using the commands javac and java. Another acceptable alternative is to package your project using ant. Although we encourage the use of Eclipse for development, you should NOT assume that your graders will use Eclipse. In any case, you should document how to compile, test, and run your code in your README file. See this guide for some useful tips on how to package your code in an acceptable form and for more detail on the README.
Because grades in comp314 are so strongly tied to your class projects, and because class projects are done in groups (pairs), your grade necessarily becomes entangled with your partner’s. In order to address problems we have had in the past, comp314 has a hard and fast rule:
You flake, you fail.
If your partner is counting on you and you disappear, it hurts your partner. As much as possible, we wish to prevent this. By “flaking,” we mean being unresponsive (over a period of days, or hours at a crucial time) to e-mail and other attempts to contact you. You are expected to pull your own weight in this class.
If you flake, we will reassign your partner and you receive an instant ‘F’ as your grade for the project. Your professionalism grade is forfeit as well.
Alternatively, if we determine (based on complaints, inspection of code, etc.) that one partner exerted a disproportionate share of the effort, we may arrange a non-equal distribution of the project points, at our own discretion.
Students should not assume that we will invoke any of these rules. However, we do encourage students experiencing problematic partners to contact us early so we can politely remind everyone of their responsibilities.
We also recognize that things happen in your life that are beyond your control and that require you to reprioritize your time. In these cases, you are responsible for contacting your partner(s) as well as the course staff as soon as possible to explain your predicament.
In the event you are considering dropping comp314, your timing matters. Programming projects last three weeks. The time to drop is between projects. By staying in the class, you are making a personal committent to your partner to complete a project after you have begun it. Dropping mid-project is extremely rude to your partner.
The late policy for homeworks and for project final milestones—as determined by the timestamps on your svn checkins—is as follows:
- −2% for each hour late, up to and including 3 hours.
- If more than 3 hours late, then −10% for each day late, up to 4 days.
Things you should be aware of if you turn your project’s final milestone in late:
- In your README, note how late your assignment is, and what the published deduction is (−1 if labbies have to re-calc this).
- Except for a 5 minute grace-period/clock-skew-allowance, timestamps will be strictly interpreted. Note that in the case of projects we will specifically be looking at the timestamp of the milestone tag (spec, beta, or final), so you can continue working in trunk after you’ve tagged your submission.
- Fractional hours/days are rounded up.
- The count of hours/days late includes weekends.
Note that, as per the grading rubric above, missed project spec and beta deadlines result in a loss of one point, regardless of how late you are. (Don't abuse this! The later you turn in your milestones, the less time you have to get our feedback and finish the project.)
While you are encouraged to have discussions with your peers in this course, there are a number of situations in which we require you to keep quiet.
Homeworks are designed to encourage (and assess) individual retention of course material, and are therefore to be completed on your own. While you can (and should!) discuss the lectures and topics of the class with one another, we draw a line at explicitly helping with the homework problems or code. If you get stuck on the homework, get in touch with the teaching staff; we’ll be glad to set you on the right path.
What you should and shouldn’t share depends on the phase of the project.
- Design, before the spec milestone. We wish every group to come up with its own independent project design. If you are exposed to other designs before the staff has checked off on your own work, then we cannot distinguish between your ideas and those of your peers. After you have your spec milestone check-off meeting, you are free to discuss your design with others in the class, possibly including wholesale borrowing from your peers. We expect you to cite your sources; it’s okay to borrow a design (post check-off), but you need to give credit where credit is due.
- Implementation code. The specific code you write should be kept private among the members of your group. You should take appropriate measures to prevent stray eyes from seeing your code while a project is under way. However, after a project’s final deadline has past, you may freely make your code available within (and beyond) the class. (We hope you’re proud of your projects and will want to share them!)
- Technical assistance. You are encouraged to help your peers with all the technical issues involved in using Java and the system class libraries. This may mean leaking some details of your design (e.g., “oh, it’s much easier if you build your system to accept and dispatch GUI events from the widget system.”), which is acceptable in moderation. It may also mean leaking snippets of source code (e.g., “here’s a test program I used to get the GUI system to do ‘Hello, world.’”). You must use your own discretion in choosing what you leak. Helping your peers understand the problem is good. Giving away your solution to the problem is bad.
- External resources. You are explicitly permitted to consult any external resource you can get your hands on, including textbooks, source code, or friends outside of comp314. Cite your sources. Also, for people outside of comp314, make sure to explain why you’re asking a question (and don’t let them just solve the problem for you.) With regard to incorporating code written outside of comp314 in your own solution, this will depend on the specific project. Generally, external code that, in some general purpose fashion, helps you out is okay (e.g., a better GUI layout system), but external code that largely solves the problem you’ve been assigned is forbidden. Consult the course staff if there’s any doubt.
- Materials from previous years. We reuse some materials from prior years of comp314, including homeworks and projects. Stay away from it. If you use the work of a prior comp314 student, for a project or a homework, with or without giving credit, you will be considered to be cheating and you will be referred to the Honor Council.
Any student with a documented disability seeking academic adjustments or accommodations is requested to speak with me during the first two weeks of class. All such discussions will remain as confidential as possible. Students with disabilities will need to also contact Disability Support Services in the Ley Student Center.