Syllabus

Note: I will spend a few weeks introducing/building on the fundamental Java topics that are important for this course, which should have at least been introduced in ICS-22: interfaces, standard collection classes, linked lists, trees (and recursive processing of linked lists/trees), and big-O notation. I do so to ensure that students who have learned Java know everything that I think is fundamentally important (using the vocabulary that I will use in this course).

Don't "blow-off" the first weeks, even if it seems like pure review. Use your time to solidify and extend your knowledge of these Java fundamentals. Students who have not done any Java programming recently must re-aquire these skills quickly.

For this part of the course....

The voyage of discovery is not in seeking new landscapes but in having new eyes. - M. Proust

1. Demonstrate skill solving problems/programming with Data Types: Java collection classes, specifically, the abstractions Stack, Queue, PriorityQueue, List, Set, Map, EquivalenceClass, and Graph (and their iterators).

2. Demonstrate skill at using low-level Java Data Structures (primarily arrays, self-referential linked structures, and combinations of these) to implement these Data Types correctly and efficiently.

3. Understand O (big oh), Ω (big Omega), and Θ (big Theta) notation, and demonstrate the ability to use these notations to analyze implementations of collection classes (both analytically and empirically), and understand the usefulness and limits of these notations.

4. Understand Java and general programming ideas that aid in 1-2: interfaces, iterators, linked lists and trees, recursion, hashing, caching, anonymous classes, the decorator/adapter patterns, the Eclipse Debugger, etc.

This course emphasizes Object Oriented Programming (OOP). The foundational unit of OOP is the class: a syntactic structure that describes and encapsulates both the behavior (methods implemented by control structures) and state (fields implementing data structures) of objects. Classes provide an excellent motivation and context for exploring most interesting aspects of programming. We can view software as a collection of interacting objects (which are constructed from classes; often with many objects constructed from the same class).

The main programming methodology that we will learn and employ is TDD (test-driven development). We will use Drivers and JUnit to test our code; with JUnit tests we can automatically test it (and retest it when we make changes, until it is passes all the tests: meaning it may be correct or the tests might be insufficient). We will also study and actively use other Java tools for browsing, debugging, and documenting large programs.

Programming style is a particularly important topic: to understand programming, we really need to develop appropriate aesthetics that allow us to separate "elegant" programs from "hacks". As in any writing activity, we must also learn to be self-critical of our own creations, so that we can continually improve them; this skill is difficult to acquire, and its importance extends well beyond the domain of programming.

Finally, to become an expert in any discipline, we must master its terminology. Fluency with technical terms allows us to communicate -and even to think- more accurately and concisely. Therefore, the materials in this course will define, illustrate, and repeatedly use many important technical terms concerning programming. Take the time required to master them. An old Chinese proverb says, "The first step towards wisdom is calling things by their right names."

The UCI Bookstore sells textbooks that traditionally are used throughout the ICS 21/22/23 course sequence. If you took ICS 22 here, you will probably have this book already, which contains much useful material about the fundamentals of Java (and covers quite a few advanced topics as well).

• Intel-based PCs running the Windows Operating System (OS).
• Macintosh PCs running the Mac OS operating system
• Either PC running Linux.

Programming courses at most schools are moving towards a model in which most students use their own computers (or those of their roommates or friends) to complete their programming assignments. All the software used in ICS-23 is available, for free, on the web. We are assuming that students have already installed a web browser, and have a high-speed connection to the World-Wide Web: e.g., via the campus network, or by cable, or a DSL line.

The programming environment that we will use is Eclipse (probably version 3.7.2): it is an Integrated Development Environment (IDE), including a project manager, editor, compiler, debugger, class browser, help facility, etc. We will also use the Sun Java compiler and runtime system (probably version 1.7.5)with this IDE. This software, and others useful for the course, are available through the Online Resources link (see Course Software, near the top).

