ICS 22 / CSE 22 Fall 2012
Lab Manual
The projects
Introduction
This quarter, you'll work on six programming projects. Five of them will be written in Java; the other will be written in a functional programming style using a programming language called Racket. You will discover that the projects increase in size and difficulty as the quarter goes on, but if you put the appropriate amount of effort into each of them, you'll find that your skill level will rise steadily to match the rising difficulty. Some projects you will work on in pairs using a technique called pair programming, while the others will give you the opportunity to work individually.
Some of the projects will include a starting point, in the form of documented code that I provide to you as a means of getting started. As the quarter progresses, you'll find that you're being asked to write more code, to write more of it from scratch, and to build programs that are made up of a progressively larger number of interacting parts. There is a method to this madness: not only will this course strengthen your ability to write individual Java methods, but it will also begin to cultivate your understanding of the design of ever-larger programs. Your projects will be evaluated based not only on how well they work, but also on how well they are designed and written. Poorly-written code that works will be viewed as critically as well-written code that has bugs. Don't worry, though; we don't presume that you've had any experience designing your own programs before, so we'll be providing plenty of help along the way.
By the end of the quarter, when you've successfully worked through all of these projects, you'll be surprised at how much your skills have improved.
Pair programming
What is pair programming?
For some of the projects in the course, you will be required to employ an approach called pair programming. Pair programming is not just two programmers working separately on a task, with the work divvied up between them. In pair programming, two programmers share one computer. One is the driver, who controls the keyboard and mouse. The other is the navigator, who observes, asks questions, suggests solutions, and thinks about slightly longer-term strategies. The two programmers switch roles about every 15-20 minutes, the goal being that both partners have complete mental ownership of all the work that's done, even though only one person at a time is typing. This obligates both partners to communicate with one another about what they do and do not understand, with each partner bringing the other one up to speed when necessary. In so doing, both partners have a firmer grasp on what they're doing and, at least as importantly, why they're doing it that way.
A pair of programmers (as described here) nearly always beats the stereotypical solitary loner of similar ability. The pair produces more high-quality code in less time, by far more than a two-to-one margin. For projects that require pair programming, we'll be requiring you to follow this model, and will be keeping track of students who aren't; we reserve the right to penalize students who routinely refuse to work as pair programmers.
While some industry software development environments use pair programming to (documented) good effect, the reality is that individual programming is still a widely-used strategy in the real world. Many future courses that you'll take here will require individual work, as well. Study after study shows that working in pairs at this stage of your development as computer scientists will strengthen your abilities to work individually, as well as in pairs. Still, we'll only use pair programming for a portion of this course; some projects will require individual work, to acclimate you to the demands of future courses and/or future employers. Rest assured that successful pairing to this point has made you more ready to work individually than you would have been had you been working individually from the beginning. Also remember that the course staff — me, the TAs, and the lab tutors — are here to help!
Pairing rules
For each paired assignment, you will be required to select a lab partner who is also enrolled in your lab section. (For a variety of logistical reasons, pairing of students in different lab sections will not be allowed under any circumstances.) Additionally, you will be required to partner with someone who you have not partnered with previously in this course. (If you took ICS 21 / CSE 21 previously, you will ideally find partners other than the ones you worked with in that course, as well.)
After deciding to pair up on an assignment, notify your TA of the pairing via email. Be sure that you include the names and UCInetIDs of both partners in the email.
Pairing advice
The best time to find a partner is at the ICS 22 Help Center. Don't be shy! Talk to people! (Part of the benefit of a university education is the social network that you'll have when you're finished. True story: Every job I've had since I enrolled as a student at UCI, including this one, was directly connected to my UCI experience.) If you're having trouble finding a partner, talk to your TA; he or she will be happy to help you find one.
It's not a bad idea to find a partner whose skill level is similar to yours, or one who is more skilled in areas where you are less skilled. This won't always be possible, and it's sometimes hard to compare skill levels at all, but students tell us (and other data support) that pairs are most productive when the partners are at about the same level.
Still, people often pair up with another whose skills and abilities are different. The differences may be great or small; one member may have more strengths than the other. But this is exactly like most real-world working situations. Part of accomplishing a task is to get the most out of each member and make each member stronger and more productive on subsequent tasks.
A clearly stronger partner may feel frustrated or slowed down by the other partner, but the stronger partner benefits from the teamwork in many ways: The other partner's requests for clarification often point out flaws in the approach or solution, the teamwork skills gained have great value in the job market, and the exercise of providing a clear explanation solidifies and deepen's the explainer's own understanding.
The less strong partner may feel that questions hold the other partner back or that there is no benefit to participating actively, but pair programming studies show that paired work is consistently better than work the stronger partner does individually. It is part of each partner's job to understand the whole task; that means asking questions when necessary and answering them when possible.
Am I expected to work with my partner outside of the scheduled lab sections?
Generally, yes. You'll likely need to spend some time, on at least some projects, working outside of the scheduled lab sections. It's not my assumption that you'll always be able to get the projects done by working strictly within the lab sections; some projects will take more time.
Understand, though, that you're not doing pair programming if you're in separate locations talking via instant messages, sending code back and forth via email, or even talking on the phone. Pair programming requires both partners to be in the same room, sitting behind the same computer, with one acting as the driver and the other acting as the navigator. I'm not unsympathetic to the fact that scheduling time to work together is difficult, but it's a requirement of the course, and you should be aware of it up front.
Evaluation of your work
Evaluation criteria
Each of your projects (except for the last one) will be graded using a 15-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. Each of your projects will be evaluated on the following basis:
| Quality | Value | Description |
| Correctness and robustness | 6 points | When the program is given valid input, does it generate the correct output? Is the output spacing correct, if this is an issue? In short, does the program do what it's supposed to do for any input that meets the project specifications? When the program is given unusual or erroneous input, is it handled gracefully? Programs should not crash in these situations; they should print informative messages to the user and continue executing (if possible). |
| Quality of solution, documentation, and style | 6 points | Particularly awkward, cumbersome, or inappropriate ways of approaching problems will not score as highly as cleaner, better-designed ones. Your program should be divided into logical parts using classes where appropriate, each encapsulating a single idea or task. Large methods should be broken into smaller ones that do simpler jobs. There should be enough comments to make the program clear to the reader (though it should be noted that good modularity and well-named identifiers make the commenting burden significantly lighter). Identifier names should be chosen to reflect their function; the names should be meaningful to the reader. The course style standards should be followed. |
| Testing | 3 points | How comprehensively have you tested your program? Have you considered a representative set of normal cases? Were the cases well-chosen to reflect a variety of program conditions, or were they chosen haphazardly? Do your tests also address the robubstness of the program, by including a representative set of error or boundary conditions? Keep in mind that the number of tests is not necessarily important, and we will not ask you for a specific number of test cases. In other words, concentrate your efforts on quality rather than quantity. |
| Total | 15 points |
The last project, which you will write in Racket and will be structured somewhat differently than the others, will be graded using a different scale, but will have the same weight as the others in your final course grade.
Programs that do not compile
If you submit a program that does not compile, we will not be able to execute it and, thus, will not be able to evaluate its correctness. It is your responsibility to turn in code that compiles. We reserve the right to assign zero points on the Correctness and Robustness portions of the project score for a program that does not compile, regardless of how much code there is or how close it is to working. This rule is in place not only because it is impractical for us to evaluate the correctness of non-compiling code, but to impress upon you the importance of this issue: in the "real world," there is no excuse for submitting code that does not compile.
At first blush, this sounds like a harsh policy, but it is not as difficult as it sounds to make sure your program compiles, if you develop your program one small piece at a time, ensuring that the program compiles and runs (and, ideally, runs correctly) before moving on to the next piece. It is never a good idea to write hundreds of lines of code before attempting to compile and run a program, yet many students do it. The "code-everything-then-compile" approach, which can be successful for very small programs, such as those you may have written in courses prior to this one, does not scale up well to problems the size of those you will face in this course. I urge you to consider working through your programs step-by-step, compiling and running them as you make progress. If you're not sure what the individual steps should be, talk to me, a TA, or a lab tutor; we're eager to help.
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:
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.
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
The officially-supported development environment for ICS 22 / CSE 22 is Eclipse Classic 4.2, a free integrated software development environment. Eclipse is a full-featured, commercial tool that is common in the industry, but that also boasts features that will be supportive of our work in this course, such as automatically compiling your code whenever you save it, error messages that are somewhat more friendly than those that emanate from Oracle's command-line compiler, and built-in support for the testing tool JUnit that we'll be using.
Eclipse is available for your use in the ICS labs, where I encourage you to spend much of your time working, especially on the projects that require pair programming. I also understand the reality that many of you will want to work from home when you work individually, 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. You'll need the following software, all of which can be obtained free of charge.
Java is cross-platform, so the programs you write should run the same way regardless of your operating system or what compiler you're using, as long as you're running Java 7. Still, subtle bugs and differences do exist. If you feel that you've been graded unfairly on account of such a bug, let us know, and we'll make sure that your grade is not adversely affected by incompatibilities between virtual machines. (I should point out that this will be a rare occurrence indeed; in the many years that I've taught at UCI using Java, this has occurred no more than a couple of times.)
How do I set up Java on my computer?
Here is a document I've written that describes how to set up Java on a computer running Windows or Mac OS X.
If you use Linux or Solaris, JDK 7 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 online.
Java Links
Wondering how a particular class in the Java library works? the Java 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 existing documentation is an invaluable skill in a "real" software development environment, 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!
Racket Links
When we work with Racket this quarter, we will be using an environment called DrRacket. This is a free environment built specifically for teaching and learning Racket. It's fully functional and should support any work you'll need to do for this class. DrRacket runs on Windows, Mac OS X, and various flavors of Unix and Linux. As of the beginning of this quarter, the latest stable version is 5.3, though new versions come out fairly frequently, so you may find a newer version by the time you download and install it.
How to Design Programs is an online textbook that is intended for introductory programming courses that are taught using Racket (which this book refers to as Scheme). This book is well beyond the scope of our limited coverage of Racket, but you might find it useful as a reference, or if you're interested in learning more about Racket on your own. (Personally, I think it's fascinating stuff.)
Academic honesty
The policy
As ICS 22 or CSE 22 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 (and your partner, on paired assignments). Worker in larger groups and/or sharing of code between students that are not partners 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 (and your partner, on paired assignments), you will be held responsible even if you plagiarize only a small portion of someone else's work.
You are not permitted to reuse code that you wrote along with a partner during a previous quarter. You may only reuse code that you wrote on your own, and you may only reuse it for a project that is not paired this quarter. (The reason for this rule is simply that I do not want students repeating the course to pair up with someone new and deprive them of the opportunity to work on the project. Besides, if you're repeating the course, it's generally a good idea to start fresh, to solidify the ideas you missed the first time around.)
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.