Labs

Schedule

  1. Writing Methods, Week of January 24
  2. Pixmap, Week of January 31
  3. Smiley, Week of February 7
  4. Screen Savers, Week of February 14
  5. Midterm Review, Week of February 21 (nothing submitted)
  6. Loops, Week of February 28
  7. Debugging, Week of March 7
  8. Random Text Generation, Week of March 21
  9. Processing String Data, Week of March 28
  10. Using Sets, Week of April 4
  11. Midterm Review, Week of April 11 (nothing submitted)
  12. Recursive Art, Week of April 18

Format

In lab, students will have supervised hands-on experience with course material. Labs will consist of two main parts:

  1. Prelab
    On the Sunday prior to lab, you will be expected to submit answers to the prelab assignment. The prelab will consist of one or more programming problems and questions related to the topic covered in lab.
  2. Lab exercises
    During the lab period, the lab staff will discuss the prelab exercises and highlight some student solutions. The lab programming problems will be related to prelab assignment and may be completed in pairs. Along with the programming, there may also be questions that require you to comment and reflect on the solution you wrote. If you do not finish all of the assigned problems in lab, you will need to finish and submit your solutions outside of lab.

Small Algorithmic Programming Problems

 Many labs will be based on Small Algorithmic Programming Problems (SAPPs). For each problem, you are given a problem statement and a number of sample test cases. You will write a class that contains a method with given signature. We provide a testing mechanism for your programs that compiles your solution and runs your function on a number of different inputs and compares your method's output to the correct one. For SAPPs, the goal is to write a solution that solves the problem in the simplest, most general manner. Style is far less an issue with than SAPPs than with programming assignments. Nevertheless, using good programming practice often enables students to find a solution in less time.

To see the inspiration for these problems as well as much harder examples, see Topcoder or the ACM Programming Contest.

Pair Learning

You should expect to work with another student during labs. This process is often referred to as pair programming, which is defined as follows:

Two programmers working side-by-side, collaborating on the same design, algorithm, code or test. One programmer, the driver, has control of the keyboard/mouse and actively implements the program. The other programmer, the navigator, continuously observes the work of the driver to identify tactical (syntactic, spelling, etc.) defects and also thinks strategically about the direction of the work. On demand, the two programmers can brainstorm any challenging problem. Because the two programmers periodically switch roles, they work together as equals to develop software.

-- Laurie Williams, North Carolina State University

In other words, it is essential that all students in the group are active participants. Done right, this can be a very positive experience for all involved. For more information on pair programming and pair learning, see www.pairprogramming.com.

Comments?