Project Observations

Gallery of Peg Puzzles



See the wiki for Image Caption project designs (must be on an SIUC computer or connected through VPN)

Teamwork

For both projects there were examples of good balanced teamwork which in general produced superior results. We are also seeing examples of this in the Robot Simulation project. There are also some comments and suggestions which indicate that teamwork could be improved. Please read through these and with honest self-reflection be respectful to others and continue trying to improve yourselves.

Some people feel that:

  1. their ideas haven't been fairly listened to
  2. they have had teammates who were too bossy (might relate to above)
  3. they have had teammates who haven't done their fair share of the work
  4. that explaining things to their teammates has slowed them down
  5. that it is hard to meet with teammates outside of class
  6. it is frustrating trying to figure out what the customer wants
  7. it is hard to figure out who is supposed to be doing what
In general, pairings seem to work best when both partners have mutual respect for each other perceive each other's skills to be about equal. For the good of the project as a whole, sometimes patience is required to slow down and explain things to a partner. Professionals report that they often learn things when paired with some one much less experienced.

The process of explaining and working with someone with a different perspective can introduce new ideas. It is also good for knowledge about the project to circulate through the team rather than having numerous patches of code only understood by certain individuals. During the customer project you are urged to work with several different people and on different parts of the code. Try pair programming as well.

Items 6 & 7 are difficult to give an easy answer to but becoming better at listening and communicating are a big help. It can be hard for customers to really know and express what they want. Learn to ask good questions with the goal of providing the best end-product for the customer. Practice egoless programming. Develop incrementally and iteratively getting continuous feedback (from the client as well as other developers too). Notice that this is different from the typical programming assignment where you are more or less told what to do. These situations require more creative thinking  and social skills. You may also find non-agile work environments which give much more specific (less creative) job tasks (here is the design, you code it).

Technical Notes

Version Control, Build files, Jarfiles, Javadoc

  1. Reduce redundancy in test code by using setUp(). Each test will call setUp() before it begins. Only place things in setUp() that are used by all the test cases. Tests will begin to cluster based upon what they require. You can make multiple test classes (each has their own setUp()) and compose them. See JUnit javadoc on TestCase.
  2. Do not place "local.properties", ".project" and generated files (compiled code, jarfiles, javadoc etc.) under version control. A fresh copy of generated files can be easily built with the build file. Make generated files go to a place that is "cleaned" when clean is run. Use the variables in the build file to specify where these files go. Use svnIgnore on files (like ".project" etc.) that should not be placed under version control.
  3. To avoid clutter, keep images and other special files (sounds, data etc.) in an appropriate subdirectory rather than  at the top level of the project directory.
  4. Images require special care when creating jarfiles. See item 2 under Java coding.

Java Coding

  1. Careful on the use of  "static". Constants can be declared as "public static final" and these can actually be placed in an interface. In general, static should be treated as a special case since all instances of a class will share that field.
  2. Making a self-contained jarfile with images will require your code to access the images differently then when images are stored in the file system. This class(ImageLoad) may help.
  3. Subclassing GUI components can be very useful - JButton subclass that knows how to draw pegs. Can use this idea for JLabels too.
  4. Check API for existing classes which already perform needed tasks (Point already has x,y - no need to make a new class for this) API classes may also already have equals(), hashCode() etc.
  5. Many switch/case blocks as well as other convoluted logic blocks can be reduced or eliminated by using appropriate data structures. As we saw from first refactoring the pegPuzzle code, using arrays well often eliminates having to write separate code for many different cases.
  6. Many  switch/case or if /else conditions can have duplicate code factored out and called once after all special processing is handled. For instance, in an actionPerformed() cases may exist to check which button was pressed and then issue a command to the model. The model might return a status code and then the updateGUI() needs to be called. Instead of issuing setText("some particular message") and up
  7. Many if-else blocks which test an expression and return or set a boolean could be replaced by a simple expression
    8. if (mode != illegal) setEnable( true) else return setEnable(false);
    becomes setEnable(mode != illegal)
  8. Try to maintain separate sections of code for model/view/controller
  9. The model should not know about the tests - it should not create specific code for specific test cases.
  10. Redundant code in test cases can be reduced using the setUp() function. If so, all test cases which use that setUp() should use the same items. If you are finding that your tests are not, it may be time to break up your tests into more classes.