Talk to your instructor or TA immediately if you are experiencing any problems with your computing platform. Typically it takes only a few days before everyone has correctly downloaded and installed the necessary software, and learned how to use it properly. Using this software is integral to every programming assignment during the quarter, so it is best to be aggressive and master this software quickly.

ICS courses often schedule lab hours (to complement lecture hours), during which students can learn how to use software tools and work on their programming assignments, all under the supervision of ICS-23 staff members. This quarter, all Labs meet in rooms ICS 189 and ICS 183. Each of these rooms contains about 45 Dell Optiplex computers running Windows 7 and all the necessary course software. These labs are typically open for class use on weekdays, during "normal" hours: 8:00am to 8:00pm; and, they are closed on weekends.

The lab in ICS 364 is a general purpose lab in which no courses are scheduled. It is typically open to students on weekdays and weekends during "extended" hours: MTuWThT 8:00am - 10:pm, F 8:00am - 8:00pm, and SaSu 12:00pm (noon) - 6:00pm. You can examine the Lab Schedules for all these labs.

Because of UC buget cutbacks over the past few years, ICS-23 staff members will not be present in ICS 364.

If you find it inconvenient to use these labs, and would rather work from your dorm room or off campus, ICS-23 staff will also provide more limited online help through Instant Messaging. The forums on MessageBoard and also an excellent way to get help.

Finally, although the machines in the ICS labs also provide some external storage space (on a Unix system), it is an excellent idea to obtain a USB memory stick to backup all the work you do, both on your own computer and in our labs.

I will be glad to talk with you about any of the ICS-21/22/23 courses, Computer Science, UCI, or whatever else you want to discuss. Although UCI is a large school, ICS is a smaller school within it, and ICS promotes opportunities for close faculty-student interaction, especially with instructors who are lecturers. Unfortunately, in my opinion, few students take full advantage of this opportunity at UCI.

I especially encourage students who are having problems in the course to visit me immediately; I know that this is asking a lot -because it is demoralizing to come in because you are confused- but the payoff for recognizing the situation and acting on it immediately is tremendous. The primary reason that students fail to thrive in programming courses is that they fall behind in their work -often because of what is initially a small misunderstanding; but, because of the cumulative nature of this course, even a small misunderstanding can quickly grow into a big one. Often, I can quickly diagnose and rectify such a problem one-on-one. It is like surgery: a bit painful at first, but in the long-term beneficial.

Getting help fast can critically affect your overall performance in this course: many times I've seen students start performing one grade level higher after coming in to get help during my office hours (a typical visit lasts for about 20 minutes, and there is typically no waiting).

Finally, I plan to hold the equivalent of "office hours" during the labs too. This means I plan to attend the labs, and students can talk to me there (for private matters we can even step outside to talk). The labs are a great place to discuss programming tools, because it is easy for us to sit down together and work together.

If you are not already a member of AIM Sign Up for this service (it is free). Using this system, you will be able to Instant Message me, as well as use an audio (voice) connection if you have a headset with a microphone. You can IM me with questions; you can also cut/paste code into your message. Please be aware that I may be having multiple conversations, and therefore react more slowly than you might expect.

Another effective [debugging] technique is to explain your code to someone else. This will often cause you to explain the bug to yourself. Sometimes it takes no more than a few sentences, followed by an embarrassed "Never mind, I see what's wrong. Sorry to bother you." This works remarkably well; you can even use non-programmers as listeners. One university computer center kept a teddy bear near the help desk. Students with mysterious bugs were required to explain them to the bear before they could speak to a human counselor. - B. Kernighan & D. Pike (in "The Practice of Programming" pp. 123)

When I am not teaching nor attending meetings, I try to answer email every few hours during the day. I normally will not answer email sent after about 10:00pm until early the next morning (but I'll typically answer it by the next morning). If you have problems late at night "problems that the staff cannot help resolve" please send me email summarizing your problems, and then go to work on something else (or if it is really late, go to sleep). By planning to finish assignments early, you can protect yourself against a big problem that arises at night and cannot be fixed until the next day (you don't want to have to fix such a problem the night that an assignment is due).

