Informatics 45 Spring 2010
Lab Manual
The projects
Introduction
This quarter, you'll work on four programming projects. As you proceed through that work, you'll notice some things:
There is a method to this madness: this course is intended to strengthen your ability to design and implement larger programs than you may have written in the past, to give you confidence working individually as well as in pairs, and to cultivate your ability to construct programs out of existing components that you have not worked with before. No one, regardlesss of his or her level of experience, is intimately familiar with every detail of every part of the Java library (which consists of many thousands of classes), nor with the range of open-source and commercial components that can be used in building a software system. If you want to build interesting software, it is absolutely critical to have the ability to find existing code that might help you solve a problem, quickly learn enough about it to understand whether it will help, then to figure out how to integrate it into your own system if it does.
Your projects will be evaluated based not only on how well they work, but also on how well they are designed, written, and tested. Poorly-written code that works will be viewed as critically as well-written code that has bugs. Don't worry, though; we know that most of you are still relatively new at designing programs, so we'll be providing plenty of help along the way.
Additionally, there will be some writing required along the way. You'll be asked to plan ahead and to explain your plan — where the decisions you've made are demonstrably grounded in facts and your experience — before you proceed too far on coding up your project. After each project, you'll be asked to summarize various lessons learned, so that you will be better equipped to handle similar problems going forward.
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 and how much your confidence has risen.
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 members of the pair 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 partner. If you do not select one within a reasonable amount of time, we will select one for you.
For each paired assignment, you will be required to partner with someone who you have not partnered with previously in this course. (If you took Informatics 41, Informatics 42, ICS 21 / CSE 21, or ICS 22 / CSE 22 previously, you will ideally find partners other than the ones you worked with in those courses. One of the goals of your education should be to build a social network; you can't build a social network without meeting and working with a variety of other people.)
After deciding to pair up on an assignment, notify your TA of the pairing. Your TA may prefer this notification to be done in person or via email; if you're not sure, ask your TA for his or her preference.
Pairing advice
The best time to find a partner is during your lab section. 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 a direct result of getting to know someone while I was a student at UCI.) 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 an 18-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. |
| Documentation of project planning | 3 points | Have you thoroughly considered what direction you plan to go as you work on your project? Have you justified the decisions you made about what direction you plan to go — which project you've chosen (when given a choice), which layout manager you'll use, which open source component you chose, which menus will contain which commands? Did you make the choices seemingly randomly or were you able to use facts and experience as a basis for your decisions? |
| Documentation of lessons learned | 3 points | Have you thoroughly answered the specific "lessons learned" questions posed in the project write-up? Did you demonstrate an awareness of what went well and why — so you can recognize similar situations and handle them similarly? Did you also demonstrate an awareness of what did not go well and why, as well as suggest ways that you could have done better — so you will not make the same mistakes again in the future? |
| Total | 18 points |
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, since doing so can have a negative effect on potentially every member of a large team.
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 or a TA; 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.
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 a solution to it.
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 Informatics 45 is Eclipse Classic 3.5.2, a free integrated software development environment. Eclipse is a full-featured, open-source 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, as well as error messages that are somewhat more friendly than those that emanate from Sun's command-line compiler.
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 a cross-platform language. The intent is that Java programs can be executed on a variety of platforms (e.g., Windows, Mac, Linux) and work identically (or as close to identically as possible) on all of them. The machines that you'll be using in the ICS labs run Windows, though you're welcome to do your work on any platform you'd like. You should be aware, however, that subtle bugs and differences do exist between Java implementations, especially when you start moving beyond the core language and into the libraries, as we'll be doing. When we grade your projects, we will be using a Windows implementation of Java to do so; we expect your programs to work correctly on the Windows implementation, so you are encouraged to test your programs on the machines in the ICS labs before submitting them.
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, JDK 6 can be downloaded from java.sun.com, the same way it can for Windows. You're on your own as far as installing it goes, but I assume you can handle that, or you wouldn't be Linux users. :)
Java Links
Wondering how a particular class in the Java library works? Sun's Java 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!
Looking for a good on-line Java tutorial? Start at Sun's Java Web site (java.sun.com), and find a link somewhere on the page that leads to tutorials. (They rearrange their pages fairly often, so I didn't provide a direct link.) The Java tutorial is organized into "trails" that lead you through various topics, from simple to advanced. Be aware that many of these tutorials will be somewhat out of date.
Academic honesty
The policy
As Informatics 45 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.
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 Final Exam is also expected to be an individual effort. 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.