This handout describes some of the general information that you will need to know about 6.030. It also includes course policies that we will expect you to abide by during this term. You should read through this handout and make sure that you understand its contents. You will probably also want to save it for future reference. This handout -- as well as other course information -- is available on the web via the course web page, http://www-cs101.ai.mit.edu/courses/fall99/.
Email us at firstname.lastname@example.org or zwrite -c cs101-staff
Professor Lynn Andrea Stein, email@example.com, x3-2663, NE43-811. Office hours by appointment.
Duncan Bryce, firstname.lastname@example.org
Mike Wessler, email@example.com
Jennifer Chung, firstname.lastname@example.org
Matt Deeds, email@example.com
Michael Harder, firstname.lastname@example.org
Pavel Langer, email@example.com
Paul Njoroge, firstname.lastname@example.org
Course Secretary Jean Hwang, email@example.com, NE43-812
We are each individually reachable by email. Some of us read email regularly, others only every few days. Collectively, we can be reached at firstname.lastname@example.org. If you have something urgent, this is probably the best way to contact someone.
You may also try zephyring us using the class 6.030-staff (that is, zwrite -c 6.030-staff); it might raise a staff member even sooner. Zephyring us individually (see contact information above) might also work. Be warned, however, that some of us (Lynn in particular :o)) look like we're logged in when we're in reality nowhere near our computers.
Feel free to communicate with other students on the zephyr instance called 6.030. To subscribe to -i 6.030, use
zctl add message 6.030 \* -- receive zephyrs from the instance permanently
zctl sub message 6.030 \* -- receive zephyrs from the instance for your current athena session only
zctl unsub message 6.030 \* -- stop receiving zephyrs from the instance for your current athena session only
zctl delete message 6.030 \* -- stop receiving zephyrs from the instance permanently
In order to write to the instance, use the command
zwrite -i 6.030
Note that to write to the 6.030-staff zephyr class you use "zwrite -c", and to write to the 6.030 zephyr instance you use "zwrite -i". The instance can allow you to zephyr students and course staff members who have subscribed and who are logged onto athena. This is a good way to ask questions, etc., outside of regular course hours.
Text: The textbook for this course is a draft of Interactive Programming in Java (IPIJ). This book was developed especially for this course. This semester it is also being used by a thousand other students at universities around the world.
The text is available for purchase (at copying cost) from the instrument desk on the fifth floor of building 38 during regular business hours. You will need to pay for the text at the cashier's office first. To do this, take the receipt (distributed in class on the first day) to the cashier's office in 10-180 together with $22 (cash or check). After you have paid, you should take your recipt to the EECS instrument desk in 38-501 to get your copy of the notes. The instrument desk is next door to the course lab and can only be approached through building 36.
Only the first (larger) installment of the book is available at this time. A second installment will be made available later in the semester. The $22 fee covers both of these installments as well as all additional handouts during the semester.
An html version of IPIJ is also available for browsing and reference on the course web site. The (html) version is not suitable for printing. If you have your own printer and would like to print a copy directly from the pdf file, you may access that file from the publisher's web site, http://www.mkp.com/ipij. You SHOULD NOT print the pdf on MIT printers!
Reference: There is no required reference for this course; the textbook plus a web reference such as Java's API documentation (URL) should be sufficient. However, some people prefer to have a paper reference in addition to the on-line reference.
If you prefer to have a paper copy of a Java reference, we recommend that you acquire a copy of
Java in a Nutshell by David Flanagan (O'Reilly).
Be sure that you get the second or third edition. This book is an excellent reference on Java and it is reasonably priced. It is available from Quantum Books (see below) or online.
If you do buy Java in a Nutshell, you need not do so until after the first part of the course. The third edition of this book will be published in November, and you may wish to wait until then to buy it. The second edition will do fine if you want a copy and decide that you cannot wait until November.
Further Reading: If you are interested in the topics covered in this class, you may wish to read more. In particular, we recommend:
Concurrent Java by Doug Lea, Addison Wesley.
Java Design by Peter Coad, Mark Mayfield, and Jon Kern, Prentice Hall.
These are both superb books. However, neither was inexpensive when we priced them last. Both cover more advanced material than we will in this class, and neither is in any way required for 6.030. During the term we may recommend other advanced books for those who wish to learn more about certain topics.
Sources: You can buy Java books (among many other places) at Quantum Books, the Tech Coop, or from on-line stores such as amazon.com, bookpool.com, or Barnes and Noble. Quantum Books has been given the names of the three books listed above and should have them in stock. Some publishers -- like O'Reilly -- also sell their books directly. Shop around for a good price.
The class meets on Mondays and Wednesdays from 12-1 in 35-225. The class will generally meet in smaller groups for recitation on Fridays at the same times (in 35-225 and 38-136). Recitation assignments will be posted at the end of the first week of class. The first Friday of the semester will be a lecture meeting, NOT a section. See attached schedule and the section on missed meetings, below.
In addition to lecture, each student will be assigned to a three-hour weekly laboratory session (one of Monday, Tuesday, Wednesday, or Thursday 2-5 pm). Please check your section and laboratory assignments, which will be posted at http://www-cs101.ai.mit.edu/courses/fall99/handouts/sections.html. All laboratory sessions are held in 34-501. See the section on laboratories, below, for further information.
During the term, there will be seven regular laboratories, three written assignments, one examination, and a final project.
The examination will be scheduled for the middle of November. The examination will cover Java programming and conceptual understanding in ways that may be difficult to asses during the laboratory sessions.
The final project will occupy the laboratory meetings during the last month of the course. All final projects will be group projects. The final project will include design and programming components as well as a substantial written document (such as a user's manual) and an oral presentation. Each of these components will be included in the project grade.
Your grade in 6.030 will be a weighted mixture of the evaluated elements of the course (laboratories, written assignments, exam, and final project) together with the assessment of your understanding of course materials made by the course staff, e.g. in laboratory check-in and check-out interviews, participation in class meetings, etc.
To earn an A in 6.030, you should regularly demonstrate mastery of the material, have a strong understanding of and performance in laboratory work, be a valuable participant in course meetings and collaborations, and complete all portions of the course work in a timely fashion. For example, at the end of the course, you should be able to lead a team in designing and building a complex networked video game.
To earn a B in 6.030, you should demonstrate a solid grasp of most of the course material, competently perform laboratory work, participate in course meetings and collaborations, and complete all portions of the course work in a timely fashion. For example, at the end of the course, you should be able to independently design and build a simple networked video game.
To earn a C in 6.030, you should demonstrate a sufficient understanding of the course materials that you can go on to build on that understanding in subsequent courses or employment, participate in course meetings and collaborations, and complete all portions of the course work in a timely fashion. For example, at the end of the course, you should be a solid contributor to a team that designs and builds a networked video game.
If none of the three descriptions above fits you at the end of 6.030, there are two possibilities:
Late work will not be accepted and may be treated as missing work. Always turn in what you have completed on time rather than delaying in the hope that you will be able to do more.
Laboratory sessions are an essential part of the course. Each week, a laboratory assignment will be distributed to students. This assignment will generally have three parts: preparatory work, in-lab work, and post-lab work.
Students are expected to come to their assigned laboratory session having completed the preparatory work. When you arrive at the lab, a TA or an LA will check you in. (Typically, this will involve asking you questions about your preparatory work and/or asking to see your development plan for the laboratory.) In general, you are not expected to have begun the programming of the laboratory assignment before coming to lab; however, you are expected to have spent time outlining the program that you intend to write and to have planned the various steps that you will take during your three hour lab.
Students who do not prepare adequately for lab will be denied admission to the laboratory. Such students will be permitted, on a space-available basis, to attend a later laboratory session (provided they successfully complete the check-in procedure on that day). However, failure to check-in to your assigned lab will be reflected in your grade for that laboratory.
Each laboratory assignment is designed so that there is a range of work that might solve the problem. You should begin by implementing a simple piece or version of the solution. When this works to your satisfaction, you should build on additional features or behavior. The laboratory assignment will indicate a target portion to be completed in lab. Often, you will be asked to design test cases as a part of the pre-lab exercises or to share code and test cases with your classmates.
When you are done with your assignment, or when the lab session is nearing its end, you should ask a TA or an LA to check you out of lab. Check-out consists of a discussion between you and the course staff member about your work. During this discussion, you will probably be asked to show your code in operation; to discuss how your code works; to display part or all of your code; to answer some questions about how your code might behave; and to test some or all of these hypotheses. You may be left with some questions or issues to think about, including some possible modifications to your code.
As a rule, you are not expected to spend any time outside of the laboratory session at a computer, programming. Of course, you may do so if you would find it helpful at any point: to try out the programs and environments that we provide; to test hypotheses; to develop intuition; or just to have fun!
Your grade on the laboratory will be based on how well you complete the target portion of the assignment. In general, it is better to do this part well than to go beyond the target portion.
You may leave lab as soon as your work is done and you have been checked out. Please respect the course staff's schedules and try to ensure that you are ready to leave (i.e., checked out) when lab ends at 5pm.
After the laboratory session ends, you should write up and turn your completed assignment on the specified due date. Although the details of the post-lab writeup will vary from lab to lab (and from student to student), you can expect that it will generally include:
You should also include
If the enrollment in the course (as judged by attendance at the first meeting) exceeds the capacity of the course resources, a lottery will be held. In order to participate in the lottery, you MUST attend the first meeting of 6.030 and fill out a lottery form (or have made alternate arrangements with the professor prior to that time). Participation in the lottery is deemed an indication of your commitment to take 6.030; do not sign up for the lottery unless you really intend to enroll.
Because this course is intended for those with little or no prior programming experience, the lottery will give preference to students who have not previously completed 6.001 or another substantial course in computer science. Those who are not MIT undergraduates should speak with the professor or another course staff member ASAP to ascertain the appropriateness of 6.030. (Cross-registered undergraduates without a college CS course need not do so.) In particular, note that 6.030 does not carry graduate credit.
If a lottery is held, the results will be posted on the course web site and outside the lecture room prior to the second meeting of the course. Students accepted into the course are still responsible for ensuring that they are enrolled according to the MIT registrar's office (i.e., the lottery doesn't automatically enroll you). Students not lotteried in are responsible for dropping the course officially.
You are responsible for all material covered in each lecture and recitation unless otherwise indicated. This material may not be covered elsewhere, so if you miss a meeting, you are responsible for getting notes from a friend or otherwise making up the material. Handouts will not be distributed on paper outside of class, but all course handouts will be made available on the course web site.
Attendance at laboratory is mandatory. If for any reason you cannot attend your scheduled laboratory session, it is your responsibility to make alternate arrangements with the course staff as far in advance as is reasonably possible. In particular, if you have an athletic event or other scheduled conflict, we expect that you will discuss this with us as soon as the conflict is scheduled. We understand that unforseen events do arise (see below); however, your brother's wedding is (probably) not one of them.
The only exceptions to this policy (i.e., last-minute or after-the-fact rescheduling) will be in cases of significant and unanticipatable emergency. In these cases, we request a note from the Medical Department or the Dean's Office. In addition, we would appreciate it if you would make an effort to notify the course staff at the earliest possible opportunity so that we can adjust accordingly.
There are a few times during the term when a religious holiday conflicts with a course meeting. If this will cause difficulty for you, please email the course staff at the beginning of the term to let us know of such conflicts. Note, however, that there will be no lecture on Monday, 20 September.
Students scheduled for the Monday laboratory who cannot make the September 20 lab meeting (and other students with similar conflicts at other points during the term) will be accommodated provided that you email us about the conflict immediately. If you know that you will have systematic conflicts with a particular day of the week, please try to avoid schedulingyour lab for that day.
Laboratories are due on Friday at the beginning of section. Other assignments will have due dates clearly indicated. Late work will not be accepted.
This section details the general course collaboration policy. Certain assignments require different kinds of, or restrictions on, collaboration. When the collaboration policy differs from that described here, it will be specified in the laboratory assignment.
We encourage you to work together on the pre-lab exercises. They are designed for working in small groups, allowing you to help each other learn and to balance your knowledge and strengths. Note that collaboration extends to discussion and problem-solving, but not to writeups. We expect that any written work you turn in will be your own, though it may reflect joint preparation.
Laboratory work is a more complex topic. It is often useful to discuss your program with peers or with course staff, and we strongly encourage this. It is particularly useful to do so as a means of debugging your program. Reading code written by others and having others critique your code are good ways to improve your programming style. However, it is of no benefit to you or to anyone else to have someone else actually do your laboratory work. We expect that the default assumption (i.e., unless specified otherwise) is that laboratory assignments are your own work, but may reflect input from others just as an essay edited by friends might. You should be the one who wrote the code you turn in.
Some labs, and the final project, will involve more explicit collaboration. In those cases, we will explicitly specify ways in which labs can be broken up, so that each person writes code but no one person writes the whole program, or indicate explicitly that a particular lab or portion of the lab may be programmed together, as a team. Even in this case, it is important that each team member have an opportunity to independently compose some code. Since the pre-lab will generally involve designing the code that you are going to write, it is best to also allocate responsibility for pieces of the code to members of the team at that time.
In each piece of work that you turn in, you must specify everyone with whom you have collaborated and each person's role in the collaboration (e.g., pre-lab, post-lab discussion and analysis, in-lab coding (specify which pieces or how responsibility was distributed), debugging, or advice). Failure to specify such collaboration will be interpreted as a statement that you have not collaborated with others in your work. While this is acceptable under course policy, it is probably ill-advised. (Really. We want you to work together and to learn from each other!)
Examinations are diagnostic in nature and as a consequence should represent independent work.
Of course, copying of the work of others is entirely unacceptable.
We also encourage you to make use of the course-wide mailing list (email@example.com) and zephyr class (zwrite -i 6.030). The course-wide mailing list is archived; you can read the archives by following the link from the course home page.
The primary source of information for this course is the world-wide web. The home page for the course is located at http://www-cs101.ai.mit.edu/courses/fall99/. Course materials will be made available there. Check this page regularly for news and updates.
This course is a part of Lynn Andrea Stein's Rethinking CS101 project at the MIT AI Lab and the Department of Electrical Engineering and Computer Science at the Massachusetts Institute of Technology.
Questions or comments:
Last modified: Tue Sep 7 13:01:20 1999