6.170 / Fall 2000 / General Information

Handout H1

• Course web site
• Staff
• TA Office Hours
• Texts
  • Required Text
  • Recommended Java Texts
  • Other References
• Where and When
  • Lecture/recitation
  • Quizzes
  • Office Hours
• Policies
  • Grading policy
  • Late/missing work
  • Collaborative work
• Procedures
  • Handouts
  • How to Submit Assignments
• Problem set hints

Course web site

Staff

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 tried to find the answer yourself first.

• "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.

TA Office Hours

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 special tricks of the Java language. It goes into lots of detail on the tricky aspects like GUIs, multithreading, 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". Well written and explained. Organized as a catalog for easy access. Highly recommended.
• 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. Well worth reading and understanding if you want to learn how to analyze problems and develop maintainable and flexible systems.
• 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.
• Java API specifications are available at http://www.javasoft.com/products/jdk/1.2/docs/api/index.html. If you work on your own machine, you will want to download the full documentation so you can access it quickly.

Where and When

Lecture/recitation

Recitation Section Locations (Thursdays at 11am):
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	Location	Section	Location
1	38-136	5	24-307
2	36-155	6	36-144
3	13-1143	7	24-110
4	24-407	8	24-112

Recitation section information will be distributed by email on the evening of Wednesday, September 6, and will also be available at sections.html.

Quizzes

Office Hours

Policies

Grading policy

Late/missing work

• Late work will receive no credit. (If a problem set is due at noon, and you have a class that runs until noon, 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 noon on the Monday following the due date, and it not to be regarded as late. You may use your slack credit once, for any of problem sets 1-6 (in the first half of the term). Simply 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 credit for problem set 6 or the final project.
• Grades of "incomplete" will not be given, except under extraordinary circumstances.

Collaborative work

• For the individual problem sets in the first half of term, you are permitted to discuss only background material 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 other students' work, such as code, test cases, and documentation, nor to show your work to other students.
• 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. You may reuse code from your work earlier in the semester. Any code you use must be fully documented to 6.170 standards.
• Throughout the course, you should feel free to look at materials from previous offerings of 6.170 ("bibles"), with the exception of code contained therein. You may also use any code from the standard Java libraries, and any libraries specifically offered for your use by the 6.170 staff. Otherwise all code in your submitted work is to be of your own creation.
• 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 and is available in several of the MIT Libraries. If you use any material from an external source, you should credit it clearly in your documentation.

Procedures

Handouts

How to Submit Assignments

Physical problem set solutions should be handed in to the course secretary (NE43-529) by 12 noon on its due date, with your name, user name, TA's name, and section number written on it.

Electronic problem set solutions should be submitted via the turnin6170 script.

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.