Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Wu-Tang Cases: General Advice
Here's some general advice after taking CS2335/2340:
Try to choose teammates who are dedicated to the class. There are two
reasons for this: the obvious one is that someone more devoted to the
class will do more work, but also you don't want a teammate who will
drop the class right at the drop date in the middle of your project.
Get everyone involved in the design, and start designing early. If
only a few people are involved in the design, then those who are not
involved don't know what they're doing when it comes time to write
the code and they produce very little code or code that doesn't fit
the design (or both). Also, more minds involved in the design should
hopefully lead to a clearer/more implementable design.
This brings up another point. Choose a meeting time/place
carefully. You want everyone involved, so don't choose a time when
one of the group members has just gotten out of a long stretch of
classes, hasn't eaten for hours, etc.
Figure out a good system of sharing your code. Squeak code isn't
very editable outside of squeak, so you can't use an external
editor (effectively) and squeak doesn't have CVS built-in, so
integration can be difficult.
We chose to file out each class as an individual .st file, so we
could easily file-in each other's code without messing with our
own. Once we finished all the classes in a class category, we could
then just file out the whole class category. We also put version
numbers into the filename when we filed out the code, and uploaded
all the code to a central FTP server. This method leads to a large
number of .st files, but it works.
Also, if you have a function inside of a class (lets say the function
foo inside of class MyClass) and you delete the function and file-out
the class, then someone else files in the file to an image that already
had the class (and the function) then the function will NOT be removed
from that image. (Filing in files just adds the new code and changes
any functions that are changed, it doesn't keep track of removed
functions). Changesets might take care of this problem, but we didn't
want to take the time to figure out changesets, because changesets
have problems of their own....
Don't choose an artist or a perfectionist to make your GUI. Pick
someone who works early and hard, so that you can actually see your
program run. Nothing sucks more than finishing the model ahead of
time and staying up all night the night that it's due trying to make
a GUI because the GUI person is a slacker...
Most Importantly, if you are allowed to demo a milestone (which you probably
will be) then do so. Doing a demo for the TA allows you to show the TA what
works without them getting frustrated trying to figure out you're program (not
a good idea to get you're TA frustrated). This can bring you're grade from an
F to a C or B, or from a B or C to an A. Furthermore, you won't have to spend
time writing a perfect README file.
Finally, get the program working before adding polish. And before
making it fast/efficient. A program that works slowly is infinitely
better than a program that crashes quickly.
Link to this Page