Princeton University |
Computer Science 333:
|
|
Thanks to everyone for putting on a good show
for the demos -- it was a great collection of interesting systems and
neat ideas. For submission, we would appreciate it if you could
include a pointer to your presentation slides if it's easy; that will
help us refresh our memory about how you presented the system. Don't
go to any extra work if it is not easy.
A couple of people have asked about installation and other aspects of project submission.
We are most interested in having access to a working version of your system so we can play with it; that's really important. You might find it useful to ask a friend to try it from a machine in the CS department to be sure that there isn't some obvious problem; after that, you should be ok. If something does come up, we'll just send you mail and let you straighten it out.
The installation part is mostly to make sure that all the files you created are included and there's enough of a roadmap that someone really dedicated (not me) could get it installed on a new system; it's partly a way to encourage you to be sure that you've included everything that's needed, either directly because it's code you wrote, or by reference if it's a big package like MySQL or some Java class library. One way to be sure that you have provided enough code and supporting info is to take your own installation package and move it to another machine and install it yourself as if you were a new developer. That's almost always a good check, and if that works, it should be more than enough for us too.
Lecture notes: 2/4 2/6 2/11 2/13 2/18-20 2/25 2/27 3/4 3/6 3/11 3/13 3/25 3/27 4/3 4/8 4/17 4/22 4/24 4/29 5/1
Assignments:   1   2   3   4 5
Project: preliminary description 2/4 slides 2/18 slides 3/6 mySQL info Project groups and TA's Carl's notes on CVS demo information 4/15
Reading: language tutorials Ousterhout on scripting languages quotes on languages an interview with Ken Thompson
Old stuff: survey formatting programs Avian networks testing assignment 5 Peter Weinberger hello world Intercal Peter Ullman '91 Tom Szymanski Tom Szymanski's slides
Dates: (Intermediate project dates are subject to minor revision.)
S M Tu W Th F S Feb 2 3 4 5 6 7 8 first class 9 10 11 12 13 14 15 assignment 1 due 16 17 18 19 20 21 22 assignment 2 due; preliminary project info 23 24 25 26 27 28 Mar 1 assignment 3 due 2 3 4 5 6 7 8 assignment 4 due 9 10 11 12 13 14 15 initial project proposal due 16 17 18 19 20 21 22 (spring break) 23 24 25 26 27 28 29 assignment 5 due; detailed project plan due 30 31 Apr 1 2 3 4 5 6 7 8 9 10 11 12 project prototype 13 14 15 16 17 18 19 20 21 22 23 24 25 26 alpha test 27 28 29 30 May 1 2 3 beta test 4 5 6 7 8 9 10 project presentations and demos 11 12 13 14 15 16 17 Dean's date; project due
This is a course about the practice of programming, an attempt to expose students to the development of real programs. Programming is more than just writing code. Programmers must also assess tradeoffs, choose among design alternatives, debug and test, improve performance, and maintain software written by themselves and others. At the same time, they must be concerned with compatibility, robustness, and reliability, while meeting specifications. Students will have the opportunity to develop these skills by working on their own code and in group projects.
COS 333 is about programming, not about a specific language. The course will assume that you are familiar with C, and will include excursions into C++, Java, and Visual Basic, and scripting languages like shells, Awk, Perl, and Tcl. There will be significant emphasis on tools, both how to use them and how they are designed and built. The course will use Unix and Linux more than Windows, but not exclusively. Students must be comfortable with C programming and Unix, and able to write modest-sized programs that work. COS 217 is a prerequisite.
This is meant to be more than a laundry list, however. Each section will also discuss issues of design, implementation, testing, performance, portability, and other software engineering concerns, and these will also be part of the programming assignments. With luck there will be a few guest lecturers as well.
There will be two lectures each week. During the first half of the semester, there will be a modest-sized programming assignment each week, which should take perhaps 5 hours to complete. During the second half of the semester, students will work in groups of 3 or 4 on a project that will involve a significant amount of design and implementation.
There is one required text: The Practice of Programming, by Kernighan and Pike; you should also know basic Unix tools and usage as described in, for example, The Unix Programming Environment. Other readings will be handed out in class or found on the Web. The books listed in this bibliography are also worth looking at; they cover a wide variety of material related to programming.
Lectures:
Tuesday and Thursday 11:00-12:20, somewhere.
Professor:
Brian Kernighan,
311 CS Building, 609-258-2089,
bwk@cs.princeton.edu.
Office hours by appointment, or just drop in if my door is open,
which it usually is.
Teaching Assistants:
Limin Jia, ljia@cs.princeton.edu, CS 418a. Office hours Tue 3-4pm
Ge Wang, gewang@cs.princeton.edu, CS 413, 258-1797
For most questions about the course, check the newsgroup first; this will be monitored by the TAs, and answers will be posted for everyone's benefit.
Five programming assigments will be assigned during the first half of the term; each is intended to take about five hours, but is sure to take longer unless you are careful.
Assignments are together worth about 30 percent of the course grade. Assignments are due by midnight on Thursdays unless there are extraordinary circumstances. For the record, extracurricular activities and heavy workloads in other classes don't count as "extraordinary", no matter how unexpected or important or time-consuming. You must complete all assignments and project requirements to pass the course.
The project will have frequent checkpoints along the way for which you will have to present status reports, preliminary designs, and the like. There will be a public presentation and demo at the end, a written writeup, and submission of a system for testing and evaluation. All of these are graded.
The project will be worth about 60 percent of the course grade; it will be shared equally among group members, with the possibility of negative adjustments for members who fail to contribute their fair share.
Regular class attendance is expected; frequent absences are grounds for a failing grade regardless of other performance.
Project groups are encouraged to share insights and information about how things work, how to get things done, and other aspects of programming knowledge. In general, code that is written for one project should not be used in another without compelling reasons; if this is likely to become an issue, please consult with the instructor.
Do not, under any circumstances, copy another person's program. Writing code for use by another or using another's code in any form violates the University's academic regulations.
Examples of unacceptable behavior include:
The program you turn in must be your work. You may get help from the instructor or TA after you have started writing code, but not from other students. Computer science assignments are not like physics or math problem sets: there is no single right answer. Each student is expected to come up with his or her own individual solution.
If you plan to do something that you are not absolutely sure is legal, ask first. Ignorance of this policy will not be accepted as an excuse for your actions.
You are responsible for ensuring that your files are not readable by your classmates. We recommend doing your CS333 work on your own machine or in a private subdirectory, i.e.:
% mkdir cs333 % chmod 700 cs333