6.170 / Spring 2001 / General Information

Handout A1

• Course web site
• Registration Form
• Staff
  • Staff Hours
  • Who to Ask
• Texts
  • Required Text
  • Recommended Java Texts
  • Other References
• Where and When
  • Lecture/recitation
  • Labs
  • Quizzes
• Policies
  • Grading policy
  • Late/missing work
  • Collaborative work
• Procedures
  • Handouts
  • How to Submit Assignments
  • Graded Assignments
  • Re-Turning in Assignments
• Problem set hints

Course web site

Registration Form

For the final group project your team must consist of people from the same recitation as yourself. Since you will not be permitted to change recitations after they are assigned take care when listing the people you would like to be in a recitation with. The list of people you wish to work with should be consistent amongst yourselves.

Staff

Mail sent to 6.170-staff@mit.edu will reach the lecturers, TAs, and LAs.
Mail sent to 6.170-lecturers@mit.edu will reach the lecturers.
Mail sent to 6.170-tas@mit.edu will reach the teaching assistants.
Mail sent to 6.170-las@mit.edu will reach the laboratory assistants.

Staff Hours

TAs will schedule office hours and locations by the end of the first week of class. Please visit your TA (or another TA, if necessary) during their office hours if you have anything you'd like to discuss about the course or course materials. Office hours will be posted on the web at http://web.mit.edu/6.170/www/office-hours.html

LAs will schedule LA hours held in designated clusters. Please feel free to work in the cluster so you can talk to them in person when you have questions about Java or other technical details. Time permitting, they also monitor the 6.170 zephyr instance while on duty, but they give priority to students who visit them in person (which is a better way to interact with the LAs anyway). Please see the LA Lab hours for an up-to-date list of hours.

The lecturers are available by appointment but do not have fixed office hours.

Who to Ask

When solving your assignments, the laboratory assistants should be your first resource for problems with your Java code or the Athena environment. For other questions, the LAs may be able to help you with advice or information, but the answer of a TA or lecturer is authoritative. Your TA can answer most questions about the course. The LAs or TAs may choose to escalate your questions to the head TA or the lecturers; you may also do so yourself if you do not receive an answer.

Here are some examples of questions appropriate for various staff members. Naturally, you shouldn't ask a question unless you have first tried to find the answer yourself. When asking a question, be sure to say what you have already tried to do to solve the problem; that way the staff won't waste its time and yours repeating something you already know.

• "I run `javac GeoSegment.java' and I get this message: XXX"
  Ask an LA.
• "I run `java MyClass' and I get this error: XXX"
  Ask an LA.
• "What is an interface in Java?"
  First read your Java text and Liskov's Program Development in Java, then ask an LA or a TA.
