Assignments: Provide sample README before first assignment. Providing READMEs for all sample code is sufficient. Assignments: Provide more guidance about testing thoroughness before first assignment. Assignments: Specify test code policy for GUI-based programs. I.e., test code not expected, but helpful for partial credit. Assignments: More clearly specify course-wide assignment expectations. Assignments: Students often just generate UML diagrams at the end of a project, rather than at the beginning. As such, they don't provide significant evaluative feedback. Either better motivate their need to produce them or drop them from requirements. (Students _do_ find UML diagrams useful for understanding provided code and examples.) Assignments: Provide a sample solution for all assignments. Assignments: Clarify when students need to provide O() analyses for code. Assignments: Hangman: Replace hangman project as potentially offensive? Assignments: Hangman: Get all the hangman sample source code organized in one place. It is currently distributed among a lecture, a tutorial, and the assignment. Assignments: Hangman: Use a standard mutable list and the Adapter Pattern, rather defining special lists for letters and body parts. Assignments: Hangman2: Specify GUI or the MVC pieces in more detail? Would allow partial automated testing. Could reduce confusion. Assignments: Hangman2: Provide commented stub code to explain purposes of each method described in sample MVC code. Assignments: Hangman2: Why does the sample MVC code use two pictures and two BodyPartsLists? This is confusing since hangman3 doesn't. It complicates code, especially by having list-end-accessing functions. Either simplify or explain/motivate. Assignments: Stacks and queues: Fix wording -- LRStruct doesn't have methods to access the end. Assignments: RPN: Replace RPN project because of similarity to COMP320's RPN projects? Some students complain of too many RPN projects. Assignments: RPN: Simplify the design or explain it better. Several features seem to be present for the sole purpose of testing various skills. As a result, it doesn't seem very coherent. One possibility: Make the main goal be stream-based I/O, eliminate the expression/interactive mode confusion by making a GUI and keyboard interface two different views of the same calculator (I.e., calculator model would just see single operations, and all stream tokenization would be in the view.), and eliminate the unmotivated stack rolling operations. For consistency with COMP320, could make the keyboard interface a subset of that used in dc. Assignments: RPN: Change sample RPN GUI to meet new specifications. Assignments: RPN: Standardize at least some key issues for the implementation, so that we can use a standard test client for grading. Assignments: RPN: Need to specify behavior on erroneous input, including division by zero. Need to specify how to quit program. Assignments: Strongly consider dropping the middle deadline. This would give the students more flexibility in scheduling work and decrease the grading workload. Besides, it is essentially impossible to email grades from the middle deadline before students reach the final deadline. Assignments: RPN: Rename FormStream to EvaluateString. Have it take a String instead of a Reader. Assignments: Othello: Comment provided code. Assignments: Othello: For consistency, decapitalize the method names. Assignments: Othello: Fix provided code. Need to pass OthEngine around, not just the board. Assignments: Othello: Specifications can be confusing in that students may initially write a version that doesn't use eval(). This is unnecessary extra work. This is especially confusing since this idea only makes sense if NextMove() looks one move ahead -- but it shouldn't, since looking ahead moves is eval()'s job. Assignments: Othello: OthEngine needs to make OthBoard.SIZE visible to players. Assignments: Othello: Clarify that can tell that a game node is a leaf if there are no legal moves. Exams: Need to be better specified to eliminate ambiguities. Pretest them! Finish them more than one day ahead of time. Notes: General: Put all TEX and ASCII sources in the notes directory. This is helpful for future instructors of the class by having a single repository for all course information. Notes: General: Lectures stand alone too much. Consider breaking notes into units of topics, rather than class periods. (Pragmatic benefit: Avoid overlapping notes when you don't finish a topic in a lecture.) Also, emphasize what the overall progression of material is. Notes: General: Organize each lecture or topic into its own subdirectory, and provide a single link per lecture/topic. Notes: General: Organize the material based upon primarily the data structure and algorithm content. OO and patterns are important concepts throughout the course, but they aren't the concepts used for organizing the material. Similarly, reword material so that patterns are the techniques to accomplish higher-level goals, such as presenting kinds of data structures? Learning patterns is not a satisfying end unto itself. **This is not a suggestion to reduce the OO and patterns content.** E.g., * Course overview * Basic data structures I.e., how to do COMP210 material in Java. Includes basic OO (inheritance, polymorphism, ...), Java syntax intro, some patterns (union, state, visitors, ...). * Immutable recursive data structures * Mutable recursive data structures * Mutable arrays * Data structures & algorithms, using the previous building blocks. Asymptotic analysis. Containers, stacks, queues, balanced trees, hashtables. Searching (including min/max), sorting. Inner classes, GUI, animation, threads are brief asides from this organization. Notes: General: Provide pattern "prototypes" for every pattern. I.e., in addition to examples, provide a general summary of the purpose and features of each pattern. This should include a UML diagram with holes. Notes: Overview: Set up course working expectations better. E.g., clarify that students will be expected to learn Java syntax mostly by example. E.g., assignments will be larger and more loosely/flexibly specified than in COMP210. Notes: Overview: Reorganize to emphasize the following points, and how this course will deal with them: * Code reuse (including OOP, especially inheritance, and polymorphism). Relate to Scheme/COMP210's use of polymorphism and helper functions. * Information hiding (including scope, access modifiers, and packages). * Static code analysis (including static typing, various kinds of classes, subtyping, access modifiers). Give general introduction to what static code analysis is and why it is useful. Note how it complicates syntax. Relate to COMP210's use of "contracts". Reinforce these ideas by using these terms when introducing details later. Notes: Overview: Relate COMP210's use of design recipes and templates to design patterns. COMP210's first templates are based solely on data definitions. Later, students saw that the template (and program structure) also depended on a basic idea of how data is to be used. Design patterns are based on the same ideas, plus also various ways of structuring code to accomplish information hiding and dealing with static typing and inheritance issues. Notes: Union pattern: More clearly relate to COMP210 recursive data definitions with specific examples. Notes: Union pattern & Singleton pattern: Initially relate Scheme's "empty" to a singleton object, and don't mention Java's "null" in this context. This virtually eliminates the need to ever mention the C-style use of "null" in recursive data structures. Notes: Union pattern: Give concrete example of how the union pattern combines with information hiding. Contrast the use of public fields vs. private fields with selectors/getters and modifiers/setters. This can double as the syntax intro for field selection, method calls, and access modifiers. Notes: Union pattern: Give a simple tree example. (Could be in lab instead.) This helps students generalize what the union pattern is, plus is more similar to COMP210. Trees are fundamental, and this is a natural place to discuss them, instead of later. Notes: Factory pattern: Introducing in conjunction with immutable lists provides poor motivation. Since its use is not emphasized, why not put it off until a more appropriate data structure, such as 2-3-4 trees, where the desired visible interface is clear, but there are multiple reasonable implementations of it. Notes: Factory pattern: Students are unclear on when to use it, since the motivation is weak, and only one assignment requires it. Notes: State pattern/Mutable lists: Reword intro so that the subject is mutable data structures. State pattern is merely the technique to accomplish this goal. Notes: State pattern/Mutable lists: Give a simple tree example. (Could be in lab instead.) Again, this would be more similar to COMP210. This is a natural place to discuss them, instead of later. Notes: State pattern: Avoid the term "node", unless this is indeed standard terminology. It conflicts with the traditional tree terminology when using mutable trees. Notes: Inner classes: Compare to Scheme local functions. Anonymous inner classes: Compare to Scheme lambda. Notes: Inner classes: Consider discussing earlier. Named inner classes shouldn't be a difficult concept, and could easily be introduced with the Union Pattern, especially in conjunction with the Factory Pattern. More provided code should use inner classes. Notes: Arrays: Compare to the nearly identical Scheme vectors. This should actually reduce the amount of time necessary to discuss them. Concentrate instead on the type issues, which are new to students. Notes: Array Containers: Add intro discussing the invariants to be maintained, before presenting code. Point out that these are not the only possible invariants. Notes: Have a real introduction to overloading. It currently gets hidden in a couple other examples. Notes: Circular lists: Talk about circular *doubly-linked* lists, to distinguish them from circular singly-linked lists. Notes: Circular lists: Unclear motivation for circularity. Why not just present non-circular doubly-linked lists? Circularity is not useful that often. Notes: Binary search: Add intro discussing the invariants to be maintained, before presenting code. Should be able to cover more quickly, since the presentation is essentially the same as in COMP210. Notes: Sorting: Need a transition from COMP210's functional sorts (i.e., sorting produces a new, sorted data structure) to COMP212's in-place sorts. Should be a generic intro that places the COMP210 list-based sorts and COMP212 array-based sorts in a larger context. E.g., sorting can be done on many different data structures. E.g., could have in-place sorting of lists, or functional sorting of arrays. These two courses simply examine the most common cases. Notes: Heapsort: Provide a simpler constructor that just sorts an array, and doesn't have low and high indices as parameters. Notes: Hashing: Comment the provided code more. Notes & Tutorials: Early on, clarify the correspondence between directory structure and packages. Notes & Tutorials: Rename LRStruct to MutableList, or something more mnemonic and meaningful. Notes & Tutorials & Assignments: Min-max: Inconsistently talk about board values in range [-1,1] while having heuristics that return values outside this range. Tutorials: Register & Emacs: Figure out how to automatically set up their emacs with Java color fontification and DOS-mode. Tutorials: UNIX: Choose subset of commands better, and use smaller subset. Add examples of relative and absolute paths. Move the changing of shells into a recommendation for them to do on their own, but specifically mention that they'll need, e.g., a .bashrc. Add a use of background mode and &. Tutorials: UNIX: Could minimize the amount of UNIX initially introduced by adding a UNIX Tip at the beginning of each lab. That could also allow each tip to be better motivated, by fitting it within the context of an appropriate lab. Tutorials: StructureBuilder: Show how to generate UML PNG-format image file. Tutorials: Clarify compilation and execution commands interaction with packages. Tutorials: Give a general intro to error-checking and defensive programming? Students have not seen this in COMP 210. Tutorials: Re-add a tutorial on nested classes and anonymous inner classes. As an example, show how it applies to the state pattern. Tutorials: MVC: Put all Swing-specific calls in the view. Emphasize that is what the MVC Pattern is all about. Tutorials: MVC: Provide a sample with two different views. Tutorials: IO: Need more explanation of when and how to use StreamTokenizer. Tutorials: IO: Need more explanation of difference between InputStream and OutputStream vs. Reader and Writer. Tutorials: Applets: Stands alone too much. Put adjacent in schedule to MVC tutorial? Have assignment with applet GUI? Show example with AWT and Swing views of same model. Tutorials: Tic-Tac-Toe: Rewrite some*HasAll() routines in SmartPlayer and TTEngine to use TTBoard.SIZE. Tutorials: Tic-Tac-Toe: Fix provided code. Need to pass TTEngine around, not just board. Tutorials: Tic-Tac-Toe: Drop second exercise. No one can get that far. General: Coordinate timeline of class, tutorials, and assignments better. Crosslink information more. I.e., plan the whole semester ahead of time. General: Have one TA whose sole responsibility is writing support code!!! There's simply not enough time to do that and be an instructor. If we can generate a good set of support code once, it will decrease the work for future semesters. General: Adapt COMP320's auto-tester to test all student's code. Could automatically generate Javadoc comments and UML diagrams. This could save lots of time for the labbies. General: Make variable, method, and class names more consistent, especially list parts. Make sure UML diagrams agree. General: Make sure all provided code is well-commented, has all Javadoc comments, a README, a test client, and UML diagram!!! Currently much of the code has insufficient or imprecise comments. General: Make sure all provided code has error output going to System.err, not System.out. General: Put all relevant provided code in a central location for use as a library. Have students import this code directly without copying it. This ensures that they don't change the code, and saves them from the mistakes of copying or retyping. Would need to show them how to use class paths. General: Make clearer what appropriate package structurings are, and make sure our sample code fits those guidelines. E.g., visitors should NOT be in a subpackage of their data structure. General: Coordinate wording and/or timing with COMP280 on introduction of O()? General: Provide prominent link to Sun's online Java API info. General: Create web pages that form a glossary of all the relevant patterns. General: Could create a web-based script to handle requests for and tallying of slip days. General: Design a better set of web pages.