For some problems -ones that are of general interest to the class- you should send email to the all students in the course, or post a question on one of the Message Board Forums (see below). By doing so, everyone can see the question and its answer: and students can answer each other's questions. It is often said that you don't understand something until you can explain it to someone else: which is why teachers often understand things very well.

I have created a the following forums: Java and Eclipse, Lecture Material, Programming Assignments Quizzes and Exams (and if it is useful, I'll create more).

If you have a question of general interest (of interest to many students in the course, not just you), then you should post the question on the appropriate forum. For example, if a lecture note, programming assignment, etc. contains unclear (or even contradictory) information, ask for a clarification. I, or someone from the staff will read and reply to whatever questions are asked in the forums. In fact, if you read a question, and know the answer -or generally have something to contribute to the topic- I encourage you to reply as well, to help resolve the problem even sooner.

Again, class email/forums are appropriate for questions relevant to most students in the course; directly email me (see above) for questions of a more individualistic nature. Obviously students should neither solicit nor post answers to take-home quizzes, programming assignments, or anything else that would be interpreted as academic misconduct (which is discussed in greater detail below). But, a discussion of these assignments (having to do with issues of clarification) is fine on email/forums.

It is an excellent idea to read your email and check these forums at least daily, certainly whenever you are about to do coursework, to keep up to date on any coursewide discussions. Reading your email and checking these forums can save you a lot of time and confusion. There is a special mechanism that you can invoke to have the forum email you when new information is added (either one email for each new item, or a digest sent late at night of all items added that day).

Our Tutors will primarily help students to debug their programs during scheduled lab hours.

While consulting, the TA and Lab Tutors will help you diagnose any computer/programming problems that you have and guide you toward a solution. They will help you learn how to program by answering your questions; but, do not expect them to write your programs for you. Sometimes when you come to the staff with a specific question, they will show you how to solve a more general problem. Be patient; the staff are just trying to teach you how to recognize and solve these problems by yourself.

I encourage you to participate by raising your hand; sometimes I may finish the point I'm making before calling on you, but please keep your hand up if you want to speak. If you have a question about the material, it typically means that I have explained something incorrectly, poorly, or incompletely, and that other students have (or will soon have, maybe right after they leave the classroom) the same question. So, it would be best for all of us to correct the problem immediately in class by someone bringing it to my attention. In summary, this class runs on the Dershowitz principle: "Question authority; but raise your hand first".

The quizzes are open-book: you will be able to use any class materials, or any other materials from the web, to answer its questions. The quizzes are also open-computer: by that I mean that you may use a computer to check your work. But, you must work on the quizzes by yourself, not soliciting or sharing answers with other students.

Academic Integrity

The following information is my own restatement of this policy, as it applies in my course (originally written while I taught at CMU). You will also be asked to read and sign a handout to acknowledge that you understand the Academic Integerity Contract in force for this course.

• Plagiarism will be suspected if an assignment that calls for independent development and implementation of a program results in two or more solutions so similar that one solution can be converted to the other(s) by a series of simple transformations.
• Plagiarism will be suspected if a student who completed an assignment cannot explain both the intricacies of the solution and the techniques used to generate that solution.

Here are examples of which some are clearly cheating and some clearly not cheating.

Examples of cheating:

• Turning in someone else's work, in whole or in part, as your own (with or without his/her knowledge), without it including a statement of collaboration in the solution.
• Allowing another student to turn in your work, in whole or in part, as his/her own, without it including a statement of collaboration in the solution.
• Turning in a completely duplicated assignment. Even if all the comments are changed, all the variables names are changed, all the whitespace is changed, and the code appears in a different order: it is still the same program.
• Several students/pairs writing one assignment and turning in multiple copies, all represented (implicitly or explicitly) as an individual student's/pair's work, without it including a statement of collaboration in the solution.
• After receiving graded written work, returning written work, for regrading, which has been altered.
• Finding a solution to the same problem on the web and submitting it without explicit attribution in the solution.
• Stealing an examination or solution from the instructor.

If you ever feel that after talking to someone about a program, which is legal, your solution will be very similar to theirs, cite the consultation in the header comment in your program. Doing so protects you from University disciplinary action (although the instructor is free to grade the material as he/she sees fit).

Examples of NOT CHEATING:

• Turning in work done alone or with the help of the course's staff.
• Submitting one assignment for a group of students if group work is explicitly permitted (or required, as in pair-programming).
• Getting or giving help about using the computers.
• Getting or giving help about solving syntax errors.
• High level discussions of course material to better understand them.
• Discussing assignments to better understand them.

Many courses in ICS use this software to spot potential cheating cases. Once it identifies suspicious behavior, instructors carefully examine the flagged code to make a final determination as to whether students will be prosecuted for cheating. Often instructors can find additional evidence of cheating, once this software points them to the simlar code.

Instructors must contact the student within 15 calendar days of discovering evidence of academic dishonesty and evaluating the relevant work. Notice of any action taken by an instructor will also be forwarded to the Associate Undergraduate Dean of ICS, the Associate Undergraduate Dean of the student's home school (if different), and the Office of the Dean of the Division of Undergraduate Education. These offices act as a repository for such information, in case the student commits multiple infractions.

Although it is embarrassing to fail an assignment, getting caught cheating is much worse. I know, though, that students rarely think about getting caught. But think about it: I often see students break down and cry when they get caught cheating and only then start to realize the consequences of their actions. Their stress level goes through the roof and it immediately affects both the academic and social parts of their lives. The process is distressing for me too, although I must confess that I have been hardened by the number of times that I have had to go through it (typically multiple times each quarter). Pursuing these cases at the University level takes a lot of my time, and reduces the time that I can spend on more important matters relating to my course and my students. It is definitely a lose-lose situation.

Cheating is like playing Russian Roullete: you may get away with it a few times, but the more times you cheat, the more likely you will get caught.

The #1 excuse that I hear for cheating is, "I was pressed for time, so I cheated." By carefully managing your time, you can avoid this problem. If you start working early enough, and run into problems (and you should expect to run into problems), you will have time for the course staff to help you learn to solve them. Also, I understand that some students take this course only because it is a requirement for their major, and that they have little intrinsic interest in the subject area; this is not a valid excuse for cheating either.

I have seen too many instances recently where student A asks a friend, student B, for help; specifically, A asks to see B's quiz or code (on paper or in a computer file). Often, A copies B's answer (with or without B's knowledge). I understand that B feels pressure to give A help. But, B is doing A no favor if A's cheating is discovered; B has made a bad situation (A would receive no credit) worse (A receives negative credit and is reported to the Dean of Student Affairs). And, according to UCI's rules, B can get into trouble for these actions too. I have seen friendships shattered because A copies B's answers without telling B what was done, and then both get prosecuted under UCI's rules.

Like driving drunk, friends should not let friends cheat.

A similar situation arises with cheating on quiz questions. I have seen too many students cheat on one question on a quiz and receive a negative score for the whole quiz (and letter to the Dean of Student Affairs), when leaving the question blank would result in a small point deduction and no university action.

Recently I have seen an uptick in problems where students programming in a pair divide up the work instead of working together. Then, one student cheats on their part of the program, without telling his/her partner. When I discover the cheating there is lots of bad will between the students, who both get in trouble.

In my final statement here, I ask you to pause and reflect on the consequences of choosing to cheat at UCI: this includes the impacts that it will have on you, your parents, your siblings, your friends, and your fellow classmates at UCI. Cheating is invariably the wrong decision.

If you need such an exception, email me as soon as you know about the problem and ultimately bring a copy of the required documentation to me as soon as possible: beforehand if you know about the problem in advance, on the next day that you are able to attend class (or during my office hours) if you do not have advance warning. I will need to keep the copy for my records. Again, if you have advance notice of a problem, please notify me by email beforehand to discuss any ramifications.