• What does function foo in the JDK API do? What arguments does it take?
  Look in the JDK API documentation.
  (Don't ask this sort of question on the zephyr instance, either, unless you have carefully read the documentation and still do not understand it.)
• "The problem set asks for a set of test cases; are these enough: XXX"
  Ask a TA.
• "What does the problem set mean when it says this: XXX"
  Ask a TA.
• "I found a bug in the problem set."
  Ask a TA.
• "My TA hates me and won't answer my questions and makes me sit facing the corner during recitation."
  Ask a professor.

Texts

Required Text

Recommended Java Texts

• Ivor Horton, Beginning Java 2 -- JDK 1.3 Edition, Wrox Press, 2000.

Tutorial introduction to all parts of Java, including user interface libraries. No knowledge of other languages is assumed. A big book (over 1200 pages!): you won't want to carry this around in your backpack! Available at Quantum Books (specially reserved), or from amazon.com.

• Ken Arnold, James Gosling, and David Holmes. The Java Programming Language, 3rd edition, Addison-Wesley, 2000.
  A much briefer explanation of Java. Assumes more background; much less explanation about how to use Java's features. User interface libraries not discussed. New edition includes discussion of collection classes. Details at http://java.sun.com/docs/books/javaprog/thirdedition/
.
• David Flanagan. Java in a Nutshell, 3rd edition, O'Reilly, 1999.
  A reference book rather than a tutorial. Succinct but covers a lot. Assumes knowledge of a language like C. Details at http://www.oreilly.com/catalog/javanut3/.
• Bruce Eckel Thinking in Java, 2nd edition, Prentice-Hall, 2000. Also available on-line at http://www.bruceeckel.com/TIJ2/index.html (but don't try printing it yourself, as it is over 1000 pages). This is written for the person who can already program, but wants to learn object-oriented thinking and the Java language. It goes into lots of detail on the tricky aspects like GUIs, multithreading, and remote method invocation.

Other References

• Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley 1995, ISBN 0-201-63361-2.

The seminal book on design patterns, usually referred to as the "Gang of Four book". Organized as a catalog.
• Martin Fowler. Analysis Patterns: Reusable Object Models. Addison Wesley Longman, 1997.

A book on object models of problems, organized in the style of the Gang of Four book. Notation differs slightly from the notation we'll use, but that shouldn't be a major obstacle.
• James Gosling, Bill Joy, and Guy Steele. The Java Language Specification.
  The official reference for Java by its inventors. Available as a book, or online at http://java.sun.com/docs/books/jls/index.html.
• Martin Fowler. Refactoring: Improving the Design of Existing Code. Addison-Wesley, 1999. ISBN 0-201-48567-2.
  A book on techniques for restructuring code to make it more readable, extensible, and maintainable without changing its meaning. Particularly helpful for those coming from a non-object-oriented background. Examples are presented in Java.
• For more on Java, see the Java websites listed in the Athena Environment handout.

Where and When

Lecture/recitation

Recitation Section Locations (Thursdays at 10am):
You will be assigned to a recitation based on the sign-up form you submit; the section assignment made by the registrar is ignored.

Section	Instructor	Location	Section	Instructor	Location
1	Felix	36-153	7	Jeremy	36-372
2	Allison	36-144	8	John	26-328
3	Matt	66-168	9	Kenneth	66-144
4	Sameer	26-322	10	David	66-156
5	Jeffrey	24-407	11	Delphine	38-136
6	Andreas	31-161

Recitation section information will be distributed by email on the evening of Wednesday, February 7, and will also be available on the web.

Labs

Lab sessions will involve a one-hour exercise that introduces you to some tool (such as editing environments, compilers, debuggers, and profilers) or to some aspect of the Java language (such as inheritance and the Swing library). TAs and LAs will be on hand to help you with any problems. Students will work in pairs to help you learn from each other: your styles, little tricks about programming, using the environment, etc. You can also get to know other students; we encourage you to work with a different partner each week (but we do not require it). Lab sessions are not to be used for working on problem sets, which are individual work.

Lab sessions are held in 34-501 (the 6.001 lab). There are three one-hour lab sessions per week: Friday at 10, 11, and 2. You may attend whichever is most convenient for you.

Quizzes

Policies

Grading policy

Late/missing work

• Late work will receive no credit. (If a problem set is due at 5:00, and you have a class that runs until 5:00, turn the problem set in before class; five minutes late is enough to earn you a zero.) However, you have one weekend's slack credit, which allows you to hand in your problem set at 5:00 on the Monday following a Thursday due date (or at 5:00 on the Thursday following a Monday due date) You may use your slack credit once, for any of problem sets 1-6 (in the first half of the term). You must notify your TA, by the original due date, that you are using your slack weekend.
• In unusual or extenuating circumstances (e.g., serious illness with a doctor's note), you may be able to turn in a problem set late without using your slack credit, but only if you receive advance permission from your TA. The further in advance you ask for an extension, the more likely you are to get it.
• You will not pass the course if you receive no, or essentially no, credit for problem set 6 or the final project.
• Grades of "incomplete" will not be given, except under extraordinary circumstances.

Collaborative work

• Code:
  • For the individual problem sets in the first half of term, you are permitted to discuss only background material (and use of tools such as editors, compilers, and debuggers) with other students. You should not discuss the problems or their solution, and any design, coding and documentation that you hand in must be entirely your own work. You are not allowed to look at anyone else's work, such as code, test cases, and documentation, nor to show your work to anyone else.

    Your solution may use code from the standard Java libraries and from libraries offered for your use by the 6.170 staff. Otherwise all code in your submitted work for the individual assignments is to be of your own creation.

    It is a violation of the collaboration policy to zephyr more than 5 lines of code to the zephyr instance. It is a violation of the collaboration policy to permit anyone besides the 6.170 and yourself read-access to your ~/6.170 directory (or any other location where you keep 6.170 code).

  • For the final project, you are encouraged to collaborate with your teammates on all aspects of the work, although every member of the team will be expected to contribute a roughly equal share to the design and implementation. Your design and the bulk of your implementation must be unique to your group. However, you may reuse code from your work earlier in the semester or from other sources. (For instance, you might use a specialized image library to create a special effect on yoru final project.) Any code you submit must be properly attributed and must be coded, documented, and tested to 6.170 standards.
• Conceptual material:
  • You may discuss any of the conceptual material covered in the course with classmates, but may not discuss problems from the problem sets, nor their solutions.
  • Throughout the course, you are permitted to look at materials from previous offerings of 6.170 ("bibles"), with the exception of code and specifications contained therein. In other words, you may review the conceptual material from previous terms.
  • You are welcome to research algorithms or other concepts, and use any material you find in textbooks or other sources such as websites (except for copying code). Introduction to Algorithms by Cormen, Leiserson, and Rivest is an excellent resource for this purpose; it is available in several of the MIT Libraries. If you use any material from an external source, you must credit it clearly in your documentation.

Procedures

Handouts

How to Submit Assignments

Your documentation must clearly indicate any shortcomings of your program. If your code does not compile, or if certain functionality is missing, and your documentation does not clearly and prominently indicate as such, then you will lose points for the omissions (as well as for the defect itself).

Diagrams which you turn in must be readable. While we shan't be grading on artistic merit, if it is not easy to see what is happening, then you have not successfully conveyed the relevant information, and you will be graded accordingly.

Physical problem set solutions should be handed in to the course secretary (NE43-529) by 5:00 pm on the due date, with your name, user name, TA's name, and section number written on it. Please be prompt and don't harass the course secretary about the deadline as she would like to go home on Thursday nights.

Electronic problem set solutions should be submitted via the turnin6170 script. You should place your name near the top of all files you turnin. Along with your electronic submissions you must always include a README file which should provide a brief overview of your turnin. The README should include brief descriptions of any files you turn in. (You may wish to describe each by a single line, or describe groups of them together; do whatever is clearest.) Do not turn in extraneous files, as every file you turn in will be graded, and points will be taken off for files that are not used or are not mentioned in the README file.

All code you turn in must compile. It must also run when called in the manner specified by the problem set, or it will not receive credit for correctness. TAs will not adjust your output formats or otherwise debug your programs to try to get them to run. You will be given example input and output files, and often full test suites as well, in order to test your own programs before submitting them. Specifically, you should use the validate6170 script to check your code before you submit it.

For many of the problem sets we will provide you with a detailed specification for the behavior of the code that you will write. It is imperative that the program you write conform precisely to these specifications. This means that your program should not write anything to either standard out or standard error other than precisely what is specified. You should verify that the spelling, phrasing, or punctuation conforms to the specification as your program will be subjected to automated testing. The output of your program should furthermore be deterministic: it should not vary from run to run when presented with the same input.

In addition to providing specifications for the behavior of your program, we will often provide specifications for certain classes. For such classes you are free to add private fields, methods, and constructors, but unless otherwise specified you may not add public, protected, or default-access (package) fields, methods, or constructors.

The test suites which you include with your program should run in under a minute when testing your implementation.

Graded Assignments

Re-Turning in Assignments

For example, suppose that student Tortoise received 60/75 points on the first problem set submission, then later submitted a correct program, and further suppose that student Hare received 70/75 points on the first problem set, but did not bother to fix the problems in the submission. Then after adding the returnin points, Tortoise's final grade would be 85/100, while Hare's would be 70/100.

You can resubmit your assignment using returnin6170 which operates similarly to turnin6170.

Problem set hints

• Start as early as possible.
• Read the entire text of the assignment before starting any part of it.
• Think before you code. You'll find that sketching out a plan on paper before you start will make your coding faster and less error-prone.
• Write test cases before you code. This avoids the pitfall of thinking about the code as you write your tests, which could cause you to overlook the same issues in your testing as you did when writing the program. You may want to add additional test cases after writing the code, of course, particularly if implementing the specification brought issues to your attention that you had not been aware of before you started coding.
• Don't debug aimlessly: you'll waste a lot of time and get frustrated. Instead, form a hypothesis and devise an experiment to check it. If you're stuck, leave your computer for a while. You may well find that clearing your head allows you to see an obvious problem that you'd missed before because you were focused on the (wrong!) details. When you're tired, stop.
• Make sure that your answers to questions are succinct and to the point.