ICS 23 / CSE 23 Summer 2012, Lab Manual

Evaluation of your work

Each of your projects will be graded using a 4-point scale. As you work on your projects, it is naturally your primary goal to write a program that works correctly. However, writing a correctly-working program is not your sole objective. The evaluation of each project will also consider issues of design and style, as well as correctness and completeness.

An explanation of the 4-point scale follows:

0 points. You submitted no work. Note that this includes submitting a program in which no attempt was made to solve the problem given (e.g., submitting only the code that was provided as a starting point, or code that has nothing to do with the problem given).
1 point. Some attempt was made to address the requirements, but the work is mostly incomplete and poorly done. Programs that do not run will generally be awarded no more points than this.
2 points. The work you submitted is of reasonable quality and completeness, addressing at least the most important of the requirements. The program runs. Shows a basic understanding of the material, but not a complete one. Presentation may be significantly lacking (e.g., a program that is hard to follow or has a cumbersome design).
3 points. Work that is of high quality and is complete and well-presented — with perhaps a few minor errors and/or design or style problems. This is the score given for good, solid — but not extraordinary — work.
4 points. Work of very high quality that demonstrates a full and complete understanding of the material covered with a very polished presentation. The program is complete (contains the features specified) and correct (functions as it should, with no errors).

If we find it difficult to decide whether your work is best represented by one score or another — say, we're deliberating between 2 and 3 — we may award the half-point in between — say, 2.5. You can expect that this will be relatively rare.

Late work

Things happen and ten-week quarters can be unforgiving. It's not unreasonable to expect that you may find it difficult to finish one of the projects on time, even if you're on top of things most of the time. I get emails often from students, saying things like If I just had one more day to work on this, I'd get it done! On the other hand, being consistently behind is a recipe for struggle in this course; we'll be moving quickly, and it will be progressively harder to catch up the farther behind you get.

The best balance between these two realities is that everyone is allowed to have a tough time with a project once this quarter — maybe you underestimated the difficulty of an assignment, maybe you have three midterms and a paper due the same day, maybe you have a sudden outside commitment that can't be avoided. For this reason, I'm offering the following late work policy:

Each student is permitted to submit any one project up to 48 hours late, with no questions asked about why and no prior notification required.

For the purposes of clarification, here are some additional details about how this policy works:

You are not required to notify us in advance — in fact, in all honesty, we'd prefer that you didn't. (There are a lot of students in this course, so that would represent a lot of extra work for us.) We'll be looking for submissions up to 48 hours beyond the deadline of each project.
There is a ten-minute grace period after the due date, allowing you time to get your files submitted to Checkmate. If you submitted your files at 12:08am for an 11:59pm due date, you're fine. Best not to play with fire, though, if you're already done before 11:59pm; at 12:11am, you'll have used up your one-time extension. No exceptions!
The first project that you submit late will fall under this policy; any subsequent project you submit late will not be accepted. (In other words, you can't submit two projects late, then wait to see which one you get a better score on; we won't be grading the second one.)
If any one file is submitted beyond the ten-minute grace period, the entire project is considered late.

We'll be tracking this throughout the quarter and, of course, will not grant the extension to anyone more than once. But this should accommodate the unforeseen issues that might otherwise prevent you from finishing a project on time.

Other than this, late work is not accepted in this course.

Out-of-the-ordinary circumstances sometimes warrant exceptions to this policy; if you are faced with a problem that is preventing you from getting your work done on time, either on a single assignment or chronically, please contact me and we can talk about how best to approach the problem.

Paired or group work

In this course, your programs are to be written individually. No paired or group work is permitted.

Re-evaluation of your work

The TA will be grading all of the projects this quarter. If you believe you've been graded unfairly, you should first contact your TA to discuss the issue. If, after that conversation, you're still feeling that your score does not fairly represent your work, contact me and I'll be glad to arbitrate. Understand, however, that my overruling a TA's judgment is relatively rare.

Style standards

In an organization (be it a corporate environment or even an open-source project), good software development is not just about writing a program that works. It also requires writing a program that is easy to understand, both for the original author and others who may work on it in the future. It is important that the program can be maintained easily as bugs are found and new user needs inevitably arise. Style standards (including, but certainly not limited to, documentation requirements) help ensure that code written within an organization can be understood by everyone else within it.

For this course, I've defined a set of style standards that I'm requiring you to follow as you write your programs. These standards will ensure that we'll have an easier time reading your programs as we help you with them and grade them. More importantly, they also will help instill good "code cleanliness" habits that you will carry with you long after the course is over.

Submitting your projects

When you complete each project, you must submit it to us electronically. Follow this link for a detailed description of how to submit your projects. Understand that we will only accept projects submitted using the procedure described there; we do not accept printed copies of your projects, nor do we accept them via email under any circumstances.

You are responsible for submitting the version of your project that you want graded. We will grade the most recent submission that you made before the deadline. Accidentally submitting the wrong version will not be considered grounds for a regrade.

