This course is open to anyone who's comfortable in a programming language other than Java and wants to learn Java. It is designed for a more specific audience: high school teachers who are currently teaching C++. Accordingly, some of the assignments will have to do with lesson plans, textbooks, or development environments, and course coverage will be influenced (although not completely determined) by the AP CS subset of the Java language, and by differences between C++ and Java. If you're teaching middle school, or college, or Visual Basic, or you're not a teacher at all, you should still get a lot out of the course.
If you want to learn how to use a computer (for word processing, spreadsheets, databases, Web browsing, email, etc.) and perhaps create your own Web page, but not write full computer programs yourself, you should take CSC 170, “Introduction to Computers and Their Applications”, instead.
If you want to learn to program, you should take CSC 160 “A First Course in Computer Programming” or 171 “Introduction to Computer Programming” instead; talk to me to decide between those two courses.
A large portion of the semester will be spent on the Java language, particularly how it differs from C++. Many programming tasks are easier in Java than in C++, and as a result, many object-oriented concepts that were omitted from the AP subset of C++ because they were too hard have been included in the AP subset of Java; we'll discuss those aspects of object-oriented programming (OOP) in depth. I expect to cover somewhat more material than you will get through in a half-year high school course, so that you have the perspective to answer questions from your students and to assign advanced projects to the hot shots.
We'll also talk about philosophies of teaching. I've been strongly influenced by the TeachScheme! project, a remarkably successful and fulfilling approach to teaching beginning programming. Another important influence on me is XTreme Programming, a collection of programming-productivity practices, many of which can be taught at the first-year level. Some of these principles include
Teach as few syntactic features as possible, one at a time as they become necessary.
Teach step-by-step design recipes, made up of specific questions students can ask themselves to get past “blank page syndrome” and end with working, tested programs.
Write carefully-chosen test cases, and their expected behavior, before writing code. This not only removes an excuse for not testing, but also helps to understand the problem.
If possible, have students work in pairs; a second pair of eyes can spot the great majority of programming errors early.
“The shape of the data determines the shape of the code.” Knowing the input and output data types of a function allows you to use data-driven templates to get started on the code.
Our primary textbook this semester will be Cay Horstmann's Big Java. This is actually a beginning programming text, but (as the name suggests) contains much more material than would actually be covered in a one-semester beginning course. We'll go through it more or less in order, skipping quickly through the parts that introduce familiar topics like conditionals and loops, and spending more time on the topics with which you're probably less familiar.
A runner-up in my process of choosing a textbook was Bruce Eckel's Thinking in Java, which is written for experienced programmers who are new to Java. I've ordered a few copies at the bookstore, but most of the book is also available for free on the Web.
The reading assignments are an important part of the course. If you're going to pay $70 or so for a textbook, you might as well get your money's worth by reading it. We'll go through more than half of the Horstmann textbook: quickly through the first six chapters, which (except for Applets) should be familiar material to anyone who's programmed in a high-level language, then slower as we get to more unfamiliar concepts. Make time in your weekly schedule to read an average of 50 pages a week.
You are responsible for everything in the reading assignments, whether or not I discuss it in a lecture. You are also responsible for checking my class Web page at least once a week or so for assignments, corrections to assignments, solutions to assignments, etc..
I expect to give seven programming assignments, one every week or two. Most assignments are to be turned in by email, and will be considered late if the time stamp on the email is after midnight on the assigned due date. Assignments turned in up to a day late lose 10% credit; those up to two days late lose 20% credit; etc. So if you have a choice between turning in an incomplete program today and a better one tomorrow, you should turn it in late only if you think the extra day will allow you to improve it by more than 10%. Any homework assignment turned in after midnight, Wednesday, Dec. 11 (the last day of class) will get a zero. (This is so I have, perhaps, time to grade them before the final exam.)
There will also be one major non-programming assignment: a book report. I'd like each of you to read through a different Java-based programming textbook (which I'll lend you), discuss the author's approach and priorities, assess the suitability of the text for various sorts of courses, and present your conclusions to the class.
We'll have a two-hour final exam, weighted the same as a programming assignment. It will include material from the whole semester, but concentrate on the most recent topics (those on which you haven't done a homework assignment).
There will also be a “brownie points” score, weighted the same as a programming assignment. The “brownie points” score is my purely subjective opinion of how seriously you're taking the course. You gain brownie points by asking good questions in class, coming to my (or the tutors') office hours when you have a problem, etc. You lose brownie points by cheating, by being confused and not doing anything about it, and by doing anything else that annoys the professor.
The final exam must be taken at the scheduled time, unless arranged in advance or prevented by a documented medical or family emergency. If you have three or more exams scheduled on the same date, or a religious holiday that conflicts with the exam date, please notify me in writing within the first two weeks of the semester in order to receive due consideration. Exams not taken without one of the above excuses will be recorded with a grade of 0.
Every program must contain, in the first few lines, a comment indicating the name(s) of the student(s) working on it, the course number (CSC 680), and which assignment it is. Programs not containing this information, clearly visible, will get a zero. If you're turning in homework by e-mail, please put this same information in the Subject: line as well, so it's easier for me to file my e-mail correctly.
A program that hasn't been adequately tested is worthless. I expect you to choose, and write down, a good selection of test cases (along with the “correct” result of each one) for every function before you write its body. In many cases, you'll put these test cases into a test method, so you can easily run them all every time you modify the program. Programs with inadequate or poorly-chosen test cases will lose points.
Every program must be adequately and accurately commented. Ideally, most of your code should be so easy to read that it doesn't need comments, but if there are non-obvious restrictions on the use of a particular variable or function, or non-obvious tricks in your algorithm, explain these. The development environment we'll be using for most of the semester provides boilerplate comments automatically; you'll be expected to fill them in with something more substantial. And when you modify a program, be sure to update the comments too!
Having done my share of programming, I know that sometimes you hit a brick wall and cannot get the thing to work for love or money. If this happens, turn in the program together with a description of how the program fails, what you've tried in your attempts to fix it, and how those attempts didn't succeed. You won't get full credit, but if I'm convinced that you're working on it diligently, you'll get partial credit. Note that “how the program fails” does not mean saying “I got an error message”: you need to tell me which error message you got, when you saw it, and what you think the error message means. Similarly, if the program fails by producing wrong answers, you need to tell me when it produces wrong answers (are they all wrong, or just in a few cases?), how they are wrong (e.g. are all the numbers consistently higher than you expected, are they the negatives of the correct answers, or are they all over the place with no apparent pattern?), and your speculations on how such an error might have arisen. I'm requiring all this not because I'm mean and horrible, but because by the time you've written all this down, you may have enough information to actually fix the problem, which is much better than turning it in incomplete.
Programs will be graded not only on producing correct answers (although that's obviously a requirement), but on stylistic issues such as user-friendliness, readability, extensibility, and modifiability. To drive home the importance of modifiability, I may occasionally change the assignment slightly on the day that it's due. When you read an assignment, you should immediately start thinking “how is Dr. Bloch likely to change this at the last minute?” and write the program in such a way that you can respond to such changes easily. If it takes you more than an hour to handle my last-minute change, you didn't design the program well.
Most homework assignments in this course involve writing, testing, and debugging a program. For most of these assignments, I would prefer that you work in teams of two students, switching teams from one assignment to the next; for other assignments, I may ask you to work individually.
When I say “teams of two students”, I don't mean “you write the first half of the assignment, and I'll write the second half”; I want both students working together on all of the assignment, using the techniques of Pair Programming: two people using one workstation, with one typing and the other “looking over the first one's shoulder”. If you haven't encountered this approach before, I'll point you to a good article about it. Since most of you commute to campus, you may find it difficult to arrange to work side-by-side with your partner, but do try; it's worth it.
It's hard to define what constitutes “cheating” in this sort of course. Students are encouraged to help one another with mechanical and linguistic difficulties (“how do I save this file?”, “how do you declare a static instance variable?”, etc.), regardless of whether they're on the same team, but designing, coding, testing, and debugging should be done by team members. It's remarkably easy for a professor to notice when three different teams have turned in nearly-identical programs; if that happens, I'll grade it once and divide the credit among the three, so the best any of them can hope for is 33%.
All work on the final exam must be entirely the work of the one person whose name is at the top of the page. If I have evidence that one student copied from another on an exam, both students will be penalized; see above.
This class meets every Wednesday from 6:00-8:30 PM in Science 227. Our final exam will be from 6:00-8:00 PM, in the same room, on Wednesday, Dec. 18. If you have a problem with these scheduled dates and times, let me know at least two weeks in advance so we can make suitable arrangements.
All dates in the following schedule are tentative, except those fixed by the University; if some topic listed here as taking one lecture in fact takes two lectures to cover adequately, or vice versa, the schedule will shift.
In the column marked “Reading”, all chapter numbers are in the Horstmann book unless stated otherwise.
I expect you to have read the reading assignments before the lecture that deals with that topic. This way I can concentrate my time on answering questions and clarifying subtle or difficult points in the textbook, rather than on reading the textbook to you, which will bore both of us. Please read ahead!
When I say “read” above, I mean an active process, involving not only the textbook but pencil, scratch paper, and a notebook for writing down key points. Finally, and perhaps most importantly, you'll need a computer for trying out the new ideas you find in your reading. Just as you cannot learn to drive a car or to cook just by reading about it, you cannot learn about programming just by reading about it. In short, every time you read about a new programming idea, try it!
Calendar of Topics and Assignments