Development environment

We will be doing our work in Java, using Java SE 7. You have your choice of development environment in this course, the only requirement being that you submit Java source code (.java files) to us that are compatible with Java 7.

If you took the two previous courses in this sequence (ICS 21 / CSE 21 and ICS 22 / CSE 22) here at UCI, you'll likely have used an integrated development environment called Eclipse. If you've taken your prior coursework elsewhere, you may have tried other options, such as NetBeans, BlueJ, or the command-line javac compiler and a text editor. In general, I'd encourage you to consider Eclipse (or another integrated environment, such as NetBeans) for your work this quarter, as it offers features like an integrated debugger that you'll likely find helpful as you work on your programs. But you're welcome to use whatever makes you feel comfortable.

Setting up your own machine

While I encourage you to work on your projects in the labs as much as you can, so that help will be available for you when you need it, I also understand the reality that many of you will want to work from home, or on your own laptops wherever, at least part of the time. You're certainly welcome to do it, though it should be noted that you're responsible for obtaining and installing the required software on your own machine(s). Unfortunately, we realistically cannot support each of your home installations, so you're mostly on your own in getting these things set up and maintained. However, I do have some information that will help.

Here is a document that describes how to set up Java on your Windows- or Mac OS X-based machine. If you use Linux or Solaris, Java can be downloaded from Oracle's Java SE Downloads page, the same way it can for Windows, and can also be downloaded using built-in "package managers." Installation procedures vary from one distribution of Linux to another, but ample documentation is available onine.

If you've never used Eclipse and you're looking for a quick tutorial, have a look at Lab #0 from my most recent offering of ICS 22 / CSE 22. In particular, I'd suggest using the workspace I provided in that course, as compiler settings and other configuration has been set up properly for introductory Java programming work.

Java Links

Wondering how a particular class in the Java library works? The Java 7 API documentation is exactly what you need! When I'm writing Java code, I spend a lot of time there. After all, who can remember all the parameters to all of the methods in the Java library? Besides, learning how to look things up in documentation is an invaluable skill, so it's best if you start developing that skill now. Of course, if you're not sure where to look, we're happy to help!

Academic honesty

The policy

As ICS 23 or CSE 23 students, you are expected to know and follow the academic honesty policies of both the Bren School of ICS and the University as a whole. Please take a few minutes to read the policies, which can be found at this link.

All of your lab work is expected to be completed solely by you. Worker in larger groups and/or sharing of code between students is not permitted. Note that "high-level discussion of course material for better understanding" is permitted and encouraged, but when it comes time to sit down and write code, that is expected to be done by you and you alone. All submissions are compared to one another using an automated plagiarism detection system. This system is extraordinarily good at finding similarities between submissions, even when there are superficial differences. (Note that we also compare your submissions to those submitted during previous quarters whenever one of these assignments was given during a previous quarter, so it is an exceedingly bad idea to turn in, or even refer to, code written by a friend of yours who took the course already.)

Since all of your work is expected to be completed solely by you, you will be held responsible even if you plagiarize only a small portion of someone else's work.

Academic honesty is a two-way street. Providing your code to other students for them to turn in as their own is not permitted anymore than turning in someone else's code. Resist the temptation to give code to your friends "for reference." Based on my experience, I can say that your "friends" may very well betray you and turn it in, anyway.

Naturally, the Midterm and Final Exam are also expected to be individual efforts. Dishonest behavior during an exam will not be tolerated.

Violators of academic honesty policies are subject to the penalties described in the Bren School of ICS policy. They are also subject to an immediate course grade of F, and you will not be allowed to drop the course to avoid the grade. Also be aware that a single documented case of academic dishonesty may preclude you from switching into computing majors, registering for computing minors, joining the ICS Honors Program, and graduating from a computing major with honors.

The lesson

Okay, so the moral of the story is that it's wise to avoid cheating. I believe that it's relatively rare that students enter a course with the conscious intent to cheat their way through it; why come to UCI if you're not planning to get something out of the coursework? So why do people cheat every quarter in every course? The answers vary, but here's the easiest way I can boil down the numerous conversations I've had with students caught cheating in my courses over the years: I fell behind and couldn't figure out how to catch up. Things happen and ten-week quarters are unforgiving. You might get sick, you might have issues crop up in your family, you might have an off-campus job that's demanding too much of your time, you might be trying to decide whether you're on the path you want to be on... Any of those things (and many others) can make it hard to keep up. You fall a little behind, you fall a little further behind, and pretty soon the situation seems hopeless. You're under pressure, temptation gets the better of you...

If you feel like you're beginning to slip off course or things are getting beyond your control, the best thing to do is to talk to us sooner rather than later. We're here to help; we understand. But the reality of taking large-sized courses at a large-sized institution is that we're not going to know you're in need unless you tell us. If things are happening in your life, tell us; you don't have to be specific if you're not comfortable with it. Before the fact, there's often a way to work things out. After the fact, it's usually too late.